SCHEMA RELAZIONALE 1

Transcript

1 SCHEMA RELAZIONALE 1

2 DIAGRAMMA RELAZIONALE 2

3 Analisi e riconciliazione della sorgente operazionale I concetti principali sono EMPLOYEES, DEPARTMENTS, JOBS e JOB_HISTORY; inoltre cʼè una componente geografica costituita da LOCATIONS, COUNTRIES e REGIONS. Un punto importante da chiarire è la relazione tra il JOB attuale di un EMPLOYEE (FK2 nello schema) e la sua JOB_HISTORY: il JOB attuale di un EMPLOYEE è anche nella JOB_HISTORY? Per rispondere alla domanda, si può far riferimento a 1) Specifiche e requisiti del progetto 2) Dizionario dei dati associati al DBO In assenza di queste informazioni, si possono analizzare i dati presenti nel DBO; il JOB attuale di un EMPLOYEE dovrebbe essere presente in JOB_HISTORY con START_DATE = HIRE_DATE e END_DATE=NULL. Ma se analizziamo lo schema, in JOB_HISTORY END_DATE è in grassetto, ovvero non può essere NULL. Allora si conclude che il JOB attuale di un EMPLOYEE non è nella sua JOB_HISTORY Data Profiling 1) Analisi delle chiavi JOB_TITLE è chiave (alternativa) di JOBS? Tale attributo è NOT NULL (infatti è in grassetto nello schema) quindi occorre controllare solo che sia UNIQUE, controllando che il risultato di questa query sia vuoto SELECT JOB_TITLE FROM JOBS GROUP BY JOB_TITLE HAVING count(*)> 1 Nota : se nello schema lʼattributo JOB_TITLE è già dichiarato come chiave alternativa (cioè come attributo non nullo ed unique ) allora non è necessario fare nessun controllo. Se JOB_TITLE è chiave di JOBS allora determina gli altri attributi JOB_ID, MIN_SALARY e MAX_SALARY. Nella progettazione concettuale del fatto si potrà quindi considerare JOB_TITLE come attributo dimensionale al posto di JOB_ID. Nella progettazione logica, JOB_ID si potrebbe considerare come chiave surrogata della dimension table JOBS. Supponiamo che al termine dellʼanalisi delle chiavi siano state individuate le seguenti chiavi (nelle rispettive tabelle): JOB_TITLE rinominata per semplicità JOB REGION_NAME rinominata per semplicità REGION COUNTRY_NAME rinominata per semplicità COUNTRY DEPARTMENT_NAME rinominata per semplicità DEPARTMENT E tali chiavi verranno utilizzate come attributi dimensionali nello schema di fatto. 3

4 2) Analisi delle dipendenze funzionali (FD) Ricordiamo che le FD esplicitamente dichiarate in uno schema sono quelle derivanti dalle chiavi (ad esempio in COUNTRIES si ha che COUNTRY_NAME à REGION_ID quindi, siccome REGION_ID à REGION_NAME per transitività si ottiene COUNTRY_NAME à REGION_NAME Eʼ interessante analizzare le FD della tabella LOCATIONS. Trascurando POSTAL_CODE e STREET_ADDRESS, che relazione cʼè tra CITY, STATE_PROVINCE a COUNTRY_ID? In base al significato dei termini una CITY è in un STATE_PROVINCE che a sua volta è in una COUNTRY, quindi CITY à STATE_PROVINCE e STATE_PROVINCEà COUNTRY_ID. Per verificare che queste FD siano effettivamente valide sui dati, si effettuano, rispettivamente, le seguenti query: SELECT CITY FROM LOCATIONS GROUP BY CITY HAVING count(distinct STATE_PROVINCE)> 1 SELECT STATE_PROVINCE FROM LOCATIONS GROUP BY STATE_PROVINCE HAVING count(distinct COUNTRY_ID)> 1 Se le query restituiscono vuoto, allora le FD sono rispettate, altrimenti occorre analizzare nel dettaglio i dati. Supponiamo ad esempio che la prima query restituisca solo Reggio Emilia ; questo indica che la FD è valida per le altre città mentre per Reggio Emilia è probabile che ci siano dei dati errati Allora modifico la query per vedere quante STATE_PROVINCE ha Reggio Emilia SELECT STATE_PROVINCE, count(*) FROM LOCATIONS WHERE CITY= Reggio Emilia GROUP BY STATE_PROVINCE Se ottengo Emilia Romagna con count=100 ed Emilia_Romagna con count=2, allora ho trovato lʼerrore e nelle due righe con Emilia_Romagna posso correggere i dati riportando Emilia Romagna. Questo appena discusso è un semplice caso di data cleaning, la cui trattazione esula dagli scopi del nostro corso. Per la tesina, i dati presenti in Adwenture Works non dovrebbero essere sporchi, quindi non è necessaria alcuna azione di data cleaning. 4

5 Una considerazione particolare vale per il valore NULL. Supponiamo che la query SELECT STATE_PROVINCE FROM LOCATIONS GROUP BY STATE_PROVINCE HAVING count(distinct COUNTRY_ID)> 1 Restituisca una sola riga con NULL (ricordiamo che in base allo schema STATE_PROVINCE può assumere il valore NULL): questo indica che la FD STATE_PROVINCE à COUNTRY_ID È verificata, quindi abbiamo la gerarchia Quindi CITY à STATE_PROVINCE à COUNTRY_ID CITY à STATE_PROVINCE à COUNTRY_NAME però si deve considerare anche il caso in cui STATE_PROVINCE sia NULL: Cosa significa STATE_PROVINCE con valore NULL? Può essere un errore, una incompletezza nei dati, però può essere anche un valore significativo, un modo per indicare che per una certa location non è applicabile il concetto di STATE_PROVINCE, cioè ci sono alcune location per le quali è riportata la CITY e il COUNTRY_ID (quindi COUNTRY_NAME) ma non STATE_PROVINCE. Il classico esempio è CITTA DEL VATICANO che è collegata direttamente allo STATO VATICANO senza passare attraverso una STATE_PROVINCE. In questo caso si parla di GERARCHIE INCOMPLETE (argomento ancora da trattare); si suppone che STATE_PROVINCE non presenti valori NULL. 5

6 Reverse engineering: dallo schema logico allo schema ER Il punto di partenza della progettazione concettuale di uno schema di fatto è lo schema ER del DB operazionale, costituito da entità ed associazioni; pertanto, dato lo schema logico del DB operazionale (espresso in termini di key e foreign key) normalmente viene ricavato lo schema ER corrispondente. Dʼaltra parte è possibile effettuare la progettazione concettuale dello schema di fatto partendo direttamente dallo schema logico del DB operazionale. Tuttavia, come si mostrerà nel seguito, ci sono vantaggi di passare prima attraverso lo schema ER, i principali sono seguenti: 1) Avere una rappresentazione più semplice ed efficace dello schema dei dati, in termini di entità ed associazioni tra entità 2) Evidenziare le cardinalità delle associazioni, in particolare distinguendo tra associazioni uno-amolti, uno-a-uno e molti-a-molti La regola più semplice e frequente per ricavare lo schema ER corrispondente è quella che riporta una FOREIGN KEY (che non è chiave o parte di una chiave) dello schema relazionale in unʼassociazione UNO-A-MOLTI dello schema ER. Ad esempio la foreign key REGION_ID di COUNTRIES riferita a REGIONS equivale ad unʼassociazione in cui COUNTRIES partecipa con molteplicità 1 e REGIONS con molteplicità N. Siccome REGION_ID non è dichiarato NOT NULL, cioè può assumere il valore NULL, allora la cardinalità minima di COUNTRIES è 0. Se analizzando i dati reali si vede che in effetti REGION_ID non è mai NULL, allora si mette come cardinalità minima 1. Ricordiamo che a livello di schema di fatto una cardinalità minima 0 corrisponde ad un arco opzionale. Siccome REGION_ID non è chiave (alternativa) di COUNTRIES, REGION_ID può ripetersi in COUNTRIES cioè la cardinalità massima di REGIONS è N. La cardinalità minima di REGIONS non è rilevante e viene generalmente indicata 0; tale cardinalità si potrebbe verificare sui dati ad esempio attraverso il seguente LEFT JOIN: SELECT * FROM REGIONS R LEFT JOIN COUNTRIES C ON (R.REGION_ID=C.REGION_ID) WHERE C.REGION_ID IS NULL Se vuoto allora ogni REGION ha almeno una COUNTRY, quindi cardinalità minima 1. Consideriamo la FK2 MANAGER_ID in DEPARTMENTS; la domanda sorge spontanea: MANAGER_ID è chiave (alternativa) di DEPARTMENTS (cioè non deve ripetersi in DEPARTMENTS, ovvero un MANAGER può dirigere un solo DEPARTMENT) oppure no (cioè può ripetersi in DEPARTMENTS, ovvero un MANAGER può dirigere più DEPARTMENT) Si effettua il controllo e si decide. SELECT MANAGER_ID FROM DEPARTMENTS GROUP BY MANAGER_ID HAVING count(*)> 1 6

7 Se MANAGER_ID è chiave allora lʼassociazione della FK2 tra DEPARTMENTS e EMPLOYEES è di tipo uno-a-uno e come tale deve essere trattata a livello di progetto concettuale del fatto: la soluzione normalmente adottata è quella di considerare lʼemployee MANAGER del DEPARTMENT come un attributo descrittivo di DEPARTMENT (pag 23 di Se MANAGER_ID non è chiave allora lʼassociazione della FK2 tra DEPARTMENTS e EMPLOYEES è di tipo uno-a-molti: in questo caso si ricade in una gerarchia ricorsiva (argomento ancora da trattare) in quanto un DEPARTMENT ha un EMPLOYEE MANAGER, ma lʼemployee ha a sua volta il DEPARTMENT, e cosi via, ricorsivamente. Lʼultimo caso da considerare è quello in cui la FOREIGN KEY è parte di una chiave, come nel caso di JOB_HISTORY, in cui EMPLOYEE_ID è foreign key riferita ad EMPLOYEE: a livello di schema ER, lʼentità JOB_HISTORY ha EMPLOYEE come componente del suo identificatore, costituito da.{ EMPLOYEE, START_DATE}. Di seguito viene riportato lo schema ER, limitatamente alle associazioni e agli attributi principali (discussi in precedenza). 7

8 Nello schema ER non sono riportate le FD relative alla LOCATION, cioè FD2: CITY à STATE_PROVINCE FD3: STATE_PROVINCE à COUNTRY Tali dipendenze verranno prese in considerazione direttamente nella costruzione dello schema di fatto (durante la fase di editing dellʼalbero degli attributi). 8

9 SCELTA DEL FATTO E PROGETTAZIONE CONCETTUALE Il fatto dovrebbe essere unʼassociazione n-aria, cioè unʼassociazione molti-a-molti, tra le dimensioni. Inoltre tale associazione dovrebbe variare rispetto al tempo, cioè dovrebbe avere almeno una componente temporale. JOB_HISTORY è unʼassociazione n-aria (nello schema ER ottenuto, tale associazione è espressa in forma reificata) tra i seguenti concetti EMPLOYEE START_DATE END_DATE JOB DEPARTMENT (denominata OLD_DEPARTMENT per distinguerla dal DEPARTMENT dellʼemployee) 9

10 10

11 Schema di Fatto; Non sono riportate le gerarchie ricorsive; Alcuni attributi sono stati omessi (quale ad esempio SALARY di EMPLOYEE) 11

12 Condivisione su JOB : ci sono due concetti di JOB, quello di JOB_HISTORY (corrispondete alla dimensione JOB) e quello (attuale) di EMPLOYEE. Condivisione su DEPARTMENT: ci sono due concetti di DEPARTMENT, quello di JOB_HISTORY (corrispondete alla dimensione OLD_DEPARTMENT) e quello (attuale) di EMPLOYEE. 12