Economic Analysis and Data Warehousing for Retail and Insurance Companies

Institut Supérieur des Études Technologiques
1/12
100%
Rendu du PDF...
Page 1 sur 12Lecteur de document UniversityLib

Economic Analysis and Data Warehousing for Retail and Insurance Companies

Institut Supérieur des Études Technologiques · Data Warehousing and Business Intelligence · notes

Browse all intelligence artificielle et données documents

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

1/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

2/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Remarque :

  • La plupart des attributs dimensionnels ont un ID ainsi qu'un champ descriptif. Par exemple, dans la table Date, le mot 'Novembre' n'est pas suffisant pour identifier avec précision ce mois, car on le retrouve dans chacune des années. Il faut donc un attribut idMois (ex: '11/2010') ainsi qu'un attribut descriptif descrMois (ex: 'Novembre'). C'est la même chose pour l'attribut ville: le même nom de ville peut se trouver dans plusieurs pays ou même plusieurs fois dans un même pays;

  • Nous avons créé une table TypeClient selon la stratégie de mini-dimension. L'avantage est que la table TypeClient peut être pré-générée (toutes les combinaisons possibles de sexe, ville, groupe d'âge, etc.). De même, les tables Destination, Date, Forfait, Promotion et CanalVentes peuvent également être prégénérée et ne sont (presque) jamais modifiées. Seule la table de dimension Client est modifiée à chaque fois qu'un client s'ajoute au système;

  • La clé primaire de la table de faits Vente est une clé composée car il est très rare que l'on accède individuellement les lignes de cette table. En revanche, les clés primaires des tables de dimension sont toujours des clés artificielles simples (ex: NUMBER).

    2. Niveaux de hiérarchies

Advertisement

Les niveaux d'une hiérarchie doivent avoir une relation 1 à plusieurs : un parent peut avoir plusieurs enfants (ex : une année a plusieurs mois) mais chaque enfant n'a qu'un seul parent (ex : le mois '11/2010' appartient uniquement à l'année 2010).

Table de dimension Hiérarchies
Destination idDestination ← idVille ← idPays ← idRégion ← tous
Date idDate ← idMois ← année ← tous
Forfait idForfait ← tous
Client idClient ← tous
TypeClient idTypeClient ← idVille ← idProvince ← idPays ← tous
CanalVente idCanal ← tous
Promotion idPromotion ← tous
ModePaiement idModePaiement ← tous

3. Stratégie d’agrégation :

Pour définir la stratégie d'agrégation, il faut choisir, pour chaque dimension, un niveau hiérarchique permettant de faciliter l'analyse. L'objectif est d'accélérer les calculs en précalculant les agrégations faites dans les requêtes analytiques fréquentes. Ainsi, on prévoit que les analyses se feront aux niveaux suivants:

3/12

Dimension Niveau hiérarchique retenu
Destination idPays
Date (achat) tous
Date (départ) idMois
Forfait idForfait
Client tous
TypeClient idProvince
CanalVente idCanal
Promotion idPromotion
ModePaiement tous

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

4/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

5/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Advertisement

Commençons par créer une table de faits très simple, avec deux dimensions et un indicateur.

1- première dimension : le mois de « production » concaténé à l’année. On appelle mois de production le mois lors duquel le client a signé son contrat. Exemple de valeur : « 1204 » pour décembre 2004.

2- deuxième dimension : le type de risque (produit). On suppose pour simplifier que la compagnie d’assurance vend seulement trois produits :

♦ l’assurance automobile (type de produit A) ♦ l’assurance habitation (type H) ♦ l’assurance responsabilité civile (type R)

3- indicateur : le chiffre d’affaires du mois. Il s’agit de la somme des montants des contrats

  • pour un produit donné – signés dans le mois.

Début janvier 2005, un programme (ETL) charge dans cet entrepôt de données une couche composée de 3 enregistrements seulement. Exemple de la couche chargée début janvier 2005 :

Pour toute l’année 2004, cette base de faits comporte 36 enregistrements (3 par mois * 12 mois) Ils permettent déjà, par exemple, d’éditer 4 tableaux :

  • évolution au cours de l’année du CA par type de risque (3),

  • évolution au cours de l’année du CA tous risques confondus (1), Exemple de tableau pour Type_risque = R (responsabilité civile) avec 1 seule dimension, le mois et l’indicateur :

Advertisement

6/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Exemple de tableau avec les deux dimensions, le mois et le type de risque, et 1 indicateur, le CA.

Ajoutons une dimension, la note du risque Lorsqu’il chiffre le risque, l’agent lui donne une note de 1 à 3 en estimant la probabilité de coût pour l’entreprise, à partir d’un certain nombre de critères (classement du client, caractéristiques des biens assurés, etc...). 1 probabilité de coût élevé 2 probabilité de coût moyen 3 probabilité de coût faible Les couches de novembre et de décembre 2004 deviennent :

7/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Figure 5

Et le cube peut être représenté par le « cube » (3,3,2) ci-dessous. Dans chaque élément du tableau, la valeur de l’indicateur CA.

A ce stade, nous avons une base de faits du magasin « police » comportant les 4 variables suivantes : Mois||année dimension - élément de la clé multiple Type risque dimension - élément de la clé multiple Note dimension - élément de la clé multiple CA indicateur Créons un deuxième magasin (datamart) « sinistre » avec pour commencer la table de faits suivante :

8/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Advertisement

9/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

A partir du même ED, on peut aussi éditer le tableau suivant (ici limité à novembre et décembre), en ajoutant la note à partir de la table de faits « police » et en calculant le ratio paiement / CA du mois :

10/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

11/12

ISET Rades Mastère MPBI-M1 I. BEN TARBOUT

Taille totale : 36 millions x 9 (champs) x 8 (octets) = (environ) 2.6 Giga-octets

12/12