36 J. AKOKA &I.WATTIAU Illustration à l'aide de l'approche de Fong & Ho en 1993 Transformation d'un...

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


• 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


Type d'enregistrementEntité

Entité faible


• 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



• 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



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


• 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


• 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


• 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#


• 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#


• 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


STUDENTINSTRUCTOR


1

1

1

n

SECTIONmn

GRADEm n



section# grade


• Etape 8 : dérivation des clés des entités

COURSE


PREREQUISITE

DEPARTMENT


STUDENTINSTRUCTOR


1

1

1

n

SECTIONmn

GRADEm n



section#

Entité Clé

Department department#

Student student#

Instructor department#instructor-name

Course course#

Prerequisite prerequisite#

grade


• Etape 9 : production du schéma EER

COURSE


PREREQUISITE

DEPARTMENTdepartment#department-name

STUDENTINSTRUCTOR

department#instructor-nameinstructor-address1

1

1

n

SECTIONmn

GRADEm n



section# grade

HIRE

COURSE-PRER


• 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


• 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


• 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


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


• 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)


• 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.


• 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)


• 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


• Etape 3 : dérivation des entités régulières

PERSON

STUDENT EMPLOYEE

UNDERGRAD

COURSE

JOB

LOCATION


• Etape 4 : dérivation des entités faibles



Les tables en gras sont transformées en entités faibles


• Etape 4 : dérivation des entités faibles

PERSON

STUDENT EMPLOYEE

UNDERGRAD

COURSE

JOB

LOCATION

PROJECT

DEPARTMENT

works on

runs

1 n

1

n


• Etape 5 : dérivation des associations m:n



Les tables en gras sont transformées en associations m:n


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


• 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


• 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


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


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


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.


• 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


• 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


• 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


Architecture de MeRCI

KS1

KS2

KS6

Control data

Control

Blackboard data

.

..


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


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


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


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


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é


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


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.


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


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.


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


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.


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.


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.


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.


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.

36 J. AKOKA &I.WATTIAU Illustration à l'aide de l'approche de Fong & Ho en 1993 Transformation d'un...

Documents

Transcript of 36 J. AKOKA &I.WATTIAU Illustration à l'aide de l'approche de Fong & Ho en 1993 Transformation d'un...