1 / 8

DOCUMENTAZIONE DI SCHEMI E/R

DOCUMENTAZIONE DI SCHEMI E/R. Uno schema E/R non è quasi mai sufficiente da solo a rappresentare tutti gli aspetti e vincoli di un dominio applicativo, per varie ragioni:

dena
Télécharger la présentation

DOCUMENTAZIONE DI SCHEMI E/R

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DOCUMENTAZIONE DI SCHEMI E/R • Uno schema E/R non è quasi mai sufficiente da solo a rappresentare tutti gli aspetti e vincoli di un dominio applicativo, per varie ragioni: • in uno schema E/R compaiono solo i nomi dei vari concetti ma questo può essere insufficiente per comprenderne il significato. • vari vincoli di integrità (proprietà dei dati rappresentati) non possono essere espressi direttamente dai costrutti del modello E/R • Documentazione di schemi E-R: uno schema E/R è corredato con una documentazione di supporto che faciliti l'interpretazione dello schema stesso e a descrivere vincoli di integrità non esprimibili in E/R • Regole aziendali o business rules • Una descrizione di un concetto (entità, associazione e attributo) dello schema E-R (Dizionario dei dati) • Un Vincolo di integrità, sia esso la documentazione di un vincolo dello schema E/R o la descrizione di un vincolo non esprimibile in E/R • Una Derivazione ovvero un concetto che può essere derivato calcolo da altri concetti dello schema (Dato Derivato)

  2. Esempio: Dizionario dei dati

  3. Esempio: Vincoli di Integrità e di Derivazione • Regole Aziendali espresse nello schema E/R: • Uno studente può essere rappresentante di una sola facoltà • La matricola di uno studente è univoca all’interno della sua facoltà • Una facoltà ha esattamente tre rappresentanti • Una facoltà ha almeno uno studente iscritto • Regole Aziendali, non incluse (non esprimibili) nello schema E/R: • Il numero di studenti NUMSTUDENTI di una facoltàè pari al numero di studenti iscritti alla facoltà (associati tramite ISCR) [REGOLE DI DERIVAZIONE] • I rappresentanti di una facoltà devono essere studenti di quella facoltà[VINCOLO DI INTEGRITA’]

  4. IMPLEMENTAZIONE REGOLE AZIENDALI • Quando si produce lo schema logico e quindi il codice SQL, tutte le regole aziendali - sia quelle già espresse in E/R che quelle non espresse, devono essere opportunamente implementate. • Attraverso la progettazione logica solo alcuni vincoli di integrità espressi nello schema E/R, tra i quali in particolare • Identificatori (Vincoli di chiave) • Partecipazione con molteplicità unitaria ad una associazione vengono riportati nello schema logico e quindi in SQL! • Esempio: Traduzione in relazionale dello schema E/R: FACOLTÀ(CODFAC,NUMSTUDENTI) STUDENTE(MATR,CODFAC) FK : CODFAC REFERENCES FACOLTÀ RAPPRES(MATR,CODFAC,CODFAC_RAPPRESENTATA,DATA) FK : MATR,CODFAC REFERENCES STUDENTE FK : CODFAC_RAPPRESENTATA REFERENCES FACOLTÀ NOT NULL

  5. IMPLEMENTAZIONE REGOLE AZIENDALI • Per le regole aziendali • Espresse in E/R ma non sono esprimibili nello schema logico: cardinalità con un valore preciso, proprietà di copertura, … • Non esprimibili in E/R, in particolare regole di derivazione si hanno diverse modalità di implementazione: • Soluzione lato server:Nel DBMS, ovvero direttamente sul DB, attraverso elementi avanzati del linguaggio SQL, quali trigger e CHECK complessi nella CREATE TABLE • Queste regole non potranno mai essere violate! • Soluzione lato client:Nelle applicazioni che accedono al DB, attraverso la definizione di opportune procedure in un linguaggio di programmazione o nelle interfacce per accedere al DB (ad esempio: maschere in ACCESS) • Queste regole possono essere violate dalle altre applicazioni!

  6. ESEMPIO: SOLUZIONE LATO SERVER • Soluzioni particolari: La regola (B.) non espressa in E/R equivale a dire che in RAPPRES gli attributi CODFAC e CODFAC_RAPPRESENTATA sono uguali: si può mettere un unico attributo RAPPRES(MATR,CODFAC,DATA) FK : MATR,CODFAC REFERENCES STUDENTE • Trigger o Regole Attive (SQL-99) : Programmi attivati automaticamente dal DBMS al verificarsi di determinate condizioni e operazioni sulle tabelle. • In un trigger vengono specificati tre elementi (EVENT- CONDITION- ACTION ): al seguito della modifica specificata in EVENT se è vera la condizione CONDITION vengono specificate le azioni di ACTION • Esempio: trigger per assicurare che max-card(FACOLTA’,RAPPRES)=3 • EVENT : inserimento in RAPPRES di una tupla (-,-,CODF2,-) • CONDITION : RAPPRES contiene 3 tuple con (-,-,CODF2,-) • ACTION: abort (l’inserimento non viene effettuato)

  7. ESEMPIO: SOLUZIONE LATO CLIENT • Esempio: Nella maschera per l’inserimento delle facoltà si inseriscono esattamente tre box per ottenere card(FACOLTA’,RAPPRES)=(3,3) • Se i dati sono inseriti senza usare la maschera ma direttamente nella tabella RAPPRES il vincolo viene violato!

  8. INCONSISTENZA di uno schema con vincoli • INCONSISTENZA: lo schema con vincoli di integrità non ammette alcuna istanza ovvero non è possibile soddisfare i vincoli di integrità presenti nello schema Esempio di schema E/R inconsistente • CONTROLLO DI CONSISTENZA : algoritmi per decidere se uno schema è consistente o meno

More Related