Progettazione logica Analisi delle prestazioni su schemi E-R Ristrutturazione di schemi E-R Traduzione verso il modello relazionale Progettazione Logica

requisiti del Sistema informativo progettazione concettuale SCHEMA CONCETTUALE progettazione logica SCHEMA LOGICO progettazione fisica SCHEMA FISICO

Obiettivo della progettazione logica “Tradurre" lo schema concettuale (schema E-R) in uno schema logico (modello relazionale) che rappresenti gli stessi dati in maniera corretta ed efficiente Progettazione Logica

Dati di ingresso e uscita schema concettuale informazioni sul carico applicativo modello logico Uscita: schema logico documentazione associata Progettazione Logica

Non si tratta di una pura e semplice traduzione Lo schema E-R va ristrutturato: Semplificazione della traduzione: alcuni aspetti dello schema concettuale non sono direttamente rappresentabili nel modello logico Ottimizzazione del progetto: è necessario considerare le prestazioni Progettazione Logica

Ristrutturazione dello Schema E-R Carico applicativo Ristrutturazione dello schema E-R Fase 1 Schema E-R ristrutturato Modello logico Traduzione nel modello logico Fase 2 Schema logico

Fase 1: Ristrutturazione schema E-R E' indipendente dal modello logico scelto e si basa sui due principi di: semplificazione ottimizzazione Osservazione: uno schema E-R ristrutturato non è (più) uno schema concettuale nel senso stretto del termine Progettazione Logica

Analisi delle prestazioni su schemi E-R Per ottimizzare il risultato abbiamo bisogno di analizzare le prestazioni a questo livello Le prestazioni non sono valutabili con precisione su uno schema concettuale, dato che dipendono anche da parametri fisici: - dal sistema per la gestione di basi di dati utilizzato - dalle strutture dati utilizzate per memorizzare le tabelle - dai vari modi in cui si possono realizzare le operazioni in SQL Progettazione Logica

Consideriamo degli "indici di prestazione" dei parametri che regolano le prestazioni di uno schema E-R: occupazione di memoria (spazio): spazio di memoria necessario per memorizzare i dati descritti dallo schema dipende dal numero di occorrenze di entità e relazioni previste costo di una operazione (tempo): numero di occorrenze (di entità e relationship) visitate per rispondere a un’operazione sulla base di dati Progettazione Logica

Informazioni necessarie per l’analisi delle prestazioni Per studiare questi parametri abbiamo bisogno di conoscere, oltre allo schema, le seguenti informazioni volume dei dati: numero di occorrenze di ogni entità dello schema numero di occorrenze di ogni relationship dello schema dimensioni di ciascun attributo (di entità o relationship) caratteristiche delle operazioni: tipo di operazione (interattiva o batch) frequenza dell’esecuzione dati coinvolti (entità e/o relationship) Progettazione Logica

Schema di riferimento Cognome Telefono Impiegato Dipartimento Nome Città Indirizzo Telefono Dipartimento Composizione Sede Direzione Afferenza Impiegato Progetto Partecipazione Nome Cognome Budget Data Via CAP (1,1) (0,1) (1,N) (0,N) Codice

Tavola dei volumi vi sono riportati i concetti dello schema col volume previsto a regime

Occorrenze di una relationship Il numero delle occorrenze di una relationship dipende da: Numero di occorrenze delle entità coinvolte nella relationship Numero medio di partecipazioni di una occorrenza di entità all’occorrenza della relationship Esempio: Volume Composizione = Volume Dipartimento Volume Afferenza  Volume Impiegato Volume Direzione = Volume Dipartimento Volume Partecipazione = 3  Volume Impiegato Progettazione Logica

Esempio di valutazione di costo delle operazioni Operazione: assegna un impiegato a un progetto trova tutti i dati di un impiegato, del dipartimento nel quale lavora e dei progetti ai quali partecipa trova i dati di tutti gli impiegati di un certo dipartimento per ogni sede trova i suoi dipartimenti con il cognome del direttore e l’elenco degli impiegati del dipartimento Progettazione Logica

Descrizione delle operazioni L’analisi delle operazioni principali richiede la codifica di: tipo dell’operazione : Interattiva (I) o Batch (B) frequenza: numero medio di esecuzioni in un certo periodo di tempo schema di navigazione: frammento dello schema E/R interessato dall’operazione sul quale viene disegnato (con delle frecce) il “cammino logico” da percorrere per accedere alle informazioni di interesse Progettazione Logica

Tavola delle operazioni Progettazione Logica

Regola 80-20 Regola 80-20: l’80% del carico è generato dal 20% delle operazioni Dunque il carico si può valutare accuratamente basandoci sulle principali operazioni previste Per ogni operazione significativa si costruisce uno schema di navigazione (frammento di di schema E-R interessato all’operazione) Progettazione Logica

Operazione 2: trova tutti i dati di un impiegato, del dipartimento nel quale lavora e dei progetti ai quali partecipa Cognome (0,N) Codice Impiegato Telefono Nome Data (1,N) (0,1) (1,1) Dipartimento Afferenza Nome Budget (1,N) Progetto Partecipazione schema di navigazione

Tavola degli accessi Per ogni operazione significativa si costruisce una tavola degli accessi basata sullo schema di navigazione il campo costrutto specifica il tipo di concetto (entità o associazione) nel campo accessi si conta il numero degli accessi necessario per eseguire una volta l’operazione il campo tipo è riferito al tipo di operazione: le operazioni di scrittura (S) sono più onerose di quelle di lettura (L) il peso degli accessi in scrittura è in genere considerato doppio di quello delle letture Progettazione Logica

Tavola degli accessi Un accesso può essere di tipo L (lettura) o S (scrittura) Il numero delle istanze si ricava dalla tavola dei volumi mediante semplici operazioni es: in media ogni impiegato partecipa a 6000/2000 = 3 progetti Progettazione Logica

Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari Progettazione Logica

1. Analisi delle ridondanze Una ridondanza in uno schema E-R è una informazione significativa ma derivabile da altri dati in questa fase si decide se eliminare le ridondanze eventualmente presenti o mantenerle Progettazione Logica

Ridondanze Vantaggi Svantaggi semplificazione delle interrogazioni riduzione del numero degli accessi necessari per calcolare il dato derivato Svantaggi appesantimento degli aggiornamenti maggiore occupazione di spazio Progettazione Logica

Forme di ridondanza in uno schema E-R attributi derivabili: da altri attributi della stessa entità (o relazione) da attributi di altre entità (o relazioni) relazioni derivabili dalla composizione di altre relazioni in presenza di cicli Progettazione Logica

Attributo derivabile Importo netto Fattura IVA Importo lordo Progettazione Logica

Attributo derivabile da altra entità Importo totale Composizione Acquisto Prodotto Prezzo (1,N) Importo totale è ottenibile con operazioni di aggregazione Progettazione Logica

Ridondanza dovuta a ciclo Corso Studente Frequenza (0,N) (1,N) Professore Insegnamento (1,1) Docenza Ridondanza dovuta a ciclo

Mantenere o meno la ridondanza? La decisione di mantenere o eliminare una ridondanza va presa confrontando il costo di una esecuzione delle operazioni che coinvolgono il dato ridondante e l’occupazione di memoria, nei casi di presenza e assenza della ridondanza Progettazione Logica

Analisi di una ridondanza Residenza Persona Città Numero abitanti (1,1) (1,N) L’attributo numero abitanti è derivabile da una operazione di conteggio delle istanze di persona residenti in una città Progettazione Logica

tavola dei volumi Operazione 1: memorizza una nuova persona con la relativa città di residenza (500 volte al giorno) Operazione 2: stampa tutti i dati di una città (incluso il numero di abitanti) (2 volte al giorno) Progettazione Logica

Presenza di ridondanza Operazione 1 Operazione 2 Progettazione Logica

Assenza di ridondanza Operazione 1 Operazione 2 n.persone/n.città = media accessi per calcolare il numero di abitanti di una città Progettazione Logica

Presenza di ridondanza Costi: Operazione 1: 1500 accessi in scrittura e 500 accessi in lettura al giorno Operazione 2: trascurabile. Contiamo doppi gli accessi in scrittura Totale di 3500 accessi al giorno Progettazione Logica

Assenza di ridondanza Costi: Contiamo doppi gli accessi in scrittura Operazione 1: 1000 accessi in scrittura Operazione 2: 10000 accessi in lettura al giorno Contiamo doppi gli accessi in scrittura Totale di 12000 accessi al giorno Conviene dunque mantenere il dato ridondante Progettazione Logica

Ristrutturazione dello schema E-R Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari Progettazione Logica

2. Eliminazione delle gerarchie il modello relazionale non può rappresentare direttamente le generalizzazioni entità e relazioni sono invece direttamente rappresentabili si eliminano perciò le gerarchie, sostituendole con entità e relazioni Progettazione Logica

Tre possibilità accorpamento delle figlie della generalizzazione nel genitore accorpamento del genitore della generalizzazione nelle figlie sostituzione della generalizzazione con relazioni Progettazione Logica

E0 R1 A01 A02 E3 R2 E4 E2 E1 A11 A21 Schema generale

Accorpamento delle figlie della generalizzazione nel genitore E1 e E2 sono eliminate e le loro proprietà vengono aggiunte al padre E0 A E0 viene aggiunto anche un nuovo attributo, TIPO, che serve a distinguere le occorrenze di E1 da quelle di E2 Gli attributi A11 e A21 possono assumere anche valori nulli su E0 Progettazione Logica

Collasso verso l’alto A01 A02 A11 E0 E3 A21 TIPO E4 (0,1) R1 (0,1) (0,..)

Esempio Dom(Tipo)= {L,D,N} Denom. Studente Matr. Nome Tit.Stage (0,1) Tit.Tesi (0,1) Matr Relatore Azienda (0,1) Tipo (1,n) Studente Laureando Diplomando Matr. Nome Tit.Stage Tit.Tesi Matr Relatore Denom. Azienda (1,1) (p,e) (1,n)

Osservazioni Conveniente quando le operazioni sulla base di dati non fanno molta distinzione tra le occorrenze e tra gli attributi di E0, E1, E2 Vantaggi: numero minore di accessi Svantaggi: spreco di memoria per la presenza di valori nulli Progettazione Logica

E0 R1 A01 A02 E3 R2 E4 E2 E1 A11 A21 totale

Accorpamento del genitore della generalizzazione nelle figlie E0 viene eliminato, i suoi attributi e identificatore vengono assegnati alle figlie R11 e R12 sono le restrizioni di R1 alle occorrenze di E1 e E2 Nota Bene tale trasformazione è possibile solo se la generalizzazione è totale, altrimenti le occorrenze di E0 - (E1 U E2) non sarebbero rappresentate Conviene quando ci sono operazioni che si riferiscono solo a occorrenze di E1, o di E2 e fanno distinzioni tra tali entità

Collasso verso il basso

Esempio Dipendente Impiegato Operaio CF Nome macchine capacità Dirigente n_sottoposti Sindacato Contribuisce 0,1 1,n Dirige Impiegato Operaio macchine capacità Dirigente n_sottoposti Sindacato Contr_I 0,1 0,n 1,n CF Nome Contr_D Contr_O Dir_D Dir_O Dir_I

Quando conviene utilizzare questa alternativa? Quando ci sono operazioni che si riferiscono solo a occorrenze di E1 oppure di E2, e fanno distinzioni tra le 2 entità Gli attributi non assumono mai valori nulli Progettazione Logica

Sostituzione della generalizzazione con relationship La generalizzazione si trasforma in due associazioni uno a uno che legano l’entità padre E0 con E1 e E2 Si pongono dei vincoli per impedire che una occorrenza di E0 partecipi sia a E1 che a E2 Nota bene -conviene se gli accessi alle entità figlie sono separati dagli accessi al padre -è sempre possibile indipendentemente dalla copertura e conserva tutte le entità -le entità vengono mantenute e sono identificate esternamente Progettazione Logica

E0 A01 A02 E2 E1 R2 E4 A11 A21 R1 E3 (0,1) (0,1) RG1 RG2 (1,1) (1,1)

Esempio Progetto Prog_sw Prog_hw Cod Desc N_schede Mesi uomo Comp_hw usa 1,n 0,n Progetto Prog_sw Prog_hw Cod Desc N_schede Mesi uomo Comp_hw usa 1,n 0,n 0,1 1,1

Quando conviene usare questa alternativa? quando la generalizzazione non è totale, quando ci sono operazioni che si riferiscono solo a occorrenze di E1, E2 oppure E0, Risparmio di memoria rispetto alla scelta (1): non si introducono valori nulli Aumento degli accessi per mantenere la consistenza delle occorrenze Progettazione Logica

Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari Progettazione Logica

gli accessi si riducono: entità e associazioni in uno schema E-R possono essere partizionati o accorpati per rendere più efficienti le operazioni, in base a un semplice principio: gli accessi si riducono: separando attributi di un concetto che vengono acceduti separatamente; raggruppando attributi di concetti diversi acceduti insieme; Progettazione Logica

Ristrutturazioni, casi principali partizionamento orizzontale/verticale di entità eliminazione di attributi multivalore accorpamento di entità/ relationship Progettazione Logica

Partizionamento verticale di entità Impiegato Livello Stipendio Ritenute Cognome Indirizzo Data nascita Codice Progettazione Logica

Data nascita Dati anagrafici lavorativi (1,1) Si separano gli attributi in gruppi omogenei Livello Stipendio Ritenute Cognome Indirizzo Data nascita Codice Dati Impiegato Dati anagrafici lavorativi (1,1) Progettazione Logica

Eliminazione di attributi multivalore Agenzia Indirizzo Città Telefono Nome (1,N) Progettazione Logica

Utenza Agenzia Telefono (1,N) (1,1) Si introduce una entità le cui istanze sono identificate dai valori dell’attributo L’associazione può essere uno a molti o molti a molti Numero Indirizzo Nome Utenza Agenzia Telefono (1,N) (1,1) Città Progettazione Logica

Eliminazione di attributi multivalore Agenzia Indirizzo Città Telefono Nome (1,3) Se la cardinalità massima K è nota: è possibile prevedere K repliche degli attributi Tel2 Tel1 Tel3 Nome Agenzia Indirizzo Città Progettazione Logica

Accorpamento di Entità Codice fiscale Cognome Interno Indirizzo (0,1) (1,1) Intestazione Persona Appartamento Data nascita Indirizzo Progettazione Logica

Persona Data nascita Codice fiscale (0,1) Interno Indirizzo Cognome Data nascita Codice fiscale (0,1) Progettazione Logica

Partizionamento orizzontale di associazioni (0,1) Cognome Composizione Giocatore Squadra (1,N) Ruolo Nome Città Data acquisto Data cessione Cognome Comp. passata Giocatore Squadra (0,N) (1,N) Ruolo Nome Città Data acquisto Data cessione attuale (1,1)

Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari Progettazione Logica

Scelta degli identificatori principali operazione indispensabile per la traduzione nel modello relazionale perché nel modello relazionale le chiavi vengono usate per stabilire legami tra dati in relazioni diverse; i DBMS richiedono di specificare una chiave primaria; si deve decidere quale degli identificatori utilizzare come chiave principale Progettazione Logica

Criteri Gli attributi con valori nulli non possono essere identificatori principali Gli identificatori con uno o pochi attributi sono preferibili vantaggio in termini di risparmio di memoria nella realizzazione dei legami logici tra le varie relazioni facilita le operazioni di join Un identificatore interno è preferibile Un identificatore utilizzato nelle operazioni più frequenti o importanti è preferibile Progettazione Logica

Se nessuno degli identificatori soddisfa i requisiti visti? Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per questo scopo ES. Contatori, Sigle Progettazione Logica

L’identificatore {Interno, Indirizzo} è opzionale, quindi non può essere scelto Tra Codice fiscale e Codice SSN la scelta dipende da quale è più frequentemente usato per accedere a una persona Interno Indirizzo Cognome Data nascita Codice fiscale (0,1) Codice SSN Persona

Fase 2: Traduzione verso il modello relazionale Input: schema concettuale modello logico Output: schema logico Sono possibili altre fasi: Verifiche sulla qualità dello schema Normalizzazione dello schema prodotto Progettazione Logica

Traduzione verso il relazionale idea di base: le entità diventano relazioni sugli stessi attributi e la chiave è l’identificatore principale le relationship (o associazioni) diventano relazioni i cui attributi sono gli identificatori delle entità coinvolte e gli attributi propri dell’associazione Progettazione Logica

Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP) Ogni entità è tradotta con una relazione con gli stessi attributi La chiave primaria coincide con l’identificatore principale dell’entità Gli attributi composti vengono ricorsivamente suddivisi nelle loro componenti, oppure si mappano in un singolo attributo della relazione, il cui dominio va opportunamente definito Per brevità, usiamo l’asterisco (*) per indicare la possibilità di valori nulli Persona indirizzo via città n.civico (0,1) CAP nome cognome cod_fiscale Persona(CF, Cognome, Nome, Via, NCivico*,Città,CAP)

Entità e relationship molti a molti Partecipazione (0,N) (1,N) Cognome Stipendio Matricola Impiegato Nome Codice Budget Progetto Data inizio Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Progettazione Logica

Impiegato(Matricola, Cognome, Stipendio) Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Progettazione Logica

Impiegato(Matricola, Cognome, Stipendio) Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Impiegato, Progetto, DataInizio) Progettazione Logica

Relationship ricorsive Quantità (0,N) Composizione (0,N) Composto Componente Prodotto Costo Nome Codice Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) Progettazione Logica

Relationship n-arie Fornitore(PartitaIVA, Nome) Prodotto Dipartimento Fornitura Partita IVA Genere Codice Quantità Telefono (0,N) (1,N) Fornitore(PartitaIVA, Nome) Prodotto(Codice, Genere) Dipartimento(Nome, Telefono) Fornitura(Fornitore, Prodotto, Dipartimento, Quantità)

Relationship uno a molti Cognome Giocatore Squadra Contratto Data nascita Città Nome Ingaggio (1,1) (0,N) Ruolo Colori sociali Giocatore(Cognome, DataNascita, Ruolo) Squadra(Nome, Città, ColoriSociali) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) Progettazione Logica

Soluzione più compatta Giocatore(Cognome, DataNascita, Ruolo) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) Giocatore e Contratto hanno la stessa chiave: possiamo fonderle in un’unica relazione Giocatore(Cognome, DataNasc, Ruolo, Squadra, Ingaggio) con vincolo di integrità referenziale fra Squadra in Giocatore e la chiave di Squadra Progettazione Logica

Osservazione Cognome Giocatore Squadra Contratto Data nascita Città Nome Ingaggio (0,1) (0,N) Ruolo Colori sociali se la cardinalità minima della relationship è 0, allora Squadra e Ingaggio in Giocatore devono ammettere valore nullo Giocatore(Cognome, DataNasc, Ruolo, Squadra*, Ingaggio*) Squadra(Nome, Città, ColoriSociali) Progettazione Logica

Associazioni ricorsive uno a molti Responsabile Dipendente Qualifica Nome Codice (0,N) (0,1) Dipendenza Impiegato In questo caso è possibile operare una traduzione con 1 o 2 relazioni 1 relazione: Impiegato(Codice, Nome, Qualifica, Responsabile*) FK: Responsabile REFERENCES Impiegato 2 relazioni: Impiegato(Codice, Nome, Qualifica) Dipendenza(Dipendente, Responsabile) FK: Dipendente REFERENCES Impiegato FK: Responsabile REFERENCES Impiegato

Entità con identificazione esterna Nel caso di entità identificata esternamente, si “importa” l’identificatore della/e entità identificante/i. L’associazione relativa risulta automaticamente tradotta Iscrizione Studente Università Cognome Matricola AnnoDiCorso Nome Indirizzo (1,1) (1,N) Città Studente(Matricola, Università, Cognome, AnnoDiCorso) Università(Nome, Città, Indirizzo)

Relationship uno a uno (1,1) – (1,1) Direttore Dipartimento Direzione Cognome Codice Sede Nome Data inizio (1,1) Stipendio Telefono Direttore (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) Direttore (Codice, Cognome, Stipendio, InizioD, Dipartimento) Dipartimento (Nome, Sede, Telefono)

Relationship uno a uno (0,1) – (1,1) Impiegato Dipartimento Direzione Cognome Codice Sede Nome Data inizio (0,1) (1,1) Stipendio Telefono tradurre l’associazione Direzione inglobandola in Impiegato non è in generale una buona scelta (dipende dai volumi dei dati in gioco): troppi valori nulli! Progettazione Logica

Relationship uno a uno (0,1) – (1,1) Impiegato Dipartimento Direzione Cognome Codice Sede Nome Data inizio (0,1) (1,1) Stipendio Telefono Impiegato(Codice, Cognome, Stipendio, Dipartimento*, DataInizio*) Dipartimento(Nome, Sede, Telefono) Progettazione Logica

Impiegato (Codice, Cognome, Stipendio) Soluzione: Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) con vincolo di integrità referenziale, senza valori nulli Progettazione Logica

Relationship uno a uno (0,1) – (0,1) Data inizio Cognome Sede Nome Codice (0,1) (0,1) Direzione Impiegato Dipartimento Stipendio Telefono Per evitare la presenza di valori nulli nelle chiavi esterne: Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore) Direzione (Direttore, Dipartimento, DataInizio)

Un esempio particolare Marito Moglie Nome CF (0,1) Matrimonio Persona 2 relazioni: Persona(CF, Nome) Matrimonio(Marito, Moglie) Progettazione Logica

Indirizzo Dipartimento Sede Impiegato Progetto (1,1) (0,1) (1,N) (0,N) Città Indirizzo Telefono Dipartimento Composizione Sede Direzione Afferenza Impiegato Progetto Partecipazione Nome Cognome Budget Data Via CAP Codice

Progetto(Nome, Budget) Per le entità E che partecipano ad associazioni sempre con max-card(E,R) = n la traduzione è immediata: Sede(Città, Via, CAP) Progetto(Nome, Budget) Anche l’associazione Partecipazione si traduce immediatamente: Partecipazione(Impiegato, Progetto) L’entità Dipartimento si traduce importando l’identificatore di Sede e inglobando l’associazione Direzione Dipartimento(Nome, Città, Telefono, Direttore) Per tradurre l’associazione Afferenza, assumendo che siano pochi gli impiegati che non afferiscono a nessun dipartimento, si opta per una rappresentazione compatta Impiegato(Codice, Cognome, Dipart*,CittàDip* Data*)

Esercizio 1 AA ciclo nome (1,1) (0,n) responsabilità cognome Corso_AA Docente data_nascita cod_doc (1,1) attivato nome (0,n) data FA_VISITA (1, 1) (0, N) IN_VISITA MEDICO VISITA PAZIENTE esito cognome cod_corso telefono cod_med nome Corso nome cognome data_nascita cod_paziente Progettazione Logica

Esercizio 2 Trovare lo schema ER che dà luogo al seguente schema relazionale:   GIOCATORI(n_giocatore, cognome, iniziali, data_nascita, sesso, iscritto_dal, indirizzo, numero, cap, citta, telefono, n_socio) SQUADRE(n_squadra, n_giocatore, categoria) PARTITE(n_partita, n_squadra, n_giocatore, vittorie, sconfitte) PENALITA(n_pagamento, n_giocatore, data_pagamento, importo) MEMBRI_COMMISSIONE(n_giocatore, data_inizio, data_fine, carica) Progettazione Logica