Architetture della Informazione Anno accademico 2009-2010 C. Batini 5 Architetture della Informazione Anno accademico 2009-2010 C. Batini 5.7.2 Metodologie per scegliere la architettura ottima dei dati 1

Modello di ottimizzazione versione 1 Concept: scegliere tra le tante soluzioni EII quella che porta al miglior rapporto costi benefici. Costi: costi a design time + costi a run time + costi di manutenzione Unita’ di misura dei costi  € Benefici: maggiore efficacia informativa, intesa come maggiore efficienza e soprattutto di efficacia dei processi che utilizzano la nuova informazione che possiamo estrarre dalla architettura integrata rispetto alla informazione estraibile dalla architettura attuale Unita’ di misura dei benefici  Δ efficacia processi, misurata come maggiori guadagni economici possibili per il processo  € Ma siccome e’ difficile da modellare, scegliamo 

Modello di ottimizzazione versione 2 Concept: scegliere tra le tante soluzioni EII quella che porta al miglior rapporto costi benefici. Costi: costi a design time + costi a run time + costi di manutenzione Unita’ di misura dei costi  € Benefici: maggiore capacita’ informativa, intesa come maggiore informazione che possiamo estrarre dalla architettura integrata rispetto alla architettura attuale Unita’ di misura dei benefici  Δ Capacita’ informativa Remark: numeratore ( € ) e denominatore (Δ Capacita’ informativa) vanno omogeneizzati!!

On information capacity

Δ information capacity of a schema resulting from the integration of n local schemas The difference between the IC of the integrated schema w.r.t the sum of ICs of the non integrated schemas

Information capacity The concept of information capacity is quite general, as much as is the concept of information. Let’s introduce several definitions, and comment how each one of them catches the intuition

Information capacity 1 - IC1 The number of queries that can be expressed on the schema E3 R34 E4 R131 R132 E1 E2 R12 E5 It is possibile to define more than 1100 type of queries over this schema We do not consider attributes

IC1 – Example - 1 ICA=3+24=27 ICB=2+2=4 Schema B Schema A E1 E2 E3 E3

Δ IC1 – Example E1 E2 E3 ICA=3+24=27 ICAB=4+76=80 E1 E2 E3 E4 ICB=2+2=4 E3 E4 Integrated schema

IC2 – Information capacity considering the actual load Queries in the application load are a subset of all the queries. IC2 considers only cross queries between schemas that enrich actual queries in the application load Furthermore weights can be assigned based on the number of executions of queries

IC2 – Example - 2 Only Q12 has to be considered! E1 E2 E6 Q11 Q12 S1

Application load IC – Example - 2 Local schema 1 AL: 1. E1-E3 2. E3 Local schema 2 AL: 1. E4-E3 Δ Integrated schema AL: E1-E3-E4 E4-E3-E1 E4-E3-E2 Integrated schema

Application load information capacity Per ogni schema e’ in genere noto l’insieme delle queries che costituiscono l’application load. Ogni query viene eseguita un certo numero di volte x e restituisce un certo insieme di tuple t. Possiamo percio’ definire una information capacity dello schema integrato che estende le sole interrogazioni degli application load degli schemi locali che visitano entita’ sulla frontiera.

Observation Until now we have considered only schemas and not values! Moreover …. the world is dirty! Thus……we propose two further definitions

Error free Instance based IC In questa tipologia di capacita’ informativa i cammini delle query vengono pesati sulla base delle istanze delle entita’ collegabili, e si assume che tutte le istanze dei due schemi siano collegabili da join Quindi in questo caso: Detto #Inst(E) il numero di istanze di una entita’ C un cammino E1_R1_..._Rn-1_En #Inst(C) e’ #Inst(E1) * #Inst(R1) * …*#Inst(En) Intuitivamente #Inst(C) e’ il numero di istanze collegabili, assumendo che tutti i join effettuabili siano completi. Capacita’ informativa instance based error free di uno schema SC, e’ la somma di tutti gli #Inst(C) per tutti i cammini dello schema SC.

Error dependent instance based IC In questa tipologia di capacita’ informativa i cammini continuano a essere valutati sulla base del numero di istanze collegabili, ma si tiene conto del fatto che, a seguito di errori o eterogeneita’, non tutte le istanze potrebbero essere riconosciute come identiche e quindi collegabili con un join esatto. Per cui, nel caso di uno schema S risultato della integrazione di due schemi S1 e S2, si assume che: Per ogni coppia di entita’ facenti parte dell’insieme comune {E121, E122, …E12n} sia nota, in quanto misurata, la percentuale di istanze collegabili in join, dove la percentuale puo’ essere compresa tra 0 e 1.

Coming back to Integration cost Building and mantaining a schema is costly. The design cost increases often with an order of O(n2) with the number of sources (due to the correlations existing among sources). The maintenance cost is greater in GAV (since the global mapping has to be changed, so it is O(n) x # of new sources) than in LAV (usually only the local mapping has to be added, so is # of new sources)

Naive algorithm Assumption: the final choice results in one and only one cluster of schemas (this is not the most general choice, we could select n clusters) Given a set of schemas generate the set of all possible subsets of schemas For each subset Si of schemas calculate costs C(Si) and the increment of information capacity IIC(Si) Relate C and IIC using a normalization factor nf Choose the subset Si where [IIC (Si) / nf * C(Si)] is optimal The above algorithm is non polinomial, an improvement may be obtained by branch and bound techniques.

Improvement Use branch and bound operation research techniques

The end