Gestione database e diagrammi e/r

di il
7 risposte

Gestione database e diagrammi e/r

Salve. Dovrei fare un progetto per un esame di basi di dati in università solo che ho qualche dubbio sul da farsi.
1) In pratica devo realizzare un database di una biblioteca che contiene 10000 pubblicazioni(che possono essere libri o riviste) e inizialmente 4000 utenti di cui bisogna registrare i prestiti e le restituzioni(vi sono 2000 prestiti registrati inizialmente). Ogni giorno si registrano in media 100 prestiti e 80 restituzioni. Sulla base di questi dati come posso fare l'analisi di ridondanza?

2) Inoltre accorpo le entità figlie(libri e riviste) nell'entità padre(pubblicazioni) per la normalizzazione. Però le riviste avranno più attributi dei libri come il N°_volume + Anno_pubblicazione che insieme formano la chiave primaria per la loro identificazione. La mia domanda qui è: meglio creare un'entità a parte per memorizzare i dati aggiuntivi delle riviste o meglio tenere tutto nell'entità pubblicazione(anche se con questa soluzione avrò molti campi settati a NULL per i libri)?

3) Ultima domanda: le entità deboli sono assolutamente da evitare?
Il nostro professore ci ha fatto usare Database Designe Studio per realizzare un modello e/r che il programma stesso utilizza per creare gli script di creazione delle tabelle. Ora il DDS con una relazione del tipo:
entità relazione entità
utente(cardinalità N)------prestito--------(cardinalità M)pubblicazione
a causa delle cardinalità mi crea una entità debole su prestito. La cosa è ragionevole? O c'è un modo più intelligente di agire?

7 Risposte

  • Re: Gestione database e diagrammi e/r

    Io so usare soltanto Access per gestire un database. Nel tuo linguaggio, usi termini che io non conosco:
    - analisi di ridondanza
    - le entità deboli

    Se mi permetto di risponderti è perchè ho un database, per certi versi, simile, se non altro proprio per la problematica di capire come Libri e Riviste possono diventare omogenei. Tieni presente che io ho un database che accorpa Libri, Giornali, Supporti musicali (CD, LP, MC...), Supporti video (DVD, VHS)...ma anche oltre dato che oggi giorno tutti questi supporti tendono a scomparire e tutto sta diventando digitalizzato (ma questo è un altro problema).
    Io ho risolto in questa maniera: ho creato una tabella Supporti. Un Supporto è ovviamento un Libro, CD, DVD, Scatola, Raccoglitore, Hard-disk, Pen-drive...insomma un contenitore di quello che ti pare. Dentro questo Supporto puoi mettere molti Titoli di qualsiasi natura. Io ho infatti una tabella Titoli. Anche qui i Titoli possono essere Titoli di Libri, Titoli di Canzoni, Titoli di Riviste, Titoli di Articoli di Riviste...per differenziarli gli uni dagli altri uso un campo apposito che discrimina ciò.
    Strutturalmente parlando sembrerebbe che Supporti è in relazione uno-a-molti con Titoli. Però occorre non sottovalutare che uno stesso Titolo può comparire su più Supporti. L'esempio delle Canzoni sarebbe più facile, ma ti faccio un esempio proprio sui Libri. Un titolo come "I promessi sposi" può avere più edizioni con diversi curatori, quindi tu avrai più Libri (Supporti) con lo stesso titolo "I promessi sposi". Io ho preferito considerare Supporti e Titoli in relazione molti-a-molti. Mi fermo qui, sperando di aver toccato corde giuste fra i tuoi ragionamenti. Altrimenti scusa, faccio dietro-front.
  • Re: Gestione database e diagrammi e/r

    Si più o meno si.. Però voglio farti ancora una domanda. Qual è l attributo che nel tuo caso mette in relazione supporti e titoli? O hai una terza tabella senza chiave propria per collegarli?
  • Re: Gestione database e diagrammi e/r

    Volevo anche specificare il significato di:
    -analisi di ridondanza sarebbe una parte della normalizzazione in cui in base al carico di lavoro stimato(n° di tuple e n° di specifiche operazioni sulle entità) posso calcolare i costi giornalieri di tutte le operzazioni;
    -un'entità debole è un entità senza chiave primaria propria. Ho letto che è sconsigliabile creare tabelle di questo tipo, ma credo che per la relazione che ho postato nel primo commento sia l'unia via di gestione.
  • Re: Gestione database e diagrammi e/r

    Io ho una tabella di congiunzione che si chiama DettagliSupporti che ha i seguenti campi:
    IDDS (significa IDDettaglioSupporto)(contatore, chiave primaria)
    IDSupporto (numerico)
    IDTitolo (numerico)
    Indirizzo (testo)(sta a indicare dove si trova il Titolo nel Supporto. Può essere un semplice numero, nei casi delle tracklist dei CD, ma può esserci dentro anche un path intero...ecco perchè è testo)
    ...poi ho altri campi meno importanti che non so se siano pertinenti al nostro discorso.

    Questo discorso di una eventuale tabelle di congiunzione, devi essere tu a valutarlo con attenzione. Non è detto che sia una scelta obbligata. Io l'ho creata perchè avevo le idee chiare sullo scenario che mi sarei trovato davanti in futuro. Voglio dire che, se l'esempio di "I promessi sposi" accade in meno del 5% dei casi, si può tranquillamente pensare a un campo memo dove descrivi a parole eventuali differenze (so che era una prassi consolidata nelle biblioteche e archivi di tanti anni fa quando si lavorava con le schede a mano) e lasciare una relazione Supporti uno-a-molti con Titoli...bla bla bla...
    ...ripensandoci bene Un Libro è un Supporto sempre. Un Giornale è un Supporto sempre. Le scelte vanno fatto in base a come si presentano i dati ai tuoi occhi e cosa vuoi ottenere/chiedere dal database.
    Devi dirci tu se ti interessa archiviare i DettagliSupporti.
    Una decina di esempi tipo renderebbero meglio l'idea generale.
    -analisi di ridondanza sarebbe una parte della normalizzazione in cui in base al carico di lavoro stimato(n° di tuple e n° di specifiche operazioni sulle entità) posso calcolare i costi giornalieri di tutte le operzazioni;
    Per me è arabo quando questo linguaggio è puramente teorico. Io non saprei descrivere tutte le regole di normalizzazione, ma so normalizzare i database semplicemente sbattendo la testa sui dati guardandoli direttamente sul computer.
    -un'entità debole è un entità senza chiave primaria propria. Ho letto che è sconsigliabile creare tabelle di questo tipo, ma credo che per la relazione che ho postato nel primo commento sia l'unia via di gestione.
    Non so se ho compreso davvero questo concetto. In alcuni casi si può non mettere una chiave primaria su un solo campo. Io ce la metto SEMPRE come mia formamentis mentale e mi aiuta a non trovarmi mai nei guai.
  • Re: Gestione database e diagrammi e/r

    Se il precedente messaggio non ti è piaciuto, proverei a partire da questo schema

    è un database da Biblioteca costruito insieme a un altro utente che, partendo da zero conoscenze di Access, ha trovato funzionale quello schema.
    Trattandosi di Biblioteca si parla solo di Libri. La tabella Libri la si può rendere più generalizzata giocando con i campi appropriati.
    Nel tuo caso le Donazioni non interessano, quindi puoi togliere i campi e la relazione che li coinvolge.
    Tutto il resto, secondo me, può essere un buon punto di partenza.
  • Re: Gestione database e diagrammi e/r

    Grazie mille sei stato molto chiaro. Purtroppo è da poco che ho a che fare con i database quindi sono ancora un po' lento. Più che altro mi deve entrare in testa che le soluzioni posso essere varie a seconda di quello che si vuole ottenere, e soprattutto, nel momento in cui devo fare un esercizio per un esame, mi viene da credere che la soluzione giusta sia una sola. Comunque questa discussione mi ha aperto abbastanza la mente e ora credo di essere giunto ad un risultato decente! Grazie ancora!
  • Re: Gestione database e diagrammi e/r

    Si potrebbe aggiungere anche la tabella Generi (IDGenere, Descrizione) ed una tabella LibriGeneri (ID, IDLibro, IDGenere) che relazioni molti-molti la tabella Generi con la tabella Libri, in quanto spesso capita che un libro possa appartenere a 2 o più generi contemporaneamente.
    In questo caso nella tabella Libri, il campo Genere andrebbe sostituito con IDGenere.
Devi accedere o registrarti per scrivere nel forum
7 risposte