Formation Merise


Télécharger



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Formation sur les principaux savoir-faire de Merise

...

1.2 Définition de l'information et des systèmes d'information

   Une information est un élément qui permet de compléter notre connaissance sur une personne, un objet, un événement …  .

Exemple: Le nom d'une personne est une information concernant cette personne.

 La couleur d'une voiture est une information concernant cette voiture.

 La d

ate de la fête scolaire est une information concernant cet événement.

   Un système d'information est constitué par l'ensemble des informations relatives à un domaine bien défini.

Exemple: Toutes les informations relatives à la gestion d'une librairie constituent le système d'information de cette librairie. Ce système peut couvrir le simple stockage des livres, mais également la gestion des commandes, des ventes et même des clients.

Un système d'information ne doit pas nécessairement être informatisé. Bien que la plupart des systèmes actuels se basent sur la technologie de l'informatique,  il existe encore des systèmes d'information où l'information est stockée, manipulée et communiquée à l'aide de moyens "traditionnels" tels que armoires, classeurs, calculatrices, fiches sur papier etc. .

   Un système d'information existe indépendamment des techniques informatiques.

Le système d'information ne doit pas être confondu avec le système informatique qui est constitué par les éléments suivants:

  • Les ordinateurs
  • Les programmes
  • Les structures de données (Fichiers, Bases de données)

Dans ce chapitre nous allons découvrir une démarche d'informatisation, qui nous permet de modéliser un système d'information et de le représenter à l'aide d'un système informatique. Le but de cette démarche est de concevoir des systèmes stables et optimisés en termes de performance, de fiabilité et de convivialité.

1.3 Les données, les traitements et les informations

Bien que les deux termes "informations" et "données" soient souvent utilisés comme synonymes , il existe une différence subtile entre eux.

Prenons un exemple:

Dans  une librairie, un client demande au vendeur si le livre "L'étranger"  (Albert Camus) est disponible en stock. Le vendeur conseille la base de données de la librairie à l'aide de son ordinateur et confirme au client que le livre est disponible. Le vendeur a donc donné au client l'information que le livre est en stock. Afin de pouvoir donner cette information, le vendeur a du consulter les données qui représentent le stock de la librairie. Le fait de consulter le stock constitue un traitement sur les données du stock.

Nous pouvons généraliser:

Un système d'information contient les données et les traitements nécessaires pour assimiler et stocker les informations entrantes et produire les informations sortantes.

Dans les systèmes d'information nous retrouvons généralement les traitements suivants:

  • Consultation des données;
  • Ajout de données;
  • Suppression de données;
  • Modification de données.

Exemple:

Le propriétaire d'une vidéothèque reçoit une livraison avec des nouvelles cassettes vidéo. Pour chaque cassette vidéo, il lit le titre, la langue et la durée et sauvegarde ces informations dans la base de données de la vidéothèque. Il a donc utilisé un traitement d'ajout de données afin de transformer les informations entrantes (titre, langue, durée) en données.

1.4 La représentation informatique des données

Les données d'un système d'information peuvent être stockées et manipulées à l'aide d'un outil informatique spécialisé dans ce domaine. Actuellement les Systèmes de Gestion de Bases de Données (SGBD) constituent le type de logiciel le mieux adapté pour implémenter la plupart des systèmes d'information. Sachant que les tables forment la base de stockage d'une base de données, on peut représenter n'importe quel système d'information par un ensemble de tables dont chacune contient un certain nombre de champs de données. Nous allons voir qu'on peut même définir des liens entre ces tables via des champs communs.

  1. Démarche de modélisation des données

2.1 Le groupe d'étude (angl. Project group)

Un système d'information qui n'est pas trop complexe et volumineux en terme d'informations, peut facilement être informatisé par une seule personne, qui ne doit pas nécessairement être un informaticien. Il suffit d'être un peu familiarisé avec une méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentation informatique, cohérente et fonctionnelle, d'un tel système d'information.

Dès que le système d'information atteint une certaine envergure (par exemple: informatiser la gestion des sinistres d'une compagnie d'assurances), un groupe d'étude est généralement créé.

Ce groupe ne devra en aucun cas contenir seulement des informaticiens mais également:

  • Un ou plusieurs représentants des futurs utilisateurs du système informatisé

 (Par exemple: Un employé du service qui gère les sinistres) ;

  • Un ou plusieurs représentants de chaque département impliqué

 (Par exemple: Un employé du service des contrats ) ;

  • Un représentant de la direction.

Généralement, un responsable du groupe (angl. Project Manager) est nommé, afin de coordonner les travaux effectués par le groupe et de suivre le déroulement à partir de l'analyse jusqu'à la mise en place du système informatisé.

2.2 Les étapes

Chaque projet d'informatisation, qu'il soit exécuté par une seule personne, ou géré par un groupe d'étude,  prévoit plusieurs étapes.

En général, nous avons les étapes suivantes:

  1. Analyse de la situation existante et des besoins
  2. Création d'une série de modèles qui permettent de représenter tous les aspects importants
  3. A partir des modèles, implémentation d'une base de données

2.3 Sources d'information

La première étape de chaque projet est donc l'analyse de l'existant et des besoins. Afin de pouvoir réaliser une analyse correcte sur laquelle on peut baser la suite du projet, il faut d'abord identifier les sources d'information, et puis collectionner exactement les informations importantes pour le projet.

Sources d'information primaires:

  • L'interview avec les utilisateurs;
  • L'étude de documents provenant du système d'information actuel (Rapports, Bons de commandes, Factures …).

Pour les projets d'une certaine envergure s'ajoutent:

  • L'interview avec les responsables des services impliqués;
  • Pourvu que la tâche d'analyse soit partagée entre plusieurs membres du groupe d'études, il faut coordonner les actions et comparer les résultats avec les autres membres.

Pour les projets qui se basent sur un système déjà partiellement informatisé s'ajoute:

  • L'étude de l'application informatique existante.
  1. Méthode de modélisation des données

3.1 Définition

Nous avons vu que la démarche classique d'un projet informatique comprend les étapes suivantes:

  1. Analyse de la situation existante et des besoins;
  2. Création d'une série de modèles, qui permettent de représenter tous les aspects importants;
  3. A partir des modèles, implémentation d'une base de données.

En ce qui concerne la première étape, nous n'allons pas introduire de vraies règles, mais simplement utiliser nos connaissances de gestion d'une entreprise, notre esprit ouvert et même notre fantaisie pour analyser correctement la situation existante et les besoins des utilisateurs. Le résultat de l'analyse est généralement un ou plusieurs documents, qui contiennent les indications principales sur le fonctionnement désiré du système informatisé. Le document d'analyse contient souvent déjà des prototypes de certains documents importants, que le futur système devra être capable de produire.

Une fois que l'analyse est terminée, il s'agit d'élaborer une série de modèles, basés sur le document d'analyse. Ces modèles nous permettront plus tard d'implémenter une base de données, qui contiendra toutes les informations nécessaires au bon fonctionnement du système informatisé.

La création de ces modèles se fait selon une certaine méthode. Nous allons baser notre cours sur la méthode MERISE (Méthode d'Etude et de Réalisation Informatique de Systèmes d'Entreprise), qui a été développée pendant les années '70 sous l'impulsion du ministère français de l'industrie. Merise est aujourd'hui largement répandue au Luxembourg, mais également dans beaucoup d'autres pays européens.

MERISE prévoit une conception par niveaux, et définit pour cela 3 niveaux essentiels:

  1. Le niveau conceptuel, qui se base directement sur l'analyse, décrit l'ensemble des données du système d'information, sans tenir compte de l'implémentation informatique de ces données. Ce niveau, qui représente donc la signification des données, se traduit par un formalisme que nous appelons:

Modèle conceptuel des données  (MCD)

  1. Le niveau logique, qui se base sur le modèle conceptuel des données, prend en considération l'implémentation du système d'information par un SGBD. Ce niveau introduit la notion des tables logiques, et constitue donc le premier pas vers les tables des SGBD. Ce niveau est représenté par le:

      Modèle logique des données  (MLD)

  1. Le niveau physique, qui se base sur le modèle logique des données, contient finalement les tables définies à l’aide d’un SGBD spécifique (p.ex. MS Access, dBASE, Oracle …). Ce niveau est représenté par le:

      Modèle physique des données  (MPD)

Voici donc les 4 étapes nécessaires pour traduire un système d'information naturel en une base de données:

3.2 Pourquoi modéliser ?

Nous avons vu qu’une base de données est constituée par un ensemble de tables qui contiennent toutes les données de la base. Une méthode de modélisation nous permet de trouver le bon nombre de tables pour une base de données et de déterminer quelles données sont représentées à l’intérieur de quelle table.

Pour l’instant, il nous suffit de savoir qu’une table est un ensemble d’enregistrements, dont chacun est composé par les mêmes champs de données. On pourrait comparer une table à une liste en MS-Excel . Les tables sont étudiées en détail dans le chapitre 6.

Voici un exemple d’une table :

Marque Modèle Cylindrée Poids

BMW

525i 2500 1360

Ford

Orion 1800 1080

BMW 320i 2000 1200

... ... ... ...

A l’aide d’un exemple précis, nous allons voir pourquoi il est important de bien réfléchir sur le nombre de tables d’une base de données et sur la structure de chaque table.

Il s’agit de créer une base de données pour une caisse de maladie. On veut stocker tous les employés-membres de la caisse avec leur société-employeur. Afin de faciliter l’exercice, nous allons uniquement stocker les informations suivantes pour chaque employé:

  • le numéro de l’employé
  • le nom de l’employé
  • le prénom de l’employé
  • le numéro de son entreprise
  • le nom de son entreprise
  • la localité où se trouve l’entreprise

A première vue, la solution suivante s’impose :

NoEmp Nom_Emp Prénom_Emp NoEntr Nom_Entr Localité

102 Boesch Emil 1 Schaffgaer S.à r.l. Differdange

103 Midd Erny 2 Gudjär Colmar Berg

104 Witz Evelyne 1 Schaffgaer S.à r.l. Differdange

105 Kuhl Menn 1 Schaffgaer S.à r.l. Differdange

106 Super Jhemp 2 Gudjär Colmar Berg

... ... ... ... ... ...

Nous voyons ici uniquement quelques enregistrements. Une caisse de maladie ayant des miliers de membres, et cette table possédant un enregistrement par membre, on peut bien s’imaginer la taille réelle de la table.

Hors cette solution, bien qu’elle soit correcte dans le sens le plus large du terme, nous impose un certain nombre de problèmes .

Exercice 1

Essayez de trouver en discussion quelques problèmes qui peuvent se manifester lors du travail journalier avec cette table.

Exercice 2

Comment est-ce qu’on pourrait éviter ces problèmes sans toutefois perdre des informations ?

3.3 Le modèle conceptuel des données (MCD)

3.3.1 Définition

En se basant sur un document d'analyse, le modèle conceptuel des données (MCD) fait référence à tous les objets du système d'information et à des relations entre ces objets. Le formalisme utilisé dans ce modèle est encore connu sous le nom de "Schéma Entité-Relation". Ce formalisme se base autour de 3 concepts principaux, les entités, les relations et les propriétés.

Voici par exemple un MCD qui représente une entreprise avec ses employés.

Nous allons par la suite détailler le rôle de ces 3 concepts de base du MCD.

3.3.2 La notion d'entité

   Une entité permet de modéliser un ensemble d'objets concrets ou abstraits de même nature.

Dans l'exemple du chapitre précédent , l'entité Entreprise spécifie donc l'ensemble des entreprises, qui nous intéressent dans le contexte de notre système d'information. De même, l'entité Employés représente tous les employés de notre système d'information.

Une entité est caractérisée par son nom et ses propriétés.

 Représentation graphique:

Prenons par exemple une entité Client:

Voici quelques exemples de clients:

   Chacun de ces clients représente une occurrence de l'entité Client.

3.3.3 La notion de propriété

    Une propriété est une donnée élémentaire d'une entité.

Une propriété est unique dans un MCD; et ne peut pas être rattachée à  plusieurs entités différentes. 

 Représentation graphique d'une propriété:

 Le nom de la propriété est indiqué à l'intérieur du rectangle qui représente l'entité correspondante.

Voici quelques exemples de propriétés:

Pour une entité Client:

  • Nom du client
  • No.Tél. du client

Pour une entité Salarié:

  • Nom du salarié
  • No. Matricule
  • Salaire mensuel

Pour une entité Contrat d'assurance:

  • No Contrat
  • Type d'assurance
  • Montant assuré

    A l'intérieur des occurrences, les propriétés prennent des valeurs

Exemple:

L'entité Client  est définie par les propriétés suivantes:

A l'intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart des cas une valeur numérique, une valeur sous forme de texte ou encore une date.

La propriété Nom prend p.ex. les valeurs "Meier", "Muller" et "Weber" dans les 3 occurrences.

  A l’intérieur de chaque occurrence, chaque propriété ne prend qu’une seule valeur au maximum.

Le client 002 par exemple ne peut pas avoir 2 adresses.

3.3.4 La notion d'identifiant

  Afin de pouvoir distinguer les différentes occurrences d'une même entité, l'entité doit être dotée d'un identifiant. L'identifiant est composé d'une ou de plusieurs propriétés de l'entité. Chaque occurrence d’une entité doit avoir une valeur différente pour l’identifiant Le choix d'un identifiant correcte est très important pour la modélisation:

Comme choix pour l'identifiant d'une entité nous distinguons généralement 3 possibilités:

  1. Une propriété naturelle

 Exemple: Le nom d'un pays pour une entité Pays

  1. Une propriété artificielle qui est inventée par le créateur du MCD

 Exemple: Le numéro d'un client pour une entité Client

  1. Une propriété composée d'autres propriétés naturelles

Exemple: Le nom et la localité pour une entité Entreprise

   Représentation graphique de l'identifiant d'une entité:

La ou les propriétés qui constituent l'identifiant d'une entité sont soulignées.

  Exercice

Indiquez graphiquement les entités qui représentent :

  1. les passagers d’un vol d’une société aérienne. Nous supposons que la société garde ces informations après le vol ;
  2. les résultats sportifs de l’entrainement d’un coureur ;
  3. les médicaments d’une pharmacie.

3.3.5 La notion de relation

3.3.5.1 Définition

   Une relation  décrit un lien entre deux ou plusieurs entités.

Chaque relation possède un nom, généralement un verbe à l'infinitif.

Bien qu'une relation n'ait pas d'identifiant propre, elle est implicitement identifiée par les identifiants des entités auxquelles elle est liée.

  Nous distinguons deux types de relations:

  • les relations binaires, qui sont liées à 2 entités;
  • les relations ternaires, qui sont liées à 3 entités.

Exemple d'une relation binaire:

L'occurrence d'une relation est représentée par les occurrences des entités liées à la relation. Voici quelques occurrences de la relation Ecrire.

Une occurrence d’une relation est uniquement déterminée par les occurrences des entités liées à la relation.

  Pour chaque occurrence d’une relation, l’identifiant composé des identifiants des entités liées à la relation doit être unique.

3.3.5.2 Les cardinalités d'une relation

  Une relation est liée à chacune de ses entités par une patte. Sur la patte, on indique les cardinalités.

Les cardinalités précisent la participation de l'entité concernée à la relation. Le premier nombre indique la cardinalité minimale, le deuxième la cardinalité maximale.

Quelle est la signification des cardinalités ?

Exemple 1:

Dans le MCD précédent, entre l'entité Client et la relation Passer, nous avons les cardinalités suivantes:

  • Cardinalité minimale = 1 , ce qui veut dire que chaque client passe au moins une commande.
  • Cardinalité maximale = n , ce qui veut dire que chaque client peut passer plusieurs (n) commandes.

Entre l'entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes:

  • Cardinalité minimale = 1 , donc chaque commande est passée par au moins un client.
  • Cardinalité maximale =1 , chaque commande est passée au maximum par un seul client.

Exemple 2:

Entre l'entité Employé et la relation Utiliser, nous avons:

  • Cardinalité minimale = 0 :

 Certains employés n'utilisent pas d'ordinateur

  • Cardinalité maximale = n:

Entre l'entité Ordinateur et la relation Utiliser, nous avons:

  • Cardinalité minimale = 1 :
  • Cardinalité maximale = n :

   De façon générale, on peut dire:

La cardinalité minimale exprime le nombre minimum de fois q’une occurrence d'une entité participe à une relation. Cette cardinalité est généralement 0 ou 1.

  • Cardinalité minimale = 0 : Certaines occurrences de l'entité ne participent pas à la relation
  • Cardinalité minimale = 1 : Chaque occurrence de l'entité participe au moins une fois à la relation

La cardinalité maximale exprime le nombre maximum de fois q’une occurrence d'une entité participe à une relation. Cette cardinalité vaut souvent 1 ou n, avec n indiquant une valeur >1 mais pas connue à priori.

  • Cardinalité maximale = 1 : Chaque occurrence de l'entité participe au maximum une seule fois à la relation.
  • Cardinalité maximale = n : Chaque occurrence de l'entité peut participer plusieurs fois à la relation.

En pratique, afin de déterminer les bonnes cardinalités, le concepteur doit se référer aux résultats de l'analyse.

Exemple 3:

Pour les deux cas suivants, on peut affirmer qu'une commande est toujours passée par au moins un client. Une commande est également passée au maximum par un client. Une commande est donc toujours passée par un et un seul client.

Un client passe au moins une commande et au maximum plusieurs (n) commandes.

Cette modélisation ne tient pas compte des clients qui ne passent aucune commande. Un client est uniquement considéré comme tel s'il passe au moins une commande.

Un client peut passer aucune commande et au maximum plusieurs (n) commandes.

Cette modélisation tient compte des clients qui ne passent aucune commande.

Laquelle des deux modélisations est correcte ?

Les deux modélisations sont bien sûr correctes. Le choix dépend uniquement du résultat de l'analyse. Imaginez que vous avez fait pendant l'analyse une interview avec un futur utilisateur du système. Il vous a dit qu'il veut enregistrer dans son système des clients potentiels, c.à.d. des personnes dont la compagnie dispose des données personnelles, mais qui n'ont encore jamais passé de commande auprès de la compagnie. La compagnie désire enregistrer les données de ces personnes afin de leur envoyer de temps en temps des publicités. Dans ce cas vous devez opter pour la deuxième modélisation.

Exemple 4:

Interprétez cette modélisation :

On dit que Client est l'entité indépendante par rapport à la relation disposer (cardinalité minimale = 0) , tandis que Carte_membre est l'entité dépendante par rapport à la relation disposer (cardinalité minimale = 1).

Une occurrence d'un client peut donc très bien exister sans carte de membre, mais une carte de membre ne peut jamais exister sans client. La cardinalité minimale nous indique donc si une entité est indépendante ou dépendante.

   On dit qu'une entité est indépendante par rapport à une relation lorsque sa cardinalité minimale vaut 0, et dépendante par rapport à une relation lorsque sa cardinalité minimale vaut 1.

   Une relation ne peut pas être liée uniquement à des entités dépendantes ayant en plus une cardinalité maximale de 1   ! ! !

La modélisation suivante par exemple n'est pas correcte:

Dans ce cas, il faut réunir les propriétés des deux entités dans une seule.

3.3.5.3 Propriétés d'une relation

Une relation peut généralement être dotée de propriétés.

Exemple:

  Exercice

Pourquoi est-ce qu’on ne peut pas associer la propriété Année à une des entités ?

Attention:  Cette propriété peut même devenir une partie de l'identifiant. Dans ce cas, elle doit être soulignée.

Exemple:

Comme un professeur peut avoir la même classe pendant plusieurs années (p.ex. Jos Weber  12CG2), un identifiant composé de No_Matricule et Code_Classe n'est pas suffisant, puisqu’il ne garantit pas l’unicité. On y ajoute l'Année.

   Attention:  Une relation à cardinalité (1,1) n'est jamais porteuse de propriétés. Dans ce cas, les propriétés migrent dans l'entité portant cette cardinalité (1,1).

Exemple:

Cette modélisation n'est pas correcte !  Chaque facture ne possède qu'une et une seule date d'émission, ce qui fait que la propriété Date_émission doit migrer dans l'entité Facture.

Voici la modélisation correcte:

3.3.6 Exemple "KaafKaaf"

PARTIE 1

La société "KaafKaaf" désire informatiser son système de facturation. Les factures devraient se présenter de la façon suivante:

Créez un MCD, qui permet de modéliser correctement le système d'information nécessaire, sachant que:

  • Un client peut bien sûr recevoir plusieurs factures, mais il est uniquement considéré comme tel à partir du moment où il reçoit sa première facture.
  • Une facture concerne un et un seul client.

Remarque:

Bien que le numéro du client n'apparaisse pas en tant que tel sur la facture, il est préférable d'ajouter cette propriété artificielle à l'entité Client, et de la définir comme identifiant de cette entité. Cela nous empêche de devoir définir un identifiant composé de trop de propriétés.

PARTIE 2

Il s'agit d'étendre le MCD de la partie 1.

Le responsable de la facturation de la société désire rendre les factures plus informatives. Comme un client peut acheter plusieurs articles différents en même temps, la facture devrait indiquer pour chaque article le numéro , un libellé, le prix unitaire, la quantité vendue et le prix total pour ce type d'article.

Voici l'aspect que la facture devrait avoir:

Proposez un nouveau MCD qui reflète ces modifications, en respectant que:

  • Tous les articles disponibles sont stockés (p.ex. No=234 Libellé="Marteau" PU=470 Luf.). Même si un article n'est pas encore considéré par une facture, il existe dans le système d'information.

Remarques:

  • L'entité Facture ne contient plus la propriété Montant. Il existe une règle générale de conception qui dit:

    Aucune propriété qui peut être calculée à partir d'autres propriétés existantes, ne devra être stockée dans le MCD.

Pour la même raison, on n'a pas besoin de modéliser explicitement le prix à payer pour l'achat d'une quantité d'articles donnés. Le prix pour chaque article figurant sur la facture peut être calculé à partir du prix unitaire et de la quantité

  • Nous retrouvons ici le cas d'une relation qui a une propriété. En fait, la propriété Quantité n'est pas spécifique à un article, mais à l'achat de cet article à l'aide d'une facture. Cette façon de modéliser la situation est la plus facile, mais il existe une alternative. On peut introduire l'entité abstraite Ligne_de_facture, qui représente une ligne de détail d'une facture, p.ex celle pour le marteau.

3.3.7 Exemple  "Gestion d'école"

PARTIE 1

Dans une école, on veut informatiser le système d'information qui gère les classes.

Elaborez un MCD sachant que:

  • Un élève est caractérisé par son no. matricule, son nom et prénom, ainsi que sa date de naissance.
  • Une classe est caractérisée par le nom de la classe (p.ex 13CG2) et par une indication du cycle (valeurs possibles: "inférieur", "moyen", "supérieur").
  • Il faudra prévoir de connaître la fréquentation des classes des élèves sur plusieurs années consécutives.
  • Un élève enregistré dans le système fréquente au moins une classe au cours des années.

PARTIE 2

Il s'agit maintenant de concevoir une extension au MCD précédent qui permet de représenter la situation suivante:

  • La direction de l'école désire également saisir tous les professeurs dans le système d'information. Un professeur est caractérisé par un code interne unique (p.ex. Jemp Muller aura le code JEMU), son nom et prénom et la matière qu'il enseigne. Nous supposons que chaque professeur enseigne une seule matière.
  • Modélisez le fait que chaque classe est enseignée chaque année par un ou plusieurs enseignants. Un enseignant peut bien sûr donner des cours dans plusieurs classes, mais peut également ne pas donner des cours pendant une ou plusieurs années.

3.3.8 L’utilisation d’une relation ternaire

Lors de l’introduction des relations nous avons déjà mentionné la notion de relation ternaire. Une relation ternaire est une relation à laquelle sont liée 3 entités.

Bien que dans la pratique la plupart des relations soient binaires (2 entités) il existe cependant des situations où l’utilisation d’une relation ternaire s’impose.

Exemple :

A partir des 3 entités Professeur (CodeProf, Nom, Prénom); Matière(CodeMatière, Libellé) et Classe(Nom,Cycle) il s’agit de créer un MCD qui renseigne sur le fait quelle matière est enseignée dans quelle classe par quel professeur pour une année scolaire donnée.

  Exercice

Essayez de montrer les limites/défauts d’un MCD qui représente l’énoncé de l’exemple précédent en utilisant uniquement des relations binaires.

Solution de l’exemple précédent :

Voici une solution qui utilise une relation ternaire

Il existe 3 façons pour lire/interpréter ce modèle:

  • Un professeur  peut enseigner 1 à n fois  une matière dans une classe.
  • Une matière peut être enseignée 1 à n fois par un professeur dans une classe.
  • Une classe  peut être enseignée 1 à n fois dans une matière par un professeur.

On peut dire que chaque occurrence de la relation enseigner associe un professeur à une matière et une classe pour une année donnée. Ou encore, ce modèle nous permet de montrer pour chaque année scolaire quelle matière est enseignée dans quelle classe par quel professseur.

Il n’est pas toujours facile de déterminer quand il faut utiliser une relation ternaire. Généralement, on peut déjà affirmer que si une ou plusieurs des entités liées à une relation ternaire possèdent une cardinalité maximale de 1, la modélisation n’est pas optimisée dans le sens qu’il faudrait mieux décomposer la relation ternaire, c.à.d. la représenter par 2 relations binaires.

Exemple :

La direction d’une chaîne d’hôtels désire gérer les séjours des clients dans les différents hôtels. Comme on peut effectivement dire "Un client effectue un séjour dans un hôtel" on est ammené à proposer la modélisation suivante.


58