-FIORENTINO MICHELE- Appunti BD Maratea.pdf

BASI DI DATI – MARATEA UNIVERSITÀ DEGLI STUDI DI NAPOLI “PARTHENOPE” Appunti a cura di FIORENTINO MICHELE INTRODUZIONE I seguenti appunti sono stati scritti durante la frequentazione del corso di BASI DI DATI tenuto dal professore Antonio Maratea nell’ a.a. 2020/2021...

BASI DI DATI – MARATEA UNIVERSITÀ DEGLI STUDI DI NAPOLI “PARTHENOPE” Appunti a cura di FIORENTINO MICHELE INTRODUZIONE I seguenti appunti sono stati scritti durante la frequentazione del corso di BASI DI DATI tenuto dal professore Antonio Maratea nell’ a.a. 2020/2021. BASI DI DATI - INDICE Le lezioni: 7, 10, 13, 16, 19, 25, 28, 30, 33 e 36 sono Laboratorio. 2 - Lez 1/2: Introduzione DB, RDBM e RDBMS 5 - Lez 3: Modellazione concettuale 8 - Lez 4/5: Approfondimenti entità e chiavi 12 - Lez 6: Grado di un’associazione 15 - Lez 8: Modelli E/R estesi 19 - Lez 9: Concetti sugli insiemi 24 - Lez 11: Traduzione da modello concettuale a relazionale, parte 1 (regole di traduzione e traduzione delle associazioni) 27 - Lez 12: Traduzione da modello concettuale a relazionale, parte 2 (specializzazione, unione e entità deboli) 31 - Lez 14: Progettazione del software 33 - Lez 15: Algebra relazionale, parte 1 37 - Lez 17: Algebra relazionale, parte 2 (varianti di JOIN) 40 - Lez 18: Algebra relazionale, parte 3 (operatore gamma e logica trivalente) 43 - Lez 20: Algebra relazionale, parte 4-1 (vincoli di traduzione) 46 - Lez 21: Algebra relazionale, parte 4-2 (vincoli di traduzione) 49 - Lez 22: Introduzione SQL e Comandi base Oracle RDBMS 51 - Lez 23: SQL e differenze con RA 53 - Lez 24: SQL: GROUP BY e HAVING 55 - Lez 26: SQL: ORDER BY, Op. insiemistici, Query innestate ed esempi 58 - Lez 27: Ulteriori esempi, Query innestate correllate e FOR ALL 60 - Lez 29: Estensioni di SQL, PL/SQL 65 - Lez 31: Query gerarchiche e viste 69 - Lez 32: Vincoli (asserzioni e trigger) 73 - Lez 34: Politiche di reazione e Transazioni 75 - Lez 35: Problemi, proprietà e protocolli delle transazioni 79 - Lez 37: Teoria della normalizzazione Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 1 LEZIONE 1/2 Con database si intende un insieme di dati strutturati, ovvero omogeo per contenuti e formato, memorizzati in un computer. Prima di procedere oltre, è importante capire la differenza fra dato e informazione: - dato: è una porzione di informazione condensata in un formato (numerico o alfanumerico). Possiamo pensare ad un dato come un’informazione grezza; - informazione: deriva da un dato (o da un insieme di dati) che sono stati sottoposti ad un processo di interpretazione che li ha resi signficativi per il destinatario. Da notare come dal dato si passi all’informazione, e come dall’informazione si passi alla conoscenza, che è il nostro obiettivo. Possiamo inoltre distinguere diverse categorie di dato, quali dati: strutturati, non strutturati e semi strutturati: - strutturati: sono dati che si presentano sotto la forma “attributo:valore”. Tali dati sono fatti e numeri oggettivi che possono essere facilmente raccolti, semplificando l’esportazione, la memorizzazione e l’organizzazione all’interno di un DB (es. nome: Mario, cognome: Rossi, indirizzo: via Roma 10…). - non strutturati: sono dati come testo libero, immagini e suoni, i quali sono difficili da raccogliere, e che rendono quindi complicata l’esportazione, la memorizzazione e l’organizzazione all’interno di un BD. Inoltre ingombrano molta memoria. - semi strutturati: sono misti, quindi contengono sia dati strutturati che non strutturati. Possiamo pensare ad una pagina web e ad un file xml. Un ulteriore tipo di dato è il metadato (aka catalogo), il quale consiste in un’informazione che descrive un insieme di dati. DBMS Prima degli anni ’70, quando non esistevano ancora i database relazionali, ogni qual volta un utente aveva la necessita di lavorare su un database potevano presentarsi dei conflitti. All’inizio ogni utente aveva (e lavorava) su una copia del DB, ma in tal modo ogni file sarebbe stato diverso dall’altro. Anche sincronizzare i file non sarebbe bastato in quanto potevano comunque verificarsi errori di comunicazione, perdita di dati e sovrascritture, oltre a non risolvere completamente il problema dei confilitti. Anche considerare un unico file e permettere l’accesso ad un utente per volta non sarebbe sufficiente, in quanto potrebbero verificarsi ancora problemi di accesso alle risorse, sovrascritture e conflitti. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 2 Capiamo come il principale problema di un DB siano gli accessi concorrenti. La soluzione consiste nell’inserire una sorta di “muro” fra gli utente e il file. Tale muro prende il nome di DBMS. Un database management system (DBMS) è un sistema computerizzato che permette agli utenti di creare e mantenere un database. Il DBMS è un sistema software general- purpose che facilita il processi di definizione, costruzione, manipolazione e condivisione di un database fra i vari utenti e le applicazioni. Il suo scopo è quello di proteggere i dati e di regolare l’accesso degli utenti (in quanto funge da intermediario). Il DBMS con il quale avremo a che fare è quello relazionale, il quale rappresenta il modo migliore per organizzare “dati strutturati”. La correlazione fra RDBMS e dati strutturati è così forte che parlare di uno implicare parlare dell’altro. Un DBMS garantisce diverse proprietà: - persistenza: i dati vengono memorizzati in modo permanente; - integrità: quando si crea un DB si introducono delle regole di integrità, ovvero dei vincoli che i dati devono rispettare, senza le quali rischieremmo di corrompere il DB (es. un voto deve essere compreso fra 18 e 30). Inoltre garantisce integrità anche nelle situazioni di scrittura concorrente da parte di più utenti; - affidabilità: i DB sono dotati di procedure di ripristino consistenti in caso di insorgenza di guasti, cioè il ripristino deve avvenire in modo coerente (pensiamo se fossimo nel mezzo dell’eliminazione di 1000 tuple. Ne eliminiamo 300 e salta la corrente. Al prossimo avvio dobbiamo trovare il DB al momento precedente dell’operazione di eliminazione). In caso di guasti straordinari (prende fuoco il server) non possiamo fare nulla se non abbiamo previsto l’utilizzo di backup, mirroring o geolocalizzazioni. - condivisione: un DB gestisce l’accesso degli utenti, i quali potrebbero avere permessi diversi, e determinate risorse potrebbero essere accessibili sono attraverso determinati permessi. Un DBMS può essere rappresentato con 3 livelli di astrazione, quali (dal meno astratto al più astratto): fisico, logico, di vista-logica. - fisico: in che ordine i dati sono scritti su disco. (è quello che influisce maggiormente sulle prestazioni) - logico: può seguire diversi modelli, fra cui il modello relazionale. - di vista logica: è quello visto dalle applicazioni. La vista infatti dipende dai permessi che abbiamo dato a tali applicazioni. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 3 Inoltre i DB devono garantire indipendenza fisica e indipendenza logica: - indipendenza fisica: si può cambiare la struttura in cui sono memorizzati i dati senza cambiare lo schema logico e viceversa; - indipendenza logica: si può cambiare il modo in cui vengono visualizzati i dati (vista logica) senza cambiare lo schema logico e viceversa; Nei sistemi moderni l’indipendenza fisica è fortemente garantita, a differenza di quella logica che non è sempre garantita. Modello Relazionale Un modello relazionale è un modello logico di rappresentazione dei dati di un database implementato su DBMS. Tali sistemi prendono il nome di RDBMS. Il modello relazionale è fortemente legato al linguaggio SQL (Structured Query Language), in quanto è il linguaggio standard per i DB relazionali. Per questo motivo DBR e SQL sono spessi usati come sinonimi. È importante non confondere SQL con i DBR che usano SQL (come ad esempio Oracle, PostgresSQL o mySQL), i quali utilizzano delle estensioni proprietarie dell’SQL (DL/SQL per Oracle, TSQL per Postgres). SQL vs NoSQL I database alternativi ad DB relazionali prendono il nome di DB NoSQL (Not Only SQL). Tali DB sono nati come un movimento di DB alternativi a quelli relazionali. I motivi per cui volessimo preferire un tipo di DB ad un altro sono molteplici: - SQL: sono più coerenti, affidabili, prestazioni ouù elevate per dati strutturati. Inoltre hanno un linguaggio universale (SQL) che ha poi ulteriori estensioni. Sono inadaguati per dati non strutturati e non godono di scalabilità (aumento delle prestazioni all’aumentare del numero di server). È un sistema con schema, in quanto ha una struttura che deve essere progetta (richiedere competenze ed è impegnativo). - NoSQL: prestazioni più elevate, ideale per dati non strutturati o semi strutturati, e scalabilità. Non hanno un linguaggio universale e più che DB sono dei “depositi di dati”. È un sistema senza schema (schemeless), in quanto non ha una struttura. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 4 LEZIONE 3 : Modellazione concettuale Il modello concettuale è il progetto architetturale del DB. Tale progetto è di tipo grafico, e viene creato attraverso dei diagrammi entità/associazione, aka diagrammi ER (entity/relationship). Tali diagrammi devono stabilire quali informazioni devono essere memorizzate e le relazioni fra queste informazioni. Possiamo distinguere diverse tipologie di dati: rilevanti, disponibili, meterializzati e runtime. I dati rilevanti devono essere incrociati con quelli disponbili, in quanto un dato può essere rilevante ma non disponibile, o viceversa può essere disponible ma non è rilevante. Se mi mancano dei dati rilevanti, devo fare in modo di raccoglierli. I dati materializzati sono tutti quei dati che vengolo salvati su disco, mentre quelli runtime sono tutti quei dati che vengono creati durante l’esecuzione del programma. Gli unici dati devono essere inseriti all’interno di un DB sono solo quelli materializzati. Inoltre, è anche importante individuare un contesto, aka mini-mondo (in quanto è un aspetto limitato della realtà), in quanto ci permette di meglio definire la struttura di un DB. (pensiamo al DB di una biblioteca dove si fanno solo consultazioni con una dove è possibile anche prendere in prestito libri. I due DB avranno strutture diverse). Elementi di un diagramma ER (secondo Navathe) Un diagramma ER contiene tre elementi: entità, attributi e associazioni. L’ entità rappresenta una classe di oggetti del mondo reale (oggetti sia materiali che immateriali). Ogni entità è caratterizzata da un nome e viene rappresentata con un rettangolo. Gli attributi rappresentano le caratteritische delle entità. Ogni attributo è caratterizzato da un nome e viene rappresentato con un ovale. Possiamo distinguerne di diversi tipi: - ATOMICI e STRUTTURATI: Un attributo è atomico quando è costituito da un solo elemento, mentre è definito strutturato quando è composto da più elementi. Un attributo atomico è ad esempio un nome, mentre uno strutturato è ad esempio un indirizzo (che contiene varie informazioni, come via, CAP, numero civico, ecc…). Da notare che in un DBR non usiamo mai “dati non strutturati”, quindi l’indirizzo (che può presentarsi sottoforma di testo) deve essere scomposto in ulteriori elementi. Di conseguenza, un attributo avrà più attributi. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 5 - UNIVOCI e MULTIVALORE: Un attributo è univoco quando è possibile inserire un solo valore, mentre è multivalore quando è possibile inserire più valori (in tal caso, verrà rappresentato da un doppio ovale). Ad esempio, una persona può avere un solo codice fiscale e una sola data di nascita, ma potrebbe avere più nomi o più numeri di telefono. Un attributo che è sia strutturato che multivalore prende il nome di complesso. Tale tipo di attributo viene rappresentato solo con un ovale. Da notare che tale attributo non dovrebbe avere altri tipi strutturati, altrimenti sarebbe meglio riconsiderarlo come una entità. - DERIVATI: un attributo è derivato quando può essere derivati da altri dati, e viene rappresentato con un ovale tratteggiato (es. età derivata da DN). - TOTALI e PARZIALI: un attributo è totale in quanto ogni entità, nel mondo reale, ha tale attributo, mentre è parziale nel caso opposto, ovvero quando non è detto che ogni entità, nel mondo reale, abbia tale attributo. Ad esempio, tutte le persone hanno un codice fiscale (totale) ma non tutti abbiamo un numero di telefono (parziale). - OBBLIGATORI e FACOLTATIVI: un attributo è obbligatorio quando è considerato necessario per instanziare un’entità, mentre è facoltativo nel caso opposto. Ad esempio, per istanziare uno studente è necessario conoscerne la matricola, mentre gli altri attributi potrebbero essere facoltativi. La differenza fra attributi TOT/PAR e OBB/FAC consiste nel fatto che gli attributi totali e parziali rappresentano una caratteristica intrinseca dell’attributo, mentre gli attributi obbligatori e facoltativi rappresentano una scelta del progettista. Ad esempio la “data di morte” è totale in quanto tutti ne hanno una, al contrario del numero di telefono. Tuttavia potremmo decidere di rendere obbligario inserire un numero di telefono. Non è detto, inoltre, che un attributo totale debba essere obbligatorio. Ad esempio, la data di morte, essendo sconosciuta, non può essere obbligatoria. - DINAMICI e STATICI: un attributo dinamico è un attributo che varia nel tempo (o che varia spesso), mentre è statico quando NON varia nel tempo (o che sia molto improbabile che vari). Se un attributo è statico o dinamico dipende dal ciclo di vita del DB, che prende il nome di orizzonte dinamico del DB. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 6  Ad esempio, un nome o un numero di telefono possono essere considerati statici in quanto è molto improbabile che possano variare; al contrario, il “totale di merce” stoccato in un magazzino è dinamico in quanto varia ad ogni ritiro/deposito di merce, o ancor peggio è dinamico l’età, in quanto varia ad ogni istante di tempo. Se i dati hanno un ciclo di vita molto breve potrebbero comunque essere considerati dinamici (pensiamo ad una fiera che volesse conoscere l’età media dei suoi visitatori, in tal caso potremmo considerare l’età “statica”, o meglio ne consideriamo una sua approssimazione). NB: I dati dinamici dovrebbero essere evitati in quanto potrebbero creare delle incoerenze. Le associazioni rappresentano un legame fra due o più entità. Viene rappresentata graficamente da un rombo contentente un verbo, il quale fornisce una direzione di lettura. Le associazioni possono essere totali o parziali (ad esempio, pensiamo all’esempio sopra. Posso avere che tutti gli studenti prendano in prestito dei libro o che tutti i libri siano presi in prestito da degli studenti). In un’associazione è totale disegniamo una doppia linea fra l’entità e il rombo. L’associazione, come in matematica, è un’associazione fra insiemi, e quindi sono importanti il concetto di totalità e la molteplicità: - totalità: possiamo pensare all’esempio sopra. Posso avere che tutti gli studenti prendano in prestito dei libro o che tutti i libri siano presi in prestito da degli studenti). In un’associazione è totale disegniamo una doppia linea fra l’entità e il rombo. In caso contrario, l’associazione si dice parziali. - molteplicità: un’associazione può essere biunivoca (1:1), multivalore (1:N), univoca (N:1), multivalore doppia (M:N). nb: M:N e non N:N per non creare ambiguità, infatti non è detto che i due numeri debbano essere uguali. nb: non esistono associazioni che associano altre associazioni. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 7 LEZIONE 4/5 – Approfondimento Entità e chiavi Precisazioni Per convenzione, le associazioni si leggono da sx a dx, e dall’alto verso il basso. Per le associazioni ci interessa solo la totalità per la diretta e per l’inversa. È come se ci ponessimo delle domande (es. biblioteca): - diretta: quanti libri può prendere in prestito uno studente? molti! - inversa: un libro da quanti studenti può essere preso in prestito? molti! Da tali domande otteniamo la molteplicità, in questo caso M:N. Con univocità possiamo intendere due significati diversi, a seconda che stiamo parlando di una istanza o di un’entità: - istanza: un solo valore per attributo; - entità: univocità fra le istanze (es. non ci sono due studenti che hanno lo stesso numero di telefono); Aspetti di un’entità Possiamo analizzare un’entità sotto due aspetti: - aspetto intensionale: o schema intensionale, è rappresentaro dall’elenco degli attributi di un’entità. - aspetto estensionale: o stato estensionale, è rappresentato da una collezione concreta di istanze di un’entità in un deterimato istante di tempo. Pensiamo all’entità studente, il suo schema intensionale sarà rappresentato da tutti gli attributi che caratterizza uno studente, mentre il suo stato estensionale sarà rappresentato dal valore che assumono tali attributi, in un determinato istante di tempo, per ogni studente. nb: lo stesso ragionamento vale anche per le associazioni, con la differenza che non parleremo di una collezione di istanze ma di coppie. esempio DB: Biblioteca (gli iscritti sono studenti che hanno preso in prestito uno o più libri) aspetto intensionale (studente): matr, nome, cognome, data_nascita, CF, via… aspetto estensionale (studente): insieme degli studenti (s1,s2,s3…); aspetto intensionale associazione: (prende in prestito): data, durata; aspetto estensionale associazione (prende in prestito), dati i prestiti (p1,p2,p3…): (p1,s2,data1,durata3), (p2,s5,data3,durata1), (p3,s1,data4,durata2)… Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 8 Chiave Una chiave, più nello specifico una chiave primaria, è un attributo (o un insieme di attributi, detta multiattributo) che identifica univocamente una specifica istanza di un’entità. Una chiave possiede una serie di proprietà, che devono valere a livello intensionale, ovvero è: obbligatoria, costante, univoca e (preferibilmente) atomica. - obbligatoria: in quanto deve identificare ogni istanza dell’entità. Non possiamo quindi pensare che ad un’istanza possa mancare l’identificativo. Che l’attributo sia parziale (es. telefono) o totale (es. CF) è irrilevante, fintanto che l’attributo è obbligatorio. Tuttavia, è preferibile utilizzare un attributo totale. - costante (o immutabile): in quanto non vogliamo che la chiave possa cambiare di valore. - univoca: in quanto non vogliamo più valori di chiave per ogni entità. - atomica: è preferibile atomica, ma nulla vieta che possa strutturato, o più in genere un insieme di attributi (l’importante è che non sia MAI non strutturato). Tali proprietà devono valere a livello “intensionale”, cioè devono valere qualsiasi sia la collezione concreta di istanze che si va a raccogliere. Al contrario, se fosse “estensionale” ci basterebbe che valghi solo per la nostra specifica collezione di istanze, che tuttavia è variabile, ed è quindi facile che una di queste proprietà possa essere poi violata. Da notare che queste proprietà possano essere rispettate in modo più o meno rigido. Infatti più siamo rigidi nei confronti di queste proprietà, più è difficile trovare una chiave: la combinazione (nome, cognome, data_nascita, luogo_nascita) e l’indirizzo non sono univoci, quindi non sono buoni candidati per essere una chiave, ma se ci pensiamo bene non è un buon candidato nemmeno il numero di telefono (non univoco, pensiamo al numero di casa o al fatto che i numeri sono riciclati) e nemmeno il CF (omocodia), e quindi rimane solo la matricola come candidato (nata proprio per questo motivo). Non c’è bisogno di essere molto intransigenti su queste proprietà, altrimenti non saremmo mai in grado di trovare una chiave naturale. Se per il nostro DB presumiamo che il presentarsi di un certo conflitto per un attributo è molto raro (ad esempio perché l’orizzontale temporale è molto breve) potremmo ritenere di utilizzare quell’attributo come chiave, e pensare successivamente ad un modo per gestire un eventuale conflitto. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 9 CHIAVI NATURALI vs CHIAVI ARTIFICALI Una chiave naturale è formata da un attributo “reale” dell’entità, che ha un significato anche al di fuori del database (un esempio è il CF). Una chiave artificiale è formata da un attributo privo di un significato proprio. Di solito consiste in un contatore che si autoincrementa ad ogni istanza che si aggiunge (pensiamo ad un ID). Dovrebbe essere utilizzato come ultima spiaggia, quando nessun attributo gode della proprietà di chiave primaria (o se tale chiave risulterebbe grande e complessa) in quanto non ha alcun significato al di fuori del DB. NB: con chiave “artificiale” non intendiamo il senso stretto del termine. Ad esempio matricola, CF e ISBN potrebbero sembrare artificiali, ma in realtà sono naturali. Questo perché sono sigle standard, riconosciute da specifici enti. Anche il codice ASIN di AMAZON potrebbe sembrare artificiale ma, essendo Amazon un’azienda molto grande che ricoprire un’enorme quantità di prodotti, può essere considerato naturale. Fondamentalmente, sono naturali perché hanno senso anche al di fuori del loro DB. SUPERCHIAVI Tutti gli attributi che godono delle proprietà di chiavi prendono il nome di superchiavi. Di queste superchiavi a noi interessano quelle col minor numero di attributi, che prendono il nome di superchiavi minimali, o chiavi candidate. Una fra le chiavi candidate diventa chiave primaria. La scelta spetta al progettista. es. SUPERCHIAVI CHIAVI CANDIDATE CHIAVE PRIMARIA (matr, CF) (matr) (matr) (matr) (CF) (CF) (Nome, Cognome, DN, LN) Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 10 Entità debole e Entità forte Un’entità debole è un’entità la cui chiave dipende dalla chiave di un’altra entità, e viene rappresentata con un doppio rettangolo. Al contrario, un’entità forte è un’entità la cui chiave non dipende da nessun altra entità. La chiave di una entità debole prende il nome di chiave debole, e viene tratteggiata. Un’istanza di un’entità debole viene identificata dalla chiave debole più la chiave dell’entità associata. L’associazione che collega un entità debole ad un’altra entità prende il nome di associazione identificante, e viene rappresentata con un doppio rombo. Tale associazione è sempre del tipo 1:N (multivalore). es. Biblioteca Una biblioteca conserva una o più copie di ogni libro, ognuna delle quali è identificata da un “num_copia”. Il libro rappresenta l’entità forte, e ISBN è la sua chiave, mentre copia libro rappresenta l’entità debole, e num_copia è la sua chiave. Normalmente solo num_copia non sarebbe sufficiente come chiave, ma in combinazione con il codice ISBN si. Libro e Copia Libro sono collegate attraverso l’associazione identificante multivalore “Ha”. nb: Studente adesso non sarà più collegato a Libro, ma a Copia Libro attraverso una normale associazione (N:M, “prende in prestito”). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 11 LEZIONE 6 - Grado di un’associazione Il grado di un’associazione indica il numero di entità legate dall’associazione stessa. Associazioni di grado superiore al 2 Utilizziamo associazioni di grado superiore al 2 quando la dipendenza fra le entità è superiore al grado 2. Il loro utilizzo è necessario in quanto talvolta non siamo in grado di ottenere tutte le informazioni che ci interessano con le sole associazioni binarie. Da notar bene che non è detto che un’associazione di grado superiore possa sostituire tutte quelle di grado inferiore, in quanto alcune informazioni potrebbero essere non ricavabili utilizzando solo associazioni di grado superiore. (ad es. non è detto che un’associazione di grado 3 possa sostituire tutte quelle di grado 2, in quanto potrebbero esserci delle infromazioni che non possiamo ricavare dalla terna). Considerazioni: - Un’entità ha totalità se ha totalità su tutte le entità a cui è collegata. - Per individuare la molteplicità di un’associazione dobbiamo considerare le “eventuali associazioni binarie” che collega un’entità con le altre, per ogni entità, e fra queste prendiamo quella maggiore. - Tali associazioni sono quasi sempre del tipo M:N:K (grado 3, ma uguale per gli altri). Infatti, se notiamo che tutte le associazioni di grado 2 del nostro modello sono del tipo M:N (multivalore doppia), molto probabilmente è necessario utilizzare un’associazione di grado 3. - D’altra parte, se si presenta una terna del tipo M:N:1 è molto probabile che non è necessario utilizzare un’associazione di grado 3 ma bastano quelle di grado 2. nb: le associazioni di grado: - 3: sono rare, ma vengono utilizzate; - 4: sono molto rare, ed è improbabile (ma non impossibile) il loro utilizzo; - 5 o superiore: non è impossibile, ma quasi sicuramente abbiamo sbagliato qualcosa. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 12 Esempio DB pizzeria Abbiamo 3 entità: cliente, pizza (tipo) e pizzeria. Dove: - un cliente può ordinare una o più pizze, e una pizza può essere ordinata da uno o più clienti; - una pizza può essere preparata da una o più pizzerie, e una pizzeria può preparare una o più pizze: - un cliente riceve la pizza da una o più pizzerie, e una pizzeria invia la pizza a uno più clienti. Notiamo come tutte queste associazioni siano del tipo M:N, che potrebbe farci intuire la presenza di una terna. Infatti possiamo notare che tale modello ha una grave mancanza: non sappiamo da quale pizzeria proviene una determinata pizza, ed è un’informazione non ricavabile con nessuna associazione binaria. Tale problema può essere risolta creando una terna “consuma”, le quali sono una collezioni di triple del tipo (cliente1, pizza3, pizzeria1) + più eventuali attributi dell’associazione. Notare che questa terna non ha reso inutile l’utilizzo di altre associazioni binarie, ad esempio non conosciamo il menu delle varie pizzerie ed è un informazione non ricavabile da “consuma”. Creeremo quindi un’associazione “Ha nel Menu” che collega Pizza con Pizzeria. Esempio associazione 4 grado: Supponiamo che tale modello abbia anche una 4 entità Pizzaiolo, tale che: - un pizzaiolo lavora in una sola pizzeria, e in una pizzeria possono lavorare uno o più pizzaioli (N:1). Supponiamo di voler conoscere la pizza preferita di un cliente, preparata da un certo pizzaiolo che lavora in una determinata pizzeria. In questo caso creeremo un’associazione “preferisce” che collega tutte e 4 le entità. Tale associazione sarà del tipo M:N:K:P (multivalore doppia). Attributo prezzo in questo esempio? Dipende: - Se fosse su Pizza staremmo dicendo che universalmente tutte le pizze di un certo tipo hanno quel prezzo (Potrebbe andare bene tuttavia per una catena). - Se fosse su Pizzeria, staremmo dicendo che tutte le pizze hanno lo stesso prezzo. - Se fosse su “ha nel menu”, staremmo dicendo che ogni coppia (Pizza, Pizzeria) ha un prezzo diverso (è la più verosimile). - Se fosse su “consuma” ripeteremmo l’informazione del prezzo per ogni ordine, e quindi si tratta di un’informazione ridondante (a meno che il prezzo (per una pizza) non venga deciso ogni singola volta per ogni singolo ordine). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 13 Modello Esempio Associazioni ricorsive Un’associazione ricorsiva è un’associazione fra un’entità e se stessa. Viene rappresentata come un’associazione ripiegata su stessa. Da notare che vale tutto il ragionemento fatto finora per le associazioni, infatti possiamo immaginare che si tratti di un’associazione fra due entità uguali. Da notare che: - un’entità può avere più associazioni ricosive; - possono esserci associazioni ricorsive di grado 3, ma sono molto rare; - è convenzione riportare il ruolo fra le due entità, che può essere: o simmetrico: se le due entità hanno lo stesso ruolo; o asimettrico: se le due entità hanno ruolo diverso. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 14 LEZIONE 8 – Modelli E/R estesi I modelli EER (extended entity/relationship) consentono una progettazione più accurata dello schema di dati, in quanto permette una rappresentazione più precisa dei vincoli fra i dati, e diminuiscono le ridondanze. Il modello EER comprende tutti i concetti del modello ER, a cui ne va ad aggiungere di nuovi, fra cui: - Specializzazione (o generalizzazione); - tipo Unione (o categoria); - ereditarietà degli attributi e delle associazioni. SPECIALIZZAZIONE (o generalizzazione) La specializzazione è un concetto che viene utilizzato quando due o più entità hanno molti attributi in comune. Infatti, in una situazione del genere, è molto probabile che queste entità siano una specializzazione di un’entità più generale. Ad esempio, studente e lavoratore sono entrambi una generalizzazione di persona. In particolar modo parleremo di: - generalizzazione, se leggiamo lo schema dal basso verso l’alto (es. studente si generalizza a persona); - specializzazione, se leggiamo lo schema dall’alto verso il basso (es. persona si specializza in studente). In modo simile alla programmazione ad oggetti, le due entità entità “specializzate” sono entità che eriditano dell’entità “generalizzata”, e nello schema gli attributi in comune devono essere riportati solo su questa entità. Da notar bene che fra gli attributi delle entità deve esserci almeno una chiave in comune, e quel che accadrà è che la chiave dell’entità “generalizzata” diventerà anche la chiave delle entità specializzate (la loro ex-chiave primaria diventa una chiave candidata). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 15 La specializzazione può essere di 2 tipi: - disgiunta D (disjointed) - sovrapposta O (overlapped) Il che ci porta a distinguere 4 casi diversi: - disgiunta parziale: l’intersezione fra gli insiemi delle entità specializzate è vuoto, e la loro unione non ricopre completamente l’insieme dell’entità generalizzata; - sovrapposta parziale: l’intersezione fra gli insieme delle entità specializzate non è vuoto (esiste almeno un’istanza che appartiene ad entrambe le entità), e la loro unione non ricopre completamente l’insieme dell’entità generalizzata; - disgiunta totale: l’intersezione fra gli insiemi delle entità specializzate è vuoto, e la loro unione ricopre completamente l’insieme dell’entità generalizzata. In questo caso si dice che le entità specializzate sono una copertura di quella generalizzata; - disgiunta totale: l’intersezione fra gli insiemi delle entità specializzate non vuoto, e la loro unione ricopre completamente l’insieme dell’entità generalizzata. Nel modello si inserirà una doppia linea per dire che è totale, ed una singola linea per dire che è parziale. All’interno del cerchietto che collega le entità andremo ad inserire una lettera: D se disgiunta, O se sovrapposta. Sul collegamento, dalla parte dell’entità specializzata, riporteremo una U di “Unione”. Esempi: DP: uno studente non può essere un lavoratore e viceversa. Non tutte le persone sono studenti o lavoratori. SP: uno studente può essere un lavoratore e viceversa. Non tutte le persone sono studenti o lavoratori. DT: uno studente non può essere un lavoratore e viceversa. Tutte le persone sono studenti o lavoratori. ST: uno studente può essere un lavoratore e viceversa. Tutte le persone sono studenti e/o lavoratori. nb: un’associazione fra entità specializzate è considerata un’associazione ricorsiva. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 16 TIPO UNIONE (o categoria) Il tipo Unione è concettualmente il contrario della specializzazione. In questo creeremo un’entità che sarà una specializzazione di entità già presenti nello schema. Utilizziamo il tipo Unione ogni qualvolta vogliamo un “OR”, cosa che non possiamo avere utilizzando i normali diagrammi ER, nel quale le associazioni sono tutte AND. Esempio: Supponiamo di avere 3 entità: azienda, persona, vendita. Se effettuassi una normale associazione azienda/vendita - persona/vendita, sarebbe come dire che “la vendita è associata ad un’azienda AND una persona”, quando in realtà io voglio sapere se “la vendità è associata ad un’azienda OR una persona”. Per fare questo assoceremo alla vendità nuova entità, cliente, che rappresenterà un’azienda oppure una persona. Dal punto di vista grafico, si rappresenta come una specializzazione al contrario. All’interno del cerchietto si riporta una U che sta per “Union”. (nb: ricorda che dal punto di vista algebrico la Union si rappresenta con una OR. es: Clienti = Aziende OR Persone) La lettura avviene dall’alto verso il basso, dove l’entità specializzata è una classe figlia di UNA E SOLO UNA delle classi madri, dalla quale erediterà gli attributi (ereditarietà selettiva). Ciò implica che il tipo Unione può essere solo digiunto, e quindi avremo solo 2 casi: disgiunzione totale e disgiunzione parziale. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 17 Considerazioni su tipo Unione: - sulla classe figlia riporteremo gli attributi in comune delle classi madri; - in un tipo Unione le classi madri non hanno mai una chiave naturale in comune, per questo motivo siamo costretti a costruire una chiave artificiale, che prende il nome di chiave surrogata; - se le classi madri avessero una chiave naturale in comune, non si tratterebbe più di un tipo Unione ma di una specializzazione vista al contrario; - sul collegamento, dalla parte della classe madre, riporteremo una U di “Unione”; - La totalità è quasi sempre presente (non c’è solo in casi estremi). DIFFERENZE specializzazione vs tipo unione - nella specializzazione abbiamo una classe madre e più classi figlie, nel tipo Unione abbiamo più classi madri ed una classe figlia; - nella specializzazione tutte le classi figlie ereditano tutti gli attributi della classe madre, nel tipo Unione la classe figlia eredita gli attributi di una sola delle classi madre (ereditarietà selettiva). - nella specializzazione abbiamo 4 casi, nel tipo Unione solo 2. - nella specializzazione la classe madre e le classi figlie hanno una chiave in comune, che viene riportata solo sulla classe madre. Nel tipo Unione ogni classe madre ha una sua chiave, e l’entità figlia ha necessariamente una chiave artificiale detta chiave surrogata. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 18 LEZIONE 9 - Concetti sugli insiemi C’è una sottile differenza fra come gli insiemi sono definiti in matematica e in informatica. In matematica, un insieme è una collezione di elementi di qualsiasi tipo, nel quale non è rilevante l’eventuale presenza di elementi ripetuti e quindi non vengono contati (anche se “per correttezza” non dovrebbero proprio esserci). logica dei SET. In informatica, il concetto di insieme viene esteso al concetto di multinsieme, nel quale è rilevante la presenza di eventuali elementi ripetuti e quindi vengono contati. logica dei BAG. Un multinsieme è definito da: - insieme di supporto: è l’insieme degli elementi distinti del multinsieme. - funzione di molteplicità: è una tabella di due colonne nella quale si mette da una parte gli elementi dell’insieme e dall’altra il numero di volte che sono contenuti (frequenza assoluta). Due insiemi (matematica), per essere uguali, devono contenere gli stessi elementi (non importa che siano ripetuti). Due multinsiemi, per essere uguali, devono avere lo stesso insieme di supporto e la stessa funzione di molteplicità. nb: un insieme rappresenta una collezione di elementi, e non un collezione ordinata di elementi. Ciò significa che due insiemi che hanno gli stessi elementi ma ordinati in modo diverso sono comunque uguali. Esempio: A = { 1,2,7,7,9 } //nb: un altro modo per definire un insieme è Z = { x ∈ N | x , ≤ , ≥, ≠, = } Es. studente ⨝ esame superato attr1 Θ attr2 Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 39 LEZIONE 18 – Algebra relazionale (parte 3, operatore gamma γ e logica trivalente) L’operatore gamma γ ci permette di effettuare una serie di azioni sulle tabelle. A sinistra dell’operatore verrà indicata una lista di funzioni mentre a destra verrà indicata una lista di attributi (attributi di raggruppamento). Le funzioni più comuni che vengono utilizzate sono: MAX, MIN, COUNT, SUM e AVG. La colonna su cui effettuare l’operazione dovrà essere indicata di fianco fra parentesi. Attraverso quest’operatore creeremo una nuova tabella che avrà una sola riga e tante colonne quante saranno il numero di funzioni utilizzate. GAMMA vs UNION L’operatore gamma γ risulta un’ottima scelta per effettuare delle operazione di unione, ovvero quando vogliamo accodare una tabella ad un’altra. Il motivo per cui vorremmo preferire gamma all’operatore UNION è che quest’ultimo ha due grossi svantaggi: 1. se deve essere fatto un join, fa più volte il join fra le stesse tabelle (poco efficiente); 2. dobbiamo conoscere a priori il numero di elementi distinti di un attributo. Al contrario, l’operatore gamma effettua il join una sola volta (se deve essere fatto), risultando più efficiente, e NON dobbiamo conoscere a priori il numero di elementi distinti di un attributo. La nuova tabella avrà come attributi le funzioni o gli attributi della tabella stessa abbiamo inserito nella lista, e avrò tante righe quanti sono i gruppi distinti. Il motivo per cui vorremmo inserire un attributo nella lista di funzioni è per visualizzarne la colonna nella tabella risultato, e di tale attributo dovremmo solo riportarne il nome. Da notar bene che tale attributo deve essere ANCHE presente nella lista di destra. nb: è concettualmente sbagliato inserire un attributo univoco all’interno della lista di funzioni o nella lista di attributi: - LF: perché non esiste qualcosa come un attributo univoco che rappresenta un gruppo perché ogni riga avrà in quel campo un valore diverso (non saprei cosa mettere). È un’operazione che NON si può effettuare, ed infatti in un sistema reale ci verrebbe restituito un errore; - LA: perché non creeremmo alcun raggruppamento, in quanto tutte le righe della tabella originale verrebbero considerate un gruppo distinto. È tuttavia un’operazione che si può effettuare ma non avrebbe senso; (Ad esempio, se raggruppassimo uno studente per matricola, otterremmo la stessa tabella della tabella studente). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 40 ESEMPI (tabelle riferimento: Studente ed Esame_superato): Voto medio, massimo e minimo degli esame superati: (nb: max e min si riferiscono al voto massimo/minimo registrati, e non il voto massimo/minimo in senso assoluto) AVG(V),MAX(V),MIN(V) γ (E_SUP) AVG(V) MAX(V) MIN(V) 25 30 21 Voto medio degli studenti di Informatica di Napoli: AVG(V) γ (σPROV=NA and CDL=INF(STUDENTE) ⨝ E_SUP) Esempio unione attraverso UNION e GAMMA Voto medio degli studenti di Informatica delle varie province: Union (Operazione diversa per ogni provincia) AVG(V) γ (σPROV=NA and CDL=INF(STUDENTE) ⨝ E_SUP) U AVG(V) γ (σPROV=SA and CDL=INF(STUDENTE) ⨝ E_SUP) U … ⨝ E_SUP) Gamma (Ci basta fare un’unica operazione) AVG(V),PROV γ PROV (STUDENTE ⨝ E_SUP) AVG(V) PROV 27 NA 25 SA 26 CE 25 AV 27 BN Notare che la tabella è ordinata per provincia (PROV a destra). Inoltre, se non avessimo inserito anche PROV a sinistra, non ne avremmo visualizzato la colonna. È anche possibile mostrare anche il numero di studenti attraverso la funzione COUNT(mat). ATTENZIONE: Non possiamo sostituire AND o OR all’operatore di UNION, questo perché AND richiede che entrambe le condizioni vengano rispettate, mentre OR metterebbe insieme tutti gli attributi (nel caso di sopra, è come se facessimo la media degli studenti di Napoli E Salerno), mentre noi vogliamo semplicemente accodare una tabella ad un’altra. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 41 OSSERVAZIONI SUI VALORI MANCANTI (NULL) I valori mancanti vengono riportati con NULL, e sono diversi da: - ‘ ‘ : è una stringa vuota - ‘NULL’: è una stringa che riporta il testo “NULL” - 0: è un numero Per le diverse situazioni dovremmo applicare una logica diversa, e (se è possibile) è preferibile evitare la possibilità di inserire dati mancanti. NON è possibile effettuare un’operazione di uguaglianza fra un NULL e qualcos’altro, e questo semplicemente perché NULL rappresenta un valore sconosciuto. σSECONDO_NOME = NULL(STUDENTE) ERRORE! Proprio perché NULL è un valore sconosciuto, se effettuiamo una somma fra diversi elementi, di cui almeno uno è NULL, il risultato sarà sempre NULL. Questo perché stiamo sommando a qualcosa una quantità sconosciuta, e quindi il risultato sarà una quantità sconosciuta. (sapendo che x1 = NULL)… X1 + X2 + X3 + … + Xn = NULL Logica Trivalente La logica trivalente viene utilizzata per gestire in modo corretto la presenza di valori nulli, e presenta 3 valori di verità: True, False e Unknown. La tavola di verità sarà qualcosa del tipo: P Q AND OR NOT(P) T T T T F T F F T F … … … … … T U U T F U U U U U Possiamo notare come questa logica sia fin troppo stringente. Per questo motivo non viene utilizzata nei sistemi reali, a cui viene invece preferita la logica bivalente “aggiustata”. Come sappiamo, non è possibile effettuare delle operazioni di uguaglianza su valori NULL. Invece si utilizza l’operatore IS. σSECONDO_NOME IS NULL(STUDENTE) CORRETTO! Per quanto riguarda le somme, i valori mancanti vengono semplicemente ignorati (come se fossero 0). Se facessimo un raggruppamento nel quale sono presenti valori NULL, verrebbero prima inseriti tutti i valori “normali” e infine verrebbe accodata la tabella dei NULL, anche logicamente sarebbe sbagliato in quanto non è detto che NULL 1 = NULL2 … NULLn. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 42 LEZIONE 20 – Algebra relazionale (parte 4-1, vincoli di traduzione) I vincoli fanno riferimento ad aspetti della realtà, e la loro implementazione è necessaria per evitare il verificarsi di situazione assurde. (es. data consegna di un prodotto antecedente alla data di ordine, questo può verificarsi perché data consegna e data ordine sono due attributi indipendenti). Classificazione dei vincoli: - STATICO vs DINAMICO: un vincolo è statico se rimane costante nel tempo, mentre un vincolo è dinamico se riguarda l’evoluzione dei dati. - INTENSIONALE vs ESTENSIONALE: un vincolo è intensionale se riguarda lo schema degli attributi (dominio), mentre un vincolo è estensionale se riguarda lo stato degli attributi. - su ENTITÀ vs su ASSOCIAZIONI: dipende dove agisce il vincolo. Con il diagramma ER siamo in grado di esprimere solo pochi vincoli, quali la molteplicità, la totalità e la chiave. È possibile rappresentare alcuni di questi vincoli attraverso un diagramma relazionale. L’inserimento di vincoli più complessi deve essere effettuato a livello di codice. Esempi: Un vincolo statico può essere un vincolo di dominio (il voto di un esame è compreso fra 18 e 30), mentre un vincolo dinamico può riguardare l’anno di iscrizione di uno studente: per potersi iscrivere al 2 anno si deve aver completato il primo. Un vincolo intensionale può riguardare il voto di un esame: può essere data la lode solo a chi prende 30. Un vincolo estensionale può riguardare il numero massimo di iscritti massimo di un certo anno, ovvero mi limita il numero di tuple. Il dominio di un attributo (DOM) non deve essere confuso con il dominio nello stato (ADOM), ovvero l’insieme di tutti i possibili valori distinti che si sono verificati. Tutti i sistemi relazionali prevedono l’esistenza del vincolo di integrità referenziale, il quale afferma che: ADOM(fk) ⊆ ADOM(pk). Si tratta di un vincolo di fondamentale importanza in quanto garantisce l’integrità delle chiavi esterne, infatti afferma che la chiave esterna è un sottoinsieme della chiave primaria, e che non è possibile “puntare” ad un valore che non esiste. Si tratta di vincolo estensionale (perché riguarda lo stato dei dati), ed è implicito nella maggior parte dei sistemi relazionali. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 43 UNIQUE Unique è un vincolo statico e intensionale, che viene utilizzato per tradurre le associazioni 1 a 1, e serve per non confonderlo con le associazioni 1 a N. Esso afferma che ogni valore che compare nella chiave esterna può comparire solo una volta. TOTALITÀ/NOT NULL La totalità viene rappresentata attraverso un altro vincolo: l’obbligatorietà. Esso viene indicato con “NOT NULL” dal lato della chiave esterna, e si tratta di un vincolo statico e intensionale. Un limite della traduzione è che non è possibile esprimere la “doppia totalità”, in quanto l’obbligatorietà potrà essere espressa solo sulla chiave esterna. Sebbene anche la chiave primaria sia obbligatoria, possiamo creare delle tuple anche senza collegarle con la tabella dove è presente la chiave esterna (non c’è più totalità). Se c’è doppia totalità, la scelta del lato da rappresentare è indifferente. Notiamo come ad ogni fattura corrisponda un acquisto (c’è totalità), infatti NOT NULL ci obbliga a non inserire valori nulli. Inoltre UNIQUE ci costringe anche ad inserire solo valori distinti. Tuttavia, d’altra parte, nulla mi impedisce di inserire degli acquisti a cui non corrisponde alcuna fattura (perdo la totalità), e quindi perdo di espressività. Nel caso delle associazioni 1 a N non è possibile esprimere la totalità dalla parte di 1, questo perché non ho nulla che mi costringe ad inserire delle tuple che sono collegate a tuple dell’altra tabella. Nel caso delle associazioni M a N non è possibile esprimere NESSUNA delle due totalità, questo perché, da ambo le parti, non ho nulla che mi costringe ad inserire delle tuple che sono collegate a tuple dell’altra tabella. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 44 TOTALITÀ SULLA SPECIALIZZAZIONE Consideriamo casi diversi in base a come vogliamo rappresentare le tabelle: - Tabella Unica: non è possibile esprimere la totalità in quanto potrei inserire una tupla che ha i valori dell’entità generica ma non quelli dell’entità specializzata. Così facendo non avrei più una specializzazione totale ma parziale. - Partizionamento Orizzontale: è possibile esprimere la totalità in quanto avrò una tabella diversa per ogni entità, che condividono tutti i dati dell’entità generica. - Partizionamento Verticale: non è possibile esprimere la totalità in quanto avrò necessariamente la tabella generica e le tabelle specializzate, e nulla mi impedisce di caricare solo i dati nella tabella generica. In tutti e 3 casi tuttavia non è possibile rappresentare la disgiunzione, che dovrà invece essere controllata tramite codice. Ogni tecnica ha i suoi vantaggi e svantaggi, e nessuna ci consente di rappresentare a pieno tutti i vincoli presenti nel costrutto di specializzazione. Esempio: Tutte le persone (nel nostro DB) sono studenti o lavoratori. Tuttavia con la tabella Unica potrei inserire solo i dati riguardo la persona e non i dati riguardo la specializzazione. Abbiamo quindi inserito una persona che non è né uno studente né un lavoratore. Da NOTARE inoltre che non è nemmeno possibile esprimere la disgiunzione, perché nulla ci impedisce di inserire i dati sia per studente che per lavoratore, creando di fatto uno studente/lavoratore. Con il partizionamento orizzontale avrò solo due tabelle: Studente e Lavoratore. Quindi quando dovrò aggiungere una persona questa dovrà essere necessariamente uno studente o un lavoratore. Da NOTARE tuttavia che non è possibile esprimere la disgiunzione perché nulla ci impedisce di caricare gli stessi dati sia sulla tabella degli studenti che in quella dei lavoratori. (NB: CF è PK, ma comunque matricola e tesserino sono UNIQUE). Con il partizionamento verticale avrò 3 tabelle: Persona, Studente e Lavoratore. Nulla mi impedisce di inserire i dati solo di Persona e non quelli di Studente o Lavoratore. Da NOTARE tuttavia che non è possibile esprimere la disgiunzione perché nulla ci impedisce di caricare gli stessi dati sia sulla tabella degli studenti che in quella dei lavoratori. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 45 LEZIONE 21 – Algebra relazionale (parte 4-2, vincoli di traduzione) TOTALITÀ SULL’UNIONE Non è possibile esprimere la totalità dell’Unione, questo perché nulla mi impedisce di inserire delle tuple nella classe figlia che non corrispondono a nessuna delle classi madri. Inoltre non è nemmeno possibile esprimere il concetto di UNION, in quanto nulla mi impedisce di inserire una tupla nelle classi madri che fanno riferimento alla stessa classe figlia (è come se la classe figlia avesse due madri, cosa che non dovrebbe accadere) tuttavia l’integrità referenziale non è violata. Quindi mi ritroverò invece con una INTERSEZIONE. La chiave esterna va sulla classe madre, e questa deve essere NOT NULL + UNIQUE, in quanto ogni tupla della classe madre fa (e deve fare) riferimento ad una SOLA tupla della classe figlia. Esempio: Come vediamo, il concetto di totalità non è rappresentato in quanto posso inserire delle tuple in Clienti che non corrispondono né a persona né a banca, e nemmeno il concetto di UNION è rappresentato in quanto posso avere sia Persona che Banca che fanno riferimento alla stesso Cliente (come nell’esempio). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 46 TOTALITÀ SU ENTITÀ DEBOLE La totalità dell’entità debole è rappresentabile, ed è espressa implicitamente (questo perché la chiave esterna dell’entità debole è anche una chiave primaria). La totalità a 1 invece non è esprimibile perché si tratta comunque di una 1 a N, e quindi dobbiamo dare priorirtà al lato N. Fondamentalmente dovremo solo indicare la chiave esterna e non fare null’altro. nb: in un’associazione 1 a N, quando l’entità a sinistra è composta aggregando gli elementi dell’entità a destra, dove tali elementi sono indipendenti, si parla di aggregazione (possiamo pensare ai pezzi di ricambio di un auto), mentre se tali elementi dipendono dall’entità a sinistra si parla di composizione (possiamo pensare ai pezzi che compongono la macchina). In entrambi i casi vengono indicati con “part of”, ma sono diversi dal punto di vista semantico in quanto la composizione è più forte rispetto all’aggregazione, ed infatti è rappresentata attraverso un’entità debole. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 47 SITUAZIONI PARADOSSALI Possono verificarsi delle situazioni in cui la totalità può essere espressa ma NON deve essere espressa, in quanto generebbe una situazione paradossale. Ad esempio, pensiamo alla seguente associazione ricorsiva: Se rispettiamo questa totalità, significa che per ogni persona dobbiamo inserire anche i dati della madre. Ma anche la madre è una persona, ed avrà a sua volta una madre, che a sua volta avrà un’altra madre, e così via… fondamentalmente ci ritroveremo in una situazione di stallo. ORDINE DI POPOLAMENTO ED ELIMINAZIONE L’integrità referenziale ci costringe a seguire un ordine di popolamento, ovvero dobbiamo caricare prima i dati nella tabella dove c’è la chiave primaria e poi carichiamo i dati dove c’è la chiave esterna. Questo perché se facessimo il contrario potremmo ritrovarci ad inserire delle chiavi esterne che non fanno riferimento ad alcuna tupla, violando quindi l’integrità referenziale. L’eliminazione delle tuple (al contrario) deve avvenire prima nella tabella dove c’è la chiave esterna e poi in quella dove c’è la chiave primaria. Infatti, se facessimo il contrario finiremmo per violare l’integrità referenziale (avremmo delle tuple la cui chiave esterna non punta ad alcuna chiave primaria). Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 48 INTRODUZIONE ALL’SQL In informatica, SQL (Structured Query Language) è un linguaggio standardizzato per database basati sul modello relazionale (RDBMS), progettato per le seguenti operazioni: - creare e modificare schemi di database (DDL = Data Definition Language); - inserire, modificare e gestire dati memorizzati (DML = Data Manipulation Language); - interrogare i dati memorizzati (DQL = Data Query Language); - creare e gestire strumenti di controllo e accesso ai dati (DCL = Data Control Language). A dispetto del nome, non si tratta perciò di un semplice linguaggio di interrogazione: alcuni suoi sottoinsiemi, infatti, permettono di creare, gestire e amministrare database. Al giorno d’oggi SQL è utilizzato come sinonimo dei RDBMS, e questo perché è un linguaggo ben fondato da un punto di vista formale e perché divenne rapidamento uno standard. L’SQL standard è in continua evoluzione nel tempo, sebbene ancora oggi le versioni più utilizzate siano quelle del ’92 e del ’99. Tuttavia tale standard non è utilizzato nella realtà dai DBMS, i quali invece utilizzano dei “dialetti”, ovvero delle leggere varianti dell’SQL. (In questo corso lo Standard è Oracle). LEZIONE 22 – Comandi base Oracle RDBMS I comandi base del DBL sono: - CREATE TABLE nomeT ( lista attributi di cui specifichiamo tipo, size ed eventuali vincoli ); - DROP TABLE nomeT; //elimina tabella - ALTER TABLE nomeT ADD (attributo) //altera la tabella (qui aggiunge attr) Possiamo distinguere vari tipi di dato, fra cui: - char (lunghezza fissa); - varchar (lunghezza variabile); - number (specifichiamo 2 valori, il numero di cifre e il numero di decimali); - date (tipo data, del tipo 01-JAN-97) nb: non esiste il tipo boolean. Appunti a cura di Fiorentino Michele – Università degli studi di Napoli “Parthenope” | 49 Fra i vincoli abbiamo: PRIMARY KEY, NOT NULL, UNIQUE, CHECK. Per quanto riguarda CHECK possiamo usarlo per verificare se un certo valore che inseriamo corrisponde ad un dominio: CHECK sesso IN (‘M’,’F’,’U’); O per verificare se un certo numero è compreso in un certo valore: CHECK (voto