Le Modèle Entité-Relation (Entité-Association) Chapitre 2 The slides for this text are organized into chapters. This lecture covers Chapter 2. Chapter 1: Introduction to Database Systems Chapter 2: The Entity-Relationship Model Chapter 3: The Relational Model Chapter 4 (Part A): Relational Algebra Chapter 4 (Part B): Relational Calculus Chapter 5: SQL: Queries, Programming, Triggers Chapter 6: Query-by-Example (QBE) Chapter 7: Storing Data: Disks and Files Chapter 8: File Organizations and Indexing Chapter 9: Tree-Structured Indexing Chapter 10: Hash-Based Indexing Chapter 11: External Sorting Chapter 12 (Part A): Evaluation of Relational Operators Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques Chapter 13: Introduction to Query Optimization Chapter 14: A Typical Relational Optimizer Chapter 15: schéma Refinement and Normal Forms Chapter 16 (Part A): Physical Database Design Chapter 16 (Part B): Database Tuning Chapter 17: Security Chapter 18: Transaction Management Overview Chapter 19: Concurrency Control Chapter 20: Crash Recovery Chapter 21: Parallel and Distributed Databases Chapter 22: Internet Databases Chapter 23: Decision Support Chapter 24: Data Mining Chapter 25: Object-Database Systems Chapter 26: Spatial Data Management Chapter 27: Deductive Databases Chapter 28: Additional Topics 1

Objectifs Survol de la conception des base de données Analyse des prérequis, design conceptuel, design logique, normalisation et design physique Modèle entité-relation (ER) Éléments de base: Entités Relations Attributs Éléments avancés: Contraintes Entités faibles Hiérarchies ISA Agrégation Design conceptuel utilisant le modèle ER 2

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 sont les opérations dont la performance est critique? Design conceptuel: Utiliser le résultat de l’AP afin de développer une description (sémantique) de haut niveau pour les données à stocker, ainsi que les contraintes typiques de ces données. 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’intégrité qui sont valides? Le résultat de cette étape est le schéma conceptuel des données. 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. 2

Survol de la Conception des BDs (Suite) Décomposition du schéma: Analyser le schéma logique, identifier les problèmes potentiels et résoudre ces derniers en décomposant les schémas logiques à l’aide des formes normales. Design physique: Considérer la charge de travail attendue que la BD supportera afin de décomposer davantage le design en vue de la performance désirée. Design des applications et de la sécurité: Considère des aspects du design qui vont au delà de la BD elle-même. Les méthodologies complètes de design telles que UML sont utiles ici. Quels sont les utilisateurs et les processus impliqués dans l’application? Quels sont les rôles des utilisateurs impliqués? Quelles parties de la BD doivent être accessibles à chaque rôle et et quelles autres parties ne le doivent pas? 2

Conception des BDs: Résumé Analyse des prérequis Domaine Prerequis Design conceptuel Diagramme ER Design logique Schéma logique Normalisation Formes normales Design physique Schéma physique 2

Design Conceptuel de la Base de Données Design conceptuel: (Le Model ER est utilisé à cette étape.) Quelles sont les entités and relations du domaine? Quelles informations à stocker dans la 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 représenté par un diagramme (diagrammes ER). Le diagramme ER sera traduit en un schéma relationnel à l’étape suivante du design. 2

Eléments de Base du Modèle ER Employees ssn name lot Entité: Objet du monde réel, distinct des autres objets. Une entité est décrite par 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. (Exception: hiérarchies ISA – voir plus loin) Chaque ensemble d’entités a une clé, c.à.d un ensemble minimal d’attributs dont les valeurs identifient exactement une entité de l’ensemble d’entités. Chaque attribut a un domaine, c.à.d. un ensemble de valeurs possibles. The slides for this text are organized into several modules. Each lecture contains about enough material for a 1.25 hour class period. (The time estimate is very approximate--it will vary with the instructor, and lectures also differ in length; so use this as a rough guideline.) This covers Lectures 1 and 2 (of 6) in Module (5). Module (1): Introduction (DBMS, Relational Model) Module (2): Storage and File Organizations (Disks, Buffering, Indexes) Module (3): Database Concepts (Relational Queries, DDL/ICs, Views and Security) Module (4): Relational Implementation (Query Evaluation, Optimization) Module (5): Database Design (ER Model, Normalization, Physical Design, Tuning) Module (6): Transaction Processing (Concurrency Control, Recovery) Module (7): Advanced Topics 3

Eléments de Base du Modèle ER (Suite) since name dname ssn lot did budget Employees Works_In Departments 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. Un ensemble de relations n-aires R relie n ensembles d’entités E1 ... En; Chaque relation de 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. 4

Eléments de Base du modèle ER (Suite) name Eléments de Base du modèle ER (Suite) ssn lot Employees since name dname super-visor subor-dinate ssn lot did budget Reports_To Employees Works_In Departments 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ées peuvent jouer des rôles différents; p.ex. emp1 fait rapport à un employé emp2 (le manager). Des indicateurs de rôle soulignent cette différence de rôles joués. Si un ensemble d’entités a des entités qui jouent plus d’un rôle, on obtient des attributs non ambigus pour l’ensemble des relations en concaténant l’indicateur avec les attributs de l’ensemble d’entités. 4

Contraintes de Clé since lot name ssn dname did budget Dans 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; cela s’appelle la contrainte de clé (Voir la flèche dans la figure ci-haut) Manages Employees Departments 1-to-1 1-to Many Many-to-1 Many-to-Many 6

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 Departments doit être en relation avec Manages Ci-dessous: une ligne grasse (fine) signifie participation totale (partielle) since since name name dname dname ssn lot did did budget budget Employees Manages Departments Works_In since 8

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 losanges à contour épais. Un ensemble d’entités faibles a une clé partielle (Voir ligne hachée). name cost ssn pname lot age Employees Policy Dependents 10

Hiérarchies ISA (`is a’) name Hiérarchies ISA (`is a’) ssn lot Employees Comme en C++, ou Java, les attributs sont hérités. Si nous disons que A ISA B, toute entité de A est aussi considérée comme une entité de B. hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps 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: Les 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 (Voir page 16). 12

name Agrégation ssn lot Employees 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. Monitors until started_on since dname pid pbudget did budget Projects Sponsors Departments agrégation vs. relation ternaire: -- Surveiller une relation distincte avec un attribut descriptif est ainsi possible. -- Permet de dire que chaque relation est surveillée par au plus un employé. 2

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

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

Entité vs. Attribut (Suite) from to name Employees ssn lot dname 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é: Nous voulons enregistrer plusieurs valeurs de l’attribut descriptif pour chaque relation. Cela est accompli par l’introduction d’un nouvel ensemble d’entités appelé Duration. did budget Works_In4 Departments name dname budget did ssn lot Employees Works_In4 Departments Duration from to 5

Entité vs. Relation Ceci résout le problème! Le premier diagramme ER est correct si un manager reçoit un budget discrétionnaire séparé pour chaque dept. Si par contre un manager reçoit un budget discrétionnaire 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 ! since dbudget name dname ssn lot did budget Employees Manages2 Departments name ssn lot since dname Employees did budget Manages2 Departments ISA Ceci résout le problème! Managers dbudget 6

Relations Binaires vs. Ternaires name Employees ssn lot pname age Covers Dependents Mauvais design par rapports aux prérequis ci-bas Policies policyid cost Ce diagramme ER n’exprime pas les requis suivants: Une police ne peut être couverte par deux personnes en même temps. Chaque police doit être couverte par quelqu’un. Dependents est un ensemble d’entités faibles avec “pname” comme clé partielle et identifiées par la clé primaire de Policies. Qu’est ce que ce diagramme exprime? Quelles contraintes additionnelles résoudraient notre problème? 7

Relations Binaires vs. Ternaires (Suite) Solution: introduire deux relations binaires à la place de Covers, à savoir Purchaser et Beneficiary. Ensuite ajouter les contraintes suivantes: Contrainte de clé sur Policies par rapport à Purchaser Contrainte de participation totale sur Policies par rapport à Purchaser Contraintes appropriées sur l’ensemble d’entités faibles Dependents Quid si nous n’ajoutons qu’une contrainte de clé sur Policies par rapport à Covers? name Employees ssn lot pname age Dependents Purchaser Beneficiary Meilleur design policyid cost Policies 7

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 quantity. 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 quantity? Il semble impossible de le représenter de manière précise avec ces relations binaires. 9

Résumé Le design conceptuel 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 ! Éléments de bases: entités, relations (associations) et attributs. Quelques éléments additionnels: entités faibles, hiérarchies ISA et agrégation. Note: Il y a beaucoup de variations notationnelles du modèle ER. 11

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épendances fonctionnelles) 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. 12

Résumé (Suite) Le design en modèle ER est subjectif. Il y a souvent plusieurs manières de modeler un scénario donné. L’analyse des alternatives peut être plein d’astuces à maîtriser, 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égations. Un bon design conceptuel résulte en un schéma relationnel qui sera analysé et décomposé plutard. Les info sur les FDs et les techniques de normalisation sont particulièrement utiles ici. 13