PDA

Visualizza la versione completa : [OT] Normalizzazione Schema E-R


Nintendojo
14-01-2006, 10:22
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.

VERSIONE PRELIMINARE

http://img59.imageshack.us/img59/1011/er3jw.jpg (http://imageshack.us)

SCHEMA RISTRUTTURATO

http://img62.imageshack.us/img62/9477/erricl2xw.jpg (http://imageshack.us)

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 :messner:

anx721
14-01-2006, 19:58
direi che è corretto

newbie
16-01-2006, 13:48
Dal punto di vista formale, non è molto corretto fare tutto in un passo solo. Bisognerebbe

1) accorpare le entità nel padre, aggiungendo il campo "tipo" come attributo composto ID-Descrizione
2) separare l'attributo composto in un'altra tabella (poichè nelle ristrutturazioni gli attributi composti vanno eliminati)

Se vuoi evitare i due passi, dovresti almeno dire perchè hai accorpato in quel modo (sporco ma efficace).

Nintendojo
16-01-2006, 14:05
Grazie per la dritta: non mi è però chiaro quando dici accorpare le entità figlie nel padre: come faccio ad inserire ditta e privato all'interno di Clienti?
Non basta che nel primo punto creo un nuovo attributo composto "tipo" (composto da id e descrizione) e riporto in cliente gli attributi CF, Nome e Partita IVA.
Poi creo la tabella Profilo come nella seconda immagine.
Ho sbagliato qualcosa?

Grazie in anticipo!

PS: inoltre è più corretto che nella relazione da Profilo verso Clienti non sia (1,N) ma (0,N), perchè alcuni profili posso essere presenti senza però essere necessariamente associati a nessun cliente, non trovi?

newbie
17-01-2006, 18:05
Praticamente "accorpare le entità figlie nel padre" vuol dire, in burocratese, quello che hai già fatto, cioè trasformare la gerarchia in un'unica entità contenente gli attributi di padre e figlie. Il "Profilo", come hai detto tu stesso nel primo post, fa da "tipo" (che in teoria sarebbe un attributo, composto, di ogni elemento di Cliente), che hai messo in una tabella separata.
A livello concettuale, cioè, non c'è niente di sbagliato. E' a livello formale che i prof potrebbero avere da ridire, nel senso che hai messo insieme due passi della progettazione (trasformazione delle gerarchie ed eliminazione degli attributi composti), e forse loro (compresi i miei) li vogliono vedere separati. Non conoscendoli, non so se separare i due passi serva o meno, comunque, per non rischiare, ti converrebbe almeno motivare la scelta.

Loading