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#

• 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

• 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

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

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

SECTIONmn

GRADEm n

section# grade

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

COURSE

PREREQUISITE

DEPARTMENT

STUDENTINSTRUCTOR

SECTIONmn

GRADEm n

section#

Entité Clé

Department department#

Student student#

Instructor department#instructor-name

Course course#

Prerequisite prerequisite#

• Etape 9 : production du schéma EER

COURSE

PREREQUISITE

DEPARTMENTdepartment#department-name

STUDENTINSTRUCTOR

department#instructor-nameinstructor-address1

SECTIONmn

GRADEm n

section# grade

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

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

LOCATION

PROJECT

DEPARTMENT

works on

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

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

PERSON

STUDENT EMPLOYEE

UNDERGRAD

COURSE

LOCATION

PROJECT

DEPARTMENT

works on

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

enrollment

works on

• 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

LOCATION

PROJECT

DEPARTMENT

works on

enrollment

works on

lives at

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

Control data

Control

Blackboard data

Transfor-

mationsde

modèlesde

Database

Database Model

Conceptual Model

Semantic Model

KS2 KS3

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

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

degré

numéro

nomdomaine

composant1 N

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

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

Schéma Directeur “Zaerdegaard”

La sécurité informatique - Site de Mohamed Amine … · Wattiau/Akoka 197 5. Politique de sécurité informatique RFC2196 : Une politique de sécurité est une déclaration formelles

Comment aborder les marchés des BIC (Brésil, Inde, Chine)? Présenté par Ofure EMONFOMWAN, Agnès FONG,, Sabine FRAISSE, Sandrine FORT, Julie GILLERY, Julie.

1. Analyse Concurrentielle de Porter · J. Akoka & I. Wattiau Chaîne de valeur de Porter Utilisée en analyse stratégique. Approche systématique visant à examiner les sources

Simulated Electronic Health documentation: what influence Health... · Chan Kim Geok, Saloma Pawi, Ong Mei Fong, Yanika Kowitlawakul, Goy Siew Ching, Presented at the 11th International

J. Akoka & I. Comyn-Wattiau 1 1 Intégration de schémas de bases de données J. Akoka I. Comyn-Wattiau.

PRATIQUES - les-cineastes.fr · Wong Kar-Wai (né à Shanghai en 1958) arrive après la génération de la Nouvelle vague à Hong Kong (Allen Fong, Anne Hui, Patrick Tam, Stanley

SCHEMA CINEMATIQUE. SCHÉMA CINÉMATIQUE Un schéma cinématique de mécanisme est un schéma qui doit non seulement permettre la compréhension des différents.

Le schéma directeur d’accessibiliLe schéma d'accessibilité ...Le Schéma directeur d’accessibilité des transports Agenda d’accessibilité programmée Guide méthodologique

· 2017-10-20 · 1 Supporting Information Highly Efficient Cs-based Perovskite Light-Emitting Diodes Enabled by Energy Funnelling Yan Fong Ng,abc Sneha A. Kulkarni,a Shayani Parida,d

Palmarès 2017 - Premiers Plans · 2 000€ offerts à un comédien par l’Adami Eddhy Dupont dans CHASSE ROYALE de Lise Akoka et Romane Guéret France PRIX MADEMOISELLE LADUBAY

La difficulté majeureLa difficulté majeure · 2009. 5. 22. · Miang Fong. Félicitations, c'est vraiment un grand progrès pour l’oeuvre de Monsieur Fischer et je vous souhaite

Schéma d'installation

Schéma electrique

Schéma Directeur Routier

DOSSIER DE - Palais des festivals · 2018. 9. 26. · CHILLY GONZALES accompagné du Kaiser Quartett *Changement de distribution samedi 26 Juillet à 19h : La pianiste Grace Fong

Schéma Directeur d’Assainissement

Schéma éléctrique ()

LE SCHÉMA DE PRINCIPE ET LE SCHÉMA DE CONSTRUCTION.

Formulaire de nomination Internationale Mémoire du monde ... · Lau Fong Adresse: Arquivo de Macao,Un V. Les inconvénients. Ferreira de Almeida, n.º 91-93, Macau Téléphone +853