Site A.T.L.A.N.T.I.C-83
COURS = Initiation aux bases de données (Chapitre_3) - VERSION: 1.0 (M.A.J: 26/11/2017)
- AUTEUR(s): Bernard GIACOMONI
Ecran large mobile
Retour
sommaire cours

III.LE MODÈLE CONCEPTUEL ENTITÉS-ASSOCIATIONS:

AVANT PROPOS:
Nous avons vu au chapitre précédent que le MODÈLE CONCEPTUEL DES DONNÉES (MCD) a pour but d'élaborer une représentation du SYSTEME D'INFORMATION compréhensible au niveau de l'UTILISATEUR, à l'aide de concepts appelés ENTITÉS et ASSOCIATIONS. De ce fait, pour faciliter la compréhension, le MCD est représenté sous la forme d'un GRAPHIQUE. Nous allons étudier dans ce chapitre les différents éléments de base composant un graphique MCD et la manière de représenter les relations qui existent entre ces éléments.

III.1.LA NOTION D'ENTITÉ:


III.1.1.DÉFINITION:

Une ENTITÉ définit un ensemble d'individus ou d'objets ayant des CARACTÉRISTIQUES communes.
PAR EXEMPLE, dans la base de données d'une entreprise, on peut définir les entités «clients», «fournisseurs», «commandes», etc:
  • L'entité «CLIENTS» regroupera les données relatives à tous les clients de l'entreprise;
  • L'entité «FOURNISSEURS» regroupera les données relatives à tous les fournisseurs travaillant avec l'entreprise.
Les individus ou objets appartenant à une même entité sont appelés REPRESENTANTS de cette entité (Ainsi un représentant de l'entité «fournisseurs» est l'un quelconque de ces fournisseurs). De ce fait, une ENTITÉ doit être nommée par un NOM COMMUN AU PLURIEL.

III.1.2.ATTRIBUTS D'UNE ENTITÉ:

Les ATTRIBUTS sont des propriétés liées à chaque ENTITÉ. La valeur de ces attributs permet d'individualiser chacun des REPRESENTANTS d'une même ENTITÉ.
PAR EXEMPLE, l'entité ELÈVES peut avoir pour ATTRIBUTS le nom, les prénoms et la classe d'appartenance de chaque élève. Les REPRÉSENTANTS de cette entité sont des élèves qui se distingueront les uns des autres par les valeurs données à ces attributs :


Le schéma ci-contre représente une entité "ELÈVES" caractérisée par 3 attributs: Nom, Prénoms et Classe. Nous avons fait figurer dans le schéma trois des représentants de cette entité qui se différencient les uns des autres par les VALEURS des attributs:
  • Le réprésentant dont les valeurs d'attributs sont DUPOND, Thomas et CM2 (élève Thomas DUPOND, de la classe de CM2);
  • Le réprésentant dont les valeurs d'attributs sont DURAND, Agnès et CE2 (élève Agnès, de la classe de CE2);
  • Le réprésentant dont les valeurs d'attributs sont DUVAL, Annie et CM1 (élève Annie DUVAL, de la classe de CM1).
Entités

III.1.3.IDENTIFIANTS D'UNE ENTITÉ:

Lorsqu'un attribut permet de distinguer sans ambiguité chaque représentant d'une entité, cet attribut peut être pris comme IDENTIFIANT de l'entité. PAR EXEMPLE, dans une entité CLIENTS, l'attribut NomClient ne peut être pris comme identifiant, car deux clients peuvent avoir le même nom. En revanche, si tous les clients sont français, on pourrait prendre comme identifiant leur numéro de sécurité sociale.

Un identifiant peut être constitué de plusieurs attributs: ainsi, l'identifiant d'une entité ABONNÉS pourrait être constitué des attributs Pseudo et MotdePasse car le couple Pseudo - Mot de passe est en principe unique.

REMARQUE:
Dans la plupart des cas, il est très difficile de trouver un attribut ou un ensemble d'attributs "naturels" qui puisse servir d'identifiant. Dans ce cas, on peut toujours en créer un "artificiellement", en attribuant à chaque représentant de l'entité un numéro unique (par exemple, chaque nouveau client d'une entreprise peut se voir attribuer un numéro de client unique, qui n'est jamais réattribué). Les systèmes de gestion de bases de données peuvent gérer automatiquement ce type d'attribut, qui est souvent appelé dans le contexte des SGBD "ATTRIBUT ENTIER AUTOINCREMENTABLE" (il s'agit, bien sûr, d'un entier POSITIF).

III.1.4.REPRÉSENTATION GRAPHIQUE D'UNE ENTITÉ:

Dans le modèle CONCEPTUEL entité-association, une entité est représentée de la manière suivante:
Représentation graphique des entités REMARQUES:
  • L'entité CLIENTS est munie de l'identifiant NumClient, qui peut être dans ce cas un attribut entier positif autoincrémentable: Chaque client nouvellement créé dans la BD se verra attribuer un NumClient incrémenté de 1 par rapport au dernier client créé. La suppression d'un client ne libère pas la valeur de son NumClient qui ne pourra donc plus être utilisée;
  • L'entité ARTICLES est munie de l'identifiant NumArticle qui est probablement un nombre entier positif. Cependant, il n'est pas avantageux d'utiliser dans ce cas un attribut autoincrémentable, car dans le commerce, un article donné possède presque toujours un numéro de nomenclature unique qu'il est bien plus avantageux d'utiliser à cet effet.


III.2.LA NOTION D'ASSOCIATION:


III.2.1.DÉFINITION:

Une ASSOCIATION établit des CORRESPONDANCES entre les représentants d'une ENTITÉS A et ceux d'une entité B. Ces correspondances sont dites BIUNIVOQUES, car:
- Un représentant quelconque de A ne peut être mis en correspondance qu'avec un seul représentant de B (la correspondance est UNIVOQUE de A vers B);
- Un représentant quelconque de B ne peut être mis en correspondance qu'avec un seul représentant de A (la correspondance est UNIVOQUE de B vers A).
Le nom d'une association doit être un verbe à l'infinitif, comme ACHETER, COMMANDER, RESERVER, etc.

EXEMPLE: Si l'entité «CLIENTS» à pour représentants Client1, Client2, Client3 et Client4 et si l'entité ARTICLES a pour représentants Pommes, Poires, Abricots, l'association ACHETER pourra établir les correspondances représentés dans le schéma ci-dessous:

La signification logique sera:
  • Le client Client1 a acheté l'article Pommes;
  • Le client Client2 a acheté les article Pommes et Poire;
  • Le client Client3 a acheté l'article Pommes;
  • Le client Client4 a acheté l'article Poires.
REMARQUES: Personne n'a acheté l'article «Abricots». Par contre, tous les clients ont acheté quelque chose, car sinon, ils ne seraient pas clients.
Principe logique des associations
Notons (bien que cela ne soit pas vraiment dit par la théorie), qu'une association possède implicitement un "sens": dans l'exemple ci-dessus, l'association ACHETER se comprend dans le sens CLIENT --> ACHÈTE --> FRUIT. En sens inverse, il faudrait définir l'association EST ACHETÉ PAR. Cette remarque permettra de mieux appréhender la notion de CARDINALITÉ.

III.2.2.ATTRIBUTS D'UNE ASSOCIATION:

Une association entre deux entités établit donc un certain nombre de liens entre les représentants de la première entité et ceux de la seconde. Cependant, la connaissance de l'ensemble de ces liens ne suffit en général pas à caractériser totalement l'association.

PAR EXEMPLE: le schéma ci-dessus permet de connaître qui a acheté quoi, mais il ne permet pas de savoir en quelle quantité.

On a donc besoin dans certains cas de caractériser les associations par des attributs. Par exemple, l'association ACHETER pourrait se voir affecter les attributs «quantité_achetée» et «date_commande». De ce fait, les associations représentées dans les schémas de données dits CONCEPTUELS peuvent être caractérisées par des attributs de la même façon que les entités.

III.2.3.REPRÉSENTATION GRAPHIQUE D'UNE ASSOCIATION:

Les ASSOCIATIONS sont représentées dans les schémas conceptuels d'une manière assez semblables aux entités. La différences est que les coins des rectangles sont ARRONDIS:
Représentation graphique des associations


III.3.LES SCHEMAS ENTITÉS-ASSOCIATIONS:


III.3.1.RELATIONS BINAIRES ET NOTION DE CARDINALITÉ:

Nous avons vu que le MODELE CONCEPTUEL des bases de données RELATIONNELLES modélise les bases de données sous la forme d'ASSOCIATIONS D'ENTITÉS. Etudions le cas le plus simple de schéma ENTITÉ-ASSOCIATION: celui où une ASSOCIATION relie entre elles deux ENTITÉS (ASSOCIATION dite BINAIRE).
Le schéma conceptuel ci-dessous représente une telle association BINAIRE. Il exprime qu'il existe des correspondances établie entre les représentants de l'entité AUTEURS et ceux de l'entité ROMANS qui figurent dans la base de données: en gros, certains de ces auteurs ont écrit certains de ces romans (ce schéma conceptuel pourrait faire partie du schéma conceptuel d'une bibliothèque). Cependant, il inclue également certaines informations "quantitatives" qui vont permettre de répondre à certaines interrogations:
  • Est-ce que tous les auteurs figurant dans la base de données doivent avoir écrit au moins un des romans figurant dans cette BD ? On peut imaginer que certains auteurs aient écrit uniquement d'autres types d'oeuvres: nouvelles, articles, etc. ou encore que certains romans aient été supprimés de la base de données car tous les exemplaires ont disparus;
  • Les romans représentants de l'entité ROMANS doivent-ils obligatoirement avoir été écrit par un des auteurs représentants de l'entité AUTEURS?
  • Un roman peut-il avoir plusieurs auteurs ?
  • Etc.
Ce type d'interrogation va être résolu par la notation des CARDINALITÉS.


Menu de commande de l'animations

Exemple de schema d'association binaire
COMMENTAIRES:
  • Les LIENS LOGIQUES existants entre l'association et les entités sont figurés par des lignes droites continues;
  • Nous pouvons constater l'existence de couples de valeurs (numériques ou littérales) sur chacun de ces liens (ici, {0,n} pour le lien de gauche et {1,m} pour le lien de droite). Ces valeurs, qui sont toujours des entiers positifs ou nuls, expriment les CARDINALITÉS de la relation;
  • Ici, le couple figurant sur le lien de gauche (0,n), exprime qu'un auteur figurant dans la BD peut avoir écrit de 0 à n des romans figurant dans cette BD: on est donc dans le cas oû un auteur peut n'avoir écrit aucun de ces romans: ceci n'est pas aberrant si l'on suppose que la BD est également dotée d'une entité POÉSIES, par exemple: un auteur peut très bien n'écrire que des recueils de poésies;
  • Le couple figurant sur le lien de droite (1,m), exprime qu'un roman figurant dans la BD doit avoir été écrit par 1 ou plusieurs des auteurs figurant dans cette BD: on est donc dans le cas oû un roman doit forcément avoir été écrit par au moins un des auteurs figurant dans la BD.
  • Cette cardinalité, si elle était définie telle-quelle aurait une conséquence importante sur la gestion de la BD: la suppression d'un auteur devrait entraîner obligatoirement la suppression de la BD de tous les romans qu'il a écrit! une telle disposition n'est pas forcément aberrante, mais on conçoit que ses conséquences doivent être bien maîtrisées;
  • Ceci prouve bien que la définition des cardinalités est une tâche qui doit être menée avec le plus grand soin!


III.3.2.RECHERCHE DES CARDINALITÉS:

La cardinalité d’une association pour une des entités A et B qu'elle met en relation est donc un couple de nombres entiers positifs ou nuls :
  • Le premier nombre indique le minimum de fois qu’une occurrence de l’entité participe aux occurrences de l’association (généralement: 0 ou 1);
  • Le deuxième nombre indique le maximum de fois qu’une occurrence de l’entité participe aux occurrences de l’association (généralement 1 ou n);


III.3.3.LES TROIS TYPES D'ASSOCIATIONS BINAIRES:

Suivant les cardinalités qui relient les entités à l'association, on distingue trois sortes d'associations binaires:

TYPE UN à UN :
Lorsque, dans une association binaire, les deux cardinalités maximales sont égales à 1, l'association est de type "un à un" (ou 1:1):
Association de type 1:1
Ici, les cardinalités expriment qu'un employé d'une entreprise ne peut diriger au plus qu'un seul service et qu'un service a forcément un chef de service et n'en a qu'un seul (autrement dit: un service de l'entreprise a un chef et un seul).
TYPE UN à N :
Lorsque, dans une association binaire, UNE SEULE des cardinalités maximales est égale à 1, l'association est de type "un à N" (ou 1:N):
Association de type 1:N
Ici, les cardinalités expriment qu'un service peut employer de 1 à N employés (1, car il emploie au moins le chef de service), mais qu'un employé de peut appartenir qu'à 1 service et un seul.
TYPE M à N :
Lorsque, dans une association binaire, les deux cardinalités maximales sont supérieures à 1, l'association est de type "m à n" (ou m:n):
Association de type M:N
Ici, les cardinalités expriment qu'une commande concerne au moins 1 article, mais peut en concerner un nombre quelconque m (>=1), et qu'un article peut ne pas avoir été commandé ou avoir été commandé un nombre quelconque n de fois.


III.3.4.ASSOCIATIONS N-AIRES:

Le modèle prévoit également la possibilité d'ASSOCIATIONS reliant plus de deux ENTITÉS. Par exemple: les associations ternaires (reliant 3 entités), quaternaires (reliant 4 entités), et plus généralement, les associations N-aires, reliant N entités. Ces associations complexes sont toujours équivalentes à plusieurs associations binaires. De ce fait, lors de la conception du modèle d'une BD, il est conseillé de n'utiliser dans un premier temps que des associations binaires, puis, si nécessaire, de regrouper ces associations.
EXEMPLE-ASSOCIATION TERNAIRE:

Associations Ternaires
REMARQUE:
Déterminer les cardinalités des relations reliant plus de deux entités est assez difficile. Le principe à suivre est le suivant: "Dans une association n-ere, la cardinalité relative à une entité correspond au nombre d’occurrences possibles d'entités associées dans la relation quand les autres ( n-1 ) valeurs sont fixées".
Pour l'exemple ci-contre, ceci revient à se poser les questions suivantes :
  • En ce qui concerne l'entité Créneaux_Horaires, combien de créneaux horaires peuvent être affectées à un professeur donné dans une salle donnée, au minimum et au maximum ? (la réponse sera 1,n);
  • En ce qui concerne l'entité Professeurs, combien de professeurs peuvent enseigner dans une salle donnée et à un horaire donné, au minimum et au maximum ?  (la réponse sera 0,1);
  • En ce qui concerne l'entité Salles, combien de salles peuvent héberger l'enseignement d'un professeur à un horaire donné, au minimum et au maximum ? (la réponse sera 1,1).



III.4.EXEMPLE DE CONSTRUCTION D'UN M.C.D:

III.4.1.REMARQUE PRELIMINAIRE:

Un MCD peut être constitué de nombreuses entités et associations, chacune pouvant posséder plusieurs attributs. Il est évidemment indiqué pour la lisibilité des diagrammes de donner à ces attributs des noms évocateurs de leur nature. Cependant, si l'on n'y prend pas garde, cette démarche peut aboutir à donner les mêmes noms à des attributs appartenant à des entités ou associations différentes.
PAR EXEMPLE:
Des entités CLIENTS et FOURNISSEURS risquent fort de se retrouver dotées toutes les deux d'attributs nommés e_mail ou adresse_postale: ceci n'est pas grave tant qu'on s'en tient au diagramme MCD, puisque ces attributs apparaissent à l'intérieur de leurs entités ou associations respectives. En revanche, cela pourra poser des problèmes dès qu'on abordera les niveaux logiques et physiques, notamment pour nommer ce qu'on appellera les "clefs étrangères").
Une solution simple à ce problème est de faire référence dans le nom d'un attribut au nom de l'entité ou de l'association auquel il appartient (ou, pour ne pas trop alourdir la notation, à deux lettres du nom de l'entité). Par exemple:
  • L'attribut nom de L'entité Clients sera nommé nom_cl;
  • L'attribut email de L'entité Fournisseurs sera nommé email_fo.
C'est cette méthode que nous emploierons par la suite.


III.4.2.SYSTÈME A MODÉLISER:

Le modèle conceptuel doit modéliser un SYSTÈME D'INFORMATION gérant une BIBLIOTHÈQUE. Supposons que les spécifications à respecter aient été définies par les personnels chargés de la gestion de la manière suivante:
  • Le système d'information doit pouvoir fournir l'identité et la biographie des auteurs;
  • Le système d'information doit pouvoir fournir le titre, l'année de parution et une présentation de chacun des livres qu'il gère;
  • Un livre est emprunté à une date donnée et pour une durée déterminée.
  • Un emprunt concerne un seul ouvrage;
  • Pour emprunter un livre, il faut être abonné à la bibliothèque.


III.4.3.ANALYSE DU PROBLEME:

La simple lecture de ces spécifications permet déja de repérer:
  • Des ENTITÉS qui entreront dans la constitution du MCD: Auteurs, Livres, Abonnés;
  • Des ASSOCIATIONS qui relieront ces entités: Ecrire, Emprunter;
  • Certains des attributs des entités et associations (Pour Auteur: identité, biographie, pour Emprunter: date et durée, pour Livres: le titre, l'année de parution, une présentation, etc.).
On peut également repérer certaines consignes concernant la gestion (obligation d'être abonné pour emprunter, etc.).
A ce stade, on peut déja dessiner le MCD suivant:
MCD bibliothèque provisoire
Ceci n'est évidemment qu'une première approche du problème. En effet:
  • il paraît évident que la gestion des abonnées exigera que l'on définisse des attributs pour cette entité;
  • Les cardinalités ne sont pas encore définies
  • Les spécifications données par les administrateurs manquent de précision: par exemple, il faut faire la différence entre un ouvrage littéraire (un livre dans le langage courant), et un exemplaire de cet ouvrage: dans le premier cas, il s'agit d'une création de l'esprit alors que dans le deuxième cas, il s'agit d'un objet physique. Ce qui est emprunté est bien sûr un exemplaire d'un livre. ceci aura pour conséquence que plusieurs exemplaires d'un même livre pourront être empruntés simultanément;
  • Le point précédent va amener la définition d'une entité supplémentaire (l'entité Exemplaire) et d'une nouvelle association, l'association Correspondre qui permettra d'associer à chaque exemplaire le livre dont il est le représentant.

Ces spécifications supplémentaires sont en géneral le résultat d'un travail d'approfondissement mené par l'informaticien chargé du projet en collaboration avec les utilisateurs.
Après détermination des cardinalités, le MCD complété pourrait ressembler à ce qui suit:
Menu de commande de l'animations

MCD approfondi de la bibliothèque
En définitive, pour traduire ce recueil de besoins:
  • Nous avons créé l'entité AUTEURS et l'entité LIVRES;
  • Nous avons mis en relation ces deux entités par l'association ECRIRE;
  • Nous avons attribué la cardinalité 1,m à l'entrée de l'association Ecrire. Celle-ci exprime qu'un auteur a écrit au moins un des livres répertoriés dans la bibliothèque;
  • Celle-ci exprime qu'un livre doit être écrit par un ou plusieurs AUTEURS, ce qui permet de prendre en compte les ouvrages collectifs.
  • Nous avons créé l'entité EXEMPLAIRES, distincte de l'entité LIVRES, de façon à exprimer le fait que la bibliothèque peut posséder plusieurs exemplaires d'un même livre. Ces deux entités sont reliées par la relation CORRESPONDRE;
  • Nous avons attribué la cardinalité 0,n à l'entrée de l'association CORRESPONDRE (et non 1, n), ce qui permet de spécifier le fait qu'un LIVRE donné peut continuer à être géré même si l'on ne possède plus aucun exemplaire de ce livre!
  • Nous avons attribué la cardinalité 1.1 à la sortie de l'association CORRESPONDRE exprime qu'un exemplaire correspond à un livre et un seul;
  • Nous avons créé l'entité ABONNÉS et nous l'avons mise en relation avec l'entité EXEMPLAIRES par l'association EMPRUNTER;
  • Nous avons attribué la cardinalité 0,n à l'entrée de la relation EMPRUNTER pour spécifier qu'à un instant donné, un abonné peut avoir emprunté de 0 à n exemplaires d'un même livre ou de livres différents;
  • Nous avons attribué la cardinalité 0,1 à la sortie de la relation EMPRUNTER pour spécifier qu'un exemplaire ne peut être emprunté simultanément par plusieurs abonnés.


III.RÉCAPITULATION ET CONCLUSION:

  • Dans ce chapitre, nous avons decouvert et décrit les différentes règles et les différents concepts logiques qui sont utilisés pour analyser l'organisation d'un système d'information et le traduire sous la forme d'un MODÈLE CONCEPTUEL DE DONNÉES (M.C.D);
  • Ensuite, nous avons appliqué ces enseignements à l'étude d'un cas simple mais concret de système d'informations (une bibliothèque). Le résultat de ces travaux est le schéma du M.C.D de ce domaine. Cette étape est nécessaire pour permettre de justifier, compléter et stabiliser les exigences des futurs utilisateurs du système: elle correspond en gros à la phase de spécification technique du besoin (S.T.B) d'un projet classique;
  • Cependant, comme dans le cas d'une S.T.B, elle ne permet pas de passer directement à la réalisation du système informatique car l'étude reste à un niveau FONCTIONNEL, c'est à dire qu'elle n'aborde pas l'aspect TECHNIQUE: contraintes et performances à respecter, etc;
  • De ce fait, une étape intermédiaire doit être effectuée avant de commencer la réalisation. Cette étape, qui correspond à peu près à la phase de conception préliminaire d'un projet classique va permettre de déduire du M.C.D un nouveau modèle moins compréhensible par les utilisateurs mais beaucoup plus proche des aspects techniques, le MODÈLE LOGIQUE DES DONNÉES (M.L.D);
  • L'avantage du M.L.D par rapport au M.C.D est qu'il pourra être directement traduit par les développeurs dans le langage du SGBD choisi, car les entités qui le composent correspondent à des entités manipulées par les directives (requêtes) composant ce langage.



Retour accès aux cours Retour sommaire cours
FormateurGaucheRepos FormateurGaucheActif FormateurDroitRepos FormateurDroitActif