IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

courses hippiques


Sujet :

Schéma

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2005
    Messages : 49
    Points : 39
    Points
    39
    Par défaut courses hippiques
    Bonjour,

    Je souhaite créer une base de données rendant compte des résultats des courses hippiques : rapports des jeux gagnants (jeux simple gagnant et simples placés ainsi que le quinté dans l'ordre et dans le désordre), performance du cheval, palmarès des trois acteurs que sont le jockey, l'entraîneur et le propriétaire.

    En me basant sur les excellents ouvrages de M. Christian Soutou ( De UML à SQL et UML2 pour les bases de données) j'ai réalisé le Modèle Conceptuel de Données suivant : Nom : MCD courses.JPG
Affichages : 4308
Taille : 142,2 Ko


    En simplifiant à l'extrême, voici les entités qui y sont rattachées:

    - Courses (courue dans un hippodrome (Hippodromes), caractérisée par une discipline (Disciplines)((trot ou galop), par le nom du prix (Prix)(ex : prix d'Amérique), par une distance (Distances)(ex : 1600 mètres) et par l'état du terrain (Terrains)(ex : terrain souple).

    - Simples et Quinte donnent les rapports des jeux gagnants.

    - Partants avec les attributs numero (numéro pmu), cote (rapport probable si le cheval gagne) et commentaire (commentaire de la performance du cheval).

    - Trotteurs et Galopeurs : un cheval est soit trotteur, soit galopeur (OU exclusif) et chaque catégorie est caractérisée différemment : son poids pour le galopeur et pour le trotteur son chrono etc.

    Les associations Entrainement et Appartenance tiennent compte du fait que le cheval peut changer d'entraîneur ou de propriétaire au cours de sa carrière d'où les attributs entrainéDepuis et appartenuDepuis.


    J'aimerais avoir vos critiques, vos remarques et vos suggestions sur ce MCD tout en sachant que vous n'êtes pas forcément au fait du fonctionnement de ce genre de pari.

    Je vous en remercie d'avance.

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    En préambule, il faudrait que le nom de chaque entité-type soit au singulier : par exemple Cheval et non pas Chevaux. C’est ce qu’ont toujours respecté les pères de MERISE : Dominique Nanci, Hubert Tardieu, Arnold Rochfeld, Yves Tabourier, etc. Leurs dignes successeurs aussi, voyez par exemple Michel Diviné, Christophe Sibertin-Blanc, etc.

    Une entité-type correspond en effet à un prédicat :
    Le cheval référencé par RefCheval, ayant pour nom NomCheval, né le DateNaissance et de sexe SexeCheval
    C’est un modèle pour les propositions :
    Le cheval 1 ayant pour nom Daryakana, né le 14 Avril 2006, de sexe 'F'
    Le cheval 2 ayant pour nom Yeats, né le 23 avril 2001, de sexe 'M'
    Etc.
    Ceci dit, votre MCD a une tête sympathique.

    Entités-types SIMPLE et QUINTE : d’après le graphisme, ce sont des spécialisations de l’entité-type COURSE. Pourquoi avoir utilisé deux triangles et non pas un seul ?

    Il y a une cardinalité 0,1 portée par la patte connectant l’entité-type COURSE et l’association-type REL_12. Ceci est générateur de NULL au niveau logique (où l’on opère), et NULL voilà l’ennemi, chose que l’on ignore au niveau conceptuel où l’on se contente de décrire. Il serait préférable de mettre en œuvre une cardinalité 1,1 et donc une valeur supplémentaire, du genre « état du terrain non précisé ». Même principe pour la connexion entre GALOPEUR et REL_8.

    Pour ma gouverne : à quoi correspond l’entité-type RANG ? Est-ce la position au départ, par rapport à la corde (comme dans l’épreuve du 400 mètres en athlétisme) ?

    L’entité-type PARTANT est identifiée relativement à COURSE d’une part et CHEVAL d’autre part : très bien. Mais attention, dans la même course, deux ou plusieurs chevaux pourront porter le même numéro, être montés par le même jockey, avoir le même rang et la même cote. Vous me direz « Mais comment faire pour éviter un tel scénario quantique ? » On est en fait face à une faiblesse de la représentation du MCD en Merise (et plus généralement de l’approche entité/relation).

    Ça n’est qu’au niveau logique que vous pourrez prendre les précautions d’usage, en y définissant des clés alternatives supplémentaires pour garantir les règles :
    Dans une course donnée, un numéro n’est porté que par un cheval, un jockey ne monte qu’un cheval, etc.

    A quoi correspondent les cardinalités 2,N (cf. JOCKEY et RANG) ? Un jockey doit avoir participé au moins à deux courses ?

    La propriété NombreDePartants est a priori un théorème (elle induit donc une redondance). En effet, le nombre effectif de partants est connu au niveau logique par la fonction COUNT appliquée à la table PARTANT.

    Voilà quelques observations après un balayage rapide de votre MCD. A vous de jouer.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2005
    Messages : 49
    Points : 39
    Points
    39
    Par défaut
    Bonjour,

    Merci pour votre réponse.

    Suite à vos observations, j'ai essayé d'apporter quelques modifications :



    Entités-types SIMPLE et QUINTE : d’après le graphisme, ce sont des spécialisations de l’entité-type COURSE. Pourquoi avoir utilisé deux triangles et non pas un seul ?
    En réalité, mon MCD utilise beaucoup de triangles :

    Le diagramme ci-dessus n'est pas complet mais c'est juste pour me servir de modèle : il existe encore beaucoup d'autres types de jeux que je n'ai pas encore fait figurer sur ce MCD : COUPLE, MULTI, TRIO etc.

    Le problème est que tous les types de jeu ne se trouvent pas dans chaque course : par exemple, le QUINTE n'existe que dans une seule course sur au moins une vingtaine de courses par jour.
    Si on regroupe tout dans un très grand tableau, j'aurai beaucoup de cases non remplies, alors je ne sais pas si c'est préférable de faire ainsi....

    Il y a une cardinalité 0,1 portée par la patte connectant l’entité-type COURSE et l’association-type REL_12. Ceci est générateur de NULL au niveau logique (où l’on opère), et NULL voilà l’ennemi, chose que l’on ignore au niveau conceptuel où l’on se contente de décrire. Il serait préférable de mettre en œuvre une cardinalité 1,1 et donc une valeur supplémentaire, du genre « état du terrain non précisé ». Même principe pour la connexion entre GALOPEUR et REL_8.
    Je ne comprends pas bien l'inconvénient de cet aspect. Est-il possible de gérer a posteriori, "programmatiquement" ce problème une fois que la base issue du MLD est créée ? (Les tableaux de la base ne seront remplis à l'aide d'un programme (java) et non manuellement).


    Pour ma gouverne : à quoi correspond l’entité-type RANG ? Est-ce la position au départ, par rapport à la corde (comme dans l’épreuve du 400 mètres en athlétisme) ?
    Normalement, le numéro de corde se trouve dans l'entité Partant mais je l'ai enlevé provisoirement pour plus de clarté...

    Rang correspond au résultat de la course de chaque cheval : 1er, 2è, 3è,....20è ou T (tombé), R (rétrogradé), Dai (disqualifié) etc.

    L’entité-type PARTANT est identifiée relativement à COURSE d’une part et CHEVAL d’autre part : très bien. Mais attention, dans la même course, deux ou plusieurs chevaux pourront porter le même numéro, être montés par le même jockey, avoir le même rang et la même cote.
    Je n'ai pas très bien compris pourquoi ? Ou alors, est-ce la conséquence de certaines erreurs sur les cardinalités (que j'ai modifiées : cf mon dernier MCD) ?

    A quoi correspondent les cardinalités 2,N (cf. JOCKEY et RANG) ? Un jockey doit avoir participé au moins à deux courses ?
    C'était une erreur de ma part, je l'ai corrigée (cf nouveau MCD).

    Je vous remercie d'avance de vos réponses et autres observations.

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Citation Envoyé par lazare Voir le message
    En réalité, mon MCD utilise beaucoup de triangles :

    Le diagramme ci-dessus n'est pas complet mais c'est juste pour me servir de modèle : il existe encore beaucoup d'autres types de jeux que je n'ai pas encore fait figurer sur ce MCD : COUPLE, MULTI, TRIO etc.

    Le problème est que tous les types de jeu ne se trouvent pas dans chaque course : par exemple, le QUINTE n'existe que dans une seule course sur au moins une vingtaine de courses par jour.
    Si on regroupe tout dans un très grand tableau, j'aurai beaucoup de cases non remplies, alors je ne sais pas si c'est préférable de faire ainsi....
    Supposons qu’il y ait un quinté pour la course C1, mais pas pour la course C2. Représentons les choses ainsi :




    Puisque du point de vue des paris, seules certaines courses sont à quinté, on peut considérer que l’entité-type QUINTE représente une spécialisation de l’entité-type COURSE. Au niveau tabulaire la représentation sera la suivante, dans laquelle QUINTE hérite de l’identifiant de COURSE :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    COURSE   CourseId    CourseNom           ReunionId
             --------    ----------------    ---------
                   C1    Prix Developpez            R1
                   C2    Prix Merise                R1
                  ...    ...                       ...
    
    QUINTE   CourseId    Rapport_Ordre   Rapport_Desordre
             --------    -------------   ----------------
                   C1         10000.00             100.00

    En tenant compte des simples, si les courses C1 et C2 sont concernées :

    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
    COURSE   CourseId    CourseNom           ReunionId
             --------    ----------------    ---------
                   C1    Prix Developpez            R1
                   C2    Prix Merise                R1
                  ...    ...                       ...
    
    QUINTE   CourseId    Rapport_Ordre   Rapport_Desordre
             --------    -------------   ----------------
                   C1         10000.00             100.00  
    
    SIMPLE   CourseId    Rapport_Gagnant   Rapport_Place_1   Rapport_Place_2   Rapport_Place_3
             --------    ---------------   ---------------   ---------------   ---------------
                   C1              14.50              3.20              3.60              2.00
                   C2              12.80              3.50              3.20              2.10

    Et l’on poursuit ainsi avec les différents types de paris. Évidemment, il y a des subtilités intéressantes à prendre en compte, concernant par exemple le couplé et ses rapports spéciaux : je lis ceci dans le Paris-Turf du 10 décembre 2009 :




    Affaire à suivre. En tout cas, il est hors de question de tout regrouper tout dans un très grand tableau !

    A propos des réunions :

    L’entité-type COURSE est porteuse d’attributs NumeroReunion et DateReunion. L’attribut DateReunion est déterminé par l’attribut NumeroReunion et doit donc dégager de l’entité-type COURSE. De même, d’après Paris-Turf, l’état du terrain ne dépend pas de la course mais plutôt de la réunion.

    Le MCD devrait évoluer ainsi :




    Je suis obligé d’interrompre la discussion pour le moment. Pour la suite je vous tiendrai au courant dès que possible.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par lazare Voir le message
    Il y a une cardinalité 0,1 portée par la patte connectant l’entité-type COURSE et l’association-type REL_12. Ceci est générateur de NULL au niveau logique (où l’on opère), et NULL voilà l’ennemi, chose que l’on ignore au niveau conceptuel où l’on se contente de décrire. Il serait préférable de mettre en œuvre une cardinalité 1,1 et donc une valeur supplémentaire, du genre « état du terrain non précisé ». Même principe pour la connexion entre GALOPEUR et REL_8.
    Je ne comprends pas bien l'inconvénient de cet aspect. Est-il possible de gérer a posteriori, "programmatiquement" ce problème une fois que la base issue du MLD est créée ? (Les tableaux de la base ne seront remplis à l'aide d'un programme (java) et non manuellement).
    Que la mise à jour et la consultation des tables soit manuelles ou programmées n’a rien à voir avec cette histoire de NULL qui joue uniquement au niveau des opérations en SQL. Comme je l’ai dit, la cardinalité 0,1 au niveau conceptuel est génératrice de NULL au niveau logique (SQL). Soit vous la remplacez par une cardinalité 1,1 si c’est possible, sinon il faut en passer par une entité-type associative entre COURSE et TERRAIN (pour reprendre cet exemple). Pour en savoir un peu plus, voyez par exemple la discussion ouverte par soul-31 et dans laquelle MacFly pose quelques questions.


    Citation Envoyé par lazare Voir le message
    Normalement, le numéro de corde se trouve dans l'entité Partant mais je l'ai enlevé provisoirement pour plus de clarté...
    D’après ce que j’ai compris, il y a par exemple des départs « à l’autostart » dans des courses de trot. Sans chercher à modéliser la chose, pourriez-vous expliquer le rôle de la corde selon les différents types de courses ? A quel moment la place est-elle attribuée ?

    Citation Envoyé par lazare Voir le message
    Rang correspond au résultat de la course de chaque cheval : 1er, 2è, 3è,....20è ou T (tombé), R (rétrogradé), Dai (disqualifié) etc.
    D’accord. Étant donné que la cardinalité portée par la patte connectant les entités-types PARTANT et RANG est 1,1 et que RANG ne contient qu’un seul attribut naturel (Rang), celui-ci pourrait intégrer directement l’entité-type PARTANT. C’est au sein de l'instruction CREATE TABLE PARTANT correspondante qu’on pourra injecter une contrainte permettant de garantir que les valeurs prises par l’attribut Rang sont valides. Mais si vous préférez conserver la modélisation actuelle, pas de problème.
    Question subsidiaire : deux partants d’une même course peuvent-ils avoir le même rang (cas des ex aequo) ?

    Citation Envoyé par lazare Voir le message
    L’entité-type PARTANT est identifiée relativement à COURSE d’une part et CHEVAL d’autre part : très bien. Mais attention, dans la même course, deux ou plusieurs chevaux pourront porter le même numéro, être montés par le même jockey, avoir le même rang et la même cote.
    Je n'ai pas très bien compris pourquoi ? Ou alors, est-ce la conséquence de certaines erreurs sur les cardinalités (que j'ai modifiées : cf mon dernier MCD) ?
    Les cardinalités ne sont pas en cause. Le problème se pose au niveau du MLD, c'est-à-dire des tables. Je détaillerai cette histoire demain.

    Bon courage en attendant.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Je n’ai pas Win’Design, donc je transpose votre MCD dans le contexte Power AMC (V11). Comme dans le cas de Win’Design, l’identifiant d’une entité-type est souligné et la petite clé jaune est remplacée pat le symbole <pi> (comme primary identifier).
    Avec Win’Design, l’identification relative est symbolisée par « 1,1(R) » et par « (1,1) » avec Power AMC.

    Dans le MCD ci-dessous, les attributs participant à des clés primaires sont suffixés par « id » (exemple : ReunionId), ce qui sous-entend que les valeurs prises par ces attributs sont automatiquement fournies par le système, elles sont invariantes et n’ont aucune signification pour l’utilisateur (humain ou programme), ce qui revient à dire qu’elles lui sont cachées. En contrepartie, si l’utilisateur a besoin d’une « clé naturelle » pour accéder à l’information, il disposera d’un identifiant alternatif dont il pourra faire ce qu’il veut, donc en changer les valeurs à sa guise. Ainsi, l’entité-type REUNION est dotée d’un identifiant primaire ReunionId et d’un identifiant alternatif ReunionNumero (accompagné du mickey <ai>, comme alternate identifier).

    Comme je l’ai déjà signalé, la date d’une course est celle de la réunion dont cette course fait partie. De même, si j’en crois Paris-Turf, ça n’est pas une course mais la réunion dont elle fait partie qui détermine l’état du terrain ou l’hippodrome où a lieu cette course. Bref, tout ceci justifie la mise en œuvre d’une entité-type REUNION. A son tour, une réunion est composée de courses, d’où l’identification relative entre les entités-types REUNION et COURSE exprimant une relation de composition.

    Le MCD ci-dessous reprend une partie du vôtre, notre intention étant de traiter de la partie « quantique » qui vous surprend.




    Passons au MLD produit par l’AGL :



    Observations :

    Les entités-types se traduisent ici par des tables et les identifiants des entités-types se traduisent par des clés.
    Ainsi, l’identifiant de l’entité-type REUNION donne lieu à la clé dite primaire {ReunionId} de la table REUNION (mickey <pk>, comme primary key). Pour sa part, l’identifiant alternatif ReunionNumero donne lieu à la clé alternative {ReunionNumero} (mickey <ak>, comme alternate key).

    Comme on a utilisé l’identification relative pour exprimer une relation de composition entre les entités-types REUNION et COURSE (une réunion est composée de courses), la clé primaire de la table COURSE est-elle-même composée de la paire {ReunionId, CourseId}, l’attribut ReunionId étant pour sa part hérité de la table REUNION.

    Cela signifie que pour une course donnée, dans le cadre d’une réunion donnée, on n’a qu’un seul prix, un seul numéro de course, une seule durée et une seule allocation.

    Je rappelle que par convention, l’attribut ReunionId est invariant et fourni par le système. L’utilisateur (humain ou programme) ne peut en aucune façon en changer la valeur. Par contre, il fait ce qu’il veut de l’attribut naturel NumeroCourse, avec toutefois la restriction évidente suivante : Dans le cadre d’une réunion, le numéro de la course est unique, c'est-à-dire qu’il faut définir une clé alternative {ReunionId, NumeroCourse}. Le cartouche COURSE doit devenir le suivant :




    Il y a un problème dans cette affaire : on aimerait que cette clé alternative soit automatiquement dérivée d’un identifiant alternatif du MCD plutôt que de la définir manuellement au stade du MLD. Malheureusement, par construction, l’approche entité/relation ne le permet pas (elle le pourrait, mais en tout cas les AGL ne le permettent pas).

    De la même façon, si l'attribut PrixId symbolise une course (exemple : Prix de Marvejols, cf. message précédent), il faudra définir une clé alternative en conséquence.

    Examinons maintenant le cas des partants.

    Du fait que l’entité-type PARTANT est identifiée relativement d’une part à l’entité-type COURSE et d’autre part à l’entité-type CHEVAL, la clé primaire de la table PARTANT est en conséquence l’union des clés clé primaires des tables COURSE et CHEVAL :
    {ReunionId, CourseId, ChevalId}.

    Ainsi, dans le cadre d’une course donnée, d’une réunion donnée, un cheval donné ne pourra être monté que par seul jockey, n’obtenir qu’un seul rang, ne porter qu’un seul numéro, n’avoir qu’une seule cote et peser un seul poids.




    Mais rien n’interdit que l’on ait la situation suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    ReunionId  CourseId  ChevalId  JockeyId  RangId  PartantNumero  PartantCote  PartantPoids
    ---------  --------  --------  --------  ------  -------------  -----------  ------------
            1         2         1         4       1              3          15             50
            1         2         7         4       3              1           5             45
            1         2         5         1       4              3          10             55
          ...       ...       ...       ...     ...            ...         ...            ...
    Ainsi, dans la même course, le jockey 4 serait censé avoir monté les chevaux 1 et 7, tandis que les chevaux 1 et 5 auraient porté le même numéro, etc.

    Vous me direz que la saisie des données est faite par programme, mais ça n’a aucune preuve de garantie, les erreurs sont seulement engrangées plus vite qu'à la main.

    Par exemple, si l’on examine l’équipe de basket des Blazers de Portland telle qu'elle est composée à ce jour, il y a des anomalies qui ne sont certainement le fait d’une saisie manuelle (des joueurs âgés de 2010 ans, pesant 38 kilos...) :




    Et vous noterez que si l’on n’y prend garde, de même qu’il y a deux joueurs portant le numéro 23, rien n’empêche que deux chevaux portent aussi un même numéro. Autrement dit, il est des contrôles qu’il vaut mieux sous-traiter au SGBD.

    Ainsi, pour jouer la carte de la sécurité, ou plutôt de l’intégrité des données, il est nécessaire de doter la table PARTANT de clés alternatives, afin d’être sûr que dans la même course, un cheval ne portera qu’un seul numéro, un jockey ne montera qu’un seul cheval, et — à moins que l'on ne soit dans monde quantique — un jockey ne participera pas au même moment à deux courses différentes :

    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  7. #7
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2005
    Messages : 49
    Points : 39
    Points
    39
    Par défaut
    Bonsoir,
    Citation Envoyé par fsmrel Voir le message
    Représentons les choses ainsi :
    En réalité, j'ai plus d'une dizaine d'entités liées, de la même manière que QUINTE et SIMPLE , à COURSE et donc j'avais mis autant de triangles jaunes que d'entités liées par pure commodité.


    Citation Envoyé par fsmrel Voir le message
    L’entité-type COURSE est porteuse d’attributs NumeroReunion et DateReunion. L’attribut DateReunion est déterminé par l’attribut NumeroReunion et doit donc dégager de l’entité-type COURSE. De même, d’après Paris-Turf, l’état du terrain ne dépend pas de la course mais plutôt de la réunion.
    Le MCD devrait évoluer ainsi :

    En fait, je viens de me rendre compte que j'avais supprimé par mégarde l'entité REUNION de l'original du MCD que je vous ai présenté
    :




    Dans ce modèle, l'attribut NumReunion de l'entité course n'a rien à voir avec idReunion de l'entité Reunion.
    NumReunion caractérise les 3 ou 4 réunions par jour : R1, R2 etc.
    J'ai fait en sorte qu'il y ait une entière cohérence entre ma base et les identifiants utilisés par le site Paris-turf.com alors idReunion et idCourse sont tout simplement récupérés sur le site.

    J'aime bien le modèle que vous avez proposé. Le problème est que :
    - le terrain peut changer au cours d'une réunion, s'il pleut par exemple, ce terrrain peut passer de souple à lourd pour les courses restantes.
    - une réunion ne se passe pas toujours (bien que ce soit rare) dans le même hippodrome : il arrive que les organisateurs incluent certaines courses étrangères dans une réunion qui se passe en France, donc dans un hippodrome différent.


    MLD correspondant :


    Citation Envoyé par fsmrel Voir le message
    D’après ce que j’ai compris, il y a par exemple des départs « à l’autostart » dans des courses de trot. Sans chercher à modéliser la chose, pourriez-vous expliquer le rôle de la corde selon les différents types de courses ? A quel moment la place est-elle attribuée ?
    Les numéros de corde ne concernent qu'un seul type de course : le galop, pour les courses d'obstacles et de trot ces numéros de corde n'existent pas. Pour le galop, ces numéros sont publiés en même temps que la publication de la liste des partants.
    Pour les courses de trot, le numéro de la place derrière l'autostart correspond tout simplement au numéro de brassard du partant.

    Citation Envoyé par fsmrel Voir le message
    Question subsidiaire : deux partants d’une même course peuvent-ils avoir le même rang (cas des ex aequo) ?
    Réponse : oui, aussi bien qu'il peut y avoir 3 chevaux tombés par exemple.

    Je n'ai pas encore eu le temps de bien intégrer les notions de clé alternative et d'entité-type associative.

    Merci beaucoup fsmrel.

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Un jour on gagne, un jour on perd, à l'hippodrome de Cagnes-sur-Mer...
    Salve lazare,


    En réalité, j'ai plus d'une dizaine d'entités liées, de la même manière que QUINTE et SIMPLE , à COURSE et donc j'avais mis autant de triangles jaunes que d'entités liées par pure commodité.
    D’accord. Cela dit, l’essentiel est que chaque sous-type tel que QUINTE, SIMPLE et compagnie, soit doté seulement des attributs pertinents (comme c’est le cas de QUINTE et de SIMPLE). J’ai jeté un coup d’œil chez Wikipedia, côté imagination, le Pari mutuel urbain ça n’est pas triste ! Comme vous dites, il y a beaucoup de types de jeux, mais même si vous avez une dizaine de sous-types, il n’y a pas de quoi s’inquiéter. Grâce à ces sous-types, le système est ouvert et il sera aisé de prendre en compte les futurs types de jeux que des gens pleins d’imagination sauront bien concocter...


    Je n'ai pas encore eu le temps de bien intégrer les notions de clé alternative et d'entité-type associative.
    Traitons déjà des clés alternatives.

    L’objet principal d’une clé est de garantir la règle dite d’unicité : deux lignes d’une table ne doivent pas avoir la même valeur de clé. En effet, vous allez vraisemblablement utiliser un SGBD relationnel : pour celui-ci, une table est un ensemble, manipulé au moyen de l’algèbre relationnelle, or dans un ensemble on ne trouve pas deux fois le même élément ; imaginez que l’on bégaie en définissant ainsi l’ensemble des entiers naturels (que devient l’arithmétique ?) :
    1, 1, 1, 2, 3, 3, 4, ....
    Ou que l’on bégaie à propos des courses d’une réunion et que l’on trouve 36 fois la course 1 pour la réunion 3 du 14 décembre 2009 à Cagnes-sur-Mer...

    En signifiant au SGBD que {IdReunion} est clé de la table REUNION, celui-ci veillera au grain, on n’y trouvera jamais deux fois la même valeur pour l’attribut IdReunion.

    Considérez maintenant le tableau périodique des éléments. Ce tableau permet de représenter les éléments et on y voit que l’élément de numéro atomique 6 a pour nom Carbone, pour symbole C, pour masse atomique 12, etc. Aucun autre élément n’a les caractéristiques de cet élément : numéro atomique, nom, symbole, masse atomique, etc. sont autant de propriétés devant être gouvernées par la règle d’unicité. Chacune d’elles est candidate à être clé : dans la théorie relationnelle on dira que {numéro atomique}, {nom}, {symbole}, {masse atomique}, etc. sont des clés candidates de la table ELEMENT (ou plus simplement clés). En SQL, on dit que parmi ces clés l’une sera choisie pour être clé primaire, auquel cas les autres seront reléguées au rang de clés alternatives. Ce distinguo primaire/alternative est parfaitement inutile, mais il existait jadis dans la théorie relationnelle (année 1970), et depuis a subi un coup de rasoir d’Ockham en 1993. En SQL il serait plus difficile d’en faire autant (pensez au nombre de tables en production dans le monde dans lesquelles figurent la clause « Primary Key »...)

    Pour en revenir à la table REUNION, souvenez-vous de ce que j’ai écrit :
    L’identifiant de l’entité-type REUNION donne lieu à la clé dite primaire {ReunionId} de la table REUNION (mickey <pk>, comme primary key). Pour sa part, l’identifiant alternatif ReunionNumero donne lieu à la clé alternative {ReunionNumero} (mickey <ak>, comme alternate key).
    En l’occurrence, l’usage est de retenir pour la clé primaire un attribut qui soit calculé par votre système (et surtout pas par un système qui n’est pas le vôtre). Par ailleurs, comme je l’ai déjà écrit, une clé primaire doit être invariante et sans signification. Au vu de tout cela, {ReunionId} tiendra ce rôle, et {ReunionNumero} — dont vous n'avez pas la maîtrise — sera clé alternative.

    Au fait, pourquoi les clés ne doivent pas dépendre de systèmes externes ? Je recopie ici ce que j’ai écrit dans une discussion avec faressam :
    Les concepteurs d’un projet d’une grande banque avaient retenu le numéro Siren des entreprises pour identifier celles-ci (attribut NoSiren de l’entité-type Entreprise). Au niveau SGBD, par le jeu des liens inter-tables (clé primaire - clé étrangère), le numéro Siren se propageait dans de nombreuses tables. Or, ce numéro est fourni par l’INSEE, lequel envoyait tous les mois les correctifs modifiant le Siren des nouvelles entreprises (10% d’entre elles à peu près). Les concepteurs en avaient tenu compte et me montrèrent le modèle correspondant à la mise à jour des tables impliquées : une usine à gaz ! J’avais fait observer que, vu le nombre de tables touchées et leur volumétrie (plusieurs millions de lignes chacune), cela pouvait faire exploser la production informatique (batchs de nuit), du fait d’une activité de mise à jour excessive et en plus, délicate à ordonnancer. Sans que j'ai eu à le leur demander, les concepteurs définirent une nouvelle propriété, non porteuse d’information, artificielle et invariante, destinée à être l’attribut composant la clé primaire de la table Entreprise, propagé en conséquence dans les autres tables, en lieu et place de l’attribut NoSiren. A partir de là, modifier un numéro de Siren n’impactait plus que la seule table Entreprise, les utilisateurs ayant bien évidemment toujours accès au contenu de l’attribut NoSiren, devenu clé alternative (et n’ayant donc pas perdu sa propriété d’unicité).

    Je poursuivrai mes explications dès que j'aurai un moment.

    A bientôt,

    fsmrel
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #9
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Entité-type associative
    Bonsoir,

    Concernant la notion d’entité-type associative.

    Le but de la manœuvre est d’éviter au niveau opérationnel d’avoir la situation suivante, dans laquelle l’état du terrain n’est pas connu pour la réunion R2, auquel cas le bonhomme NULL vient se manifester, conséquence de la conservation de la cardinalité 0,1 au niveau conceptuel :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    TERRAIN (TerrainId,    TerrainEtat)
             ---------     -----------
                    T1     bon
                    T2     merdique
                   ...     ...
    
    REUNION (ReunionId, TerrainId,  ...)
              --------  ---------   --- 
                    R1         T1   ...
                    R2       NULL   ...
                   ...        ...   ...
    Une solution : définir un état du terrain particulier, par exemple « inconnu », ce qui permet de remplacer les cardinalités 0,1 par 1,1. Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    TERRAIN (TerrainId,  TerrainEtat)
             ---------   -----------
                    T1   bon
                    T2   merdique
                   ...   ...
                   T99   inconnu
    
    REUNION (ReunionId, TerrainId,  ...)
              --------  ---------   --- 
                    R1         T1   ...
                    R2        T99   ...
                   ...        ...   ...
    Solution alternative : utilisation d’une entité-type associative REUNION_TERRAIN (elle associe les entités-types REUNION et TERRAIN) :

    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
    TERRAIN (TerrainId,  TerrainEtat)
             ---------   -----------
                    T1   bon
                    T2   merdique
                   ...   ...
    
    REUNION (ReunionId,  ...)
              --------   --- 
                    R1   ...
                    R2   ...
                   ...   ...
    
    REUNION_TERRAIN (ReunionId, TerrainId) 
                            R1         T1
                           ...        ...
    Cette fois-ci, la réunion R2 n’est pas concernée par les problèmes de terrain.


    MCD dans le style Power AMC :




    MLD :

    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2005
    Messages
    49
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2005
    Messages : 49
    Points : 39
    Points
    39
    Par défaut Merci
    J'ai lu avec grand intérêt toutes vos réponses éclairées mon cher fsmrel.

    Je tiens à vous en remercier infiniment

  11. #11
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir lazare,

    Que mes réponses soient éclairées, j'en suis content, mais sont-elles éclairantes ?

    Avez-vous l'impression de progresser ?

    Sinon, à cause de vous, me remonte dans la tête une chanson de Roro d'il y a quarante ans :

    "Ce soir, c'est sam'di soir,
    au PMU tabac le tiercé se débat.
    Et je sens que demain la course est ma main" ...

    (après j'ai oublié, à part :
    "Un jour on gagne un jour on perd
    à l'hippodrome de Cagnes-sur-Mer,
    Tchaba, tchabada bad'a (bis)

    et que "c'est Jojo qui r'file les tuyaux"...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  12. #12
    Invité
    Invité(e)
    Par défaut question d'un débutant
    Bonjour,

    J'ai de l'intérêt pour cet article et veuillez excuser la question du béotien que je suis mais
    comment traduit-on une "clef alternative" en Language sql ?

    Je vous remercie vivement pour vos éléments de réponse .
    Merci.

  13. #13
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour ceststef,

    Pour reprendre les diagrammes du post #6, dans le MCD l’entité-type REUNION a un identifiant alternatif {ReunionNumero} qui se traduit au stade MLD par la clé alternative {ReunionNumero}. En SQL on traduit cela par une contrainte « UNIQUE » :

    CREATE TABLE REUNION
    (
            ReunionId           INTEGER      NOT NULL
          , ReunionNumero       INTEGER      NOT NULL
          , ReunionDate         DATE         NOT NULL
        , CONSTRAINT REUNION_PK PRIMARY KEY (ReunionId)
        , CONSTRAINT REUNION_AK UNIQUE (ReunionNumero)
    ) ;
    Et n'oubliez pas de voter pour les posts qui ont pu vous intéresser...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  14. #14
    Invité
    Invité(e)
    Par défaut Numérotation des clés étrangères
    Bonsoir,

    Merci, merci pour cette prompte réponse ciselée.
    J'aurais une autre interrogation à vous soumettre:

    Quand on observe le mld #6, dans l'entité-type PARTANT, si je comprends bien que
    ChevalId en plus d'être qualifié de clé primaire on ajoute la clé étrangère numérotée 2,
    pourquoi dès lors ReunionId et CourseId supportent-ils un même numéro de clé étrangère, en l'espèce fk1 ?
    Et pourquoi pas fk3 pour l'un des deux ? Est-ce parce que ces "attributs" émanent d'une même "direction" ?

    Pardon par avance pour mon vocabulaire imprécis.
    Merci.

  15. #15
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir ceststef,

    Citation Envoyé par ceststef Voir le message
    Quand on observe le mld #6, dans l'entité-type PARTANT, si je comprends bien que ChevalId en plus d'être qualifié de clé primaire on ajoute la clé étrangère numérotée 2
    Précisions :
    Il est d’usage que dans un MLD, on n’utilise pas le terme « entité-type » (on ne l’utilise que pour le MCD), mais celui de « table ». Ceci dit, restons-en au MLD :

    Les noms A1, A2, ..., Am des attributs (éléments donc) d’une clé sont mis entre accolades : {A1, A2, ..., Am}. En effet, une clé est un ensemble au sens de la théorie des ensembles. Cela vaut même dans le cas des singletons, en vertu de quoi {ReunionId} est clé (primaire) de la table REUNION, {ReunionNumero} est clé (alternative) de cette table. Pour sa part, l’attribut ChevalId n’est pas clé primaire de la table CHEVAL, il n’est qu’élément de la clé primaire {ChevalId} de celle-ci ; par ailleurs l’attribut ChevalId n’est qu’un des éléments de la clé primaire {ReunionId, CourseId, ChevalId} de la table PARTANT.

    Dans la table PARTANT, {ChevalId} est aussi clé étrangère faisant référence à la clé primaire {ChevalId} de la table CHEVAL, intégrité référentielle oblige (sinon on pourrait évoquer dans la table PARTANT des chevaux inconnus dans la table CHEVAL, ça serait la panique). Pour la petite histoire, AMC accompagne les clés de symboles, de mickeys nous permettant de nous y retrouver : <pk> est un mickey, une abréviation (mais pas un nom !) pour« clé primaire », <fk> est une abréviation pour « foreign key » (cf. tables SIMPLE et QUINTE). Si une clé étrangère fait référence à une clé primaire comportant n attributs, alors cette clé étrangère comporte aussi n attributs : la clé primaire {ReunionId, CourseId} de table COURSE contient 2 attributs, donc la clé étrangère {ReunionId, CourseId} correspondante dans la table PARTANT contient ces 2 [noms d’] attributs, ReunionId et CourseId. Si une table fait référence à plus d’une table, les clés étrangères correspondantes sont symbolisées et numérotées de la façon suivante par AMC :<fk1>, fk2>, etc. Ainsi, dans la table COURSE, le mickey <fk1> désigne la clé étrangère {ReunionId} faisant référence à la clé primaire {ReunionId} de la table REUNION, tandis que le mickey <fk2> désigne la clé étrangère {PrixId} faisant référence à la clé primaire {PrixId} de la table PRIX. De la même façon, dans la table PARTANT, le mickey <fk1> désigne la clé étrangère {ReunionId, CourseId} faisant référence à la clé primaire {ReunionId, CourseId} de la table COURSE, tandis que le mickey <fk2> désigne la clé étrangère {ChevalId} faisant référence à la clé primaire {ChevalId} de la table CHEVAL. Dans le même sens, le mickey <fk3> y désigne la clé étrangère {JockeyId} faisant référence à la clé primaire {JockeyId} de la table JOCKEY, tandis que le mickey <fk4> y désigne la clé étrangère {RangId} faisant référence à la clé primaire {RangId} de la table RANG.
     
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  16. #16
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    En complément :

    Les conventions définies par AMC valent aussi pour les clés alternatives. Ainsi, <ak> est une abréviation pour « alternate key ». Si une table contient plusieurs clés alternatives, elles y sont désignées par <ak1>, <ak2>, etc.

    Prenons le cas du MLD ci-dessous :

    Nom : lazare(courses_hippiques)Reunion_mld.png
Affichages : 2959
Taille : 32,0 Ko

    Dans la table PARTANT, on voit que <ak1> désigne la clé alternative {ReunionId, CourseId, JockeyId}, tandis que <ak2> désigne la clé alternative {ReunionId, CourseId, PartantNumero}.

    Au passage, vous aurez noté que dans une table, un attribut peut être à la fois élément de la clé primaire, d’une clé étrangère (voire de plusieurs) et d’une clé alternative (voire de plusieurs).

    Dans le style SQL, les mickeys ne sont plus de mise, on utilise cette fois-ci des noms pour les contraintes. Par exemple :

    CREATE TABLE HIPPODROME 
    (
            HippodromeId     INT           NOT NULL 
          , HippodromeNom    VARCHAR(48)   NOT NULL 
        , CONSTRAINT HIPPODROME_PK PRIMARY KEY (HippodromeId)
    ) ;
    
    CREATE TABLE TERRAIN 
    (
            TerrainId        INT           NOT NULL 
          , TerrainEtat      VARCHAR(16)   NOT NULL 
        , CONSTRAINT TERRAIN_PK PRIMARY KEY (TerrainId)
    ) ;
    
    CREATE TABLE CHEVAL 
    (
            ChevalId              INT           NOT NULL
          , ChevalNom             VARCHAR(48)   NOT NULL
          , ChevalDateNaissance   DATE          NOT NULL
          , ChevalSexe            CHAR(1)       NOT NULL
        , CONSTRAINT CHEVAL_PK PRIMARY KEY (ChevalId)
    ) ;
    
    CREATE TABLE JOCKEY 
    (
            JockeyId              INT           NOT NULL
          , JockeyNom             VARCHAR(48)   NOT NULL
        , CONSTRAINT JOCKEY_PK PRIMARY KEY (JockeyId)
    ) ;
    
    CREATE TABLE RANG 
    (
            RangId                INT           NOT NULL
          , RangLibelle           VARCHAR(48)   NOT NULL
        , CONSTRAINT RANG_PK PRIMARY KEY (RangId)
    ) ;
    
    CREATE TABLE PRIX 
    (
            PrixId                INT           NOT NULL
          , PrixNom               VARCHAR(48)   NOT NULL
        , CONSTRAINT PRIX_PK PRIMARY KEY (PrixId)
    ) ;
    
    CREATE TABLE REUNION 
    (
            ReunionId        INT           NOT NULL
          , TerrainId        INT           NOT NULL 
          , HippodromeId     INT           NOT NULL
          , ReunionNumero    INT           NOT NULL
          , ReunionDate      DATE          NOT NULL
        , CONSTRAINT REUNION_PK PRIMARY KEY (ReunionId)
        , CONSTRAINT REUNION_AK UNIQUE (ReunionNumero)
        , CONSTRAINT REUNION_TERRAIN_FK FOREIGN KEY (TerrainId)
              REFERENCES TERRAIN
        , CONSTRAINT REUNION_HIPPODROME_FK FOREIGN KEY (HippodromeId)
              REFERENCES HIPPODROME (HippodromeId)
    ) ;
    
    CREATE TABLE COURSE 
    (
            ReunionId        INT           NOT NULL
          , CourseId         INT           NOT NULL
          , PrixId           INT           NOT NULL
          , CourseNumero     INT           NOT NULL
          , CourseDuree      TIME          NOT NULL
          , CourseAllocation INT           NOT NULL
        , CONSTRAINT COURSE_PK PRIMARY KEY (ReunionId, CourseId)
        , CONSTRAINT COURSE_AK UNIQUE (ReunionId, CourseNumero)
        , CONSTRAINT COURSE_REUNION_FK FOREIGN KEY (ReunionId)
              REFERENCES REUNION
        , CONSTRAINT COURSE_PRIX_FK FOREIGN KEY (PrixId)
              REFERENCES PRIX (PrixId)
    ) ;
    
    CREATE TABLE SIMPLE 
    (
            ReunionId        INT           NOT NULL
          , CourseId         INT           NOT NULL
          , Rapport_Gagnant  INT           NOT NULL
          , Rapport_Place_1  INT           NOT NULL
          , Rapport_Place_2  INT           NOT NULL
          , Rapport_Place_3  INT           NOT NULL
        , CONSTRAINT SIMPLE_PK PRIMARY KEY (ReunionId, CourseId)
        , CONSTRAINT SIMPLE_COURSE_FK FOREIGN KEY (ReunionId, CourseId)
              REFERENCES COURSE (ReunionId, CourseId)
              ON DELETE CASCADE
    ) ;
    
    CREATE TABLE QUINTE 
    (
            ReunionId        INT           NOT NULL
          , CourseId         INT           NOT NULL
          , Rapport_Ordre    DECIMAL(9,2)  NOT NULL
          , Rapport_Desordre DECIMAL(9,2)  NOT NULL
        , CONSTRAINT QUINTE_PK PRIMARY KEY (ReunionId, CourseId)
        , CONSTRAINT QUINTE_COURSE_FK FOREIGN KEY (ReunionId, CourseId)
              REFERENCES COURSE (ReunionId, CourseId)
              ON DELETE CASCADE
    ) ;
    
    CREATE TABLE PARTANT 
    (
            ReunionId        INT           NOT NULL
          , CourseId         INT           NOT NULL
          , ChevalId         INT           NOT NULL
          , JockeyId         INT           NOT NULL
          , RangId           INT           NOT NULL
          , PartantNumero    INT           NOT NULL
          , PartantCote      VARCHAR(16)   NOT NULL
          , PartantPoids     DECIMAL(4,2)  NOT NULL
          , PartantCommentaire VARCHAR(256) NOT NULL
        , CONSTRAINT PARTANT_PK PRIMARY KEY (ReunionId, CourseId, ChevalId)
        , CONSTRAINT PARTANT_JOCKEY_AK UNIQUE (ReunionId, CourseId, JockeyId)
        , CONSTRAINT PARTANT_NUMERO_AK UNIQUE (ReunionId, CourseId, PartantNumero)
        , CONSTRAINT PARTANT_COURSE_FK FOREIGN KEY (ReunionId, CourseId)
          REFERENCES COURSE (ReunionId, CourseId)
        , CONSTRAINT PARTANT_CHEVAL_FK FOREIGN KEY (ChevalId)
              REFERENCES CHEVAL (ChevalId)
        , CONSTRAINT PARTANT_JOCKEY_FK FOREIGN KEY (JockeyId)
              REFERENCES JOCKEY (JockeyId)
        , CONSTRAINT PARTANT_RANG_FK FOREIGN KEY (RangId)
              REFERENCES RANG (RangId)
    ) ;
    Cela vous éclaire-t-il ?

     
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  17. #17
    Invité
    Invité(e)
    Par défaut
    Bonjour,

    Effectivement, la réponse apportée ne fait pas que m'éclairer, elle est lumineuse et limpide.
    Nantie du code sql en plus. Merci.

    D'ailleurs, je m'interrogeais car quand je lis par exemple cet extrait du bloc CREATE TABLE REUNION :

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    CONSTRAINT REUNION_TERRAIN_FK FOREIGN KEY (TerrainId)
              REFERENCES TERRAIN
        , CONSTRAINT REUNION_HIPPODROME_FK FOREIGN KEY (HippodromeId)
              REFERENCES HIPPODROME (HippodromeId)

    je vois dans le MLD donc, que {TerrainId} et {HippodromeId} sont toutes deux des clés alternatives de la table REUNION, mais qu'elles n'ont pas tout à fait la même transcription SQL. En effet, pour la contrainte {HippodromeId}, pourquoi ajoute-t-on en fin d'expression " (HippodromeId) " tandis que pour la contrainte {TerrainId}, on ne retrouve pas " (TerrainId) " en fin de code alors que pourtant ces deux clés alternatives de la table REUNION semblent avoir la même "destination" ou plutôt le même statut ?

    Merci beaucoup en tout cas pour votre attention.
    Dernière modification par Malick ; 19/01/2020 à 17h13. Motif: Ajout balises code

  18. #18
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour ceststef,


    Citation Envoyé par ceststef Voir le message
    {TerrainId} et {HippodromeId} sont toutes deux des clés alternatives de la table REUNION,
    Que nenni ! Ce ne sont que des clés étrangères ! La clé étrangère {TerrainId} a pour objet de garantir que chaque valeur prise par l’attribut TerrainId dans la table REUNION soit aussi (et d’abord) une valeur de la clé primaire {TerrainId} de la table TERRAIN. Un terrain donné peut être utilisé pour plusieurs réunions, mais si {TerrainId} était clé alternative de la table REUNION, alors ce terrain ne pourrait être utilisé que pour une seule réunion, ce qui est peu !

    Je rappelle qu’une clé primaire et une clé alternative sont des clés candidates : leur rôle est de garantir l’unicité. Mais si une table a N clés candidates, une seule de celles-ci peut être élevée au rang de clé primaire, les autres étant ravalées au rang de dauphines, c’est-à-dire de clés alternatives. Disons que c’est purement honorifique, il y a une clé qui est plus égale que les autres...
    C’est un peu comme pour l’élection de Miss France, il y a N candidates, mais il n’y a au bout du compte qu’une seule Miss, les autres demoiselles devenant ses dauphines.

    Miss Primary Key :

    Nom : Miss_clé_primaire.png
Affichages : 2572
Taille : 148,7 Ko


    Bien entendu, ce qui vaut pour {TerrainId} vaut pour {HippodromeId}.



    Citation Envoyé par ceststef Voir le message
    pour la contrainte {HippodromeId}, pourquoi ajoute-t-on en fin d'expression " (HippodromeId) " tandis que pour la contrainte {TerrainId}, on ne retrouve pas " (TerrainId) " en fin de code
    En fonction du SGBD qu’on utilise, le code SQL généré par AMC à partir du MLD comporte ou ne comporte pas la référence à la clé primaire "(TerrainId)" en fin de code. Ainsi, si j’avais utilisé MySQL, AMC aurait généré :

      CONSTRAINT REUNION_TERRAIN_FK FOREIGN KEY (TerrainId)
          REFERENCES TERRAIN (TerrainId)
    Mais j’ai utilisé SQL Server, lequel se borne à générer :

      CONSTRAINT REUNION_TERRAIN_FK FOREIGN KEY (TerrainId)
          REFERENCES TERRAIN
    Ce qui est conforme à la norme SQL, pour qui la référence "(TerrainId)" est facultative (le SGBD doit alors comprendre que cette référence est la clé primaire {TerrainId} de la table TERRAIN). SQL Server accepte donc que l’on fournisse ou non cette référence "(TerrainId)".

    Ceci vaut évidemment pour chaque clé étrangère. Puisque j’ai dit à AMC que j’utiliserai SQL Server, celui-ci n’a généré aucune référence. En pensant aux lecteurs de mon post qui travailleraient avec MySQL ou autre SGBD exigeant que les références soient présentes (sinon, avec MySQL c’est : "Error Code: 1215. Cannot add foreign key constraint"), je les ai ajoutées manuellement, et bien entendu, distraction oblige, la référence "(TerrainId)" est passée au travers, ce qui ne vous a pas échappé...

    Libre à vous d'ajouter ou non la référence "(TerrainId)"

     
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  19. #19
    Invité
    Invité(e)
    Par défaut
    Bonjour,

    Merci pour la réponse.

    Je suis impardonnable, j'ai pensé étrangère et j'ai écrit alternative. Quand je me relis, j'ai peine à y croire.

    Navré, "ma fourche a langué !"

    Quoiqu'il en soit merci pour la leçon et puis avec des croquis ou en l'espèce des images, on assimile tout de suite mieux les notions.

  20. #20
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par ceststef Voir le message
    j'ai pensé étrangère et j'ai écrit alternative
    Je m’en suis bien douté, et nous sommes tous à même de penser une chose et en écrire une autre, moi le premier ! Mais votre étourderie m’a permis de faire une mise au point qui pourra profiter aux visiteurs…


    Et n'oubliez pas de continuer à voter pour les messages qui vous ont été utiles.

     
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

Discussions similaires

  1. Raisonnement pour la prédiction des performances en course hippique
    Par sp2308 dans le forum Algorithmes et structures de données
    Réponses: 9
    Dernier message: 02/04/2015, 20h53
  2. [AC-2007] Création Formulaire - Gestion de courses hippiques
    Par jean33000 dans le forum IHM
    Réponses: 8
    Dernier message: 26/04/2010, 20h42
  3. [FLASH MX2004] Course de bateaux
    Par Kalyptus dans le forum Flash
    Réponses: 9
    Dernier message: 31/05/2005, 19h26
  4. Réponses: 2
    Dernier message: 15/02/2005, 20h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo