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 :

Unicité d'une clef composée


Sujet :

Schéma

  1. #1
    Candidat au Club
    Unicité d'une clef composée
    bonjour a tous

    je dois faire le mcd d un champ de course de chevaux mon probleme se situe entre 3 itentitee qui sont : CHEVAL COURSE JOCKEY
    on me dit que le n=° de dossard depend DU CHEVAL de la COURSE et du JOCKEY
    donc je fait une ternaire n,n,n entre les trois le probleme quand je fait ça c que UN JOCKEY peut participer a la meme course sur plusieurs chevaux

    C=course
    JK=jockey
    CH=chevaux

    C1 CH1 JK1 ici j ai le jockey 1
    C1 CH2 JK2
    C1 CH3 JK1 ici j ai encore le jockey 1 malgres que ma cle soit unque

    il en ai de meme je peut avoir jockey sur un cheval

    C2 CH4 JK1
    C2 CH5 JK2
    C2 CH4 JK4

    mon probleme et donc de trouver une contrainte pour que ca n arrive pas

    je vous remercie par avance vous pouvez me contactez par msn yannickgasc707@msn.com

    yannick

  2. #2
    Inactif  
    primary key (course_id,cheval_id,jockey_id)

  3. #3
    Expert éminent sénior
    Clés candidates
    Bonjour,

    Considérons l’ensemble E des attributs Jockey, Cheval, Course, Dossard.

    Soit T la table correspondante. Celle-ci a pour entête :

    T (Jockey, Cheval, Course, Dossard)

    Le triplet (Jockey, Cheval, Course) peut-il être clé candidate ? Non.

    En effet, étant donné que dans une course un jockey monte un seul cheval et porte en l’occurrence un seul dossard, on peut traduire cela sous forme de dépendances fonctionnelles.

    DF1 : {Course, Jockey} -> {Cheval}
    DF2 : {Course, Jockey} -> {Dossard}

    De la même façon, il existe les dépendances fonctionnelles :

    DF3 : {Course, Cheval} -> {Jockey}
    DF4 : {Course, Cheval} -> {Dossard}

    Ou encore :

    DF5 : {Course, Dossard} -> {Jockey}
    DF6 : {Course, Dossard} -> {Cheval}

    On en déduit les clés candidates pour T :

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}

    D’où l’instruction CREATE TABLE (par exemple avec SQL Server 2005) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    CREATE TABLE T (
         Course    int   Not Null, 
         Jockey    int   Not Null, 
         Cheval    int   Not Null, 
         Dossard   int   Not Null, 
       Unique (Course, Dossard),
       Unique (Course, Jockey),
       Unique (Course, Cheval)
    ) ;
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  4. #4
    Expert éminent sénior
    BCNF et courses hippiques
    Bonsoir,

    Pour ceux que cela intéresse, j’apporte un complément d’information, concernant la forme normale de Boyce-Codd (BCNF). Au préalable, il est nécessaire de savoir ce que l’on entend par surclé et dépendance fonctionnelle triviale (les définitions que je donne se retrouvent dans les ouvrages de C.J. Date, notamment "The Relational Database Dictionary").

    Concept de surclé (superkey)

    Considérons à nouveau la table T évoquée dans mon précédent message.
    L’entête de cette table est composé des attributs suivants : Jockey, Cheval, Course et Dossard :

    T (Jockey, Cheval, Course, Dossard)

    Je rappelle que T possède 3 clés candidates :

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}

    Dans le cadre de la théorie relationnelle la définition d’une surclé est la suivante :

    Soit SK un sous-ensemble (non strict) de l’entête d’une table S ; SK est une surclé de S si et seulement si deux tuples (lignes) distincts de S ne peuvent avoir la même valeur.

    Cette contrainte porte le nom de Contrainte d’unicité.

    Par définition (au moins dans le cadre de la théorie relationnelle), l’entête de la table T répond à cette contrainte et constitue une surclé :

    SK1 : {Jockey, Cheval, Course, Dossard}

    De la même façon, le triplet SK2 : {Jockey, Cheval, Course} constitue aussi une surclé.

    Il en va de même pour les couples :

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}

    En revanche, le triplet {Jockey, Cheval, Dossard} ne vérifie pas la contrainte d’unicité et ne constitue donc pas une surclé :

    En effet, un jockey a pu monter le même cheval, avec le même dossard dans des courses différentes.

    De la même façon, les singletons {Course}, {Jockey}, {Cheval} et {Dossard} ne respectent pas la contrainte d’unicité et ne constituent pas non plus des surclés :

    En effet, à une course participent plusieurs jockeys, plusieurs chevaux et on y voit plus d’un dossard.
    Un jockey a pu participer à plusieurs courses, avec des chevaux et des dossards différents.
    Un cheval a pu participer à plusieurs courses, et y avoir été monté par différents jockeys avec des dossards différents.
    Un dossard est un numéro que l’on retrouve dans les différentes courses, épinglé dans le dos d’un tas de jockeys (à ceci près que deux jockeys ne peuvent pas porter le même numéro dans la même course, d’où la contrainte d’unicité exprimée par K3 et de la même façon, K1 et K2 expriment une telle contrainte).

    Concept de clé candidate

    Une clé candidate est une surclé SK pour une table S si elle obéit non seulement à la contrainte d’unicité, mais aussi à une contrainte dite d’irréductibilité, selon laquelle :

    Il n’existe pas de sous-ensemble SK’ strictement inclus dans SK obéissant lui aussi à la contrainte d’unicité.

    Ainsi, le quadruplet SK1 : {Jockey, Cheval, Course, Dossard} ne respecte pas la contrainte d’irréductibilité puisqu’il contient (entre autres) le couple K1 : {Course, Jockey}, lequel obéit à la contrainte d’unicité.
    Le triplet SK2 : {Jockey, Cheval, Course} ne respecte pas non plus la contrainte d’irréductibilité puisqu’il contient lui aussi ce couple K1.

    En résumé, seuls les couples K1, K2 et K3 constituent des surclés qui sont aussi clés candidates, tandis que le quadruplet SK1 et le triplet SK2 sont des surclés non clés candidates.

    Concept de dépendance fonctionnelle

    Je rappellerai ici la définition d’une dépendance fonctionnelle.
    Soit X et Y deus sous-ensembles quelconques de l’entête d’une table S.

    S satisfait à la dépendance fonctionnelle (DF) X -> Y si et seulement si, à chaque fois que deux tuples (lignes) de S ont même valeur pour X, alors ils ont même valeur pour Y (X est appelé le déterminant et Y le dépendant).

    Ainsi, on peut relever les dépendances fonctionnelles suivantes (cf. mon précédent message) :

    DF1 : {Course, Jockey} -> {Cheval}
    DF2 : {Course, Jockey} -> {Dossard}
    DF3 : {Course, Cheval} -> {Jockey}
    DF4 : {Course, Cheval} -> {Dossard}
    DF5 : {Course, Dossard} -> {Jockey}
    DF6 : {Course, Dossard} -> {Cheval}

    Mais aussi celles que l’on peut obtenir à partir de ces DF, au moyen des 3 premiers axiomes d’Armstrong (dont l’étude sort malheureusement du périmètre de cette discussion) et des règles qu’on en infère :

    DF7 : {Jockey, Cheval, Course} -> {Dossard} ____ (axiome d’augmentation et règle de décomposition)
    DF8 : {Course, Dossard, Cheval} -> {Jockey} ____ (idem)
    Etc.

    Dépendance fonctionnelle triviale

    La DF : X-> Y est triviale si et seulement si Y est un sous-ensemble (non nécessairement strict) de X, c’est-à-dire que cette DF est inviolable.

    Les dépendances fonctionnelles suivantes répondent à cette définition :

    DF9 : {Course} -> {Course}
    DF10 : {Jockey} -> {Jockey}
    DF11 : {Cheval} -> {Cheval}
    DF12 : {Dossard} -> {Dossard}

    mais aussi :

    DF13 : {Course, Jockey} -> {Course}
    DF14 : {Course, Jockey} -> {Jockey}
    DF15 : {Course, Jockey, Cheval} -> {Course}
    DF16 : {Course, Jockey, Cheval} -> {Jockey}
    DF17 : {Course, Jockey, Cheval} -> {Cheval}
    DF18 : {Course, Jockey, Cheval, Dossard} -> {Course}
    Etc.

    Définition de la BCNF (forme normale de Boyce-Codd)

    Je rappelle que la forme normale de Boyce-Codd permet de corriger des structures maladroites de tables, et ainsi d’éliminer des redondances inutiles et dangereuses, d’éviter certaines pertes d’informations et de simplifier les opérations. Normaliser consiste à "casser" une table non normalisée en 2 ou plusieurs tables normalisées BCNF, sachant que l'on peut recoller les morceaux par jointure naturelle (au besoin sous forme d’une vue) et retrouver ainsi le contenu de la table initiale (décomposition/recomposition sans perte). William Kent fut à l’origine de cette forme normale (que l’on appelle parfois BCKNF). Le but était de pallier un manque de la 3e forme normale de Codd.

    L’énoncé de la BCNF est le suivant (il en existe des variantes), tel qu’il est donné aujourd’hui par C.J. Date (qui a repris C. Zaniolo) :

    Une table S est en forme normale de Boyce-Codd (BCNF) si et seulement si
    pour chaque dépendance fonctionnelle non triviale X -> Y satisfaite par S, X est une surclé de S.

    La table T (Jockey, Cheval, Course, Dossard) respecte-t-elle la BCNF ?

    Seules les DF non triviales sont à examiner, à savoir DF1 à DF6, ainsi que celles qui en en ont été inférées, telles DF7 et DF8.
    Or, le déterminant de chacune des DF DF1à DF6 est une clé candidate, donc une surclé de la table T :

    Le déterminant de DF1 et celui de DF2 correspondent à K1,
    Le déterminant de DF3 et celui de DF4 correspondent à K2,
    Le déterminant de DF5 et celui de DF6 correspondent à K3.

    Concernant toutes les autres DF non triviales, telles DF7 et DF8, leur déterminant inclut celui d’une des DF DF1 à DF6 et en conséquence est une surclé de la table T. En conséquence :

    La table T respecte la BCNF.

    NB. Référence :
    "The Relational Database Dictionary", petit ouvrage de 100 pages tenant facilement dans la poche :

    http://www.oreilly.com/catalog/relationaldb/
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  5. #5
    Membre à l'essai
    merci fsmrel pour cette explication
    je viens de relire ton dernier message une 4me fois parce que pour moi les termes "surclé" "clé candidate" et "non triviale" sont tous nouveaux

    par contre j'ai maitenant un doute sur le choix de la clé primaire. pour cette table ça sera SK2 ({Jockey, Cheval, Course}) c'est ça ?

  6. #6
    Expert éminent sénior
    Bonsoir,

    J’ai simplement oublié de préciser que la clé primaire était choisie a priori de façon arbitraire parmi les clés candidates, lesquelles, je le rappelle sont les suivantes :

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}

    En vertu de quoi SK2 est disqualifiée.

    Pour en revenir à la clé primaire, comme je l’ai précisé dans quelques discussions, elle doit rester invariante et non significative (ce qui facilite soit dit en passant la mise en œuvre de l’intégrité référentielle). Il va de soi qu’elle ne peut pas prendre la valeur nulle.

    Pour imager, je dirais que la clé primaire est aux clés candidates non retenues ce qu’est Miss France pour ses dauphines...

    Une clé candidate non retenue comme clé primaire est encore appelée clé alternative (alternate key) ou encore de rechange.

    A vous de jouer. Si vous avez des doutes, faites-le savoir.

    Curieusement, la discussion a été entamée par highlander03 et au vu de la réponse précédente, on dirait que highlander03 = vh...
    Qu’en est-il ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  7. #7
    Membre à l'essai
    d'accord merci
    pour le livre j'ai cherché sur le site d'Oreilly et je ne l'ai pas trouvé en français, c'est dommage ça m'aurais bien aidé

    Citation Envoyé par fsmrel
    Curieusement, la discussion a été entamée par highlander03 et au vu de la réponse précédente, on dirait que highlander03 = vh...
    Qu’en est-il ?
    pas du tout, je suis venu ici à partir du lien que vous avez mis dans un autre discussion.

    ça prouve juste que je ne suis pas le seul à ne pas maitriser les formes normales

  8. #8
    Expert éminent sénior
    Citation Envoyé par vh

    pour le livre j'ai cherché sur le site d'Oreilly et je ne l'ai pas trouvé en français, c'est dommage ça m'aurais bien aidé
    Il y a la grande référence, traduite en français, mais pour plus de 60 euros (quand on aime on ne compte pas...)

    http://www.amazon.fr/Introduction-b...dp/2711748383

    Sinon, attention, tout a été dit sur les formes normales, mais généralement de façon fantaisiste, façon Wikipedia qui commence très fort :

    Citation Envoyé par Wikipedia

    1FN - première forme normale : toute propriété dépend de la clé
    Cf. http://fr.wikipedia.org/wiki/Forme_...tionnelles%29

    Désolé. Selon la théorie relationnelle, toute relvar (variable relationnelle, informellement table SQL) est dotée d'au moins une clé candidate (cf. mon message du 20/02/2007) , sinon il s'agit d'un sac à doublons (bag). Qu’une relvar soit dotée d’au moins une clé candidate n’a donc rien à voir avec la normalisation.
    Pour mémoire, une clé candidate détermine chaque attribut (appelé propriété ci-dessus).

    Concernant la normalisation, on peut donc seulement écrire :

    Une relation (valeur prise par une relvar) est normalisée si et seulement si chacun de ses tuples contient exactement une valeur pour chacun de ses attributs (On dit encore de façon équivalente qu’elle est en première forme normale).

    En outre, une relvar est normalisée (1NF) par définition. (A ce sujet, je rappelle qu’un attribut peut être du type Relation, c’est-à-dire que ses valeurs sont alors des relations).

    Etc., etc. Je ne parlerai même pas de la BCNF façon Wikipedia...

    Pour finir, je signale qu'après avoir traité de la normalisation (toujours au sens 1NF du terme), Ted Codd a défini la 2e et la 3e formes normales : celles-ci ne revêtent plus aujourd'hui qu'un intérêt historique. La BCNF est plus contraignante mais pas très compliquée à appréhender. Pour vous éviter de faire défiler les messages de cette discussion, j’en rappelle la définition :

    Une table S est en forme normale de Boyce-Codd (BCNF) si et seulement si
    pour chaque dépendance fonctionnelle non triviale X -> Y satisfaite par S, X est une surclé de S.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  9. #9
    Membre émérite
    Bonjour,

    je voulais remercier fsmrel pour ces réponses de qualité sur la théorie relationnelle et les NF. Je sais que ça prend un certain temps mais tu n'as jamais été tenté par l'écriture ou la correction d'articles de wikipedia ? Tu pourrais apporter beaucoup sur les articles que tu as cités.

  10. #10
    Expert éminent sénior
    Bonjour,
    Citation Envoyé par vemolines

    tu n'as jamais été tenté par l'écriture ou la correction d'articles de wikipedia ?
    Il est évident que je suis navré de ce que Wikipedia propose concernant la normalisation. Je ne tiens pas particulièrement à y écrire ou corriger les articles qu’on y trouve, car manifestement c’est le dernier qui a rédigé qui a raison, ce qui n’est pas sain. On n’y gère pas d’historique (visible...) alors qu’avec developpez.com on peut débattre et suivre les discussions.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  11. #11
    Membre à l'essai
    Citation Envoyé par fsmrel
    (quand on aime on ne compte pas...)
    mais quand ce qu'on apprend peut nous rapporter de l'argent, on compte et on achète ce livre ;-)
    merci pour la référence

    Citation Envoyé par fsmrel
    façon Wikipedia qui commence très fort :
    même en temps que non spécialiste j'ai été choqué par la simplification "1FN = La clé. 2FN = Toute la clé. 3FN = Rien que la clé." (et la tête alouette ...)

    Citation Envoyé par fsmrel
    Pour vous éviter de faire défiler les messages de cette discussion, j’en rappelle la définition
    désolé mais encore une fois j'ai du remonter et redescendre plusieurs fois le temps de me rappeller les termes
    je vais enregistrer cette page sur mon disque ça va me servir de référence

    Citation Envoyé par fsmrel
    On n’y gère pas d’historique (visible...)
    toutes les modifications sont accessibles en cliquant sur "Historique" en haut, ce n'est pas ça que vous cherchez ?
    http://fr.wikipedia.org/w/index.php?...action=history

  12. #12
    Inactif  
    Les objects relation mapping tools demandent des clefs primaires

    avec les unique ont fait comment ? et quel intérets a t on ?

    une clef primaire composée suffit largement à mon avis ...

  13. #13
    Inactif  
    Ce message n'a pas pu être affiché car il comporte des erreurs.

  14. #14
    Membre à l'essai
    Citation Envoyé par *alexandre*
    Les objects relation mapping tools demandent des clefs primaires

    avec les unique ont fait comment ? et quel intérets a t on ?

    une clef primaire composée suffit largement à mon avis ...
    fsmrel a répondu là :
    http://developpez.net/forums/showthr...83#post1777683
    tu regardes toutes les clés candidates et tu choisis celle qui te fais des yeux doux

  15. #15
    Expert éminent sénior
    Bonsoir,

    A propos de Wikipedia
    Citation Envoyé par vh

    toutes les modifications sont accessibles en cliquant sur "Historique" en haut, ce n'est pas ça que vous cherchez ?
    Exact et merci pour l'information. Cela dit, je m’abstiendrai quand même...


    Citation Envoyé par *Alexandre*

    Citation Envoyé par fsmrel

    Considérons l’ensemble E des attributs Jockey, Cheval, Course, Dossard.

    Soit T la table correspondante. Celle-ci a pour entête :

    T (Jockey, Cheval, Course, Dossard)

    Le triplet (Jockey, Cheval, Course) peut-il être clé candidate ? Non.
    ????? la relation est determinée justement par le triplet (jockey,cheval,course)
    en quoi c est pas unique ? essaye d insérer 1,1,1 deux fois
    Ça n’est parce que l’on a une association (Jockey, Cheval, Course) que son identifiant se transforme en clé primaire. Je rappelle qu’une clé primaire, comme toute clé candidate, doit obéir à la règle d’unicité et à celle d’irréductibilité. Quand on dit que lors d’une course un jockey monte un seul cheval, le triplet ne peut pas être clé.
    En effet, si le triplet était clé, alors on pourrait insérer les valeurs suivantes dans la base de données, en violation de cette contrainte forte :

    (Course = 1, Jockey = 1, Cheval = 1)
    (Course = 1, Jockey = 1, Cheval = 2)

    C.Q.F.D.

    Citation Envoyé par *Alexandre*

    j avoue ne pas avoir eu le courrage de lire ton pavé, essaye d'être simple ....
    Merci du conseil. Ce qui précède montre quand même qu’il faut avoir un minimum de courage et lire un (bien modeste) pavé, pour éviter de commettre des grosses boulettes, et d’induire ses camarades à leur tour en erreur. Si c’est trop compliqué, résolvez-vous à changer d’orientation et gardez vos commentaires pour vous. Heureusement que vmolines et vh sont là pour exprimer une autre opinion.

    Citation Envoyé par *Alexandre*

    Les objects relation mapping tools demandent des clefs primaires....
    avec les unique ont fait comment ? et quel intérets a t on ?
    J’ai traité de la modélisation selon la théorie relationnelle.
    Dans l’instruction CREATE TABLE initiale, j’ai utilisé SQL Server pour injecter les 3 clauses UNIQUE. Maintenant, vous êtes quand même assez grand pour remplacer par exemple :

    UNIQUE (Course, Dossard) par PRIMARY KEY (Course, Dossard).

    Concernant cette contrainte et les 2 autres :

    UNIQUE (Course, Jockey)
    UNIQUE (Course, Cheval)

    Je crois que je ne vais quand même pas revenir sur leur intérêt. Elles expriment des règles de gestion fortes (et quand même évidentes). Si vous ne savez pas quoi faire de la clause UNIQUE avec vos outils, vérifiez qu’ils sont conformes au standard SQL et si tel n’est pas le cas, faites les faire évoluer ou changez-en.


    Citation Envoyé par *Alexandre*

    Citation Envoyé par fsmrel

    Un jockey a pu monter le même cheval, avec le même dossard dans des courses différentes.
    désolé mais c'est pas la même course ... date différente
    manque la date c est vrai (tu t appellerais pas Julien par hazard ? )
    Sans commentaire. Il manque aussi le nom du jockey, celui du cheval et l’âge du capitaine. Avant que je ne perde patience : en supposant que vous évoquiez les dates des courses, alors le quadruplet (Course, Jockey, Cheval, Date) viole la 2e forme normale. Exercice à votre intention : pourquoi ? (Un conseil : n’oubliez pas de commencer par en déterminer toutes les clés candidates).
    Et merci de ne plus venir polluer les discussions les mains dans les poches, des contrevérités et des commentaires vains, puérils et stupides plein la musette (sans compter les fautes d’orthographe). Vous dérangez tout le monde.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  16. #16
    Inactif  
    hello, un peu d'humour parfois ne fait pas de mal (et effectivement certains propos sont déplacés -passons-), alors j'essaye donc de déterminer quelles seraient les clefs candidates

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}
    k4 : {Course, Date}





    la connaissance d'une valeur de X, quelle qu’elle soit,
    implique la connaissance d’une seule valeur de Y si et seulement si, à chaque fois que deux tuples (lignes) de S ont même valeur pour X, alors ils ont même valeur pour Y (X est appelé le déterminant et Y le dépendant).

    serait erroné car

    pour DF1 : {Course, Jockey} -> Cheval pourrait donc donner

    {course 10 jockey 1} cheval 1
    {course 10 jockey 1} cheval 2

    Car pour une même course avec le même jockey le cheval (dépendant) pourrait être différent.

    Si j ai "bien" compris ?

    Par contre si je définis

    K1 : {Course, Jockey,Date}
    K2 : {Course, Cheval,Date}
    K3 : {Course, Dossard,Date}


    pour DF1 : {Course, Jockey,Date} -> Cheval

    {course 10 jockey 1 12.12.2008} cheval 1
    {course 10 jockey 1 12.12.2007} cheval 2

    Serait cette fois valide.Non ?

  17. #17
    Membre expert
    Bonjour,

    Citation Envoyé par *alexandre*
    en quoi c est pas unique ? essaye d insérer 1,1,1 deux fois
    Effectivement on ne pourra pas insérer 2 fois la même PK. On aura donc bien 1 triplet de valeurs uniques.
    Pour autant, dans ce cas la 3-aire ne permet pas d'empecher les anomalies d'insertion.
    Comme l'a déja fait remarquer fsmrel, rien n'empêche d'insérer dans la base 1 jockey participant à la même course, avec 2 chevaux différents (ou la réciproque).
    En partant des DF on obtient ce modèle.



    Ce qui au niveau physique donne ceci.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    create table dossard
    (
    courseid             numeric(6,0)           not null,
    iddossard            numeric(6,0)           not null,
    chevalid             numeric(6,0)           not null,
    jockeyid             numeric(6,0)           not null,
    constraint p_identifiant_1 primary key (courseid, iddossard),
    constraint f_participer foreign key (courseid) references course (courseid),
    constraint f_inscrire_c foreign key (chevalid) references cheval (chevalid),
    constraint f_inscrire_j foreign key (jockeyid) references jockey (jockeyid),
    unique (courseid, chevalid),
    unique (courseid, jockeyid) 
    );
    Ce qui est ce que proposait fsmrel. La relation n-aire est réduite en 2 relations et le modèle est bien en bcnf. Les contraintes uniques correspondant aux 2 DF (co+jo --> ch, et co+ch --> jo) empêchent les anomalies d'insertion.

  18. #18
    Inactif  
    Jolie comme résolution.

  19. #19
    Expert éminent sénior
    Citation Envoyé par TheLeadingEdge


    La relation n-aire est réduite en 2 relations et le modèle est bien en bcnf. Les contraintes uniques correspondant aux 2 DF (co+jo --> ch, et co+ch --> jo) empêchent les anomalies d'insertion.
    Imparable.
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  20. #20
    Expert éminent sénior
    Bonsoir,

    Citation Envoyé par *Alexandre*

    j'essaye donc de déterminer quelles seraient les clefs candidates

    K1 : {Course, Jockey}
    K2 : {Course, Cheval}
    K3 : {Course, Dossard}
    k4 : {Course, Date}
    Merci *Alexandre*, vous adoptez une attitude positive.
    Considérons maintenant la table T (Course, Jockey, Cheval, Dossard, Date).
    Je ne l’ai peut-être pas précisé, mais la contrainte d’unicité des surclés (donc des clés candidates) a un corolaire : l’ensemble K1 (même chose pour K2, etc.) est une surclé si et seulement si il détermine l’ensemble des attributs de la table T :
    DF1 : {Course, Jockey} -> {Course, Jockey, Cheval, Dossard, Date}

    ou (en vertu de la règle de décomposition inférée des axiomes d’Armstrong) :

    DF11 : {Course, Jockey} -> {Course}
    DF12 : {Course, Jockey} -> {Jockey}
    DF13 : {Course, Jockey} -> {Cheval}
    DF14 : {Course, Jockey} -> {Dossard}
    DF15 : {Course, Jockey} -> {Date}


    En notant que (un peu de vocabulaire ne fait pas de mal) :

    DF11 et DF12 sont des DF triviales,
    DF13 et DF14 sont des DF irréductibles à gauche (ou élémentaires, ou totales, ...)
    et DF15 est une DF réductible à gauche (ou partielle), c’est-à-dire que si la même course ne peut pas avoir lieu à des dates différentes, alors DF15 inclut la DF :

    DF16 : Course -> {Date}________ (Une course n’a lieu qu’à une date donnée)


    Dans ces conditions, concernant K4, la situation est la suivante :

    DF41 : {Course, Date} -> {Course, Date}
    {Course, Date} -/-> {Jockey, Cheval, Dossard} ____ (absence de DF)
    K4 n’est donc pas une surclé et a fortiori clé candidate. Sinon, si K4 était clé candidate, cela voudrait dire que pour une course donnée, à une date donnée, on aurait un seul jockey, un seul cheval et un seul dossard, ce qui ne serait pas fait pour attirer la foule des parieurs.



    la connaissance d'une valeur de X, quelle qu’elle soit,
    implique la connaissance d’une seule valeur de Y si et seulement si, à chaque fois que deux tuples (lignes) de S ont même valeur pour X, alors ils ont même valeur pour Y (X est appelé le déterminant et Y le dépendant).

    serait erroné car

    pour DF1 : {Course, Jockey} -> {Cheval} pourrait donc donner

    {course 10 jockey 1} cheval 1
    {course 10 jockey 1} cheval 2

    Car pour une même course avec le même jockey le cheval (dépendant) pourrait être différent.

    Si j ai "bien" compris ?


    Je rappelle la définition que j’ai donnée de la dépendance fonctionnelle :

    Soit X et Y deus sous-ensembles quelconques de l’entête d’une table S.

    S satisfait à la dépendance fonctionnelle (DF) X -> Y si et seulement si, à chaque fois que deux tuples (lignes) de S ont même valeur pour X, alors ils ont même valeur pour Y (X est appelé le déterminant et Y le dépendant).

    Si cette définition est erronée, ça craint, car on la doit à Ted Codd, l’inventeur du Modèle Relationnel de Données, qui l’a énoncée en 1971. S’il s’était trompé, ça se saurait ! Je pense donc plutôt que quelque chose vous a échappé.

    Considérons donc la DF : {Course, Jockey} -> {Cheval}.
    Par définition, si deux tuples t1 et t2 comportent la valeur <Course = 10, Jockey = 1> alors ils comportent la même valeur, soit <Cheval = 1> soit <Cheval = 2>, mais pas les deux à la fois.



    Par contre si je définis

    K1 : {Course, Jockey,Date}
    K2 : {Course, Cheval,Date}
    K3 : {Course, Dossard,Date}


    pour DF1 : {Course, Jockey,Date} -> {Cheval}

    {course 10 jockey 1 12.12.2008} cheval 1
    {course 10 jockey 1 12.12.2007} cheval 2

    Serait cette fois valide.Non ?

    Ça ne fonctionne toujours pas...
    En effet, la DF {Course, Jockey, Date} -> {Cheval}
    inclut la DF {Course, Jockey} -> {Cheval}, et comme on vient de le voir, pour une course et jockey donnés vous pouvez insérer soit la valeur <Cheval = 1> soit la valeur <Cheval = 2>, mais pas les deux à la fois...

    En conclusion, *Alexandre*, avez-vous encore des points d’incompréhension ? Si tout va bien, je vous suggère une nouvelle fois de démontrer que quadruplet (Course, Jockey, Cheval, Date) viole la 2e forme normale...
    Ceci fait, inspirez-vous du MCD imparable de TheLeadingEdge pour y intégrer les dates des courses...
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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