Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

esempio modello concettuale

7,770 views

Published on

Esempio di una progettazione di un database per gestire di dati delle partite di calcio

  • Be the first to comment

  • Be the first to like this

esempio modello concettuale

  1. 1. Modello concettuale della progettazione del database Esempio di progettazione
  2. 2. L’entità dominante <ul><li>Il campionato di calcio </li></ul><ul><li>Quali sono gli attributi che permettono di definire la chiave primaria ? </li></ul><ul><li>L’anno ? </li></ul><ul><li>La serie ? (A, B, C….) </li></ul><ul><li>Anno+serie ? </li></ul><ul><li>L’anno è un dato ambiguo perché un campionato è come l’anno scolastico, parte a settembre e finisce a maggio dell’anno successivo! </li></ul><ul><li>Non sarebbe un problema perché convenzionalmente intenderemo sempre l’anno di inizio </li></ul><ul><li>Tuttavia questo dato posso trovarlo come chiave straniera in altre tabelle. </li></ul><ul><li>Conviene creare una chiave numerica surrogata </li></ul><ul><li>Per lasciare aperta la porta dell’inserimento anche dei dati storici dei campionati del passato posso gestire il valore di questa chiave numerica, magari prevedendo di usare dei numero non progressivi. </li></ul><ul><li>Ad esempio uso per il campionato in corso il codice 1000. </li></ul>
  3. 3. L’entità dominante campionato
  4. 4. L’attributo multivalued squadre <ul><li>Espandiamo l’attributo multivalued in entità </li></ul><ul><li>Per questa nuova entità devono essere scoperti ed indicati gli attributi </li></ul><ul><li>Tra questi attributi occorre comprendere quali sono candidati per fare da chiave primaria </li></ul><ul><li>Contemporanemente a questa espansione-trasformazione dobbiamo creare la relazione binaria tra l’entità di partenza “campionato” e la nuova entità “squadre”. </li></ul><ul><li>Occorre indicare il nome della nuova relazione, la sua cardinalità e partecipazione. </li></ul><ul><li>Vanno individuato eventuali attributi di tale relazione </li></ul>
  5. 5. Espansione squadra
  6. 6. La chiave primaria di partita <ul><li>Quale è la chiave primaria ? </li></ul><ul><li>I codici delle due squadre che s’incontrano ? </li></ul><ul><li>Il codice del campionato ? </li></ul><ul><li>La data di svolgimento della partita ? </li></ul><ul><li>Conviene creare un numero partita come chiave surrogata ? </li></ul><ul><li>Una partita è un’entità debole! </li></ul><ul><li>Potrebbe esistere senza il campionato ? Senza le squadre ? Senza i giocatori ? </li></ul>
  7. 7. Espansione giocatori <ul><li>Per ogni squadra devi memorizzare i nomi ed il ruolo dei giocatori che partecipano ad ogni partita di ogni campionato sportivo. </li></ul><ul><li>Per la nuova entità “giocatori” scopro tutti gli attributi richiesti e quali tra questi possono fungere da chiave primaria </li></ul><ul><li>Conviene anche in questo caso creare una chiave surrogata numerica da usare come chiave primaria </li></ul><ul><li>Occorre creare la relazione tra l’entità “squadra” e la nuova entità “giocatore” </li></ul><ul><li>Occorre stabilire tutte le proprietà di questa nuova relazione </li></ul>
  8. 8. Espansione attributo multivalued giocatori
  9. 9. Mapping dell’entità “giocatore” <ul><li>Tabella GIOCATORE </li></ul><ul><li>GIOCATORE( codiceG, nomeG,ruoloG ) </li></ul>
  10. 10. L’attributo multivalued partita <ul><li>Partita è un attributo multivalued di molte entità: campionato, squadra, giocatore. </li></ul><ul><li>Infatti una partita è giocata in un campionato da due squadre e dai giocatori (non tutti) di queste due squadre ! </li></ul><ul><li>Sembra opportuno vedere questo attributo non come attributo, ma addirittura come relazione quaternaria: riflessiva tra l’entità “squadre”, e in associazione con “campionato” e con “giocatori” </li></ul>
  11. 11. La relazione partita
  12. 12. Il giocatore segna gol
  13. 13. Il gol è un’entità
  14. 14. Attributi partita
  15. 15. L’entità partita
  16. 16. Proprietà delle relazioni con partita
  17. 17. Mapping dell’entità partita <ul><li>Proviamo a sistemare questa entità difficile da progettare </li></ul><ul><li>Tabella Partita: </li></ul><ul><li>PARTITA( numeroPartita , codiceSq1 , codiceSq2,codiceCa ,dataP, oraInizioP, oraFineP, stadio, città, arbitro) </li></ul>
  18. 18. Mapping della relazione “gioca” <ul><li>Tabella “gioca” </li></ul><ul><li>GIOCA( codiceG , numeroPartita ,numCartelliniGialli,Espulso,minutoIngresso,minutoUscita) </li></ul>
  19. 19. Mapping dell’entità debole “gol” <ul><li>Tabella GOL </li></ul><ul><li>GOL( numeroPartita , codiceG , minutoRealizzazione ,azione) </li></ul>
  20. 20. Per concludere <ul><li>Bisogna sistemare la “classifica” </li></ul><ul><li>Inoltre si debbono espandere gli attributi multivalued “allenatori”, “presidenti”, “scudetti” </li></ul><ul><li>È facile. </li></ul><ul><li>Invece occorre focalizzare la nostra attenzione sulla “classifica”. </li></ul>

×