[SQL]Chiavi Primarie ed Esterne

[cionci]

Volendo essere pignoli, per minimizzare la ridondanza:

indirizzo (id, indirizzo, altro, idlocalita)
localita(id, localita, provincia, CAP)

Tra l'altro questo la tabella con i CAP si trova già pronta.

Addirittura si potrebbe estrarre l'informazione sul ruolo, visto che bene o male c'è duplicazione.

ruolo (id, denominazione, descrizione)
assegnazione (idruolo, iddipendente, idsede) con chiave (iddipendente, idsede) se una persona può avere un solo ruolo in una determinata sede, con chiave (idruolo, iddipendente, idsede) se una persona può avere diversi ruoli in una determinata sede.

Se questi dati servissero in altre relazioni, basterebbe estrarre un idassegnazione ed usarlo come chiave primaria.

[RaouL_BennetH]

EDIT, non avevo ancora letto i nuovi messaggi di Cionci

[Guille]

Originariamente inviato da cionci

Ok, questo ha perfettamente senso.

Però tutto deve essere modificato.

sede (id, denominazione, descrizione, idindirizzo)
persona (id, nome, cognome, etc, idindirizzo)
ruolo (ruolo, iddipendente, idsede) con chiave (iddipendente, idsede)
dipendente (id, idpersona, tipo_contratto, scadenza, etc, etc)
indirizzo (id, indirizzo, comune, provincia, cap)

Originariamente inviato da cionci

Volendo essere pignoli, per minimizzare la ridondanza:

indirizzo (id, indirizzo, altro, idlocalita)
localita(id, localita, provincia, CAP)

Tra l'altro questo la tabella con i CAP si trova già pronta.

Addirittura si potrebbe estrarre l'informazione sul ruolo, visto che bene o male c'è duplicazione.

ruolo (id, denominazione, descrizione)
assegnazione (idruolo, iddipendente, idsede) con chiave (iddipendente, idsede) se una persona può avere un solo ruolo in una determinata sede, con chiave (idruolo, iddipendente, idsede) se una persona può avere diversi ruoli in una determinata sede.

Se questi dati servissero in altre relazioni, basterebbe estrarre un idassegnazione ed usarlo come chiave primaria.

Concordo su quasi tutto, anche se hai ridotto il tutto alla gestione dei dipendenti , ma rimane comunque il fatto che se non si ha la necessita' di assegnare lo stesso indirizzo a piu' entita', e qui viene eliminata dal fatto che esiste l'entita' sede che ha un suo indirizzo unico altrimenti sarebbe un'altra sede, la tabella indirizzi è inutile a meno che non si abbia la necessita' di assegnare piu' indirizzi alla stessa entita' e in quel caso si dovrebbe avere la tabella indirizzi che punta all'entita' in questione (ad esempio un cliente) e non viceversa o, al limite, si dovrebbe interporre una tabella di assegnazione, come hai fatto per il caso dei ruoli multipli, cosa che potrebbe coprire tutte le possibili eventualita'.

[cionci]

L'avevo lasciato appunto aperto alla gestione di nuove relazioni che necessitano di indirizzo e persone...
Ad esempio:

clienti (id, denominazione, p.iva, idsede_legale, idsede_amminsitrativa, idpersona_referente)

etc etc

Ad esempio: un referente potrebbe avere come indirizzo (per spedire la posta) l'indirizzo della sede legale o della sede amminsitrativa o addirittura un altro completamente diverso.

[CwNd]

Originariamente inviato da cionci

Non mi sembra poi tanto bello...poi per carità, può avere senso per le prestazioni.

Effettivamente inq uesto genere di ristrutturazione si introduce un campo che funge da discriminante per determinare il tipo di entità che rappresenta quel record.
Come ripeto, la soluzione che ho proposto è utile se si stima che la maggior parte delle persone sono anche dipendenti, altrimenti no perchè si andrebbero a generare un sacco di valori nulli.

Comunque è difficile proporre una soluzione efficiente ed ottimizzata senza avere uno schema con le associazioni e le relative cardinalità.

[RaouL_BennetH]

Originariamente inviato da Guille

Concordo su quasi tutto, anche se hai ridotto il tutto alla gestione dei dipendenti , ma rimane comunque il fatto che se non si ha la necessita' di assegnare lo stesso indirizzo a piu' entita', e qui viene eliminata dal fatto che esiste l'entita' sede che ha un suo indirizzo unico altrimenti sarebbe un'altra sede, la tabella indirizzi è inutile a meno che non si abbia la necessita' di assegnare piu' indirizzi alla stessa entita' e in quel caso si dovrebbe avere la tabella indirizzi che punta all'entita' in questione (ad esempio un cliente) e non viceversa o, al limite, si dovrebbe interporre una tabella di assegnazione, come hai fatto per il caso dei ruoli multipli, cosa che potrebbe coprire tutte le possibili eventualita'.

Questa necessità c'è

Basta pensare alla sede di un cliente dove il dipendente va a lavorare.

[gugoXX]

Originariamente inviato da RaouL_BennetH

Ciao a tutti

Considerando queste entità:

Persona
(id, nome, cognome)


Dipendente : Persona
(ruolo, personaId, indirizzoId)

Indirizzi
(id_indirizzo, domicilio, comune, provincia, cap)
Vorrei capire:

1) Nella tabella dipendente, è necessaria una chiave primaria?
2) Nella tabella dipendente, le chiavi esterne sono relative alle chiavi primarie di Indirizzi e Persone, posso mettere due chiavi esterne sulla stessa tabella?
3) C'è modo per impedire anche per il più incredibile dei casi, che vengano inseriti nella tabella dipendente degli id relativi a persone o indirizzi che non esistono nelle due tabelle?

Grazie mille per i chiarimenti

RaouL.

la tabella dipendente e' la classica tabella associativa.
Per la quale puoi mettere la chiave primaria multipla (personaId, indirizzoId), e ciascun campo in chiave straniera verso la tabella entita' relativa.
Non si capisce "ruolo" che senso abbia in questa tabella.
Forse che ogni persona, a seconda dell'indirizzo, puo' avere un ruolo diverso? Se si', allora va bene li', altrimenti migrala sulla tabella Persona, se puo' avere un ruolo solo, oppure crea la tabella apposta di associativa ruoli come porposto da Cionci (anch'essa con la chiave primaria su 2 campi)

[Guille]

Originariamente inviato da RaouL_BennetH

Questa necessità c'è

Basta pensare alla sede di un cliente dove il dipendente va a lavorare.

In realta' non è vero in quanto l'entita' dipendente lo devi associare all'entita' cliente (per sapere a chi intestare la fattura), e da questa associazione ricavi l'indirizzo dove va a lavorare: ovvero l'indirizzo del cliente.
Se prevedi per l'entita' cliente piu sedi di lavoro questa entita' sede cliente deve essere definita ed ovviamente associata all'entita' cliente, per cui al massimo avresti l'associazione dell'entita' dipendente all'entita' sede cliente da cui ricavi l'indirizzo.
E ritorniamo sempre al punto che ad una entita' indirizzo deve corrispondere sempre un'altra entita' che ne sia titolare.
Negli esempi finora riportati invece si ha la possibilita' di avere indirizzi senza che siano assegnati ad una entita' e che per creare un entita' di tipo persona, cliente, sede, ecc.. debba prima essere creata un'entita' indirizzo. Vogliamo parlare di cosa comporterebbe, all'atto pratico, l'implementazione di una soluzione del genere ?