Systèmes d'Information Avancés

Année académique 2013/2014

Prof. Domenico Beneventano
EXERCICES – Entreposage de données
1 EXERCICES - CONCEPTION D'UN DW...................................................................................................2
1.1 Exercice : Expédition.............................................................................................................................2

1.1.1 Solution

1.1.2 Variante 1.......................................................................................................................................11

1.1.3 Variante 2 (mesure dérivée)..........................................................................................................11

1.1.4 Variante 3 : (schéma transactionnel)................................................................................................12

1.1.5 Solutions possibles pour la mesure NUMÉRO (comptage des événements primaires)...........................................14

1.1.6 Solutions possibles pour la mesure COÛT (mesure avec AVG dans un schéma transactionnel)..................15

1.2 Exercice : Détail de la Commande..................................................................................................................19

1.2.1 Solution

1.3 Exercice : Billet.................................................................................................................................22

1.3.1 Solution........................................................................................................................................24

1.3.2 Variante

1.3.3 Variante (dimension taille résultant de la discrétisation)....................................................................27

1.4 Exercice : Examen .................................................................................................................................29

1.4.1 Solution

1.5 Exercice : Vente .................................................................................................................................32

1.5.1 Solution........................................................................................................................................32

1.6 Exercice (19/12/2012) ..........................................................................................................................34

1.7 Exercice (14/01/2013) .........................................................................................................................35

1.8 Exercice (16/04/2013) .........................................................................................................................36

1.9 Exercice (10/09/2013) .........................................................................................................................37

1
1 EXERCICES - Conception d'un DW
Pour certains exercices, le code SQL est également fourni pour tester les solutions données. La table de faits et les
Les tables de dimension sont définies comme des vues dans le DBO donné (architecture à un niveau)

1.1 Exercice : Expédition

Considérons un DBO avec le schéma E/R suivant et le schéma relationnel correspondant (dans le schéma)
il peut y avoir des contraintes d'intégrité supplémentaires)

RÉGION ÉTAT
VILLE
MAGASIN (1,1) DANS (0,N) CITTA RÉGIONà ÉTAT

(1,N) (0,N) DONNÉES

MAGASIN
CITTA
Moisà ANNEE
DANS ADRESSE

ORDRE
(1,1) (1,1)

REPARTO(REPARTO, MAGASIN:MAGASIN)
DISTRIBUTION CLIENT

MAGASIN
(1,N) REPARTITION (1,N)
CLIENT
OUAIS CLIENTE
DEL

COÛT EXPÉDITION(NRIGA,ORDRE:ORDRE,
(1,1) PRODUIT (1,1)
PRODUIT
REPARTO
EXPÉDITION (1,N) ORDRE
DATE
(1,1) COSTO)
(1,1) NRIGA ORDRE

MOIS
Données AK: { ORDINE,PRODOTTO,
ORDRE DÉPARTEMENT
DONNÉES ANNEE

(0,N)
Données (0,N)
DONNÉES
EXPÉDITION

Il est demandé de :
A) Conception conceptuelle : Conception du schéma de fait EXPÉDITION avec dimensions
PRODUIT
mesurer
COUT : c'est le coût moyen de DÉ[Link]

NUMÉRO : c'est le nombre total d'expéditions

c'est le nombre total de commandes
B) Conception logique : Conception du SCHÉMA STAR et du SCHÉMA FLAKE

C) Alimentation : Écrire en SQL l'alimentation de la table de faits.

2
Exemple d'instance du DBO et correspondante instance du fait (événements primaires)

Événements primaires du fait

EXPÉDITION
avec des dimensions

PRODUIT
ENTREPÔT
CLIENT
DATASPED

3
Solution
Conception conceptuelle

Dans la conception conceptuelle, il est nécessaire de présenter un schéma de fait avec toutes les dimensions requises et, pour
chaque dimension, avec toute la hiérarchie dérivant du schéma du DBO.

Arbre des attributs initial

4
INNESTO sur REPARTO et ORDRE

La DATE de la COMMANDE est également ÉLAGUÉE

On ajoute les dépendances fonctionnelles suivantes, non présentes dans le schéma ER :

RÉGIONà État

MÉSEà ANNEE

5
Si obtient

Viene POTATA anche NRIGA

6
Choix des dimensions

Un schéma de fait est donc créé, en tenant compte d'un partage sur CITTA.

7
 VILLE
RÉGION ENTREPÔT

ÉTAT

EXPÉDITION DATASPED
NUMÉRO
COUT (Moy.) MOIS
CLIENT NUMÉRO_DE_COMMANDES
ANNEE
PRODUIT

EXPÉDITION(NRIGA,ORDRE,PRODUIT,DÉPARTEMENT, DATASPEDITION,COUT)

AK: { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE }

Dimensioni:{PRODOTTO,MAGAZZINO,CLIENTE,DATASPED}

Granularité

Dépendances fonctionnelles entre les dimensions : Aucune

Mesures normales
NOMBRE= COUNT(*), additive

NUMERO_ORDINI = compter(distinct ORDINE), additive par rapport à CLIENTE, car

ORDREà
CLIENT
Ainsi, NUMERO_ORDINI ne peut être agrégé que par rapport à CLIENTE, donc l'ensemble des
dimensions par rapport auxquelles il n'est pas agrégable est NA : {PRODUIT, MAGASIN, DATASPED}

Mesures calculées
COSTO = COSTO_SUM / COSTO_COUNT
pigeon
COSTO_SUM = SOMME(COSTO), additive
COSTO_COUNT = COUNT(COSTO)

Table de faits
TABLE_DE_FACTURE(PRODUCT,ENTREPOT,CLIENT,DATESPED,
NUMÉRO

À ce stade, une table de faits avec une structure simplifiée (sans références aux)
Tableau des dimensions) pour résumer quelles sont les dimensions du fait et les mesures à considérer.
Résumer quelles sont toutes les mesures est également utile pour vérifier s'il y a parmi toutes ces mesures
certaines équivalentes. Par exemple, dans ce cas, deux mesures ont été introduites et reportées dans la Table des Faits

NOMBRE
COUNT(COSTO)
Ces deux mesures sont-elles équivalentes ? Si la réponse est positive, une seule sera insérée dans la Fact Table.
mesure.

8
Conception Logique

Dans la conception logique, il est demandé de décrire à la fois le SCHÉMA ÉTOILE et le SCHÉMA FLOCON.
SCHEMA; La table de faits dans ces deux types de schémas coïncide (tandis que celles qui changent sont
évidemment les tables de dimension) donc nous pouvons rapporter la table de faits une seule fois.

La table des faits a la structure suivante

FACT_TABLE(PRODOTTO,MAGAZZINO,CLIENTE,DATASPED,
NUMÉRO

Comme dit précédemment, nous devons nous demander si les deux mesures

COMPTE(*)
COUNT(COSTO)

sont équivalents, c'est-à-dire si leur valeur coïncide. Donc, il faut vérifier si COUNT(*) et
COUNT(COSTO) renvoie la même valeur : la réponse est négative si dans le DBO le champ COSTO peut
assumer des valeurs NULL, car par définition une valeur NULL est comptée par COUNT(*) mais
non est compté par COUNT(COSTO). Dans nos exercices, nous supposons le cas général de la présence de
NULL donc dans la table de faits, les deux mesures seront toujours retenues.

La table des faits sera donc

FACT_TABLE(CLIENTE:dtCLIENTE,MAGAZZINO:dtMAGAZZINO,DATASPED:dtDATA,PRODOTT
O,
NUMÉRO

Veuillez noter que la dimension PRODUIT est dégénérée, donc la table de dimension correspondante n'est pas insérée.

Schéma en étoile

dtDonnées(DONNÉES,MÉMOIRE,ANNÉE)

dtCLIENTE(CLIENTE,CITTA,REGIONE,STATO)

dtMAGAZZINO(MAGAZZINO,VILLE,RÉGION,ÉTAT)

Schéma SnowFlake

dtDonnées(DONNÉES, MOIS:dtMOIS)

dtMESE(MESE,ANNO)

dtCLIENTE

dtMAGAZZINO(MAGAZZINO,VILLE:dtVILLE)

dtCITTA(CITTA,REGIONE:dtREGIONE)

dtRÉGION(RÉGION, ÉTAT)

9
Alimentation

La requête d'alimentation de la table de faits est constituée comme suit :

À PARTIR DE : en plus de la table EXPÉDITION, il faut considérer la table DÉPARTEMENT (qui contient
MAGASIN) et le tableau COMMANDE (qui contient CLIENT).
GROUP BY : banale, contient les dimensions du fait
SELECT : en plus des dimensions du fait, le calcul des mesures est rapporté sur la base de ce qui est spécifié dans
glossaire
CREER_VUE_FACT_TABLE_EN_TANT_QUE
SÉLECTIONNER
EXPÉ[Link]
[Link]
[Link]
EXPÉ[Link]
SOMME(COSTO)
COUNT(COSTO)
COMPTE(*)
=NB([Link])
DE EXPÉDITIONJOIN NATUREL
REPARTOJOINTURE NATURELLE
ORDRE
REGROUPEMENT PAR

EXPÉ[Link]
EXPÉ[Link]
[Link]
[Link]

Pour tester la requête, en devant l'exécuter sur un SGBD qui ne prend pas en charge le NATURAL JOIN :
DE EXPÉDITIONJOINDRE
[Link]=SPÉ[Link]
[Link]

10
1.1.2 Variante 1
Il est demandé de discuter comment change l'agrégation de la mesure NUMERO_ORDINI en tenant compte de
come dimensione MESE_ORDINE invece di DATASPED.

Dimensioni:{PRODOTTO,MAGAZZINO,CLIENTE,MESE_ORDINE}

Les FD concernant l'ORDRE sont (rappelons que NUMERO_ORDINI=SELECT (DISTINCT ORDRE))

ORDREà CLIENT

ORDREà MOIS_COMMANDE
Donc maintenant NUMERO_ORDINI est agrégable tant par rapport à CLIENTE qu'à MESE_ORDINE, par conséquent

NA:{PRODOTTO,MAGAZZINO }

1.1.3 Variante 2 (mesure dérivée)

Il est demandé de discuter comment change l'agrégation de la mesure NUMERO_ORDINI en tenant compte de
come dimensione ORDRE au lieu de CLIENT.

Dimensioni:{PRODOTTO,MAGAZZINO, ORDINE,DATASPED }

Par rapport à l'exemple précédent, on utilise comme dimension ORDRE à la place de CLIENT, donc le nouveau
fait est à un niveau de détail plus élevé. L'aspect principal concerne la mesure
NOMBRE_COMMANDES=COMPTER(DISTINCT COMMANDE):
Grâce à la présence de la dimension ORDRE, maintenant NUMÉRO_COMMANDES est une mesure dérivée d'un
dimension, donc elle ne sera pas insérée dans la table des faits !

Le schéma est en fait similaire à celui précédent : l'ajout de l'attribut dimensionnel ORDRE fait que
DATA est désormais un attribut dimensionnel commun entre la dimension COMMANDE (en effet, une COMMANDE a une
DATA) et la dimension DATASPED. Notez que pour cet attribut dimensionnel commun, on utilise le
termine plus général DATA et non DATA_SPED (sinon il serait indiqué qu'une COMMANDE a une)
DATA_SPED, chose non vraie). Cependant, DATA_SPED doit rester comme nom de la dimension, donc il
mette tale nome sularco(come avveniva ad esempio nel caso del Fatto Chiamata discusso sulle dispense).

CITTA ÉTAT
ENTREPÔT

EXPÉDITION RÉGION
NUMÉRO ORDRE

COSTO (Moy.) CLIENT

ANNEE
PRODUIT
DONNÉES DONNÉES
MOIS
SPÉD

Fait:EXPÉDITION(NRIGA,ORDRE,PRODUIT,DÉPARTEMENT, DATASPEDITION,COUT)
AK: { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE }

Dimensioni:{PRODOTTO,MAGAZZINO,ORDINE,DATASPED}

Granularité

11
Dépendances fonctionnelles entre les dimensions : Aucune

Mesures normales
NUMÉRO

Mesures calculées
COSTO_MEDIO = COSTO_SUM/COSTO_COUNT où
SOMME(COSTO), additive
COUNT(COSTO)
Mesures dérivées
NOMBRE_COMMANDES
Table des faits

TABLE_DE_FACTURES(PRODOTTO,MAGAZZINO,ORDINE,DATASPED,
NUMÉRO

Maintenant, la mesure dérivée NUMERO_ORDINI est facilement calculable en fonction de sa définition.

1.1.4 Variante 3 : (schéma transactionnel)

Comme troisième et dernière variante, on considère le fait SPÉDIZION avec des dimensions

PRODUIT

Donc, on utilise la taille SERVICE au lieu de STOCK, donc - comme dans le précédent
variante - le nouveau fait est à un niveau de détail plus élevé, c'est-à-dire que le nouveau fait a une granularité plus fine.
La caractéristique fondamentale de ce cas est que les dimensions coïncident (et qu'elles contiennent) une
clé du fait, c'est-à-dire que les dimensions coïncident avec la clé alternative

AK: { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE }

Ainsi, le nouveau fait EXPÉDITION est transactionnel ; les événements primaires du nouveau fait EXPÉDITION seront
en nombre égal au nombre d'instances (la cardinalité) de la relation EXPÉDITION du DBO :

Demande d'EXPÉDITION Événements Principaux de l'Expédition

Dans ce qui suit, ce nouveau cas est entièrement développé, mettant en évidence comment pour un schéma de
le fait transactionnel soit différent la requête d'alimentation de la table fait et le calcul des mesures, dans
particulièrement celles agrégées par la moyenne.
12
Conception Conceptuelle

Le schéma est en fait similaire au précédent : l'ajout de l'attribut dimensionnel ORDRE fait que
DATA est maintenant un attribut dimensionnel commun entre la dimension COMMANDES (en effet, une COMMANDE a une
DATA) et la dimension DATASPED. Dans ce qui suit, la convergence/le partage sur DATA sera discuté.

DISTRIBUTION
VILLE ÉTAT

MAGASIN
EXPÉDITION RÉGION
NUMÉRO ORDRE

COSTO (MÉD) CLIENT

ANNEE
PRODUIT
Données DONNÉES
MÊSE
SPÉD

FattoEXPÉDITION
AK: { ORDINE,PRODOTTO, REPARTO,DATASPEDIZIONE }

{PRODUIT,DÉPART,COMMANDE,DATESPED}

Granularité

Dépendances fonctionnelles entre les dimensions : Aucune

Conception Logique
FACT_TABLE(ORDINE:dtORDINE,REPARTO: dtREPARTO,DATASPED:dtDATA,PRODOTTO,
<sera terminé après la discussion sur les mesures>
Schéma en étoile

dtDONNÉES(DONNÉES,MOS,ANNÉE)

dtORDRE

dtREPARTO

Schéma SnowFlake

dtDONNEES(DONNEES,MOIS:dtMOIS)

dtMESE(MESE,ANNO)

dtORDINE(ORDINE,DATA:dtDATA,CLIENTE:dtCLIENTE)

dtCLIENTE

dtCITTA(CITTA,RÉGION:dtRÉGION)

dtRÉGION(RÉGION, ÉTAT)

dtREPARTO(REPARTO,MAGAZZINO:dtMAGAZZINO)

dtMAGAZZINO

13
1.1.5 Solutions possibles pour la mesure NUMÉRO (compte des événements primaires)
La mesure NUMÉRO dans le cas d'un schéma transactionnel correspond à ce qui a été discuté dans le cas de « Schémas ».
de fait vides”, c'est-à-dire que NUMERO est une mesure utilisée pour le comptage des événements primaires. Comme cela avait été
déjà signalé et comme nous le mettrons en évidence dans l'exemple, le nom « Schémas de fait vide » provient du fait que dans
dans ce cas, une solution possible est de ne pas insérer explicitement de mesure dans le schéma de
fait pour le comptage des événements primaires, c'est-à-dire ne mémoriser aucune valeur : ce concept de non
l'insertion de aucune mesure et la non-mémorisation de aucune valeur entraîne que dans la table des faits correspondante il n'y a pas
il ne doit y avoir aucun attribut pour cette mesure. D'autre part, le schéma de fait et donc la table de faits peuvent
contenerealtremisure (comme c'est le cas ici pour la mesure COÛT)

Prima Solution : mesurez les indicateurs pour le comptage des événements primaires

Mesures normales
(COMPTER)à pour indiquer en effet une mesure vide pour le comptage des événements primaires

Table des faits

FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED)

Alimentation

CREER VUE FACT_TABLEAS

SÉLECTIONNERPRODUIT
FROMSPEDIZIONE

Deuxième solution : mesurebooléana pour le comptage des événements primaires

Une autre manière de représenter la survenue d'un événement est à travers une mesure de type booléen, additive :
normalement, lorsqu'il s'agit d'effectuer un simple comptage des événements primaires, cette mesure prend
il n'y a que la valeur 1 (événement qui s'est produit) et non la valeur 0 (dans le schéma, en fait, on ne représente pas les
événements qui ne se produisent pas). Nous verrons néanmoins dans un prochain exercice qu'il est parfois nécessaire de compter
seulement certains événements (par exemple, dans le cas de l'exercice sur le fait BIGLIETTO, on souhaite représenter
tous les billets mais on ne veut compter que ceux qui ont également enregistré des bagages); dans ce cas
La mesure de comptage booléenne prend les valeurs 1 et 0.

Mesures normales
NUMERO = 1, additiva

Table de faits
TABLE_DE_FAITS
NUMÉRO)

NUMÉRO est une mesure normale : cette mesure a une valeur pour chaque événement primaire - dans ce cas
constante égale à 1 – et un opérateur d'agrégation pour en déterminer la valeur pour les événements secondaires

Si je le ramenais dans la table des faits, alors pour les agrégations, je devrais évidemment utiliser

NUMERO = SOMME(NUMERO)
14
Mais étant NUMERO=1, cela équivaut à faire

SOMME(1)
Il n'est donc pas nécessaire de rapporter le NUMÉRO comme attribut de la table de faits.

Comme exemple d'utilisation de cette mesure, calculons le modèle {MAGASIN_VILLE,CLIENT_VILLE}

dans le schéma SNOW-FLAKE :

SÉLECTIONNER
M.VILLE_MAGASIN_VILLE, C.VILLE_CLIENT_VILLE
=SOMME(1)
FROMFACT_TABLE FJOIN
dtREPARTO [Link]=[Link]
dtMAGAZZINO [Link]
dtORDINE [Link]=[Link]
dtCLIENTE [Link]=[Link]
GROUPE PAR [Link], [Link]

On peut vérifier que le résultat est correct en le comparant avec ce qui a été obtenu dans les tableaux de faits.
précédents.

En définitive, nous avons deux solutions similaires, dans les deux cas rien n'est reporté dans la table des faits pour la
mesure numéro (c'est ce qui justifie le terme Schéma de Fait vide utilisé dans ces cas). Ce que
Changez l'opérateur d'agrégation, dans le sens où nous pouvons utiliser deux opérations équivalentes

=NB(*)
ou bien

=SOMME(1)

1.1.6 Solutions possibles pour la mesure COÛT (mesure avec AVG dans le schéma transactionnel)
Dans un schéma transactionnel, pour une mesure telle que le COÛT qui doit être agrégée par moyenne, il
il y a deux solutions possibles

1) mesure normale avec opérateur d'agrégation AVG

2) mesure calculée COÛT = COÛT_TOTAL/COÛT_NOMBRE où
COSTO, additiva
=COMPTE(COSTO), additive
La solution généralement adoptée est la seconde ; nous présenterons néanmoins les deux solutions par la suite.
vérifiant qu'ils sont équivalents.

Première solution : mesure normale avec l'opérateur d'agrégation AVG

Table de faits

15
Alimentation

CREER VIEWFACT_TABLEAS
SELECTIONNER PRODUIT
FROMSPEDIZIONE

Comme exemple d'utilisation de cette mesure, calculons le modèle {MAGASIN_VILLE,CLIENT_VILLE} et

tous ses sous-modèles dans le schéma en flocon de neige :

SÉLECTIONNER
M.CITTAASMAGAZZINO_CITTA
C.CITTAASCLIENTE_CITTA
COSTO = MOYEN(COSTO)
DE<comme avant>

On peut vérifier que le résultat est correct en le comparant avec ce qui a été obtenu dans les schémas de fait.
précédents.

Deuxième solution : mesure calculée COÛT = COÛT_TOTAL / COÛT_NOMBRE

Dans ce cas, nous avons deux mesures normales.
COSTO, additiva
=COUNT(COSTO)
Qui seront ensuite utilisées pour le calcul de la mesure calculée COÛT.

Dans ce cas, étant le schéma transactionnel, les événements primaires seront calculés sans regrouper.
il n'a donc évidemment aucun sens de définir une mesure à travers un opérateur d'agrégation :
dans COSTO_COUNT =COUNT(COSTO) il a été indiqué COUNT en italique justement pour indiquer que
conceptuellement, je dois faire un comptage mais ce comptage est unitaire, c'est-à-dire COSTO_COUNT=1. De
en conséquence, cette mesure COSTO_COUNT coïncide avec la mesure NUMERO et peut donc être
définie et calculée comme déjà discuté précédemment :COMPTE(*)ou bienSOMME(1).

Table de faits FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED,COSTO_SUM)

Alimentation
CRÉER VUE FACT_TABLEAS
SÉLECTIONNERPRODUIT
FROMSPEDIZIONE

Comme exemple, on calcule le motif {MAGAZZINO_CITTA,CLIENTE_CITTA} et tous ses sous-motifs dans le

Schéma en flocon de neige utilisant pour COSTO_COUNT les deux possibilités
SÉLECTIONNER
M.CITTAASMAGAZZINO_CITTA
C.CITTAASCLIENTE_CITTA
COSTO =SUM(COSTO_SUM)/COUNT(*) ou COSTO =SUM(COSTO_SUM)/
SOMME(1)
DE<comme avant>
On peut vérifier que le résultat est correct en le comparant à ce qui a été obtenu dans les schémas de fait.
précédents.

Les deux solutions pour le calcul du COÛT comme valeur moyenne coïncident sous l'hypothèse que dans le schéma
operazione le valeur de COÛT ne doit pas être NULL ; en effet, une valeur NULL de COÛT n'est pas prise en compte,
c'est-à-dire qu'elle ne participe pas au calcul, dans la première solution, car, par définition, la fonction AVG est
calcolée sur les valeurs non nulles. Dans la deuxième solution, en revanche, la valeur NULL de COÛT est considérée dans
combien n'est pas additionné (par définition, la fonction SOMME sur les valeurs non nulles) mais est
conteggié, que ce soit via COUNT(*), car par définition COUNT(*) compte aussi les valeurs nulles, soit
à travers SUM(1) .

Modifions la table EXPÉDITION avec quelques NULL sur COÛT, puis vérifions la différence pour un
modèle simple {ORDRE}

16
tableau SPEDIZIONE COUT calculé comme COUT calculé comme
COUT=MOYEN(COUT) COSTO=SUM(COSTO_SUM)/SUM(1
)

Dans le cas de COÛT en tant que mesure calculée, pour considérer que COÛT peut être nul et donc non
doit participer à la moyenne, nous ne pouvons plus utiliser comme COSTO_COUNT l'expression SUM(1) (même
discours pour l'expression COUNT(*)) mais nous devons compter les valeurs NULL différemment, donc
on insère une mesure normale COÛT_COUNT qui sera 1 si COÛT n'est pas NULL, 0 sinon.

Table des faits FACT_TABLE(PRODOTTO,REPARTO,ORDINE,DATASPED,COSTO_SUM,COSTO_COUNT)

Alimentation

CREER VUE_TABLE_COMME
SELECTPRODOTTO
COSTO
CASE WHEN COSTO IS NULL THEN 0 ELSE 1 END
FROMSPEDIZIONE

Vérifions dans l'exemple de la page précédente :

table SPEDIZIONE COUT calculé comme COUT calculé comme

COSTO=MOY(COSTO) COSTO=SUM(COSTO_SUM)/
SOMME(COSTO_COUNT)

17
Code SQL

Création du DBO (vérifier, il peut ne pas être complètement à jour par rapport à l'exemple)

CREER TABLE ORDINE(ORDINE INT,CLIENTE INT, DATA INT);

CRÉER TABLE REPARTO(REPARTO INT, MAGAZZINO INT);
CREER TABLE MAGAZZINO(MAGAZZINO INT,CITTA INT);
CREER TABLE CLIENTE( CLIENTE INT,CITTA INT);
CRÉER TABLE CITTA(CITTA INT,REGIONE INT,STATO INT);
CRÉER TABLE DONNÉES( DONNÉE INT, MOIS INT, ANNÉE INT);
CRÉER TABLE SPEDIZIONE(NRIGA INT,ORDINE INT,PRODOTTO INT,REPARTO INT,DATASPEDIZIONE INT,COSTO FLOAT);

INSÉRER CITTA ( CITTA, RÉGION, ÉTAT ) SÉLECTIONNER 10,10,10

INSÉRER CITTA (CITTA, RÉGION, ÉTAT) SÉLECTIONNER 20, 20, 10
INSÉRER CITTA ( CITTA, RÉGION, ÉTAT ) SÉLECTIONNER 30, 20, 10
INSÉRER MAGAZZINO ( MAGAZZINO,CITTA ) SÉLECTIONNER 10,10
INSÉRER MAGAZZINO ( MAGAZZINO,CITTA ) SÉLECTIONNER 20,30
INSÉRER CLIENT (CLIENTE, VILLE) SÉLECTIONNER 10,10
INSÉRER CLIENTE (CLIENTE, CITTA) SÉLECTIONNER 20, 20
INSÉRER REPARTO ( REPARTO,MAGAZZINO ) SÉLECTIONNER 10,10
INSÉRER REPARTO ( REPARTO,MAGAZZINO ) SÉLECTIONNER 20,20
INSÉRER REPARTO ( REPARTO,MAGAZZINO ) SÉLECTIONNER 30,20
INSÉRER COMMANDE ( COMMANDE, CLIENT, DATE ) SÉLECTIONNEZ 1,10,30
INSÉRER ORDRE ( ORDRE, CLIENT, DATE ) SÉLECTIONNER 2,20,30
INSÉRER ORDRE ( ORDRE, CLIENT, DATE ) SÉLECTIONNER 3, 20, 30
INSÉRER EXPÉDITION ( NRIGA,ORDRE,PRODUIT,DÉPARTEMENT,DATASPD,COÛT ) SÉLECTIONNER 1,1,1000,10,10,10
INSÉRER SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SÉLECTIONNER 2,1,1000,10,10,21
INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 3,1,1000,10,10,11
INSÉRER EXPÉDITION ( NRIGA, ORDRE, PRODUIT, DÉPARTEMENT, DATEEXPÉDITION, COÛT ) SÉLECTIONNER 4, 1, 3000, 10, 10, 11
INSÉRER SPÉDIZION ( NRIGA, ORDINE, PRODUIT, RÉPARTITION, DATE SPÉDIZION, COÛT ) SÉLECTIONNER 1, 2, 3000, 20, 30, 11
INSÉRER ENVOI ( NRIGA, ORDRE, PRODUIT, DÉPARTEMENT, DATEENVOI, COÛT ) SÉLECTIONNER 2, 2, 3000, 30, 30, 11
INSÉRER SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SÉLECTIONNER 3,2,1000,20,10,10
INSÉRER ENVOI ( NRIGA, ORDRE, PRODUIT, SERVICE, DATEENVOI, COÛT ) SÉLECTIONNER 4, 2, 1000, 30, 10, 11
INSÉRER EXPÉDITION ( NRIGA, ORDRE, PRODUIT, DÉPARTEMENT, DATEEXPÉDITION, COÛT ) SÉLECTIONNER 5, 2, 1000, 20, 10, 11
INSERT SPEDIZIONE ( NRIGA,ORDINE,PRODOTTO,REPARTO,DATASPEDIZIONE,COSTO ) SELECT 1,3,3000,20,10,11
INSÉRER EXPÉDITION (NRIGA, ORDRE, PRODUIT, DÉPARTEMENT, DATEEXPÉDITION, COÛT) SÉLECTIONNER 2, 3, 3000, 30, 10, 21
INSÉRER EXPÉDITION ( NRIGA, ORDRE, PRODUIT, SERVICE, DATEEXPÉDITION, COÛT ) SÉLECTIONNER 3, 3, 3000, 20, 30, 11
INSÉRER DES DONNÉES ( DONNÉES, MOIS, ANNEE ) SÉLECTIONNER 10,10,10
INSÉRER DES DONNÉES (DONNÉES, MOIS, ANNÉE) SÉLECTIONNER 20,20,10
INSÉRER DES DONNÉES ( DONNÉES, MOIS, ANNÉE ) SÉLECTIONNER 30,20,10

18
1.2 Exercice : Détail de la commande
Considérons un DBO avec le schéma E/R suivant et le schéma relationnel correspondant
RÉGION État

VILLE
ENTREPRISE (1,1) DANS (0,N) VILLE RÉGIONà État
(1,N) (0,N)
ENTREPRISE
VILLE DONNÉES(DONNÉES,Mois,ANNÉE)
DI ADRESSE DF : MOISà ANNEE

(1,1) PRÉFÉRER (1,1) ORDRE

PRODUIT (0,N) (1,1) CLIENT PRODUIT(PRODUIT,ENTREPRISE:ENTREPRISE)

(0,N) (1,N)
Produit ENTREPRISE
CLIENT
DA DEL
CLIENTE
COÛT
(1,1) (1,1) PREFER:PRODOTTO)

DÉTAIL (1,1) (1,N) ORDRE DÉTAIL(NRIGA,ORDRE:ORDRE,

(1,1)
PRODUIT:PRODUIT
(1,1) NRIGA ORDRE DATE
DONNÉES COUT)
Mois
ORDRE
Données ANNEE

(0,N)
Données (0,N)
Données
EXPÉDITION

Il est demandé de
A) Conception conceptuelle : Conception du schéma de fait DÉTAILS des co-dimensions
produit
c'est le coût moyen
NUMÉRO : c'est le nombre total d'expéditions
B) Conception logique : Conception du SCHEMA STAR et du SCHEMA SNOWFLAKE
C) Alimentation : Écrire en SQL l'alimentation de la table de faits.

Solution
Le schéma de fait est similaire à celui de la fait Livraison – deuxième variante : le seul ajout est
l'association PREFER (un CLIENT a un PRODUIT préféré) qui relie CLIENT à PRODUIT.
Cela implique que l'attribut dimensionnel PRODUIT est maintenant commun aux deux dimensions COMMANDES et
PRODUIT. Dans ce cas - contrairement à ce qui a été discuté avec DATE et DATE_EXPÉDITION - étant donné qu'il n'y a pas
nous pouvons utiliser le même nom PRODUIT à la fois pour la dimension et pour l'attribut commun.

PRODUIT ENTREPRISE VILLE ÉTAT

DÉTAIL RÉGION
NUMÉRO

(C) COÛT (MOY) ORDRE CLIENT

ANNÉE

Données Données MOIS

ÉDUCATION SPÉCIALE

Avec la nouvelle association PREFER, CITTA est également accessible par le chemin CLIENTE_PRODOTTO.

19
Fait:DÉTAIL(NRIGA,ORDRE, PRODUIT, DATEXPÉDITION,COSTE)

Dimensioni:{PRODOTTO,ORDINE,DATASPED}

Temporal

Dépendances fonctionnelles entre les dimensions : Aucune

Mesures normales
NOMBRE

Mesures calculées
COSTO_MOYEN = COSTO_SOMME / COSTO_NOMBRE
colombe
SOMME(COSTO), additive
COUT_COUNT = COUNT(COUT), additif

Table de faits
FACT_TABLE(PRODOTTO,MAGAZZINO,CLIENTE,DATASPED,
NUMÉRO
Conception Logique

FACT_TABLE(ORDINE:dtORDINE,PRODOTTO:dtPRODOTTO,DATASPED:dtDATA,
NUMÉRO
Schéma en étoile

dtDONNÉES(DONNÉES,MOIS,ANNEE)

dtORDINE(ORDINE,DATA,MOIS,ANNEE,
CLIENT
PROD_P_CLIENTE
PROD_P_CLIENTE_AZIENDA_REGION )

dtPRODOTTO(PRODOTTO,AZIENDA,AZIENDA_CITTA,AZIENDA_REGIONE,AZIENDA_STATO)

Schéma SnowFlake

dtDonnées(DONNÉES,MES:dtMÉS)
dtMESE(MESE,ANNO)
dtORDINE
dtPRODUIT(PRODUIT,ENTREPRISE:dtENTREPRISE)
dtENTREPRISE(ENTREPRISE,VILLE:VILLE)
dtVILLE(VILLE,RÉGION:dtRÉGION)
dtRÉGION(RÉGION, ÉTAT)
dtCLIENTE(CLIENTE, CITTA:dtCITTA,PREFER:dtPRODOTTO)

Alimentation

CREER VUE_TABLE_DE_FAIT
SÉLECTIONNER
PRODUIT
SOMME(COSTO)
COUNT(COSTO)
=NB(*)
DE
DÉTAIL
GROUPE PAR
PRODUIT

20
Code SQL

Création du DBO
CRÉER TABLE ORDINE ( ORDINE INT, CLIENTE INT, DATA INT);
CRÉER TABLE PRODOTTO ( PRODOTTO INT, AZIENDA INT);
CRÉER TABLE AZIENDA ( AZIENDA INT, CITTA INT);
CREER TABLE CLIENTE ( CLIENTE INT, CITTA INT, PREFER INT);
CRÉER TABLE CITTA ( CITTA INT, REGIONE INT, STATO INT);
CRÉER TABLE DONNÉES ( DONNÉE INT, MOIS INT, ANNÉE INT);
CRÉER UNE TABLE DETTAGLIO ( NRIGA INT, ORDRE INT, PRODUIT INT, DATASPED INT, COÛT FLOAT );

INSÉRER VILLE ( VILLE, RÉGION, ÉTAT ) SÉLECTIONNER 10, 10, 10

INSÉRER CITTA ( CITTA, RÉGION, ÉTAT ) SÉLECTIONNER 20, 20, 10
INSÉRER CITTA ( CITTA, RÉGION, ÉTAT ) SÉLECTIONNER 30,20,10
INSÉRER AZIENDA (AZIENDA, CITTA) SÉLECTIONNER 10,10
INSÉRER AZIENDA (AZIENDA, CITTA) SÉLECTIONNER 20,30
INSÉRER CLIENT (CLIENTE,CITTA,PREFER) SÉLECTIONNER 10,10,10
INSÉRER CLIENT (CLIENTE, CITTA, PREFER) SÉLECTIONNER 20, 20, 30
INSÉRER CLIENT (CLIENTE, VILLE, PREFER) SÉLECTIONNER 30,20,30
INSÉRER PRODUIT ( PRODUIT, ENTREPRISE ) SÉLECTIONNER 10,10
INSÉRER PRODUIT ( PRODUIT, ENTREPRISE ) SÉLECTIONNER 20, 20
INSÉRER PRODUIT ( PRODUIT, ENTREPRISE ) SÉLECTIONNER 30,20
INSÉRER ORDRE ( ORDRE, CLIENT, DATE ) SÉLECTIONNER 1, 10, 30
INSÉRER ORDRE ( ORDRE,CLIENT,DATE ) SÉLECTIONNER 2,20,30
INSÉRER ORDRE ( ORDRE,CLIENT,DATE ) SÉLECTIONNER 3,20,30
INSÉRER ORDRE ( ORDRE, CLIENT, DATE ) SÉLECTIONNER 4,30,30
INSÉRER DES DONNÉES ( DONNÉES, MOIS, ANNÉE ) SÉLECTIONNER 10,10,10
INSÉRER DES DONNÉES (DONNÉES, MOIS, ANNEE) SÉLECTIONNER 20,20,10
INSÉRER DES DONNÉES ( DONNÉES, MOIS, ANNÉE ) SÉLECTIONNER 30, 20, 10

INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 1, 4, 10, 30, 22
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 2, 4, 20, 30, 22
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 3, 4, 30, 30, 22
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATEENVOI, COÛT ) SÉLECTIONNER 1, 1, 10, 30, 16
INSÉRER DÉTAIL ( NRIGA,ORDRE,PRODUIT,DATASPED,COUT ) SÉLECTIONNER 2,1,20,20,15
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATEENVOI, COÛT ) SÉLECTIONNER 3, 1, 30, 30, 13
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 1, 2, 10, 20, 13
INSÉRER DÉTAIL ( NRIGA, ORDINE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 2, 2, 20, 30, 13
INSÉRER DÉTAIL ( NRIGA, ORDRE, PRODUIT, DATASPED, COÛT ) SÉLECTIONNER 3, 2, 30, 20, 12
INSÉRER DÉTAIL ( NRIGA,ORDRE,PRODUIT,DATASPED,COUT ) SÉLECTIONNER 1,3,10,20,11
INSÉRER DÉTAIL ( NRIGA,ORDRE,PRODUIT,DATASPED,COUT ) SÉLECTIONNER 2,3,30,30,22

Création du StarSchema
CRÉER UNE VUE [DTDATA] AS SÉLECTIONNER * DE DONNÉES

CRÉER UNE VUE [DTORDINE] AS

Sélectionner [Link], [Link], [Link], [Link], [Link],
[Link]
[Link] COMME PROD_P_CLIENTE, [Link] COMME PROD_P_CLIENTE_AZIENDA,
[Link] EN TANT QUE PROD_P_CLIENTE_AZIENDA_CITTA
PROD_P_CLIENTE_AZIENDA_REGIONE
DE ENTREPRISE JOINDRE
ORDRE INNER JOIN
DONNÉES SUR [Link]ÉES = DONNÉ[Link]ÉES JOINDRE INNER
CLIENT ON [Link] = [Link] INNER JOIN
CITTA SUR [Link] = [Link] INNER JOIN
PRODUIT SUR [Link] = [Link] SUR [Link] = [Link] INTÉRIEUR
REJOINDRE
CITTA COMME CITTA_1 SUR [Link] = CITTA_1.CITTA

CRÉER UNE VUE [DTPRODOTTO] COMME

[Link], [Link], [Link] AS ENTREPRISE_VILLE, VILLE_1.RÉGION AS
SÉLECTIONNER
AZIENDA_REGIONE, CITTA_1.STATO EN TANT QUE AZIENDA_STATO
DE PRODUIT
REJOINDRE AZIENDA SUR [Link] = [Link]
REJOINDRE CITTA EN TANT QUE CITTA_1 SUR CITTA_1.CITTA = [Link]

21
1.3 Exercice : Billet
Considérons un DBO avec le schéma relationnel suivant :

VOLO(CODVOLO,DATA,RITARDO,COMPAGNIA)

BIGLIETTO(POSTO,[CODVOLO,DATA]:VOLO,COSTO )

[POSTO, CODVOLO, DATA]: BIGLIETTO

NCOLLI )

Il est demandé de

A) Conception conceptuelle : schéma de fait BILLET co-dimensions {VOL, NPLACE} et

misure{COSTO,NBIGLIETTI,NBIGLIETTI_CHECK-IN} dove

coût moyen du billet

NBIGLIETTI : est évalué avec le comptage des billets
NBIBLIETTICHECK-IN : est évalué avec le comptage des billets qui ont également le check-in
B) Conception logique : Schéma en étoile

C) Alimentation : Écrire en SQL l'alimentation de la table de faits.

Observations : La caractéristique de cet exercice est la présence de deux mesures de comptage :

NBIGLIETTI : évalué avec le décompte des billets

NBIBLIETTICHECK-IN : évalué avec le comptage des billets qui ont également le check-in
Dans la section 1.1.5, nous avons vu deux solutions pour de telles mesures. Dans cet exercice, nous les utiliserons toutes les deux, et
donc

NBIGLIETTI : mesure de comptage pour le comptage des événements primaires

NBIBLIETTICHECK-IN : mesure booléenne pour le comptage des événements primaires

En effet, on veut représenter tous les billets (en comptant leur nombre total via NBIGLETS et le coût
moyen coût) et on veut compter ceux qui ont également fait le check-in : NBIBLIETTICHECK-IN
ce sera une mesure de comptage booléenne qui prend la valeur 1 (il y a eu un enregistrement) et la valeur 0 (pas d'enregistrement)
dans).

Une autre caractéristique réside dans l'alimentation : en effet, la taille VOLO provient d'une paire d'attributs.
(Données et CODVOLO) du DBO.

22
Exemple d'instance du DBO et instance correspondante du fait (événements primaires)
VOL BILLET

ENREGISTREMENT

Événements Primaires
du Fait BIGLIETTO
Avec des dimensions
{VOLO,NPOSTO}

CRÉER TABLE [DBO].[VOLO] ([DATA] [DATETIME],[CODVOLO] [INT],[RITARDO] [INT],[COMPAGNIA] [INT] )

CRÉER TABLE [BIGLIETTO] ( DONNÉES
CRÉER TABLE [CHECK-IN] ([DATA] [DATETIME],[CODVOLO] [INT],[POSTO] [INT],[NCOLLI] [INT])
INSÉRER VOLO (DATA, CODVOLO, RITARDO, COMPAGNIA) SÉLECTIONNER '12 DÉC 2010 00:00', 123, 25, 100
INSÉRER VOLO ( DONNÉES,CODVOLO,RITARDO,COMPAGNIA ) SÉLECTIONNER '13 DÉC 2010 ',123,15,100
INSÉRER VOLO ( DATA,CODVOLO,RITARDO,COMPAGNIA ) SÉLECTIONNEZ '12 DÉC 2010',124,0,200
INSÉRER VOLO (DATA, CODVOLO, RITARDO, COMPAGNIA) SÉLECTIONNER '13 DÉC 2010', 124, 5, 200
INSÉRER BIGLIETTO (DATA, CODVOLO, POSTO, COÛT) SÉLECTIONNER '12 DÉCEMBRE 2010', 123, 1, 100
INSÉRER BIGLIETTO ( DATE, CODVOLO, POSTO, COÛT ) SÉLECTIONNER '12 DÉC 2010', 123, 2, 159
INSÉRER BIGLIETTO ( DATE, CODVOLO, POSTO, COÛT ) SÉLECTIONNER '12 DÉC 2010', 123, 3, 200
INSÉRER BIGLIETTO ( DATE,CODVOLO,POSTO,COSTO ) SÉLECTIONNER '13 DÉC 2010 ',123,1,50
INSÉRER BIGLIETTO ( DATE, CODVOLO, POSTO, COÛT ) SÉLECTIONNER '13 DÉC 2010', 123, 2, 50
INSÉRER BIGLIETTO ( DATE,CODVOLO,POSTO,COSTO ) SÉLECTIONNER '13 DÉC 2010 ',123,3,150
INSÉRER BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SÉLECTIONNER '13 DÉC 2010', 124, 1, 150
INSÉRER BIGLIETTO ( DATA,CODVOLO,POSTO,COSTO ) SÉLECTIONNER '13 DÉC 2010 ',124,2,50
INSÉRER [CHECK-IN] (Données, CODVOLO, POSTO, NCOLLI) SÉLECTIONNER '12 DÉCEMBRE 2010', 123, 2, 2
INSÉRER [CHECK-IN] ( DONNÉES,CODVOLO,POSTO,NCOLLI ) SÉLECTIONNER '12 DÉC 2010 ',123,3,3
INSÉRER [ENREGISTREMENT] (DONNÉE, CODVOLO, POSTE, NCOLLI) SÉLECTIONNER '13 DÉC 2010', 123, 1, 2
INSÉRER [CHECK-IN] (DATA, CODVOLO, POSTO, NCOLLI) SÉLECTIONNEZ '13 DÉC 2010', 124, 2, 4

23
1.3.1 Solution
Conception conceptuelle

Pour des raisons de simplicité, on commence par effectuer l’ingénierie inverse du schéma relationnel.

On commence par NPOSTO

BILLET ENREGISTREMENT
VOL NCOLLI
Cela correspond à une entité identifiée par DATA+CODVOLO. (1,1)
Donc BILLET COÛT
BIGLIETTO(POSTO,[CODVOLO,DATA]:VOLO,COSTO ) DEL

Identifiée par entité VOLO + NPOSTO; enfin

(1,N)
ENREGISTREMENT([POSTO,CODVOLO,DATA]: BILLET,
NCOLLI ) DONNÉES RITARDO
VOL
Étant la clé étrangère sur sa clé primaire : c'est un sous-ensemble. COMPAGNIE
CODVOLO

NPOSTO
Le schéma de fait BILLET avec dimensions
{VOLO,NPOSTO} est très simple ; notez qu'avec VOLO, on
entend l'attribut dimensionnel dérivant de CODVOLO + VOLO BILLET
(comme dans le cas du DISTRICT de l'exemple VENTE). COUT (Moyenne)
L'attribut dimensionnel CODVOLO est un fils de VOLO (de NBC
CODVOLO permet de recueillir des informations telles que le départ, la destination NB

non considérés dans l'exercice)

CODVOLO VOLO

COMPAGNIE
NB=NBIGLIETTI
NBIGLIETTI_CHECK-IN Données
RITARDO

FattoBIGLIETTO(VOL,NPOSTO,COUT)

Dimensioni {VOLO,NPOSTO}

Granularité : Transactionnelle (en fait VOLO est CODVOLO + VOLO, donc on obtient CODVOLO, VOLO, DATE)

Dépendances fonctionnelles entre les dimensions : Aucune

Mesures normales
NB=1, additiva

NBC =SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS 1 SINON 0, additive

Veuillez noter qu'à ce stade, il est seulement indiqué, à un niveau élevé, comment calculer le NBC ; le calcul effectif
sera explicité lors de l'alimentation

Mesures calculées
COSTO_SUM/COSTO_COUNT
dove COSTO_SUM = SUM(COSTO), additiva
COSTO_COUNT = COUNT(COSTO), additiva

Table de faits
(VOLO,NPOSTO,NBC, COSTO_SUM,COSTO_COUNT)
Veuillez noter que deux choix de conception ont déjà été effectués :

1) pour la mesure NB : elle n'est pas introduite dans la Fact Table, elle sera agrégée via COUNT(*)

24
 2) pour la mesure COÛT : le schéma est transactionnel, il y a deux possibilités pour définir COÛT
(voir section 1.1.4), il est choisi de considérer le COÛT comme une mesure calculée

Conception Logique

(NPOSTO, VOLO:dtVOLO, NBC, COSTO_SUM, COSTO_COUNT)

Schéma en étoile (le schéma en flocon de neige coïncide avec le schéma en étoile)

dtVOLO(VOLO,DONNEE,CODVOLO,COMPAGNIE,RETARD)

Alimentation

Le schéma est transactionnel, donc la vue d'alimentation ne doit pas regrouper. Il faut calculer.
NBC =SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS 1 SINON 0, additive

Pour vérifier si le BILLET est également en CHECK-IN : on effectue un left-join

SÉLECTIONNER...

NBC=CAS QUAND C.[CODVOLO] EST NULL ALORS 0 SINON 1 FIN

DEBIGLIETTO BLEFT JOIN[ENREGISTREMENT] CON(
B.[DONNÉES]=C.[DONNÉES]ETB.[CODVOLO]=C.[CODVOLO]ETB.[POSTO]=
C.[POSTO])

Il est important (même sans l'exécuter réellement) de savoir que cette requête retourne en sortie le même
nombre de tuples de BIGLIETTO : en effet, BIGLIETTO est du côté gauche de la jointure et BIGLIETTO et CHECK-IN
ils partagent la clé. Par conséquent, si dans la sélection, on met BIGLIETTO.*, je reçois la table BIGLIETTO.
avec en plus la colonne NBC et donc j'ai tout ce dont j'ai besoin pour calculer la Fact Table.

CREER VUE_TABLE_COMME
[Link],
VOLO=[Link]+CODVOLO
NBC=CAS QUAND C.[CODVOLO] EST NULL ALORS 0 SINON 1 FIN,
COSTO
CASE WHEN COSTO IS NULL THEN 0 ELSE 1 END
DEBIGLIETTO BLEFT JOIN[ENREGISTREMENT] CON(
B.[DONNÉES]=C.[DONNÉES]ETB.[CODVOLO]=C.[CODVOLO]ETB.[POSTO]=C.[POSTO])

En réalité, pour effectuer la concaténation VOLO = [Link] + CODVOLO, il est nécessaire de les convertir en chaînes.
VOLO=CONVERTIR(CHAR(20),[Link]) +'__'+CONVERTIR(CHAR(20),[Link]).

Bien que non demandé par le texte, voici l'alimentation de la dtVOLO :

CRÉER UNE VUE dtVOLOAS

SELECTVOLO=CONVERT(CHAR(20),DATA) +'__'+CONVERT(CHAR(20),CODVOLO),
CODVOLO
DEVOLO

25
1.3.2 Variante
Dans le schéma de fait précédent (transactionnel), on introduit la mesure

GUADAGNO, définie comme SUM(COSTO)

C'est-à-dire que le GAINS est défini à partir de l'attribut COÛT, tout comme la mesure COÛT, mais c'est une
mesure additive. On introduit également une mesure additive NCOLLI. Les événements primaires sont :

BILLET(VOYAGE, PLACE, COÛT)

Dimensioni {VOLO,NPOSTO}
Granularité
Dépendances fonctionnelles entre les dimensions : Aucune

Mesures normales
NB=COMPTE(*), additive

NBC = SOMME(SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS 1 SINON 0), additive

NCOLLI = SOMME(SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS NCOLLI SINON 0), additive

COSTO, additiva

Mesures calculées
COSTO = SOMME_COSTO / NOMBRE_COSTO
colombe
SOMME(COSTO), additive
COUT_COUNT = COUNT(COUT), additif

Conception Logique
Naturellement, le GUADAGNO est calculé à partir de COSTO_SUM, donc il n'est pas nécessaire d'avoir un autre attribut :

FACT_TABLE(NPOSTO,VOLO:dtVOLO, NBC, COSTO_SUM,COSTO_COUNT,NCOLLI)

Alimentation : on ajoute le calcul de la mesure normale NCOLLI

NCOLLI=ISNULL(NCOLLI,0)

26
1.3.3 Variante (dimension résultant de la discrétisation)
Si considère une autre variante dans laquelle la dimension précédente NPOSTO est discrétisée dans l'attribut.
classe dimensionnelle de cette manière :

si NPOSTO <= 1 alors 'PREMIÈRE' sinon 'DEUXIÈME'

Schéma de fait condimensions {VOL, CLASSE}

emisure{COSTO,NBIGLIETTI,NBIGLIETTI_CHECK-IN,GUADAGNO,NCOLLI}.

GUADAGNO est encore défini comme SUM(COSTO)

Exemple d'instance du DBO et instance correspondante du fait (événements primaires)

Événements Primaires
de la Fait BIGLIETTO

Le schéma de fait BIGLIETTO avec dimensions {VOL, CLASSE} BILLET

COUT (Moyenne)
si obtient du précédent en remplaçant NPOSTO par CLASSE (qui NBC
constitue une discrétisation de celle-ci NB
CLASSE
GUADAGNO
NCOLLI
FATTI(BILLET, VOL, PLACE, COÛT)
Dimensioni VOL
CODVOLO
Temporal VOL
Dépendances fonctionnelles entre les dimensions : Aucune
COMPAGNIE

DONNÉES
RITARDO

Mesures normales
NB=NB(*), additive
NBC = SOMME(SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS 1 SINON 0), additive
NCOLLI = SOMME(SI <BIGLIETTO AVEC ENREGISTREMENT> ALORS NCOLLI SINON 0), additive
GUADAGNO : SOMME(COSTO), additive

Mesures calculées COSTO= COSTO_SUM/COSTO_COUNT où

SOMME(COSTO), additive
COMPTE(COSTO), additive
27
Conception Logique Schéma en étoile (le schéma en flocon coïncide avec le schéma en étoile)

FACT_TABLE(CLASSE,VOLO:dtVOLO,NB,NBC,NCOLLI, COSTO_SUM,COSTO_COUNT)
dtVOLO(VOLO,DATAS,COMPAGNIE,FASCIA_RITARDO)

Alimentation : Étant donné le schéma temporel, l'alimentation de la Table de faits nécessite de regrouper
sur les dimensions. Mais dans ce cas, les deux dimensions sont calculées

VOL=DONNÉE+CODVOL
CLASSE=SI POSTO<=1 ALORS 'PRIMA' SINON 'SECONDA' FIN

En SQL, le regroupement GROUP BY est également possible sur des expressions génériques donc

CRÉER TABLE DE VUEFACT

SÉLECTIONNER
VOLO =CONVERTIR(CHAR(11),[Link]) +'__'+CONVERTIR(CHAR(3),[Link])
CLASSE=CAS QUAND [Link]<=1 ALORS 'PRIMA' SINON 'SECONDA' FIN,
SOMME(COSTO)
COUNT(COSTO)
NB=COMPTE(*)
NBC=SUM(CASE WHEN C.[CODVOLO] IS NULL THEN 0 ELSE 1 END),
NCOLLI=SUM(CASE WHENC.[CODVOLO]IS NULLTHEN0ELSENCOLLIEND)
DE BIGLIETTO BLEFT JOIN[CHECK-IN] CON
(B.[DATA]=C.[DATA]ETB.[CODVOLO]=C.[CODVOLO]ETB.[POSTO]=
C.[POSTO])
GROUPE PAR
CONVERTIR(CHAR(11),[Link]) +'__'+CONVERTIR(CHAR(3),[Link]),
CAS QUAND [Link] <= 1 ALORS 'PRIMA' SINON 'SECONDA' FIN

Bien que non demandé, pour obtenir les événements primaires et la table de dimension dtVOLO

SÉLECTIONNER VOL, CLASSE, COÛT = COÛT_SUM / COÛT_COUNT, NB, NBC, NCOLLI

GUADAGNO_C = (COUT_SUM/COUT_COUNT)*NB, -- mesure calculée
GUADAGNO_D = COÛT_SUM *1) -- mesure dérivée agrégée avec SUM
DE_TABLE_FACTURE
CRÉER LA VUE dtVOLOAS
SélectionnerVOLO =CONVERT(CHAR(11),DATA) +'__'+CONVERT(CHAR(3),CODVOLO),
DONNÉES
DEVOLO

28
 1.4 Exercice : Examen
RÉGION SEDE: un CDS (CorsoDiStudio) a sede d'une
ÉTUDIANT (1,1) ISCRI
(0,N) FACULTÉ
FACULTÉ
DI (0,N) TTO
(0,N)
(0,N) DELtra DOCENTE et CDS : un DOCENTE est de
(1,1)
GROUPE (0,N) un CDS
RAPPRES
TIPO (1,N) AFFERENZA
ENTANT SIEGE
CONtra APPELLO et DOCENTE : un APPEL
EXAMEN DEL (1,1) c'est avec le DOCENTE qui le tient
(1,1) (1,1)
ÉTUDIANT
(1,1)
(1,N) DEL (1,1) Attributo TYPE_EXAM de l'EXAMEN : assume le
CDS ENSEIGNANT
EXAMEN valore STUD s'il s'agit d'un examen d'un étudiant
GROUPE
(1,N) et la valeur GRUP s'il s'agit d'un examen d'un
(T,E) CON
GÉNÉRE
groupe
VOTE (1,1)
NUMES NUMESè un identifiant d'EXAMEN (clé
EXAMEN (1,1) DI (1,N) APPEL
alternativa dans le schéma relationnel):
c'est un numéro progressif unique
DONNÉES TYPE_DE_EXAMEN de l'examen.
(ÉTUD/GROUPE)

FACULTÉ CDS
ENSEIGNANT
APPELLO
ESAME(NUMES, APPELLO:APPELLO, DATA, TIPO_ESAME, VOTO) AK : NUMES
ESAMEGRUPPO(NUMES:ESAME, GRUPPO:GRUPPO)
ESAMESTUDENTE(NUMES:ESAME, STUDENTE:STUDENTE) GRUPPO(GRUPPO,TIPO)
Il est demandé :
A) Conception conceptuelle : Conception du schéma de fait EXAMEN avec
dimensions GROUPE
L'ÉTUDIANT est l'ÉTUDIANT qui a passé l'examen
GRUPPO est le GRUPPO qui a passé l'examen
mesures
c'est la note moyenne de l'examen
c'est le nombre distinct des appels
B) Conception logique : Conception du STARSCHEMA
C) Alimentation : Écrire en SQL l'alimentation de la table de faits.

Exemple d'instances :
DBO:relationEXAMEN DW : Événements Primaires du Fait EXAMEN

29
Solution
Conception conceptuelle

Partage sur ÉTUDIANT : Dépendances fonctionnelles entre les dimensions :

ÉTUDIANT qui a passé l'examen ÉTUDIANTà TIPOESAME
ÉTUDIANT représentant du CDS du DOCENTE GROUPEà TIPOESAME

Partage sur FACULTE :

FACULTÉ DU DOCUMENT Modèle primario =
FACULTÉ de l'ÉTUDIANT ÉTUDIANT
FACULTE du REPRESENTANT étudiant

ENSEIGNANT Pour les FD entre les dimensions, dans le schéma

équivalente si ha (si riporta solo la parte)
intéressée)
FACULTÉ
Si noter la convergence sur TIPO_ESAME
RÉGION
CDS ÉTUDIANT
EXAMEN
ÉTUDIANT VOTE MOYEN
T,E
EXAMEN
(C) VOTO_MEDIO (MÉDIO) NUM_APPELLI
T,E DONNÉES
GROUPE
NUM_APPELLI
TYPE_D_EXAMEN
GROUPE TYPE
TIPO
TYPE_D_EXAMEN

FattoESAME(NUMES, APPELLO:APPELLO, DATA, TIPO_ESAME, MESE,ANNO,VOTO)

Dimensioni ENSEIGNANT

Mesures normales
COUNT(DISTINCT [Link]), additiva avec NA = {STUDENTE,DATA,GRUPPO}

Mesures calculées
VOTO_TOT / VOTO_COUNT
colombe
SOMME(VOTO)
COMPTE_VOTES = COMPTE(*)

Table de faits TABLE_DE_FAITS(DONNÉES,GROUPE,ÉTUDIANT,ENSEIGNANT,TYPE_D_EXAMEN,

VOTO_TOT, VOTO_COUNT, NUM_APPELLI)

Conception Logique STARSCHEMA :

FACT_TABLE(DATA,GRUPPO:dtGRUPPO,STUDENTE:dtSTUDENTE,DOCENTE:dtDOCENTE
TIPOESAME

dtGRUPPO(GRUPPO,TIPO)
dtSTUDENTE(STUDENTE, FACOLTA, FACOLTA_REGIONE, FACOLTA_STATO)
dtDOCENTE(DOCENTE,FACOLTA, FACOLTA_REGIONE,
CDS
CDS_ÉTUDIANT

30
Alimentation

L'aspect caractéristique est la présence de dimensions optionnelles, dont la valeur nulle est appropriément
codifié (on utilise toujours 9999)

CRÉER UNE VUE VIEW1 COMME

SÉLECTIONNER ESAME.*, ISNULL([Link],9999) AS STUDENTE,
ISNULL([Link],9999) AS GRUPPO
DE ESAMELEFT OUTER JOIN
ESAMEGRUPPO SUR [Link] = [Link] LEFT OUTER JOIN
ESAMESTUDENTE SUR [Link] = [Link]

CRIÉR VUE FACT_TABLE COMME

SÉLECTIONNERGROUPE
COUNT(*) AS NUM_TOT
SOMME(VOTO) AS VOTO_TOT,
COUNT(VOTO) AS VOTO_COUNT,
COUNT(DISTINCT [Link]) AS NUM_APPELLI
DE LA VUE1 JOINDRE NATURELLEMENT APPELLO
GROUPE PAR GROUPE, ÉTUDIANT, TYPE D'EXAMEN, DATE, ENSEIGNANT

Pour une simplicité, on utilise le NATURAL JOIN (afin d'éviter d'écrire la condition de jointure).

Il est possible d'utiliser le NATURAL JOIN même pour les jointures externes, c'est-à-dire que l'écriture de la VIEW1 peut
simplifier en écrivant :
CRÉER UNE VUE VIEW1 COMME
SELECT ESAME.*, ISNULL([Link],9999) AS STUDENTE,
ISNULL([Link],9999) AS GRUPPO
DE L'ESAME
JOINTURE NATURELLE GAUCHE SUR LE MÊME GROUPE
JOINTURE NATURELLE GAUCHE AVEC LE MÊME ÉTUDIANT

31
1.5 Exercice : Vente
Soit donné le schéma relationnel du DBO
VENTE
PRODUITà CAISSE
NUMÉRO_DE_BON_DE_CASSEà
DONNÉES
PRODUIT(PRODUIT,TYPE:TYPE)

TIPO
Il est demandé :
1) Ingénierie inverse : Schéma E/R équivalent
2) Conception Conceptuelle : Schéma de Fait avec
{PRODUIT,CAISSE,COMMIS,DAT}
i. NUMVENDITE = count(*)
ii. NUMCLIENTI = compter(DISTINCT NUMERO_SCONTRINO)
3) Conception logique : SCHÉMA EN FLOCON DE NEIGE
4) Supposons que l'attribut COMMIS prenne la valeur NULL pour les ventes sans COMMIS et
une valeur NON NULLE pour les ventes avec vendeur, considérer le Schéma de Fait avec
{PRODUIT, CAISSE, DATE} et discuter de la définition et de l'agrégation de
mesure nombre de ventes avec COMMIS

1.5.1 Solution
Schéma E/R :

VENTE (1,1) DANS (1,N) SCONTRINO (1,1) CON

(1,1) COMM
CATÉGORIE
DI
CASSA (1,N)
GROUPE
(1,N)

TYPE (1,N) HA (1,1) PRODUIT TOUT

(1,N) (1,N) DONNÉES
CASSA

Schéma des faits de VENTE

CHAT
GROUPE CHAT GROUPE

TYPE
TYPE
PRODUIT PRODUIT

VENTE VENTE
CAISSE
NUMVENDIT
NOMBRE DE VENTES
E CASSA
NUMCLIENTI
NUMCLIENTI

COMM Données COMM DONNÉES

FaitVente
Dimensioni= { PRODOTTO,CASSA, COMM,DATA}
Granularité
Dépendances fonctionnelles entre les dimensions : {Données, Produit}à CASSA
32
Mesures normales
NOMBREVENTES= COUNT(*),additive
NUMCLIENTI=COMPTE(DISTINCT NUMERO_SCONTRINO), additif
{ PRODUIT, COMM}
Pour évaluer quels sont les modèles pour lesquels la valeur agrégée de NUMCLIENTI peut être calculée :
si considère le schéma équivalent sans FD entre les dimensions : NA = { PRODUIT, COMMISSION}.

Schéma SnowFlake
FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI)
dtPRODOTTO(PRODOTTO,TIPO:dtTIPO)
dtTIPO(TIPO, GROUPE, CATÉGORIE)
Il est possible de limiter la clé de la Fact Table au seul pattern primaire {PRODUIT,DATE,COMMANDE}
FACT_TABLE(PRODOTTO:dtPRODOTTO,DATA,COMMESSO,CASSA,NUMVENDITE,NUMCLIENTI)

Il est également possible de normaliser la Fact Table au seul schéma primaire.

Produit
FACT_TABLE(PRODOTTO:dtPRODOTTO, DATA,COMMESSO, NUMVENDITE,NUMCLIENTI)
dtPRODOTTO(PRODOTTO,TIPO:dtTIPO)
dtTIPO(TIPO,GRUPPO, CATEGORIA)
dtCASSA(PRODOTTO:dtPRODOTTO, DATA, CASSA)

33
1.6 Exercice (19/12/2012)
Étant donné le schéma de fait suivant

RÉGION VILLE
FILIALE COMPTE COURANT
ÉTAT BANQUE OPÉRATION
CLIENT
MONTANT (MOY)

BANQUE N_BANCOMAT
CHÈQUE SEXE
MOIS
COMMISSION

OPÉRATIONS via CARTE BANCAIRE dans une AGENCE et sur un COMPTE COURANT ; pour les OPÉRATIONS
diversamento-assegnoc’il y a la BANQUE du CHÈQUE DÉPOSÉ et la COMMISSION est indiquée
cela dépend de cette banque et de l'ÉTAT de la banque de la succursale de l'opération.
Il est demandé de :
1) Conception logique : Conception du SCHÉMA SNOWFLAKE ;
2) Si considère un arc multiplo pour COMPTE COURANT et CLIENT (un compte courant est maintenant au nom de
plus de clients, avec un certain POIDS), avec MONTANT mesure pondérée et N_BANCOMAT mesure d'impact.
Discuter de ce qui change dans la Conception Logique (il suffit de rapporter seulement les parties du schéma)
qui sont modifiées).

Solution
SCHÉMA ENFLAKE
TABLE_DE_FAITS (MOIS, FILIALE:DT_FILIALE, CC:DT_CC, BANCAASSEGNO:DT_BANCA,
NBANKOMAT
DT_BANCA(BANCA,ÉTAT)
DT_CC(CC,CLIENTE:DT_CLIENTE)
DT_CLIENTE
DT_FILIALE
DT_VILLE(VILLE, RÉGION:DT_RÉGION)
DT_RÉGION(REGION, ÉTAT)
DT_COMMISSIONE(BANCAASSEGNO:DT_BANCA,STATO,COMMISSIONE)

Arco multiple entre COMPTE COURANT et CLIENT :

FACT_TABLE_PD(MESE,FILIALE:DT_FILIALE,CC:DT,BA:DT_BANCA, CLIENTE:DT_CLIENTE,
NBANKOMAT_P
DT_CC(CC,CLIENTE:DT_CLIENTE)

Le SCHÉMA SNOWFLAKE est identique au précédent, on enlève seulement DT_CC car il est maintenant dégénéré.

34
1.7 Exercice (14/01/2013)
Étant donné le schéma relationnel suivant du DBO :

VIAGGIO(PERSONA:PERSONA,DATA, ITINERARIO:ITINERARIO)
ITINERARIO(ITINERARIO,PARTENZA:CITTA,DESTINAZIONE:CITTA,AGENZIA,TIPO)
FD: PARTENZA, DESTINAZIONE à AGENCE
PERSONA
CITOYEN
RÉGION(RÉGION, ÉTAT)

Il est demandé de :
A) Conception conceptuelle : schéma de fait VOYAGE en co-dimensions
RÉSIDENCE
1. NumVIAGGI : nombre de voyages, obtenu par un simple comptage
2. NumITINERARI : nombre d'itinéraires, obtenu comme count(distinct ITINERARIO)
3. NumPERSONE : nombre de personnes, obtenu avec count(distinct PERSONA)

dove ANNO est un attribut dimensionnel de DATE, donc DATEà ANNEE.

B) Conception logique : Schéma en étoile.

Solution
Schéma de Fait VOYAGE

RÉSIDENCE VILLE RÉGION ÉTAT

VOYAGE
NumITINERARI DÉPART
ANNEE DISTRICT
NumPERSONE

NumViaggi ÉTAT_DE_DESTINATION
AGENCE

FattoVIAGGIO(PERSONA:PERSONA,DATA:DATA, ITINERARIO:ITINERARIO)
Dimensioni= { RESIDENZA,PARTENZA, DESTINAZIONE_STATO, ANNO, AGENZIA }
Temporelle
Mesures normales
COMPTE(*)
NumITINERARI = COMPTE(DISTINCT ITINERARIO), additive
con NA = { RÉSIDENCE, ANNÉE } en raison de
ITINÉRAIREà DEPART
NumPERSONE =COMPTER(DISTINCT PERSONA), additive
{PARTENZA, DESTINATION_STATE, AGENCY, YEAR}
en tant que PERSONNEà RÉSIDENCE

Schéma en étoile

FACT_TABLE(RESIDENZA:DTCITTARESID,PARTENZA:DTCITTAPART,
DESTINATION_ÉTAT
NumPERSONNES
DTCITTARESID(RESIDENCE,RÉGION,ÉTAT,DISTRICT)
DTCITTAPART(DÉPART,RÉGION,ÉTAT,DISTRICT)

35
1.8 Exercice (16/04/2013)
Étant donné le schéma relationnel du DBO :
TELEFONATA(NP,DATA,DA_CHIAMANTE:SIM, A_CHIAMATA:SIM,DURATA)
SIM
PREFISSO(PREFISSO, OPERATORE)
UTILISATEUR
Il est demandé de :
A) Conception conceptuelle : schéma de fait APPEL TÉLÉPHONIQUE
condimensioni{DATA, SIM_CHIAMANTE, OPERATORE_CHIAMATO, UTENTE_CHIAMATO }
émisure
DURATA_MEDIA durée moyenne des appels
NumSIM_CHIAMANTI nombre de SIM appelants,count(distinct DA_CHIAMANTE)
NumSIM_CHIAMATE nombre des SIM appelées, count(distinct A_CHIAMATA)
B) Conception logique : Conception du SCHÉMA ÉTOILE.
SolutionSchéma de Fait APPEL TÉLÉPHONIQUE

OPÉRATEUR

OPÉRATEUR_APPELÉ

SIM_APPELANT PREFISSO

APPEL TÉLÉPHONIQUE
NumSIM_APPLE TARIF
Données
NumSIM_APPELS
UTILISATEUR
DURÉE_MOYENNE
UTILISATEUR_APPELÉ
VILLE

(NP, DATE, DE_L_APPELANT: SIM, A_APPELE: SIM, DUREE)

Dimensioni DATE
Granularité
Dépendances fonctionnelles entre les dimensions : Aucune
Mesures normales
=NB(DISTINCTA_CHIAMATA), additive
{DONNÉES, SIM_APPELANT}
en tant que A_APPELà OPÉRATEUR_APPELÉ
Mesures calculées
DURÉE_MÉDIANE - mesure calculée DURÉE_TOT / DURÉE_COUNT - con
SOMME(DURATA)
DURATA_COUNT = COUNT(DURATA)
Mesures dérivées
NOMBRE(DISTINCT DA_CHIAMANTE)
mesure dérivée de la valeur d'une dimension ; pour les événements primaires, cela vaut 1 ; pour les événements secondaires cela
USA COMPTER(DISTINCT DA_CHIAMANTE).
Schéma en étoile
La dimension OPERATEUR_APPELE est dégénérée donc elle ne nécessite pas de table de dimension.
La mesure NumSIM_CHIAMANTI est dérivée donc elle n'est pas dans la FACT_TABLE.
FACT_TABLE(DATA, OPERATORE_CHIAMATO,
DT_SIM_CHIAMANTE
DT_UTENTE_CHIAMÉ
DURATA_COUNT
DT_SIM_CHIAMANTE(SIM,TARIFFA,PREFISSO,OPERATEUR,UTILISATEUR,VILLE)
DT_UTILISATEUR_APPELÉ
36
1.9 Exercice (10/09/2013)

Étant donné le schéma relationnel suivant du DBO :

CONVENTION
CONTRAT COMMITTENTE
PERSONA, ANNO, TIPO, DURÉE, MONTANT
INSTITUTION
PERSONA
VILLE
Il est demandé de :
A) Conception conceptuelle : schéma de fait CONTRAT avec cinq dimensions
CONTRATANT
CLIENT_VILLE
3) CONVENTION
4) ANNEE
5) TYPE
les tremblements

1) DURÉE : c'est la durée moyenne des contrats

2) MONTANT : c'est le montant total des contrats
NUMÉRO : c'est le nombre total de contrats

B) Conception logique : Schéma en étoile.

C) On discutera de l'agrégation des mesures suivantes :

1) NumCOMMITTENTI : obtenu comme count(distinct COMMITTENTE)

2) NumCONTRAENTI: obtenu comme count(distinct CONTRAENTE)
3) NumISTITUZIONI : obtenu comme count(distinct ISTITUZIONE)

Solution

Schéma de Fais TELEPHONE

GÉNÉRER

INSTITUTION
ÉTAT
CONVENTION
ANNEE
CONTRAT
CONTRAENT
DURÉE VILLE
IMPORTO PERSONA TITRE
NUMÉRO

TYPE COMMANDITAIRE_VILLE

DIMENSIONI ={CONTRAENTE, COMMITTENTE_CITTA, CONVENZIONE, ANNO, TIPO}

L'ensemble des dimensions contient la clé {CONTRACTANT, CONVENTION}, donc le schéma est
la dépendance fonctionnelle entre les dimensions

37
PARTIEà VILLE_COMMISSIONNAIRE

Mesures normales

DURÉE

IMPORTO, additiva

Étant donné que le schéma transactionnel, la mesure NUMÉRO peut être considérée comme une mesure vide, par
agréger par count(*) et donc ne sera pas reporté dans la FACT_TABLE.

Schéma en étoile

FACT_TABLE(CONVENZIONE:DTCONVENZIONE,CONTRAENTE:DTCONTRAENTE,
DTCOMMITTENTE_CITTA
DTCOMMITTENTE_CITTA(CITTA, STATO)
DTCONVENZIONE(CONVENZIONE, GENRE, INSTITUTION,
DIRECTEUR
VILLE_SEDE
DTCONTRAENTE(PERSONA, TITOLO, CITTA, STATO,)

Aggrégabilité des mesures :

1) NumCOMMITTENTI : obtenu comecount(distinct COMMITTENTE)

Elle est additive par rapport à la dimension COMMITTENTE_CITTA (puisque
CLIENTà COMMITTENTE_CITTA), non agrégable par rapport aux autres dimensions

2) NumCONTRAENTI : obtenu comme count(distinct CONTRAENTE)

C'est une mesure dérivée (CONTRAINTÉ est dans la FACT_TABLE) ; donc agrégable par rapport à toutes les
dimensions

3)NumISTITUZIONI: obtenu comecount(distinct ISTITUZIONE)

C'est additif par rapport à la dimension CONVENTION (car
ÉTABLISSEMENTà CONVENTION), non agrégable par rapport aux autres dimensions.

38