A.A. 2017-18 Architetture di data integration
Eterogeneità e corrispondenze (guardare anche gli appunti a mano) Una base di dati rappresenta classi di atomic individuals del mondo reale (che chiameremo concetti della bd nel seguito) tramite lo schema logico o concettuale Esempio una entità nel modello ER, uno schema di relazione nel modello relazionale Singoli individuals del mondo reale (che chiameremo oggetti della bd nel seguito) tramite la istanza Esempio una tupla nel modello relazionale
Classes, individuals, concepts, objects Real world Class of individuals Individuals Data base Concepts Objects
Eterogeneità e corrispondenze Date due basi di dati bd1 e bd2, una eterogeneità tra due oggetti o1 in bd1 e o2 in bd2 o concetti c1 in bd1 e c2 in bd2 delle due basi di dati una differenza di rappresentazione nel modello adottato per gli oggetti o concetti Es un oggetto data (es. 3 settembre 2015) rappresentata con tre valori distinti in una tabella relazionale e un valore in un’altra Es il mio nome rappresentato come Crlo in bd1 e Carlo in bd2 Una eterogeneità tra due oggetti o concetti porta a evidenziare una corrispondenza tra i due oggetti o concetti in bd1 e bd2. La individuazione delle eterogeneità e corrispondenze è aspetto fondamentale della schema integration e della data integration
Types of heterogeneities - 1 DBMS level all the characteristics of the two DBMSs Model DDL DML Acid
Types of heterogeneities - 2 2. Schema level semantic heterogeneties between two concepts, relevant in schema integration - Names of concepts Homonimies – same names of concepts for classes (of individuals), different classes e.g. Student for university students and secondry school students Sinonimies – different names of concepts for classes, same classes e.g. Student and Pupil - Types of concepts (model dependent, e.g. Relational, ER) Pairs of attributes ≠ definition domains D(attr1) ≠ D(attr2) D(attr1) included in D(attr2) ≠ granularities (1-10), (11 – 20) vs (1 – 5), (6 – 10) etc. - Pairs of concepts ≠ types e.g. Attribute vs Entity e.g. Date as attributes vs Date as Entity ≠ cardinalities between two relationships ≠ identifiers (ER) or keys (Relational)
Types of heterogeneities - 3 3. Instance level semantic heterogeneities between two objects, relevant in data integration - Conflicting sets of objects for the same concept - Conflicting values for attributes of the same object (e.g. Crlo vs Carlo for Name) 4. Instance quality level of objects for the same concept ≠ accuracy ≠ completeness ≠ currency ≠ consistency
Types of schema correspondences (not exhaustive!) Stud - Between concepts Same Different Is-a 2. Between names of concepts Hyperonimies (e.g. Professor is-a Person) 3. Between types of concepts - Pairs of attributes Functional relationshps ( e.g. number of hours vs number of credits for the lessons of a course) - Pairs of concepts Aggregation relationships (e.g. soccer team vs soccer player) - Relations in the relational model Referential integrity Schema2 Stud Med Schema1
Riassumendo Nella integrazione di BD si distinguono due attività Schema integration Data integration 2. In entrambe dobbiamo confrontare le due BD per individuare le eterogeneità tra coppie di concetti/istanze 3. Questo passo di progettazione è chiamato comparison 4. Le eterogeneità sono risolte con due tipi di azioni
Azioni per risolvere le eterogenetià Eventuale modifica di uno dei due concetti Ad esempio in questo caso se sono sinonimi, Stud può essere modificato in Stud Med 2. Intoduzione di una corrispondenza interschema Stud Med Stud Stud Med Stud Med Stud Schema2 Stud Med Schema1
Esercizio Abbiamo due basi dati con schemi S1: ProfItaliani (N,S,DoBirth,CityofBirth) con 10.000 professori S2: ProfEuropei (N,S,DoB, Country) con 100.000 professori in cui si assuma che l'istanza di S2 contenga anche i prof italiani e, inoltre, si assume di non sapere se i due insiemi di prof italiani coincidano o meno. Dovete allora definire uno schema globale e la sua rappresentazione tramite la istruzione SQL View coerente con l'approccio Global as View (schema globale espresso in termini degli schemi locali) Inoltre dovete scrivere in SQL la query "Trovare nomi, cognomi, country, data di nascita dei professori non italiani nati dopo il 10/05/1980", assumete che ci siano circa 10.00 professori che ricadono in questa tipologia Dovete infine a. produrre una versione della interrogazione che ottimizza il query tree arricchito con le operazioni di trasferimento, cioè ottimizza i costi dei blocchi oggetto di trasferimento tra msecondaria e centrale + costi di trasferimento tra wrappers e mediatore. b. confrontarla, in termini di costi, con la corrispondente interrogazione prodotta con l'unfolding