Modello ER e vincoli speciali
ZeroUno
Nell'ultimo scritto per l'esame di stato di ingegneria informatica si
chiedeva, tra l'altro, di "Progettare lo schema concettuale dei dati e
delle funzioni" e "Progettare lo schema logico dei dati" di un sistema
informativo per una università. Nella descrizione del sistema erano
presenti vincoli molto restrittivi, come ad esempio (cito a memoria):
- Un appello per un determinato canale di insegnamento può essere
istituito solo da un docente che appartenga a quel canale.
- Per ciascun appello viene stabilita una commissione di tre docenti,
uno dei quali deve essere il docente che ha istituito l'appello.
Per quel che ho capito io, le richieste di progettazione di cui sopra
vengono semplicemente soddisfatte dal progetto di un modello
Entità-Relazione del sistema e del conseguente modello logico, ma in
questi due modelli, per quello che leggo nei libri, non trovo il modo di
esprimere vincoli come i due citati sopra. Penserei piuttosto che il
rispetto di questi vincoli debba essere imposto successivamente, tramite
codice interno all'applicazione che gestirà il database, o trigger sql,
o altro.
Cosa ne pensate? C'è un modo di esprimere quei vincoli nel modello ER?
Grazie.
--
01
The man with two watches
> Un appello per un determinato canale di insegnamento può essere
> istituito solo da un docente che appartenga a quel canale.
Ciao
Io non sono un grande fan dell'E/R, ma lo schema logico si puo` fare
cosi`:
Ruoli { (Docente, Canale)_PK }
Appelli { Data, (Docente, Canale)_FK -> Ruoli }
La tabella Ruoli elenca i canali a cui un docente e` assegnato;
la sua chiave primaria e` l'insieme dei due campi. La tabella Appelli
fa riferimento alla tabella Ruoli per verificare che l'abbinamento
docente+canale sia valido.
> - Per ciascun appello viene stabilita una commissione di tre docenti,
> uno dei quali deve essere il docente che ha istituito l'appello.
Commissioni { Data, NumeroProf, Docente } CHECK (NumeroProf <= 3)
IstitutoreCommissione { Data_FK -> Commissioni,
Docente_FK -> Commissioni,
(Data, Docente, Canale)_FK -> Appelli }
Quest'ultimo ha la seguente interpretazione: "La commissione
riguardante l'appello del <data> e` partecipata dal prof. <docente>
il quale ha istituito l'appello di pari data".
La cosa non elegante e` la forzatura di cardinalita` che deve
essere fatta mediante vincolo manuale CHECK dato che il modello
relazionale (nelle sue primitive) non prevede specificazione di
cardinalita` degli insiemi.
Controlla se ho scritto scemenze e fammi sapere.
> non trovo il modo di esprimere vincoli come i due citati sopra.
> Penserei piuttosto che il rispetto di questi vincoli debba essere
> imposto successivamente, tramite codice interno all'applicazione
> che gestirà il database
No, tutti i vincoli di integrita` devono stare il piu` appresso
possibile ai dati; altrimenti e` solo questione di tempo affinche`
vengano aggirati.
ciao
orsopoeta
> Ruoli { (Docente, Canale)_PK }
> Appelli { Data, (Docente, Canale)_FK -> Ruoli }
spero mi perdoni zeroUno se vado un po' fuori tema, ma volevo chidere
una cosa su questo tipo di modello.
- ruoli ha una pk composta, che magari ogni chiave e' una fk
- appelli ha una chiave fk, che non e' la prima fk di ruoli e la
seconda, ma la composizione delle due (come se insieme fossero
un'unica chiave)
io in questi casi faccio cosi'
- Ruoli { (Docente, Canale)_UNIQUE, chiave_autogenerata_PK }
- Appelli { Data, chiave_autogenerata_PK -> Ruoli }
altrimenti dovrei riportare su Appelli le due chiavi di ruoli, ma chi
mi dice che la "coppia" (docente, canale) sia univoca?
e' giusto?
grazie 1k
Rob
The man with two watches
> Il 09/09/2008, The man with two watches ha detto :
>
>> Ruoli { (Docente, Canale)_PK }
>> Appelli { Data, (Docente, Canale)_FK -> Ruoli }
> io in questi casi faccio cosi'
>
> - Ruoli { (Docente, Canale)_UNIQUE, chiave_autogenerata_PK }
> - Appelli { Data, chiave_autogenerata_PK -> Ruoli }
Esplicitando: hai surrogato la vera PK declassandola a vincolo,
poi ne hai fatto l'alias col solito ID senza significato.
Nella tabella Appelli hai tolto due campi e li hai sostituiti
con una fk verso Ruoli; la risultante tabella e` molto piu` povera
di dati, criptica, e necessita di un join obbligatorio per
"tradurre" l'ID, il quale non e` un dato e non significa nulla di
per se'.
Ora, per "tradurne" il significato, la tabella Appelli e`
completamente dipendente da Ruoli; anzi, da una _specifica_
istanza di Ruoli (dato che l'ID e` influenzato ad esempio dalla
sequenza in cui aggiungo righe).
Le informazioni che le due tabelle danno NON SONO le stesse; le
informazioni dati neppure.
Nella tabella originale:
Appelli { Data, (Docente, Canale)_FK -> Ruoli }
...io potrei decidere di cambiare solamente il valore di Canale, e
lasciare il compito di verificare l'integrita` referenziale al dbms.
Il corrispondente con gli ID richiede _sempre_ il preventivo join
con una tabella Ruoli GIA` POPOLATA: e che succede se un domani
cade il vincolo che l'Appello puo` essere fatto solo da insegnanti
di ruolo? Devi riscrivere la tabella E TUTTO IL CODICE CHE VI ACCEDE.
Inoltre, come gia` detto molte volte in passato, se io cambio
un valore in Ruoli posso cambiare il significato di una riga in
Appelli, creando condizioni per dati falsi.
> altrimenti dovrei riportare su Appelli le due chiavi di ruoli,
E che problema c'e`?
Comunque non sono due chiavi, ma una chiave composita di due colonne.
> ma chi mi dice che la "coppia" (docente, canale) sia univoca?
Le specifiche concettuali ed il corrispondente vincolo di pk.
> e' giusto?
No, non lo vedi insegnato in alcun testo serio.
Io leggo parecchio e consulto i siti dei docenti; non ho ancora
trovato uno che faccia quello di cui sopra, tranne uno, che
dovrebbe dedicarsi all'agricoltura (ha mancato persino la
definizione di database relazionale...), pero` ha scritto libri
per una nota casa editrice, mah.
ciao
The man with two watches
> Nella tabella originale:
> Appelli { Data, (Docente, Canale)_FK -> Ruoli }
> ...io potrei decidere di cambiare solamente il valore di Canale, e
> lasciare il compito di verificare l'integrita` referenziale al dbms.
Aggiungo che potrei decidere di voler fare vincoli FK aggiuntivi
con altre tabelle, ad esempio Canale con una tabella Canali,
Docente con una tabella Lezioni. Con che cosa li fai se i due attributi
sono ora conglobati in una colonna ID (il quale ID riguarda solo una
particolare istanza di solo una particolare tabella)...?
orsopoeta
niente da dire (magari al momento...)
chiarissimo come sempre
grazie :o)
Rob
ZeroUno
> Io non sono un grande fan dell'E/R, ma lo schema logico si puo` fare
Mi spiace, ma quello chiedono ;)
Per curiosità, quali modelli sono maggiormente usati al posto dell'E/R?
> Ruoli { (Docente, Canale)_PK }
> Appelli { Data, (Docente, Canale)_FK -> Ruoli }
Ok, qiundi oltre a una classe Docente (qui non definita) usi anche una
tabella Ruoli che associa docenti e canali, e poi nella definizione
dell'appello usi la coppia come chiave? Interessante, grazie.
Ma nella tabella Appelli l'attributo Data non dovrebbe essere una PK,
per distinguere un appello dall'altro?
>> - Per ciascun appello viene stabilita una commissione di tre docenti,
>> uno dei quali deve essere il docente che ha istituito l'appello.
>
> Commissioni { Data, NumeroProf, Docente } CHECK (NumeroProf <= 3)
>
> IstitutoreCommissione { Data_FK -> Commissioni,
> Docente_FK -> Commissioni,
> (Data, Docente, Canale)_FK -> Appelli }
>
> Quest'ultimo ha la seguente interpretazione: "La commissione
> riguardante l'appello del <data> e` partecipata dal prof. <docente>
> il quale ha istituito l'appello di pari data".
Questa non la capisco molto, ma forse non mi sono spiegato bene prima...
non capisco come faccio a forzare la presenza di quel particolare
docente nella formazione della commissione. Perché, in effetti,
supponendo che ci sia una tabella Docenti:
Docenti { Matricola_PK, Nome, Cognome, ... }
Dovrei poi avere una tabella che in qualche modo mi permetta di sapere
da chi è formata ciascuna commissione:
Commissioni { (Data, Canale)_FK -> Appelli,
Matricola1, Matricola2, Matricola3 }
Dove Matricola1/2/3 provengono dalla tabella Docenti.
Forse potrei sostituire "(Data, Canale)_FK" con "(Data, Docente,
Canale)_FK", e poi togliere Matricola3? Questo sarebbe sufficiente?
> Controlla se ho scritto scemenze e fammi sapere.
Ma figurati, non sarei mai in grado ;)
Anzi sono nuovo del campo, quindi ho sicuramente scritto o capito male
qualcosa io.
>> Penserei piuttosto che il rispetto di questi vincoli debba essere
>> imposto successivamente, tramite codice interno all'applicazione
>> che gestirà il database
>
> No, tutti i vincoli di integrita` devono stare il piu` appresso
> possibile ai dati; altrimenti e` solo questione di tempo affinche`
> vengano aggirati.
L'idea di usare trigger SQL non può essere utile?
Grazie mille per l'aiuto!
--
01
The man with two watches
> Il 9-09-2008 20:38, The man with two watches ha scritto:
>
>> Io non sono un grande fan dell'E/R, ma lo schema logico si puo` fare
>
> Mi spiace, ma quello chiedono ;)
> Per curiosità, quali modelli sono maggiormente usati al posto dell'E/R?
Bella domanda; statisticamente credo che il piu` usato sia
la descrizione narrativa su foglio di carta :-) seguita dalla
traduzione diretta nel db.
La mia opinione e` che il modello E/R si pone troppo poco al di
sopra del modello relazionale per giustificare sempre la pena di
mantenere due schemi.
Inoltre sarebbe piu` utile qualcosa che mi risolva anche la
generazione del codice, oggetti e metodi. UML da questo punto di
vista e` piu` completo. (Poi pero` sara` il turno di chiedersi se
val la pena di usare un cannone per ammazzare una zanzara)
>> Ruoli { (Docente, Canale)_PK }
>> Appelli { Data, (Docente, Canale)_FK -> Ruoli }
>
> Ok, qiundi oltre a una classe Docente (qui non definita) usi anche una
> tabella Ruoli che associa docenti e canali, e poi nella definizione
> dell'appello usi la coppia come chiave? Interessante, grazie.
Si; in questo modo ci si assicura che il docente e` effettivamente
di ruolo in quel canale.
> Ma nella tabella Appelli l'attributo Data non dovrebbe essere una PK, per
> distinguere un appello dall'altro?
Si. Oppure la chiave e` un'altra; non lo posso sapere, dato che ci
hai dato solo un frammento di specifiche. Io ho dato solo il minimo
per risolvere i due problemi principali.
> Questa non la capisco molto, ma forse non mi sono spiegato bene prima...
> non capisco come faccio a forzare la presenza di quel particolare
> docente nella formazione della commissione.
Approfitto per pulire lo schema (elenco solo gli attributi e i vincoli
a parte).
Ruoli { Docente, Canale }
Appelli { Data, Docente, Canale }
Commissioni { Data, NumeroProf, Docente }
IstitutoreCommissione { Data, Docente, Canale }
La presenza del docente nella relativa commissione e` verificata
dal vincolo (Data, Docente)_FK -> Commissioni, mentre invece
il vincolo (Data, Docente, Canale)_FK -> Appelli mi verifica che il
docente e` lo stesso che ha istituito l'appello di pari data per
quel canale.
Mancano svariati vincoli piu` semplici che vengono delegati
ai laureandi :-)
> Perché, in effetti, supponendo che ci sia una tabella Docenti:
>
> Docenti { Matricola_PK, Nome, Cognome, ... }
>
> Dovrei poi avere una tabella che in qualche modo mi permetta di
> sapere da chi è formata ciascuna commissione:
C'e` gia`: nel mio schema e` la tabella commissioni. Es.
Commissioni
Data NumeroProf Docente
--------------------------------
10/9/2008 1 Tizio
10/9/2008 2 Caio
10/9/2008 3 Sempronio
> Commissioni { (Data, Canale)_FK -> Appelli,
> Matricola1, Matricola2, Matricola3 }
>
> Dove Matricola1/2/3 provengono dalla tabella Docenti.
ORRORE!!!!!!!!!!!!!!!!!!!! TIRATONA D'ORECCHIE!!!!!!!!!!!
Quale principio fondamentale questa tabella viola?
> Forse potrei sostituire "(Data, Canale)_FK" con "(Data, Docente,
> Canale)_FK", e poi togliere Matricola3? Questo sarebbe sufficiente?
No: solo un docente e` richiesto che abbia istituito l'appello; gli
altri due possono non averlo fatto (oppure si).
Questo e` causa della necessita` di avere una tabella a parte che
mi specifica il docente che ha costituito la commissione.
Potrei anche farlo mediante vincolo
Appelli.(Data, Docente)_FK -> Commissioni.(Data, Docente)
...ma mi richiederebbe che all'atto dell'istituzione dell'appello
sia gia` decisa ed inserita la commissione, il che immagino non
avvenga; in caso contrario, si potrebbe togliere la tabella
IstitutoreCommissione ed usare il vincolo sopra per verificare
che il docente che istituito l'appello sia parte della commissione.
>> Controlla se ho scritto scemenze e fammi sapere.
>
> Ma figurati, non sarei mai in grado ;)
Ciascuno e` in grado di insegnare qualcosa a chiunque; io non ho
mai avuto timore reverenziale per nessuno, e per questo mi sono
puntualmente scontrato con chi pretendeva di avere ragione
"ipse dixit".
>> No, tutti i vincoli di integrita` devono stare il piu` appresso
>> possibile ai dati; altrimenti e` solo questione di tempo affinche`
>> vengano aggirati.
>
> L'idea di usare trigger SQL non può essere utile?
No: un trigger e` procedurale (es. non mi verifica i dati passati)
e puo` essere aggirato in svariati modi. Un vincolo dichiarativo e`
molto superiore e preferibile al codice procedurale.
ciao
ZeroUno
> La presenza del docente nella relativa commissione e` verificata
> dal vincolo (Data, Docente)_FK -> Commissioni, mentre invece
> il vincolo (Data, Docente, Canale)_FK -> Appelli mi verifica che il
> docente e` lo stesso che ha istituito l'appello di pari data per
> quel canale.
Ok grazie, credo di aver capito.
> Commissioni
> Data NumeroProf Docente
> --------------------------------
> 10/9/2008 1 Tizio
> 10/9/2008 2 Caio
> 10/9/2008 3 Sempronio
Ah ok, non avevo capito il significato di NumeroProf: credevo indicasse
"quanti prof sono presenti nella commissione", e in effetti qualcosa non
mi quadrava ma avevo sorvolato per non perdermi nei dettagli ;-)
Così è a posto.
>> Commissioni { (Data, Canale)_FK -> Appelli,
>> Matricola1, Matricola2, Matricola3 }
>>
>> Dove Matricola1/2/3 provengono dalla tabella Docenti.
>
> ORRORE!!!!!!!!!!!!!!!!!!!! TIRATONA D'ORECCHIE!!!!!!!!!!!
> Quale principio fondamentale questa tabella viola?
Accetto la tirata senza riserve, a mia parziale discolpa posso dire che
mi sembrava brutto già a guardarlo ma non mi sono messo a pensarci
troppo :-)
Il fatto è che nel breve tempo dedicato finora allo studio
dell'argomento ho sempre disegnato prima il modello ER e poi da lì sono
passato alla progettazione logica. Qui invece ho scritto la cosa al volo
tanto per spiegarmi. Certamente pensando di dover fare le cose per bene
immaginerei di creare due entità, Docente e Commissione, legate da una
relazione "Fa parte di", e quindi il risultato sarebbe diverso.
--
01