http://img353.imageshack.us/img353/8357/schemazf7.png
mi date qualche consiglio? Ciao Olmos
Non è detto...dipende dalla base da cui vuoi partire...
Se una composizione ha un interprete, un compositore, e un direttore
d'orchestra devono appartenere a tebelle separate sempre che tra essi non vi
sia una relazione.
es. se non può esistere un interprete associato a un direttore d'orchestra
allora le tabelle interprete e direttore dovranno essere legate tra loro e a
loro volta legate all'opera...immagina la struttura tenendo in
considerazione il tipo di relazioni e le combinazioni che non si possono
avere nella composizione musicale.
Questo non vuol dire che lo schema che proponi non sia normalizzato.
Spero di essermi spiegato.
VT potrà sicuramente darti più consigli di me a proposito di
normalizzazione.
Guarda inoltre www.accessgroup.it - cisa 2007 - normalizzare un db
Ciao
--
Roberto da Parma
Direi proprio di no.
Nel modello E-R ogni entità dovrebbe rappresentare ciascuno degli
elementi reali che hanno una propria ragion d'essere nel contesto di
riferimento, autonoma e distinta da quelle degli altri.
E non mi sembra che compositori, interpreti e direttori siano
concettualmente assimilabili gli uni agli altri.
Certo, può accadere che una persona sia tutte e tre le cose, ma ciò non
vuole dire che questo sia vero in generale.
>e io li mettei in una unica tabella con un attributo che li
> distingue con una relazione molti a molti con la tabella Composizione
> musicale
In questo modo rappresenteresti una generalizzazione "Operatori musicali"
che ha come figli "Direttori", "Compositori", "Interpreti".
Però nel modello relazionale le generalizzazioni non possono essere
rappresentate esplicitamente e sei costretto a rappresentarle in uno dei
seguenti modi:
- accorpando i figli nel padre (la tua soluzione)
- accorpando il padre nei figli (con tre relazioni distinte come nella
soluzione che ti hanno già suggerito)
- rappresentando separatamente padre e figli collegandoli tramite
opportune relationship.
Comunque, al di là di questo, secondo me non si tratta di una
generalizzazione: sono proprio tre entità distinte già a livello
concettuale.
> http://img353.imageshack.us/img353/8357/schemazf7.png
>
>
> mi date qualche consiglio? Ciao Olmos
>
Prevederei anche per i compositori una relazione molti a molti analoga a
quella già prevista per gli interpreti: infatti un'opera potrebbe essere
composta a più mani.
--
Vincenzo Turturro
Certificato Eucip Core Level
ITA 0000-002299 del 14/05/2007
---------------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------
risorse Access:
http://www.accessgroup.it
---------------------------------------------
Il sito comune di it.comp.as400
http://www.faq400.com
---------------------------------------------
Non è sbagliato accorparli ed associarli N N con una tabella intermedia
ovviamente con un campo TipoPersona che li distingua.
Ma sia la tua che la sua sono soluzioni ottimizzate.
Però attenzione la cosa cambia se le strutture non coincidono totalmente.
Immaginiamo di inserire l'età del direttore d'orchestra, in tal caso se
questo dato agli altri due non serve, tu ottieni una struttura non più
ottimizzata mentre la sua lo è ancora.
Personalmente, nonostante la mole di lavoro userei la sua con N N per
ciascuna delle entità (come già avviene per l'interprete) in modo da non
avere costrizioni ne ora ne mai.
Questo ti genera inevitabilmente un database meno trasparente gestibile
in modo decisamente più complesso.
A questo punto devi fare una valutazione costi, benefici, importanza del
progetto
Ciao
Prima di tutto ringrazio tantissimo VT, Roberto e Paolo per avermi
risposto e per le valutazioni, molto interessante, ho capito che la
struttura che mi è stata proposta è adeguata ed eventualmente
espandibile visto che tengo distinte le entita Direttore, Cantante,
Compositore, dall' altra parte la seconda struttura è più 'costretta'ma
adatta se si hanno poche esigenze, ecco a cosa sono giunto con un aiuto
esterno:
http://img166.imageshack.us/img166/6397/screenshotyi2.png
la tabella ruoli serve a far si che posso inserire lo stesso artista con
più ruoli. Ho eliminato la tabella Nazioni che non mi serve per fare
delle query di selezione ma solo per completare il profilo dell'
artista, quindi magari nato in tempi e nazioni ora dissolte.
Una domanda nella _prima_ struttura se voglio inserire per ogni Opera e
ogni Brano un Artista con più ruoli come dovrei fare ?
Ciao Olmos
Normalizzare... si se hai 100 CD, se hai 10.000 lp è un bel problema,
codificare ogni volta l'artista.
E poi perchè tabella differenti per direttore d'orchestra,
compositore, interprete, autore, ecc.
Una sola con il tipo record, nel mio l'ho chiamato ruolo artista.
Bye.
Bye.
Mmmmm.....e se la canzone è stata scritta da uno ma suonata dall'altro???
Come la gestisci con un campo solo?
>
> "Ganimede" <newto...@yahoo.com> ha scritto nel messaggio
>
news:3d128c29-b8eb-4cbd...@b1g2000hsg.googlegroups.com...
> On 21 Lug, 14:00, "Olmos" <olmos12...@nospamyahoo.com> wrote:
>> Volevo catalogare la mia musica MP3 CD DVD VHS non ho particolari
>> mi date qualche consiglio? Ciao Olmos
>
>
>
> Normalizzare... si se hai 100 CD, se hai 10.000 lp è un bel problema,
> codificare ogni volta l'artista.
>
> E poi perchè tabella differenti per direttore d'orchestra,
> compositore, interprete, autore, ecc.
> Una sola con il tipo record, nel mio l'ho chiamato ruolo artista.
>
> Bye.
>
> Mmmmm.....e se la canzone è stata scritta da uno ma suonata
> dall'altro??? Come la gestisci con un campo solo?
Beh se c'è una tabella ruolo dovrebbe senvire anche a questo, vedi lo
schemino:
http://img166.imageshack.us/img166/6397/screenshotyi2.png
Certo che per le collezioni musicali (CD) lo schema potrebbe anche andar
bene il fatto è che ho anche migliaia di MP3 che sono brani singoli e
con lo schemino non si riesce a gestirli entrambi.
Olmos
> Mmmmm.....e se la canzone è stata scritta da uno ma suonata dall'altro???
> Come la gestisci con un campo solo?
Io faccio così
Tabella per i supporti originali
Tabella per i supporti copia
Ciascuna è in relazione ad una tabella tracce, nella quale c'è un capo
tipologia (una sola lettera) che definisce se è O (per gli originali)
o C se è per le copie, poi con un ulteriore campo di riferimento_ID
che prende l'id univoco di ciscuna tabella (originali e copia)
La tabella degli artisti funziona allo stesso modo, solo che in più si
relaziona anche alle tracce, per cui il campo tipo può contenere O, C
o T, sempre con riferimento_ID di discuna tabella.
Sempre nella tabella degli artisti c'è il campo "ruolo artista" che
cosa ha fatto quella persona in quel disco o traccia, per esempio:
http://img291.imageshack.us/img291/2426/93521172ty9.jpg
http://img291.imageshack.us/img291/3176/79500937ck4.jpg
http://img67.imageshack.us/img67/1218/35293202ym5.jpg
http://img367.imageshack.us/img367/9153/44283701jk4.jpg
Poi ho delle funzioni che trasferiscono gli artisti di un supporto
alle sue tracce (nel caso di dischi non complicati) o del procedimento
inverso, come nel caso delle compilation, per cui ragruppo in maniera
uni
Ovviamente il ruolo dell'artista è codifificato in un'altra tabella
dove tengo tutte le informazioni anagrafiche (i formati (cd, lp, S8,
Elcaset, ecc.), suono (mono, stereo, quadrifonico, 5.1, ecc.), ecc.)
anch'essi differenziati per classe.
Poi ho tabelle per gestire gli ascolti, i cicli di pulizia del
supporto, movimenti, ecc.
Uso Access solo per in front-end e PostgreSQL per il back-end, trigger
e rule mantengono l'integrità riferenziale.
Miao.
Ganimede Dignan.