36 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

37 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 Set Association 1:1 Association 1:n Relation IS-A 4.3. La rétroconception de schémas réseaux Type d'enregistrement Entité Entité faible

38 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ême enregistrement Association N-M Association n-aire Set Association 1:1 Relation IS-A 4.3. La rétroconception de schémas réseaux

39 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

40 J. AKOKA &I.WATTIAU Un exemple : le système dinscription dune 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-name instructor-address (SE) SECTION section# grade

41 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

42 J. AKOKA &I.WATTIAU Etape 2 : dérivation dassociations 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 n

43 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 n SECTION m n prerequisite# student#

44 J. AKOKA &I.WATTIAU Etape 6 : dérivation des agrégations – Lassociation 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# STUDENT INSTRUCTOR instructor-name n SECTION m n GRADE mn student# prerequisite#

45 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 STUDENT INSTRUCTOR instructor-name instructor-address n SECTION m n GRADE mn prerequisite# prerequisite-title student# student-name section# grade

46 J. AKOKA &I.WATTIAU Etape 8 : dérivation des clés des entités COURSE course# course-location PREREQUISITE DEPARTMENT department# department-name STUDENT INSTRUCTOR instructor-name instructor-address n SECTION m n GRADE mn prerequisite# prerequisite-title student# student-name section# grade

47 J. AKOKA &I.WATTIAU Etape 9 : production du schéma EER COURSE course# course-location PREREQUISITE DEPARTMENT department# department-name STUDENT INSTRUCTOR department# instructor-name instructor-address n SECTION m n GRADE mn prerequisite# prerequisite-title student# student-name section# grade HIRE COURSE-PRER

48 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

49 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 Méthode de Fonkam & Gray

50 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 Méthode de Fonkam & Gray

51 J. AKOKA &I.WATTIAU Un exemple : la base relationnelle des ressources humaines dune 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ées les clés candidates sont en italiques les relations sous-type/supertype sont représentées par des clés communes

52 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_bui lding#,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)

53 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_stu dy,undergrad],[sname,student],[address,student]],[[unde rgrad_id,stud_id]]) permet didentifier 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.

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

55 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

56 J. AKOKA &I.WATTIAU Etape 3 : dérivation des entités régulières PERSON STUDENT EMPLOYEE UNDERGRAD COURSE JOB LOCATION

57 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

58 J. AKOKA &I.WATTIAU Etape 4 : dérivation des entités faibles PERSON STUDENT EMPLOYEE UNDERGRAD COURSE JOB LOCATION PROJECT DEPARTMENT works on runs 1n 1 n

59 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

60 J. AKOKA &I.WATTIAU PERSON STUDENT EMPLOYEE UNDERGRAD COURSE JOB LOCATION PROJECT DEPARTMENT works on runs 1n 1 n Etape 5 : dérivation des associations m:n enrollment m n works on m n

61 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_ro om) 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

62 J. AKOKA &I.WATTIAU Etape 6 : dérivation des associations 1:n PERSON STUDENT EMPLOYEE UNDERGRAD COURSE JOB LOCATION PROJECT DEPARTMENT works on runs 1n 1 n enrollment m n works on m n lives at 1 n

63 J. AKOKA &I.WATTIAU Comparaison de quelques approches de rétro- conception de bases relationnelles Légende : * utilise partiellement ** exploite intensivement

64 J. AKOKA &I.WATTIAU L'approche MeRCI

65 J. AKOKA &I.WATTIAU 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.

66 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 La désoptimisation du schéma physique

67 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 La conceptualisation du schéma logique

68 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 La description sémantique

69 J. AKOKA &I.WATTIAU Architecture de MeRCI

70 J. AKOKA &I.WATTIAU Transfor- mations de modèles de MeRCI MODELE DE LA BASE DE DONNEES MODELE CONCEPTUEL MODELE SEMANTIQUE Base de données

71 J. AKOKA &I.WATTIAU 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és Associations Généralisations

72 J. AKOKA &I.WATTIAU La conceptualisation dans MeRCI

73 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 Patte rôle cardinalité Identifiant Attribut caractérise identifie dépend de générique spécifique nom degré numéro nom domaine composant 1N N N 1 1

74 J. AKOKA &I.WATTIAU Index nom unique Le méta- modèle de la base de données Groupe colonnes obligatoire sansdouble clé-accès clé potentielle peut-être 1 peut-être 2 peut-être 3 Clé étrangère nom Clé nom primaire référence a valeurs communes inclusion comparé a valeurs identiques Vue nom opérations comprend Colonne nom nomcode domaine homonymes synonymes Table nom composé

75 J. AKOKA &I.WATTIAU Mapping récursif sur le modèle de la base relationnelle

76 J. AKOKA &I.WATTIAU Mapping du modèle relationnel vers le modèle EER

77 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 dune sémantique, –règles de consolidation : renforcement dune présomption –règles de confirmation : confirmation dune sémantique. Les catégories sont matérialisées par des degrés de confiance, facteurs de certitude associés aux règles

78 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 : –lattribut number dans les deux tables ne correspond pas au même concept (homonyme). –lattribut 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.

79 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 dhéritage entre T1 et T2 avec une certitude p1. Exemple de règle de présomption avec insertion des certitudes

80 J. AKOKA &I.WATTIAU Exemple de règle de consolidation –PERSON (number, name, address) –COURSE (number, description, level) La suspicion sur la nature de lattribut 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.

81 J. AKOKA &I.WATTIAU Exemple de règle de consolidation avec insertion des certitudes RCS13 : Si il existe un lien dhé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 Alorsil existe un lien dhéritage entre T1 et T2 avec une certitude p2 et T1.C et T2.C ne sont pas des homonymes.

82 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é dune 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. –lautre composant de la clé nest pas contenu dans une autre table –il ny a pas de spécification DML impliquant uniquement cet autre composant.

83 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 une certitude 1.

84 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 ny aucune source dinformation concernant un concept. Par exemple, column. index. unique. vrai avec certitude 0 indique quil ny pas de spécification DDL avec un index unique défini sur la colonne. –p1 correspond à la valeur de suspicion correspond à lexploration dune source dinformation –p2 (supérieur à p1) correspond au cas où des informations provenant de sources différentes se consolident.