Discussion :

[snoopo]

Salut, je voudrais s'il était paossible d'avoir ce type de relation
Par exemple : un passager doit avoir un billet pour voyager.
J'ai mis dans l'agrégat ->entité vol,date et aéroport. Ils forment d'ailleur une ternaire.
Mais ensuite j'ai une entité client/passager qui est en relation avec l'agrégat avec comme cardinalité client->agrégat :1,1 et agrégat->client : 1,n.
Est-ce possible d'avoir 1,n entre l'agrégat et le passager?
thx

[Invité]

Puisque tu es très pressé, je réponds d'instinct :

Pourquoi rattaché ton client à ta ternaire ??
Rattache le plutôt à ton vol par exemple.. Car si tu as le vol tu aura la date & l'aéroport...

De plus, est-il primordial d'avoir la date comme entité ? veux tu gérer l'historique ou non ? Si c'est non, alors un entité d'assoc est suffisante (heu je ne suis pas sûr que ce soit le terme exact j'ai une tendance à mélanger E/R & Objet !!beurk honte à moi )

La vrai réponse, si tu associe client à ta ternaire, ce n'est plus une ternaire puisqu'il y a 4 entités,
Et ce n'est pas possible d'avoir une cardinalité 1-1 dans une ternaire.....


Je dis ça, je dis rien je ne suis pas l'inventeur de MERISE :-)

[fsmrel]

Bonsoir Snoopo,

Vous êtes dans un forum Merise : merci d'utiliser la langue qui convient. Définissez par exemple de façon très précise ce que vous entendez par "agrégat".
(Êtes-vous UMLien ?)

De la même façon, donnez la signification de votre symbole "->"
(cf. l"'agrégat ->entité vol...")

Fournissez les définitions des entités-types et des relations qui les unissent, ainsi que les règles de gestion à partir desquelles on puisse définir les dépendances fonctionnelles, clés candidates, métabolisme, etc. C'est peut-être un peu fastidieux, mais on n'a rien sans rien.
Bien sûr, personne n'ignore ce qu'est a priori un vol, un aéroport ou un passager, mais le fait de rédiger avec rigueur et précision vous permet déjà de résoudre vous-même une catégorie de problèmes.

A défaut, nous ne pouvons que supputer, ce qui n'encourage pas à traiter votre problème...

[snoopo]

Salut,
dsl .
En fait qd je parlais d'agrégat, c'est les agrégations d'association. Ce que je voulais savoir en fait concerner s' il était possible d'avoir ce genre de cardinalité entre l'entité passager et l'agrégat association.

jactheripper a écrit :
De plus, est-il primordial d'avoir la date comme entité ? veux tu gérer l'historique ou non ? Si c'est non, alors un entité d'assoc est suffisante (heu je ne suis pas sûr que ce soit le terme exact j'ai une tendance à mélanger E/R & Objet !!beurk honte à moi

Je crois que si on a besoin parce qu'on me dit qu'un vol , c'est une certaine date, une seule par jour et possède toujours le même horaire.

Enfin voila une partie du mcd pour mieux se réprésenter.


On va par bien sur l'image mais la clé primaire est sur "Code_Aeroport" pour l'entité Aeroport et sur date et heure pour l'entité DATE

PS: euh petite précision en ce qui concerne la relation passager et l'agrégation d'association. Le passager a la possibilité de faire des escales pour arriver à la destination voulue et donc reçoit 2fois un n° embarquement

[fsmrel]

Bonsoir Snoopo,

Votre agrégat n’a rien de merisien ! Peu importe, on comprend ce que vous voulez exprimer. Maintenant, de façon plus rigoureuse, il s’agit dans un premier temps de rédiger en français les règles de gestion de données, notamment celles qui expriment des dépendances fonctionnelles et permettent de définir des entités-types et leurs relations en sorte que les clés candidates soient correctement exprimées et la normalisation respectée.

Ainsi, selon les réponses que vous fournirez ci-dessous, votre association DECOLLER pourra voler en éclats de plusieurs façons, avant même que l’on traite des passagers (cf. les pièces jointes).

Supposons donc que, par hypothèse, on définisse une entité-type VOL.

Des ambiguïtés sont à lever concernant la date du vol :

a) Le même avion pouvant effectuer plus d’un aller-retour par jour, le même vol peut-il avoir lieu plus d’une fois par jour ? Selon vos propos, il semblerait que ça ne soit pas le cas, mais ce que vous dites est vague, contradictoire semble-t-il avec votre MCD et doit être formellement précisé :

_____Règle (R01) : "Un vol a lieu au moins et au plus ... fois par jour"_____(compléter la règle)

Illustrez cela par un exemple : "le vol IT5926 blabla..."

b) Selon que la date d’un vol est exprimée en jour-mois-année ou simplement sous la forme du jour dans la semaine (exemple : "lundi"), la modélisation peut changer.

=>
_____Règle (R02) : "La date d’un vol est exprimée de la façon suivante : ... "_____(compléter la règle)


_____ (exemple : " ... ")

Etc. La modélisation est impactée par ces règles.

De façon complémentaire :

— Gérez-vous les départs seuls, sans les arrivées ? (dates, aéroports)

— Que fait l’attribut classe au niveau du vol ?

— Si l’on modélise telle quelle votre relation DECOLLER, au résultat de l’étape de dérivation, la table DECOLLER aura pour clé primaire :

_____ (N°Vol, DateVol, HeureDépart, CodeAeroport)

Ce qui veut dire (entre autres !) que le même jour et à la même heure, un vol donné peut avoir lieu dans plusieurs aéroports : on retrouve une variante intéressante du chat de Schrödinger...

Cas du passager

Là encore, soyez précis quant aux règles de gestion :
Je suppose que dans le cas simple, un passager est muni d’un billet et embarque une seule fois.
En cas d’escales, je suppose que le passager est toujours porteur d’un seul billet, mais ce dernier fait-il mention de ces escales ?
Selon votre MCD, un billet détermine un vol : le vol est-il multi-escales ?

Merci de donner des précisions.

En Merise (classique au moins), on ne peut pas établir une relation entre une entité-type et une autre relation (celle que vous appelez agrégat).
Si pour un vol on peut avoir plusieurs dates, pour contourner la difficulté, vous transformez l’association DECOLLER en entité-type faible (weak entity), identifiée relativement à VOL (cf. 2e pièce jointe).

Si pour un vol on a une seule date (et une seule heure), les données relatives au passager sont en relation directe avec VOL (cf. 1re pièce jointe).

Association ACHETER : selon les cardinalités, BILLET est en relation avec N passagers et un passager est en relation avec un seul billet : c’est un billet de groupe ?

________________

En pièce jointe, le sort que subit DECOLLER (outil "Toad Data Modeler" (freeware)) :

— PJ 1 : Pour un vol on a une seule date (par exemple "lundi") et une seule heure de décollage ("20h55") : DECOLLER disparaît.

— PJ 2 : Pour un vol on a plus d’une date (et une seule heure pour un vol et une date). J’ai supposé que l’aéroport pouvait changer avec la date : si tel n’est pas le cas, le lien avec l’aéroport est à faire avec VOL et non pas avec DECOLLER. Là encore, préciser les règles de gestion...

[snoopo]

Salut,
tout d'abord merci pour ton aide. Ensuite

pour la règle 1 : "Un vol a lieu au moins et au plus 1 fois par jour"
Ex : AF105 décolle de CDG à 7h20 pour arrivée à Lille 8h00.
Du coup je crois que l'entité DECOLLER vole en eclat, de même que l'entité DATE

Règle (R02) : "La date d’un vol est exprimée de la façon suivante : 15/01/2007

En ce qui concerne l'entité vol, oui il faut gérer l'heure,heure d'arrivée et donc ajouter une propriété HeureA et DateA.

Je suppose que dans le cas simple, un passager est muni d’un billet et embarque une seule fois.

Oui dans ce cas ci.

En cas d’escales, je suppose que le passager est toujours porteur d’un seul billet, mais ce dernier fait-il mention de ces escales ?

Sur le billet, il est fait mention des vols que le passager devrait prendre pour arriver à destination.
Par ex, le passage se munit d'un billet pour aller à ORLY depuis toulouse et sur ce billet on détaille les vols qu'il doit prendre.

Association ACHETER : selon les cardinalités, BILLET est en relation avec N passagers et un passager est en relation avec un seul billet : c’est un billet de groupe ?

Non

[Soutou]

Sans revoir tout le problème depuis le début et sans vouloir affiner ton MCD initial qui mettait en oeuvre un agrégat, le principal problème est qu'aucun outil ne comprend le concept d'agrégat issu d'extensions de modèle E/A.

Alors qu'UML le traduit à l'aide de classes-associations, il faut avec Merise utiliser souvent le concept d'identification relative (entités faibles) qui n'est pas très simple.
Souvent aussi, il suffit d'utiliser correctement des ternaires en y ajoutant éventuellement des contraintes.

C'est bon snopoo, tu as toutes tes réponses?

[fsmrel]

Bonjour Snoopo,

Si j’interprète la règle 1 et l’exemple qui l’accompagne, il apparaît que le vol (exemple " AF105") a lieu à une heure unique, indépendamment de la date et du reste : ceci se traduit par une contrainte d’unicité appelée dépendance fonctionnelle :

_____DF1 : {N°Vol} -> {HeureDépart} _____(Un vol a toujours lieu à la même heure)

{N°Vol} est appelé le déterminant et {HeureDépart} le dépendant.

{N°Vol} -> {HeureDépart} se lit ainsi : {N°Vol} détermine fonctionnellement {HeureDépart}, ou encore {HeureDépart} est déterminé par {N°Vol} (ou plus simplement {N°Vol} flèche {HeureDépart}).

Les crochets encadrant les noms des attributs sont là pour signifier qu’une dépendance fonctionnelle a lieu entre ensembles (au sens de la théorie des ensembles) d’attributs. Quand ces ensembles sont des singletons on peut faire l’économie des crochets dans la mesure où il n’y a pas d’ambiguïté et que l’on continue à parler d’ensembles :

_____N°Vol -> HeureDépart

La dépendance fonctionnelle est le marteau à casser rationnellement les tables, les normaliser et éviter ainsi les anomalies lors des opérations de consultation et de mise à jour.

Je vous conseille la discussion suivante pour étudier de plus près les dépendances fonctionnelles, les clés candidates et la normalisation :

http://www.developpez.net/forums/sho...d.php?t=281221

Pour en revenir à l’interprétation de la règle 1 et l’exemple qui l’accompagne, il apparaît que le vol (exemple "AF105") détermine l’aéroport ("CDG") indépendamment de la date. Ceci fait l’objet d’une dépendance fonctionnelle :

_____DF2 : N°Vol -> CodeAeroport _____ (Un vol a toujours le même aéroport de départ)

De la même façon, on doit écrire noir sur blanc et traduire cela sous forme de DF, qu’un vol a une heure (théorique) d’arrivée et un seul aéroport d’arrivée (je suppose).

C’est ainsi que se construit l’entité-type VOL.

Concernant la date du vol : vous écrivez que la date est au format jj/mm/aaaa, exemple : 15/01/2007. Si l’on part du principe qu’un vol peut ainsi avoir lieu à des dates successives, N°Vol ne détermine donc pas DateVol :

_____N°Vol -/-> DateVol _____ (A Un vol correspondent plusieurs dates de départ)

D’où la nécessité d’une nouvelle entité-type DATEVOL (le terme DECOLLER ne me convient pas trop) ayant pour clé candidate le couple {N°Vol, DateVol}.

Les autres attributs de DATEVOL sont ceux qui dépendent nécessairement du couple {N°Vol, DateVol} et de celui-là seulement, par exemple le numéro de l’avion qui assure le vol, dans la mesure où ça n’est pas toujours le même avion qui est utilisé.

Cas du billet

Vous écrivez que le billet fait mention des vols empruntés par le passager. On peut supposer que, pour un voyage donné, le passager emprunte un ou plusieurs vols, à des dates précises, donc que la relation à établir est entre BILLET et DATEVOL (relation SEGMENT, cardinalité M-N).

A son tour, le passager est le détenteur du billet. Sous réserve de précisions supplémentaires de votre part, le MCD (ou plutôt le MLD pour les merisiens) commencerait à prendre l’allure de celui qui est fourni en PJ.

[fsmrel]

Bonsoir,

A propos de l’agrégat :

Alors qu'UML le traduit à l'aide de classes-associations, il faut avec Merise utiliser souvent le concept d'identification relative (entités faibles) qui n'est pas très simple.

Merci de dresser le catalogue des difficultés engendrées par l’identification relative et la mise en œuvre des entités-types faibles.

Souvent aussi, il suffit d'utiliser correctement des ternaires en y ajoutant éventuellement des contraintes

Merci de montrer formellement à quoi on reconnaît l’utilisation correcte des relations ternaires. Qu'entendez-vous par "correcte" ? De quelles contraintes parlez-vous ?

[Soutou]

Salut

C'est que je n'ai ni le temps, ni l'énergie de le faire ici. Je ne réponds que ponctuellement sur les forums et il n'est pas question pour moi de faire un cours ou élaborer de grandes théories.

Pour les interéssés il faudra se procurer :

http://www.editions-eyrolles.com/Liv...ses-de-donnees

Mais tes écrits sont très intéressants même si je n'ai pas le temps de me poser dessus. A bientôt

[snoopo]

salut fsmrel,
merci encore pour votre aide. En tous cas ça m'a permis de mieux comprendre comment concevoir un mcd.

[fsmrel]

Bonjour Snoopo,

Je suis heureux d’avoir pu vous apporter quelques éclaircissements, même si tout n’est pas forcément évident. Je pensais que Soutou s’expliquerait à propos de ce qu’il voulait dire initialement, mais comme tel ne sera semble-t-il pas le cas, je m’y colle.

De l’identification relative

L’identification relative permet de transformer en entité-type une propriété multivaluée d’une autre entité-type. Par exemple, comme les lignes de commande constituent une propriété multivaluée de l’entité-type Commande, il est possible de "sortir" ces lignes de la commande pour en faire une entité-type LigneCommande et d’établir une relation 1-N/1,1 avec Commande. Mais LigneCommande n’a pas d’existence propre, elle n’existe que par Commande qui l’a engendrée : elle hérite de l’identifiant de cette dernière. Si donc Commande a pour identifiant, disons, CommandeId, LigneCommande aura pour identifiant le couple {CommandeId, LigneCommandeId}, où l’attribut LigneCommandeId a pour fonction de garantir l’unicité des lignes d’une commande au sein d’une commande donnée, en complément de l’élément d’identification générique, CommandeId (ce qui est vrai aussi quand les lignes de commande restent dans le sein maternel).
LigneCommande n’existant qu’au travers de Commande, on dit qu’elle est une entité-type "faible" (weak entity) ou encore qu’elle est une caractéristique (characteristic) de Commande. Il va de soi qu’une entité-type faible peut engendrer d’autres entités-types faibles, lesquelles à leur tour... Par exemple, une ligne de commande peut engendrer des engagements sur ligne de commande, lesquels peuvent à leur tour engendrer des livraisons, etc.
Par contraste, des entités-types telles que Client ou Produit qui ne dépendent d’aucune autre entité-type sont dite fortes (ou autonomes, indépendantes, régulières, ...), on peut encore les appeler à la façon de Codd des noyaux (kernels)
Une entité-type faible peut être mise en relation avec tout autre type d’entité : Si Produit est une entité-type forte, rien n’interdit de mette LigneCommande en relation avec celle-ci (au sens de Codd, LigneCommande ne caractérise pas, mais désigne Produit.

A noter que l’on peut envisager de considérer la commande comme propriété du client et d’en faire une entité-type faible à son tour : un moyen de se décider consiste à vérifier si oui ou non, la suppression d’un client entraîne celle de ses commandes (il est par ailleurs évident que la suppression d’une commande entraîne celle de ses lignes). Un autre élément de réflexion : une commande peut elle changer de client ?

Les AGL permettent de prendre en compte l’identification relative de façon très simple. Par exemple, PowerAMC affiche en conséquence les cardinalités 1-1 entre parenthèses dans le MCD ci-dessous :

_____

Dans ce MCD, on pourra noter que le numéro de commande (CommandeNo), connu de l’utilisateur, est un point d’entrée dans le système pour celui-ci et fait l’objet d’un identifiant alternatif.

Au niveau MLD, on voit bien l’enrichissement progressif des clés primaires :



Il va de soi qu’au niveau tabulaire, pour traduire le métabolisme de la relation entité-type faible - entité-type forte, on utilise l’effet Cascade pour l’intégrité référentielle, puisqu’une propriété (par exemple LigneCommande) ne peut pas s’opposer à la suppression d’une occurrence de l’entité qui la porte (Commande) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
create table CLIENT (
   ClientId             int                  not null,
   ClientNom            char(32)             not null,
   ...                  ...                  ...,
   constraint Client_PK primary key  (ClientId)
)
go

create table COMMANDE (
   ClientId             int                  not null,
   CommandeId           int                  not null,
   CommandeNo           int                  not null,
   CommandeDate         datetime             not null,
   ...                  ...                  ...,
   constraint Commande_PK primary key  (ClientId, CommandeId),
   constraint Commande_AK1 unique (CommandeNo),
   constraint ComCli_FK foreign key (ClientId)
      references CLIENT (ClientId)
         on delete cascade
)
go

create table PRODUIT (
   ProduitId            int                  not null,
   ProduitNom           char(32)             not null,
   PrixHT               decimal(16)          not null,
   ...                  ...                  ...,
   constraint PK_PRODUIT primary key  (ProduitId)
)
go

create table LIGNECOMMANDE (
   ClientId             int                  not null,
   CommandeId           int                  not null,
   LigneCommandeId      int                  not null,
   ProduitId            int                  not null,
   Quantite             int                  not null,
   ...                  ...                  ...,
   constraint LigneCommande_PK primary key  (ClientId, CommandeId, LigneCommandeId),
   constraint LigneCom_FK foreign key (ClientId, CommandeId)
      references COMMANDE (ClientId, CommandeId)
         on delete cascade,
   constraint LigneProd_FK foreign key (ProduitId)
      references PRODUIT (ProduitId)
         on delete cascade
)
go

create table ENGAGEMENT (
   ClientId             int                  not null,
   CommandeId           int                  not null,
   LigneCommandeId      int                  not null,
   EngagementId         int                  not null,
   Quantite             int                  not null,
   ...                  ...                  ...,
   constraint Engagement_PK primary key  (ClientId, CommandeId, LigneCommandeId, EngagementId),
   constraint EngLigne_FK foreign key (ClientId, CommandeId, LigneCommandeId)
      references LIGNECOMMANDE (ClientId, CommandeId, LigneCommandeId)
         on delete cascade
)
go

Identification relative et performance

A ce stade, on ne devrait pas encore parler de performance. Je ferai quand même observer ceci : L’attribut générique des clés des tables dérivées des entités faibles (en l’occurrence ClientId) permet de regrouper les commandes d’un client donné dans une même page physique, même chose pour les lignes et les engagements. Cela veut dire que si les tables ne sont pas désorganisées, le débit des lectures de pages est optimal, puisque cette lecture peut être rendue synchrone avec celle des pages de l’index "primaire" et réduit au mieux (ce qui est fort utile pour les traitements batchs). Dans le jargon, on dit alors qu’on est plutôt CPU bound qu’I/O bound. Dans l’exemple ci-dessus, seuls les accès à la table Produit (récupération par exemple du nom du produit) pourraient être source de ralentissement, par accroissement de l’effet I/O bound.

Des associations ternaires

Reprenons votre association ternaire :

_____Decoller (N°Vol, DateVol, CodeAeroport)

Pour résumer les avanies que cette association a subies, on s’était servi des dépendances fonctionnelles (DF) traduisant des règles de gestion de données exprimant des contraintes d’unicité.

Pour compléter, en considérant non plus l’association, mais la table Decoller qui en est issue et en s’appuyant sur la théorie relationnelle, il faut s’assurer des dépendances fonctionnelles et des clés candidates de cette table.

Les clés candidates sont obtenues à partir des DF.
Pour mémoire, la définition d’une clé candidate n’est pas exactement celle d’un identifiant...

Soit T une table ; soit U l’ensemble composé de tous les attributs de T et X un sous-ensemble (non nécessairement strict) d’attributs de T. X est une clé candidate de T si :

1) X -> U _____ (règle d’unicité).

2) Il n’existe pas Y strictement inclus dans X, tel que Y -> U _____ (règle d’irréductibilité).

Or, comme on l’a vu jeudi dernier, il existe la DF :

_____N°Vol -> CodeAeroport

qui fait que le triplet {N°Vol, DateVol, CodeAeroport} viole la règle d’irréductibilité et ne peut être clé candidate, contrairement au couple {N°Vol, DateVol} (en notant que N°Vol ou DateVol seuls ne permettent pas pour leur part de garantir la règle d’unicité).

La table Decoller est caractérisée par les DF suivantes (entre autres) :

_____{N°Vol, DateVol} -> CodeAeroport
_____N°Vol -> CodeAeroport

Cette dernière signifiant en passant que la BCNF n’est pas respectée,
cf. le message fsmrel du 20/02/2007, 12h36, sujet "Unicité d'une clef composée" :

http://www.developpez.net/forums/sho...d.php?t=281221

La table (donc l’association) Decoller "vole" (sic) alors en éclats. On aboutit au résultat figurant dans la pièce jointe du message du 22/03/2007, 17h57.