Problemi con database: ereditarietà e generalizzazione

[Barbalbero]

Io non ho mai capito una cosa...
Ho l'entità PERSONA
le entità UOMO e DONNA sono generalizzazioni di persona.
Che differenza c'è con l'ereditarietà?

E soprattutto:
Una volta definito il modello concettuale entità-relazione, come si esprimono questo tipo di relazioni con il linguaggio SQL?
Mi potete fare un semplice esempio?

[yorkeiser]

Le entità uomo e donna dovrebbero essere specializzazioni della classe persona.
L'ereditarietà è una caratteristica che ti permette di implementare tale specializzazione: le classi ereditano dalla superclasse gli attributi ed i metodi. Sarebbe inutile ogni volta ridefinire anche nelle sottoclassi gli stessi attributi della superclasse.

[Barbalbero]

sì ok persona è una generalizzazione di uomo e donna, ho sbagliato a dire...
Quello che intendevo comunque era capire come realizzarlo in sql. Poi ho trovato da qualche parte che bisogna eliminare le generalizzazioni e trasformarle in relazioni 1 a 1, oppure utilizzare un flag uomo/donna nella tabella PERSONA, senza creare le tabelle UOMO e DONNA

[yorkeiser]

Le mie nozioni di E-R risalgono alla preistoria e sono per la maggior parte nel dimenticatoio, ma nella pratica la realizzazione del DB deve essere comunque funzionale ai tuoi scopi.
Ad occhio, potresti avere un'unica tabella (persona) e potresti realizzare la specializzazione con due viste (uomo e donna); mi sembra inutile replicare la stessa struttura su tre tabelle. Per differenziare tali viste, potresti effettivamente utilizzare un flag. Chiaramente, questo vale nel caso in cui nelle sottoclassi non definisci nuovi attributi rispetto alla superclasse, altrimenti dovresti
- aggiungere delle colonne nella tabella persona
oppure
- aggiungere una tabella con i nuovi attributi e metterla poi in join con la tabella persona

[Barbalbero]

PERSONA, UOMO e DONNA era un esempio per rendere l'idea...
Io in pratica dovrei avere UTENTE che è la generalizzazione di AMMINISTRATORE e CLIENTE.
Sia AMMINISTRATORE che CLIENTE avranno attributi comuni come nome, cognome, username, password, email ecc.... Ma le mansioni dei due sono totalmente disaccoppiate. Utente avrà una serie di relazioni con varie altre entità del database, ad esempio CARRELLO, SALDO e altre cose, mentre l'AMMINISTRATORE avrà totalmente altre relazioni con altre classi.

Quindi credo di dover fare la tabella UTENTE e relazionarla con le tabelle AMMINISTRATORE e CLIENTE. Creando un amministratore quindi creerò una riga nella tabella UTENTE e nella tabella AMMINISTRATORE. Quando creerò un CLIENTE invece creerò una riga nella tabella UTENTE e nella tabella CLIENTE.

Cosa ne pensi, ti sembra ragionevole? E' così che si agisce di solito?
(riguardo alle viste boh...non le ho mai concepite, ma se sono effettivamente utili, me le riguarderò)

[yorkeiser]

Secondo me, in questo caso la discriminante per il tipo di soluzione da adottare è data da quante operazioni coinvolgono una sola sottoclasse e quante invece possono coinvolgere entrambe.
E' chiaro che se su 100 possibili operazioni, 99 coinvolgono solo una, ha poco senso fare un'unica tabella ed ogni volta sobbarcarsi l'overhead della creazione della vista: in questo caso, tenere separate le tabelle potrebbe essere una buona soluzione. A quel punto, però, eviterei di implementare la tabella della superclasse (utente) dal momento che dovresti duplicare eventuali operazioni di inserimento, update e cancellazione (o quantomeno prevedere dei cascade).

P.S. A mio giudizio le viste sono molto utili, se venissero utilizzate più spesso non mi troverei a dover replicare la stessa query su 20 tabelle differenti, come purtroppo spesso mi succede. Senza contare che garantiscono l'integrità dei dati, che spesso viene meno quando si progettano database con trilioni di tabelle e senza i dovuti vincoli di integrità referenziale.

[Barbalbero]

Non ho mai avuto a che fare con database seri... sempre e solo cose didattiche. Quindi non so bene quali siano le reali necessità di un database di certe dimensioni.
Ti ringrazio per i consigli, credo che per semplificare, distinguerò le due tabelle CLIENTE e AMMINISTRATORE, senza relazionarle, in quanto non vedo nessun beneficio dato dalla generalizzazione UTENTE. L'avevo introdotta solo perchè i docenti hanno sempre insistito su queste cose e ci hanno sempre costretto a ereditare e generalizzare ogni volta possibile!

Originariamente inviato da Barbalbero

Non ho mai avuto a che fare con database seri... sempre e solo cose didattiche. Quindi non so bene quali siano le reali necessità di un database di certe dimensioni.
Ti ringrazio per i consigli, credo che per semplificare, distinguerò le due tabelle CLIENTE e AMMINISTRATORE, senza relazionarle, in quanto non vedo nessun beneficio dato dalla generalizzazione UTENTE. L'avevo introdotta solo perchè i docenti hanno sempre insistito su queste cose e ci hanno sempre costretto a ereditare e generalizzare ogni volta possibile!

Vedi infine come ti è più congeniale, rispettare la normalizzazione non deve essere una regola ma solo una buona strada da seguire.

L'importante è avere chiaro in mente cosa si vuole ottenere e quali regole seguire per la normalizzazione, nulla vieta però di piegare o spezzare tali regole ove più comodo e produttivo.

[zulutown]

Originariamente inviato da Barbalbero

PERSONA, UOMO e DONNA era un esempio per rendere l'idea...
Io in pratica dovrei avere UTENTE che è la generalizzazione di AMMINISTRATORE e CLIENTE.
Sia AMMINISTRATORE che CLIENTE avranno attributi comuni come nome, cognome, username, password, email ecc.... Ma le mansioni dei due sono totalmente disaccoppiate. Utente avrà una serie di relazioni con varie altre entità del database, ad esempio CARRELLO, SALDO e altre cose, mentre l'AMMINISTRATORE avrà totalmente altre relazioni con altre classi.

Quindi credo di dover fare la tabella UTENTE e relazionarla con le tabelle AMMINISTRATORE e CLIENTE. Creando un amministratore quindi creerò una riga nella tabella UTENTE e nella tabella AMMINISTRATORE. Quando creerò un CLIENTE invece creerò una riga nella tabella UTENTE e nella tabella CLIENTE.

Cosa ne pensi, ti sembra ragionevole? E' così che si agisce di solito?
(riguardo alle viste boh...non le ho mai concepite, ma se sono effettivamente utili, me le riguarderò)

Se usi Java esiste JPA (una delle sue implementazioni è Hibernate) che consente rapidamente di mappare classi java su tabelle relazionali di DB.

e supporta anche i concetti di ereditarietà.

Nel tuo caso comunque non so se sia giusto usare l'ereditarietà.. o metti un ENUM sulla tabella persona che dice (utente/admin/moderatore) oppure fai una many to many tra persona e gruppo e poi verifichi l'appartenenza a un gruppo

ciao