Création MCD de cocktails à partir d'un énoncé

Bonjour tout le monde,

J'ai un exercice qui demande de transformer le Dictionnaire des données en MCD.

Le but de ce message est de voir comment je peux faire pour créer le MCD de cette exercice, sela sera alors beaucoup plus facile pour moi de comprendre.

Ceci n'est pas du tout un exercice coté ou un exercice à faire comme devoir.

Voici l'énoncé :

Création de cocktails :

Les données :

- Nom du cocktail (Daiquiri, Bloody Mary...)
- Nom de l'ingrédient entrant dans la composition (Rhum, citron, sucre, etc..)
- Numéro de la variante du cocktail (variante 1, variante 2, variante 3)
- La quantité de l'ingrédient dans le cocktail d'une telle variante
- L'untié de mesure de la quantité de l'ingrédient dans le cocktail (gramme, centilitre, cuillère,ect...)

Les règles de gestion sont :

RG1: le nom du cocktail est toujours sans ambiguïté possible pour le connaisseur.
RG2: Dans une variante d'un cocktail, les quantités d'ingrédients peuvent changer, voir les ingrédients eux-mêmes.

On doit pouvoir répondre facilement aux questions suivantes :

- Dans un tel cocktail, quelles sont les variantes ?
- Qu'y a-t'il dans chaque variante du cocktail ?
- Dans quel cocktail utilise-t-on un ingrédient déterminé ?

Je vous avoue, c'est du chinois pour l'instant, bon je commence à connaître le vocabulaire (entité, propriétés,....) mais je ne vois pas du tout comment résoudre ce MCD.

Je vous remercie sincèrement pour votre aide.

beegees

Est ce qu'on pas avoir une même variante dans diffrénets cocktail ?

Ce n'est pas précisez dans le sujet donc à mon avis c'est à ton bon vouloir :lol:

Oki je propose le MCD ci-joint :
http://www.developpez.net/forums/att...1&d=1161867245

Bonjour bujuman et Tazmania,

Merc beaucoup pour ce MCD.

Première question :

Avec quel programme as-tu fait ce MCD ?

Deuxième question :

Que veux dire Association_1 ?

Troisième question :

Nous avons un MCD à 5 pattes ?

Quatrième question :

Entre ingrédient et quantification, je vois 1,1, cela veut donc dire qu'un ingrédient ne peut avoir qu'une quantification ?

Cinquième question :

N'as t'on à faire à aucun CIF ?

Merci sincèrement pour votre aide.

beegees

Houla tant de question !!

Bon j'ai regardé vite fait le MCD de Bujuman, il me semble correct mais je ne me suis pas attardé plus que sa donc je vais reprendre le modèle de Bujuman pour répondre à certaines de tes questions.


1- Je sais pas (WinDesign, PowerAMC) - A voir directement ave Bujuman

2- Il s'agit d'une association ternaire, ici Bujuman ne lui a pas donné de nom mais tu aurais très bien pu mettre possède.
Cette association relie donc trois entités.
Pour la lire correctement, tu pars d'une entité vers les deux autres.
Exemple : Un cocktail possède un ou plusieurs ingrédient et possède une ou plusieurs variantes.

3- Je ne connais pas cette expression (5 pattes). Je voudrais pas dire une connerie mais je pense que cela doit correspondre au nombre d'association.

4- Le 1,1 entre ingrédient et quantification comme je l'ai expliqué ci dessus, signifie qu'un ingrédient est quantifier par une et une seule unité de mesure.

5- Il existe ici une CIF ou contrainte d'intégrité fonctionnelle, elle se situe entre la table Ingrédient et Unité. Celle-ci va te contraindre à créer et remplir ta table Unité avant de créer et remplir la table Ingrédient.
En effet, sur ce modèle, un ingrédient est associé à une unité de mesure, si l'unité de mesure n'existe pas tu ne pourras pas t'y référer et donc tu ne pourras pas créer ton ingrédient.
Il faut savoir que lorsqu'il y a une cardinalité 1,1 la table ou qui se trouve à coté de cette cardinalité va récupérer en clé étrangère, l'identifiant de la table sur laquelle pointe cette cardinalité.

Voila, j'espère t'avoir éclairé.

Citation:

---

Envoyé par beegees

Bonjour bujuman et Tazmania,
Avec quel programme as-tu fait ce MCD ?

---

Power AMC

Citation:

---

Envoyé par beegees

Que veux dire Association_1 ?

---

C'est une appellation, tu peux mettre à la place Composition

Citation:

---

Envoyé par beegees

Nous avons un MCD à 5 pattes ?

---

Je ne vois pas ce que tu veux dire

Citation:

---

Envoyé par beegees

Entre ingrédient et quantification, je vois 1,1, cela veut donc dire qu'un ingrédient ne peut avoir qu'une quantification ?

---

D'après mon MCD oui, ça peut toutefois changer en fonction de tes régles de gestion

Citation:

---

Envoyé par beegees

N'as t'on à faire à aucun CIF ?

---

Si, entre Cocktail, Ingredien et Variante

Re-bonjour Bujuman et Tazmania,

Merci à vous deux d'avoir consacré du temps à me répondre.

J'imprime et j'analyse vos réposne dans le train ensuite (demain ou samedi), je vous recontacterai.

Encore un super grand merci à vous deux, vous êtes très sympa.

beegees

Bonsoir Beegees,

Vous devriez être désormais un fin connaisseur de Merise, suite au travail effectué sur le parcours de des étudiants de votre fac !

Bon, passons. Je rédige un bout de cours, en sorte que Coucou17 puisse en profiter.

Entités

On va dire que les cocktails Daiquiri, Bloody Mary, Beegees, etc. partagent des propriétés communes, par exemple avoir un nom, une couleur, que sais-je. On va donc procéder à l’abstraction de tout cela et (nous sommes ici dans un contexte Entité-Relation) mettre en œuvre ce que l’on appelle une entité-type ou type d’entité ou encore en raccourci, entité quand il n’y a pas confusion (une entité est en réalité un représentant d’une entité-type, une instance, ou encore une valeur, un individu, que sais-je). En l’occurrence on nommera cette entité-type COCKTAIL (notez l’emploi du singulier). Elle est dotée de propriétés (ou attributs) telles que NOM, COULEUR, etc.

Un cocktail peut être décliné en variantes, lesquelles caractérisent le cocktail. On pourrait considérer l’ensemble de ses variantes comme une propriété multivaluée du cocktail, mais il est préférable de les dégager et d’en faire une entité-type VARIANTE. Simplement, autant un cocktail est une entité forte (autonome), autant une variante est une entité faible (ou dépendante), elle n’a aucun sens si elle n’est pas attachée à un cocktail (comme une ligne de commande n’a de sens que lorsqu’elle est attachée à une commande).

A leur tour, les ingrédients comme le rhum, le sucre, etc. peuvent faire l’objet d’une abstraction et donner lieu à une entité-type INGREDIENT dont je vous laisse le soin de définir les propriétés... Dans le cadre du micro-monde qui nous intéresse ici (que l’on appelle encore Univers du discours, merci M. Augustus De Morgan), cette entité-type peut être considérée comme forte.

Vous avez mentionné une donnée intéressante, celle de quantité. Quantité de quoi ? de sucre, de rhum, etc. A quelle fin ? Pour composer une variante de cocktail. On dira donc que le rhum entre à raison de 10 cl dans la composition de la variante 3 du Beegees (cocktail fortement recommandé par la Faculté).

(Incidemment, une question se pose : est-ce que l’unité utilisée pour le rhum est la cuillérée ? le centilitre ? Les deux formules sont-elles possibles, en sorte qu’au niveau d’une composition on puisse choisir entre 3 cuillérées ou 3 cl ? Admettons ici qu’un ingrédient ne s’exprime que dans une seule unité.)

On est d’accord que cette quantité de 10 cl ne prend son sens que dans le contexte d’une relation entre un ingrédient (rhum en l’espèce) et une variante (la variante 3 du Beegees). Donc de même que l’on a procédé à l’abstraction d’entités agréablement buvables en une entité-type, en toute logique, on pourra mettre en œuvre une relation-type (ou association-type) que l’on appellera par exemple Entrer_Dans_La_Composition ou, pour faire plus court, COMPOSER ou tout autre verbe (ou nom tel que COMPOSITION, l’essentiel n’est pas là). Pour ma part (je suis merisement un tantinet hérétique !), je préfère parler d’entité-type associative plutôt que de relation-type. Ainsi, la mise en œuvre d’une entité-type associative COMPOSITION pourra servir à connecter les variantes et les ingrédients. Elle est dotée d’une propriété : Quantité.

Je mettrai donc en œuvre quatre types d’entités

- Deux types d’entités fortes : COCKTAIL, INGREDIENT,
- Un type d’entité faible : VARIANTE,
- Un type d’entité associative : COMPOSITION (en notant que VARIANTE peut être à son tour considérée comme forte relativement à COMPOSITION).

Une remarque concernant l’unité de mesure. Il est d’usage de définir la liste des valeurs associées : centilitre, cuillère, gramme, comme vous l’avez fait. Au niveau du SGBDR (ici DB2), au niveau de la table INGREDIENT on sait établir la liste précise de ces valeurs au niveau de la colonne unité de mesure (appelons-la Unité) :

Create Table INGREDIENT (...,
Unité Char Constraint Type_Unite Check Unité In ('centilitre', 'gramme', 'cuillère’),
...) ;

Mais il fréquent avec Merise de mettre en œuvre une entité-type (forte), qui permet d’en dire plus sur une propriété telle qu’unité, en fournissant les propriétés supplémentaires qui vont bien (qui a défini telle unité, à quelle date, etc.)

Donc, d’accord pour mettre en œuvre un type d’entité supplémentaire que nous appellerons UNITE.

Il nous reste au moins deux choses à faire :
- Identifier les entités.
- Définir les liens qui les unissent.

Des identifiants

Je ne vais pas vous faire un cours complet, mais disons qu’il est nécessaire de pouvoir repérer une entité en particulier. Ceci nécessite de choisir une propriété qui garantisse l’unicité des entités et on l’appelle identifiant. Par exemple, si deux cocktails ne peuvent pas porter le même nom, alors ce nom peut servir d’identifiant.

Cela dit, il arrive que l’on ait la possibilité d’avoir des jumeaux parfaits. Pour évacuer ce problème, il est préférable de mettre en œuvre une propriété artificielle (celles dont nous avons parlé jusqu’ici sont dites naturelles). De même, il est indispensable, pour des raisons que je ne peux développer ici, que cet identifiant soit invariant : la mise en œuvre d’une propriété artificielle s’impose encore plus.

Par ailleurs j’ai laissé entendre que l’identifiant correspond à une seule propriété : en fait, on peut très bien identifier une entité par un couple, un triplet, un quadruplet, ... un n-uplet de propriétés (voir ci-dessous le cas des variantes et des compositions).

Dans ces conditions, l’entité-type COCKTAIL aura pour propriétés : C_Id, Nom, Couleur, etc., C_Id étant le nom de l’identifiant (vous êtes libre de choisir le nom qui vous convient). Il est par ailleurs souvent d’usage de souligner les propriétés identifiantes pour mieux les repérer.

De même pour INGREDIENT : I_Id, Nom, Couleur, etc.

Les entités-types COCKTAIL, INGREDIENT et UNITE sont fortes et ont un identifiant singleton (respectivement C_Id, I_Id, U_Id).

L’entité-type VARIANTE est faible, elle traduit une propriété multivaluée de COCKTAIL : son identifiant est celui de COCKTAIL (C_Id). Mais, les entités variante 1, variante 2, du cocktail Daiquiri etc. auront même valeur d’identifiant, ce qui enfreint la contrainte d’unicité : on complète cet identifiant par une propriété supplémentaire permettant de respecter la contrainte. Le plus souvent, on utilise une numérotation par entiers, partant de 1 pour chaque Cocktail. Appelons V_Id cette propriété : pour le cocktail dont l’identifiant C_Id a la valeur 1, sa variante 1 aura pour identifiant <C_Id =1, V_Id =1>, sa variante 2 aura pour identifiant <C_Id =1, V_Id =2>, etc. De la même façon, pour le cocktail dont l’identifiant C_Id a la valeur 2, sa variante 1 aura pour identifiant <C_Id =2, V_Id =1>, sa variante 2 aura pour identifiant <C_Id = 2, V_Id =2>, etc.

L’entité-type VARIANTE aura pour propriétés : C_Id, V_Id, Nom, ...

A son tour, l’entité-type associative COMPOSITION peut être considérée comme faible relativement à VARIANTE et à INGREDIENT : son identifiant est donc l’union des identifiants de ces deux entités-types. COMPOSITION aura pour propriétés : C_Id, V_Id, I_Id, Quantité.

Un détour du côté de SQL

A partir des descriptions précédentes, vous pouvez déjà définir un jeu de tables, où vous noterez la correspondance entre l’identifiant d’une entité-type et la clé primaire de la table qui en découle :

Create Table COCKTAIL (C_Id Integer, Nom Char(32), Couleur Char (32), ..., Primary Key (C_Id)) ;

Create Table VARIANTE (C_Id Integer, V_Id Integer, Nom Char(32), ..., Primary Key (C_Id, V_Id)) ;

Create Table UNITE (U_Id Integer, Nom, ..., Primary Key (U_Id)) ;

Create Table INGREDIENT (I_Id Integer, Nom Char(32), U_Id Integer, ..., Primary Key (I_Id)) ;

Create Table COMPOSITION (C_Id Integer, V_Id Integer, I_Id Integer, Quantité Integer, Char(32), ..., Primary Key (C_Id, V_Id, I_Id)) ;

Pour répondre aux questions que vous posez dans votre message initial, il n’y a guère de difficultés :

- Quelles sont les variantes du cocktail Beegees :

Select V.Nom From COCKTAIL C, VARIANTE V Where C.Nom = 'Beegees' And C.C_Id = V.C_Id ;

- Ce qu’il y a dans chaque variante du cocktail Beegees :

Select V.Nom, I.Nom, K.Quantité, U.Nom
From COMPOSITION C, VARIANTE V, COMPOSITION K, INGREDIENT I, UNITE U
WHERE C.Nom = 'Beegees' And C.C_Id = V.C_Id And V.C_Id = K.C_Id And V.V_Id =K.V_Id And K._I_Id = I.I_Id And I.U_Id = U.U_Id

- Dans quel cocktail utilise-t-on un ingrédient déterminé :

Select C.Nom From COCKTAIL C, COMPOSITION K, INGREDIENT I Where I.Nom = 'arsenic' And I.Id = K.I_Id And K.C_Id = C.C_Id ;

Maintenant vous me ferez peut-être observer que j’ai utilisé l’instruction Select de SQL pour répondre aux questions, comment fait-on en Merise ? Réponse : y a pas d’équivalent ! Dans les années soixante-dix, Merise a été conçu pour modéliser la structure des données (et certaines contraintes d’intégrité) et aussi modéliser la synchronisation des événements déclencheurs des processus manipulant ces données. La modélisation des données produit un modèle conceptuel des données (MCD) tandis que la modélisation des déclenchements des processus produit un modèle conceptuel des traitements (MCT).

Merise traite aussi du niveau logique, par dérivation des MCD et MCT en MLD et MOT (respectivement Modèle Logique des Données et Modèle Organisationnel des Traitements).

Concernant la dérivation des MCD en MLD (voire en MPD, Modèle Physique des Données), vous pouvez utiliser des AGL tels que Power AMC ou Win’Design
(voir http://www.developpez.net/forums/forumdisplay.php?f=33).

Vous pouvez aussi utiliser DBDesigner 4 qui permet de travailler directement au niveau MLD et MPD. Vous pouvez encore fouiller sur la Toile...

Des relations (ou associations)

Dans ce qui précède, je n’ai pas particulièrement traité des relations qui unissent les entités et pourtant j’ai utilisé des requêtes SQL pour fournir des résultats : quand j’ai codé C.C_Id = V.C_Id, j’ai marié les tables COCKTAIL et VARIANTE, en utilisant l’opérateur par excellence du Modèle relationnel (dont SQL s’est inspiré), à savoir la jointure sur une colonne commune : C_Id. Le Modèle relationnel est en fait éminemment associatif. A partir du jeu de Create Table, je pourrais faire de la rétroconception et produire un MCD, sous réserve, par sécurité, d’avoir défini en SQL les liens qui unissent les tables :

Alter Table VARIANTE Add Foreign Key (C_Id) References COCKTAIL;

Alter Table COMPOSITION Add Foreign Key (C_Id, V_Id) References VARIANTE;

Alter Table COMPOSITION Add Foreign Key (I_Id) References INGREDIENT;

Alter Table INGREDIENT Add Foreign Key (U_Id,) References UNITE;

Je ne vais pas ici développer le concept de Foreign Key (Clé étrangère in french), disons qu’il s’agit d’un élément intervenant dans ce qu’on appelle l’intégrité référentielle, permettant d’éviter par exemple qu’une variante fasse référence à un cocktail inexistant.

A son tour, Merise exige à juste titre que l’on définisse les relations entre entités. Graphiquement, une entité est symbolisée par un rectangle. Une relation est représentée par un ovale, unissant deux (voire plusieurs) entités par des liens symbolisés par des traits (je ne dessine pas les rectangles et symbolise la relation par la lettre O majuscule) :

Cocktail--------------O---------------Variante

Personnellement (qu’on m’excuse !) je ne symbolise pas les relations que je préfère remplacer par des entités associatives. Par voie de conséquence, je ne symbolise que les liens :

Cocktail------------------------------Variante

Des cardinalités

Quoi qu’il en soit, quel que soit le cas de figure, on n’en reste pas là, on fait intervenir ce que qu’on appelle les cardinalités.

Il s’agit d’un point très fort de la Méthode, permettant d’exprimer le fait que :
Une relation entre deux (ou plusieurs) entités est de type un à un, un à plusieurs ou plusieurs à plusieurs.

En outre, il faut exprimer la minimalité d’une cardinalité, à savoir si une entité peut être (provisoirement) sans relation avec une entité partenaire ou au contraire si elle doit à tout moment entretenir cette relation. On dit que la relation est facultative ou obligatoire.

Par exemple, pour signifier qu’un cocktail donné se décline en au moins une variante et qu’une variante est une déclinaison d’un cocktail et un seul (on aura reconnu une surjection), on symbolise ainsi la chose :

Cocktail--|----------------------------|<--Variante

Pour signifier qu’une unité de mesure donnée a la possibilité de n’avoir pas encore été utilisée (mais cela viendra bien sur un jour, cas par exemple du beegee/seconde), ou ne l’est plus (on aura reconnu une simple application) :

Unité--|------------------------0<--Ingrédient

Nous n’avons pas le cas ici, mais pour signifier qu’une entité A entretient au plus une relation avec une entité B (injection) :

A-|--------------------------0-|-B

Pour signifier qu’une entité A entretient au moins et au plus une relation avec une entité B et réciproquement (bijection) :

A-|----------------------------|-B

Pour des raisons de complétude, on peut rencontrer la situation (qui à mon sens traduit une modélisation incomplète) :

A-|-0------------------------0-|-B

En revanche on peut avoir des relations de plusieurs à plusieurs (cas fréquent et légitime) :

A->|-0------------------------0<-B

qu’il est préférable, par la mise en œuvre d’une entité-type associative C de transformer en :

A-|-------------0<--C-->0------------|-B

Cas particulier des relations identifiantes

On traduit la dépendance d’une entité par rapport à une autre à l’aide d’un mickey particulier (par exemple ici, le signe "="). Dans votre univers de cocktails, ceci concerne donc les entités VARIANTE et COMPOSITION :

Cocktail--|----------------------------|<=-Variante

Variante--|----------------------------|<=-Composition

Ingrédient --|----------------------------|<=-Composition

Ceci vaut bien sûr dans le cas de l’injection :

A-|--------------------------0-|=-B

Si vous avez à lire des schémas de type entité-association sur ce forum ou ailleurs, vous noterez que les noms des identifiants hérités d’entités plus fortes ne figurent pas dans les rectangles utilisés pour les entités faibles. En effet, il n’y a aucune valeur ajoutée à faire figurer ce qui est implicite, conséquence de l’utilisation d’une relation. Plus généralement, on ne fait pas figurer dans un rectangle les propriétés héritées par relation. Prenons le cas de l’entité-type COMPOSITION :

Conceptuellement on écrit donc

COMPOSITION (Quantité)

plutôt que

COMPOSITION (C_Id, V_Id, I_Id, Quantité)

Toutefois, quand on est au niveau logique (MLD), comme par exemple avec DBDesigner 4, la redondance est effective (ce qui n’est pas un problème).

Autres notations des cardinalités

Chaque Méthode, chaque AGL, chaque SGBD, chaque langage a ses propres mickeys pour représenter les cardinalités. Par exemple

Cocktail--|----------------|<--Variante est équivalent à : Cocktail--1,1----------------1,N--Variante

Cocktail--|---------------|<=-Variante est équivalent à : Cocktail--(1,1)----------------1,N--Variante

Unité--|------------------0<--Ingrédient est équivalent à : Unité--1,1-----------------0,N--Ingrédient

A--|-----------------------0-|=-B est équivalent à : A--(1,1)-----------------------0,1--B

Etc.

Règles de passage du MCD au MLD (et/ou MPD)

Supposons que vous vouliez traduire des concepts du MCD au niveau SQL, tabulaire. Je ne m’étendrai pas sur ce sujet, car il peut faire l’objet d’un roman au sens propre du terme.

Il est d’usage de transformer une entité-type en table (alors que l’on peut en faire à l’occasion un type, cf. plus haut le cas de l’unité de mesure).

Il est d’usage qu’une injection ou une bijection donne lieu à la fusion des deux entités-types impliquées (je ne suis pas convaincu du bien fondé de la chose).

Les relations en Merise

Les relations en Merise sont graphiquement représentées par des ovales. D’un point de vue sémantique, on fait ainsi très nettement la distinction entre entité et relation. Jusqu’ici j’ai parlé de COMPOSITION comme étant une entité-type associative. En réalité il s’agit d’une relation-type entre VARIANTE et INGREDIENT (vous noterez que cette relation-type est porteuse de la propriété Quantité). Ci-dessous je symbolise l’ovale par une paire de parenthèses encadrant le nom de la relation-type que je renomme en COMPOSER :

INGREDIENT------------------(COMPOSER)-----------------------VARIANTE

Concernant les cardinalités, plutôt que de les exprimer ainsi :
INGREDIENT--|-------------0<--(COMPOSER)-->0-------------------|--VARIANTE

on évacue les cardinalités implicites redondantes :

INGREDIENT---------------0<--(COMPOSER)-->0---------------------VARIANTE

et on utilise la notation définie pour Merise quant aux cardinalités restantes :
INGREDIENT---------------0,N--(COMPOSER)--0,N---------------------VARIANTE

Cas de la relation entre COCKTAIL et VARIANTE (nommons-la SE_DECLINER) :

COCKTAIL--|----------------------------|<=-VARIANTE

peut être symbolisé (noter les parenthèses encadrant 1,1)

COCKTAIL ----------1,N--(SE_DECLINER)--(1,1)-------------- VARIANTE

Incidemment, vous aurez intuité que la relation-type COMPOSER fait l’objet d’une table quand on descend au niveau SQL. Problème avec SE_DECLINER : en fait-on une table ? Procède-t-ton comme nous l’avons fait plus haut (clé étrangère dans la table VARIANTE) ? La réponse n’est pas forcément toujours la même.

Les CIF

J’ai posé une question plus haut : est-ce que l’unité utilisée pour le rhum est la cuillérée ? le centilitre ? Les deux formules sont-elles possibles, en sorte qu’au niveau d’une composition donnée on puisse choisir ? J’avais supposé qu’un ingrédient ne s’exprime que dans une seule unité. Supposons maintenant que pour une quantité donnée de rhum, cela puisse être le centilitre ou la cuillérée. L’entité-type UNITE n’est alors plus en relation avec INGREDIENT mais avec COMPOSITION :

UNITE--|------------------------0<--COMPOSITION

et COMPOSITION aura désormais pour propriétés pour propriétés : C_Id, V_Id, I_Id, Quantité, U_Id.

Si l’on utilise la représentation par ovales, la relation COMPOSER pose un problème très intéressant. En effet, elle connecte non seulement INGREDIENT et VARIANTE, mais aussi UNITE. Or, la règle en Merise est que l’identifiant d’une relation est la concaténation (je préfère dire l’union) des identifiants des entités reliées. L’identifiant de COMPOSER est donc le quadruplet {C_Id, V_Id, I_Id, U_Id} or, on a vu qu’en réalité, au niveau SQL, la clé de la table COMPOSITION était le triplet {C_Id, V_Id, I_Id}. Soit l’identifiant merisien n’est pas équivalent à la clé du Modèle relationnel, soit il faut mettre en œuvre un concept supplémentaire permettant de résoudre le problème posé. Ce concept porte le nom de Contrainte d’Intégrité Fonctionnelle (CIF), que je vous laisse le soin d’étudier (voir les FAQ).

Pour finir

Suite à cette introduction à la modélisation conceptuelle des données, je vous conseille d’approfondir à partir des FAQ de ce forum. Vous pouvez aussi étudier avec profit l’ouvrage « Parlez-vous Merise ? » de Michel Diviné :

http://michel.divine.free.fr/Livre.htm
http://michel.divine.free.fr/Parlez.zip

Vous constaterez qu’il existe mille et une façons de modéliser un thème donné comme le vôtre. L’erreur est humaine et on peut se tromper, ceci vaut pour moi comme pour vous. L’essentiel est de savoir le reconnaître et de corriger les boulettes.

Je vous demande de me pardonner pour les coquilles et les copier/coller intempestifs...

Bon courage.