[Forse OT] Traduzione Schema ER

[Nintendoz]

Salve a tutti,
mi scuso in anticipo per la discussione non propriamente in tema ma volevo chiedervi un consiglio vista la mia inesperienza con i database in generale: sto sviluppando un database in access per un progetto scolastico che prevede la realizzazione prima dello schema e-r e poi del progetto logico.
Vorrei chiedervi se il seguente schema, con la relativa ristrutturazzione, può considerarsi corretta o meno.

SCHEMA PRELIMARE



SCHEMA RISTRUTTURATO



Vi spiego: nel primo caso ho assunto che i clienti possono essere di due tipi (ditte o privati), ma la generalizzazione è parziale, ossia nel mio database voglio avere anche la possibilità di aggiungere a seconda delle mie esigenze nuove tipologie di clienti (Succursali, enti statali ecc). Così, nella ristrutturazione, invece che inserire direttamente un campo "Tipo" all'interno di "Clienti", ho creato una nuova entità che ha il compito di catalogare e associare tutte le tipologie di clienti creati.

Alla fine ho il seguente modello logico tradotto:

CLIENTI(ID, Nome, Cognome*, Partita IVA*, CF*, Indirizzo, Tipo:PROFILO)
PROFILO (CODICE, Descrizione)

con ID e CODICE come chiavi primarie, quelli senati con l'* come opzionali a seconda della tipologia del Cliente

Credete che sia corretto questo passaggio?

Grazie in anticipo per la collaborazione!

Un neofita alle prime armi

[rdefalco]

Mi sembra corretto, anche se magari l'entità PROFILO dovrebbe poter esistere anche se non c'è nessun cliente collegato (ad esempio se creo il profilo ENTI non deve necessariamente esserci un ente da creare contestualmente) quindi la cardinalità da profilo verso cliente potrebbe (ma non per forza) essere (0,n).

E comunque se procedi per teoria (almeno all'Università di Salerno, corso di Basi di Dati) non è mai stata contemplata la creazione di una nuova entità per definire il tipo, semplicemente si mette un attributo TIPO nell'entità CLIENTI.

Il metodo che hai scelto tu è però più corretto se applicato ad ambiti pratici (puoi definire una tabella PROFILO prima ancora di creare i clienti, però poi hai bisogno di (0,n) sulla cardinalità).

Spero di aver capito il problema e di essere stato chiaro

[Nintendoz]

Originariamente inviato da rdefalco

Mi sembra corretto, anche se magari l'entità PROFILO dovrebbe poter esistere anche se non c'è nessun cliente collegato (ad esempio se creo il profilo ENTI non deve necessariamente esserci un ente da creare contestualmente) quindi la cardinalità da profilo verso cliente potrebbe (ma non per forza) essere (0,n).

E comunque se procedi per teoria (almeno all'Università di Salerno, corso di Basi di Dati) non è mai stata contemplata la creazione di una nuova entità per definire il tipo, semplicemente si mette un attributo TIPO nell'entità CLIENTI.

Il metodo che hai scelto tu è però più corretto se applicato ad ambiti pratici (puoi definire una tabella PROFILO prima ancora di creare i clienti, però poi hai bisogno di (0,n) sulla cardinalità).

Spero di aver capito il problema e di essere stato chiaro

Sei stato chiarissimo!
In effetti anche a noi ci hanno spiegato che basta mettere l'attributo "Tipo" in Clienti, però in Access è molto più comodo crearsi una tabella con tutte le tipologie di clienti, richiamabili poi con un vincolo che permette di segliere il tipo di cliente con un comodo menu a tendina.
Hai pure ragione per la cardinalità, in effetti da Tipologia a Cliente è (0,n), perchè non è necessario che una certa tipologia sia associata ad un cliente (mentre è vero il contrario).
Correggimi se sbaglio, intanto grazie mille per l'aiuto!

[*zodiacus*]

Originariamente inviato da rdefalco

E comunque se procedi per teoria (almeno all'Università di Salerno, corso di Basi di Dati) non è mai stata contemplata la creazione di una nuova entità per definire il tipo, semplicemente si mette un attributo TIPO nell'entità CLIENTI.

Idem, io avrei agito così.
Tra l'altro non ho capito a cosa si riferisce "codice" per quanto riguarda profilo. Io avrei messo chiave primaria a Codice/PartitaIVA a cliente e aggiunto l'attributo Tipo.

Che comunque su Access puoi impostare facilmente con il menù a tendina.
Basta che apri la tabella in questione, vai in visualizza struttura, clicchi sul campo in questione e vai su ricerca. Imposti casella combinata (invece che di testo), vai su origine riga e scrivi "Ente statale";"Privato";"Azienda";"Quellochevuoi"

^__^

[rdefalco]

Originariamente inviato da *zodiacus*

Idem, io avrei agito così.
Tra l'altro non ho capito a cosa si riferisce "codice" per quanto riguarda profilo. Io avrei messo chiave primaria a Codice/PartitaIVA a cliente e aggiunto l'attributo Tipo.

Che comunque su Access puoi impostare facilmente con il menù a tendina.
Basta che apri la tabella in questione, vai in visualizza struttura, clicchi sul campo in questione e vai su ricerca. Imposti casella combinata (invece che di testo), vai su origine riga e scrivi "Ente statale";"Privato";"Azienda";"Quellochevuoi"
^__^

No la sua soluzione è più pulita: se in Access memorizzi nella casella combinata tutti i possibili valori non saprai mai dove vanno a finire, non saranno accessibili da software esterni e non potrai esportarli in nessun modo (salvo che per rarissimo caso Access non li esporti come domìni, ma non credo). Cioè: Access ti crea la casella combinata, ma se scrivo un software che funga da interfaccia, dove pesco i possibili valori da proporre? Se c'è la tabella si può fare!

Lui giustamente ha messo su una seconda entità che DEVE avere una chiave primaria (codice) che verrà usata per collegare CLIENTI a PROFILO. L'unica differenza rispetto al campo TIPO del cliente è che si può memorizzare in anticipo le categorie, e riutilizzarle quando necessario.