Schema ER: consiglio

[Masco89]

Salve a tutti, come da titolo avrei bisogno di un consiglio riguardante la realizzazione di una base di dati. La traccia è questa:



Tralasciando la parte iniziale, mi viene un dubbio quando dice(penultimo paragrafo) "E' richiesto di tenere traccia di tutti gli utilizzi delle macchine fatte dagli operai: ...": in questo caso sarebbe più opportuno utilizzare una relazione tripla tra cantiere, operaio e macchina oppure creare un'ulteriore entità "Utilizzo" collegata alle 3 suddette entità tramite tre distinte relazoni? La stessa domanda vale per la parte finale, quando chiede di "registrare tutti gli interventi di manutenzione effettuati sulle gru": entità o relazione?

[Umby2]

Devi creare l'entita' utilizzo.
All'interno di questa entità memorizzi i dati della macchina, dell'operaio, e del cantiere.

[Masco89]

Grazie per la risposta, anche io ero più orientato a creare un'entità piuttosto che utilizzare una relazione tripla... Un'entità utilizzo da collegare a cantiere, macchina e operaio, avente come chiave DATA e CANTIERE. Ho creato un'entità(INTERVENTO) anche per l'altra richiesta, è corretto? Inoltre, da cosa si riconosce formalmente se si deve creare un'entità o una relazione in casi del genere? Da "E' richiesto TENERE TRACCIA" e "REGISTRARE TUTTI"?

[Rggb1]

"Masco89":Inoltre, da cosa si riconosce formalmente se si deve creare un'entità o una relazione in casi del genere? Da "E' richiesto TENERE TRACCIA" e "REGISTRARE TUTTI"?

Scusa ma con quale metodo ricavi o calcoli le relazioni? Nell'esempio, dovendo tenere traccia di una "data" di utilizzo e di una "data" di intervento, come avresti creato una "relazione tripla"?

[Masco89]

Inizialmente credevo che la data potesse essere utilizzata come attributo di relazione... ma a ben pensarci, la data fa parte della chiave nella relazione utilizzo (insieme alle chiavi esterne cantiere e macchina), quindi dobbiamo necessariamente creare una nuova entità, giusto?

[Umby2]

"Masco89":Grazie per la risposta, anche io ero più orientato a creare un'entità piuttosto che utilizzare una relazione tripla... Un'entità utilizzo da collegare a cantiere, macchina e operaio, avente come chiave DATA e CANTIERE. Ho creato un'entità(INTERVENTO) anche per l'altra richiesta, è corretto? Inoltre, da cosa si riconosce formalmente se si deve creare un'entità o una relazione in casi del genere? Da "E' richiesto TENERE TRACCIA" e "REGISTRARE TUTTI"?

Piu che DATA - CANTIERE
farei come campo chiave: [DATA + MACCHINA + Indice]
come dati: [Operaio - Cantiere]

In questo modo potresti memorizzare l'utilizzo della macchina, anche nel caso in cui venga utilizzata piu volte nella stessa giornata da operaio diversi
Per "indice" intendo un contatore che parte da 1, e che ti numera tutti gli utilizzi della macchina.

In base al database che utilizzi, potresti pensare di creare delle chiavi alternative di ricerca, o in alternativa creare delle query, esempio:
Si desidera conoscere l'operaio Umby, quali macchine ha utilizzato durante il mese di marzo 2010, oppure in quali cantieri ha lavorato... e cosi' via...

[Rggb1]

"Masco89":Inizialmente credevo che la data potesse essere utilizzata come attributo di relazione... ma a ben pensarci, la data fa parte della chiave nella relazione utilizzo (insieme alle chiavi esterne cantiere e macchina), quindi dobbiamo necessariamente creare una nuova entità, giusto?

Vedo che non sei proprio a zero, benissimo

Per quanto riguarda la domanda: non è necessario crearla ma magari è utile. Cerca sempre di ridurre all'essenziale entità e relazioni, e relativi attributi.

Nello schema vedo sicuramente le entità Personale, Macchine, Cantieri, e le relazioni fra questi. Proseguendo, puoi per esempio dividere Personale in Operai e Direttori (ma devi controllare l'unicità del dipendente) oppure Macchine in Escavatrici e Gru (elimini un attributo inutile da Escavatrici ma devi avere una relazione in più) e così via.

Consiglio: comincia sempre dallo schema più semplice, in questo caso con entità Personale, Macchine, Cantieri; costruisci le relazioni, se non riesci a rispettare i vincoli e/o lo schema si semplifica, aggiungi qualcosa. Guarda dove ti porta questo metodo e poi facci sapere.

@Umby
Sei andato troppo avanti, stai già progettando il DB mentre noi siamo ancora allo schema ER
[Scherzi a parte, anche io faccio così, "penso" lo schema direttamente in tabelle, chiavi e indici... ma qui sto cercando di essere un po' più formale: direi che è una traccia di esercitazione o simile]

[Umby2]

"Rggb":

@Umby
Sei andato troppo avanti, stai già progettando il DB mentre noi siamo ancora allo schema ER
[Scherzi a parte, anche io faccio così, "penso" lo schema direttamente in tabelle, chiavi e indici... ma qui sto cercando di essere un po' più formale: direi che è una traccia di esercitazione o simile]

Hai proprio ragione...
Ho un approccio sempre da "analista-programmatore" ai problemi, e mai da "puro matematico". Non sono un filosofo dell' informatica, ma un "muratore".

[Masco89]

In primo luogo vorrei ringraziare entrambi per l'aiuto e la vostra disponibilità davvero notevole....
Dunque, sono arrivato ad ottenere il seguente schema relazionale:

CANTIERE( Comune*,Numlicenza*,Datainizio,Tipologia,Direttore,Compenso)
DIRETTORE(CF,NomeDirettore,ResidenzaD)
OPERAIO(CF,NomeOperaio,ResidenzaO)
GRUISTA(CF)
INTERVENTO(DataInt*,NumProg*,CasaC*,PesoMax,Gruista)
MACCHINA(NumProg*,CasaC*,Modello,AnnoA)
ESCAVATRICI(NumProg*,CasaC*)
GRU(NumProg*,CasaC*,PesoMax)
UTILIZZO(Comune*,NumLicenza*,Data*,NumProg*,CasaC*,Operaio)

ESCAVATRICI E GRU li colleg0 ognuno a Macchina tramite il collegamento "standard" (per eliminare la generalizzazione) ossia con vincoli 0:1 e 1:1
UTILIZZO ha chiavi esterne per CANTIERE e MACCHINA

Spero che questo schema relazionale sia comprensibile; Ho rappresentato direttamente lo schema logico perchè è più semplice da postare ed è strettamente collegato allo schema ER

@Umby: Il professore vorrebbe che in questi casi utilizzassimo le chiavi già presenti senza creare indici o codici, a meno che non ce ne sia strettamente bisogno...

[Masco89]

P.S. Gli attributi rappresentati con gli asterischi sono le chiavi

[Umby2]

"Masco89":
DIRETTORE(CF,NomeDirettore,ResidenzaD)
OPERAIO(CF,NomeOperaio,ResidenzaO)
GRUISTA(CF)

Ma dal punto di vista di database, prevedi una singola tabella per questi 3 elementi, oppure 3 distinte ?
Io ne farei una, mettendo la tipologia del PERSONALE, dove il CF potrebbe rappresentare la chiave, poi ci sono i dati anagrafici, ed infine un campo che potrebbe valere "D" "O" "G" che rappresenta appunto la qualica del dipendente.

[Masco89]

Sinceramente avevo pensato di raggrupparla come mi hai consigliato, solamente che i fatto che esiste una relazione ben esplicitata (direttore GESTISCE cantiere), pensavo fosse più opportuno mantenere direttore come un'entità separata. Al limite si potrebbe fare una via di mezzo? ossia considerare DIRETTORE come definita nel post precedente e OPERAIO con l'aggiunta di un campo che potrebbe rappresentare se è un gruista...

[Umby2]

A me non piace molto, perchè tendo a raggruppare le informazioni omogenee nella stessa tabella (archivio).
Ad esempio la relazione che hai scritto:

CANTIERE( Comune*,Numlicenza*,Datainizio,Tipologia,Direttore,Compenso)
potresti modificarla in:
CANTIERE( Comune*,Numlicenza*,Datainizio,Tipologia,Personale,Compenso)

ovviamente facendo i dovuti controlli in fase di inserimento dati (appunto che il responsabile del cantiera possa essere solo e solamente un direttore e non altri dipendenti).

[Rggb1]

Rieccomi

Anche a me lo schema in generale "non piace" - ma a volte ho idiosincrasie particolari Alcune considerazioni:

1) La r. Direttore/Cantiere non è 1:1 semmai 1:N; l'entità va comunque bene.
2) Separando Direttore e Operaio perdi l'univocità del dipendente, come la controlli?
3) INTERVENTO: non mi è chiaro perché ripeti l'attributo PesoMax

L'unico "problema" vero sembra essere quello che ho indicato al num. (2), il resto direi va bene.