Relazioni di generalizzazione

[simone.marchese]

Ciao Ragazzi,
Sono diversi anni che non creo diagrammi ER e ne ho appena ricostruito uno, avrei bisogno del vostro parere.
E' possibile realizzare una Gerarchie di generalizzazione di tre livelli? come potete vedere nella
foto

E un'ultima cosa questa gerarchia come si riproduce poi in mysql

Spero che qualcuno mi aiuti ...

Grazie a tutti

[michellemabelle]

Ciao, allora si può fare, ma in ogni caso prima di creare il database vero e proprio dovrai ristrutturare il tuo schema e togliere le gerarchie.
Puoi farlo in 2 modi essenzialmente:
1) se le entità figlie non hanno "vita propria", ossia vivono degli attributi ereditati dall'entità padre allora queste vanno incorporate nel genitore, avrai quindi un'unica entità
2) se le entità figlie sono collegate ad associazioni diverse tra loro e hanno diversi attributi allora è il padre che converge nelle figlie e avrai 2 o più entità a seconda del numero delle figlie.

Una volta ristrutturato il primo livello di generalizzazione passi al secondo.

Spero di esserti stata utile

[simone.marchese]

Ciao come prima cosa ti ringrazio della risposta.
E ti segnalo che l'entità hanno una loro vita propria in quanto oltre agli attributi del padre hanno dei loro attributi come hai potuto vedere nella foto.

A questo punto dovrei inserire gli attributi nell'entità persone e definire un campo che definisci da dove provengono i vari attributi aggiuntivi? o sbaglio?

Il secondo punto non l'ho capito benissimo

[michellemabelle]

Scusa, non mi so spiegare molto bene!

Mettiamo che le altre due entità figlie di Soggetto (a parte persone) siano A e B.
Se tu mi dici che Vip e Politici sono molto diverse tra loro in quanto hanno attributi diversi e all'interno del contesto svolgono "azioni" diverse, io fare così:

Toglierei Soggetto.

Quindi le entità rimanenti che metterei nel Database sono:

FOTO (campo1, campo2, campo3, ecc)
A (codsoggetto, campo1, campo2, ecc)
B (codsoggetto, campo1, campo2, ecc)
POLITICI (codsoggetto, nome, sesso, partito, caricagovernativa)
VIP (codsoggetto, nome, sesso, datadinascita)

Chiaramente devi vedere tu se i campi uguali sono ridondanti o sono necessari.

[deleted_29]

La risposta breve è "... non esiste una risposta breve ..."

Quella media è "quanti attributi hai da de-normalizzare? Son pochi? Collassa l'intera gerarchia in UNA singola tabella flat".

Guadagni in prestazioni enormemente, e pure in semplicità di gestione.
---
Son tanti? Ti tocca aggiungere relazioni (=> tabelle)

"pochi" potrebbero essere 10-20.
Questa è una possibilità

codsoggetto
persona_nome
persona_sesso
persona_datadinascita
persona_flagvip
persona_flagpolitico
persona_partito
persona_caricagovernativa

Questa un'altra

codsoggetto
persona_nome
persona_sesso
persona_datadinascita
persona_tipo_persona
persona_partito
persona_caricagovernativa

---
In generale ti suggerisco, finchè puoi, di adottare una strategia opposta a quella che normalmente viene insegnata, ossia de-normalizzare anzichè normalizzare.
Sono metodologie anni '60, vecchie quindi di una cinquantina d'anni, indispensabili quando i computer avevano memorie limitate a pochi KB.
Oggi avere un db grande non costa nulla, mentre i join costano, eccome.
Chiaramente bisogna decidere volta per volta: portarsi dietro un po' di "zavorra" (qualche campo varchar, qualche intero) va bene.

[michellemabelle]

@simone.marchese

Io ti ho scritto quello che mi è stato insegnato in Uni (ossia: "o fai così o non so se ti faccio arrivare al 18").

franzauker ne sa sicuramente più di me!

[simone.marchese]

Ok michelle ora vedo anche perchè la tua proposta non sò se posso crearla in base a tutto il progetto che devo creare...
Valuterò comunque la tua opzione, il problema che l'entità B sarà associata ad altre due entità e mi viene difficile eseguire delle interrogazioni con il metodo che hai proposto... o almeno credo

Per franzauker ho sicuramente pochi campi ma queste tabelle devono interagire con altre 10 tabelle e per le query che devo eseguire per esempio trovare le foto con i luoghi e i soggetti di un determinato politico (a e b) sono luoghi e oggetti in cui le foto sono state scattate...

Quindi secondo il mio giudizio e traduzione del progetto creavo un'entità soggetti in cui inserire tutti i campi comuni e le varie figlie in modo che in base all'id del soggetto posso recuperare la persona il soggetto e il luogo... o secondo te è una cavolata?

[deleted_29]

Originariamente inviato da michellemabelle
@simone.marchese

Io ti ho scritto quello che mi è stato insegnato in Uni (ossia: "o fai così o non so se ti faccio arrivare al 18").

franzauker ne sa sicuramente più di me!

adesso, non esagerare
quando insegnavo in uni dicevo "se non usi la testa non arriverai mai a 18", e la mia domanda-trabocchetto preferita era... modellare i dati anagrafici dei documenti fiscali... il 99% li normalizzava... e tornava successivamente (vabbuò è appurato che son bastard-inside)

Per franzauker ho sicuramente pochi campi ma queste tabelle devono interagire con altre 10 tabelle e per le query che devo eseguire per esempio trovare le foto con i luoghi e i soggetti di un determinato politico (a e b) sono luoghi e oggetti in cui le foto sono state scattate...

Quindi secondo il mio giudizio e traduzione del progetto creavo un'entità soggetti in cui inserire tutti i campi comuni e le varie figlie in modo che in base all'id del soggetto posso recuperare la persona il soggetto e il luogo... o secondo te è una cavolata?

Niente è mai una cavolata (tranne quello che scrivo io).

Non capisco cosa sono le "figlie", immagino intendi (forse) "tabelle" figlie ?
---
La versione medio-lunga è "puoi avere una chiave, e tante tabelle separate e collegate alla chiave medianti relazioni, ognuna delle quali contiene il relativo payload (oltre alla chiave esterna)"

Eliminate le dipendenze funzionali ottieni una (magnifica?) forma normale.

Bon, fin qui è l'approccio (supersintetico) per i corsi elementari di progettazione.
---
Nel "mondo reale" ti accorgi subito che ogni relazione diventa un join, il quale richiede un carico notevole all'RDBMS, enormemente più elevato rispetto ad una tabella flat (denormalizzata).

Paradossalmente per applicazioni ad alta concorrenza ed elevate prestazioni questa (flat) è di gran lunga preferibile a quella (normalizzata).

Ma, oltre agli aspetti diciamo così puramente di prestazioni, ci sono pure quelli di progettazione logica "vera", ove spesso si parte automaticamente a normalizzare, senza saper bene perchè si normalizza, e quando non lo si deve fare, neppure dal punto di vista accademico-teorico.
---
Vabbuò visto che si sta risvegliando il bastard-inside, maieuticamente ti faccio questo esempio-domanda.

Come modelleresti l'anagrafica di un documento fiscale (ditta, indirizzo, città, bastano questi)?

Così?
anagraficaCliente(codicecliente, ditta, indirizzo, citta, (...))

documento(numerodocumento, data, importo (...), codicecliente)?

---
Se la risposta è sì => niente 18

(vabbè dai spero si colga l'aspetto lieve, non voglio certo pontificare oltremisura)