TD No 1 corrigé Modèle Conceptuel – Schéma Relationnel

Ce document pédagogique, élaboré par l'Université de Provence, est destiné aux étudiants de troisième année de Licence d'Informatique dans le cadre de leur cours de Bases de données. Il constitue le Travail Dirigé n°1 et vise à explorer les principes fondamentaux de la modélisation conceptuelle des données.

Il couvre les notions essentielles suivantes :

  • La description détaillée du modèle entité-association (entités, associations, attributs et cardinalités).
  • Les règles de transformation d'un modèle conceptuel en un schéma de base de données relationnelle.
  • Des exercices pratiques pour appliquer ces concepts et consolider les compétences en conception de bases de données.
TD No 1 corrigé Modèle Conceptuel – Schéma Relationnel

Modélisation Merise : TD No 1 corrigé Modèle Conceptuel – Schéma Relationnel

Télécharger PDF

Modèle Conceptuel de Données et Schéma Relationnel

Le Modèle Conceptuel de Données (MCD) présenté ci-dessus est le modèle entité-association qui permet une représentation graphique du schéma d’une base de données (BD) : le diagramme entité-association (diagramme EA).

On y retrouve 3 types d’éléments :

  • Les rectangles composent les types d’entité (TE). Ils représentent un ensemble d’entités perçues comme similaires et ayant les mêmes caractéristiques. Chaque entité (E) représente un objet du monde réel, perçu comme ayant une existence propre, et à propos duquel on veut enregistrer des informations.

    Ex : Suppliers, Customers, Items, ...

  • Les losanges composent les types d’associations (TA). Ils représentent un ensemble d’associations ayant la même sémantique et décrites par les mêmes caractéristiques (liant des entités de mêmes types avec mêmes rôles et mêmes propriétés, respectifs). Chaque association (A) représente un lien entre plusieurs entités, où chaque entité joue un rôle déterminé. Si l’association lie des entités du même type, elle est dite cyclique ou réflexive et, dans ce cas, la spécification des rôles est indispensable.

    Ex : Includes, Carries, Supplies, ...

  • Les ellipses composent les listes d’attributs. Les attributs (Att) représentent les propriétés associées à un type d’entité ou à un type d’association, ou même participant à la composition d’un autre attribut. L’ensemble des attributs d’un TE (TA) représente l’ensemble des informations inhérentes que l’on souhaite conserver sur les entités ou associations.

    Ex : Salary, Balance, Quantity, ...

On appelle occurrence d’un TE (TA) toute entité (association) appartenant à l’ensemble décrit par le TE (TA). On appelle population d’un TE (TA) l’ensemble des occurrences du TE (TA).

La Figure 1 présente un Modèle Entité-Association pour la base de données YVCB (Yuppie Valley Culinary Boutique).

Les cardinalités d’un lien entre un TE E et un TA A sont définies par le couple (a,b) = card(E,A) où a est le nombre minimum et b le nombre maximum de fois qu’une occurrence du TE peut être concernée par le TA. Les possibilités pour a et b sont 0, 1 ou N (pour indéterminé). Les nombres a et b vérifient les propriétés suivantes :

  • Le couple de cardinalités (a,b) vérifie toujours la relation : a ≤ b.
  • La cardinalité maximum vérifie la relation : b ≥ 1.
  • Si a = 0, on parle de participation partielle du TE au TA (toute occurrence du TE peut exister indépendamment du TA).
  • Si a ≥ 1, on parle de participation totale du TE au TA (aucune occurrence du TE ne peut exister indépendamment du TA).
  • Si b = 1, toute occurrence du TE assume au plus une fois le rôle correspondant.
  • Si b = N, toute occurrence du TE peut assumer un nombre non limité de fois le rôle correspondant.

Exemple de l’association « depts – manages – managers » :

Pour déterminer la cardinalité entre « manages » et « depts », on se fixe un « manager » donné. Donc pour un directeur donné, combien de départements différents peut-il diriger ? Au minimum, il peut en diriger aucun, mais il ne peut pas diriger plus d’un. Par conséquent, on en déduit la cardinalité <0,1>.

De la même manière, on fixe un « dept ». Dans ce cas, on peut avoir aucun directeur qui le dirige, fixant ainsi la cardinalité minimale. On peut aussi avoir plusieurs directeurs pour un même département, d’où la cardinalité maximale indéfinie N. Par conséquent, la cardinalité entre « manages » et « managers » est <0,N>.

Les liaisons entre les entités, les associations et les attributs sont de deux sortes :

  1. Les traits continus expriment une contrainte de cardinalité normale.
  2. Les flèches expriment des cas particuliers de contrainte de cardinalité, correspondant au cas où toute occurrence du TE assume au plus une fois le rôle correspondant, soit le couple (0,1). Une flèche est toujours dirigée de l’association vers l’entité.

On classifie une association binaire A selon les cardinalités maximums des entités participantes E et F :

  • A est 1:1 si maxCard(E,A) = 1 et maxCard (F,A) = 1
  • A est 1:N si maxCard(E,A) = 1 et maxCard (F,A) = N (ou vice-versa)
  • A est N:N si maxCard(E,A) = N et maxCard (F,A) = N

Sur l’exemple précédent, l’association « manages » est une association binaire (car elle lie 2 entités « depts » et « managers »). La cardinalité maximale entre « depts » et « manages » est 1, et la cardinalité maximale entre « managers » et « manages » est N. On en déduit que l’association « manages » est une association binaire 1:N.

Exercice 2 : Application au Modèle Entité-Association Bancaire

Énoncé

Une personne peut ouvrir un ou plusieurs comptes à une agence bancaire. Elle doit donner son nom, son adresse, et éventuellement son numéro de téléphone. Chaque compte a une seule date d’ouverture, un numéro d’identification de compte, et un type (compte de chèques, compte épargne, etc.). Un compte a un seul titulaire. Chaque agence bancaire a un nom, un numéro d’agence, une adresse et un numéro de téléphone. Une opération est effectuée par une seule personne (le titulaire du compte ou un tiers) et concerne au plus deux comptes : le compte émetteur et le compte récepteur de l’opération. Une opération a un numéro d’identification, une date, un lieu, un type qui indique la nature de l’opération : retrait par carte bancaire, versement de salaire, encaissement ou paiement de chèque, virement de compte en compte, etc. Le solde d’un compte est établi à une date précise, au début de chaque mois. Si le solde est négatif, alors une lettre est adressée au titulaire du compte.

Questions

1. Liste des entités (avec leurs attributs)

  • Personne : Nom, Adresse, Numéro de téléphone (éventuel)
  • Compte : Type, Date d’ouverture, Numéro d’identification de compte
  • Agence : Nom, Numéro d’agence, Adresse, Numéro de téléphone
  • Opération : Numéro d’identification, Date, Lieu, Type

Liste des associations entre entités

  • Effectuer : Personne et Opération
  • Ouvrir : Titulaire, Compte et Agence
  • Concerner : Opération et Compte(s)
  • Appartenir : Compte et Personne
  • Lire le solde (solde, jour) : Titulaire et Compte

2. Définition des clés primaires pour chaque entité

  • Personne : Nom, Adresse, Numéro de téléphone
  • Compte : Numéro d’identification de compte
  • Agence : Numéro d’agence
  • Opération : Numéro d’identification

3. Liste de contraintes de données (de cardinalités)

  • Association « Effectuer » :
    • Une personne peut réaliser aucune ou plusieurs opérations : contrainte <0,N> entre « personne » et « effectuer ».
    • Une opération peut être concernée par une et une seule personne (titulaire ou non) : contrainte <1,1> entre « opération » et « effectuer ».
  • Association « Ouvrir » :
    • Un compte peut être ouvert par une seule personne et dans une agence donnée : contrainte <1,1> entre « compte » et « ouvrir ».
    • Une personne peut ouvrir un ou plusieurs comptes dans une ou plusieurs (si au moins 2 comptes) agences, mais aucune agence ne peut être associée à un compte si la personne n’est pas le titulaire du compte : contrainte <0,N> entre « personne » et « ouvrir ».
    • Une agence peut contenir plusieurs comptes d’une même personne ou de personnes différentes, et elle peut n’avoir aucun client (dans un tel cas, l’agence est inutile) : contrainte <0,N> entre « agence » et « ouvrir ».
  • Association « Concerner » :
    • Pour un compte émetteur, plusieurs opérations sont possibles, de même pour le compte récepteur : contrainte <0,N> entre « compte (émetteur) » et « concerner », contrainte <0,N> entre « compte (récepteur) » et « concerner ».
    • Pour une opération donnée, au plus deux comptes sont concernés, soit au maximum un compte émetteur et un compte récepteur. Au minimum, on aura un compte associé à cette opération : contrainte <1,1> entre « opération » et « concerner ».
  • Association « Lire le solde » :
    • Pour un compte donné, on a une et une seule personne titulaire de ce compte : contrainte <1,1> entre « compte » et « lire le solde ».
    • Pour une personne donnée, on peut avoir aucun ou plusieurs comptes concernés par la lecture du solde et l’envoi d’un courrier pour solde négatif : contrainte <0,N> entre « personne » et « lire le solde ».
  • Association « Appartenir » :
    • Pour un compte donné, on a une et une seule personne titulaire de ce compte : contrainte <1,1> entre « compte » et « appartenir ».
    • Pour une personne donnée, on peut avoir aucun ou plusieurs comptes : contrainte <0,N> entre « personne » et « appartenir ».

Liste de contraintes de données (fonctionnelles)

Les contraintes fonctionnelles sont les suivantes :

  • Pour un bon fonctionnement, c'est-à-dire pour que chaque mois, le solde de tous les comptes soit effectué, il faut que le jour soit compris entre 1 et 28 (au-dessus, on risque de ne pas contrôler le solde tous les mois).
  • Associations et contraintes fonctionnelles :
    • Appartenir : Compte -> Personne
    • Ouvrir : Compte -> (Personne, Agence)
    • Effectuer : Opération -> Personne
    • Concerner : Opération -> (Compte émetteur, Compte récepteur)
    • Lire le solde : Compte -> Personne

4. Graphe du modèle conceptuel de données

Le graphe du modèle conceptuel de données n'est pas inclus ici.

5. Schéma de base de données relationnelle de cette gestion

Pour passer du schéma Entité-Association au schéma de base de données relationnelle, il faut respecter les 5 règles suivantes :

Règle 1 : Type d’entité

  • Pour chaque TE E, créer une relation R ;
  • Inclure dans R tous les attributs simples de E ;
  • Inclure dans R les composants simples des attributs composés de E ;
  • Un identifiant de E devient clé primaire de R ;
  • La notion d’attribut composé est perdue dans le modèle relationnel ;
  • Les relations telles que R sont appelées relations d’entité.

Règle 2 : Association binaire 1:1

  • A : association binaire 1:1 entre TE E1 et E2 ;
  • R1, R2 : relations obtenues à partir de E1 et E2 ;
  • Choisir R1 ou R2 pour représenter l’association A (préférer R1 si E1 est total dans A) ;
  • Inclure comme clé étrangère dans la relation choisie R1, la clé primaire de R2 ;
  • Inclure dans R1 les attributs simples et composants simples d’attributs de A ;
  • A peut aussi être représenté par une relation (comme par la règle 5).

Règle 3 : Association binaire 1:N

  • A : association binaire 1:N entre TE E1 (cardinalité Max = 1) et E2 (cardinalité Max = N) ;
  • R1, R2 : relations obtenues à partir de E1 et E2 ;
  • Inclure comme clé étrangère dans R1 la clé primaire de R2 ;
  • Inclure dans R1 les attributs simples et composants simples d’attributs de A ;
  • Si la cardinalité de E1 est (1,1), la clé étrangère ne peut recevoir la valeur NULL.

Règle 4 : Association binaire N:N

  • R1, R2 : relations obtenues à partir des TE E1 et E2 de l’association A ;
  • Représenter A comme une relation R, de clés étrangères les clés primaires de R1 et R2 ;
  • La clé primaire de R est composée de ces deux clés étrangères ; Inclure dans R les attributs simples et composants simples d’attributs de A ;
  • Peut être appliquée aux associations 1:1 et 1:N ;
  • Les relations telles que R sont appelées relations d’association.

Règle 5 : Association n-aire (n>2)

  • Créer une relation R représentant l’association n-aire A ;
  • Inclure dans R les attributs simples et composants simples d’attributs de A ;
  • Inclure comme clés étrangères dans R les clés primaires des relations représentant les TE de A ;
  • La clé primaire de R est composée de ces clés étrangères, excepté si un TE de A est de cardinalité maximum 1 dans A, auquel cas la clé primaire de R est celle de la relation représentant ce TE.

Entités en relations :

  • Opération ( ID_O , Type_O , Date_O , Lieu , #Nom_P , #Adr_P , #Tel_P )
  • Compte ( ID_C , Type_C , Date_C , Solde , #Nom_P , #Adr_P , #Tel_P )
  • Personne ( Nom_P , Adr_P , Tél_P )
  • Agence ( ID_A , Nom_A , Adr_A , Tél_A )

Associations en relations :

  • Concerner ( #ID_O, #ID_C1, #ID_C2 )
  • Ouvrir ( #ID_C , #ID_A , #Nom_P, #Adr_P )
  • Lire_Solde ( Solde , Jour , #ID_C , #Nom_P, #Adr_P , #Tel_P )

6. Clés de chaque relation

Une clé est un ensemble minimal d’attributs ayant la propriété d’identification unique de tuple. Un tuple est un ensemble de couples <attributs, valeurs>.

On parle de clés candidates lorsque l’on a plusieurs clés, sinon on parle de clé unique.

Une clé primaire est une clé privilégiée choisie parmi les clés candidates.

La clé d’une relation R1 est dite étrangère si elle correspond à la clé primaire d’une seconde relation R2 (R2 pouvant être identique à R1).

Dans les schémas de relations de la question 5, les clés primaires sont soulignées et les clés étrangères sont précédées d’un #.

Exercice 3 : Cas Pratique - Gestion de Pharmacie

Énoncé

On s’intéresse à la vente de produits dans une pharmacie. Un produit est caractérisé par un nom de produit, une classe pharmaceutique, un nom de fabricant, un numéro de lot, une date d’expiration, et un type de remboursement (attribué par la sécurité sociale). Chaque produit est déterminé par son nom et son numéro de lot. Un produit peut être remboursable ou non-remboursable. Dans le premier cas, le pourcentage du remboursement dépend de la classe pharmaceutique du produit. Le prix d’un produit n’est pas fixé, il est varié selon les périodes (promotions, augmentation de prix des fabricants, etc.).

L’achat d’un produit remboursable nécessite une ordonnance d’un médecin. Un médecin est caractérisé par un nom, une adresse, un numéro d’agrément et une spécialité.

Sur une ordonnance, on voit les informations concernant le médecin et le patient, la date de consultation, et une liste de médicaments avec les prescriptions de traitement. La pharmacie garde une copie de chaque ordonnance à laquelle elle attribue un numéro unique. D’après la liste de produits sur l’ordonnance, une préparatrice (ou un préparateur) de la pharmacie cherche les produits et établit une facture. Chaque facture a une date, un numéro d’identification et une liste de produits avec leur quantité. Si une facture a des produits remboursables, alors on distingue la somme à payer par le patient (le client) lui-même, la somme à rembourser par la sécurité sociale et la somme à rembourser par la mutuelle.

Un client est caractérisé par un nom, une adresse, un numéro de téléphone. S’il bénéficie de la sécurité sociale, alors il en a un numéro d’identification, un numéro du centre de gestion de remboursements de la sécurité sociale. Un client peut avoir au plus une seule mutuelle. Chaque mutuelle a un nom, une adresse du centre local de gestion de remboursements, dépendant de patients. Il est de même pour les centres de gestion de remboursements de la sécurité sociale.

Foire Aux Questions (FAQ) sur la Modélisation des Données

Qu'est-ce qu'un Modèle Conceptuel de Données (MCD) ?

Un Modèle Conceptuel de Données (MCD) est une représentation graphique et structurée des données d'un système d'information. Il utilise des entités, des associations et des attributs pour décrire les objets du monde réel et les liens entre eux, indépendamment de toute contrainte technique de stockage.

Quelle est la différence entre une clé primaire et une clé étrangère ?

Une clé primaire est un attribut ou un ensemble d'attributs qui identifie de manière unique chaque enregistrement (ou tuple) dans une table de base de données. Une clé étrangère est un attribut (ou un ensemble d'attributs) dans une table qui fait référence à la clé primaire d'une autre table, établissant ainsi un lien entre les deux tables et garantissant l'intégrité référentielle des données.

Comment les cardinalités influencent-elles la conception d'une base de données relationnelle ?

Les cardinalités (<min, max>) définissent le nombre minimum et maximum de fois qu'une occurrence d'une entité peut participer à une association. Elles sont cruciales pour la transformation du MCD en schéma relationnel, car elles déterminent la manière dont les relations seront créées et comment les clés primaires et étrangères seront positionnées pour représenter fidèlement les liens entre les entités.

Cela peut vous intéresser :

Partagez vos remarques, questions , propositions d'amélioration ou d'autres cours à ajouter dans notre site

Enregistrer un commentaire (0)
Plus récente Plus ancienne