GESTIONE MAGAZZINO 2

Transcript

1 GESTIONE MAGAZZINO 2 Un azienda vuole automatizzare la procedura di gestione delle scorte del suo magazzino di articoli organizzato per reparti e classificati in base alla categoria merceologica. Nella gestione degli articoli, inoltre, si deve supporre che uno stesso articolo possa essere fornito da più fornitori con eventuali differenze nel costo d acquisto. Il sistema informativo deve essere in grado di : produrre i listini degli articoli; gestire gli acquisti effettuati dai vari fornitori; gestire gli articoli in base alla categoria merceologica; gestire i costi d acquisto per ogni fornitore per individuarne quello minino; gestire il prezzo di vendita degli articoli; controllare gli articoli sotto scorta relativamente ad ogni reparto; gestire i fornitori. Considerato il problema proposto, precisando eventuali ipotesi aggiuntive, si realizzi: un analisi della realtà di riferimento che illustri le premesse per i successivi passi della progettazione della base di dati; uno schema concettuale della base di dati; uno schema logico della base di dati; la definizione delle relazioni della base di dati in linguaggio SQL. LA SOLUZIONE Analisi Ipotesi aggiuntive Schema concettuale Schema logico Definizione delle relazioni Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 1

2 Analisi La prima entità da considerare è quella che si riferisce agli articoli. L entità richiesta è una anagrafe degli articoli presenti nel magazzino dell azienda con le proprietà essenziali ed indispensabili a gestire tutte le richieste proposte dal problema. In particolare per la gestione degli ordini e il controllo degli articoli sotto scorta si ritiene necessario l utilizzo, per ogni articolo, dei valori relativi alla scorta minima e alla scorta massima. Per il concetto di scorta, scorta minima, scorta massima, valorizzazione degli articoli si faccia riferimento all analisi del problema relativa al problema: GESTIONE MAGAZZINO 1. La seconda entità da analizzare è l anagrafe dei fornitori contenente tutti i fornitori già registrati con le proprietà essenziali. Le successive entità da utilizzare consentono di classificare gli articoli sia per reparto che per categoria merceologica. Per gestire la classificazione degli articoli per reparto ( sezione in cui è possibile suddividere un ufficio, un negozio, un ospedale, ecc. ) si deve prevedere un entità reparti contenente la descrizione di tutti i reparti (per es., nel caso di un supermercato, : casalinghi, alimentari, detersivi, surgelati, ecc.) in cui è suddiviso fisicamente il magazzino. Il reparto è il luogo fisico in cui viene collocato l articolo. L uso dell entità categorie (come d altra parte richiesto dallo stesso problema) si rende necessaria in quanto si vuole classificare gli articoli in base alla categoria merceologica, ovvero in base a delle caratteristiche particolari (anche soggettive) che possono associare articoli diversi. Tutti gli articoli di un supermercato presenti in un reparto, per es. reparto detersivi, potrebbero essere ulteriormente classificati in : detersivi liquidi, detersivi in polvere, detersivi per piatti, detersivi per lavatrice, ecc. Il vantaggio di tale classificazione è quello di poter gestire gli articoli in modo più accurato e dettagliato valutando esattamente le differenze, per es., di costi, di vendite, di giacenze, ecc. per articoli dello stesso tipo. Il reparto è una classificazione fisica, la categoria merceologica una classificazione logica. La considerazione fondamentale riguarda il tipo di associazione prevista fra l entità Articoli e l entità Fornitori. La soluzione proposta (rispetto a quella presentata nel problema GESTIONE MAGAZZINO 1) prevede che uno stesso articolo possa essere acquistato da uno o più fornitori e quindi essere, eventualmente, acquistato a costi diversi. In questo caso, pertanto, l associazione fra le due entità diventa molti-a-molti con evidente introduzione di un ulteriore entità che possa consentire tale associazione. Il problema, in definitiva, comprende la gestione di cinque tabelle, individuate dalle cinque entità definite nel modello E/R. Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 2

3 Le tabelle relative ai Reparti ed alle Categorie merceologiche posso essere definite come tabelle di controllo che vengono create nella fase iniziale di creazione ed avviamento del database e che, nel tempo, subiranno poche modifiche. Il programma di creazione di tali tabelle deve, comunque, prevedere la possibilità di aggiornamento dei dati presenti nelle stesse tabelle. Anche la tabella relativa ai Fornitori può essere creata nella fase iniziale, ma è evidente che tale tabella subisce aggiornamenti più frequenti rispetto alle precedenti. Per quanto riguarda la gestione della tabella relativa agli Articoli presenti in magazzino e la gestione della tabella contenente gli Acquisti effettuati dai Fornitori con indicazione dell articolo acquistato e del fornitore che ha effettuato la fornitura, devono essere realizzate mediante un tipico programma di aggiornamento che prevede le funzioni di inserimento, cancellazione e modifica dei record contenuti nelle suddette tabelle. In particolare la tabella Articoli viene aggiornata solo quando si devono modificare dati quali il prezzo di vendita, la scorta minima e massima oppure quando si deve introdurre nella tabella un nuovo articolo. La tabella relativa agli Acquisti, invece, viene aggiornata ad ogni nuova introduzione di merce nel magazzino. Infatti, in tale tabella è previsto che, per ogni articolo acquistato, vengano inseriti, oltre al codice dell articolo, il codice del fornitore, il costo d acquisto, la quantità acquistata e la data in cui la merce è stata introdotta in magazzino. Per questo motivo la tabella può contenere record diversi aventi il codice articolo e il codice fornitore uguali (nel loro insieme non formano una chiave primaria). La tabella così definita consente di registrare tutti i Movimenti di carico ovvero l insieme di ogni singola registrazione relativa ad ogni singolo articolo acquistato. In definitiva il tipo di aggiornamento riguarda, in questo caso, solo l inserimento di nuovi record. Il vantaggio di questa soluzione è quello, avendo per ogni fornitore la storia di tutti gli acquisti effettuati, di poter effettuare delle statistiche sulle variazioni dei costi d acquisto anche eventualmente legati alla quantità acquistata ed alla data d acquisto (per esempio si potrebbe calcolare il costo medio effettuato da un fornitore, per un certo articolo, in un dato intervallo di tempo). Lo svantaggio potrebbe essere quello che il numero di record della tabella potrebbe aumentare notevolmente se il numero degli acquisti avviene con frequenza notevole. In questo caso si potrebbero cancellare i record relativi ad un periodo non più significativo oppure conservare nella tabella Articoli solo i dati relativi, per es., all ultimo anno ed utilizzare un altra tabella storica in cui travasare tutti i record contenenti informazioni relative agli anni precedenti. Se, invece, la soluzione adottata prevedesse il trattamento del solo ultimo costo d acquisto, senza gli altri dati precedentemente indicati, la gestione della tabella sarebbe, ovviamente, diversa. In tal caso l insieme del codice fornitore e del codice articolo costituiscono una chiave primaria ed, inoltre, gli aggiornamenti della tabella riguarderebbero sia gli inserimenti di nuovi record (quando si acquista per la prima un articolo da un fornitore) e sia modifiche a record già esistenti (quando si riacquista un articolo da un fornitore con un costo diverso). Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 3

4 Ipotesi aggiuntive Entità Articolo : la chiave primaria è artificiale ad autoincremento per evitare i problemi generati dalle omonimie (articoli con la stessa descrizione ma provenienti da produttori o fornitori diversi). Sono previste solo le proprietà strettamente necessarie per la risoluzione dei quesiti. Entità "Reparto": la chiave primaria è artificiale ad autoincremento. Sono previste solo le proprietà strettamente necessarie per la risoluzione dei quesiti. L utilizzo dell entità Reparto permette di ottenere una descrizione univoca per ogni reparto associato a ciascun articolo. Entità "Categoria": la chiave primaria è artificiale ad autoincremento. Sono previste solo le proprietà strettamente necessarie per la risoluzione dei quesiti. L utilizzo dell entità Categoria permette di ottenere una descrizione univoca per ogni categoria merceologica associata a ciascun articolo. Entità "Fornitore": la chiave primaria è artificiale ad autoincremento. Sono previste solo le proprietà strettamente necessarie per la risoluzione dei quesiti. Relazione Acquisti : la chiave primaria è artificiale ad autoincremento. La relazione contiene oltre alle chiavi esterne alle entità interessate (Articolo e Fornitore) le proprietà necessarie alla completa gestione di un acquisto effettuato da un fornitore e precisamente la quantità acquistata, il costo (che può cambiare, anche per lo stesso fornitore, di volta in volta in funzione di situazioni particolari), e data in cui è avvenuto l acquisto stesso. Schema concettuale della base di dati Tipi di entità I tipi di entità caratteristici del sistema sono : Reparto Categorie Fornitore Articolo contiene l elenco dei reparti in cui è diviso il magazzino; contiene l elenco delle categorie che possono essere utilizzate per classificare gli articoli; contiene l elenco anagrafico dei fornitori; contiene l elenco dei tutti gli articoli del magazzino; Attributi Tipo di entità Articolo Reparto Categoria Fornitore Sistema informativo Gestione magazzino 2 Attributi idarticolo, Descrizione articolo, Sconto da effettuare al cliente, Prezzo di vendita, Giacenza, Scorta Massima, Scorta Minima, Reparto, Categoria Merceologica; idreparto, Descrizione Reparto; idcategoria, Descrizione Categoria; idfornitore, Ragione Sociale, Indirizzo, Residenza, Partita Iva, Numero di Telefono, ; Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 4

5 Relazioni fra le entità Le relazioni tra i tipi di entità nel modello dei dati sono individuate nel seguente Modello Entità/Relazioni (E/R) : CATEGORIA FORNITORE Acquisti ARTICOLO Quantità Costo DataAcquisto REPARTO Tra l entità Fornitore e l entità Articolo esiste un associazione molti-a-molti in quanto, come richiesto dal problema, un fornitore può fornire uno o più articoli e ciascun articolo può essere fornito da uno o più fornitori. Tra l entità Reparto e l entità Articolo esiste un associazione uno-a-molti in quanto un reparto può contenere uno o più articoli e ciascun articolo deve essere sistemato in un solo reparto. Tra l entità Categoria e l entità Articolo esiste un associazione uno-a-molti in quanto una categoria merceologica può essere associata ad uno o più articoli e ciascun articolo deve essere abbinato ad una sola categoria. Nel modello E/R, inoltre, sono stati indicati, oltre ai nomi delle entità, l opzionalità od obbligatorietà delle associazioni (indicate rispettivamente con linea tratteggiata o continua). Il modello viene verificato utilizzando le regole di lettura : ogni fornitore deve fornire uno o più articoli, ogni articolo deve essere fornito da uno o più fornitori. ogni reparto può contenere uno o più articoli, un articolo deve essere abbinato ad un solo reparto. Ovvero, ci possono essere reparti che non contengono (per il momento) alcun articolo ma ogni articolo deve essere sistemato in un reparto. ogni categoria può essere associata ad uno o più articoli, un articolo deve essere associato ad una sola categoria. Ovvero, ci possono essere categorie che non sono abbinate (per il momento) ad alcun articolo ma ogni articolo deve essere abbinato ad una categoria. Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 5

6 Schema logico della base di dati Come tipo di schema logico, dovendo poi realizzarlo nello standard SQL, si sceglie di utilizzare quello relazionale. Nello schema E/R precedente si può osservare che esiste una relazione molti-a-molti (N:N) tra i tipi di entità Fornitore e Articolo. Applicando il processo di normalizzazione (definito dalle forme normali) si deve inserire una entità ausiliaria (Acquisti) che trasforma la relazione molti-a-molti in due relazioni : uno-a-molti (1:N) tra Fornitore e Acquisti, e molti-a-uno (N:1) tra Acquisti e Articolo. Applicando le regole di corrispondenza tra il modello E/R ed il modello Relazionale si passa dal precedente schema concettuale al modello logico che viene descritto sia nella forma testuale che in quella grafica. Rappresentazione testuale dello schema logico : Nella rappresentazione testuale si elencano le tabelle (indicando per ciascuna i campi) che rappresentano le entità dello schema concettuale e le tabelle che rappresentano le eventuali relazioni molti-a-molti, introducendo, inoltre, le chiave esterne per rappresentare le associazioni (le chiavi primarie sono sottolineate, le chiavi esterne sono in corsivo). Si elencano di seguito le tabelle che rappresentano le entità dello schema concettuale : tbreparti (idreparto,reparto) tbcategorie (idcategoria, categoria) tbfornitori (idfornitore,ragionesociale, indirizzo, residenza, partitaiva, telefono, ) tbarticoli (idarticolo, articolo, ksreparto, kscategoria, prezzovendita, sconto, giacenza, scortamax, scortamin) tbacquisti (idacquisto, ksarticolo, ksfornitore, quantità, costo, dataacquisto Per realizzare l associazione uno-a-molti fra l entità Reparto e l entità Articolo si introduce, fra gli attributi dell entità a molti (Articolo), la chiave esterna ksreparto associata alla chiave primaria idreparto dell entità a uno (Reparto). Per realizzare l associazione uno-a-molti fra l entità Categoria e l entità Articolo si introduce, fra gli attributi dell entità a molti (Articolo), la chiave esterna kscategoria associata alla chiave primaria idcategoria dell entità a uno (Categoria). Per realizzare l associazione molti-a-molti fra l entità Fornitore e l entità Articolo si introduce una terza entità Acquisti, che, oltre ad attributi propri dell associazione (Quantità, Costo e Data) ha, come attributi, la chiave esterna ksarticolo associata alla chiave primaria idarticolo dell entità Articolo e la chiave esterna ksfornitore associata alla chiave primaria idfornitore dell entità Fornitore. Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 6

7 Rappresentazione grafica dello schema logico : La rappresentazione grafica dello schema logico relativo al sistema informativo per la gestione del Magazzino è il seguente : Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 7

8 Definizione delle Tabelle Nel definire le tabelle e la struttura delle stesse, è consigliabile elencarle partendo dalle tabelle che non presentano chiavi esterne. In successione si definiscono le tabelle le cui chiavi primarie sono utilizzate da altre tabelle come chiavi esterne. Nel prospetto seguente, per es., si definiscono prima le tabelle tbfornitori, tbreparti e tbcategorie (in tal caso l ordine è soggettivo), quindi la tabella tbarticoli, che ha fra gli attributi due campi definiti come chiavi esterne alle tabelle tbreparti e tbcategorie, ed, infine, la tabella tbacquisti, che ha fra gli attributi due campi definiti come chiavi esterne alle tabelle tbfornitori e tbarticoli. Tabella Nome campo Chiave Tipo dati Dim. Dec. Null Descrizione tbfornitori idfornitore Primaria Intero 4 Autoincremento ragionesociale Carattere 40 Vincolo : valori unici indirizzo Carattere 30 residenza Carattere 30 partitaiva Carattere 11 Vincolo : valori unici telefono Carattere 15 SI Carattere 15 SI tbreparti idreparto Primaria Intero 4 Autoincremento reparto Carattere 30 Vincolo : valori unici tbcategorie idcategoria Primaria Intero 4 Autoincremento categoria Carattere 30 Vincolo : valori unici tbarticoli idarticolo Primaria Intero 4 Autoincremento articolo Carattere 30 ksreparto Esterna Intero 4 Integrità referenziale con idreparto della tabella tbreparti kscategoria Esterna Intero 4 Integrità referenziale con idcategoria della tabella tbcategorie prezzovendita Decimale 6 2 sconto Decimale 4 2 SI giacenza Decimale 6 2 scortamax Decimale 6 2 Scorta massima scortamin Decimale 6 2 Scorta minima tbacquisti idacquisto Primaria Intero 4 Autoincremento ksarticolo Esterna Intero 4 Integrità referenziale con idarticolo della tabella tbarticoli ksfornitore Esterna Intero 4 Integrità referenziale con idfornitore della tabella tbfornitori quantità Decimale 6 2 costo Decimale 6 2 dataacquisto Data/ora 8 SI Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 8

9 Definizione delle relazioni della base di dati in SQL Lo schema logico relazionale precedente (tabelle, relazione ed applicazione dei vincoli di integrità dei dati e referenziale) può essere creato con le seguenti istruzioni SQL (proposte in versione per ACCESS e MYSQL. ACCESS CREATE TABLE tbreparti ( idreparto Counter PRIMARY KEY, reparto Char(30) NOT NULL UNIQUE); CREATE TABLE tbcategorie ( idcategoria Counter PRIMARY KEY, categoria Char(30) NOT NULL UNIQUE); MySQL CREATE TABLE tbreparti( idreparto int(4) AUTO_INCREMENT PRIMARY KEY, reparto varchar(30) NOT NULL UNIQUE) TYPE=MyISAM; CREATE TABLE tbcategorie( idcategoria int(4) AUTO_INCREMENT PRIMARY KEY, categoria varchar(30) NOT NULL UNIQUE) TYPE=MyISAM; CREATE TABLE tbfornitori ( idfornitore Counter PRIMARY KEY, ragionesociale Char(40) NOT NULL UNIQUE, indirizzo Char(30) NOT NULL, residenza Char(30) NOT NULL, partitaiva Char(11) NOT NULL UNIQUE, telefono Char(15), Char(30)); CREATE TABLE tbfornitori ( idfornitore int(4) AUTO_INCREMENT PRIMARY KEY, ragionesociale varchar(40) NOT NULL UNIQUE, indirizzo varchar(30) NOT NULL, residenza varchar(30) NOT NULL, partitaiva char(11) NOT NULL UNIQUE, telefono varchar(15), varchar(30)) TYPE=MyISAM; CREATE TABLE tbarticoli ( idarticolo Counter PRIMARY KEY, articolo Char(30) NOT NULL, ksreparto Long NOT NULL, kscategoria Long NOT NULL, prezzovendita Single NOT NULL, sconto Single, giacenza Single NOT NULL, scortamax Single NOT NULL, scortamin Single NOT NULL, FOREIGN KEY(ksreparto) REFERENCES tbreparti(idreparto), FOREIGN KEY(kscategoria) REFERENCES tbcategorie(idcategoria)); CREATE TABLE tbarticoli ( idarticolo int(4) AUTO_INCREMENT PRIMARY KEY, articolo varchar(30) NOT NULL, ksreparto int(4) NOT NULL, kscategoria int(4) NOT NULL, prezzovendita decimal(8,2) NOT NULL, sconto decimal(4,2), giacenza decimal(6,2) NOT NULL, scortamax decimal (6,2) NOT NULL, scortamin decimal (6,2) NOT NULL) TYPE=MyISAM; Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 9

10 CREATE TABLE tbacquisti ( idacquisto Counter PRIMARY KEY, ksarticolo Long NOT NULL, ksfornitore Long NOT NULL, quantità Single NOT NULL, costo Single NOT NULL, dataacquisto Datetime, FOREIGN KEY(ksarticolo) REFERENCES tbarticoli(idarticolo), FOREIGN KEY(ksFornitore) REFERENCES tbfornitori(idfornitore)); CREATE TABLE tbacquisti( idacquisto int(4) AUTO_INCREMENT PRIMARY KEY, ksarticolo int(4) NOT NULL, ksfornitore int(4) NOT NULL, quantità decimal(6,2) NOT NULL, costo decimal(8,2) NOT NULL, dataacquisto date) TYPE=MyISAM; Nota : le istruzioni proposte per MySQL sono relative all uso di tabelle tipo MyISAM che non supportano l integrità referenziale definita con FOREIGN KEY. Il tipo di tabella InnoDB, invece, supporta la FOREIGN KEY similmente ad ACCESS. Es. di analisi di un problema a cura del Prof. Salvatore DE GIORGI - I.T.I.S. FALANTO TALSANO (TA) Pag. 10