85 j. akoka &i.wattiau conceptualisation : illustration person (ssn, name, address)...
TRANSCRIPT
1 J. AKOKA &I.WATTIAU
Conceptualisation : illustration• PERSON (ssn, name, address)
• EMPLOYEE(ssn, name, salary, hired-date)
• MANAGER(ssn, rank, promotion-date, deptno)
• CUSTOMER(ssn, custid, name, credit)
• DEPARTMENT(deptno, dept-name, location)
• PRODUCT(pronum, description)
• PRICE(pronum, minprice, maxprice)
• ORDER(ordid, order-date, prodid, custid)
• CARRIER(carrier-id, name, address)
• PROJECT(pronum, deptno, budget)
• WORK-FOR(ssn, deptno, start-date)
• CAN-PRODUCE(deptno, pronum, unit-cost)
• SHIPMENT(pack#, ordid, ship-date, carrier-id).
Le schéma relationnel initial
2 J. AKOKA &I.WATTIAU
Etape 1 :
- identification des entités PERSON, EMPLOYEE, MANAGER, CUSTOMER, DEPARTMENT, PRODUCT, PRICE et ORDER.
- suspicion d’homonymes ou d’héritages entre les clés de PERSON, EMPLOYEE, MANAGER et CUSTOMER d’une part et PRICE et PRODUCT d’autre part.
- recherche d’un identifiant pour la table relationnelle CARRIER
3 J. AKOKA &I.WATTIAU
Résultat de la première étape :
les lignes discontinues représentent les homonymes ou les liens de généralisation soupçonnés :
PERSON
EMPLOYEE MANAGER
CUSTOMER
PRICE
PRODUCT
DEPARTMENT
ORDER
4 J. AKOKA &I.WATTIAU
Etape 2 :
•Confirmation des relations d’inclusion suivantes
PERSON EMPLOYEE MANAGER et PERSONCUSTOMER
•Infirmation des autres
•Présomption d'associations entre entités :
- EMPLOYEE (ou MANAGER ou CUSTOMER ou PERSON) et DEPARTMENT ,
- deux associations entre DEPARTMENT et PRODUCT ,
- une association 1-1 entre PRICE et PRODUCT,
- deux associations entre DEPARTEMENT et PRICE,
- ORDER et une entité à déterminer
•Confirmation de Carrier-id comme identifiant de la table CARRIER
5 J. AKOKA &I.WATTIAU
Résultat de la deuxième étape :
(les ovales représentent des associations et les flèches des liens de généralisation) :
PERSON
EMPLOYEE
MANAGER
CUSTOMER
PRICE
PRODUCT
DEPARTMENT
ORDER
work-for
project
can-produce
? ?
? ?
? ?
1
1
shipment?
6 J. AKOKA &I.WATTIAU
Etape 3 : L'application des règles indiquées ci-dessous nous permet de confirmer les associations suivantes :
• work-for est une association reliant uniquement les entités EMPLOYEE et DEPARTMENT.
• a est une association 1-1 entre les entités PRODUCT et PRICE
• L'association can-produce entre DEPARTMENT et PRODUCT est consolidée.
• L'association shipment nous conduit à définir une entité organisationnelle appelée PACK.
• L'association project existant entre DEPARTMENT et PRODUCT reflète l'existence d'un homonyme contrairement à celle entre DEPARTMENT et PRICE.
• L'analyse du DML confirme l’homonymie entre la colonne Pronum de la table PROJECT et la colonne Pronum de la table PRICE ou PRODUCT. Le même raisonnement peut être appliqué à l'autre association project.
7 J. AKOKA &I.WATTIAU
Résultat de la troisième étape :
PERSON
EMPLOYEE
MANAGER
CUSTOMER
PRICE
PRODUCT
DEPARTMENT
ORDER
work-for
project
can-produce
? ?1
1
shipment
PACK
8 J. AKOKA &I.WATTIAU
Itération de l'étape 2 : Association project entre l'entité DEPARTMENT et une autre entité à découvrir
Itération de l'étape 3 : Confirmation de la nature de l'entité PROJECT (faible).
Résultat : PERSON
C u sto m er
EMPLOYEE
MANAGERORDER
PRODUCT
PRICE
DEPARTMENT
CARRIER
work-for
sh ip m en t
a
can-produce
PACK
M
N
NM
1
1
CUSTOMER
shipment
N
relatif à
P ro jectPROJECT
9 J. AKOKA &I.WATTIAU
Etape 4 : Détection de clés étrangères dans les tables relationnelles MANAGER, ORDER et SHIPMENT.
Nous obtenons alors les associations 1 : N potentielles.
Résultat : le symbole ---‰ représente une clé étrangère potentielle.PERSON
C u sto m er
EMPLOYEE
MANAGER
ORDER
PRODUCT
PRICE
DEPARTMENTCARRIER
work-for
sh ip m en t
can-produce
PACK
P ro ject
M
N
NM11CUSTOMER
shipment
N
PROJECT
relatif à
a
10 J. AKOKA &I.WATTIAU
PERSON
C u sto m erEMPLOYEE
MANAGER
ORDER
PRODUCT
PRICE
DEPARTMENT
CARRIER
work-for
sh ip m en t
has
can-produce
PACK
P ro ject
M
N
N
M
1
1
for fo r
for
N
1
1
N
from
N
1
1
N
forN
1
1
N
CUSTOMER
SHIPMENT
PROJECT
for
1
1
1
of of1
N
Etape 5 : Confirmation de toutes les clés étrangères.
L'association shipment
doit être
transformée
en entité.
11 J. AKOKA &I.WATTIAU
4.4.3.6. La désoptimisation du schéma physique
• Principe :
• Examiner les spécifications DDL pour suspecter des opérations d’optimisation
• Scanner les spécifications DML pour confirmer ou infirmer ces opérations d’optimisation
• S’il y a confirmation, vérifier dans les données pour valider les restructurations
• Réitérer le processus tant qu’il y a des opérations possibles
• Présenter le schéma logique restructuré au concepteur pour validation
• Opérations : jointure, projection, restriction, aplatissement.
12 J. AKOKA &I.WATTIAU
L’opération de jointure
• Principe :
• autorise la construction des relations formées par la concaténation des tuples de deux relations existantes selon le prédicat de jointure, incluant le plus souvent une clé étrangère.
• Exemple :
• Invoice(Invoice#,Customer#,Amount,Date)
• Customer(Customer#,Customer_name,Address)
• Incust(Invoice#,Customer#,Amount,Date,Customer_name,Address)
• Provoque une dénormalisation du schéma (3FN->2FN,2FN->1FN)
• 4 cas de jointure
13 J. AKOKA &I.WATTIAU
Jointure : cas 1
• La jointure est faite sur un attribut clé primaire des deux tables :
• R1(K, C1,C2,...,Cn) & R2(K, D1,D2,...,Dm)
=> R(K, C1,C2,...,Cn,D1,D2,...,Dm)
• introduit un grand nombre de valeurs nulles
• pas de dénormalisation : si R1 et R2 sont en 3FN, R est en 3FN
• Exemple :
•Employee(Employee_number,Rank,Salary)
•Career(Employee_number,Arrival_date,First_career_job,Starting_sal)
14 J. AKOKA &I.WATTIAU
Jointure : cas 2
• La jointure est faite sur un attribut clé primaire d’une table et clé étrangère de l’autre :
• R1(K1, C1,C2,...,Cn) & R2(K2, D1,D2,...,Dm,K1)
=> R(K2, C1,C2,...,Cn,D1,D2,...,Dm,K1)
• génère des données redondantes
• dénormalisation : R contient des dépendances fonctionnelles entre non-clés
• Exemple :
•Invoice(Invoice#,Customer#,Amount,Date)
•Customer(Customer#,Customer_name,Address)
15 J. AKOKA &I.WATTIAU
Jointure : cas 3
• La jointure est faite sur un attribut clé primaire d’une table et un attribut partie de clé de l’autre table :
• R1(K1, C1,C2,...,Cn) & R2(K1,K2, D1,D2,...,Dm)
=> R(K1,K2, C1,C2,...,Cn,D1,D2,...,Dm)
• génère des données redondantes
• dénormalisation : R contient des dépendances fonctionnelles entre partie de clé et non-clés (C1,C2,..,Cn)
• Exemple :
•Student(Student#,Name,Level)
•Result(Student# ,Course#,Grade)
16 J. AKOKA &I.WATTIAU
Jointure : cas 4
• La jointure est faite sur deux attributs non clés des deux tables :
• R1(K1, C1,C2,...,Cn,NK) & R2(K2, D1,D2,...,Dm,NK)
=> R(K1,K2, C1,C2,...,Cn,D1,D2,...,Dm,NK)
• rare
• si R1 et R2 sont en 3FN, R contient des données redondantes
• il existe des dépendances fonctionnelles entre une partie de clé (K1) et des non clés (C1,C2,...,Cn,NK).
• Exemple : joindre les deux tables suivantes sur la condition Headquarter-city=Production-city
• Supplier(Supplier#,Name,Address,Headquarter-city)
• Part(Part#,Part-name,Production-city)
17 J. AKOKA &I.WATTIAU
L’inversion de l’opération de jointure
• Principe :
• supprimer la jointure en la remplaçant par les deux relations d’origine
• c’est une opération de projection
• Détection:
• DDL : très peu (ou pas) de clauses NOT NULL
• DML : la plupart des requêtes sont des projections sur certains attributs, le plus souvent sur les mêmes attributs.
• Données : on détecte des dépendances fonctionnelles et des valeurs nulles
18 J. AKOKA &I.WATTIAU
Les règles de rétro-conception
• La règle Ru1 correspondant au cas 1 peut être paraphrasée comme suit :
• Soit la relation R(K, C1,C2,...,Cn,D1,D2,...,Dm)
SI il n’y a pas d’attribut Ci ou Di défini avec NOT NULL ET/OU
il y a plusieurs requêtes SQL avec les clauses SELECT,WHERE,ORDER BY et GROUP BY portant uniquement sur K et les Ci ET/OU
il y a plusieurs requêtes SQL avec les clauses SELECT,WHERE,ORDER BY et GROUP BY portant uniquement sur K et les Dj ET/OU
il n’y a pas de tuple contredisant la D.F. K->C1,C2,...,Cn ET/OU
il n’y a pas de tuple contredisant la D.F. K->D1,D2,...,Dm ET/OU
il y a des tuples ayant des valeurs nulles pour tous les Ci ET/OU
il y a des tuples ayant des valeurs nulles pour tous les Dj
ALORS MeRCI propose la décomposition de R en deux tables
R1(K,C1,C2,...,Cn) et R2(K,D1,D2,...,Dm)
19 J. AKOKA &I.WATTIAU
L’opération de projection
• Principe :
• simplifie une relation en réduisant sa largeur.
• permet de renommer des attributs et/ou de les permuter dans une table.
• Exemple :
• Employee(Employee#,Rank,Salary,Arrival-date,First-caree-job,Start-sal)
• Deux projections peuvent être faites conduisant aux tables suivantes :
• Payroll(Employee#,Rank,Salary)
• Career(Employee#,Arrival-date,First-caree-job,Start-sal)
• Remarques :
• Pas de perte de données
• Conserve les clés
• Ne provoque pas de dénormalisation
20 J. AKOKA &I.WATTIAU
L’inversion de l’opération de projection
• Principe :
• consiste à supprimer les tables obtenues par projection et à les remplacer par la table initiale contenant tous les attributs
• Détection:
• DDL : plusieurs relations ont des attributs clés primaires ou uniques avec le même nom et le même type de données
• DML : certaines requêtes SQL sont des jointures entre les clés des deux relations.
• Données : les attributs clés qui ont les mêmes noms ont un grand nombre de valeurs communes
21 J. AKOKA &I.WATTIAU
Les règles de rétro-conception
• Soit les relations R1(K1, C1,C2,...,Cn) et R2(K2,D1,D2,...,Dm)
SI K1 et K2 ont le même nom ET/OU
K1 et K2 ont le même type de données ET/OU
il y a une ou plusieurs requêtes SQL dont la clause WHERE contient une égalité ou une comparaison avec IN entre K1 et K2 ET/OU
l’intersection des valeurs de K1 et K2 contient un grand nombre de valeurs communes
ALORS MeRCI propose le regroupement de R1 et R2 en une relation
R(K1,C1,C2,...,Cn,D1,D2,...,Dm)
22 J. AKOKA &I.WATTIAU
L’opération de restriction
• Principe :
• forme une relation dont les tuples sont filtrés grâce à un prédicat ou condition de restriction
• Exemple :
• La relation Customer (Customer#, Customer-name, Address, Turnover)
• peut être restreint en deux relations
• Large_Customer (Customer#, Customer-name, Address, Turnover)
• et Small_Customer (Customer#, Customer-name, Address, Turnover)
• selon le montant du Turnover (inférieur ou supérieur à une borne)
• Remarques :
• Pas de perte de données
• Ne provoque pas de dénormalisation
23 J. AKOKA &I.WATTIAU
L’inversion de l’opération de restriction
• Principe :
• supprimer les tables obtenues par restriction et à les remplacer par la table initiale contenant tous les tuples (opération d’union).
• Détection:
• DDL : plusieurs relations ont le même schémas. Les attributs clés primaires ou uniques sont définis par le même type de données. Les autres attributs ont aussi le même nom, le même type, et éventuellement les mêmes contraintes (FOREIGN KEY,CHECK, etc...)
• DML : certaines requêtes SQL sont des unions entre les clés de deux relations (ou plus).
• Données : les attributs clés qui ont les mêmes noms ont un ensemble de valeurs disjointes.
24 J. AKOKA &I.WATTIAU
Les règles de rétro-conception
• Soit les relations R1(K1, C1,C2,...,Cn) et R2(K2,D1,D2,...,Dm)
SI K1 et K2 ont le même nom ET/OU
K1 et K2 ont le même type de données ET/OU
Ci et Dj ont le même nom et/ou le même type de données ET/OU
il y a une ou plusieurs requêtes SQL avec un opérateur UNION entre deux SELECT portant respectivement sur R1 et R2 et une clause WHERE contenant une condition sur K1 liée par OR à la même condition sur K2 ET/OU
l’intersection des valeurs de K1 et K2 est vide
ALORS MeRCI propose de transformer R1 et R2 en une relation unique
R(K1,C1,C2,...,Cn)
25 J. AKOKA &I.WATTIAU
L’opération d’aplatissement
• Principe :
• l’information peut être représentée comme des valeurs d’attributs, des noms d’attributs ou des noms de tables.
• l’opérateur d’aplatissement transporte l’information d’un niveau de représentation à un autre : des valeurs aux attributs.
• ce n’est pas un opérateur relationnel.
• s’applique uniquement aux attributs à type discret et ayant peu de valeurs - aplatit le type de champ dans la structure
• Exemple :
• La relation Courseplanning (Course#, Course-Day, Course-Name, Course-Hour) peut être aplatie en utilisant le jour :
Course (Course#, Course-Name, Monday-House, Tuesday-Hour, Wednesday-Hour, Thursday-Hour, Friday-Hour, Saturday-Hour).
• Réduit la clé
• Ne provoque pas de dénormalisation
26 J. AKOKA &I.WATTIAU
L’inversion de l’opération d’aplatissement
• Principe :
• remplacer plusieurs colonnes ayant le même type par un attribut décrivant ce type. L’inverse de l’aplatissement de R(K,C1,C2,...,Cn, D1,D2,...,Dm) sur les colonnes Ci remplace R par R1(K,K2, C,D1,D2,...Dm).
• Détection:
• DDL : la table aplatie a plusieurs colonnes de même type avec une partie de nom commune
• DML : certaines requêtes SQL ont des clauses WHERE avec le même prédicat sur les différentes colonnes du même type
• Données : les valeurs des colonnes qui ont le même type sont identiques.
27 J. AKOKA &I.WATTIAU
Les règles de rétro-conception
• Soit la relation R(K, C1,C2,...,Cn,D1,D2,...,Dm)
SI les Ci ont une partie du nom commune ET/OU
les Ci ont le même type de données ET/OU
il y a une ou plusieurs requêtes SQL avec une clause WHERE ou SET contenant une condition identique sur les différentes colonnes Ci ET/OU
l’intersection des valeurs des Ci contient plusieurs valeurs communes et une plage de valeurs communes
ALORS MeRCI propose de transformer R en R1(K,K1,C,D1,D2,...,Dm)
28 J. AKOKA &I.WATTIAU
American_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30))Arrival(flight_number/char(6);airport_code/char(6))Asian_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30))Departure(flight_number/char(6);airport_code/char(6))European_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30))Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2),
return/decimal(6,2))Flights(flight_number/char(6);aircraft/char(30),distance/integer,airline_code/char(3), airline_name/char(30))Int_Stops(flight_number/char(6),airport_code/char(6);airport_name/char(30),country_code/char(6), stop_number/integer)Restrictions(country_code/char(4), visa_type/char(30); conditions/text)Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text)Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date)Seat_Classes(seat_class_code/char(1); seat_class_name/char(30))Times(flight_number/char(6);mon_dep/decimal(4,2),mon_arr/decimal(4,2),tue_dep/decimal(4,2), tue_arr/decimal(4,2),wed_dep/decimal(4,2),wed_arr/decimal(4,2),
thu_dep/decimal(4,2),thu_arr/decimal(4,2),fri_dep/decimal(4,2),fri_arr/decimal(4,2),sat_dep/decimal(4,2),sat_arr/decimal(4,2),sun_dep/decimal(4,2),sun_arr/decimal(4,2))
Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1))
Désoptimisation : un exemple
29 J. AKOKA &I.WATTIAU
* (1) insert a new flight (that means, the flight, its times, its stops and its fares)* (2) delete a flight (that means, the flight, its times, its stops and its fares)* (3) modify times of a flight* (4) select the fares for each type for each airline about flights flying from airport A to airport B* (5) select the times of a given flight* (6) select the intermediate stops of a flight* (7) select the restrictiveness for a given country* (8) list the different countries and their continent names* (9) list the different airports and their respective countries* (10) list the different airlines characteristics* (11) select the different flights realized with a given aircraft* (12) what is the distance covered by a given flight
Liste des requêtes principales
30 J. AKOKA &I.WATTIAU
TABLES Ru1 Ru2 Ru3 Ru4 Ru5 Ru6 Ru7Am_Countries - - - - o X -Arrival - - - - X o -As_Countries - - - - o X -Departure - - - - X o -E_Countries - - - - o X -Fares - - - - - - -Flights - X - - - o -Int_Stops - - X - - - -Restrictions - - - - - - -Savers - - - - - - -Season - - - - - - -Seat_Classes - - - - - - -Times - - - - - o XTypes - - - - - - -
X signifie que la règle peut être appliquée à la table
o signifie que la table vérifie certaines conditions de déclenchement de la règle
- signifie la règle ne s’applique pas à la table
Application des règles aux tables de l’exemple
31 J. AKOKA &I.WATTIAU
Airline (airline_code, airline_name)Airport(airport_code; airport_name, country_code)Countries(country_code/char(6);country_name/char(30),restrictiveness/char(30), continent)Dep_arr(flight_number; airport_dep, airport_arr)Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2),
return/decimal(6,2))Flights(flight_number, aircraft, distance)Int_Stops(flight_number, airport_code; stop_number)Restrictions(country_code/char(4), visa_type/char(30); conditions/text)Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text)Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date)Seat_Classes(seat_class_code/char(1); seat_class_name/char(30))Times(flight_number/char(6),dep_arr;time) Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1))
Le schéma relationnel après la première itération de l’ensemble de règles
32 J. AKOKA &I.WATTIAU
Airline (airline_code, airline_name)Airport(airport_code; airport_name, country_code)Countries(country_code/char(6);country_name/char(30),restrictiveness/char(30), continent)Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2),
return/decimal(6,2))Flights(flight_number, aircraft, distance,airport-dep,airport-arr)Int_Stops(flight_number, airport_code; stop_number)Restrictions(country_code/char(4), visa_type/char(30); conditions/text)Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text)Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date)Seat_Classes(seat_class_code/char(1); seat_class_name/char(30))Times(flight_number/char(6),dep_arr;time) Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1))
Le schéma relationnel après une seconde itération de l’ensemble de règles
33 J. AKOKA &I.WATTIAU
Saverssaver-codesaver-namesaver-conditions
Seat Classesseat-class-codeseat-class-name
Typestype-code
Seasonsseason-codeseason-namestart-dateend-date
Faresconc-classsinglereturn
Flightsflight-numberaircraftdistanceairport-depairport-arr
Airlineairline-codeairline-name
Timesdaytime
Airportsairport-codeairport-name
Countriescountry-codecountry-namecontinent
Visavisa-type restrictions
conditions
mn
1 n
Int-Stopsstop-number
m
n
mn
mn
1
n
nm
1n
1n
n
1
Le schémaconceptuelrésultant
34 J. AKOKA &I.WATTIAU
4.5. Rétroconception des bases multidimensionnelles
• Objectif : extraire le schéma conceptuel d’une base de données multidimensionnelles à partir d’un schéma logique/physique
• Raisons :• la modélisation d’une base de données multidimensionnelle
joue un rôle important dans la conception d’un datawarehouse
• le schéma multidimensionnel d’un datawarehouse offre une vue intégrée des différentes sources de données opérationnelles
• le schéma multidimensionnel est dépendant• des besoins des utilisateurs• de la disponibilité des données des systèmes
opérationnels• de la structure de ces données
35 J. AKOKA &I.WATTIAU
• Raisons (suite) : • la plupart des projets de datawarehouse utilise une approche incrémentale
•on commence par un prototype offrant certaines fonctionnalités et utilisant un ensemble de données
•puis le prototype est affiné suivant les besoins (changeants) des utilisateurs
• les besoins des utilisateurs changent•nécessite une adaptation et une évolution du schéma
•par conséquent un coût de maintenance élevé• pour offrir une flexibilité et une réutilisation du schéma, le modèle doit être spécifié à un niveau conceptuel : ce n’est pas le cas des datawarehouses actuels
36 J. AKOKA &I.WATTIAU
Caractéristiques des systèmes multidimensionnels
• Les concepts d’OLAP: • consolidation : les données sont agrégées selon des
dimensions hiérarchisées• drill-down : une donnée agrégée est visualisée à un niveau de
détail choisi par l’utilisateur• slicing and dicing : les données sont visualisées selon
différentes perspectives (par exemple vente par région et canal de distribution)
• gestion des alertes et des seuils : des codes de couleur sont utilisés pour attirer l’attention sur certaines données
37 J. AKOKA &I.WATTIAU
• Caractéristiques des applications OLAP :• un appel à de très grands volumes de données• la présence des données agrégées• la comparaison des données agrégées hiérarchiques
et dans le temps• la présentation des données selon différentes
perspectives• la réalisation de calculs complexes• la présentation des données sous forme de tableaux
croisés facilement manipulables• la consultation des données sans les modifier.
38 J. AKOKA &I.WATTIAU
Architecture d’un datawarehouse
39 J. AKOKA &I.WATTIAU
Les modèles de données d’un datawarehouse
40 J. AKOKA &I.WATTIAU
Les modèles logiques/physiques - les concepts utilisés
Modèle en étoile Modèle enflocon
Modèlemultidimensionnel
dimension dimension dimension
table des faits table des faits variablemultidimensionnelle
attribut non cléde la table dedimension
attribut non clé dela table dedimension
variablemonodimensionnelle
opérateur drills-up
relation relation
41 J. AKOKA &I.WATTIAU
Le modèle en étoile
42 J. AKOKA &I.WATTIAU
Le modèle en flocon
43 J. AKOKA &I.WATTIAU
La rétroconception à l’aide de MeRCI -M
44 J. AKOKA &I.WATTIAU
Les étapes du processus
45 J. AKOKA &I.WATTIAU
La modélisation des règles de rétroconception
• Un méta-modèle du schéma conceptuel cible
• Un méta-modèle de la base de données multidimensionnelle
• Des règles de production qui opèrent sur les deux méta-modèles auxquelles on associe des facteurs de certitude
46 J. AKOKA &I.WATTIAU
Le méta-modèle de la base multidimensionnelle
Objet
nom
Dimension/Relation
Relation relie
0,n
2,2
Dimension
Variable
Variablemonodimensionnelle
Variablemultidimensionnelle
fait varier0,n
1,1
comporte
0,n
2,n
47 J. AKOKA &I.WATTIAU
Mapping entre les deux méta-modèles
48 J. AKOKA &I.WATTIAU
Les règles de rétroconception
• Règle de suspicion : une variable multidimensionnelle se rapportant à plus de deux dimensions peut devnir un attribut d’une association entre les entités désignées par ces dimensions.
• Règle de consolidation : les attributs des relations binaires M:N sont consolidés s’il existe plus d’un attribut non identifiant à la relation
• Règle de confirmation : une dimension devient l’identifiant d’une entité que l’on crée
49 J. AKOKA &I.WATTIAU
Un exemple
50 J. AKOKA &I.WATTIAU
Application des règles de l’étape 1
51 J. AKOKA &I.WATTIAU
Application des règles de l’étape 2
52 J. AKOKA &I.WATTIAU
Application des règles de l’étape 3
53 J. AKOKA &I.WATTIAU
Application des règles de l’étape 4
54 J. AKOKA &I.WATTIAU
• Approches "manuelles"
• Approches algorithmiques• en établissant des hypothèses simplificatrices,
• ou en définissant des pré-traitements "manuels",
• les algorithmes convertissent automatiquement des schémas logiques en schémas conceptuels
• Approches expertes• tentent de "pousser plus loin" l'automatisation en définissant
des heuristiques
5. Conclusion : Les types d'approches
55 J. AKOKA &I.WATTIAU
• Plus de 50 articles sur la rétro-conception de bases de données
• Un grand nombre de règles dont :– certaines résultent de l'inversion des règles de passage de
ER en relationnel et sont contenues dans toutes les approches
– d'autres consistent en l'utilisation d'heuristiques et sont plus spécifiques à certaines méthodologies
• L'enjeu est d'offrir des AGL incluant une fonction intelligente de rétro-conception
5. Conclusion