Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2.

Présentation au sujet: "Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2."— Transcription de la présentation:

1 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2

2 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke2 Survol de la Conception des Bases de Données  Analyse des prérequis : Trouver ce que les utilisateurs veulent faire avec la BD.  Quelles données doivent être stockées?  Quelles applications doivent être programmées pour ces données?  Quelles opérations ont des prérequis de performance critiques?  Design conceptuel : Utilise le résultat de l’AP pour développer une description ( sémantique ) de haut niveau pour les données à stocker, ensemble avec leurs contraintes. Le résultat de cet étape est habituellement un diagramme ER.  Quelles sont les entités et les relations du domaine?  Quelles sont les contraintes d’integrité qui sont valides?  Design logique: Choisir un SGBD et traduire le schéma du design conceptuel (diagramme ER) dans le modèle des données du SGBD. Le résultat de cette étape est le schéma logique des données.

3 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke3 Survol de la Conception des Bases de Données (Suite)  décomposition du schéma: Analyse le schéma logique, identifie les problèmes potentiels et résoud ces derniers en décomposant les schémas logiques à l’aide des formes normales.  Design physique: C onsidère la charge de travail attendue que la BD supportera afin de décomposer davantage le design en vue de la performance desirée.  Design des applications et de la sécurité: Considère des aspects du design qui vont audelà de la BD elle-même. Les méthodologies complète de design telles que UML sont utiles ici.  Quelles sont les utilisateurs et les processus impliqués dans l’application?  Quelles sont les rôles des utilisateurs impliqués?  Quelles parties de la BD doivent être accessible à chaque rôle et et quelles autres parties ne le doivent pas?

4 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke4 Design Conceptuel de la Base de Donnees  Design conceptuel : (Le Model ER est utilise a cette étape.)  Quelles sont les entités and relations dans l’enterprise?  Quelles informations doivent être stockées dans le BD au sujet de ces entités et relations?  Quelles sont les contraintes d’integrité de la BD?  Un `schéma’ de la BD dans le modèle ER peut être representé par une figure diagrammatique ( diagrammes ER ).  Un diagramme ER peut être traduit en un schéma relationel.

5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke5 Eléments de Base du Modèle ER  entité: Object du monde réel qui est distinct des autres objets. Une entitée est décrite en base de données en utilisant un ensemble d’ attributs.  Ensemble d’entités : Une collection d’entités similaires. P.ex. Tous les employés d’une entreprise.  Toutes les entités d’un ensemble d’entités ont les mêmes attributs. (Du moins tant que les hiérarchies ISA ne sont pas encore considerées!)  Chaque ensemble d’entités a une clé, c.a.d un ensemble minimal d’attributs dont les valeurs détermine exactement une entité de l’ensemble d’entités.  Chaque attribut a un domaine, c.a.d. un ensemble de valeurs possibles. Employees ssn name lot

6 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke6 Eléments de Base du Modèle ER (Suite)  Relation (association) : Association entre deux ou plusieurs entités. P.ex., Joe travaille dans le département de Pharmacie.  Ensemble de relations : Collection de relations similaires.  Une relation n-aire R relie n ensembles d’entités E1... En; Chaque relation dans R implique des entités e1 de E1,..., en de En.  Attributs descriptifs : Attributs d’une relation; enregistrent de l’ info au sujet de la relation. lot dname budget did since name Works_In DepartmentsEmployees ssn Reports_To lot name Employees subor- dinate super- visor ssn

7 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke7 Eléments de Base du modèle ER (Suite)  Le même ensemble d’entités pourrait participer à des ensembles de relations différents, ou à différents “rôles” dans le même ensemble de relations:  Les entités reliéespeuvent jouer des rôles différents; p.ex. emp1 fait rapport a un employe emp2 qui est son manager. Des indicateurs de rôle soulignent cette difference de rôles joues.  Si un ensemble d’entités a des entités qui jouent plus d’un rôle, on obtient des attributs nonambigus pour l’ensemble des relations en concatenant l’indicateur avec les attributs de l’ensemble d’entités. lot dname budget did since name Works_In DepartmentsEmployees ssn Reports_To lot name Employees subor- dinate super- visor ssn

8 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke8 Contraintes de Clé  Considérez la relation Works_In: Un employé peut travailler dans plusieurs depts; et un dept peut avoir plusieurs employés.  Par contre chaque dept a tout au plus un seul manager, selon la contrainte de clé (Voir la fleche dans la figure) Many-to-Many 1-to-11-to ManyMany-to-1 dname budgetdid since lot name ssn Manages Employees Departments

9 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke9 Contraintes de Participation  Chaque département a-t-il un manager?  Si oui, ceci est une contrainte de participation : La participation de Departments dans Manages est dite être totale (vs. partielle ). Chaque valeur did dans la table Departments doit apparaitre dans une ligne de la table Manages (avec une valeur ssn non-nulle!) Ci-dessous: ligne grasse participation totale; ligne fine partielle lot name dname budgetdid since name dname budgetdid since Manages since Departments Employees ssn Works_In

10 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke10 Entités Faibles (“Weak Entities”)  Une entité faible peut être identifiée uniquement seulement si l’on considère la clé primaire d’une autre entité dite propriétaire identifiante.  L’ensemble d’entités propriétaires et l’ensemble d’entités faibles doivent participer dans un ensemble de relations one-to-many (une propriétaire, de multiples entités).  L’ensemble d’entités faibles doit avoir une participation totale dans cet ensemble de relations; celle-ci est appelée ensemble de relations identifiantes.  Voir exemple ci-bas: des employés possèdent des polices d’assurance pour leurs parents. L’ensemble d’entités faibles et son ensemble de relations identifiantes sont indiqués par des rectangles et diamants à contour épais.  Un ensemble d’entités faibles a une clé partielle (Voir ligne hachée). lot name age pname Dependents Employees ssn Policy cost

11 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke11 Hiérarchies ISA (`is a’) Contract_Emps name ssn Employees lot hourly_wages ISA Hourly_Emps contractid hours_worked Comme en C++, ou d’autres languages, les attributs sont herités. Si nous disons que A ISA B, toute entité de A est aussi considerée comme une entité de B.  Contraintes de superposition : Deux classes peuvent-elles se superposer? P.ex., Joe peut-il être à la fois une entité de Hourly_Emps et de Contract_Emps? (permis/nonpermis)  Contraintes de couverture : Des entités des sousclasses contiennent-elles toutes les entités de la superclasse? P.ex., chaque entité de Employees doit-elle aussi être une entité de Hourly_Emps ou Contract_Emps? (oui/non)  Raisons d’utiliser ISA (par spécialisation/généralisation) :  Ajouter des attributs descriptifs à une sousclasse spécifique.  Identifier des entités qui participe à une relation.

12 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke12 Agrégation  Sert à modeller une relation entre ensemble d’entités et ensemble de relation.  L’agrégation permet de traiter un ensemble de relations comme un ensemble d’entités afin d’établir une relation entre eux.  Notation: une case pointillée. * agrégation vs. relation ternaire : -- Surveille une relation distincte avec un attribut descriptif. -- Permet de dire que chaque relation est surveillée par au plus un employé. budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

13 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke13 Design Conceptuel Utilisant le Modèle ER  Choix de design:  Devrait-on modeler un concept comme entité ou comme attribut?  Devrait-on modeler un concept comme entité ou comme relation?  Identification des relations: Binaire ou ternaire …? agrégation?  Contraintes du modèle ER:  Beaucoup d’aspects de la sémantique des données devrait être capturés.  Cependant quelques contraintes ne peuvent pas être capturées dans ce modèle ER.

14 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke14 Entité vs. Attribut  Devrait-on exprimer l’ adresse comme un attribut de Employees ou comme un ensemble d’entités (connectés a Employees par un ensemble de relations)?  Cela dépend de l’usage que nous voulons faire de l’info stockée dans l’adresse, ainsi que de la sémantique des données: Si nous avons plusieurs adresses par employé, address doit alors être une entité (car les attributs ne peuvent pas avoir des ensemble comme valeurs – ne sont pas “set-valued”). Si la structure (city, street, etc.) est importante (p.ex. Nous voulons être capable d’extraire les employés d’une cité donnée), address doit dans ce cas être modelée comme une entité (car les valeurs d’un attribut sont atomiques).

15 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke15 Entité vs. Attribut (Suite)  La relation Works_In4 ne permet pas à un employé de travailler dans un département pour 2 ou plusieurs périodes de temps.  Ce problème est similaire à celui de plusieurs adresses pour le même employé: Nou voulons enregistrer plusieurs valeurs de l’attribut descriptif pour chaque relation. Cela est accomplis par l’introduction d’un nouvel ensemble d’entités appele Duration. name Employees ssn lot Works_In4 from to dname budget did Departments dname budget did name Departments ssn lot Employees Works_In4 Duration from to

16 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke16 Entité vs. Relation  Le premier diagramme ER est correct si un manager reçoit un budget discretionaire séparé pour chaque dept.  Si par contre un manager reçoit un budget discretionaire qui couvre tous les depts gérés par lui, on aura  Redondance: dbudget stocké pour chaque dept géré par le manager.  Info trompeuse: Suggère que dbudget est associé avec l’ensemble de relations Manages alors que ce n’est pas le cas ! Manages2 name dname budget did Employees Departments ssn lot dbudget since dname budget did Departments Manages2 Employees name ssn lot since Managersdbudget ISA Ceci résoud le problème!

17 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke17 Relations Binaires vs. Ternaires  Si chaque police d’assurance est possedée par exactement un employé, et que chaque parent dépendant est lié à ladite police, le premier diagramme est imprécis.  Quelles contraintes additionnelles y-a-t- il dans le 2ème diagramme? age pname Dependents Covers name Employees ssn lot Policies policyid cost Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Mauvais design Meilleur design

18 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke18 Relation Binaires vs. Ternaires (Suite)  Les exemples précédents ont illustré le cas dans lequel deux relations binaires valaient mieux qu’une relation ternaire.  Un exemple dans l’autre direction: Une relation ternaire Contracts relie l’ensemble d’entités Parts, Departments et Suppliers, et a un attribut descriptif qty. Aucune combinaison de relations binaires n’est reélément adéquate pour cette situation:  S “can-supply” P, D “needs” P, et D “deals-with” S n’impliquent pas que D a accepté d’acheter P de S.  Comment pouvons nous enregistrer qty ? Il semble impossible de le représenter de manière precises avec ces relations binaires.

19 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke19 Résumé  Le design conceptual design vient après l’ analyse des prérequis.  On obtient ici une description de haut niveau (“high-level”) des données à stocker.  Le modèle ER est populaire dans le design conceptuel.  Les éléments du modèle sont expressifs et proches de la manière dont les gens pensent au sujet de leurs applications.  C’est un modèle sémantique !  Eléments de bases: entités, relations ( association ) et attributs.  Quelques éléments additionnels: faibles entités, hiérarchies ISA et agrégation.  Note: Il y a beaucoup de variations notationelles du modèle ER.

20 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke20 Résumé (Suite)  Plusieurs sortes de contraintes d’intégrité peuvent être exprimées dans le modèle ER: Contraintes clé, contraintes de participation et contraintes de superposition/couverture pour les hiérarchies ISA. Quelques contraintes de clés étrangères sont aussi implicites dans la définition de l’ensemble de relations.  Quelques contraintes (dont les dépendences fonctionelles) ne peuvent être exprimées dans le modèle ER.  Les contraintes jouent un rôle important dans la détermination du meilleur design de base de données pour une entreprise.

21 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke21 Résumé (Suite)  Le design en modèle ER est subjectif. Il y a souvent plusieurs manières de modeler un scenario donné. L’analyse des alternatives peut être plein d’astuces à maitriser, surtout pour les larges entreprises. Souvent un choix est à faire:  entité vs. attribut, entité vs. relation, binaire vs n-aire, utilisation possibles des hiérarchies ISA et des agrégation.  Un bon design conceptuel résulte en un schéma relationel qui sera analysé et décomposé plutard. Les info sur les FDs et les techniques de normalisation sont particulièrement utiles ici.