Le modèle entité-association

Introduction

le modèle conceptuel de données MCD [1] ou modèle entité-association E-A[2] vise à fournir une base conceptuelle claire pour la modélisation des données dans le domaine des bases de données. Ce modèle est fondamental en informatique pour représenter les relations entre différentes entités au sein d'un système d'information. En utilisant des entités pour représenter des objets du monde réel (comme des personnes, des lieux ou des objets), et des associations pour représenter les relations entre ces entités, le modèle E-A offre une méthode visuelle et structurée pour organiser les données et définir leurs interactions.

En pratique, le modèle E-A est largement utilisé pour concevoir des bases de données relationnelles, où les entités deviennent des tables et les associations deviennent des relations entre ces tables. Cette approche permet de capturer de manière précise les relations complexes entre les données, tout en assurant une structure de données cohérente et normalisée.

En résumé, le modèle entité-association constitue un outil essentiel dans le développement de systèmes d'information, facilitant la représentation, l'analyse et la gestion des données à travers une approche intuitive et systématique.

Les éléments de base constituant un modèle E-A[2] sont :

  • les propriétés ;

  • les entités ;

  • les relations.

Exemple d'un modèle entité_association

Propriétés

La proprité est une information élémentaire conforme aux choix de gestion de l'entreprise, Les propriétés sont les informations de base du système d'information.

Exemples:

  • référence d'un produit,

  • adresse d'un client,

  • quantité vendue d'un produit

  • ,...

Les propriétés sont caractérisées par leur type, qui peut être numérique, une représentation de date, ou une longueur spécifique peut être définie. Par exemple, le nom est une propriété de type alphabétique avec une longueur maximale de 50 caractères.

Entités

Une entité dans le modèle E-A[2] représente un objet, une personne, un lieu ou un concept distinctif du monde réel, qui peut être identifiable et distingué par ses caractéristiques propres. Dans un contexte de modélisation de données, une entité est souvent associée à une table dans une base de données relationnelle. Chaque entité est caractérisée par des attributs qui décrivent ses propriétés et ses caractéristiques spécifiques.

L'entité joue un rôle central dans la modélisation des données car elle permet de structurer et d'organiser les informations relatives à des éléments spécifiques du domaine d'application. Par exemple, dans un système de gestion d'une bibliothèque, une entité pourrait être "Livre", avec des attributs tels que "Titre", "Auteur", "Date de publication", etc.

Exemple

Les clients sont définis par certaines propriétés (numéro, nom, prénom...). Le fait de les regrouper amène naturellement à créer une entité Clients.

Le symbolisme retenu est le suivant :

Exemple de l'entité Client

L'identifiant

L'identifiant dans une entité du modèle entité-association (E-A) est un attribut spécial qui permet de distinguer de manière unique chaque occurrence de cette entité. Cet identifiant est souvent appelé "clé primaire" dans le contexte des bases de données relationnelles. Il sert à garantir que chaque ligne ou instance d'une entité dans la base de données est identifiable de manière exclusive.

Voici quelques points importants à propos de l'identifiant dans le modèle E-A :

  1. Unicité : L'identifiant doit être unique pour chaque occurrence de l'entité. Cela signifie qu'aucune autre occurrence de la même entité ne peut avoir la même valeur pour son identifiant.

  2. Stabilité : L'identifiant ne change généralement pas au cours de la durée de vie de l'entité. Il est stable et permet de référencer l'entité de manière constante.

  3. Utilisation : L'identifiant est essentiel pour établir des relations entre différentes entités dans le modèle E-A. Par exemple, dans un système de gestion d'une bibliothèque, l'identifiant d'un livre pourrait être un numéro d'identification unique assigné à chaque livre.

  4. Clé primaire : En bases de données relationnelles, l'identifiant est souvent défini comme la clé primaire de la table correspondante. Cela implique qu'il est utilisé pour indexer et accéder efficacement aux données de cette entité.

En résumé, dans le modèle E-A, l'identifiant d'une entité est un attribut crucial qui assure l'unicité et l'identification unique de chaque instance de cette entité au sein du système d'information.

Exemple

le fait de connaître la ville d'un client permet-­il de connaître son nom ? La réponse est non. Il faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est connue permet la connaissance de l'ensemble des valeurs qui s'y rattachent de façon formelle.

Ainsi, lorsque le numéro du client est connu, son nom, son prénom et toutes les valeurs des autres propriétés qui s'y rattachent sont connues de façon sûre et unique.

Au niveau du formalisme, cette propriété se souligne. Voici le schéma modifié de l'entité Clients.

Identifiant d'une entité

Relations

Une relation représente une association significative entre deux ou plusieurs entités. Elle exprime comment les entités sont connectées ou interagissent les unes avec les autres dans le contexte d'un système d'information.

Relation entre deux entité

Cardinalités

Les cardinalités dans le modèle E-A [2]définissent le nombre d'occurrences d'une entité qui peuvent être associées à un nombre donné d'occurrences d'une autre entité à travers une relation. Elles sont cruciales pour préciser la nature et la structure des associations entre les entités.

Dans notre exemple on peut se poser les questions suivantes :

  • Combien de fois au minimum un client peut­-il commander un article ?

  • Combien de fois au maximum un client peut­-il commander un article ?

À la première question, nous pouvons répondre qu'un client, pour être client, doit commander au moins un article. À la deuxième question, nous pouvons répondre qu'un client peut commander plusieurs articles.

Cardinalités dans une relation

Le "n" représente la notion de « plusieurs » ; ici nous avons représenté le fait qu'un client peut commander un ou plusieurs articles. Il faut que nous nous posions les mêmes questions pour l'article :

  • Combien de fois au minimum un article peut ­il être commandé par un client ?

  • Combien de fois au maximum un article peut ­il être commandé par un client ?

Pour le minimum, nous pouvons interpréter cela comme suit :

Y a-t-il des articles qui ne peuvent jamais être commandés ? Si nous répondons oui, alors la cardinalité minimale est 0.

Pour le maximum : Y a-t-il des articles qui peuvent être commandés plusieurs fois ? Si nous répondons oui, alors la cardinalité maximale sera n.

Voici le schéma finalisé :

Schéma avec toutes les cardinalités

Définitions

  1. La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu'une occurrence d'une entité participe aux occurrences d'une relation.

  2. La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu'une occurrence d'une entité participe aux occurrences de la relation.

Si le maximum est connu, il faut inscrire sa valeur. Par exemple, si dans les règles de gestion le client n'a le droit de commander qu'un maximum de 3 articles en tout et pour tout, dans ce cas ­là les cardinalités s'exprimeront de cette façon : 1,3.

Autre exemple :

Modélisons le fait qu'une mère élève des enfants, nous avons deux entités Mères et Enfants :

Exemple de modélisation

Les relations porteuses

Une relation est dite porteuse lorsqu'elle contient des propriétés.

Imaginons que l'on veuille connaître la quantité d'articles commandés par clients, nous nous rendons compte qu'il faut utiliser une nouvelle propriété Quantité. Cette nouvelle propriété dépend de clients, d'articles ou des deux ? La bonne réponse est que Quantité dépend des deux entités.

Voici le modèle conceptuel correspondant :

Relation porteuse

Nous pouvons interpréter ce schéma de la façon suivante : Le client X a commandé la quantité Y d'articles Z.

Si nous désirons connaître la date d'achat, il nous suffit de créer une entité Date à la relation Commander.

Une relation faisant intervenir deux entités est dite binaire. Une relation faisant intervenir trois entités est dite ternaire. Dans certains ouvrages elle est caractérisée par l'appellation « Tri­pattes ».

Exemple :

Exemple d'une relation ternaire

Relation réflexive

Une relation réflexive est une relation d'une entité sur elle­ même.

Par exemple, on désire modéliser le fait qu'un employé peut diriger d'autres employés.

Relation réflexive

À la lecture de ce schéma, nous interprétons donc qu'un employé peut diriger zéro ou plusieurs personnes et qu'un employé est dirigé par un et un seul autre employé.

Règles d'usages

  • Toute entité doit comporter un identifiant.

  • Toutes les propriétés de l'entité dépendent fonctionnellement de l'identifiant. C'est ­à­ dire que connaissant la valeur de l'identifiant, nous connaissons de façon sûre et unique la valeur des propriétés associées. Si nous recherchons le client numéro 5, nous devons récupérer le nom et le prénom du client numéro 5 et pas ceux d'une autre personne.

  • Le nom d'une propriété ne doit apparaître qu'une seule fois dans le modèle conceptuel des données. Si nous établissons une entité Clients et une nommée Fournisseurs, nous ne devons pas retrouver la propriété Nom dans les deux entités. Il faut préférer la dénomination suivante Nom_client et Nom_fournisseur.

  • Les propriétés résultantes d'un calcul ne doivent pas apparaître dans le modèle conceptuel des données.

Exercices : Série de TD 03

Ci-joint, vous trouverez la série de TD03 sur la modélisation des systèmes d'information à l'aide du modèle entité-association.