[Access] Progetto basi di dati

[Squall90]

Salve a tutti!!!

Allora sto facendo un progetto in access per la gestione di un noleggio di dvd...Ho fatto lo schema relazionale su un foglio, e ora ho creato tutte le tabelle che mi servono, ma ora viene il bello...Devo collegare tutte le tabelle mediante le relazioni...Il problema è che non ricordo come si impostano, dato che non ci sono i rombi come nello schema E-R...Faccio un esempio:

FILM (Regista, Titolo, CostoNol., Anno)
DISTRIBUTORE (CodD, Nome, Indiriz.)
DISTRIBUITO_DA (Regista, Titolo, CodD, Costo)

Film e Distributore sono due entità, mentre distribuito_da è la relazione che sta nel rombo, costo è l'attributo della relazione

Distributore-Distribuito_da: 0 a molti
Distribuito_da-Film: 1 a molti

Come devo impostare la cosa su Access??? Grazie

[Ronin]

premi il pulsante "relazioni", aggiungi le tabelle film e distributore (che avrai creato in precedenza) alla vista, poi trascini la chiave primaria dalla parte 1 alla parte molti (cioè da distributore a film), e si crea la relazione (poi vai nelle proprietà della freccia che la rappresenta, e imposti l'integrità referenziale).

sennò compri access for dummies, o libro di equivalente livello

[Squall90]

premi il pulsante "relazioni", aggiungi le tabelle film e distributore (che avrai creato in precedenza) alla vista, poi trascini la chiave primaria dalla parte 1 alla parte molti (cioè da distributore a film), e si crea la relazione (poi vai nelle proprietà della freccia che la rappresenta, e imposti l'integrità referenziale).

sennò compri access for dummies, o libro di equivalente livello

Ma devo creare anche la tabella Distribuito_da???

[~spiral~]

Perchè nel tuo elenco iniziale distribuito_da contiene anche regista e titolo?

La relazione distributore -> film è di uno a molti, e fin qui ok, quindi dovrai avere un IdDistributore nella tabella film. Poi leghi la chiave primaria della tabella distributori alla colonna IdDistributore della tabella film in modo diretto come ti ha spiegato Ronin.

Poi non so il livello di complessità che devi raggiungere, ma sarebbe buona cosa creare anche una tabella Registi, in quanto dai consistenza ai dati e permetti dei filtri validi (prova a far inserire la filmografia di Shamalayan o come caspian si scrive e far inserire ogni volta il nome regista corretto, al 99% hai perso un filtro possibile )

[Squall90]

Lo schema è questo:

[Ronin]

in access (ma anche in sql) le relazioni non esistono come tabelle a parte, ma come link tra i campi delle tabelle, quindi no, non devi creare anche "distribuito da" (vedere quello schema fa venire voglia di cancellare le università con un tratto di penna non è riferito a te, eh, ma ai professori che vivono ancora nel mondo delle schede perforate)

[Squall90]

E quindi come le devo fare???

[Ronin]

nel modo che ti ho spiegato sopra

[KymyA]

Ed in ogni tabella ci aggiungerei anche un campo sequenziale univoco e creerei una chiave primaria con i campi di cui fai le select. Purtroppo "non ho studiato" e quindi del "disegnino" non ci ho capito una benemerita... altrimenti una mano te la davo.
Esempio di Select :

SELECT     *
FROM  TABELLA1 LEFT OUTER JOIN
                      TABELLA2 ON TABELLA1.Id = TABELLA2.Id
WHERE Condizione

Non fa altro che collegarti i campi Id delle due tabelle (possono avere nomi diversi) prendendo tutti i records della tabella1 ed i corrispondenti della tabella2.
Il LEFT OUTER è il 'senso' del collegamento, ovvero per ogni records di Tabella1 prendi TUTTI i records di Tabella2

[Squall90]

nel modo che ti ho spiegato sopra

E ma quindi le relazioni Organizzato_In ecc., non mi servono a niente in access???

Ed in ogni tabella ci aggiungerei anche un campo sequenziale univoco e creerei una chiave primaria con i campi di cui fai le select. Purtroppo "non ho studiato" e quindi del "disegnino" non ci ho capito una benemerita... altrimenti una mano te la davo.
Esempio di Select :

SELECT     *
FROM  TABELLA1 LEFT OUTER JOIN
                      TABELLA2 ON TABELLA1.Id = TABELLA2.Id
WHERE Condizione

Non fa altro che collegarti i campi Id delle due tabelle (possono avere nomi diversi) prendendo tutti i records della tabella1 ed i corrispondenti della tabella2.
Il LEFT OUTER è il 'senso' del collegamento, ovvero per ogni records di Tabella1 prendi TUTTI i records di Tabella2

Queste sono le query, che però non mi servono, per ora devo solo creare le tabelle su access con tutte le relazioni

[Ronin]

insisto:


non sai quanto ne hai bisogno.

[Squall90]

insisto:


non sai quanto ne hai bisogno.

Eh ma non ho il tempo materiale, entro venerdi devo consegnarlo

[Ronin]

non hai il tempo di imparare a camminare perchè entro venerdì devi aver corso la maratona? auguri
(mi sembra che ci sia un corso gratis su manuali.net se è d'aiuto)

[kaaio]

in access (ma anche in sql) le relazioni non esistono come tabelle a parte, ma come link tra i campi delle tabelle, quindi no, non devi creare anche "distribuito da" (vedere quello schema fa venire voglia di cancellare le università con un tratto di penna non è riferito a te, eh, ma ai professori che vivono ancora nel mondo delle schede perforate)

Le relazioni molti a molti vengono rappresentate con una tabella a parte, no?
Ad esempio Lavora_In potrebbe essere (ID_centro, ID_impiegato, data_fine, carica).

Per le relazioni uno a molti come dice Ronin non serve una tabella a parte.
Organizzato_in quindi non sarà una tabella, in settore metti la chiave esterna ID_centro.

Distribuito_da sicuro sia molti a molti? un film può avere più distributori?
Perchè hai messo un entità data? Che poi usi solo per data inizio ma non per data fine?

[Squall90]

Siamo sicuri???

Perchè altri mi hanno detto che per ogni entità devo creare una tabella, tipo cosi:

[kaaio]

Sarebbe utile avere chiara la differenza tra entità e relazioni prima..

Se guardi Organizzato_in vedi che un settore può appartenere ad un solo centro, quindi diventa inutile avere una tabella per la relazione.. Magari funziona anche, però non è corretto..

[Squall90]

Per ogni relazione volevo dire sorry

Però dice che un centro può avere più settori

[kaaio]

Però dice che un centro può avere più settori

Certo, ogni settore avrà l'ID del centro di cui fà parte, così mantieni la relazione.

CENTRO(ID_Centro, Indirizzo, telefono)
SETTORE(ID_Settore, ID_Centro)

[Squall90]

Quindi vuoi dire che devo cancellare tutte le tabelle relazionali che ho creato???

[kaaio]

Quindi vuoi dire che devo cancellare tutte le tabelle relazionali che ho creato???

No, solo le relazioni uno a molti non devono avere una tabella, per le relazioni molti a molti e le entità ti serve.
Lavora_in quindi resterà, anche se continuo a non capire perchè gestisci così le date..
Ci sono parecchie altre cose che non mi tornano, ad esempio in film nel diagramma ER definisci come chiave (titolo,regista) , poi però usi una chiave surrogata..

Se ho capito bene fai ing.informatica, queste cose prima o poi ti serviranno di sicuro, già è abbastanza ridicolo fare un progetto universitario di basi di dati in access, a meno di particolari problemi ti conviene veramente perderci un pò più di tempo sopra, ne vale la pena..

[Squall90]

No, solo le relazioni uno a molti non devono avere una tabella, per le relazioni molti a molti e le entità ti serve.
Lavora_in quindi resterà, anche se continuo a non capire perchè gestisci così le date..
Ci sono parecchie altre cose che non mi tornano, ad esempio in film nel diagramma ER definisci come chiave (titolo,regista) , poi però usi una chiave surrogata..

Se ho capito bene fai ing.informatica, queste cose prima o poi ti serviranno di sicuro, già è abbastanza ridicolo fare un progetto universitario di basi di dati in access, a meno di particolari problemi ti conviene veramente perderci un pò più di tempo sopra, ne vale la pena..

E' un pò un controsenso

Tu dici che le relazioni 1 a molti non devo avere una tabella, ma la tabella Lavora_In è circondata solo da relazioni 1 a molti, quindi se la regola è questa bisognerebbe toglierla

Per quanto riguarda invece l'entità Data potrei pure toglierla infatti, o magari metterla come attributo nella relazione Lavora_In

Per quanto riguarda le chiavi titolo e regista, ne ho messa una surrogata per creare meno confusione, che dici??? Il diagramma poi dovrò cambiarlo

[Ronin]

http://www.mc2elearning.com/relazion...le-access.html
neanche la voglia di passare 5 secondi in google...

[Squall90]

E' un pò un controsenso

Tu dici che le relazioni 1 a molti non devo avere una tabella, ma la tabella Lavora_In è circondata solo da relazioni 1 a molti, quindi se la regola è questa bisognerebbe toglierla

Per quanto riguarda invece l'entità Data potrei pure toglierla infatti, o magari metterla come attributo nella relazione Lavora_In

Per quanto riguarda le chiavi titolo e regista, ne ho messa una surrogata per creare meno confusione, che dici??? Il diagramma poi dovrò cambiarlo

Uhm, la guida è buona, ma per quanto riguarda questi dubbi???

[Squall90]

Cosi va meglio???

[Ronin]

va meglio, ma:
1 sei sicuro che un impiegato possa avere cariche diverse in più centri?
2 la tabella data è priva di utilità, non avendo alcun campo tantovale scrivere la data direttamente in lavora_in