Discussion :

[Souplixx]

Bonjour,
j'essaye dans un premier temps de réaliser un modèle E/A pour le sujet suivant :

Les organisateurs d'une course de bateaux voudraient créer une base de données permettant de retrouver toutes les informations relatives à l'organisation de la course et à sa sécurité et aussi répondre à la curiosité des badauds.

La course se déroule en plusieurs épreuves sanctionnées chacune par un classement. Chaque épreuve débute et se termine dans un port, sachant que le port d'arrivée pouvant être différent du port de départ
Cependant il n'y a jamais plus d'une épreuve par jour.
Chaque bateau est financé par un ou plusieurs sponsors et armé d'un équipage composé d'un skipper et d'équipiers.
Le skipper d'un bateau ne peut changer d'une épreuve à l'autre de la course, mais cette contrainte ne touche pas les équipiers, qui en revanche peuvent changer de bateau au cours d'une épreuve.
La base de données doit permettre de répondre, parmi d'autres, aux questions suivantes:

Quels sont les sponsors d'un bateau ?
Quel est le montant de la subvention d'un sponsor particulier à un bateau particulier ?
Quels bateaux sont engagés dans l'épreuve qui débute le 27 avril ?
Quels sont les équipiers du bateau qui a gagné la première épreuve ?
Sur quels bateaux de plus de 12 mètres y a-t'il un équipier médecin ?
Quel est le classement du bateau numéro 2 à la première épreuve?
Quel est le classement général d'un navigateur particulier?
A quel prix la chaine numéro 2 A t'elle retransmit la première épreuve?

Je débute dans le domaine des bases de données et j'aimerais votre avis sur le modèle que vous trouverez ci-joint.

[fsmrel]

Bonsoir Souplixx,


Il faudrait que vous confirmiez la signification des associations.

Ce que je comprends de l’association FINANCER :

Un sponsor finance de 0 à N bateaux, tandis que pour un bateau on peut avoir de 0 à N sponsors (il peut donc y avoir des bateaux non financés).
Chacun des sponsors participant au financement d’un bateau donné le fait pour un certain montant.

Ce que je comprends de l’association SIGNER :

Un sponsor donné signe (s’engage ?) à différentes dates (de signature) pour on ne sait quoi en rapport avec un certain ensemble de bateaux.

Un bateau donné est concerné par au moins une signature, à des dates données, de la part d’un ensemble de sponsors : selon le MCD tous les sponsors doivent signer mais tous ne sont pas obligés de financer.

Cela dit, on ne voit aucune relation ou contrainte entre les signatures et les financements. Hum...

N.B. Quel rôle joue la date de fin dans l’entité-type DATE ?

Toutes choses égales, peut-on comparer l’organisation de votre course de bateaux (annuelle ? bisannuelle ? ...) à celle du Tour de France en ce qui concerne les épreuves : une épreuve est-elle comparable à une étape ? A ceci près qu’un bateau ne se transporte pas comme un vélo, autrement dit (excepté pour la 1re étape épreuve), le port d’arrivée d’une épreuve est-il aussi le port de départ de l’épreuve suivante ?

Le même jour il ne peut pas y avoir plus d’une épreuve, mais quelle est la fréquence des épreuves de la course ? (quotidienne ? hebdomadaire ? etc.) Quelle est la durée des épreuves ? (un jour, plus ?)


Entité-type EPREUVE (nom au singulier, car un nom d’entité-type est aussi un nom de prédicat) : l’identifiant est composé du couple {NomEpreuve, DateEpreuve} : La date ne suffit pas ? Avez-vous des exemples de noms d’épreuves ?


Je suppose que le classement d’un bateau à l’occasion d’une épreuve est indépendant des équipiers, c'est-à-dire que ceux-ci héritent du classement du bateau. Dans cette hypothèse, l’attribut classement (cf. l’association EstComposé) ne vaut que pour le couple {BATEAU, EPREUVE} et n’est pas à sa place dans la ternaire. Par ailleurs, selon l’association EstComposé, suite à une épreuve donnée, les équipiers d’un même bateau n’ont pas forcément tous la même rémunération. C’est bien cela ?

Sur quels bateaux de plus de 12 mètres y a-t-il un équipier médecin ?

La question n’a pas de réponse, car s’il est facile de savoir qu’un équipier est médecin (il suffit en effet de prévoir un booléen ad-hoc dans l’entité-type NAVIGATEUR), étant donné que les équipiers peuvent changer de bateau au fil des épreuves, au mieux peut-on répondre qu’à l’occasion de telle épreuve il y avait un équipier médecin à bord de tel bateau.

[Souplixx]

Bonjour,

Pour la signification de l'association FINANCER,celle-ci est correcte.
Effectivement,maintenant que vous me le dites j'ai l'impression que financer et signer sont à peu près pareil... Dans ce cas la je ne devrais garder que SIGNER (qui permet de faire signer un bateau avec un sponsor pour une durée déterminée) ?

Pour l'entité EPREUVE, seul la date est suffisante donc c'est à corriger.

J'ai mis l'attribut classement dans la relation ternaire pour permettre d'avoir le classement d'un bateau pour les épreuves mais aussi le classement de chaque équipier pour chaque épreuve (une sorte de classement global).

L'attribut Date_Fin permet d'avoir la fin du contrat qui lie un bateau avec un sponsor. A priori,pensez vous que celle-ci est inutile ?


Pour la rémunération effectivement, je dissocie la rémunération du skipper (capitaine),des autres équipiers.


Je prend note pour la dernière question qui doit être enlevée...

Merci beaucoup,avez vous d'autres suggestions pour améliorer mon travail ?

[fsmrel]

Bonsoir Souplixx,

je ne devrais garder que SIGNER (qui permet de faire signer un bateau avec un sponsor pour une durée déterminée) ?
...
L'attribut Date_Fin permet d'avoir la fin du contrat qui lie un bateau avec un sponsor. A priori, pensez-vous que celle-ci est inutile ?

Je ne dis pas que la date de fin est inutile, mais elle n’est pas à sa place. Là où elle est, elle ne joue aucun rôle dans l’association.

Quand un sponsor signe, est-ce pour une période donnée ou pour plusieurs périodes ?

On reviendra sur le montant du financement quand auront été entérinées les règles relatives aux signatures.

J'ai mis l'attribut classement dans la relation ternaire pour permettre d'avoir le classement d'un bateau pour les épreuves mais aussi le classement de chaque équipier pour chaque épreuve (une sorte de classement global).

De façon elliptique, vous confirmez que lorsque le bateau B1 a obtenu le classement C1 lors de l’épreuve E1, chaque équipier qui était à bord hérite du classement C1. L’association EstComposé viole en l’occurrence la règle merisienne de normalisation, selon laquelle, je cite l’ouvrage de référence de Tardieu, Rochfeld, Colletti : La méthode Merise, Tome 1 : Principes et outils :

« La normalisation permet de s’assurer que chacune des propriétés ne peut être vérifiée sur un sous-ensemble de la collection de la relation-type »

Pour la rémunération effectivement, je dissocie la rémunération du skipper (capitaine),des autres équipiers.

C’est bien ce que dit votre diagramme, mais ma question portait uniquement sur les équipiers. Je repose donc ma question :

A l’occasion de l’épreuve E1, les équipiers (non skippers) qui sont à bord du bateau B1 auront-ils tous, réglementairement, la même rémunération ?

Question subsidiaire :

Cette rémunération dépend-elle du classement de B1 à l’occasion de E1 ?

[Souplixx]

Signer

Pour moi un sponsor signe pour plusieurs périodes non fixées à l'avance ( par exemple,signer un contrat pour une course en particulier qui sera particulièrement médiatisé).
C'est ce qui m'a encouragé dans l'utilisation d'une relation ternaire (après tout pour un bateau et un sponsor donné on peut avoir différentes contrats de sponsoring).
Je ne comprends pas pourquoi la date de Fin n'aurait aucun role à jouer. Elle permet de caractériser la fin du contrat de sponsoring.
Par exemple,un bateau numéro i aurait un contrat de sponsoring avec la société X de 2007-2010 et enfin de 2012-2014.

Classement:

Si je viole la règle de normalisation en laissant le classement être vérifié par bateau et navigateur que me proposez vous de faire ?
De créer une autre relation entre navigateur et épreuves pour avoir accès au classement propre du navigateur ?
J'étais parti sur ca à l'origine avant de réaliser que ca serait en quelques sorte un doublon !
Désolé de mal m'exprimer mais pour moi le formalisme que requiert les bases de donnés est encore bien difficile pour moi...

Rémunération
Enfin, effectivement j'etais parti pour une rémunération identique pour tous les équipiers (à part le skipper).
Si je décide d'en faire une variable en fonction du poste,je dois créer une nouvelle entité appelé rémunération (je pense que ca collerait plus à la réalité) ?
Mais dans ce cas la, proposer une rémunération proportionnelle au classement me semble bien trop compliqué...enfin j'ai du mal à voir comment le modéliser...

Merci pour vos réponses constructives

[fsmrel]

Bonsoir Souplixx,

sponsor donné on peut avoir différentes contrats de sponsoring).
Je ne comprends pas pourquoi la date de Fin n'aurait aucun rôle à jouer. Elle permet de caractériser la fin du contrat de sponsoring.
Par exemple, un bateau numéro i aurait un contrat de sponsoring avec la société X de 2007-2010 et enfin de 2012-2014.

La date de fin a évidemment un rôle à jouer, mais ce que j’ai dit, c’est que selon votre modélisation elle ne joue pas son rôle : l’attribut Date_Fin doit en fait passer de l’entité-type DATE à l’association SIGNER :



A moins d’une contre-indication de votre part, je propose d’intégrer le montant à l’association SIGNER.

Dans ces conditions, je représente les choses ainsi au niveau tabulaire (diagramme avec MySQL Workbench, c’est quand même plus simple !) :



Les petites clés jaunes symbolisent les clés primaires des tables. Ainsi, la clé primaire de la table SIGNER est le triplet {BateauId, SponsorId, DateDebut}. La date de fin est bien présente, mais elle ne participe pas à la clé (pour un bateau et un sponsor donnés, à une date de début donnée il n’y a qu’une date de fin).

Attention, les cardinalités sont celles d’UML, donc leur placement est inverse de celui qui est le leur dans les MCD merisiens.


Concernant les épreuves et les navigateurs :





Un navigateur est soit un skipper, soit il fait partie de l’équipage de tel bateau à l’occasion de telle épreuve. Le classement des membres d’un équipage est celui du bateau dans cette épreuve, et leur rémunération est déterminée de la même façon.

Si la rémunération des équipiers ne dépend pas des épreuves, l’attribut Remuneration migrera vers la table BATEAU.

Vous noterez qu’il y a une bijection entre BATEAU et SKIPPER : les attributs du skipper (sa rémunération, mais aussi son nom, son prénom et sa date de naissance pourraient migrer dans la table BATEAU, et donc la table SKIPPER disparaître : la table NAVIGATEUR pourrait alors prendre le nom d’EQUIPIER).

Est-ce que cette approche vous convient ?

N.B. Si tel ou tel message vous a apporté quelque chose, n’oubliez pas de voter...

[Souplixx]

Bonjour,

Voici les modifications que j'ai apporté au modèle entité/association :

1)Suppression de l'association FINANCER et modification de l'association SIGNER

2) L'entité Epreuve est modifié en remplacant Nom_Epreuve par EpreuveID.

3 Modification des relation entre Bateau et Epreuve mais plusieurs choses m'échappent notamment l'introduction d'une entité Equipage?
Le modèle que vous proposez est un schéma relationnel non ? je dis ca parceque c'est la prochaine étape de mon travail.. Après avoir fait un modèle entité association correcte (je vais essayer de rajouter d'autres choses parce que je le trouve encore un peu pauvre) je devrais passer au modèle relationnel et donc justement considérer les simplifications que vous me proposez dans votre dernier post....


NB: Je n'avais pas vu le système de vote,en tout cas vous m'êtes d'une très grande utilité,je vous remercie encore une fois...

[fsmrel]

Bonsoir Souplixx,

Suppression de l'association FINANCER et modification de l'association SIGNER

D'accord.

L'entité Epreuve est modifiée en remplaçant Nom_Epreuve par EpreuveID.

L’entité-type EPREUVE est identifiable par la date d’épreuve. Dans ces conditions, quel rôle est dévolu à l’attribut EpreuveID ?

A signaler que selon votre diagramme, l’identifiant de l’entité-type EPREUVE devient la paire {EpreuveID, DateEpreuve} mais étant donné que le singleton {DateEpreuve} suffit pour identifier l’entité-type, cette paire vient en fait ficher la patouille.

Le modèle que vous proposez est un schéma relationnel non ?

Oui, c’est ce que j’avais signifié :

je représente les choses ainsi au niveau tabulaire (diagramme avec MySQL Workbench, c’est quand même plus simple !)

J’avais expliqué que les choses y étaient moins compliquées. En effet, en Merise pur c’est la galère (pour rester dans le monde naval...) car les associations d’associations n’y sont pas autorisées :





C’est devenu possible en OOM (Orientation Objet dans Merise, cf. l’ouvrage de M. Bouzeghoub, G. Gardarin, P. Valduriez, paru en 1994 : Les objets), mais hélas, c’était déjà un peu tard... Je cite :




Pourtant, au début des années quatre-vingt-dix, José Morejon n’hésitait pas à le faire (cf. son ouvrage Principes et conception d’une base de données relationnelle, voyez la discussion avec Betanaelle.

Bref, il ne nous reste plus qu’à déguiser l’association PARTICIPATION ci-dessus en entité-type, et cette fois-ci on peut établir la relation EQUIPER entre NAVIGATEUR et PARTICIPATION :




Dans le diagramme ci-dessus, l’entité-type PARTICIPATION est identifiée relativement à BATEAU et EPREUVE (notation PowerAMC : les cardinalités 1,1 sont mises entre parenthèses). Suite à dérivation par PowerAMC, on obtient le MLD suivant :




Ce MLD est équivalent au diagramme MySQL Workbench que je vous avais présenté hier (où j’ai renommé EQUIPER en EQUIPAGE...)



Le but de la manœuvre est de ne pas perdre de temps dans la déclaration des tables au stade SQL, mais encore faut-il que nous nous mettions d'accord sur le MLD qui va bien...



Je note que votre association PARTICIPE est toujours fautive, je rappelle donc ce que j’ai écrit au sujet de la normalisation au sens Merise :

De façon elliptique, vous confirmez que lorsque le bateau B1 a obtenu le classement C1 lors de l’épreuve E1, chaque équipier qui était à bord hérite du classement C1. L’association EstComposé viole en l’occurrence la règle merisienne de normalisation, selon laquelle, je cite l’ouvrage de référence de Tardieu, Rochfeld, Colletti : La méthode Merise, Tome 1 : Principes et outils :

« La normalisation permet de s’assurer que chacune des propriétés ne peut être vérifiée sur un sous-ensemble de la collection de la relation-type »

Hardi les gars ! Vire au guindeau, good bye Farewell !

[Souplixx]

Bonjour,
voila les modifications... Qu'en pensez vous ? Si j'ai bien compris ici vous switchez une relation ternaire par 3 relations binaires... j'avoue que j'ai du mal à comprendre mais je vais faire un effort et essayer...
Le modèle entité association est t'il dans ce cas correct ?

[fsmrel]

Bonsoir Souplixx,

Si j'ai bien compris ici vous switchez une relation ternaire par 3 relations binaires... j'avoue que j'ai du mal à comprendre.

En réalité, je remplace une association par une entité-type, procédé ad-hoc vieux comme Merise, dès lors qu’il est interdit au nom du dogme de connecter deux associations.

Un AGL comme PowerAMC n’est pas en reste et veut bien s’en charger. Ainsi, pour changer l’association PARTICIPER en entité-type, il suffit de cliquer sur cette association :






Et, ô magie, l’AGL effectue tout seul le changement, comme un grand :







Et il ne nous reste plus qu’à brancher EQUIPER et PARTICIPER, en toute légalité...

Vous noterez que l’AGL a utilisé l’identification relative (cardinalités 1,1 mises entre parenthèses comme je l'ai déjà signalé), c'est-à-dire que l’identifiant de PARTICIPER est de facto la paire {BateauId, EpreuveDate}. Après branchement de PARTICIPER et de l’association EQUIPER, l’identifiant de cette dernière sera donc le triplet {BateauId, EpreuveDate, NavigateurId}.

Pour mémoire, chacun a sa notation pour l’identification relative.

A la façon de PowerAMC, donc :





Dans le style WinDesign (voir aussi la FAQ Merise) :





A la Peter Chen (père du modèle Entité-Association) :





Dans le style Open ModelSphere, la cardinalité 1,1 est soulignée :



Dans le style IEF :




Extrait du document AFCET Journée du 15 novembre 1990 - Le formalisme de données Merise : extensions du pouvoir d’expression :



Etc.

Il vous reste à voir comment procéder avec l’outil que vous avez utilisé, car en l’absence d’un mécanisme d’identification relative, votre table PARTICIPATION n’a pas d’identifiant, ce qui est évidemment une erreur...

[Souplixx]

J'utilise JMerise pour créer mon modèle E/A et je dois vous avouer qu'il me convenait jusqu'a maintenant parcequ'il est vraiment très simple d'utilisation
Cependant,en cherchant sur Internet j'ai du mal a trouver comment faire pour faire une identification relative sur JMerise ce qui me contrarie un peu... Je pensais comprendre un peu les bases de données mais je me rends compte que je suis encore loin du compte

J'ai l'impression que je me perds en complexité et que je vais avoir du mal à proposer un bon schéma relationnel par la suite parceque je comprends bien les entités maintenant que dans mon premier modèle
Y a t'il un moyen de se passer de l'dentification relative ?

[fsmrel]

Histoire de voir ce que ça donne, vous pouvez créer un identifant bidon pour l'entité-type PARTICIPATION, on l'enlèvera au niveau MLD (ou SQL), je ne sais pas ce que génère JMerise.

[Souplixx]

Bonsoir, j'ai rajouté un attribut à Participation.
Dernière question,les 2 relations qu'on a crée prendront quels noms ? Je n'arrive pas a trouver un verbe qui collerait avec la modélisation...
Le modèle E/A est t'il maintenant correct ?

[fsmrel]

Bonsoir,

J'ai rajouté un attribut à Participation.

Vu. Il s’agit donc de l’identifiant provisoire (dans le MLD il dégagera).


A propos d’identifiants, il faut en définir un (non significatif, invariant) pour chaque entité-type qui en est encore dépourvue : « BateauId » pour l’entité-type BATEAU, etc. (EPREUVE peut être dispensée...)

Pour les noms des dernières associations, ne vous prenez pas la tête avec ça, les auteurs en font des CIF. Appelez-les par exemple PART_BAT et PART_EPR...

Sinon, ça prend forme. Il y aura probablement des surprises avec les skippers, mais on reparlera (par exemple le coup de la bijection, houle en prévision, un classique).

Tentez un 1re dérivation du MCD.

[Souplixx]

Bonjour,
Je vais faire toutes les modifications.
Dans un premier temps,je vais lister toutes les entités et les associations pour voir si déjà nous sommes d'accord sur leur utilité respective.
Enfin,je ferais le modèle relationnel et procéderait aux différentes simplifications possibles (dénormalisation entre autres)
L'avantage que propose JMerise est de générer le schéma relationnel automatiquement mais je préfére le faire à la main pour mieux comprendre....

[Souplixx]

Bonsoir,
J'arrive ce soir avec un certain nombre de questions. Je vais donc essayer d'être le plus clair possible pour que vos réponses soient ciblées.

Je vous met en pièce jointe mon interprétation des entités et des relations dans le modèle avec mes hypothèses de modélisation.
entite-association.pdf
J'ai plusieurs questions à ce propos:

1) Je n'arrive toujours pas à comprendre pourquoi la dateFin de contrat peut être dans la relation signer. J'ai plusieurs exemples en tete de modèle ou on retrouve la date de Fin dans l'entité Date et ca m'avait l'air logique....

2) Les relation partBat et partEpreuve sont encore obscures pour moi...
Si j'ai bien compris,vous avez refusé ma première approche avec une relation ternaire du modèle parce que le classement des navigateurs était hérité par le bateau et cela brisait un axiome de la modélisation ?
Mais dans ce cas,en quoi faire le changement que vous avez fait permet de retomber sur nos pattes ?

3) Vous avez parlé d'introduire des Id pour l'ensemble des entités qui n'en contenaient pas mais je ne vois pas l'utilité. Du moment que je justifie dans mes hypothèses de modélisation,le caractère unique des clés pour chaque entité je peux me passer d'introduire un attribut en plus non ?

4)Vous trouvez ci joint mon nouveau diagramme E/A avec certains changements:

- rajout d'un attribut typeEpreuve pour l'entité Epreuve (courses de vitesse,endurance etc..)
-rajout d'un attribut taillePort pour l'entité Port

4) Enfin,j'aimerais avant de passer au schéma relationnel étoffer un tout petit peu mon schéma en me focalisant sur la partie retransmission de la course.
J'ai pensé à rajouter un attribut audience à la relation retransmettre pour récupérer l'audience réalisé à l'issu de la retransmission de l'épreuve...
Mais je cherche une autre idée afin d'inclure une entité spectateur ou meme site internet qui commente l'epreuve ou quelque chose dans le même genre....
Pensez-vous que c'est une bonne idée ou que je laisse le modèle tel que ?

Voila tout pour ce soir..
Merci de me suivre de façon très assidu

[fsmrel]

Bonjour Souplixx,


Je vous répondrai point par point, mais je suis actuellement sur plusieurs fronts.

Dans cette 1re partie, traitons déjà de la date de fin de contrat.

Je n'arrive toujours pas à comprendre pourquoi la dateFin de contrat peut être dans la relation signer.

Revenons sur votre tout 1er diagramme, dans lequel l’en-tête de la pseudo entité-type DATE contient l’attribut DateFin :



Partant de là, considérons l’exemple suivant (les identifiants sont soulignés) :

Code :

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

1
2
3
4
 
BATEAU {nomBat            typeBat       tailleBat}
        L’écho des îles   catamaran     10 m
        La Marie-José     catamaran     12 m

Code :

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

1
2
3
4
 
SPONSOR {nomSponsor    typeSponsor}
         Volfoni       entreprise
         Naudin        entreprise

Code :

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

1
2
3
4
5
 
DATE {DateDebut    DateFin}
      2010_05_01   2010_05_21
      2010_05_15   2010_05_27
      2012_04_18   2012_12_31

Selon Merise, il faut voir l’en-tête de SIGNER comme étant composé :

1) Des attributs qui sont les images des identifiants des entités-types connectées (BATEAU, SPONSOR, DATE). Ces attributs composent l’identifiant de SIGNER ;

2) Des attributs portés par SIGNER.

Exemple d’instances de SIGNER :

Code :

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

1
2
3
4
5
6
 
SIGNER {nomBat            nomSponsor   DateDebut     montant}
        L’écho des îles   Volfoni      2010_05_01    50000
        L’écho des îles   Volfoni      2012_04_18    10000
        L’écho des îles   Naudin       2012_05_15    10000
        La Marie-José     Volfoni      2012_05_15    20000

La date de fin ne participe pas au jeu, sinon, il n'y a aucune raison pour que les attributs typeBat, tailleBat et typeSponsor n'en fassent autant...

Par ailleurs, DATE n’est qu’une pseudo-entité-type, conséquence du dogme merisien selon lequel les attributs portés par une association n’ont pas le droit de participer à l’identification d’icelle.

Si l’on fichait ce dogme idiot à la poubelle, alors on pourrait modéliser ainsi (comme dans le cas de DB-MAIN (Université de Namur) ou, à la manière de Ted Codd, père du Modèle relationnel de données, dans Extending the Database Relational Model to Capture More Meaning, en considérant SIGNER comme une entité-type associative) :



Où l'attribut dateDebut participe de plein droit à l'identification de SIGNER.

Voyez-vous là une prétendue entité-type DATE (qui n’intéresserait guère que Chronos ) ?


N.B. l’attribut DateFin ne participe pas à l’identifiant, sinon pour un bateau, un sponsor et une date de début donnés, on pourrait avoir plusieurs date de fin et autant de montants.

[Souplixx]

Merci beaucoup c'est plus clair maintenant
Donc plus de problèmes pour date_Fin
Merci de passer autant de temps à me réexpliquer certaines notions ! On va y arriver !

[MacFly58]

Bonjour à tous, et ravi de vous revoir Fsmrel !


Le dernier MCD de Fsmrel (voir pièce jointe) propose une nouvelle façon de modéliser certaines associations-types qui est intéressante, mais qui pose de nouveaux problèmes aux Merisiens :

- L'identifiant de l'entité-type associative "SIGNER" semble être "datedébut", or ce n'est pas le cas. Cela peut poser un problème de lecture du MCD pour un néophyte, et donc de contrarier l'un des principaux buts du MCD, qui est un outil de communication. Si vous souhaitez écrire l'identifiant complet, alors on autorise une certaine redondance dans le MCD, ce qui sera très dommage. Cette redondance ne vient qu'avec le MLD pour gérer les contraintes d'intégrité référentielle, et c'est très bien ainsi.

- Une règle Merisienne nous dit en gros : "Un identifiant = une entité-type". Et cette règle est bien pratique pour savoir par exemple si les COMMANDES correspondent à un carré ou à un rond (présence d'un "n° de commande" dans le SI ou pas).



Une autre option est de transformer votre rond en carré et de faire une double identification relative, mais alors SIGNER devient un ensemble d'entités, ce qui posera un problème de sémantique en fonction du verbe utilisé.



En conclusion, l'entité-type Date n'est pas géniale mais je ne pense pas qu'on trouvera mieux ; bref c'est comme pour la démocratie, la république ou le capitalisme...

Croisons les doigts quand même

[fsmrel]

Bonjour Souplixx et Mac,


Je passe certes du temps à expliquer certaines choses, mais comme ça tout le monde peut en profiter (y compris si je me plante...) ^^

Vous avez parlé d'introduire des Id pour l'ensemble des entités qui n'en contenaient pas mais je ne vois pas l'utilité. Du moment que je justifie dans mes hypothèses de modélisation, le caractère unique des clés pour chaque entité je peux me passer d'introduire un attribut en plus non ?

Certes l’unicité est nécessaire, mais ça ne suffit pas dans l’univers impitoyable des bases de données ...

Il y a plus de 25 ans, un très grand de Merise, Yves Tabourier, a écrit ceci (De l’autre côté de MERISE, page 80), et c’est une règle d’or qui, si elle a plus de trente ans, reste malheureusement trop souvent méconnue :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Voyez par exemple ce message dans une discussion avec DarckCrystale.

J’ai vu trop souvent ces choses-là, qui m’ont permis de faire bien des audits dans les entreprises (et pas des moindres...) Quoi qu’il en soit, soyez sensible aux arguments de Tabourier mettez en œuvre des identifiants qui soient des invariants, donc sans signification aucune. Comme dit l’autre, celui qui a oublié le passé est condamné à le revivre...

Exemple(à éviter) avec des identifiants significatifs :




Ainsi, lors de la définition de la structure de l’entité-type NAVIGATEUR, au lieu d’avoir à instancier ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
NAVIGATEUR {NomNav     PrenomNav    age}
            Naudin     Fernand      24
            Volfoni    Raoul        31
            Champo     Maurice      34
            Hugo       Victor      212
            Dac        Pierre      120
            Blanche    Francis      92
            Kopa       Raymond      82 
            Jeantot    Philippe     61
            Kersauzon  Olivier      69
            Poupon     Philippe     59
            Le Cam     Jean         54

Si vous modélisez les identifiants conseillés, à la Tabourier :




Alors vous instancierez ainsi (au niveau SQL, vous laisserez vraisemblablement le SGBD incrémenter tout seul) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
NAVIGATEUR {IdNav  NomNav     PrenomNav    age}
            1      Naudin     Fernand      24
            2      Volfoni    Raoul        31
            3      Champo     Maurice      34
            4      Hugo       Victor      212
            5      Dac        Pierre      120
            6      Blanche    Francis      92
            7      Kopa       Raymond      82 
            8      Jeantot    Philippe     61
            9      Kersauzon  Olivier      69
            10     Poupon     Philippe     59
            11     Le Cam     Jean         54

Dans la version initiale, comme Raoul Volfoni est navigateur, son frère Paul ne pourra pas l’être, puisque NomNav est identifiant, alors qu’avec la 2e version ça n’est pas un problème (et ça évitera des conflits familiaux...) Si on s’est trompé dans l’orthographe du nom « Champo » et qu’il faille corriger en « Champeau », toujours avec la version initiale, il faudrait aussi modifier dans la base de données partout là où figure « Champo » (table PARTICIPER dérivée de l’entité-type du même nom), alors qu’avec la 2e version pas de problème non plus...

Association PARTICIPER

Partons donc sur la base d’identifiants stables, non significatifs et venons-en à la ternaire PARTICIPER en complétant l’exemple :

Code :

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

1
2
3
BATEAU {IdBat    nomBat            typeBat       tailleBat}
        1        L’écho des îles   catamaran     10 m
        2        La Marie-José     catamaran     12 m

(En notant que IdBat fera l'objet d'une clé candidate (alternative), unicité des noms des bateaux oblige).

Code :

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

1
2
3
4
EPREUVE {dateEpreuve}
         14/07/2010
         23/06/2011
         07/09/2013

Allons-y pour PARTICIPER, qui hérite des attributs identifiant les entités-types participant à l’association. Les équipiers de L’écho des îles à l’occasion de l’épreuve du 14/07/2010 sont les suivants : Naudin Volfoni, Dac, Jeantot, kersauzon, Hugo, Poupon, Kopa.

Code :

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

1
2
3
4
5
6
7
8
9
PARTICIPER {IdBat   dateEpreuve  IdNav    Classement  Remuneration}
            1       14/07/2010   1        5           1000
            1       14/07/2010   2        5           1000
            1       14/07/2010   4        5           1000
            1       14/07/2010   5        5           1000
            1       14/07/2010   7        5           1000
            1       14/07/2010   8        5           1000
            1       14/07/2010   9        5           1000
            1       14/07/2010   10       5           1000

Maintenant, à quoi sert d’apprendre 8 fois que L’écho des îles s’est classée 5e lors de l’épreuve du 14/07/2010 ? Autant de fois que la rémunération de ses équipiers fut de 1000 francs ? Supposons qu’il faille ajouter un attribut CteRendu, pour le compte-rendu : 8 fois on aura droit au même texte. Même chose pour chaque attribut supplémentaire qui serait ajouté à PARTICIPER. Imaginez qu’il ne s’agisse plus d’un équipage mais d’un régiment (entre 1000 et 2000 « équipiers ») ?

Une fois suffit donc :

Code :

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

1
2
PARTICIPER {IdBat   dateEpreuve   Classement  Remuneration}
            1       14/07/2010    5           1000

Suite à quoi on accroche les navigateurs aux participations ( rôle de EQUIPER) :




Pour pallier l’impossibilité de la mise en œuvre de l’identification relative avec JMerise (à vérifier quand même auprès de l’auteur), vous avez doté PARTICIPER d’un attribut identifiant ParticipationId. La situation est donc la suivante :

Code :

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

1
2
PARTICIPER {ParticipationId   IdBat   dateEpreuve   Classement  Remuneration}
            1                 1       14/07/2010    5           1000

Au niveau tabulaire, {ParticipationId} sera clé primaire de la table dérivée. Soit vous supprimerez cet attribut et la paire {IdBat, DateEpreuve} retrouvera son rôle de clé primaire, soit vous préférez le garder, auquel cas il ne faudra pas oublier de définir {IdBat, DateEpreuve} comme clé alternative (doublons interdits).

Supposons que vous conserviez ParticipationId, l’association EQUIPER donnera lieu à la table EQUIPER d’en-tête :

Code :

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

1
2
3
4
5
6
7
8
9
EQUIPER {ParticipationId   IdNav}
         1                 1      
         1                 2      
         1                 4      
         1                 5      
         1                 7      
         1                 8      
         1                 9      
         1                 10

Sinon :

Code :

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

1
2
3
4
5
6
7
8
9
EQUIPER {IdBat   dateEpreuve   IdNav}
          1      14/07/2010    1      
          1      14/07/2010    2      
          1      14/07/2010    4      
          1      14/07/2010    5      
          1      14/07/2010    7      
          1      14/07/2010    8      
          1      14/07/2010    9      
          1      14/07/2010    10

Remarque : Vous avez défini un attribut typeEpreuve dans l’en-tête de l’entité-type EPREUVE. Pour en contrôler les valeurs, il est d’usage de définir une entité-type telle que TYPE_EPREUVE :

[EPREUVE]—1,1--------( )--------0,N—[TYPE_EPREUVE]

Ce principe vaut pour des données telles que le type de bateau ou le type de sponsor.