Modellazione di dati e processi aziendali

Figura 2.13: Asserted Subtypes

Diversamente dallo schema precedente qua non deriviamo MalePatient e FemalePatient, ma questi due oggetti sono asseriti, ovvero associati alle popolazione che giocano i loro ruoli, quindi derivo il genere (Gender) a seconda del ruolo giocato.

Capitolo 2. Object Role Modeling 37

Semiderived Subtypes

Come si vede nell'immagine abbiamo che Manager è completamente derivato dalla relazione manages, dato che un Manager in quanto tale deve per forza gestire una Company.

Questo va bene se ho un vincolo che dice che ogni Manager deve gestire una Company, ma se non ho questo vincolo e un Manager resta tale anche se disoccupato, allora lo schema è sbagliato; per risolvere questo problema si utilizza + invece che *, in questo modo ho una semi derivazione.

Preferred ID

Solitamente si utilizza una freccia con linea continua per indicare un sottotipo, così l'oggetto figlio eredita il reference mode del padre; ma se vogliamo utilizzare un reference mode diverso,

Capitolo 2. Object Role Modeling 38

Esempio difficile: Questionario di partenza

Figura 2.14: Tabella del questionraio

Figura 2.15: Schema finale

Figura 2.16:

Capitolo 2. Object Role Modeling 39

2.3.1.7 Passo 7. Ultimi Vincoli e Controlli

Come ultimo passo aggiungiamo ulteriori vincoli sui ruoli e facciamo i controlli finali; questi vincoli possono essere di diversi tipi:

• Vincoli di frequenza: sono numeri interi positivi inseriti sopra al ruolo per indicare quante volte un'istanza dell'entity type associato deve giocare quel ruolo. Nell'esempio un Triangle deve giocare esattamente 3 volte quel ruolo dato che ha 3 vertici
• Range di frequenza: utilizziamo i simboli ≤ e ≥ per indicare che un'istanza dell'entity type associato ad un ruolo deve giocarlo un numero di volte compreso in quel range. Nell'esempio un Paper deve

essere reviewed da almeno 3 Researcher, mentre un Researcher può revisionare al massimo 5 Paper

Intervalli di frequenza: utilizziamo ... per indicare che un'istanza dell'entitytype associato ad un ruolo deve giocarlo un numero di volte compreso tra n e m. Nell'esempio una WeatherStation deve riportare la Temperature da 3 a 12 volte per ogni Year

Capitolo 2. Object Role Modeling 40

Vincoli di frequenza esterni: quando ho una coppia di istanze di due entitytype diversi che può giocare un ruolo un certo numero di volte utilizzo un vincolo di frequenza esterno. Nell'esempio uno Student può sostenere al massimo 3 DrivingTest con lo stesso Teacher

Vincoli ad anello: sono vincoli che tipicamente si utilizzano con le relazioni matematiche (riflessività, simmetria e transitività) ma al contrario, ovvero si controlla che ci siano le seguenti relazioni:

∀x. ¬xRx – Irreflessibilità:

∀x, → ¬yRx – Asimmetria: y. xRy

• Consistenza interna: ogni ruolo dello schema è fortemente soddisfacibile, cioèpuò essere popolato
• Consistenza esterna: lo schema concettuale concorda con i dati del campione ei requisiti
• Mancanza di rindondanza: nessun fatto elementare compare due volte
• Completezza: lo schema concettuale rispetta tutti i requisiti

in questo capitolo vedremoun esempio di un algoritmo per trasformare, cercando di perdere meno informazionipossibili, uno schema ORM in uno schema relazionale.

3.1 Schema Relazionale

Gli schemi relazionali sono stati introdotti per la prima volta da Codd, nel 1969; sono composti da tavole (o tabelle), identificate da un nome e contenenti un set di attributi. Inoltre sono presenti chiavi, chiavi estrerne, valori opzionali e regole di derivazione.

3.1.1 Rappresentazione

Gli schemi relazionali non hanno uno standard di rappresentazione, solitamente vengono utilizzati il layout verticale e orizzontale, di seguito vediamo come lo stile, i vincoli di unicità e i vincoli di obbligatorietà vengono rappresentati:

• Layout orizzontale: i vincoli di unicità si evidenziano sottolineando una volta le chiavi e due volte le chiavi primarie, mentre i vincoli di obbligatorietà utilizzano le parentesi quadre sulle colonne che possono essere nulle

Employee(empNr, empName, deptCode, gender, salary, [tax])

Capitolo 3. Relational mapping

• Layout verticale: i vincoli di unicità si evidenziano inserendo U1, U2, ecc. per le chiavi, e per le chiavi primarie inserendo PK e sottolineandola, mentre i vincoli di obbligatorietà scrivendo in grassetto le colonne obbligatorie.

3.2 Algoritmo Rmap

L'algoritmo Rmap viene utilizzato per la costruzione di uno schema relazionale partendo da quello concettuale. Si tratta di un algoritmo con l'obiettivo di ottenere una maggiore efficienza, e allo stesso tempo di evitare ridondanze. Questi due obiettivi sono un po' in contrasto tra di loro, ma Rmap permette di fare un bilanciamento tra l'efficienza e l'evitare ridondanze. Nel caso dell'efficienza, Rmap permette di utilizzare poche tabelle, quindi di utilizzare meno join (che è un'operazione costosa). Per quanto riguarda la ridondanza, evita di tradurre ogni relazione con una tabella, così da non generare troppe tabelle e quindi ripetere i fatti.

primitivi. Per ottenere questi risultati si basa su due principi:

1. Ogni fact type che ha un UC composto viene mappato in una tabella dedicata
2. I fact type binari con UC su un singolo ruolo vengono raggruppati in un' unica tabella e viene scelta una chiave primaria (tutti quei fact type che hanno ruoli funzionali attaccati allo stesso object type)

Capitolo 3. Relational mapping 45

Esempio di come raggruppare:

• R e A sono i nomi degli entity type che sono stati raggruppati
• a,d è la chiave (UC) della relazione R
• a è la chiave (UC) della relazione A
• L'attributo c è tra parentesi quadre perché non c'è un vincolo di obbligatorietà
• Si usa la chiave esterna (freccia tratteggiata) perché le istanze che compaiono nella relazione R sicuramente sono presenti anche in A

Altro esempio:

Capitolo 3. Relational mapping 46

3.2.1 Traduzione di Relazioni 1:1

Per costruire lo schema relazionale possiamo seguire una procedura che per le relazioni 1:1 si

1. È una relazione 1:1 e uno dei due lati gioca ruoli funzionali, mentre l'altro no: si crea la tavola sull'entity type che gioca altri ruoli e quindi le informazioni su di esso non saranno ripetute nello schema relazionale. Si inserisce l'informazione della relazione 1:1 impostandola come chiave in modo che venga evidenziato il fatto che non può essere ripetuta. Un altro caso simile:
2. È una relazione 1:1 e ciascuna delle estremità della relazione gioca altri ruoli funzionali e rappresenta una tavola: se uno dei due ha il vincolo di obbligatorietà, si raggruppa verso quel lato. Inoltre si impone un vincolo di chiave esterna verso la tavola non senza vincolo di obbligatorietà per indicare che gli elementi devono essere sempre presenti nella sua popolazione.
3. Entrambi i ruoli hanno un vincolo di obbligatorietà nella relazione: si sceglie uno dei due e si impone un vincolo di chiave esterna doppio perché

Capitolo 3. Relational mapping

484. Entrambe le estremità non hanno un vincolo di obbligatorietà, ma sono collegate con altre: vuol dire che ci sono dei null, quindi si raggruppa dal lato che minimizza i null. Nell'esempio è più probabile che una Company abbia un CEO piuttosto che una Person sia un CEO. Nei casi in cui le probabilità siano simili potrei definire una nuova tavola per ridurre i null e poi mettere le chiavi esterne verso le altre.

3.2.2 Traduzione di UC esterni

Quando è presente un UC esterno come chiave primaria nella tavola dello schema relazionale si utilizza l'unione delle chiavi coincolte nel vincolo. Possiamo avere diversi casi:

• UC esterno: come si vede nell'immagine, Employee è identificato dall'unione delle chiavi di Company e EmpId, quindi utilizziamo queste due chiavi come primarie e poi aggiungiamo tutti gli altri attributi degli altri ruoli giocati da Employee.

Relational mapping 49• UC e relazione n:m: in questo caso vanno inserite le chiavi della relazione n:me le chiavi dell’UC esterno

• UC esterno senza reference mode: come si vede nell’immagine il UC ester-no non identifica l’entity type Employee, quindi si traduce normalmente e poi siaggiungono come chiavi non primarie le chiavi coinvolte nell’UC esterno

• UC esterno con relazione n:m: quando c’è un UC esterno collegato ad unarelazione n:m si traduce creando una nuova tavola pre la relazione n:m e si indicala chiave esterna

Capitolo 3. Relational mapping 503.2.3 Traduzione di Oggettificazioni

Per tradurre un’ogettificazione possiamo immaginarla come una black box, ovvero imma-giniamo che la sua chiave primaria sia un simbolo che potrebbe essere composto anche dapiù elementi; nella traduzione utilizziamo questo simbolo come chiave primaria della ta-vola, e, successivamente, traduciamo questo simbolo con tutte le chiavi che compongonol’oggettificazione.

• Oggettificazione normale: Meeting(tuteCode, meetingTime, [roomCode])
• Oggettificazione con relazione n:m e entity type indipendente: Capitolo 3. Relational mapping 513.2.4 Traduzione di Sottotipi
  • Esistono tre modi per tradurre i sottotipi:
  • Assorbimento: i sottotipi vengono assorbiti dal supertipo, potrebbero essere molti campi null
    • Esempio: Capitolo 3. Relational mapping 52
  • Separazione: creo una tavola diversa per ogni sottotipo e una per il supertipo, in questo modo minimizzo il numero di campi null, ma con query complesse potrei avere bisogno di fare join
    • Esempio: Capitolo 3. Relational mapping 53
  • Partizione: se i sottotipi rappresentano tutti gli elementi del supertipo posso