Université de La Ecole Supérieure de l'Economie Numérique

Manouba
Niveau 3ème TSI A.U: 2019/2020
Matière Business Intelligence 1er semestre

Série 3 : Analyse OLAP

Exercice 1

On veut construire un entrepôt de données afin de stocker les informations sur les
consultations d'un pays. On veut notamment connaître le nombre de consultations, par
rapport à différents critères (personnes, médecins, spécialités, etc.) Ces informations sont
stockées dans les relations suivantes :

Personne (id, nom, tel, adresse, sexe)

Médecin (id, tel, adresse, spécialité)
Consultations (id_med, id_pers, date, prix)

1. Proposer un schéma conceptuel qui tient en compte de la date, du jour, de la semaine, du

mois, du trimestre et de l'année.
2. Quelle est la table des faits?
3. Quelles sont les mesures?
4. Combien de dimensions ont été retenue? Quelles sont-elle?
5. Quelles sont les hiérarchies des dimensions?
6. Faites une représentation du cube OLAP sans tenir compte des hiérarchies
7. A partir de ce cube, indiquer quelles opérations OLAP (roll up, drill down, slice, dice) faut-il
appliquer pour obtenir les informations suivantes :
a. Le coût total des consultations par médecin en 2012 et 2013
b. Le nombre de consultations par jour de la semaine par spécialité et par sexe du patient
c. Le coût des consultations par patiente pour le mois d'octobre

Exercice 2
1. On considère le schéma conceptuel suivant :

1
Indiquer quelles opérations OLAP (roll up, drill down, slice, dice) faut-il appliquer pour obtenir
la note moyenne des cours en Informatique pour chaque étudiant.

2.

Indiquer quelles opérations OLAP (roll up, drill down, slice, dice) faut-il appliquer pour obtenir
la charge totale payée par un étudiant spectateur à "GM Place" en 2010.

Exercice 3
Donner l'équivalent "Opération OLAP" de chacune des requête suivantes :

1. SELECT TIME, LOCATION, PRODUCT ,SUM(REVENUE) AS PROFIT

FROM SALES
GROUP BY ROLLUP(TIME, LOCATION, PRODUCT);

2. SELECT TIME, LOCATION, PRODUCT ,SUM(REVENUE) AS PROFIT

FROM SALES
GROUP BY ROLLDOWN(TIME, LOCATION, PRODUCT);

3. SELECT PRODUCTS, SUM(REVENUE)

FROM SALES
WHERE PRODUCTS= ‘OPV’
GROUP BY PRODUCTS ;

4. SELECT PRODUCTS, SUM(REVENUE)

FROM SALES
WHERE PRODUCTS= ‘EL’ AND LOCATION=’EUROPE’
GROUP BY PRODUCTS;

Exercice 4 :

2
La société Chausséria, installée dans la région Rhône-Alpes, désire construire un entrepôt
de données pour suivre l'évolution de ses ventes de chaussures. L’entreprise Chausséria
dispose de deux magasins « Chauss_Lyon » et « Chauss_Bron » et vend plusieurs modèles
de chaussures.
1. Proposez un modèle conceptuel et logique d’entrepôt de données DW_Chausseria pour
observer l’évolution des ventes en termes du nombre total de paires de chaussures vendues
par rapport aux axes MOIS, ANNÉE, MAGASIN et MODÈLE. Quel est le type du modèle
obtenu ? Argumentez.

2. On peut maintenant imaginer que la société désire aussi étudier la répartition de ses
ventes suivant d'autres critères, comme Genre (Homme/Femme/Enfant), Pointure, ou encore
Couleur. Proposer un nouveau modèle conceptuel de l’entrepôt de données
DW_Chausseria_Nouveau en prenant en compte toutes les dimensions anciennes et
nouvelles citées ci-dessus.

3. Soit la représentation relationnelle du data mart Chausseria_01_02. Proposez un tableau

multidimensionnel pour observer le nombre total de paires de chaussures vendues par
rapport aux axes MAGASIN et MODÈLE.

a. Tableau multidimensionnel selon les 2 axes MAGASIN et MODÈLE

b. Calculer l’opérateur CUBE sur le data mart Chausseria_01_02 avec l’approche ROLAP.

Exercice 5 :

Il s’agit de modéliser l’entrepôt de données (ED) des ventes d’une entreprise commerciale.
Cette entreprise vend des produits regroupés par familles de produits. Une vente correspond
à un produit et un seul ; la vente est effectuée par l’un des vendeurs du produit. La semaine
de vente est le numéro de semaine dans l’année. L’ED doit pouvoir fournir le chiffre
d’affaires des ventes d’un produit, par date, client, et vendeur, ainsi que toutes les
sommations possibles de chiffre d’affaires.
Les objets de l’ED sont les suivants :
1) produit, caractérisé par : code_produit, code_famille
2) client, caractérisé par : code_client, nom, csp (catégorie socio-professionnelle)
3) vente, caractérisée par : date, code_produit, code_service
4) vendeur, caractérisé par : code_vendeur, nom, code_service
5) date, caractérisée par : semaine, mois, année (la date s'écrit par exemple 20020402)

1. Donner les définitions des quatre termes suivants : table de faits, table de dimension,
indicateur (mesure), hiérarchie.

2. Schéma en étoile : tracer le schéma en étoile dimensionnel de l’ED, en précisant pour

chaque table sa nature dimensionnelle (table de faits ou table de dimension) que la nature
des champs.

3. Cube de données : Dans l’exemple traité, et représenté par le schéma en étoile, le cube
de données est un hyper cube à 4 dimensions : produit, client, vendeur, date.
Graphiquement, on peut dessiner en perspective 4 types de cubes à 3 dimensions. Définir
les 4 types. A quoi correspond chaque type?

3
4. Supposons un cube D représentant une coupe de l'hypercube à 4 dimensions, selon une
valeur de la variable date. Combien de tableaux à deux dimensions on peut obtenir à partir
de D. En tout, combien y a-t-il de types différents de tableaux à deux dimensions ?

Exercice 6 :

Soient les données suivantes :

4
Exercice 7

Une compagnie d’assurance de biens (automobile, immobilier, responsabilité civile) possède

une application transactionnelle de production permet de gérer les polices (contrats) de ses
clients ainsi que les sinistres (accidents) déclarés par ces clients.

1. Gestion des polices

Pour gérer les polices, les employés ou agents d’assurance peuvent effectuer les
transactions suivantes :

 Créer, mettre à jour ou supprimer une police d’assurance

 Créer, mettre à jour ou supprimer un risque (pour une police donnée)
 Créer, mettre à jour ou supprimer des biens assurés (voiture, maison) sur un risque
 Chiffrer ou refuser le risque
 Valider ou refuser la police

On enregistre dans ces transactions un grand nombre d’informations, et notamment : date

d’écriture (date de la transaction), date d’effet (date de début d’assurance), client
(personne(s) privée(s), personne morale), opérateur (employé, agent : chiffrage, vérificateur :
validation), risque (produit vendu par la compagnie d’assurance), couverture (description des
biens assurés), police (numéro de police, « note » de la police ou du risque,…) , transaction
(code transaction).

2. Gestion des sinistres

Pour gérer les sinistres déclarés par les clients, les employés ou agents d’assurance ont à
leur disposition les transactions suivantes :

 Créer, mettre à jour ou supprimer une déclaration de sinistre

 Créer, mettre à jour ou supprimer une expertise
 Créer, mettre à jour ou supprimer des paiements
 Clore le sinistre

Ces transactions comportent notamment : date d’écriture (date de la transaction), date d’effet
(date de déclaration), client, opérateur, risque, biens sinistrés, police, les tiers impliqués dans
le sinistre, les montants financiers (limites, déjà payé, reste à payer, …), code transaction.

3. Taille des bases de données

 Nombre de polices : 2 millions

 Moyenne de biens couverts par police : 10
 Nombre de transactions par an et par police : 12
 Nombre d’années : 3
 Taille d’une variable (clé ou indicateur) de table de faits : 8 octets
 Pourcentage de biens assurés donnant lieu à un sinistre par an : 5%
 Temps d’ouverture d’un sinistre : 1 an

Questions :

5
A partir de cette application transactionnelle, on veut créer un entrepôt de données
permettant de répondre aux questions suivantes :

- On ne s’intéresse qu’à la globalisation par mois des transactions.

- Pour chaque bien assuré, on veut connaître le montant de la prime (somme annuelle payée
par le client pour assurer le bien) associée au bien assuré, et le nombre de transactions du
mois pour ce bien.

- On veut aussi l’« état» de la police pour en spécifier les phases particulières : police
nouvellement créée, nouvellement modifiée, sinistre en cours, sinistre juste clos.

- On veut naturellement sortir des tableaux par client, agent ou employé, date d’effet, état,
avec toutes les sommations possibles y compris par police et risque.

- De même on veut pouvoir sortir des tableaux de bord par sinistre avec le total payé dans le
mois et le total reçu dans le mois pour ce sinistre. Les tableaux de bord « sinistre » doivent
pouvoir être édités par client, agent ou employé, date d’effet, état, avec toutes les
sommations possibles y compris par police et risque. On veut pouvoir établir des tableaux de
bord par client et bien assuré de l’activité sur le dossier (nombre de transactions, nombre de
sinistres), du chiffre d’affaire, du taux de sinistres et du rendement (ratio versements/prime),
et tous les totaux et sous totaux correspondants.

- On veut également déterminer la taille sur disque de l’ED.

On suivra la démarche suivante :

I. commencer par tracer quelques tableaux de bord à titre d’exemple de ce que peut éditer
l’ED : quelques (de l’ordre de 5) tableaux à deux dimensions pour les polices et quelques
uns pour les sinistres (toujours à deux dimensions). Tracer au moins un cube à trois
dimensions.

II. faire le schéma en étoile d’un magasin de données « police » ne prenant pas en compte
les sinistres. Tracer au moins un cube à trois dimensions.

III. de même, faire le schéma en étoile d’un magasin « sinistre »

IV. faire un seul ED de ces deux magasins. Y a-t-il des dimensions conformes ? Quels
tableaux de bord nouveaux peut-on alors éditer ?