Analisi soluzione DB esercizio 1

Transcript

1 Analisi soluzione DB esercizio 1 Analisi del problema Il testo propone un database capace di archiviare fatture con i relativi dati dei clienti che acquistano e degli articoli trattati. I dati fondamentali contenuti in una fattura sono quindi gli articoli acquistati compresa la loro quantità ed il loro costo ed i dati del cliente che effettua l acquisto degli stessi. Ogni fattura ha poi una serie di dati relativi alla sua emissione, (n progressivo, data, ecc.). Prederemo quindi una entità capace di memorizzare le informazioni relative a tutte le fatture considerate. L entità Fatture potrà avere gli attributi: NFattura (attributo chiave), DataFattura (data di rilascio della fattura) Essa sarà relazionata ai Clienti, tenendo appunto conto di coloro a cui la merce viene venduta. L emittente della fattura, nel nostro caso, si considera che sia sempre il medesimo (una certa ditta). L entità Clienti avrà attributi classici, vale a dire: CodiceFiscale, Nome, Cognome, NomeDitta, Via, NCiv, Citta, NTele, NCell, Mail Infine vi sono gli Articoli acquistati. Per essi si prevede di considerare una ulteriore entità che permetta di elencarli. L entità Articoli avrà come attributi: CodiceArticolo, Nome, Descrizione, Quantita, Prezzo. Le associazioni tra le entità considerate saranno: tra Fatture e Cliente, con molteplicità n da Cliente verso Fatture, in quanto un cliente può avere intestate più fatture, ed 1 da Fatture verso Cliente, in quanto una fattura è intestata senz altro ad un solo cliente, ossia molteplicità tra Fatture e Articoli con molteplicità n da Fatture ad Articoli, in quanto in una fattura ci si riferisce a più articoli, e n da Articoli a Fatture, in quanto un articolo può essere presente in più fatture. Forma relazionale schema della base di dati Articoli(CodiceArticolo, Nome, Descrizione, Prezzo) Clienti(PartitaIVA, Nome, Cognome, NomeDitta, Via, NCiv, Citta, NTele, NCell, Mail) Fatture(NFattura, DataFattura, PartitaIVA) Articoli_Fatture(CodiceArticolo,NFattura, Quantita) Script SQL di implementazione del DB CREATE TABLE Articoli ( CodiceArticolo INT UNSIGNED PRIMARY KEY, NomeArt VARCHAR(40) NOT NULL, Descrizione VARCHAR(100) NOT NULL, Prezzo DECIMAL(6,2) NOT NULL ); CREATE TABLE Clienti ( Nome VARCHAR(40), Cognome VARCHAR(40), NomeDitta VARCHAR(60), Via VARCHAR(40) NOT NULL, NCiv SMALLINT UNSIGNED NOT NULL, Citta VARCHAR(40) NOT NULL, NTele VARCHAR(20), NCell VARCHAR(20), Pagina 1

2 Mail VARCHAR(40) ); CREATE TABLE Fatture ( NFattura INT UNSIGNED PRIMARY KEY, DataFattura DATE NOT NULL, PartitaIVA INT(11) UNSIGNED NOT NULL, FOREIGN KEY(PartitaIVA) REFERENCES Clienti(PartitaIVA) ); CREATE TABLE Articoli_Fatture ( CodiceArticolo INT UNSIGNED NOT NULL, NFattura INT UNSIGNED NOT NULL, PRIMARY KEY(CodiceArticolo, NFattura), Quantita INT UNSIGNED NOT NULL, FOREIGN KEY(CodiceArticolo) REFERENCES Articoli(CodiceArticolo), FOREIGN KEY(NFattura) REFERENCES Fatture(NFattura) ); Ulteriori considerazioni Riguardo alla entità Clienti si deve specificare che in alcuni casi essi potrebbero essere dei privati ed in altri delle ditte, e proprio per questo sono stati previsti degli attributi che possano essere utilizzati in modo alternativo, alcuni nel caso il cliente sia una ditta (NomeDitta) e altri nel caso sia un privato (Nome e Cognome). In tal caso si ha una situazione di generalizzazione, che in questo caso viene risolta utilizzando un'unica tabella ed alternando quando necessario valori del tipo di attributo attinente e valori NULL negli attributi non utilizzati (ad esempio per un cliente privato saranno valorizzati gli attributi Nome e Cognome, mentre rimarrà NULL l attributo NomeDitta, e l inverso per un cliente che sia una ditta ). Si noti che potenzialmente gli attributi convolti in questo scambio potrebbero essere in un numero ben superiore (ad esempio una ditta potrebbe avere anche attributi come RagioneSociale e/o NumDipendenti) e un privato Professione e/o TitoloStudio ). Anche questi saranno quindi coinvolti in una valorizzazione che si alterna (alcuni valorizzati se ditta, altri se privato, mentre alcuni valorizzati sempre, NTel o NCell o Mail, ad esempio, perché non dipendenti da questa differenza). Un'altra considerazione riguarda le chiavi primarie ed esterne della relazione Articoli_Fatture. In questa relazione abbiamo come attributi chiave primaria una coppia di attributi: CodiceArticolo e NFattura. Infatti: Un certo articolo compare in una fattura se il suo codice è abbinato a quello di quella fattura. In modo simmetrico si può dire che una fattura tratta un certo articolo per la medesima osservazione. In realtà queste coppie di valori presenti in quella che diviene la tabella ponte Articoli_Fatture, hanno senso se ripetute una sola volta, in quanto non ha senso che uno stesso articolo compaia più volte in una stessa fattura. Ecco quindi che il valore combinato CodiceArticolo e NFattura è logico sia considerato chiave primaria in modo combinato (chiave primaria su due campi, ossia combinata). Tuttavia questi campi fungono singolarmente anche da chiavi esterne (CodiceArticolo sull entità Articoli e NFattura sull entità Fatture). In questo senso quindi in modo combinato i due campi fungono da chiave primaria, ma ognuno di essi è anche chiave esterna dei relativi campi chiave primaria nelle entità Articoli e Fatture. Si consideri anche che lo script SQL implementa anche, per completezza, istruzioni per i vincoli di integrità referenziali. Pagina 2

3 Diagramma UML del DB Modello alternativo Tenuto conto della generalizzazione Clienti -> Ditte / Privati considerata in precedenza, vale a dire che un cliente può essere sia una ditta che un privato e quindi devono essere presenti attributi opportuni per rappresentare entrambe le tipologie di cliente, una implementazione più razionale del DB potrebbe considerare di inserire nel diagramma E/R delle sottoentità che isolino tali differenze in apposite entità, a differenza dal primo modello dove tutti gli attributi erano accorpati nell entità Clienti (con largo uso di valori NULL). Tale variante è senza dubbio da preferire appena il numero di attributi sia anche solo poco più di una coppia. Questo comporterebbe un diagramma costituito dalle entità: Ditte dati specifici di clienti di tipo ditte Privati dati specifici di clienti di privati Clienti dati generici dei clienti (sia che siano ditte o che siano privati) Fatture dati relativi alle fatture Pagina 3

4 Articoli dati relativi agli articoli (pensati come tipo di articolo in senso astratto) In particolare le associazioni e le molteplicità di questa variante rimangono uguali a quelle precedenti escludendo la parte oggetto della generalizzazione Clienti -> Ditte / Privati. Infatti tra Clienti e Fatture si è detto e definito che corrisponde una associazione n a m. Viceversa tra Clienti e Ditte esiste una relazione 1 a 1, ossia ad alcuni clienti generici corrisponderà una ditta. In modo inverso anche ai dati di una ditta corrisponderanno dati generici di un ben preciso cliente. In modo analogo ad alcuni clienti generici corrisponderanno i dati di uno ed un solo cliente privato. Quindi una istanza su Clienti sarà collegata un unica istanza di Privati. Viceversa ad un privato corrisponderanno precisi dati generici di un certo cliente. Certamente siccome queste due istanze sono esclusive, una istanza su Clienti avrà corrispondenza con i dati contenuti nell una o nell altra entità. In questo caso potendo considerare la suddivisione dei clienti in ditte e privati totale, ossia tutti i clienti ricadranno per forza in queste due categorie, i dati presenti in clienti verranno sempre associati ad una ed una sola istanza in Ditte o in Privati in modo alternativo. In tal caso si è scelto come chiave primaria sia di Clienti che di Ditte e di Privati il campo PartitaIVA, ma c e da osservare che in Ditte e Privati essi funge anche da chiave esterna. Questo può succedere grazie al fatto che PartitaIVA funge da collegamento per una associazione 1 a 1, quindi ad ogni numero di partita IVA di Clienti, sarà in corrispondenza di una ed una sola istanza di Ditte o in alternativa una ed una sola istanza di Privati. Quindi inserito un record in Clienti, avremo un solo record in Ditte o in Privati che abbia partita iva coincidente. Anzi avremo sicuramente un record con il medesimo codice di partita iva in una delle due entità (perché il cliente è sicuramente una ditta o un privato). Quindi abbiamo il caso piuttosto particolare che sia in Ditte che in Privati la chiave primaria funge anche da chiave esterna. Forma relazionale schema della base di dati Articoli2(CodiceArticolo, Nome, Descrizione, Prezzo) Clienti2(PartitaIVA, Via, NCiv, Citta, NTele, NCell, Mail) Ditte2(PartitaIVA, NomeDitta) Privati2(PartitaIVA, Nome, Cognome, Professione) Fatture2(NFattura, DataFattura, PartitaIVA) Articoli_Fatture2(CodiceArticolo,NFattura, Quantita) Script SQL di implementazione del DB CREATE TABLE Articoli2 ( CodiceArticolo INT UNSIGNED PRIMARY KEY, NomeArt VARCHAR(40) NOT NULL, Descrizione VARCHAR(100) NOT NULL, Prezzo DECIMAL(6,2) NOT NULL ); CREATE TABLE Clienti2 ( Via VARCHAR(40) NOT NULL, NCiv SMALLINT UNSIGNED NOT NULL, Citta VARCHAR(40) NOT NULL, NTele VARCHAR(20), NCell VARCHAR(20), Mail VARCHAR(40) ); Pagina 4

5 CREATE TABLE Ditte2 ( RagSoc VARCHAR(10) NOT NULL, NomeDitta VARCHAR(60) NOT NULL, NDipendenti INT UNSIGNED NOT NULL, FOREIGN KEY(PartitaIVA) REFERENCES Clienti2(PartitaIVA) ); CREATE TABLE Privati2 ( Nome VARCHAR(30) NOT NULL, Cognome VARCHAR(30) NOT NULL, Professione VARCHAR(60) NOT NULL, FOREIGN KEY(PartitaIVA) REFERENCES Clienti2(PartitaIVA) ); CREATE TABLE Fatture2 ( NFattura INT UNSIGNED PRIMARY KEY, DataFattura DATE NOT NULL, PartitaIVA INT(11) UNSIGNED NOT NULL, FOREIGN KEY(PartitaIVA) REFERENCES Clienti2(PartitaIVA) ); CREATE TABLE Articoli_Fatture2 ( CodiceArticolo INT UNSIGNED NOT NULL, NFattura INT UNSIGNED NOT NULL, PRIMARY KEY(CodiceArticolo, NFattura), Quantita INT UNSIGNED NOT NULL, FOREIGN KEY(CodiceArticolo) REFERENCES Articoli2(CodiceArticolo), FOREIGN KEY(NFattura) REFERENCES Fatture2(NFattura) ); (segue diagramma UML del DB) Pagina 5

6 Diagramma UML del DB Pagina 6