Regole di join

Reperimento informazioni significative

L'ambito in cui e' opportuno definire le Regole di join e' quello di un'unica classe globale. Non ha senso cercare di formulare delle regole di fusione tra classi sorgenti appartenenti a diverse classi globali, in quanto, per come queste ultime sono costruite, non hanno entita' in comune.
Anticipo subito che l'intervento del progettista e' necessario nella delineazione di queste regole, pero' e' possibile isolare alcune situazioni in cui questo intervento e' superfluo e quindi si puo' procedere in automatico.
Le regole di join permettono appunto di isolare i casi in cui il join e' automatico, e di stabilire quali siano i campi semanticamente significativi nell'identificazione delle entita' che rendono il join corretto.
Nella individuazione dell Regole di join si e' fatto uso delle seguenti informazioni semanticamente significative:

  1. relazioni di SYN presenti nel Common Thesaurus;
  2. relazioni BT, NT presenti nel Common Thesaurus e che portano alla definizione di un unico attributo globale nella classe globale (es. name e first_name, last_name);
  3. legame tra attributi globali e attributi locali, presente nella Mapping Table;
  4. assiomi estensionali definiti dal progettista sulla base di conoscenze a priori (e relazioni isa);
  5. selezione tra i campi delle classi locali di quelli definiti chiave.

Per quanto concerne i punti 1,2,3 e' evidente che concorrono a definire attributi locali che corrispondono ad un medesimo attributo globale.
Per quanto concerne il punto 5 le situazioni che si possono presentare sono tre:


Regole di join

Chiavi semanticamente omogenee

  1. Sulle due classi locali e' definito un assioma di equivalenza, oppure di inclusione. Allora e' possibile usare gli attributi globali corrispondenti alle due chiavi come campo significativo per effettuare il join.

  2. Due classi fanno parte della stessa classe globale, ma su di esse non e' definito alcun assioma estensionale. Allora e' necessario ricercare se su di esse non vi sia una relazione estensionale di inclusione o di equivalenza implicita. Se cosi'si ricade nel caso precedente.
    Se non si trova alcuna relazione estensionale neanche implicita allora, per come sono definite le classi globale, tra le due classi locali vi e' una relazione di sovrapposizione. In questo caso non si puo' procedere automaticamente all'unificazione: e' necessaria una validazione delle chiavi da parte del progettista.
    Se nella ricerca viene ritrovata una relazione di disgiunzione implicita si procede come al punto seguente.

  3. Tra le due classi e' definito un assioma di disgiunzione, allora non ha senso cercare una via per effettuare il join.



Chiavi semanticamente disomogenee

  1. Tra le due classi e' definito un assioma di inclusione(o viene ricavata una relazione di inclusione rimasta implicita): la classe A "contiene" tutte le entita' della classe B piu' altre proprie. Nella classe B, tra i campi non definiti chiave, vi e' un campo SYN del campo chiave di A (o due o piu' campi legati da una relazione NT, BT con il campo chiave di A).
    Allora questo campo puo' essere visto come chiave alternativa, ed essere sfruttato per effettuare il join.
    Non vale il viceversa. In questo caso e qualora non si reperisca nessun legame implicito tra i campi significativi delle classi, e' necessaria la definizione esplicita di questo legame da parte del progettista.
    Nel caso particolare di chiave composta se la chiave della classe piu' grande e' contenuta nella chiave dell'altra classe allora si gli attributi di join sono quelli corrispondenti alla prima classe.

  2. Tra le due classi e' definito un assioma di equivalenza (oppure vi e' una relazione di equivalenza implicita) e in una delle due classi vi e' un campo non definito chiave, "sinonimo" della chiave dell'altra classe.
    Allora si puo' procedere al join sfruttando quest'attributo.
    Analogamente a quanto visto nel caso di inclusione, se la chiave di una delle classi coinvolte e' contenuta nella chiave dell'altra, allora la prima puo' essere selezionata come attributo di join.
    Se non si verifica questa situazione e' necessaria l'esplicitazione della via per effettuare il join da parte del progettista.

  3. Due classi implicitamente sovrapposte per l'appartenenza alla medesima classe globale, necessitano la definizione esplicita da parte del progettista di un legame tra i campi significativi per effettuare il join.

  4. tra le due classi locali e' definito un assioma di disgiunzione, quindi non ha senso cercare una via per effettuare il join.



Assenza di chiavi

L'assenza di campi chiave puo' interessare solo una o entrambe le classi locali coinvolte. Infatti se e solo se si ha a che fare con classi appartenenti ad una sorgente di tipo relazionale la presenza di almeno una chiave e' garantito. I casi che si possono presentare sono i seguenti:
  1. Se tra le due classi e' definito (esplicitamente o implicitamente) un assioma di equivalenza e una delle due classi e' sprovvista di chiave allora si ricerca tra i campi della classe sprovvista se ne esiste uno che corrisponde all'attributo globale "chiave" dell'altra classe. Se e' presente si e' praticamente trovato il campo chiave della classe sprovvista e questo campo e' quello da utilizzare per il join.
    Nel caso sfortunato in cui questo campo non ci sia o entrambe le classi siano senza chiave, e' necessario l'intervento del progettista.
  2. Se tra le due classi e' definito (esplicitamente o implicitamente) un assioma di inclusione e una delle due classi e' privo di chiave e' necessaria una ricerca analoga a quella effettuata per le chiavi disomogenee nella medesima situazione estensionale. Infatti se la classe senza chiave e' quella inclusa, bisogna cercare tra i suoi campi se ve ne e' uno corrispondente all'attributo globale "chiave" dell'altra classe.Se esiste e' l'attributo su cui effettuare il join. Non vale il viceversa, in cui, come nel caso di assenza di chiavi e' necessario l'intervento del progettista.
  3. In caso di sovrapposizione e' necessario l'intervento del progettista.
  4. In caso di assiomi di disgiunzione non vi e' necessita' di effettuare il join.

Algoritmo


Una volta individuati i campi significativi per il riconoscimento di istanze facenti riferimanto alla medesima entita' del mondo reale, l'operazione di join non e' pero' immediata.
E' infatti necessario stabilire delle funzioni (ovviamnte sara' compito del progettista) che permettano di eguagliare o perlomeno legare questi attributi identificativi.
Nel caso di chiavi disomogenee la necessita' di questa funzione appare ovvia. Pero' ve ne e' necessita' anche nel caso di chiavi omogenee, basta osservare il seguente esempio.
Una persona puo' essere identificata univocamente dal proprio numero di telefono.In una sorgente il numero, contenuto nel campo telefono, viene rappresentato come (059)909090; in un'altra sorgente lo stesso numero, contenuto nel campo num_tel, viene rappresentato come +059.909090.
Appare evidente la necessita' di portare i due numeri ad una forma canonica che permetta di eguagliarli.