¶ Modèle Entité-Association (E/A)
¶ Rappel sur les bases de données
Soit la table suivante qui représente l'information des particuliers inscrit sur un site web:
Si nous rajoutons une table (par exemple la table Date), il faut lier les 2 tables à l'aide d'une clé afin d'avoir une relation:
¶ Explication du modèle E/A
Le modèle entité-association est une méthode de modélisation visuelle qui permet de représenter la structure logique d'une base de données en décrivant les entités (tables), leurs attributs (colonnes) et les relations entre elles avant l'implémentation dans MySQL. Ce modèle permet de faire la colle entre le monde réel et le monde informatique:
Pour utiliser ce modèle, nous enregistrons nos besoins sous format d'un texte. Ce texte contient:
- Activités générant des données
- Données à stocker
- Règles que les données doivent respecter
La modélisation des données assure le passage des activités du monde réel au monde informatique en transformant le texte sous format d’un graphe composé de symboles représentant les informations les plus pertinentes du point de vue informatique.
Le modèle E/A est parfois aussi désigné par le modèle MCD.
- Le terme "Entité/Association" est plus générique et international, issu des travaux de Peter Chen
- Le terme "MCD" est plus couramment utilisé dans le monde francophone, notamment dans la méthode Merise
¶ Concept 1: La notion d'entité et de classe
Entité : Un objet ou un concept du monde réel ayant une existence propre et qui sera représenté dans la base de données (exemple : un client, un produit).
Classe : Un regroupement d'entités de même type partageant les mêmes caractéristiques ou attributs (exemple : la classe "Clients" regroupe tous les clients).
Occurrence : Une instance particulière d'une entité ou d'une classe, avec ses valeurs spécifiques (exemple : le client "Jean Dupont" est une occurrence de la classe "Clients").
| Attribut d’une entité: Propriété, caractéristique ou qualité d’une entité |
Employé: matricule, nom, prénom, fonction Département: code département, nom département |
| Domaine de l’attribut: Ensemble de valeurs acceptables pour l'attribut considéré |
Attribut « nom département » (contient l’ensemble des départements présents dans l’entreprise Exemple: ventes, achats, marketing, finances, RH |
|
Classe d’entité: La classe de toutes les entités qui sont de même nature Occurrence d’une entité (ou instanciation): Individu particulier faisant partie d'une entité |
Exemple: Manager, Directeur, Assistant, Ingénieur, etc. regroupés dans une seule entité « employés » car ils partagent les mêmes caractéristiques |
| Clé / Identifiant (id): Attribut ou ensemble d'attributs permettant d'identifier de manière unique et sans ambiguïté les occurrences d'une entité (un individu particulier) |
Exemple: 001309, Pardo, Pablo, Ingénieur Si deux personnes partagent le même nom, prénom et fonction dans l’entreprise alors la clé ici serait la matricule (001309) |
¶ Concept 2: La notion d’association
L’ association est lien qui définit la relation entre deux ou plusieurs entités en se basant sur des attributs communs.
- Attribut d’une association: Propriété, caractéristique ou qualité qui dépend de TOUTES les entités intervenant dans l’association.
- Cardinalité d’une association : Nombre minimal et maximal de participations d’une occurrence d’une entité dans une association (cardinalité min = 0 ou 1 / cardinalité max = 1 ou N)
Exemple : Chaque département est désigné par son code unique et son nom. Chaque employé sera affecté à un seul département. Un employé sera désigné par son matricule unique, son nom et prénom et sa fonction au sein de l'entreprise.
Questions à se poser:
Quel est le lien entre les entités? (ici 2 entités: employé et département)
Quel est le verbe situé entre les deux entités dans le texte? (verbes = liaisons entre les entités)
¶ Concept 3: La notion de cardinalité
La cardinalité dans le modèle entité-association (E/A) d'une base de données décrit les relations entre les différentes entités.
Cardinalité 1:1 (un à un)
Dans une relation 1:1, une entité de type A est associée à une seule entité de type B, et vice versa. Par exemple, chaque personne possède une seule carte d'identité, et chaque carte d'identité appartient à une seule personne. Par exemple:
- Personne (ID_personne, nom, prénom)
- CarteIdentité (ID_carte, date_délivrance, ID_personne)
Cardinalité 1 (un à plusieurs)
Dans une relation 1, une entité de type A peut être associée à plusieurs entités de type B, mais une entité de type B ne peut être associée qu'à une seule entité de type A. Par exemple, un client peut passer plusieurs commandes, mais chaque commande est passée par un seul client. Par exemple:
- Client (ID_client, nom, prénom)
- Commande (ID_commande, date_commande, ID_client)
Cardinalité N (plusieurs à plusieurs)
Dans une relation N, plusieurs entités de type A peuvent être associées à plusieurs entités de type B. Par exemple, les étudiants peuvent suivre plusieurs cours, et chaque cours peut être suivi par plusieurs étudiants. Par exemple:
- Étudiant (ID_étudiant, nom, prénom)
- Cours (ID_cours, intitulé, crédit)
- Inscription (ID_étudiant, ID_cours, date_inscription)
Dans une cardinalité de type plusieurs @ plusieurs, il faut impérativement avoir une 3e table (table intermédiaire) qui permet le lien entre les 2 tables.
¶ Exemple
Un site Web propose des cours et des formations. Un étudiant peut suivre un ou plusieurs cours.
Comment pouvons-nous représenter ces propos sous forme de diagramme? Comment décomposer les propos selon le concept 1, 2 et 3?
¶ Passage du modèle E/A au modèle relationnel
¶ Régle 1: Les entités
- Les entités se transforment en une table
- Les attributs de l’entité vont constituer les colonnes de la table
¶ Règle 2: Association binaire (x,1)-(x,N)
Association binaire: il y a juste 2 entités. Les possibilités sont:
(0,1)-(0,N) ou (0,1)-(1,N) ou (1,1)-(1,N) ou (1,1)-(0,N)
La clé primaire issue de l’entité côté cardinalités (0,N) ou (1,N) (= FORTE) est dupliquée dans la table issue de l’entité côté cardinalités (0,1) ou (1,1) (= FAIBLE) où elle devient clé étrangère
Prenons l'exemple suivant:
¶ Règle 3: Association binaire (0,1)-(1,1)
La clé primaire de la table issue de l’entité côté cardinalités (0,1) est dupliquée dans la table issue de l’entité côté cardinalités (1,1) où elle devient clé étrangère
Voici un exemple:
¶ Règle 4: Association binaire (0,1)-(0,1)
La clé primaire de la table issue de l’un des entités est dupliquée dans la table issue de l’autre entité où elle devient clé étrangère
Voici un exemple pour la règle 4:
¶ Règle 5: Association binaire (1,1)-(1,1)
Il existe plusieurs manières de gérer ce cas, mais la manière la plus adaptée est la fusion des tables issues des entités de l’association.
Voici un exemple de la règle 5 (ex.: contrat de mariage):
Une femme épouse un homme
Un homme épouse une femme
¶ Règle 6: Association binaire (*,N)-(*,N)
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des 2 tables. Si l’association contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Les possibilités sont:
