_______________________________________________________SURROGATE KEY

SURROGATE KEY

SURROGATE KEY
Documento Interno

Documento: 52244934.doc
Edizione:1.0
Data: 31 ottobre 20022
INDICE

1 COSA SONO..................................................................................2

2 VANTAGGI E SVANTAGGI RISPETTO ALLE CHIAVI NATURALI (NK)......2

2.1 PERFORMANCE......................................................................................................................................................4
2.2 SPAZIO DI MEMORIA............................................................................................................................................4
3 COME SI CREANO..........................................................................4
3.1 ANNOTAZIONI........................................................................................................................................................4
3.2 I PASSI DA SEGUIRE..............................................................................................................................................5
3.2.1 SK per le Tabelle Dimensionali.........................................................................................................................5
3.2.2 SK per le Fact....................................................................................................................................................9
4 SLOWLY CHANGING DIMENSIONS (SCD)........................................12
4.1 TECNICHE PER TRATTARE SCD.......................................................................................................................12
4.1.1 TECNICA 1......................................................................................................................................................12
4.1.2 TECNICA 2......................................................................................................................................................13
4.1.3 TECNICA 3......................................................................................................................................................14
4.1.4 SCELTA DI UNA TECNICA............................................................................................................................15
5 ES. CODICE SQLSERVER 2000.......................................................15

6 RIFERIMENTI & APPROFONDIMENTI..............................................15

2
1 COSA SONO

Legenda documento:

K Chiave
PK Chiave Primaria
FK Chiave Secondaria
SK Chiave Surrogata
NK Chiave Naturale (o intelligente)
SA Staging Area
DW Data Warehouse
v Vantaggio
sv Svantaggio

SK= K sintetica o artificiale usata come sostituto di una NK.

In realtà in un DW è molto più di un sostituto: è una necessaria
generalizzazione della rappresentazione di una NK ed è uno degli elementi
basilari in un buon disegno DW.
“Ogni join tra Tab. Dimensionali e Fact dovrebbe essere basato su SK e non su
NK”
Finora è la logica ETL che sistematicamente migliora e rimpiazza la NK dei
record (dim.li e fact) entranti nel DW.
Una SK non è una chiave derivata direttamente dai dati di ingresso ma è un
semplice intero “anonimo” che assume valori da 1 fino al massimo intero del
quale si ha bisogno.
Questo tipo di chiave non sarà mai:
- “esplicita”, dove si può capire qualcosa sul record solo guardando la K;
- “composta” da chiavi naturali unite assieme;
- “implementata” come join paralleli multipli tra Dim. e Fact (i cosiddetti join
doppi o tripli)

2 VANTAGGI E SVANTAGGI RISPETTO ALLE CHIAVI

NATURALI (NK)

sv (NK) = le PK sono difficili da modificare.

Ogni volta che una PK cambia in valore, oppure sono aggiunte o
eliminate colonne dalla PK si scatena un effetto a cascata sulle relazioni
con le FK. Le NK soffrono di questo problema perché non solo sono
usate come PK e FK, ma hanno associata “informazione di business”:
quando cambia tale informazione, così fa anche il valore o la struttura
della PK, con tutti i problemi che ne conseguono.

v (SK) = sono facili da modificare.

Non hanno i problemi delle NK perché non hanno necessità di cambiare.

2
 Ad esse non è associata nessuna informazione di business, quindi né il
valore né la struttura devono essere modificate se cambia tale
informazione.
Le colonne di business che erano usate come porzioni di PK (NK)
diventano ora semplici colonne di dati che possono essere modificate,
aggiunte o eliminate con facilità. L’unicità dei valori di queste colonne di
business può ancora essere garantita dall’utilizzo di indici secondari.

v (NK) = è chiaro cosa rappresentano. Le applicazioni tradizionali nascondono

l’esistenza delle SK all’UT finale, ma tools database ad hoc non lo
possono fare: l’UT deve sapere che queste colonne esistono e come si
usano per codificare i join. In molti casi ad hoc, query che usano SK in
realtà richiedono più join perché ci sono meno colonne in cascata da
una tab all’altra.

ES:

caso NK caso SK
CLIENTI CLIENTI
PK PK
NUM C1 C2 C3 C4 CLI NUM C1 C2 C3 C4
CLI SK CLI
ID_1 1 ID_1
ID_2 2 ID_2
ID_3 3 ID_3

ORDINI ORDINI
PK PK
NUM DATA B1 B2 B3 ORD CLI DATA B1 B2 B3
CLI ORD SK SK ORD
(FK) (FK)
ID_1 0103 1 1 0103
02 02
ID_1 0203 2 1 0203
02 02
ID_1 0803 3 1 0803
02 02
ID_2 0106 4 2 0106
02 02
ID_2 0206 5 2 0206
02 02
ID_3 0909 6 3 0909
02 02
NB: CLI SK non fa più parte della chiave

Se eseguo una query del tipo “Tutti i NUM CLI e le loro DATA ORD” mentre nel
caso NK interrogo la sola Tab. ORDINI, nel caso SK devo interrogare sia la
Tab. ORDINI che la Tab. CLIENTI.
La situazione è dannosa anche quando all’UT è permesso inserire nuove righe
con tools ad hoc. Non solo è richiesta la comprensione delle colonne SK, ma in
qualche modo i nuovi valori devono essere generati.

3
2.1 PERFORMANCE
Può differire tra le due tecniche:
una indagine su una singola colonna SK può essere più veloce che su .una
multicolonna NK. D’altra parte, un semplice incremento della SK può causare
problemi di contesa indici che non si trovano con una distribuzione random
delle NK.
Quando vengono usate PK SK potrebbero essere richiesti indici extra sulle
colone di business che erano usate come parti di PK NK; questi indici possono
essere necessari per mantenere l’unicità e soddisfare query ed essi possono
fare aggiornamenti più lenti.
Gli statement SQL sono differenti tra le due tecniche:
da una parte è più facile collegare tab con SK perché coinvolgono una sola
colonna, dall’altra è stato notato che le più veloci SK possono aumentare il
numero di join (perché le colonne di business dalle Tab padre non sono ripetute
nelle Tab figlie). In altre parole, potrebbero esserci meno join quando si usano
le NK (o K intelligenti), ma potrebbe essere più difficile codificarli perché
coinvolgono un maggior numero di colonne.

v (SK) = con le SK è possibile codificare la cosiddetta “conoscenza incerta”.

Ad es., se si deve sostituire una K cliente per rappresentare una
transazione, ma non si conosce con certezza qual è il cliente (situazione
comune quando le transazioni sono anonime, come ad es. i pagamenti)
ci si chiede :<<Qual è la chiave dei clienti anonimi?>>. In questi casi
viene introdotta una chiave speciale per questi clienti anonimi (questa è
una politica riferita come “hack”).

2.2 SPAZIO DI MEMORIA

Con le SK valorizzate con numeri interi si riesce a risparmiare parecchio spazio
di memoria.
Se si ha una FACT con un 109 righe  ogni Byte in ogni riga è 1 GB (1*10 9) di
spazio di memoria occupato.
Con chiavi intere su 4 Byte (come le SK) si possono rappresentare più di
2*109 valori differenti (da 1 a µ 2.147.483.647) e questo è abbastanza anche
per le cosiddette “monster dimension”. Quindi, comprimendo tutte le nostre NK
(“trasformandole” cioè in SK) su chiavi a 4 Byte il risparmio di spazio è
notevole.

3 COME SI CREANO

Fondamentalmente, ogni volta che vediamo una NK nel flusso di dati

entrante, noi dobbiamo riferire (Tabelle di lookup) il valore corretto
della SK e rimpiazzare la NK con la SK. Perché questo sia un passo
significativo (nella SA) della fase ETL si devono affinare le tecniche
per rendere gli accessi alle Tab di lookup semplici e veloci..

3.1 ANNOTAZIONI

4
- Ogni join key tra Dim e Fact dovrebbe essere fatto con SK o interi anonimi,
non con NK o smart key;
- Fare le SK assegnando 1 alla prima istanza della k, 2 alla seconda, ……..;
- E’ impossibile dire una qualunque cosa sul valore o il contesto del record
dimensionale solo guardando il valore della SK;
- Tutte le SK sono interi 4-Byte (e per piccole dimensioni interi 2-Byte)

3.2 I PASSI DA SEGUIRE

3.2.1. SK per le Tabelle Dimensionali
3.2.2. SK per le Fact

3.2.1 SK per le Tabelle Dimensionali

Per la creazione delle K per le Tab Dim.li dobbiamo distinguere
1.a) caricamento la prima volta;
1.b) caricamento le volte successive alla prima.
1.a) probabilmente viene creata una Tab Dim.le con esattamente lo stesso
numero di rec dei dati di produzione entranti. Assumiamo che i dati in ingresso
siano “puliti”, validi e che non ci sia bisogno di duplicare dati. Con questa
assunzione semplicemente assegniamo numeri sequenziali alle SK man mano
che si carica la Dim. Questo semplice processo consiste nella lettura
sequenziale dei dati entranti:

5
 Schema 1.a : Primo caricamento di una Tab. dim.le

Insieme originale
completo dei
record Dim.li

PROD_KEY Generatore di SK
DESC_PROD (partendo da 1)
CATEGORY
SIZE
….

Insieme originale
dei record Dim.li
caricabili

NOTA: la PROD_KEY SURR_KEY

originale è divenuta un PROD_KEY
attributo della tab (non DESC_PROD Caricamento sul DB
è più chiave) CATEGORY
SIZE
….

1.b) dalla seconda volta in poi, quando si leggono i dati di produzione che
definiscono la Dim, si devono prendere alcune complicate decisioni:

- la più facile: riconoscere nuovi record che sono stati aggiunti alla Dim nel
sistema di produzione e assegnati a nuove K produzione. Immaginiamo, per
semplicità, che il dato di produzione sia un singolo campo, pulito, ben
mantenuto chiamato PROD_KEY (le stesse considerazioni si possono fare se
l’unicità dei record della Dim. Prod è definita da due differenti campi).
Ogni volta che estrai informazioni dalla Dim. Prod si deve controllare che
tutte le K prodotto non esistano già. Concettualmente basterebbe guardare
nella Tab Dim.le del W dove la K prodotto è memorizzata come campo
ordinario. Invece, conviene avere una Tab di Lookup separata, piuttosto
che usare la reale Tab. Dim.le del W.

- più difficile: se la K esiste già ma alcuni attributi del record sono

legittimamente cambiati  SCD
Es. un CLI ha lo stesso ID_CLI ma è cambiato il suo STATO CIVILE
(celibe/nubile -> coniugato)
SCD » se in una Dim cambia qualche campo descrittivo
allora se il cambiamento è di tipo 1
allora il record viene sovrascritto
se il cambiamento è di tipo 2

6
 allora viene aggiunto un nuovo record al DW

NOTA: Per maggiori dettagli su SLOWLY CHANGING DIMENSIONS si rimanda al

paragrafo 4 (SCD).
E’ la politica SCD (implementata nella struttura e nella logica ETL del DW) che identifica quali
campi sono sovrascritti o aggiunti.

Come accennato sopra, il metodo più veloce per scoprire se una K esiste già è
avere una speciale Tab di Lookup per le PROD_ KEY precedentemente
riconosciute, preferibilmente ordinate ed indicizzate per un riferimneto il più
veloce possibile.

PROD_KEY CURRENT_SURR_KEY
PROD02HE77 2235
PROD02GF23 5468
PROD02HL18 6221
…

Questa Tab di Lookup ha meno righe della Tab. Dim.le, perché ha una sola
riga per ogni PROD_KEY riconosciuta, e contiene la SK usata più di recente con
quella PROD_KEY.

Ogni mattina sono processati i dati entranti nella Dim Prod per vedere se la
PROD_KEY esiste già o meno:

NON - se tengo traccia del Max Val assunto precedentemente dalla SK

ESIST  in questa Dim
E allora NEW VAL = OLD VAL +1
- creo un NUOVO RECORD
ESIST - dalla Tab Lookup prendo la SK associata alla PROD_KEY e la uso
E GIA’ per ottenere il più grande valore corrente del record
dimensionale nel DW
 - confronto il record esistente con quello entrante (campo per
campo)
se matchano tutti
allora non si ha SCD e si può passare al successivo rec in
input
se uno o più campi sono cambiati
allora con al politica SCD si deide se sovrascrivere il record o
crearne uno nuovo (NB: se si crea un nuovo rec allora
bisogna aggiornare la tab di lookup perché ora si ha una
SK più recente associata a quella PROD_KEY)

7
 Schema 1.b : Refresh di una Tab. dim.le dopo il primo caricamento

Record Record
dim.le dim.le
esistente entrante

Tab. di Lookup
(PROD_KEY↔SK)

la PROD_KEY NO
esiste già?

New SK = Old SK +1
SI

CONFRONTO Prendo la
(campo x CURRENT_SURR_KEY
campo) Creo un nuovo record

Politica SCD per

decidere la strategia AGGIUNGO
di update un nuovo record dim.le
Tipo 2
(con una nuova SK)

Tipo 1

SOVRASCRIVO CARICO
il record sul DB il record sul DB

8
3.2.2 SK per le Fact
Per ogni record in ingresso nella Fact:
- si prende la PROD_KEY dimensionale (nel record della Fact)
- si rimpiazza con la corretta SK corrente
Nota 1: nel record della Fact non si mantiene il valore della PROD_KEY; tale
valore lo si può comunque continuare a trovare nel record associato nella
Tab dim.le
Nota 2: se le componenti la K PROD sono 4-12, alllora sono necessarie 4-12
Tab. di Lookup per ricavare la giusta SK
- si carica il record sul DB.

PASSI ALGORITMO

Time key
Record della Fact Rimpiazzo Lookup corrente
1
con gli ID PROD TIME_ID
con la SK
TIME_ID
TIME_ID TIME_KEY
TIME_KEY
PROD_ID
STORE_ID 2
PROMOTION_ID
$_SALES
Prod key
UNIT_SALES
Rimpiazzo Lookup corrente
$_COST
… PROD_ID
con la SK PROD_ID
PROD _KEY PROD_KEY

Store key
Lookup corrente
Rimpiazzo
STORE_ID
con la SK STORE_ID
STORE _KEY STORE_KEY

4
Promotion key
Lookup corrente
Record della Fact con 5 Rimpiazzo
gli ID PROD PROMOTION_ID PROMOTION_ID
con la SK PROMOTION_KEY
TIME_KEY PROMOTION _KEY
PROD_ KEY
STORE_ KEY
PROMOTION_ KEY
$_SALES
UNIT_SALES
$_COST
…

6
CARICAMENTO dei
record sul DB
9
Metodo veloce
Far scorrere tutti i record in input seguendo (in multithread) tutti i passi
dell’algoritmo.

NOTA 1 (multithread) :
- rec 1 al 1° passo (subito si accoda il rec 2)
- rec 1 al 2° passo (e rec 2 al 1° )
- e così via.
Affinchè tutto avvenga velocemente, ogni rec devono seguire tutti i
passi e “volare” sulla memoria, senza essere scritto sul disco fino alla
fine.

NOTA 2 (Tab. di Lookup) :

Se possibile, tutte le Tab. di Lookup richieste dovrebbero essere
racchiuse in memoria così da poter essere accedute in modo random
ogni volta che un rec-fact presenta le sue PROD_KEY. E’ questa una
delle ragioni per cui conviene tenere le Tab. di Lookup separate dalle
Tab. Dim.li del DW.
ES: Supponiamo di avere una Tab. di Lookup con un milione di righe per
una Dim,
(PROD_KEY di 20 Byte; SK di 4 Byte)  (20+4)*106 B ≈ 24 MB di RAM
per mantenere le Tab. di Lookup.
OSS: In un ambiente in cui è possibile
configurare una macchina di Staging
con 256 MB (o più) di RAM, si
dovrebbe riuscire a tenere tutte le
Tab. di Lookup in memoria.

NOTA 3 (Grandi Dimensioni) :

Se si utilizza una grossa dimensione (decine di milioni di record) è
ancora possibile disegnare un efficace sistema a SK veloce (come quello
mostrato sopra) e persino la Tab. di Lookup della “monster dimension”
deve essere letta “out of disk”.
CONSIGLIO: preordinare i dati entranti nella Fact e la Tab. di Lookup
secondo la PROD_KEY; ora il rimpiazzamento della SK è un singolo passo
sort-merge tra due file.
NB: se le “monster dimension” sono due allora hai bisogno di un
consulente!

CONCLUSIONI

Un buon sistema a SK:

- riduce lo spazio nelle grandi e dispendiose Fact;
- si adatta potenzialmente a grandi “sorprese” come fusioni o acquisizioni;
- ha un meccanismo flessibile per il trattamento dello SCD;
10
- rappresenta i legittimi “stati di incertezza” per i quali non esistono NK.

11
4 SLOWLY CHANGING DIMENSIONS (SCD)

Risolve il problema di descrivere accuratamente il passato (la storia) in un

DW.

ES. 1
“Una Dim. Prodotto in cui la descrizione dettagliata di un dato prodotto viene
occasionalmente aggiornata”
La modifica può riguardare un particolare così piccolo che la produzione non
assegna il prodotto ad un nuovo SKU (quello che il DW sta usando come PK
della Dim. Prod), ma tuttavia dà al team_DW la descrizione di prodotto corrente
(modificata). Quando questo accade il team_DW si trova di fronte a un
dilemma: se il DW deve tenere traccia sia della OLD che della NEW descrizione
come devono essere usate le chiavi? E dove mettere i due valori degli attributi
cambiati?

ES. 2
“Nomi dei settori e dei distretti di un Sistema di Vendite”.
Ogni società che ha un sistema di vendite è facile che riassegni nomi di settori
e distretti ogni 1-2 anni.

4.1 TECNICHE PER TRATTARE SCD

1. Sovrascrittura
2. Creazione di un nuovo record dimensionale
3. Creazione di un campo “valore corrente”

Ogni tecnica risolve il problema in modo differente.

La scelta della tecnica dipende da ciò di cui ha bisogno l’UT.

4.1.1 TECNICA 1
- la più semplice
- la più veloce
- ma non permette di tenere traccia della storia
Tuttavia è usata molta frequentemente quando il team_DW decide
legittimamente che il vecchio valore degli attributi dimensionali cambiati non è
interessante.

12
4.1.2 TECNICA 2
- è molto comune
- ha molti vantaggi
ES. lo schema DW è quello di una società di spedizioni (per una società
manifatturiera) in cui la Dim. Prod è una delle più importanti

Dim PERIODO

TIME_KEY
Dim PROD

PROD_KEY …
DESC
TIPO
CATEGORIA Fact VENDITE Dim SHIP_TO
SKU#
PKG_TYPE TIME_KEY SHIP_TO_KEY
PROD_KEY
… SHIP_TO_KEY
SHIP_MADE_KEY …
SHIP_FROM_KEY
QTA VENDUTA
LINEITEM_VALUE
Dim SHIP_MADE
…
SHIP_MADE_KEY

Dim SHIP_FROM

SHIP_FROM_KEY

Una buona Dim. Prodotto in un Sistema Vendite dovrebbe avere almeno una
cinquantina di attributi che descrivono i prodotti, includendo attributi gerarchici
(es: tipo, categoria) e non (es: tipo di confezione). Un importante attributo
previsto dalle operazioni manifatturiere è il numero SKU assegnato al prodotto.
Iniziamo usando SKU come chiave della Tab. Dim.le Prodotto.
ES. Immaginiamo che avvenga un piccolo cambiamento nel packaging del
SKU#38: la desc del packaging passa da “glued box” a “pasted box”
(incollato). La modifica è così piccola che si decide di non cambiare il numero
SKU del prodotto, o il codice a barre (UPC) stampato sulla scatola.
Se sul DW si vuole comunque tenere traccia della modifica, la soluzione
migliore è creare un nuovo record come se la versione “pasted box”
identificasse un nuovo tipo di prodotto. L’unica differenza tra i due record è la
descrizione del packaging (i numeri SKU sono gli stessi) il solo modo per
13
creare un nuovo record è generalizzare la K della Tab. Dim.le Prodotto ad
essere qualcosa di più del numero SKU. Ad es SKU potrebbe essere SKU+(2 o 3
cifre per indicare la versione)
SKU#38+01 (versione “glued box”)
SKU#38+02 (versione “pasted box”)
Nota che probabilmente dovrai posizionare SKU# in un attributo (campo)
separato della dimensione (vedi la Dim. PROD dello schema sopra) per non
dover obbligare l’applicazione a spezzare la chiave per ricavare l’SKU#

OSSERVAZIONI:
- questa tecnica per SCD è molto potente (perché i nuovi record dimensionali
tracciano automaticamente la storia nella Fact)
- la vecchia versione del record dim.le punta a tutta la storia nella Fact
precedente al cambiamento
- la nuova versione del record dim.le punta a tutta la storia dopo il
cambiamento
- non c’è nessun bisogno di un timestamp nella Tab. Prod per registrare il
cambiamento. Infatti, un timestamp in un record dimensionale potrebbe non
avere senso perché l’evento di interesse è l’utilizzo attuale del nuovo tipo di
prodotto in una vendita. Questa è la miglior registrazione di un record-Fact
con la nuova corretta key Prod.
- Altro vantaggio: si possono tracciare quanti cambiamenti si vogliono per
ogni item dim.le: ogni cambiamento genera un nuovo record e ogni record
traccia perfettamente la storia.
- Svantaggi:
- necessità di generalizzare le K dim.li
- aumento della Tab. dim.le stessa.

4.1.3 TECNICA 3

Si usa quando si vuol tracciare il cambiamento in un valore dimensionale ma è

legittimo usare il vecchio valore sia prima che dopo il cambiamento.

Ad es, capita spesso nei casi di riallineamento delle vendite dove, nonostante
tu abbia cambiato il nome delle tue regioni di vendita, hai ancora bisogno dello
stato odierno delle vendite nelle regioni “di ieri”, proprio per vedere come
sarebbe stato con la vecchia organizzazione. Si può affrontare ciò non creando
un nuovo record dim.le (come nella Tecnica 2), bensì creando un nuovo campo
contenente il “valore corrente”.

ES: In un Sistema Vendite un team viene riassegnato a delle regioni

“rinominate”
- partendo dal campo Region
- viene creato il nuovo campo Current_Region
- e viene rinominato region in Previous_Region

Dim SALES Dim SALES TEAM

14
 TEAM
Sales_Team_Ke Sales_Team_Ke
y y
Team_Name Team_Name
Team_Leader Team_Leader
Region Previous_Region
Current_Region

NB: nessuna modifica è stata fatta alle K dei record dim.li o al numero di record
nella SALES_TEAM. I due campi Current_Region e Previous_Region permettono
di separare tutti i record fact sales correnti da quelli precedenti.
Questo schema permette di tracciare solo i cambiamenti più recenti delle
vendite, ma offre molta flessibilità nel determinare tutta la storia di entrambi
gli schemi di assegnamento vendite.
E’ pensabile, nonostante qualche svantaggio, di generalizzare questo approccio
a più degli ultimi due cambiamenti più recenti.
Se ci sono molti di questi riallineamenti vendite e si desidera tracciarli tutti,
allora probabilmente è la TECNICA 2 quella da usare.

4.1.4 SCELTA DI UNA TECNICA

- la 2 e la 3 riescono a coprire la maggior parte delle applicazioni con SCD

- la 2 lavora molto bene per tab dim.li con parecchie centinaia di migliaia di
record. Poi, l’aggiunta di molti nuovi record a questa dimensione
abbastanza grande non compromette la performance in DBMS che
utilizzano una buona tecnica di indicizzaazione.
- Eventualmente, un punto può essere esteso al caso delle “monster
dimension”, dove la Tecnica 2 non può essere usata.. In questo caso sei
costretto a ricorrere ad una tecnica grezza, apposita per le “monster
dimension” (vedi DBMS Maggio 1996)

5 ES. CODICE SQLSERVER 2000

http://www.microsoft.com/technet/treeview/default.asp?
url=/TechNet/prodtechnol/sql/reskit/sql2000/part5/c1961.asp (cap 19)

6 RIFERIMENTI & APPROFONDIMENTI

http://www.dbmsmag.com (Data Warehouse Architet – Ralph Kimball)

http://dbforums.com
http://www.rkimball.com (Design Tips)
15
16