Documentazione e regole aziendali

E' bene che il diagramma ER sia accompagnato da una documentazione che lo descrive in tutte le sue componenti. Tale documentazione è utile in quanto, ad esempio, il significato dei concetti presenti nel diagramma spesso richiede una spiegazione che va oltre il nome del concetto. Inoltre, può accadere che per mantenere la leggibilità del diagramma alcuni costrutti (tipicamente attributi) vengano omessi dal diagramma.

Inoltre, come ogni formalismo, anche il modello concettuale ER ha una espressività limitata. Ne deriva che esistono vincoli della realtà modellata che non possono essere espressi con il modello ER. Ad esempio, non sono codificabili nel modello ER la regola che afferma che un dipendente può partecipare al consiglio di amministrazioni di un teatro solo dopo 10 anni di attività e la regola che dice che un teatro non può mettere in scena più di due produzioni proprie all'interno della stessa stagione teatrale. Inoltre, il diagramma ER dice quali sono gli attributi calcolati ma non specifica come calcolarli. Il diagramma ER deve quindi essere integrato da un insieme di regole aziendali (business rules) che lo completano.

La documentazione del diagramma ER deve contenere:

• per ogni entità: il nome, una descrizione, la lista degli attributi, la chiave, il tipo (normale o debole) e eventuali specializzazioni;
• per ogni relazione: il nome, una descrizione, le entità partecipanti e le relative cardinalità, gli eventuali attributi e il tipo (normale o identificante);
• per ogni attributo: il nome, una descrizione, il tipo (semplice, multivalore, composto, calcolato) e il fatto che sia obbligatorio o opzionale;
• le regole aziendali.

Proponiamo una soluzione per descrivere uno schema concettuale basata su XML. Particolari applicazioni (linguaggi) XML possono essere definite nel linguaggio Document Type Definition (DTD). Proponiamo di seguito una DTD per descrivere uno schema concettuale basato sul modello ER:

<!ELEMENT er      (entità | relazione | regola)*>
<!ATTLIST er      diagramma CDATA #IMPLIED>

<!ELEMENT entità  (descrizione?, attributo*, specializzazione*)>
<!ATTLIST entità  nome ID #REQUIRED
                  tipo (normale | debole) #REQUIRED
                  relazioni IDREFS #IMPLIED>

<!ELEMENT relazione  (descrizione?, partecipazione, attributo*)>
<!ATTLIST relazione  nome ID #REQUIRED
                     tipo (normale | identificante) #REQUIRED>

<!ELEMENT partecipazione  (partecipante, partecipante, partecipante*)>
<!ELEMENT partecipante EMPTY>
<!ATTLIST partecipante entità IDREF #REQUIRED
                       cardinalitàMin CDATA #REQUIRED
                       cardinalitàMax CDATA #REQUIRED
                       ruolo CDATA #IMPLIED>

<!ELEMENT attributo  (nome, descrizione?)>
<!ATTLIST attributo  tipo (semplice | multivalore | composto | calcolato) #REQUIRED
                     opzionale (si | no) #REQUIRED
                     chiave (si | no) #REQUIRED>

<!ELEMENT specializzazione EMPTY>
<!ATTLIST specializzazione  sotto-entità IDREFS #REQUIRED
                            tipo (TO | TD | PO | PD) #REQUIRED>

<!ELEMENT descrizione (#PCDATA)>
<!ELEMENT nome        (#PCDATA)>
<!ELEMENT regola      (#PCDATA)>

La soluzione basata su XML numerosi vantaggi, fra questi:

1. non necessita di alcun DBMS;
2. la documentazione può essere interrogata mediante linguaggi di interrogazione per XML, quali XPath e XQuery;
3. la documentazione può essere validata rispetto allo schema DTD definito. Inoltre, è facile estendere il processo di validazione con delle procedure che verificano vincoli ulteriori, non catturati dalla DTD proposta. Ad esempio, il fatto che non esistano cicli di entità deboli;
4. la documentazione può essere trasformata, mediante XSLT, in altri formati, quali LaTeX e HTML.