Ce document est une fiche de révisions complète destinée aux étudiants universitaires, en particulier ceux suivant une formation en gestion des systèmes d'information. Il a pour objectif de clarifier les principes essentiels de la modélisation de bases de données relationnelles, outils indispensables à la conception d'un système d'information performant et cohérent.
Il couvre les notions suivantes :
- Le Modèle Conceptuel des Données (MCD) et le schéma relationnel.
- Les entités dépendantes, les pseudo-entités, la spécialisation et la réflexivité.
- Les contraintes d'association et d'intégrité référentielle.
Modélisation Merise : Fiche de révisions MCD et schéma relationnel
Télécharger PDFFiche de révisions : MCD et schéma relationnel
MCD - Généralités
Le Modèle Conceptuel de Données (MCD) est un diagramme essentiel qui offre une représentation schématique d'une partie ou de la totalité d'une base de données relationnelle. Lorsque la complexité d'une base de données augmente, il est courant de diviser le modèle en sous-modèles.
Les MCD s'inscrivent dans la méthode MERISE, une approche de conception française, qui inclut également d'autres schémas et diagrammes importants comme le Modèle Organisationnel des Traitements (MOT) et le schéma relationnel.
Plus spécifiquement, le MCD permet de modéliser les tables (ou entités) et les relations qui les unissent. On peut grossièrement considérer une table comme un "grand tableau" structuré.
Avec l'essor et le développement de la programmation orientée objets (POO ou OOP en anglais), cette méthode de conception tend à être remplacée en pratique par la notation UML (Unified Modeling Language), qui propose des concepts similaires mais avec une approche plus orientée programmeur.
MCD et syntaxe
Le MCD possède sa propre syntaxe et un vocabulaire qui lui est propre. On y distingue principalement des entités et des associations, c'est pourquoi il est parfois désigné comme le modèle entités-associations.
Entité
Une entité est une unité élémentaire qui se suffit à elle-même, représentant un objet du monde réel ou un concept (par exemple : un client, un fournisseur, un produit, un article). Chaque entité correspond, de manière simplifiée, à une table dans une base de données.
Elle possède un nom et des propriétés, également appelées attributs, qui correspondent aux colonnes du tableau.
Optionnellement, comme en algorithmique, on précise le type de chaque propriété (par exemple : entier, texte, date).
La ou les propriétés qui identifient de manière unique chaque enregistrement d'une entité sont appelées la clef primaire. Elles sont généralement soulignées dans la représentation graphique.
Visuellement, une entité est représentée par un rectangle.
Exemple d'entité : Client
- N° Client (Integer)
- Raison sociale (Varchar(30))
- Date immatriculation (Date)
- ....
Association
Une association décrit une relation existant entre plusieurs entités. Elle n'a de sens que sous réserve de l'existence des entités qu'elle relie. On entend par "relation" une forme d'appartenance ou de lien (par exemple : un client "réalise" un chiffre d'affaires).
Elle possède un nom et, éventuellement, des propriétés spécifiques, appelées propriétés portées (sous-entendu portées par l'association).
Important : Une association peut ou non correspondre à une table dans le schéma relationnel. Si l'association correspond à une Contrainte d'Intégrité Fonctionnelle (CIF), elle ne correspond pas à une table mais à une clef étrangère. Si l'association correspond à une Contrainte d'Intégrité Multiple (CIM), elle correspond à une table distincte.
Visuellement, une association est représentée par un ovale.
Exemple d'association : Réaliser CA
- Année
- Montant
Dans l'exemple ci-dessus, "Année" et "Montant" sont deux propriétés portées par l'association. Le nom d'une association est souvent un verbe, ce qui facilite la lecture du diagramme sans être une obligation.
Clef primaire
Si une table est une sorte de tableau et les propriétés des sortes de colonnes, alors une clef primaire correspond grossièrement à l'identifiant de la ligne, c'est-à-dire la ou les colonnes identifiant la ligne.
Toute table possède une clef primaire, un identifiant. Cet identifiant est unique et propre à chaque ligne. Lorsque la clef primaire est constituée de plusieurs propriétés, on parle de clef primaire composée.
Important :
- La clef primaire propre à une entité doit figurer dans les propriétés de l'entité et est soulignée.
- La clef primaire correspondant à une association est sous-entendue. Elle est constituée de la clef primaire de chacune des entités qu'elle met en relation (dans le cas où l'association génère une table).
Cardinalités
Une association relie au moins deux entités entre elles. Si elle relie trois entités, on dira que c'est une association ternaire. Les cardinalités précisent le lien entre les entités reliées. Elles permettent de spécifier la quantité minimale et maximale qu'une entité a d'une autre entité.
Dans le cas d'une ternaire, les cardinalités seront forcément des (0,n) voire (1,n).
Important :
- CIM (Contrainte d'Intégrité Multiple) : Lorsque les cardinalités sont de la forme (X,n) - (Y,n) (exemple : 0,n - 1,n) avec X et Y des nombres. Si une association représente une CIM, alors l'association correspond à une table.
- CIF (Contrainte d'Intégrité Fonctionnelle) : Lorsque les cardinalités sont de la forme (X,1) - (Y,n) (exemple : 1,1 - 0,n) avec X et Y des nombres. Si une association représente une CIF, alors elle ne correspond pas à une table mais à une clef étrangère. La clef étrangère apparaît alors dans la table correspondant à l'entité ayant la cardinalité de la forme (X,1).
Association et entités mises en relation sont reliées par un trait, appelé patte. Sur ces pattes, on précise la cardinalité, et optionnellement le rôle de la patte (sa signification).
Exemple :
- Une écriture comptable est constituée de 2 à plusieurs lignes (cardinalité : 2,n).
- Un compte peut apparaître dans aucune à plusieurs écritures comptables (cardinalité : 0,n).
Dans cet exemple, l'association "Ligne" représente une CIM. "Ligne" correspond donc à une table.
Clef étrangère
Dans un MCD, une clef étrangère est implicitement représentée par une CIF. Dans un schéma relationnel, la clef étrangère est représentée par un ou plusieurs champs. Lorsque la clef étrangère est constituée de plusieurs propriétés, on parle de clef étrangère composée. Grossièrement, une clef étrangère correspond, dans une table, pour chaque ligne, à une valeur pointant vers l'identifiant d'une ligne d'une autre table.
Schéma relationnel - Généralités
Le schéma relationnel, volontiers appelé Modèle Physique des Données (MPD), est une autre représentation d'une base de données relationnelle, plus concrète (moins "conceptuelle"). Il représente concrètement ses tables, leur clef primaire, leurs clefs étrangères et leurs autres champs. On le rédige sous la forme d'une sorte de liste dans laquelle figurent les informations citées ci-avant.
Syntaxe du schéma relationnel
La syntaxe est la suivante : MaTable(MaClefPrimaire, #UneClefEtrangere, UnChamp, ...)
Détail :
- Le ou les champs constituant la clef primaire sont soulignés.
- Les clefs étrangères éventuelles sont préfixées par un "#".
- Les autres champs sont simplement mentionnés.
- La clef primaire peut être constituée de plusieurs champs, tous soulignés.
- Il peut y avoir aussi bien aucune qu'une ou plusieurs clefs étrangères.
- Il peut très bien y avoir aucune, une ou plusieurs clefs étrangères dans la clef primaire.
- Une clef étrangère peut très bien être constituée de plusieurs champs, la syntaxe diffère alors légèrement :
MaTable(MaClefPrimaire, #(Champ1, Champ2), UnChamp, ...). Le couple (Champ1, Champ2) fait ci-dessus office de clef étrangère composée.
Exemple : On notera que la CIM ("Ligne") correspond bien à une table.
Ecriture(EcritureNum, EcritureLib, PieceRef, ...)Ligne(#EcritureNum, #CompteId, Debit, Credit, Lettrage, ...)Compte(CompteId, CompteNum, CompteAuxNum, CompteLib, ...)
Entité dépendante
Quoiqu'une entité soit une unité a priori indépendante, il arrive qu'on veuille la faire dépendre d'une ou plusieurs autres entités. En ce sens, une telle entité s'apparente à une association. Il y a principalement deux cas pratiques où l'on est tenté de faire dépendre une entité d'une (ou plusieurs) autre :
-
Lorsque l'on souhaite que l'identifiant d'une entité dépende d'une autre entité
Exemple : Facture n°F401CAROUF123456.
On a choisi de faire dépendre notre numéro de facture du compte auxiliaire propre à Carrefour (401CAROUF) et de préciser ensuite le "combientième" facture est adressée à Carrefour. Le 123456 correspond à la valeur de l'identifiant relatif, à savoir que c'est la 123456ème facture adressée spécifiquement à Carrefour. Une telle situation peut être modélisée par une entité dépendante.
Visuellement, l'entité dépendante (dite entité faible) est reliée à l'entité "forte" par une association avec une cardinalité (1,1) côté entité faible, parfois annotée (R) pour relatif, et (0,n) côté entité forte.
Schéma relationnel :
Facture(#IdCompte, NumFacture, DateEmission, ...)Compte(IdCompte, NumCompte, NumCompteAux, ...)
-
Lorsque l'existence d'une entité n'a de fait de sens que sous réserve de l'existence d'une ou plusieurs autres
Exemple : Un appartement n'existe que sous réserve de l'existence de l'immeuble. Détruisez l'immeuble, l'appartement n'existe plus. On peut alors modéliser cette dépendance par une entité dépendante.
Important : Comprenez bien que, lorsque l'on modélise une base de données, on pense la modélisation en fonction du résultat qu'on veut obtenir. Il y a souvent plusieurs possibilités. On choisit la modélisation qui répond au besoin.
Pseudo-entité
Le concept de pseudo-entité est assez proche de celui d'entité dépendante. Cette fois-ci, on souhaite non plus qu'une entité se comporte un peu comme une association, mais qu'une association se comporte un peu comme une entité. En fait, une association met en relation au moins deux entités. Mais il arrive que l'on souhaite pouvoir adjoindre des CIF (des clefs étrangères) à une association. Autrement dit : on peut avoir une association de type CIM, relative à deux entités (ou plus), et pouvoir lui ajouter d'autres relations (comme on le ferait pour une entité). Alors, on peut modéliser cette situation sous forme de pseudo-entité.
Comment se visualiser une pseudo-entité ? On peut se dire qu'une pseudo-entité, c'est une CIM centrale (i.e. typiquement une association relative à deux entités) à laquelle on ajoute une ou plusieurs CIF.
Quand est-on tenté d'utiliser une pseudo-entité ? Lorsqu'une relation (association) n'a de sens que relativement à deux entités (ou plus).
Exemple : On souhaite réserver une nuit d'hôtel à une date donnée. La réservation n'a de sens que relativement à l'hôtel et à la date (i.e. réserver d'une part l'hôtel, d'autre part la date, ne fait pas sens si elles ne sont pas liées).
Visuellement, la pseudo-entité peut être symbolisée par un rectangle en pointillés. La notation équivalente peut être un rectangle en pointillés uniquement autour de l'association "Réservation".
Schéma relationnel :
Hôtel(NumHotel, NomHotel, ...)Date(Date)(Note : en pratique, la création d'une table dédiée aux dates n'est pas toujours nécessaire, une colonne de type DATE étant souvent suffisante pour une simple date.)Client(NumClient, MailClient, ...)Réservation(#NumHotel, #Date, #NumClient, NbNuits)
Dans cet exemple, "Réservation" se comporte comme une CIM et génère une table. "Passer" (entre Client et Réservation) est une CIF, et "NumClient" devient une clef étrangère dans la table Réservation.
Spécialisation (Héritage)
La spécialisation, également appelée héritage (terme souvent utilisé en POO et UML), consiste à regrouper les propriétés communes d'entités semblables au sein d'une même entité, appelée entité générique (ou entité parente). Les entités semblables, qui partagent ces propriétés et en ajoutent de spécifiques, sont appelées entités spécialisées (ou entités filles).
Il n'y a qu'une façon de modéliser la spécialisation sous forme de MCD (au moyen d'un triangle reliant les entités filles à l'entité parente, avec une flèche pointant vers l'entité parente). Pour le schéma relationnel, plusieurs manières existent ; nous retiendrons une approche pédagogique.
Quand est-on tenté d'utiliser la spécialisation ? Lorsque l'on a besoin de modéliser deux ou plusieurs entités qui sont similaires, ne diffèrent que par quelques propriétés spécifiques, et partagent beaucoup de propriétés communes (i.e., ces entités sont sémantiquement proches).
Les types de spécialisation :
- X (Exclusivité) : Équivaut à un OU logique exclusif. Une instance de l'entité parente est l'une ou l'autre des entités filles, mais pas les deux à la fois. Elle peut aussi n'être aucune des deux.
- T (Totalité) : Équivaut à un OU logique inclusif. Une instance de l'entité parente est l'une, l'autre, ou les deux entités filles. Elle ne peut pas n'être aucune des deux.
- XT ou + (Partition) : Combine la totalité et l'exclusivité. Une instance de l'entité parente est soit l'une, soit l'autre des entités filles, mais ni les deux, ni aucune des deux.
- Vide : Tout et n'importe quoi. Une instance de l'entité parente peut être l'une, l'autre, les deux, ou aucune des entités filles.
Schéma relationnel :
Dans le MCD, les clefs primaires des entités filles sont sous-entendues et ne doivent pas être précisées. Ci-dessous, une modélisation possible de la spécialisation, souvent utilisée pour l'apprentissage, bien qu'elle puisse être considérée comme inefficace en pratique pour certains contextes.
Personne(NumPersonne, Adresse, CodePostal, ...)PersonneMorale(#NumPersonne, RaisonSociale, SIRET, ...)PersonnePhysique(#NumPersonne, NumSecu, NumIME, ...)
Réflexivité
En matière de bases de données, la réflexivité est un concept nécessaire afin de produire une structure arborescente ou récursive. Elle permet de modéliser des hiérarchies ou des relations d'antécédence. L'exemple typique est celui de l'arbre généalogique, qui représente des liens de filiation entre personnes. Il n'est pas nécessaire d'avoir une entité distincte pour "parent" et "enfant" ; l'entité "Personne" suffit.
Avec la réflexivité, on retrouve encore les concepts de CIF et de CIM. Seulement, au lieu d'avoir deux entités différentes reliées, on a une entité reliée à elle-même. Il est alors contraint de préciser le rôle de chacune des pattes de l'association réflexive.
Exemple : Dans un arbre généalogique, une personne peut avoir le rôle de parent, et une autre celui d'enfant. Les deux sont bien des personnes, mais elles n'ont pas le même rôle dans la relation. C'est comme s'il y avait deux entités, mais deux fois la même.
Visuellement, l'association réflexive est représentée par un ovale relié à la même entité par deux pattes, chacune avec un rôle (par exemple, "A pour parents" et "A pour enfants") et des cardinalités. Les cardinalités peuvent être (2,2) et (0,n).
Schéma relationnel :
On notera que l'association "Filiation" correspond à une CIF, ne donnant pas lieu à une table distincte. Elle se traduit par l'intégration de clefs étrangères au sein de la table de l'entité.
Personne(NumPersonne, #Pere, #Mere, Prenom, Nom, ...)
Ci-dessus, les champs "Pere" et "Mere" sont chacun une clef étrangère pointant vers la clef primaire "NumPersonne" de la même table "Personne". Qu'il s'agisse de parents ou d'enfants, il n'y a finalement ici que des personnes !
Contraintes d'association
Les CIF et les CIM ne sont pas les seules contraintes pesant sur une base de données relationnelle. Il en existe de nombreuses, appelées contraintes d'intégrité référentielle, qui visent à garantir que les données stockées sont intègres et conformes aux règles de gestion imposées (ex : règles de nommage, plages de valeurs, etc.).
Certaines de ces contraintes ne peuvent être modélisées sur un MCD ou un schéma relationnel, mais peuvent être implémentées directement dans la base de données (contrôles de base de données) ou via un logiciel applicatif (contrôles applicatifs).
En revanche, il existe une catégorie de contraintes que l'on peut modéliser sur un MCD : les contraintes d'associations. Elles sont sans impact direct sur le schéma relationnel.
Contrainte d'inclusion (I)
Le terme "inclusion" est peu intuitif et symbolise une "implication". Une telle contrainte représente le fait que, pour participer à une relation (association), il faille qu'une instance apparaisse dans une autre relation.
Autrement dit, une ligne ne peut apparaître dans la table correspondant à une association que si tout ou partie de sa clef primaire apparaît dans la table correspondant à une autre association.
Exemple : Un sportif ne peut jouer un match que s'il fait partie de l'une des équipes s'affrontant. Cela signifie que pour qu'un couple (N°Licence, N°Équipe) apparaisse dans la table "Jouer", il faut que ce même couple apparaisse dans la table "Faire partie". Elle est représentée sur le MCD par une flèche annotée "I" allant de l'association dépendante vers l'association impliquante (Ex: Jouer => Faire partie).
Contrainte d'exclusion (X)
C'est le même "X" que celui de la spécialisation. Une contrainte d'exclusion, placée entre deux associations, signifie qu'une instance ne peut pas participer aux deux relations à la fois (l'une, l'autre ou aucune).
Contrainte de totalité (T)
C'est le même "T" que celui de la spécialisation. Une contrainte de totalité, placée entre deux associations, signifie qu'une instance doit absolument participer à l'une ou l'autre des deux associations (l'une, l'autre ou les deux).
Contrainte de partition (XT ou +)
Ce sont les mêmes "XT" et "+" que ceux de la spécialisation. Une contrainte de partition, placée entre deux associations, signifie qu'une instance ne peut ni participer aux deux relations à la fois ni participer à aucune (l'une ou l'autre, exclusivement).
Contrainte de simultanéité (=)
Une contrainte de simultanéité, placée entre deux associations, signifie qu'une instance doit absolument participer à l'une et à l'autre des associations (les deux). Cela revient à un "ET" logique.
FAQ : Questions Fréquemment Posées sur les MCD et Schémas Relationnels
Quelle est la différence entre un MCD et un schéma relationnel ?
Le Modèle Conceptuel de Données (MCD) est une représentation abstraite et graphique des données et de leurs relations, indépendante de toute technologie d'implémentation. Le schéma relationnel, ou Modèle Physique de Données (MPD), est une représentation plus concrète qui détaille les tables, leurs colonnes (avec types), clefs primaires et étrangères, en vue d'une implémentation directe dans une base de données.
Comment les cardinalités influencent-elles la création de tables ?
Les cardinalités sont fondamentales pour la transformation du MCD en schéma relationnel. Si une association présente des cardinalités de type Contrainte d'Intégrité Multiple (CIM, comme (0,n)-(0,n)), elle se traduit par la création d'une table distincte. En revanche, si elle présente des cardinalités de type Contrainte d'Intégrité Fonctionnelle (CIF, comme (1,1)-(0,n)), elle se traduit par l'ajout d'une clef étrangère dans la table de l'entité située du côté de la cardinalité (X,1).
Quand faut-il utiliser une entité dépendante ou une pseudo-entité ?
Une entité dépendante est employée lorsqu'une entité n'a de sens ou ne peut être identifiée que par rapport à une ou plusieurs autres entités (par exemple, un appartement qui dépend de l'existence de son immeuble). Une pseudo-entité est utilisée lorsqu'une association elle-même doit avoir des propriétés spécifiques ou participer à d'autres relations, la faisant ainsi se comporter comme une entité à part entière (par exemple, une réservation d'hôtel qui est liée à la fois à un client, un hôtel et une date).