36 j. akoka &i.wattiau illustration à l'aide de l'approche de fong & ho en 1993...
TRANSCRIPT
1 J. AKOKA &I.WATTIAU
• Illustration à l'aide de l'approche de Fong & Ho en 1993
• Transformation d'un schéma réseau en un schéma Entité-Relation Etendu (EER)
4.3. La rétroconception de schémas réseaux
2 J. AKOKA &I.WATTIAU
• Etape 1 : dériver les entités
• Etape 2 : dériver les associations
• Etape 3 : retirer les associations redondantes– sets implantés pour des raisons de performance
SetAssociation 1:1Association 1:nRelation IS-A
4.3. La rétroconception de schémas réseaux
Type d'enregistrementEntité
Entité faible
3 J. AKOKA &I.WATTIAU
• Etape 4 : dériver les associations N:M ou n-aires
• Etape 5 : dériver les généralisations et/ou les associations 1:1
• Etape 6 : dériver les agrégations • quand une association doit être reliée à d'autres entités
Sets connectés au mêmeenregistrement
Association N-M
Association n-aire
SetAssociation 1:1 Relation IS-A
4.3. La rétroconception de schémas réseaux
4 J. AKOKA &I.WATTIAU
• Etape 7 : dériver les attributs
• Etape 8 : dériver des associations cachées
• Etape 9 : dériver les clés• trouver une clé pour chaque entité
• Etape 10 : tracer le graphe EER
Champs des enregistrements
Champ cléou non clé
Champ clédupliqué
Association 1:1 Association M:N
4.3. La rétroconception de schémas réseaux
5 J. AKOKA &I.WATTIAU
Un exemple : le système d’inscription d’une université
• Le schéma CODASYL initial
SYSTEM
(CO)COURSE course#
course-location
(PR)PREREQUISITE
prerequisite#prerequisite-title
(DEP)DEPARTMENT
department#department-name
(ST)STUDENT
student#student-name
(GR)GRADE
(IN)INSTRUCTOR
instructor-nameinstructor-address
(SE)SECTION
section#
grade
6 J. AKOKA &I.WATTIAU
• Etape 1 : dérivation des entités– Department, Instructor, Course, Prerequisite et Student sont
les entités du modèle
COURSE course#
PREREQUISITE
prerequisite#
DEPARTMENT
department#
STUDENT
student#
INSTRUCTOR
instructor-name
7 J. AKOKA &I.WATTIAU
• Etape 2 : dérivation d’associations 1:1, 1:n ou IS-A
– Association 1:n entre Department et Instructor
– Association 1:1 entre Course et Prerequisite
COURSE course#
PREREQUISITE
prerequisite#
DEPARTMENT
department#
STUDENT
student#
INSTRUCTOR
instructor-name
1
1
1
n
8 J. AKOKA &I.WATTIAU
• Etape 4 : dérivation des associations m:n– Association m:n entre Instructor et Course, appelée Section
COURSE
course#
PREREQUISITE
DEPARTMENT
department#
STUDENT
INSTRUCTOR
instructor-name
1
1
1
n
SECTIONmn
prerequisite#
student#
9 J. AKOKA &I.WATTIAU
• Etape 6 : dérivation des agrégations– L’association m:n entre Instructor et Course, appelée Section, est transformée en entité pour être associé à l’étudiant à travers une autre association m:n
COURSE
course#
PREREQUISITE
DEPARTMENT
department#
STUDENTINSTRUCTOR
instructor-name
1
1
1
n
SECTIONmn
GRADEm n
student#
prerequisite#
10 J. AKOKA &I.WATTIAU
• Etape 7 : dérivation des attributs des entités–Les champs ST.student-name, DE.department-name, IN.instructor.address, SE.section#, CO.course-location,GR.grade et PR.prerequisite-title sont transférés vers les entités respectives
COURSE
course#course-location
PREREQUISITE
DEPARTMENT
department#department-name
STUDENTINSTRUCTOR
instructor-nameinstructor-address
1
1
1
n
SECTIONmn
GRADEm n
prerequisite#prerequisite-title
student#student-name
section# grade
11 J. AKOKA &I.WATTIAU
• Etape 8 : dérivation des clés des entités
COURSE
course#course-location
PREREQUISITE
DEPARTMENT
department#department-name
STUDENTINSTRUCTOR
instructor-nameinstructor-address
1
1
1
n
SECTIONmn
GRADEm n
prerequisite#prerequisite-title
student#student-name
section#
Entité Clé
Department department#
Student student#
Instructor department#instructor-name
Course course#
Prerequisite prerequisite#
grade
12 J. AKOKA &I.WATTIAU
• Etape 9 : production du schéma EER
COURSE
course#course-location
PREREQUISITE
DEPARTMENTdepartment#department-name
STUDENTINSTRUCTOR
department#instructor-nameinstructor-address1
1
1
n
SECTIONmn
GRADEm n
prerequisite#prerequisite-title
student#student-name
section# grade
HIRE
COURSE-PRER
13 J. AKOKA &I.WATTIAU
• Beaucoup d'approches ont été décrites pour produire manuellement ou de façon automatique une représentation EER d'une base relationnelle
• Nous illustrons ici à l'aide d'un algorithme proposé par Fonkam & Gray en 1992
• L'algorithme suppose que le schéma relationnel initial est en 3ème Forme Normale
4.4. La rétroconception de schémas relationnels
14 J. AKOKA &I.WATTIAU
• Etape 1 : Renommage des attributs– l'utilisateur fournit l'information sur les homonymes et
synonymes entre les différents noms des tables
– à la fin du renommage, deux noms identiques désignent le même concept et deux noms différents distinguent deux concepts
• Etape 2 : Recherche des relations IS-A– au travers des définitions des vues relationnelles
– par examen systématique des tables ayant une même clé
• Etape 3 : Dérivation des entités régulières– relations avec un seul attribut formant la clé primaire
– relations avec une clé primaire composée qui se retrouve clé étrangère dans une autre table et dont les composants ne sont jamais seuls dans une autre table
4.4.1. Méthode de Fonkam & Gray
15 J. AKOKA &I.WATTIAU
• Etape 4 : Dérivation des entités faibles– relations avec une clé composée de la clé primaire d'une
entité et d'une "dangling key"
• Etape 5 : Dérivation des associations M:N– relations avec une clé composée des clés primaires d'autres
tables
• Etape 6 : Dérivation des associations 1:N– relations avec une clé primaire qui se retrouve clé étrangère
dans une autre table
4.4.1. Méthode de Fonkam & Gray
16 J. AKOKA &I.WATTIAU
Un exemple : la base relationnelle des ressources humaines d’une université
� person(ssn,name,address)� student(stud_id,ssn,sname,address)� undergrad(undergrad_id,ssn,year_of_study,sname,address)� course(number,name,hour)� enrollment(cou_number,undergrad_id,date)� employee(number,ssn,name,address,salary,building_num,room)� employee_project(empnum,proj_num,hours_spent)� department_project(deptnum,projnum,budget)� job(job#,description,salary_range)� employee_job(empnum,jobnum)� location(building#,room,description,capacity)
les clés sont soulignéesles clés candidates sont en italiquesles relations sous-type/supertype sont représentées par des clés communes
17 J. AKOKA &I.WATTIAU
• Etape 1 : renommage des attributs
� person(ssn,name,address)� student(student_stud_id,ssn,sname,address)� undergrad(student_stud_id ,ssn,year_of_study,sname,address)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,name,address,salary,location_bu
ilding#,location_room)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)
18 J. AKOKA &I.WATTIAU
• Etape 2 : recherche des relations IS-A
• Description de vue :• R1 : student(stud_id,sname,address)• R2 : undergrad(undergrad_id,year_of_study)• V : undergrad_view([[undergrad_id,undergrad],[year_of_study,undergrad],[sname,student],[address,student]],[[undergrad_id,stud_id]])
permet d’identifier la relation entre student et undergrad.
• Tables ayant une clé commune :• Person, Student, Undergrad et Employee
permet de générer des relations de sous-type et de supprimer les attributs héritables.
19 J. AKOKA &I.WATTIAU
• Etape 2 : recherche des relations IS-A
� person(ssn,name,address)� student(student_stud_id,ssn)� undergrad(student_stud_id ,ssn,year_of_study)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,salary,location_building#,location
_room)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)� soustype(person,student)� soustype(person,employee)� soustype(student,undergrad)
20 J. AKOKA &I.WATTIAU
• Etape 3 : dérivation des entités régulières
� person(ssn,name,address)� student(student_stud_id,ssn)� undergrad(student_stud_id ,ssn,year_of_study)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,salary,location_building#,locati
on_room)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)� soustype(person,student)� soustype(person,employee)� soustype(student,undergrad)
Les tables en gras sont transformées en entités régulières
21 J. AKOKA &I.WATTIAU
• Etape 3 : dérivation des entités régulières
PERSON
STUDENT EMPLOYEE
UNDERGRAD
COURSE
JOB
LOCATION
22 J. AKOKA &I.WATTIAU
• Etape 4 : dérivation des entités faibles
� person(ssn,name,address)� student(student_stud_id,ssn)� undergrad(student_stud_id ,ssn,year_of_study)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,salary,location_building#,location
_room)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)� soustype(person,student)� soustype(person,employee)� soustype(student,undergrad)
Les tables en gras sont transformées en entités faibles
23 J. AKOKA &I.WATTIAU
• Etape 4 : dérivation des entités faibles
PERSON
STUDENT EMPLOYEE
UNDERGRAD
COURSE
JOB
LOCATION
PROJECT
DEPARTMENT
works on
runs
1 n
1
n
24 J. AKOKA &I.WATTIAU
• Etape 5 : dérivation des associations m:n
� person(ssn,name,address)� student(student_stud_id,ssn)� undergrad(student_stud_id ,ssn,year_of_study)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,salary,location_building#,location
_room)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)� soustype(person,student)� soustype(person,employee)� soustype(student,undergrad)
Les tables en gras sont transformées en associations m:n
25 J. AKOKA &I.WATTIAU
PERSON
STUDENT EMPLOYEE
UNDERGRAD
COURSE
JOB
LOCATION
PROJECT
DEPARTMENT
works on
runs
1 n
1
n
• Etape 5 : dérivation des associations m:n
enrollment
m
n
works on
m
n
26 J. AKOKA &I.WATTIAU
• Etape 6 : dérivation des associations 1:n
� person(ssn,name,address)� student(student_stud_id,ssn)� undergrad(student_stud_id ,ssn,year_of_study)� course(course_number,name,hour)� enrollment(course_number, student_stud_id,date)� employee(employee_number,ssn,salary,location_building#,location_r
oom)� employee_project(employee_number,project#,hours_spent)� department_project(dept#,project#,budget)� job(job#,description,salary_range)� employee_job(employee_number,job#)� location(location_building#,location_room,description,capacity)� soustype(person,student)� soustype(person,employee)� soustype(student,undergrad)
Les tables en gras sont transformées en associations 1:n
27 J. AKOKA &I.WATTIAU
• Etape 6 : dérivation des associations 1:n
PERSON
STUDENT EMPLOYEE
UNDERGRAD
COURSE
JOB
LOCATION
PROJECT
DEPARTMENT
works on
runs
1 n
1
n
enrollment
m
n
works on
m
n
lives at
1
n
28 J. AKOKA &I.WATTIAU
4.4.2. Comparaison de quelques approches de rétro-conception de bases relationnelles
Sources d’information utiliséesApproches DDL DML Données Utilisateur
[Andersson, 1994] ** ** *
[Chiang et al., 1994] ** ** *
[Fonkam & Gray, 1992] ** * **
[Hainaut et al., 1992] ** ** *
[Jeusfeld et Johnen, 1994] **
[Petit et al., 1994] * ** * *
[Premerlani & Blaha, 1994] ** * ** *
[Signore et al., 1994] ** ** *
[Vermeer & Apers, 1995] ** ** **
Légende : * utilise partiellement** exploite intensivement
29 J. AKOKA &I.WATTIAU
4.4.3. L'approche MeRCI
Monde réel
Modélisation conceptuelle
Schéma EER
Conception logique
Schéma relationnel 3FN
Conception physique
Schéma physique optimisé
Mise en oeuvre
Spécifications DDL, DML, données
Description du monde réel
Description sémantique
Schéma EER
Conceptualisation (du schéma logique)
Schéma relationnel 3FN
Désoptimisation
Schéma physique
Extraction (du schéma physique)
Cycle de développement d'une base de données
Méthode de rétro-conception MeRCI
Spécifications DDL, DML, données
30 J. AKOKA &I.WATTIAU
4.4.3.1. L'extraction du schéma physique
• Objectif : – obtenir une description complète et détaillée du schéma
physique
• Moyens : – dictionnaire de données, spécifications DDL,
– états de sortie,
– écrans de saisie,
– structures cachées dans les codes sources.
31 J. AKOKA &I.WATTIAU
• Objectif :– détecter les opérations d'optimisation qui ont pu être
effectuées sur le schéma logique d'origine, pour des raisons de performance
• Résultat de la phase :– un schéma logique restructuré 3FN
– validé par le rétro-concepteur.
4.4.3.2. La désoptimisation du schéma physique
32 J. AKOKA &I.WATTIAU
• Objectif : – trouver tous les éléments du schéma conceptuel :
• entités
• associations, cardinalités
• généralisations/spécialisations
• etc.
– à partir :
• du schéma relationnel 3FN
• des informations disponibles dans les spécifications DDL, DML et dans les données.
4.4.3.3. La conceptualisation du schéma logique
33 J. AKOKA &I.WATTIAU
• Objectif : – caractériser les objets de l'univers du discours
• Moyens :– paraphrasage du schéma conceptuel
– schéma des besoins
• traduit le contenu des spécifications SQL décrites dans la base
– schéma des traitements possibles
• analyse les chemins du schéma conceptuel pour produire des requêtes nouvelles
4.4.3.4. La description sémantique
34 J. AKOKA &I.WATTIAU
Architecture de MeRCI
KS1
KS2
KS6
Control data
Control
Blackboard data
.
..
35 J. AKOKA &I.WATTIAU
Transfor-
mationsde
modèlesde
MeRCI
Database
Database Model
Conceptual Model
Semantic Model
KS1
KS2 KS3
KS4
KS5
KS6
MODELE DE LABASE DE DONNEES
MODELE CONCEPTUEL
MODELE SEMANTIQUE
Base dedonnées
36 J. AKOKA &I.WATTIAU
4.4.3.5. La conceptualisation dans MeRCI
• Principes– progressivité de la découverte sémantique
– richesse sémantique, fiabilité et efficacité
– structuration des concepts
Présomption Consolidation Confirmation
DDL DML Données
EntitésAssociations
Généralisations
37 J. AKOKA &I.WATTIAU
Présomption Consolidation ConfirmationEtape 1 • Généralisations
• Identification destables
• Entités régulières
Etape 2 • Entités faibles• Entités
organisationnelles• Associations
• Généralisations• Identification des
tables
• Généralisations• Identification des
tables• Associations
Etape 3 • Entités faibles• Entités organi-
sationnelles• Associations
• Généralisations• Entités faibles• Entités organi-
sationnelles• Associations
Etape 4 • Clés étrangères • Clés étrangères
Etape 5 • Clés étrangères• Associations
• Clés étrangères• Associations
4.4.3.5. La conceptualisation dans MeRCI
38 J. AKOKA &I.WATTIAU
Le méta-modèle conceptuel
Objet
Entité Association
Entitéorganisation-nelle
Entitérégulière
Entitéfaible
hérite de Patterôlecardinalité
Identifiant
Attributcaractérise
identifie
dépend de
générique
spécifique
nom
degré
numéro
nomdomaine
composant1 N
N
N
1
1
39 J. AKOKA &I.WATTIAU
Indexnomunique
Le méta-modèle de la base de
données
Groupe colonnesobligatoiresansdoubleclé-accèsclé potentielle
peut-être 1 peut-être 2peut-être 3
Clé étrangèrenom
Clénomprimaire
référence
a valeurscommunes
inclusion
comparé
a valeurs identiques
Vuenomopérations
comprend
Colonnenomnomcodedomaine
homonymessynonymes
Tablenom composé
40 J. AKOKA &I.WATTIAU
Mapping récursif sur le modèle de la base relationnelle
Concept relationnel Concept relationnel(source) (cible)Colonne HomonymeVue Groupe de colonnes.comparé
Groupe de colonnes.clé accèsGroupe de colonnes.clé potentielle
Colonne.homonyme Groupe de colonnes.inclusionClé étrangère
Groupe de colonnes.inclusion HomonymeGroupe de colonnes.a valeurs communes Homonyme
41 J. AKOKA &I.WATTIAU
Mapping du modèle relationnelvers le modèle EER
Concept relationnel Concept entité-association(source) (cible)Table Entité régulière, faible ou organisationnelle
HéritageAttributIdentifiant
Colonne AttributEntité organisationnelleIdentifiant
Index AttributIdentifiant
Clé étrangère Association 1-1 ou 1-NHéritage
etc.
42 J. AKOKA &I.WATTIAU
Les règles du système expert
• Les règles sont réparties en trois catégories :– règles de suspicion : présomption d’une sémantique,– règles de consolidation : renforcement d’une
présomption– règles de confirmation : confirmation d’une
sémantique.
• Les catégories sont matérialisées par des degrés de confiance, facteurs de certitude associés aux règles
43 J. AKOKA &I.WATTIAU
Exemple de règle de suspicion
• RP1 : Si la base de données contient deux tables T1 et T2 contenant une colonne de nom C Alors C peut être un homonyme.
• Exemple :– PERSON (number, name, address)
– COURSE (number, description, level)
• La comparaison des tables conduit aux deux hypothèses contradictoires suivantes :– l’attribut number dans les deux tables ne correspond pas au
même concept (homonyme).
– l’attribut number correspond au même concept. En conséequence, il existe une hiérarchie de généralisation (IS-A) entre les entités PERSON et COURSE.
44 J. AKOKA &I.WATTIAU
RP3 : Si la table T1 a une colonne de nom C avec une certitude 1
et la table T2 a une colonne de nom C avec une certitude 1
et T1 est une entité avec une certitude 1
et T2 est une entité avec une certitude 1
et C est un identifiant de T1 avec une certitude 1
et C est un identifiant de T2 avec une certitude 1
Alors il existe un lien d’héritage entre T1 et T2 avec une certitude p1.
Exemple de règle de présomption avec insertion des certitudes
45 J. AKOKA &I.WATTIAU
Exemple de règle de consolidation– PERSON (number, name, address)
– COURSE (number, description, level)
• La suspicion sur la nature de l’attribut number peut être confirmée ou réfutée par les analyses suivantes :– Les deux attributs number sont-ils définis avec le
même type de données ? Si non, ils sont homonymes.
– Y a-t-il une requête incluant une jointure conditionnée par l’égalité de ces deux attributs ? Si oui, ils ne sont pas homonymes.
– Ces deux attributs ont-ils un grand nombre de valeurs communes ? Si oui, ils ne sont probablement pas homonymes.
46 J. AKOKA &I.WATTIAU
Exemple de règle de consolidation avec insertion des certitudes
RCS13 : Si il existe un lien d’héritage entre T1 et T2 avec une certitude p1
et la table T1 a une colonne identifiante de nom C avec une certitude 1
et la table T2 a une colonne identifiante de nom C avec une certitude 1
et T1.C est inclus dans T2.C avec une certitude 1
Alors il existe un lien d’héritage entre T1 et T2 avec une certitude p2
et T1.C et T2.C ne sont pas des homonymes.
47 J. AKOKA &I.WATTIAU
Exemple de règle de confirmation• Une entité faible est confirmée quand il existe
une table dont :– la clé est composée de plusieurs attributs
• ceci peut être explicite dans les spécifications DDLou suspecté dans les spécifications DML et/ou dans les données.
– un composant de la clé est clé d’une autre table :
• ceci peut être explicite grâce à une clause REFERENCES dans les spécifications DDL ou suspecté par la présence de noms identiques non homonymes.
– l’autre composant de la clé n’est pas contenu dans une autre table
– il n’y a pas de spécification DML impliquant uniquement cet autre composant.
48 J. AKOKA &I.WATTIAU
Exemple de règle de confirmation avec introduction des certitudes
RCF4 : Si il existe une association entre les entités T1 et T2 avec une certitude p2
et K1 et K2 forment un identifiant de T avec une certitude p2
et K1 est un identifiant de T1 avec une certitude p2
et K2 est un identifiant de T2 avec une certitude p2
et T.K1 est inclus dans T1.K1 avec une certitude 1
et T.K2 est inclus dans T2.K2 avec une certitude 1
Alors il existe une association M-N entre les entités T1 et T2 avec unecertitude 1.
49 J. AKOKA &I.WATTIAU
Facteurs de certitude
• Quatre valeurs possibles :– 1 correspond à une information considérée comme sûre.
• généralement extraite des spécifications DDL.
– 0 correspond au cas où il n’y aucune source d’information concernant un concept.
• Par exemple, column. index. unique. vrai avec certitude 0 indique qu’il n’y pas de spécification DDL avec un index unique défini sur la colonne.
– p1 correspond à la valeur de suspicion
• correspond à l’exploration d’une source d’information
– p2 (supérieur à p1) correspond au cas où des informations provenant de sources différentes se consolident.