Free Press

Le modèle de données entité-relation (ER) existe depuis plus de 35 ans. Il est bien adapté à la modélisation des données à utiliser avec les bases de données car il est assez abstrait et facile à discuter et à expliquer. Les modèles ER sont facilement traduits en relations. Les modèles ER, également appelés schéma ER, sont représentés par des diagrammes ER.

La modélisation ER repose sur deux concepts :

• Les entités, définies comme des tables qui contiennent des informations spécifiques (données)
• Les relations, définies comme les associations ou les interactions entre les entités

Voici un exemple de la façon dont ces deux concepts pourraient être combinés dans un modèle de données ER : Le professeur Ba (entité) enseigne (relation) le cours de systèmes de base de données (entité).

Pour le reste de ce chapitre, nous utiliserons une base de données exemple appelée base de données COMPANY pour illustrer les concepts du modèle ER. Cette base de données contient des informations sur les employés, les départements et les projets. Les points importants à noter comprennent :

• Il y a plusieurs départements dans l’entreprise. Chaque département a une identification unique, un nom, l’emplacement du bureau et un employé particulier qui gère le département.
• Un département contrôle un certain nombre de projets, dont chacun a un nom unique, un numéro unique et un budget.
• Chaque employé a un nom, un numéro d’identification, une adresse, un salaire et une date de naissance. Un employé est affecté à un département mais peut participer à plusieurs projets. Nous devons enregistrer la date de début de l’employé dans chaque projet. Nous avons également besoin de connaître le superviseur direct de chaque employé.
• Nous voulons garder la trace des personnes à charge pour chaque employé. Chaque personne à charge a un nom, une date de naissance et une relation avec l’employé.

Entité, ensemble d’entités et type d’entité

Une entité est un objet dans le monde réel avec une existence indépendante qui peut être différenciée des autres objets. Une entité peut être

Les entités peuvent être classées en fonction de leur force. Une entité est considérée comme faible si ses tables dépendent de son existence.

• C’est-à-dire qu’elle ne peut pas exister sans une relation avec une autre entité
• Sa clé primaire est dérivée de la clé primaire de l’entité mère
  • La table Spouse, dans la base de données COMPANY, est une entité faible car sa clé primaire dépend de la table Employee. Sans un enregistrement d’employé correspondant, l’enregistrement du conjoint n’existerait pas.

Une entité est considérée comme forte si elle peut exister en dehors de toutes ses entités liées.

• Les noyaux sont des entités fortes.
• Une table sans clé étrangère ou une table qui contient une clé étrangère pouvant contenir des nuls est une entité forte

Un autre terme à connaître est le type d’entité qui définit une collection d’entités similaires.

Un ensemble d’entités est une collection d’entités d’un type d’entité à un moment donné. Dans un diagramme de relation entre entités (ERD), un type d’entité est représenté par un nom dans une case. Par exemple, dans la figure 8.1, le type d’entité est EMPLOYEE.

Dépendance d’existence

L’existence d’une entité dépend de l’existence de l’entité liée. Elle est dépendante de l’existence si elle possède une clé étrangère obligatoire (c’est-à-dire un attribut de clé étrangère qui ne peut pas être nul). Par exemple, dans la base de données SOCIÉTÉ, une entité Conjoint est dépendante de l’existence de l’entité Employé.

Caractéristiques des entités

Vous devez également vous familiariser avec les différents types d’entités, notamment les entités indépendantes, les entités dépendantes et les entités caractéristiques. Celles-ci sont décrites ci-dessous.

Entités indépendantes

Les entités indépendantes, également appelées noyaux, constituent l’épine dorsale de la base de données. C’est sur elles que reposent les autres tables. Les noyaux ont les caractéristiques suivantes :

• Ils sont les blocs de construction d’une base de données.
• La clé primaire peut être simple ou composite.
• La clé primaire n’est pas une clé étrangère.
• Ils ne dépendent pas d’une autre entité pour leur existence.

Si nous nous référons à notre base de données SOCIÉTÉ, les exemples d’une entité indépendante comprennent la table Client, la table Employé ou la table Produit.

Entités dépendantes

Les entités dépendantes, également appelées entités dérivées, dépendent d’autres tables pour leur signification. Ces entités présentent les caractéristiques suivantes :

• Les entités dépendantes sont utilisées pour relier deux noyaux entre eux.
• On dit qu’elles dépendent de l’existence de deux tables ou plus.
• Les relations de plusieurs à plusieurs deviennent des tables associatives avec au moins deux clés étrangères.
• Elles peuvent contenir d’autres attributs.
• La clé étrangère identifie chaque table associée.
• Il existe trois options pour la clé primaire :
  1. Utiliser un composite de clés étrangères de tables associées si elles sont uniques
  2. Utiliser un composite de clés étrangères et une colonne qualifiante
  3. Créer une nouvelle clé primaire simple

Entités caractéristiques

Les entités caractéristiques fournissent plus d’informations sur une autre table. Ces entités ont les caractéristiques suivantes :

• Elles représentent des attributs multivalués.
• Elles décrivent d’autres entités.
• Elles ont généralement une relation de un à plusieurs.
• La clé étrangère est utilisée pour identifier davantage la table caractérisée.
• Les options pour la clé primaire sont les suivantes :
  1. Utiliser un composite de clé étrangère plus une colonne qualifiante
  2. Créer une nouvelle clé primaire simple. Dans la base de données COMPANY, il peut s’agir de :
     • Employé (EID, Nom, Adresse, Âge, Salaire) – EID est la clé primaire simple.
     • EmployéTéléphone (EID, Téléphone) – EID fait partie d’une clé primaire composite. Ici, EID est également une clé étrangère.

Attributs

Chaque entité est décrite par un ensemble d’attributs (par exemple, employé = (nom, adresse, date de naissance (âge), salaire).

Chaque attribut a un nom, et est associé à une entité et à un domaine de valeurs légales. Cependant, l’information sur le domaine de l’attribut n’est pas présentée sur l’ERD.

Dans le diagramme entité-relation, présenté dans la figure 8.2, chaque attribut est représenté par un ovale avec un nom à l’intérieur.

Types d’attributs

Il y a quelques types d’attributs avec lesquels vous devez être familier. Certains d’entre eux sont à laisser tels quels, mais d’autres doivent être ajustés pour faciliter la représentation dans le modèle relationnel. Cette première section aborde les types d’attributs. Plus tard, nous aborderons la fixation des attributs pour qu’ils s’intègrent correctement dans le modèle relationnel.

Attributs simples

Les attributs simples sont ceux tirés des domaines de valeurs atomiques ; ils sont également appelés attributs à valeur unique. Dans la base de données SOCIÉTÉ, un exemple de ce type serait : Nom = {John} ; Âge = {23}

Attributs composites

Les attributs composites sont ceux qui consistent en une hiérarchie d’attributs. En reprenant l’exemple de notre base de données, et comme le montre la figure 8.3, l’adresse peut être constituée du numéro, de la rue et de la banlieue. Cela s’écrirait donc comme suit : → Adresse = {59 + ‘Meek Street’ + ‘Kingsford’}

Attributs multivalués

Les attributs multivalués sont des attributs qui ont un ensemble de valeurs pour chaque entité. Un exemple d’attribut multivalué de la base de données COMPANY, comme le montre la figure 8.4, sont les diplômes d’un employé : BSc, MIT, PhD.

Attributs dérivés

Les attributs dérivés sont des attributs qui contiennent des valeurs calculées à partir d’autres attributs. La figure 8.5 en donne un exemple. L’âge peut être dérivé de l’attribut Date de naissance. Dans cette situation, Birthdate est appelé un attribut stocké, qui est physiquement enregistré dans la base de données.

Keys

Une contrainte importante sur une entité est la clé. La clé est un attribut ou un groupe d’attributs dont les valeurs peuvent être utilisées pour identifier de manière unique une entité individuelle dans un ensemble d’entités.

Types de clés

Il existe plusieurs types de clés. Elles sont décrites ci-dessous.

Clé candidate

Une clé candidate est une clé simple ou composite qui est unique et minimale. Elle est unique car deux lignes d’une table ne peuvent avoir la même valeur à tout moment. Elle est minimale car chaque colonne est nécessaire pour atteindre l’unicité.

D’après l’exemple de notre base de données COMPANY, si l’entité est Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID), les clés candidates possibles sont :

• EID, SIN
• Prénom et Nom – en supposant qu’il n’y a personne d’autre dans l’entreprise avec le même nom
• Nom et DépartementID – en supposant que deux personnes avec le même nom de famille ne travaillent pas dans le même département

Clé composite

Une clé composite est composée de deux attributs ou plus, mais elle doit être minimale.

En utilisant l’exemple de la section sur les clés candidates, les clés composites possibles sont :

• Prénom et nom de famille – en supposant qu’il n’y a personne d’autre dans l’entreprise avec le même nom
• Nom de famille et ID du département – en supposant que deux personnes avec le même nom de famille ne travaillent pas dans le même département

Clé primaire

La clé primaire est une clé candidate qui est sélectionnée par le concepteur de la base de données pour être utilisée comme mécanisme d’identification pour l’ensemble des entités. Elle doit identifier de manière unique les tuples d’une table et ne pas être nulle. La clé primaire est indiquée dans le modèle ER en soulignant l’attribut.

• Une clé candidate est sélectionnée par le concepteur pour identifier de manière unique les tuples d’une table. Elle ne doit pas être nulle.
• Une clé est choisie par le concepteur de la base de données pour être utilisée comme mécanisme d’identification pour l’ensemble des entités. C’est ce qu’on appelle la clé primaire. Cette clé est indiquée en soulignant l’attribut dans le modèle ER.

Dans l’exemple suivant, EID est la clé primaire:

Employé(EID, Prénom, Nom, NAS, Adresse, Téléphone, Date de naissance, Salaire, DépartementID)

Clé secondaire

Une clé secondaire est un attribut utilisé strictement à des fins de récupération (peut être composite), par exemple : Téléphone et Nom de famille.

Clé alternative

Les clés alternatives sont toutes les clés candidates qui ne sont pas choisies comme clé primaire.

Clé étrangère

Une clé étrangère (FK) est un attribut dans une table qui fait référence à la clé primaire dans une autre table OU elle peut être nulle. Les clés étrangères et primaires doivent être du même type de données.

Dans l’exemple de base de données SOCIÉTÉ ci-dessous, DepartmentID est la clé étrangère:

Employee(EID, First Name, Last Name, SIN, Address, Phone, BirthDate, Salary, DepartmentID)

Nulls

Un null est un symbole spécial, indépendant du type de données, qui signifie soit inconnu, soit inapplicable. Il ne signifie pas zéro ou blanc. Les caractéristiques de null comprennent :

• Aucune entrée de données
• Interdit dans la clé primaire
• Doit être évité dans d’autres attributs
• Peut représenter
  • Une valeur d’attribut inconnue
  • Une valeur connue, mais manquante, valeur d’attribut
  • Une condition « non applicable »
• Peut créer des problèmes lorsque des fonctions telles que COUNT, AVERAGE et SUM sont utilisées
• Peut créer des problèmes logiques lorsque des tables relationnelles sont liées

NOTE : Le résultat d’une opération de comparaison est nul lorsque l’un des deux arguments est nul. Le résultat d’une opération arithmétique est nul lorsque l’un ou l’autre des arguments est nul (à l’exception des fonctions qui ignorent les nulls).

Exemple d’utilisation de null

Utiliser la table Salary (Salary_tbl) de la figure 8.6 pour suivre un exemple d’utilisation de null.

Pour commencer, trouvez tous les employés (emp#) dans les ventes (sous la colonne jobName) dont le salaire plus la commission sont supérieurs à 30 000.

• SELECT emp# FROM Salary_tbl
• WHERE jobName = Sales AND
• (commission + salaire) > 30,000 -> E10 et E12

Ce résultat n’inclut pas E13 à cause de la valeur nulle dans la colonne commission. Pour s’assurer que la ligne avec la valeur nulle est incluse, nous devons examiner les champs individuels. En ajoutant la commission et le salaire de l’employé E13, le résultat sera une valeur nulle. La solution est présentée ci-dessous.

Relations

Les relations sont la colle qui maintient les tables ensemble. Elles sont utilisées pour connecter les informations liées entre les tables.

La force des relations est basée sur la façon dont la clé primaire d’une entité liée est définie. Une relation faible, ou non identifiante, existe si la clé primaire de l’entité liée ne contient pas un composant de clé primaire de l’entité mère. Les exemples de base de données d’entreprise comprennent :

• Customer(CustID, CustName)
• Order(OrderID, CustID, Date)

Une relation forte, ou d’identification, existe lorsque la clé primaire de l’entité liée contient le composant de clé primaire de l’entité mère. Exemples :

• Cours(CrsCode, DeptCode, Description)
• Classe(CrsCode, Section, ClassTime…)

Types de relations

Vous trouverez ci-dessous des descriptions des différents types de relations.

Relation un à plusieurs (1:M)

Une relation un à plusieurs (1:M) devrait être la norme dans toute conception de base de données relationnelle et se retrouve dans tous les environnements de base de données relationnelles. Par exemple, un département compte de nombreux employés. La figure 8.7 montre la relation d’un de ces employés avec le département.

Relation un à un (1:1)

Une relation un à un (1:1) est la relation d’une entité à une seule autre entité, et vice versa. Elle devrait être rare dans toute conception de base de données relationnelle. En fait, elle pourrait indiquer que deux entités appartiennent en fait à la même table.

Un exemple tiré de la base de données COMPANY est qu’un employé est associé à un conjoint, et qu’un conjoint est associé à un employé.

Relations de plusieurs à plusieurs (M:N)

Pour une relation de plusieurs à plusieurs, considérez les points suivants :

• Elle ne peut pas être implémentée comme telle dans le modèle relationnel.
• Elle peut être changée en deux relations 1:M.
• Il peut être mis en œuvre en se décomposant pour produire un ensemble de relations 1:M.
• Il implique la mise en œuvre d’une entité composite.
• Créer deux relations 1:M ou plus.
• La table de l’entité composite doit contenir au moins les clés primaires des tables d’origine.
• La table de liaison contient des occurrences multiples des valeurs de clés étrangères.
• Des attributs supplémentaires peuvent être attribués au besoin.
• Il est possible d’éviter les problèmes inhérents à une relation M:N en créant une entité composite ou une entité pont. Par exemple, un employé peut travailler sur de nombreux projets OU un projet peut avoir de nombreux employés qui y travaillent, selon les règles de gestion. Ou encore, un étudiant peut avoir plusieurs classes et une classe peut contenir plusieurs étudiants.

La figure 8.8 montre un autre aspect de la relation M:N où un employé a des dates de début différentes pour différents projets. Par conséquent, nous avons besoin d’une table JOIN qui contient l’EID, le code et la StartDate.

Exemple de mappage d’un type de relation binaire M:N

• Pour chaque relation binaire M:N, identifiez deux relations.
• A et B représentent deux types d’entités participant à R.
• Créer une nouvelle relation S pour représenter R.
• S doit contenir les PK de A et B. Ceux-ci peuvent ensemble être le PK dans la table S OU ceux-ci avec un autre attribut simple dans la nouvelle table R peuvent être le PK.
• La combinaison des clés primaires (A et B) fera la clé primaire de S.

Relation unaire (récursive)

Une relation unaire, également appelée récursive, est une relation dans laquelle une relation existe entre les occurrences du même ensemble d’entités. Dans cette relation, les clés primaires et étrangères sont les mêmes, mais elles représentent deux entités ayant des rôles différents. Voir la figure 8.9 pour un exemple.

Pour certaines entités dans une relation unaire, une colonne séparée peut être créée qui fait référence à la clé primaire du même ensemble d’entités.

Relations ternaires

Une relation ternaire est un type de relation qui implique des relations de plusieurs à plusieurs entre trois tables.

Référez-vous à la figure 8.10 pour un exemple de mappage d’un type de relation ternaire. Notez que n-aire signifie plusieurs tables dans une relation. (Rappelez-vous, N = nombreux.)

• Pour chaque relation n-aire (> 2), créez une nouvelle relation pour représenter la relation.
• La clé primaire de la nouvelle relation est une combinaison des clés primaires des entités participantes qui détiennent le côté N (nombreux).
• Dans la plupart des cas d’une relation n-aire, toutes les entités participantes détiennent un côté many.

Attribution

Ce chapitre de Conception de bases de données (y compris les images, sauf mention contraire) est une copie dérivée de Data Modeling Using Entity-Relationship Model par Nguyen Kim Anh sous licence Creative Commons Attribution License 3.0 license

Le matériel suivant a été rédigé par Adrienne Watt:

1. Section et exemple de nullités
2. Termes clés
3. Exercices

.