Discussion :

[bouba69]

salut tout le monde,

En premier je tiens remercier par avance tous ceux et celles qui auront la patiente et la gentillesse de me répondre.


Voila j'ai donc un petit problème.Je m'explique .

J'ai un exercice a faire pas je ne sais pas par quel bout le prendre.Je dois modéliser la gestion d'un aeroclub sachant que la gestion de l'aéro-club répond au besoin suivants:

Gestion des pilotes:Leur caracteristiques (adresse,qualification) et leur compte au niveau du club.Un pilote est titulaire d'un compte, debité lors de chaque vol ou lors d'un achat d'un produit fourni par le club.


gestion des avions:carnet de route decrivant les utilisations successives.Prens aussi en compte l'achat et la vente d'avions.


Les données accessibles doivent être:

pour les pilotes:-nom ,prenom,adresse,numero du brevet,qualification.

pour les avions:-immatriculation,type,année de construction,compteur horaire,tarif horaire.



les operations sur les données sont:

Pour les vols:- a la suite de chaque vol on dispose du nom du pilote, du nom de l'avion,de l'heure et la date de depart et celles de l'arrivée, du nom de la personne a qui facturer le vol.

pour les comptes:-versement ou debit dont on precise la date et le montant.



les différentes requêtes que l'on souhaite formuler sont:

pour les pilotes:- la liste des noms des pilotes, la consultation des caractéristiques d'un pilote donné,pour chaque pilote la liste de ses vols entre 2 dates données et celles de tous ses mouvements comptables.

Pour les avions:-la liste des différents vols pour tous les avions, pour un avion donné la liste de ses vols entre 2 dates,les caracteristiques d'un avion, le tarif horaire de l'avion,la liste des noms d'avion (leur immatriculation)


Pour la comptabilité :-la liste des mouvements comptables entre 2 dates.


On peut proposer cette gestion le modele Entité-Relation suivant:


ENTITE PILOTE:

nom du pilote
prenom
adresse
nombre d'heures de vol
numero brevet
positin comptable vis a vis de l'aero-club


ENTITE AVION
Immatriculation de l'avion
type de l'avion
prix horaire du vol sur cet avion
compteur horaire de l'avion
caracteristique de l'avion


ENTITE AEROCLUB
raison social de l'aero-club
diverses informations relatves à l'aero-club



ENTITE Mvt-Compt-Hvol
nom du pilote sur lequel porte le mouvement
code mouvement (credit ou debit)
code nature du mouvement(cb,cheques..)
date du mouvement
montant du mouvement


ENTITE VOL
immatriculation de l'avion utilisé lors du vol
nom du pilote aux commandes du vol
nom du pilote a facturer
date de début du vol
date d'arrivé du vol
compteur horaire de l'avion au depart
compteur horaire de l'avion à l'arrivée



ASSOCIATIONS

Appartient à:-entre AEROCLUB et AVIONS
Peut-Piloter: entre PILOTE et AVIONS
Membre de :-entre PILOTE ET AEROCLUB


On obtient les relations suivantes:

Pilote(nom,prenom,adresse,nbhvol,brevet,position,habil)
Avions(immat,type,prix,compth,cara)
Aeroclub(raison,divers)
Mvt-Compt-Hvol(nom,codmouv,codnat,date,montant)
VoL (immat,nomvol,nomfact,datedeb,datefin,compthdep,compthfin)


appartient-à (raison,immat)
Peut-Piloter(nom,immat)
Membre de (raison,nom)


Comment faire le MCD?Par quel bout commencer?

dois-je me contenter de ces entités et de ces relations?Ou puis-je créer d'autres entiés.Par exemple produit ou clients ou founisseurs.Puisque l'aero-club fourni d'autres service que de louer des avions (achat et vente d'avions et vente de produit)
De même les infos sont peut-être incomplète concernant les associations?Peut-être faudrait-il ajouter l'association possede entre pilote et compte......

qu'en pensez-vous?

[Mat.M]

hmmm on dirait les grands classiques de l'informatique 1ere, 2eme ,3eme forme normale, dictionnaire de données, Merise

Comment faire le MCD?Par quel bout commencer?

Si tu as Access le plus simple est d'utiliser l'outil visuel qui permet de faire des relations..
Essaies de te documenter sur les relations Boyce-Codd je crois mais pour une telle gestion il faut faire au plus simple

Voila j'ai donc un petit problème.Je m'explique .

J'ai un exercice a faire pas je ne sais pas par quel bout le prendre.Je dois modéliser la gestion d'un aeroclub sachant que la gestion de l'aéro-club répond au besoin suivants:

Mais c'est pour un véritable aéroclub ou pour un exercice de BTS/IUT ?
Dans tous les cas commencer par faire les tables sous Access et faire les relations en s'aidant d'un papier et du dictionnaire de données

[bouba69]

Mais c'est pour un véritable aéroclub ou pour un exercice de BTS/IUT ?

un exo BTS

[Antoun]

Je ne comprends pas bien ce qu'on te demande ? Ils te donnent la liste des entités et des relations, donc le MCD est déjà fait ? Ou alors, tu dois juste dessiner ce qu'on t'indique ?

[fsmrel]

Bonjour bouba69,


Vous parlez de MCD, entités, relations, donc vous êtes au niveau conceptuel : disposez-vous d'un outil de modélisation pour produire des MCD ?

Mat.M évoque Access, mais on est déjà au niveau MLD et on saute une étape. C'est possible mais c'est dommage de ne pas déjà attaquer au niveau supérieur. Vous pouvez à la limite utiliser les gratuits que sont DBDesigner ou Toad Data Modeler, mi-MCD, mi-MLD. Mais si vous en avez la possibilité, utilisez de préférence des AGL comme Win'Design ou PowerAMC.

Une fois l'outil de modélisation en main et après avoir appris à le maîtriser, vous pourrez attaquer votre travail par le bon bout.

[bouba69]

ok merci pour les réponses vraiment ici je peux progresser.

voici donc mon MCD:

[fsmrel]

Bonjour Bouba69,


Pour produire une image avec PowerAMC :

1) Edition : cocher "Exporter en couleur"

2)Edition\Sélectionner tout\Exporter une image

3) Fenêtre Enregistrer sous" : choisir Type : JPG

[fsmrel]

Hello hed62,

J'ai pu ouvrir le fichier AEROCLUB.gif.zip de bouba69. Voir ci-dessous l'image du MCD.


Pour bouba69 :

Il y a pas mal d'observations constructives et néanmoins amicales à faire : je suppose qu'elles ne vont pas tarder, préparez-vous et restez serein...

[hed62]

Juste deux trois petites remarques rapides à corriger :

- Préfère l'utilisation d'identifiants plutot que de nom en français correct : pour l'instant c'estplus lisible, donc mieux, par contre quand tu va devoir construire ta base...

- Un pilote peut être inscrit dans plusieurs aéroclub en même temps ?
- Un avion peut appartenir à plusieurs aéroclub en même temps ?

J'ai du mal avec l'entité Mvt-Compt-Hvol... A quoi sert elle exactement, et comment t'en sers tu ?

Pourquoi reprendre le nom du pilote partout ?
Celui aux commandes n'a rien à voir avec celui qui doit payer ? Pourquoi garder le prénom de celui qui doit payer ?

A quoi servent les compteurs horaires départ/arrivée ?

NBVol est une donnée calculable aisément : elle ne doit pas etre stockée.

Le numero de brevet est un entier ? (N°Brevet différent de NUMBREVET ?)
Tu comptes stocker la liste des habilitations de quelle manière exactement ?

Pourquoi la relation "appartient" entre avion et aeroclub possède un num de brevet ?

Le type d'un avion devrait etre une table séparée me semble t il (comme plusieurs choses dans ton diagramme d'ailleurs)

Tu comptes stocker la liste des caractéristiques de quelle manière exactement ?

Euh... pour les "deux trois", on va dire que c'est plutot deux ... demie douzaines

P.S : bonjour fsmrel Je te laisse compléter :-p

[fsmrel]

Bouba69,


En préalable. Dans votre 1er message, vous mentionniez une entité AVION. Au lieu de "entité", on peut préférer écrire : "entité-type", auquel cas, AVION est un objet de modélisation (un prédicat au sens de la logique), tandis qu’une entité AVION est une instance, une occurrence d’entité-type, c'est-à-dire une concrétisation, une réalisation, une matérialisation, une réification (une proposition au sens de la logique)...

Exemple d’entité-type, représentée sous forme de prédicat :

L’avion ayant pour immatriculation IMMATRICULATION, de type TYPE, dont le tarif horaire est PRIX_HORAIRE_VOL et le compteur horaire est valorisé à COMPTEUR_HORAIRE, a pour caractéristiques CARACTERISTIQUES.

Exemple d’entité, représentée sous forme de proposition :

L’avion immatriculé F-XYZT, de type Beechcraft 123, dont le tarif horaire est de 100 et le compteur valorisé à 1234, a pour caractéristiques bla bla...

Cela dit, nombre de concepteurs abrègent "entité-type" en "entité" et remplacent "entité" par "occurrence d’entité". Ceci n'est cependant pas un problème, dans la mesure où le contexte permet d'éviter les confusions.
A noter que l’on peut utiliser aussi les termes "individu-type" et "individu". Il y a 30 ans, les termes "objet" et "individu" étaient du reste synonymes.

Ce que je viens d'écrire n'engage que moi et peut être contesté. Je ne cherche qu'à mettre un peu de rigueur, en m'inspirant du Modèle relationnel de données, qui est exemplaire en la matière.

Remarque :

Dans la représentation graphique de votre MCD, vous renommez AVION en "avions" : à éviter, puisque "avions" évoque plutôt une liste d'instances d’avions, et non pas une entité-type.

A suivre...

[fsmrel]

Bouba69,

A la demande de hed62, je commence à compléter, mais à coup de doses raisonnables, pour ne pas vous effrayer, sinon vous accabler...

De l’identification

Préfère l'utilisation d'identifiants plutot que de nom en français correct : pour l'instant c'est plus lisible, donc mieux, par contre quand tu va devoir construire ta base...

De fait, Bouba69, toute entité doit être identifiable. Elle a des propriétés dites "naturelles" :

L’avion immatriculé F-XYZT, de type Beechcraft 123, dont le tarif horaire est de 100 et le compteur valorisé à 1234, a pour caractéristiques bla bla...

Dans cet exemple, l'immatriculation de l'avion, son type, etc. sont ses propriétés naturelles. Par ailleurs, comme toute entité doit être repérable de manière unique, identifiable parmi l'ensemble de ses petites soeurs, on peut dire aussi que l’immatriculation d’un avion convient à cet effet : son numéro d'immatriculation est logiquement conduit à être un identifiant naturel. Cela dit, suivons un maître en modélisation, à savoir Yves Tabourier, qui a écrit :

"Un identifiant ne décrit rien, son rôle est de distinguer deux jumeaux parfaits".

Dans cet esprit, ajoutons donc à AVION un attribut (ou propriété, utilisez le terme qui vous plaît) "AvionId" qui soit identifiant légal et prendra, par exemple, les valeurs successives 1, 2, 3, ... Il n’aura aucune raison d’être modifié ultérieurement, contrairement au numéro d’immatriculation de l’avion, parce que, par exemple, on aura commis une erreur lors de la saisie de ce numéro. Et comme le suggère hed62, une fois que vous aurez livré la base de données en pâture aux utilisateurs, vous comprendriez votre douleur en n’ayant pas procédé comme nous vous le suggérons.

Dans ces conditions, le numéro d'immatriculation de l'avion conserve sa propriété d'unicité et devient identifiant alternatif.

=>

Avec PowerAMC

1) Ajoutez l’attribut AvionId et déclarez-le identifiant de AVION. L'AGL lui associera le qualificatif de "Identifiant_1" (terme que vous pouvez modifier).

2) Pour signifier qu’Immatriculation est identifiant alternatif :

Cliquez sur l’entité-type AVION. Apparaît la fenêtre "Propriétés de l’entité". Cliquez sur l’onglet Identifiants. Ajoutez une ligne : l’AGL met en œuvre un nouvel identifiant qu’il nomme Identifiant_2. Sélectionnez cet identifiant et cliquez sur l’icône de gauche "Afficher les propriétés" dans la fenêtre. Vous avez droit à un message "Vous ne pouvez pas modifier les propriétés..." auquel vous répondez par "oui". Apparaît une fenêtre : "Propriétés de l’identifiant..." Vous cliquez sur l’onglet "Attributs". Vous cliquez ensuite sur l’icône "Ajouter des attributs". Apparaît la liste des attributs de l’entité-type. Vous cochez la case IMMATRICULATION et vous faites "OK" en rafale. Dans le MCD graphique, la propriété IMMATRCULATION doit être accompagnée de la mention <ai> (pour "alternate identifier"). Ouf !

[bouba69]

Juste deux trois petites remarques rapides à corriger :



- Un pilote peut être inscrit dans plusieurs aéroclub en même temps ?
NON A RECTIFIER

- Un avion peut appartenir à plusieurs aéroclub en même temps ?
NON, A RECTIFIER AUSSI.


J'ai du mal avec l'entité Mvt-Compt-Hvol... A quoi sert elle exactement, et comment t'en sers tu ?

JE sais pas comment m'en servir.Je sais que d'après l'exercice pilote est titulaire d'un compte, débité lors de chaque vol ou lors d'un achat d'un produit fourni par le club.

Pourquoi reprendre le nom du pilote partout ?
je ne sais pas , qu'en pensez vous?

Celui aux commandes n'a rien à voir avec celui qui doit payer ? Pourquoi garder le prénom de celui qui doit payer ?
EFFectivement, que faire?

A quoi servent les compteurs horaires départ/arrivée ?
D'apres vous?

NBVol est une donnée calculable aisément : elle ne doit pas etre stockée.
effectivement.

Le numero de brevet est un entier ? (N°Brevet différent de NUMBREVET ?)
Non c'est une erreur

Tu comptes stocker la liste des habilitations de quelle manière exactement ?
Je ne sais pas c'est une question que je me<pose , dois-je creer une entité habilitation?

Pourquoi la relation "appartient" entre avion et aeroclub possède un num de brevet ?

exact , a la place de num brevet dois-je mettre comme indiqué dans la relations citer plus haut(donner par le prof) immat (clé primaire de l'entité avions).


Le type d'un avion devrait etre une table séparée me semble t il (comme plusieurs choses dans ton diagramme d'ailleurs)
Je ne sais pas .

Tu comptes stocker la liste des caractéristiques de quelle manière exactement ?
Je sais pas , je me pose des questions.


Euh... pour les "deux trois", on va dire que c'est plutot deux ... demie douzaines

P.S : bonjour fsmrel Je te laisse compléter :-p

[fsmrel]

Le type d'un avion devrait etre une table séparée me semble t il (comme plusieurs choses dans ton diagramme d'ailleurs)

Je ne sais pas.

Sans informations supplémentaires, le type d’un avion est quelque chose que l’on peut interpréter de plusieurs façons (chez les gens branchés, on va jusqu'à parler de polysémie).
Un quadrimoteur, un coucou, un jet, un biplan, un bombardier, un avion de ligne peuvent être des représentants de types d’avions. Vu du club où l’on voit vraisemblablement peu d’avions de lignes, et où l’on ne commence pas par piloter des jets, peut-être s’agit-il de marques et de leurs déclinaisons plus modestes : Piper J3, Cessna 150, Cessna 152, Socata TB-9 Tampico...
En tout état de cause, plusieurs avions du club peuvent être du même type. Ainsi, à supposer que le Cessna 150 soit à considérer comme un certain type d’avion, l’aéro-club Hispano-Suiza compte une dizaine de ces avions. Cela dit, Hispano-Suiza range le Cessna 150 dans le type "Biplace école à train fixe - VFR nuit", mais peut-être s'agit-il ici d'une interprétation qui ne vaut pas dans tel autre aéro-club, tout est toujours relatif. Autrement dit, il est nécessaire de tirer les vers du nez du maître d'ouvrage, pour être sûr que l'on ne se fourvoiera pas dans l’interprétation des choses.

Il peut aussi y avoir confusion entre le type de l’avion et ses caractéristiques...

Peu importe. L’essentiel à retenir est qu’une entité-type TypeAvion est à mettre oeuvre, où l’on décrira les différentes propriétés propres à un type d’avion. En effet, vous n’allez pas recopier toutes ces propriétés pour chaque avion du même type ! Les avoir une fois suffit. (Plus tard, vous verrez cela de plus près avec l’étude de la 3e forme normale).

La remarque de hed62 va dans ce sens.

Dans la représentation graphique ci-dessous, l'association-type Decrire (ce nom n'est pas terrible, je vous laisse le soin de trouver mieux...) relie les entités-types TypeAvion et Avion. Elle se lit ainsi :

Un type d'avion donné peut participer plusieurs fois à la l'association-type, autrement dit décrire plusieurs avions (du même type).

Un avion participe une seule fois à l'association-type, autrement dit un avion n'est que d'un seul type.

[hed62]

bouba, les questyions que j'ai posées plus haut ne sont pas la pour que nous y répondions nous mêmes, elles sont là pour t'aider à réfléchir, à comprendre, et à progresser.

Le but est que tu cogites là dessus, repose d'autres questions au besoin, en aprenant à mettre en évidence les faiblesses de ton modèle.

l'entité Mvt-Compt-Hvol...

Je sais pas comment m'en servir.Je sais que d'après l'exercice pilote est titulaire d'un compte, débité lors de chaque vol ou lors d'un achat d'un produit fourni par le club.

Personnellement, je pense donc que cette entité doit être en relation uniquement avec le pilote

Pourquoi reprendre le nom du pilote partout ?
je ne sais pas , qu'en pensez vous?

D'après toi, quels pourraient être les avantges et inconvénients de répéter le nom ou le prénom plutot que l'identifiant ?

Celui aux commandes n'a rien à voir avec celui qui doit payer ? Pourquoi garder le prénom de celui qui doit payer ?
EFFectivement, que faire?

Modifier ta modélisation Il faut mettre en relation un pilote qui conduit, et un pilote à facturer, si tant est qu'ils puissent être différents.

A quoi servent les compteurs horaires départ/arrivée ?
D'apres vous?

c.f les deux premières phrases de cette réponse.

Tu comptes stocker la liste des habilitations de quelle manière exactement ?


Je ne sais pas c'est une question que je me pose , dois-je creer une entité habilitation?

fsmrel te met sur la voie.

Pourquoi la relation "appartient" entre avion et aeroclub possède un num de brevet ?
exact , a la place de num brevet dois-je mettre comme indiqué dans la relations citer plus haut(donner par le prof) immat (clé primaire de l'entité avions).

Il est inutile de spécifier la clef primaire d'un Avion dans une relation entre Avion est Aéroclub. D'autant que la relation est de type 1..1-----1..n. Pourquoi ? Parcequ'au niveau MPD (donc 2 niveaux plus près de la base), cette relation va se transformer en ajoutant la clé primaire de l'aéroport en tant que clef étrangère dans la table avion. D'autre part, il n'est jamais utile de faire porter à une relation l'identifiant d'une des deux entités qui participe à cette relation.

Le type d'un avion devrait etre une table séparée me semble t il (comme plusieurs choses dans ton diagramme d'ailleurs)
Je ne sais pas .

là aussi, suis le guide

Tu comptes stocker la liste des caractéristiques de quelle manière exactement ?
Je sais pas , je me pose des questions.

Essaie de dégrossir le travail, et pose nous des questions précises

[bouba69]

Personnellement, je pense donc que cette entité doit être en relation uniquement avec le pilote


D'après toi, quels pourraient être les avantges et inconvénients de répéter le nom ou le prénom plutot que l'identifiant ?

L'identifiant est un moyen d'identifier de manière unique une occurrence d'une Entité.Par consequent je pense qu'il est preferable de creer un identifiant explicite plutôt que d'utiliser nom et prenom comme ID parce qu'il se peut que 2 pilotes par exemple possèdent le même nom...


Modifier ta modélisation Il faut mettre en relation un pilote qui conduit, et un pilote à facturer, si tant est qu'ils puissent être différents.

Je n'ai pas bien saisi ,moi je suppose que le pilote qui conduit et le pilote qui est facturer sont les mêmes,non? Me suggeres tu de creer une table "facure" par exemple?


c.f les deux premières phrases de cette réponse.


fsmrel te met sur la voie.


Il est inutile de spécifier la clef primaire d'un Avion dans une relation entre Avion est Aéroclub. D'autant que la relation est de type 1..1-----1..n. Pourquoi ? Parcequ'au niveau MPD (donc 2 niveaux plus près de la base), cette relation va se transformer en ajoutant la clé primaire de l'aéroport en tant que clef étrangère dans la table avion. D'autre part, il n'est jamais utile de faire porter à une relation l'identifiant d'une des deux entités qui participe à cette relation.


là aussi, suis le guide


Essaie de dégrossir le travail, et pose nous des questions précises

[hed62]

Effectivement, il y a les problèmes d'homonymie que tu soulèves. Mais aussi les problèmes de redondances : répéter le nom du pilote à trois endroits différents augment très considérablement le risque d'erreur, les couts de maintenance, etc... D'autre part, les recherches sur des index de type entier seront beaucoup plus rapide que sur des chaines (à vérifier tout de même).

Une table facture, pourquoi pas. Si tu supposes que le pilote qui conduit est celui qui doit payer, pourquoi faire la distinction "aux commandes" et "à facturer" ? un seul id suffit.

[bouba69]

Effectivement, il y a les problèmes d'homonymie que tu soulèves. Mais aussi les problèmes de redondances : répéter le nom du pilote à trois endroits différents augment très considérablement le risque d'erreur, les couts de maintenance, etc... D'autre part, les recherches sur des index de type entier seront beaucoup plus rapide que sur des chaines (à vérifier tout de même).

Une table facture, pourquoi pas. Si tu supposes que le pilote qui conduit est celui qui doit payer, pourquoi faire la distinction "aux commandes" et "à facturer" ? un seul id suffit.

Celui qui pilote est celui qui doit payer, cela me semble logique.Si j'ai bien compris je dois supprimer "aux commandes" et "a facturer" de l'entité Vol pour les rassembler avec un seul ID?


Autres questions que faire au lieu de repeter les noms du pilote à 3 endroits differents ne vaudrait-il pas mieus remplacer nom pilote par ID pilote dans les 3 endroits?

[hed62]

Celui qui pilote est celui qui doit payer, cela me semble logique.Si j'ai bien compris je dois supprimer "aux commandes" et "a facturer" de l'entité Vol pour les rassembler avec un seul ID?

Oui

Autres questions que faire au lieu de repeter les noms du pilote à 3 endroits differents ne vaudrait-il pas mieus remplacer nom pilote par ID pilote dans les 3 endroits?

re-oui

[bouba69]

Effectivement, il y a les problèmes d'homonymie que tu soulèves. Mais aussi les problèmes de redondances : répéter le nom du pilote à trois endroits différents augment très considérablement le risque d'erreur, les couts de maintenance, etc... D'autre part, les recherches sur des index de type entier seront beaucoup plus rapide que sur des chaines (à vérifier tout de même).

Une table facture, pourquoi pas. Si tu supposes que le pilote qui conduit est celui qui doit payer, pourquoi faire la distinction "aux commandes" et "à facturer" ? un seul id suffit.

je dois creer une entite facture?

Facture(Id facture,N°pilote,Date,Montant) par exemple?

l'Attribut N°Pilote remplace "aux commandes" et "à facturer"

[fsmrel]

Avant de parler de points plus particuliers.


Des relations entre entités-types, entités-types faibles

Bouba, vous avez défini (entre autres) trois entités-types PILOTE, AVION, VOL. En réalité, du point de vue de la modélisation, un vol est un intermédiaire, permettant de mettre en relation des pilotes et des avions. Un vol n’a pas de sens s’il n’y a pas de pilote ou d’avion : un vol est modélisé en théorie sous la forme d’une association-type.


Mais alors, par définition et selon cette représentation, un couple (Pilote, Avion) est unique : le pilote Cézig ne pourra voler qu’une seule fois avec l’avion immatriculé F-BUBS, ce qui n’est évidemment pas ce que l’on souhaite, car il est normal que Cézig puisse voler plus d’une fois avec cet avion. Il existe un certain nombre de solutions pour améliorer la modélisation, dont la quasi omniprésente participation de l’"entité-type" DATE à l’association-type.

Pour votre part, vous avez choisi de faire de VOL une entité-type. En l’occurrence, ceci est légal et légitime, mais votre MCD est en l’occurrence à revoir.

Allons-y. Les entités-types AVION et PILOTE sont à considérer comme indépendantes, car insensibles au comportement de leur environnement : elles se suffisent à elles-mêmes.
L’entité-type VOL dépend pour sa part des deux précédentes et si l’on ne veut pas en faire une association-type, alors sémantiquement parlant, on doit la considérer comme une entité-type dite faible (weak entity), car les entités (ou occurrences) qui en sont les instances dépendent de leurs parentes, instances de PILOTE et AVION. L’identifiant de VOL peut alors être implicitement inféré, défini par le couple {AvionId, PiloteId} auquel on ajoute un attribut artificiel —appelons-le par exemple VolId—permettant de distinguer chaque vol pour ce couple et cet identifiant devient alors le triplet {AvionId, PiloteId, VolId}.

Vous noterez que les attributs AvionId et PiloteId ne sont pas décrits dans l’entité-type VOL. En effet, ils y figurent implicitement du fait des cardinalités 1,1 portées par les pattes connectant VOL et Servir_A d’une part et Voler d’autre part. Comme dit l’autre, en Merise "One fact, one place".


Vous noterez encore que ces cardinalités 1,1 sont mises entre parenthèses, ce qui est la convention pour signifier à PowerAMC que les attributs AvionId et PiloteId participent à l’identifiant de VOL, en compagnie de VolId. Au contraire, quand on a modélisé la relation entre AVION et TYPEAVION, TypeAvionId ne participe pas à l’identification de AVION. L’identifiant de AVION est {AvionId} et c’est tout.

Dans la représentation graphique précédente, l’attribut VolId est relatif au couple {AvionId, PiloteId}, mais vous pouvez tout aussi bien le rendre relatif seulement à {AvionId} ou a {PiloteId}. Exemple :


Une paire de parenthèses a disparu. L’identifiant de VOL est défini cette fois-ci par le couple {AvionId, VolId}.