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

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1

Le Modèle Entité-Relation (Entité-Association)

Chapitre 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


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 à performance critique?

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.


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ésout ces derniers en décomposant les schémas logiques à l’aide des formes normales.

Design physique: Considè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 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?


Design Conceptuel de la Base de Données

Design conceptuel: (Le Model ER est utilisé à 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

représenté par un diagramme (diagrammes ER). Un diagramme ER peut être traduit en un schéma

relationnel.


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

Employees

ssnname

lot


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

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn


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

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.

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

Reports_To

lot

name

Employees

subor-dinate

super-visor

ssn


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 s’appelle la contrainte de clé (Voir la flèche dans la figure ci-haut)

Many-to-Many1-to-1 1-to Many Many-to-1

dname

budgetdid

since

lot

name

ssn

ManagesEmployees Departments


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 (avec une valeur ssn non-nulle!)

• Ci-dessous: une ligne grasse (fine) signifie participation totale (partielle);

lot

name dnamebudgetdid

sincename dname

budgetdid

since

Manages

since

DepartmentsEmployees

ssn

Works_In


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

agepname

DependentsEmployees

ssn

Policy

cost


Hiérarchies ISA (`is a’)

Contract_Emps

namessn

Employees

lot

hourly_wagesISA

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


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

budgetdidpid

started_on

pbudgetdname

until

DepartmentsProjects Sponsors

Employees

Monitors

lotname

ssn

since


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.


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)

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.

name

Employees

ssn lot

Works_In4

from todname

budgetdid

Departments

dnamebudgetdid

name

Departments

ssn lot

Employees Works_In4

Durationfrom to


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 l’ensemble de relations Manages alors que ce n’est pas le cas !

Manages2

name dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

dnamebudgetdid

DepartmentsManages2

Employees

namessn lot

since

Managers dbudget

ISA

Ceci résout le problème!


Relations Binaires vs. Ternaires

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?

agepname

DependentsCovers

name

Employees

ssn lot

Policies

policyid cost

Mauvais design par rapports aux prérequis ci-bas


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?

Beneficiary

agepname

Dependents

policyid cost

Policies

Purchaser

name

Employees

ssn lot

Meilleur design


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.


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.


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.


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.

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

Documents

Transcript of Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Le Modèle Entité-Relation...