La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2.

Présentations similaires


Présentation au sujet: "1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2."— Transcription de la présentation:

1 1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2

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

3 3 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 lAP 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 dinté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.

4 4 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 à laide 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 lapplication? 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?

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

6 6 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 dintegrité 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.

7 7 Eléments de Base du Modèle ER Entité: Objet du monde réel, distinct des autres objets. Une entité est décrite par un ensemble d attributs. Ensemble dentités : Une collection dentités similaires. P.ex. Tous les employés dune entreprise. Toutes les entités dun ensemble dentités ont les mêmes attributs. (Exception: hiérarchies ISA – voir plus loin) Chaque ensemble dentités a une clé, c.à.d un ensemble minimal dattributs dont les valeurs identifient exactement une entité de lensemble dentités. Chaque attribut a un domaine, c.à.d. un ensemble de valeurs possibles. Employees ssn name lot

8 8 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. Un ensemble de relations n-aires R relie n ensembles dentités E1... En; Chaque relation de R implique des entités e1 de E1,..., en de En. Attributs descriptifs : Attributs dune relation; enregistrent de l info au sujet de la relation. lot dname budget did since name Works_In DepartmentsEmployees ssn

9 9 Eléments de Base du modèle ER (Suite) Le même ensemble dentité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 dentités a des entités qui jouent plus dun rôle, on obtient des attributs non ambigus pour lensemble des relations en concaténant lindicateur avec les attributs de lensemble dentités. lot dname budget did since name Works_In DepartmentsEmployees ssn Reports_To lot name Employees subor- dinate super- visor ssn

10 10 Contraintes de Clé 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 sappelle la contrainte de clé (Voir la flèche dans la figure ci-haut) Many-to-Many 1-to-11-to ManyMany-to-1 dname budget did since lot name ssn Manages Employees Departments

11 11 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) lot name dname budgetdid since name dname budgetdid since Manages since Departments Employees ssn Works_In

12 12 Entités Faibles (Weak Entities) Une entité faible peut être identifiée uniquement seulement si lon considère la clé primaire dune autre entité dite propriétaire identifiante. Lensemble dentités propriétaires et lensemble dentités faibles doivent participer dans un ensemble de relations one-to-many (une propriétaire, de multiples entités). Lensemble dentité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 dassurance pour leurs parents. Lensemble dentités faibles et son ensemble de relations identifiantes sont indiqués par des rectangles et losanges à contour épais. Un ensemble dentités faibles a une clé partielle (Voir ligne hachée). lot name age pname Dependents Employees ssn Policy cost

13 13 Hiérarchies ISA (`is a) Contract_Emps name ssn Employees lot hourly_wages ISA Hourly_Emps contractid hours_worked 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. 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 dutiliser 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).

14 14 Agrégation Sert à modeller une relation entre ensemble dentités et ensemble de relation. Lagrégation permet de traiter un ensemble de relations comme un ensemble dentités afin détablir une relation entre eux. Notation: une case pointillée. * 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é. budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

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

16 16 Entité vs. Attribut Devrait-on exprimer l adresse comme un attribut de Employees ou comme un ensemble dentités (connectés a Employees par un ensemble de relations)? Cela dépend de lusage que nous voulons faire de linfo stockée dans ladresse, 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 dextraire les employés dune cité donnée), address doit dans ce cas être modelée comme une entité (car les valeurs dun attribut sont atomiques).

17 17 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é: Nous voulons enregistrer plusieurs valeurs de lattribut descriptif pour chaque relation. Cela est accompli par lintroduction dun nouvel ensemble dentités appelé 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

18 18 Entité vs. Relation 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 lensemble de relations Manages alors que ce nest 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ésout le problème!

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

20 20 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 lensemble dentités faibles Dependents Quid si nous najoutons quune contrainte de clé sur Policies par rapport à Covers? Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Meilleur design

21 21 Relation Binaires vs. Ternaires (Suite) Les exemples précédents ont illustré le cas dans lequel deux relations binaires valaient mieux quune relation ternaire. Un exemple dans lautre direction: Une relation ternaire Contracts relie lensemble dentités Parts, Departments et Suppliers, et a un attribut descriptif quantity. Aucune combinaison de relations binaires nest reélément adéquate pour cette situation: S can-supply P, D needs P, et D deals-with S nimpliquent pas que D a accepté dacheter P de S. Comment pouvons nous enregistrer quantity ? Il semble impossible de le représenter de manière précise avec ces relations binaires.

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

23 23 Résumé (Suite) Plusieurs sortes de contraintes dinté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 lensemble 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.

24 24 Résumé (Suite) Le design en modèle ER est subjectif. Il y a souvent plusieurs manières de modeler un scénario donné. Lanalyse des alternatives peut être plein dastuces à 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.


Télécharger ppt "1 Le Modèle Entité-Relation (Entité-Association) Chapitre 2."

Présentations similaires


Annonces Google