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 :

Unicité d'une clef composée [Normalisation]


Sujet :

Schéma

  1. #21
    Inactif  
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 189
    Par défaut
    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é.
    Mon idée était plutot de démontrer l'invalidité de la règle d'unicité étant donné que pour le même df plusieurs valeurs possibles étaient retournés. Dans l'exemple que je citais.

    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...
    J'avoue que j'ai découvert hier soir avec vos postes l'existence de ce formalisme.

    Dans la définition que j'ai cité de

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    K1 : {Course, Jockey,Date}
    K2 : {Course, Cheval,Date}
    K3 : {Course, Dossard,Date}
    Je pensais qu'il fallait résoudre, et vérifier l'unicité pour chacun des couples définis dans un UNIQUE {Course, Jockey,Date},

    une course, un jockey pour une date donnée
    une course, un cheval pour une date donnée
    une course, un dossard pour une date donnée

    et que cet ensemble représente enfin une clef unique sur l'ensemble des valeurs

    Je vais relire vos messages d'hier.

  2. #22
    Inactif  
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 189
    Par défaut
    Je reprend

    Si je comprend bien, étant donnée la résultante d'une surclef 'un tuple ne peut
    apparaître qu'une et une seule fois.

    On supprime donc toutes les clefs candidates pouvant être amenés à des résultats récurents.

    Dans mon cas toutes les clefs candidates sans la variable date.

    Le bncf est valide seulement si le df (x,y,z) /j ai ajouté une var pour les dates) est définis comme surclef.

    Donc {Jockey, Course,Dossard,,Date} = surclef == bncf valide

    (une fois encore c'est tout nouveau comme notion pour moi)

  3. #23
    Inactif  
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 189
    Par défaut
    Ç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 effet ... Ce me semble complexe de modéliser une bd avec ses notions.

  4. #24
    Inactif  
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2006
    Messages : 2 189
    Par défaut
    Pour résumer

    si df (a,b,c) -> x inclus (a,b) inclus (a,c) etc ?

  5. #25
    vh
    vh est déconnecté
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 24
    Par défaut
    Citation Envoyé par *alexandre*
    Donc {Jockey, Course,Dossard,,Date} = surclef == bncf valide
    d'après ce que j'ai compris (donc à confirmer par notre professeur fsmrel) on a la dépendance fonctionelle non trivialle Course -> Date
    donc pour repecter la BCNF il faudrait que "Course" soit une surclé de la table. Or il peut y avoir plusieurs fois la même valeur de "Course" donc ce n'est pas une surclé et donc la table ne respecte pas la BCNF

    Mais fsmrel a indiqué que la table ne respecte déjà pas la 2me forme normale à cause de la dépendance fonctionelle Course -> Date donc forcement elle ne peut pas respecter la BCNF

  6. #26
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 211
    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 211
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Citation Envoyé par vh
    d'après ce que j'ai compris (donc à confirmer par notre professeur fsmrel) on a la dépendance fonctionelle non trivialle {Course} -> {Date}
    Étant donné que nous ne nous inscrivons pas (encore) dans le cadre d’un univers quantique, dans lequel l’histoire du chat de Schrödinger nous inciterait à mettre à la poubelle tout ce dont nous débattons, on peut émettre l’hypothèse qu’une course donnée ne peut avoir lieu simultanément aux temps t1 et t2.
    Dans ces conditions, la DF {Course} -> {Date} permet effectivement d’interdire l’ubiquité. Cette DF n’est pas triviale, contrairement à celles-ci :
    {Course} -> {Course}
    {Date} -> {Date}

    Citation Envoyé par vh
    Donc pour repecter la BCNF il faudrait que "Course" soit une surclé de la table. Or il peut y avoir plusieurs fois la même valeur de "Course" donc ce n'est pas une surclé et donc la table ne respecte pas la BCNF.
    On ne peut mieux dire.


    Citation Envoyé par vh
    Mais fsmrel a indiqué que la table ne respecte déjà pas la 2me forme normale à cause de la dépendance fonctionelle Course -> Date donc forcement elle ne peut pas respecter la BCNF.
    Oui.
    C’est l’occasion de rappeler la définition de la 2e forme normale (2NF), pour ceux qui auraient le courage de poursuivre. Je fais observer que (tout comme la 3NF), la 2NF est moins contraignante que la BCNF, les mailles du filet sont trop lâches, elle est donc moins intéressante. Si l’on ne veut pas s’encombrer la tête de trop de définitions et s’il n’y en a qu’une à retenir, c’est bien celle de la BCNF.

    Quelques définitions préalables :

    Soit une table S, X un sous-ensemble quelconque d’attributs, et A un attribut quelconque de S.
    Une dépendance fonctionnelle X -> {A} est dite réductible si elle n’est pas triviale et s’il existe Y strictement inclus dans X tel que Y -> {A}.

    Ainsi, la dépendance fonctionnelle :
    DFa : {Course, Date, Jockey} -> {Cheval}
    est réductible car il existe {Course, Jockey} strictement inclus dans {Course, Date, Jockey} tel que :
    DFb : {Course, Jockey} -> {Cheval}
    Une dépendance fonctionnelle réductible est encore appelée partielle.
    Une dépendance fonctionnelle est dite irréductible quand elle n’est ni triviale ni réductible.
    Une dépendance fonctionnelle irréductible est encore appelée totale ou élémentaire.

    Pour en venir à la définition de la 2NF :
    Une table S est en 2NF si et seulement si chaque attribut A de S n’appartenant à aucune une clé candidate K de S est tel que la DF : K -> {A} soit irréductible.
    N.B. Il est généralement précisé dans cette définition que la table S doit être en 1NF. Une fois de plus, je rappelle qu’au sens du Modèle Relationnel de Données, une relvar (variable relationnelle, informellement table) est normalisée 1NF par définition (un attribut peut être du type Relation, c’est-à-dire que ses valeurs sont alors des relations).

    Variation sur le thème de la date.

    Les événements sont généralement datés. Revoyons donc l’univers du discours (celui des courses hippiques) en prenant pour point de départ le MCD proposé par TheLeadingEdge. On définit donc une entité-type Course ayant pour objet l’abstraction de ce que l’on connaît du monde des Grands Prix et autres courses hippiques. De la même façon, on définit une entité-type Jockey (utilisée aussi pour décrire les drivers) et une entité-type Cheval.

    A titre d’exemple, une course (ou un prix) a un nom : "Prix d’Amérique", elle est en l’occurrence hébergée par l’hippodrome de Vincennes (au stade où l’on en est, on ne tiendra pas compte des aléas faisant qu’exceptionnellement, la course ait eu lieu sur un autre hippodrome). L’entité-type Course possède évidemment d’autres propriétés que les spécialistes du syndicat hippique national ne manqueront pas de proposer.

    Au niveau logique, la table Course dérivée a pour entête (clé primaire soulignée) :

    Course (Course_Id, Course_Nom, Course_Lieu, ...)

    En ayant choisi ce point de départ particulier, on doit reconnaître que le couple {Course, Date} subit un glissement sémantique. S’il ne s’agit plus d’exprimer une contrainte telle que "La même course ne peut avoir lieu simultanément aux temps t1 et t2" mais plutôt de décrire le résultat des courses, édition par édition, donc leur historique :

    "Lors de l’édition 1956, Gélinotte a participé au Prix d’Amérique, drivée par Charlie Mills portant le dossard 5 et pris la 1re place, puis en 1957 on a repris les mêmes, etc."

    Une entité-type Edition, donc une table du même nom pointent leur museau, porteuses des attributs spécifiques de chaque édition (temps du vainqueur, état du terrain, montant du jackpot, tous attributs jugés utiles par les gens du syndicat hippique...)

    Edition (Course_Id, Course_Date_Id, Course_Date, Temps_Vainqueur, ...)

    Pour finir, on s’intéresse aux résultats des courses, édition par édition : les jockeys (ou drivers) ayant participé, avec quel cheval, quel dossard et leur classement. On met donc en œuvre une table Résultat issue de l’entité-type Dossard du MCD initial (mais "datée") :

    Résultat (Course_Id, Course_Date_Id, Dossard_Id , Jockey_Id, Cheval_Id, Place, ...)

    Et les DF :
    DF1 : {Course, Jockey} -> {Cheval}
    DF2 : {Course, Jockey} -> {Dossard}
    DF3 : {Course, Cheval} -> {Jockey}
    DF4 : {Course, Cheval} -> {Dossard}
    DF5 : {Course, Dossard} -> {Jockey}
    DF6 : {Course, Dossard} -> {Cheval}
    Sont à faire évoluer ainsi (Date signifiant Date de la course (Course_Date_Id)) :
    DF1’ : {Course, Date, Jockey} -> {Cheval}
    DF2’ : {Course, Date, Jockey} -> {Dossard}
    DF3’ : {Course, Date, Cheval} -> {Jockey}
    DF4’ : {Course, Date, Cheval} -> {Dossard}
    DF5’ : {Course, Date, Dossard} -> {Jockey}
    DF6’ : {Course, Date, Dossard} -> {Cheval}
    Le paquet des instructions Create Table est en conséquence le suivant :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
     
    Create TABLE Course
    (      Course_Id    Int        Not Null, 
           Course_Nom   Char(32)   Not Null,
           Course_Lieu  Char(32)   Not Null,
         Primary key (Course_Id)
    ) ;
    
    Create TABLE Jockey
    (      Jockey_Id              Int        Not Null, 
           Jockey_Nom             Char(32)   Not Null,
         Primary key (Jockey_Id)
    ) ; 
    
    Create TABLE Cheval
    (      Cheval_Id              Int        Not Null, 
           Cheval_Nom             Char(32)   Not Null,
           Cheval_Date_Naissance  Int        Not Null,
           Propriétaire           Char(32)   Not Null,
         Primary key (Cheval_Id)
    ) ; 
    
    Create TABLE Edition
    (      Course_Id        Int        Not Null, 
           Course_Date_Id   Int        Not Null,
           Course_Date      Int        Not Null,
           Temps_Vainqueur  Int        Not Null, -- en secondes
         Primary key (Course_Id, Course_Date_Id),
         Unique      (Course_Id, Course_Date),
         Foreign Key (Course_Id) References Course,
    ) ;
    CREATE TABLE Resultat
    (      Course_Id       Int       Not Null, 
           Course_Date_Id  Int       Not Null,
           Dossard_Id      Int       Not Null,
           Jockey_Id       Int       Not Null, 
           Cheval_Id       Int       Not Null, 
           Place           Int       Not Null,  
        Primary key (Course_Id, Course_Date_Id, Dossard_Id),
        Unique (Course_Id, Course_Date_Id, Jockey_Id),
        Unique (Course_Id, Course_Date_Id, Cheval_Id), 
        Foreign Key (Course_Id, Course_Date_Id) References Edition,
        Foreign Key (Jockey_Id) References Jockey,
        Foreign Key (Cheval_Id) References Cheval
    ) ;
    
    Insert Into  Course   Values (1, 'Prix d''Amérique', 'Vincennes' ) ;
    Insert Into  Jockey   Values (1, 'Charlie Mills') ;
    Insert Into  Jockey   Values (2, 'Alexandre') ;
    Insert Into  Cheval   Values (1, 'Gélinotte', 1950, 'Mme S. Karle') ;
    Insert Into  Cheval   Values (2, 'Totoche', 1951, 'TheLeadingEdge') ;
    Insert Into  Edition  Values (1, 1, 1956, 82) ;
    Insert Into  Edition  Values (1, 2, 1957, 80) ;
    
    Insert Into  Resultat Values (1, 1, 5, 1, 1, 1) ;
    Insert Into  Resultat Values (1, 1, 3, 2, 2, 2) ;
    Insert Into  Resultat Values (1, 2, 9, 1, 1, 1) ;
    Etc.
    Si des erreurs se sont glissées, désolé.

    Exercice : manque-t-il des DF irréductibles ?
    (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. #27
    vh
    vh est déconnecté
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 24
    Par défaut
    Citation Envoyé par fsmrel
    Si l’on ne veut pas s’encombrer la tête de trop de définitions et s’il n’y en a qu’une à retenir, c’est bien celle de la BCNF.
    magnifique, intuitivement je pensais que une (x+1)FN couvre une xFn mais je n'osais pas fare le raccourci sans démonstration théorique
    là vous n'avez pas fait de démonstration mais je vous crois sur parole et j'enregistre la BCNF dans ma tête comme but à atteindre sur le papier avant de commencer à développer
    et comme je suis perfectionniste je reviendrai ici apprende les formes normalles 4 et 5

    Citation Envoyé par fsmrel
    En ayant choisi ce point de départ particulier, on doit reconnaître que le couple {Course, Date} subit un glissement sémantique.
    c'est ce que je pensais en voyant vos nouvelles tables donc vous m'excuserez de ne pas lire toutes les explications que vous avez écrites au sujet de cette nouvelle version

    Citation Envoyé par fsmrel
    Exercice : manque-t-il des DF irréductibles ?
    d'après votre définition, une DF est irreductibles par rapport à d'autre DF mais là par rapport aux DF' 1 à 6 je n'en vois pas

    par contre intuitivement la structure de votre nouvelle table "Resultat" ne me plait pas
    je pense que cela vient de la DF {Course_Date} -> {Course} qui fait que le champ "Course_Date_id" peut être ôté de la table "Resultat"

  8. #28
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 211
    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 211
    Billets dans le blog
    16
    Par défaut
    Bonjour,

    Citation Envoyé par vh
    Citation Envoyé par fsmrel
    Si l’on ne veut pas s’encombrer la tête de trop de définitions et s’il n’y en a qu’une à retenir, c’est bien celle de la BCNF.
    intuitivement je pensais que une (x+1)FN couvre une xFn mais je n'osais pas fare le raccourci sans démonstration théorique
    là vous n'avez pas fait de démonstration mais je vous crois sur parole et j'enregistre la BCNF dans ma tête comme but à atteindre sur le papier avant de commencer à développer
    Si ce n’est pas encore fait, il est temps pour vous d’acquérir un ouvrage de référence. Le plus complet et le plus pertinent sur le sujet est celui de Chris Date (environ 750000 exemplaires vendus à ce jour) :

    C.J. Date. An Introduction to Database Systems, 8th edition. (Pearson - Addison-Wesley)
    http://www.amazon.com/dp/0321197844?...KC5YNS9WG724E&

    La version française existe (je ne l’ai pas encore acquise, mais mon exemplaire en anglais est sérieusement écorné...) :

    C.J. Date. Introduction aux bases de données, 8e édition (Vuibert)
    http://www.amazon.fr/Introduction-ba.../dp/2711748383

    Attention, Date cite les définitions traditionnelles et incomplètes de la 2NF et de la 3NF, où l’on ne parle pas de clés candidates mais seulement de clés primaires. Les définitions que je donne sont extraites de son dictionnaire (100 pages) qui tient dans la poche (et que j’ai toujours dans la mienne) :

    C.J. Date. The Relational Database Dictionary (O’Reilly)
    http://www.oreilly.com/catalog/relationaldb/

    Des armées de mathématiciens ont écrit sur la normalisation et montré qu’une (x+1)FN couvre une xFn. Attention, il y a des hurluberlus qui à partir de prémisses fausses, arrivent à vous démontrer qu’une table en 4e ou en 5e forme normale n’est pas en 3e forme normale !
    J’espère avoir un jour le temps d’exposer le démontage que j’ai fait de la démonstration exposée par un monsieur agrégé de ceci + DEA de cela + ... et professeur d’informatique...
    En l’occurrence, outre qu’il faille être à l’aise avec la 4NF, la difficulté pour quelqu’un qui n’est pas assez rôdé à la théorie de la normalisation est de percevoir le sophisme du coupable...
    Je ne résiste pas à la tentation de citer un court extrait de la démonstration du professeur d’informatique :
    "Un Tableau en Quatrième Forme Normale n’est pas en Troisième Forme Normale, ni même en Deuxième, tout simplement parce qu’il n’est pas en Première Forme Normale. En effet, la condition essentielle pour qu’un Tableau soit en Première Forme Normale est l’existence d’une Clef."
    Gloups ! Pour la nième fois, je rappelle le refrain :

    Une table est en 1NF si et seulement si pour chaque valeur légale de cette table, chaque tuple contient exactement une valeur pour chaque attribut.


    Citation Envoyé par vh
    intuitivement la structure de votre nouvelle table "Resultat" ne me plait pas
    je pense que cela vient de la DF {Course_Date} -> {Course} qui fait que le champ "Course_Date_id" peut être ôté de la table "Resultat"
    Je comprends parfaitement votre remarque. J’ai oublié de préciser que j’utilisais l’identification relative, symbolisée au niveau du MCD de TheLeadingEdge par la mise entre parenthèses (convention utilisée par l’AGL PowerAmc) de la cardinalité 1,1 associée à la patte connectant l’entité-type Dossard et l’association-type Participer.

    Ainsi, j’ai utilisé l’identification relative pour connecter Edition sur Course :

    La course 1 se décline en
    ________Course_Id__Course_Date_Id
    Edition_______1_________1
    ________ ____1_________2
    ______ ______1_________3
    ____________...
    La course 2 se décline en
    ________Course_Id__Course_Date_Id
    Edition_______2_________1
    ________ ____2_________2
    ______ ______2_________3
    ____________...
    Les valeurs 1, 2, 3, etc. prises par Course_Date_Id numérotent les éditions successives d’une course (remise à 1 des compteurs pour chaque course).

    En notant que, puisque {Course_Id, Course_Date} est clé candidate, de manière équivalente, les courses se déclinent ainsi :

    ________Course_Id__Course_Date
    Edition_______1_______1956
    ________ ____1_______1957
    ______ ______1_______1960
    ____________...

    ________Course_Id__Course_Date
    Edition_______2_______1956
    ________ ____2_______1957
    ______ ______2_______1958
    ____________...

    Vous pouvez constater, au niveau de la table Edition, que la date à laquelle a eu lieu une course ne vérifie pas la DF :
    {Course_Date} -> {Course}
    En effet, il y a eu plus d’une course en 1956...

    Pour mémoire, si je n’ai pas utilisé l’attribut Course_Date pour participer à la clé primaire, c’est au nom de l’invariance de celle-ci (interdiction pour l’utilisateur de modifier une valeur de clé primaire pouvant se propager en cascade dans la base données, comme c’est le cas ici).
    (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. #29
    Membre éprouvé
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Par défaut
    Re,

    Ma 1ere proposition ne me plaisait que moyennement. Celle ci me semble plus complète. J'y ai intégré (au moins les plus significatives) les évolutions apportées par fsmrel à la question initiale.

    Notes : J'ai omis de représenter les id. dans le graphe, mais comme il s'agit principalement de Identity, ça n'a pas vraiment d'importance.
    Egalement, pour des questions (évidentes ?) de longueur du message, je n'ai pas mis la matrice des DF, mais elle n'est guère plus complexe que la 1ere.



    Citation Envoyé par vh
    je reviendrai ici apprendre les formes normales 4 et 5
    Bonne idée, on risque de faire tomber le record du plus grand nombre de réponses ds 1 thread.

    A +

  10. #30
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 211
    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 211
    Billets dans le blog
    16
    Par défaut
    Grand Prix Merise 2007 à Développez.com, résultats :

    Vainqueur TheLeadingEdge en 29 tours.

    Peut-être un petit oubli : Table Engage, une clause UNIQUE (editionid, dossard) absente ?

    ________________

    La 4e forme normale : pourquoi pas ?
    (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.

  11. #31
    Membre éprouvé
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Par défaut
    Citation Envoyé par fsmrel
    Table Engage, une clause UNIQUE (editionid, dossard)
    Oops ...
    Bien vu.
    Bien évidemment ne pas oublier les clefs alternatives.
    On peut ajouter UNIQUE (courseId, numero) également.

    1 peu d'humour pour finir :
    Citation Envoyé par fsmrel
    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.
    la même chose dite par Date. J'ai retrouvé cette citation ds 1 de ses bouquins sur les papiers de Codd. Qd les gurus se lachent ça donne ça :
    C.J. Date a chanté :
    It was thirty years ago today
    Dr Edgar showed the world the way
    His relations won't go out of style
    They're guaranteed to last a while
    So may i introduce to you
    The act you've know for all these years
    Dr Edgar's data model band.
    cf
    http://www.amazon.fr/gp/music/clipse...284093-7016952

  12. #32
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 211
    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 211
    Billets dans le blog
    16
    Par défaut BCNF et plus, si affinités
    Citation Envoyé par vh
    comme je suis perfectionniste je reviendrai ici apprende les formes normalles 4 et 5
    Faites seulement !

    Mais pour éviter d'en passer par des copier/coller, je vous demande de vous reporter au message dans lequel je traite de la 4NF, à l'attention de Sat478.

    CF. http://www.developpez.net/forums/sho...d.php?t=358397
    (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.

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Incrémentation avec une clef composée
    Par JaimeLannister dans le forum Développement Web en Java
    Réponses: 0
    Dernier message: 08/03/2013, 02h25
  2. Impact d'une clef primaire multi composée.
    Par Berserk50 dans le forum Modélisation
    Réponses: 3
    Dernier message: 22/09/2011, 15h27
  3. Unicité d'une clef composée
    Par highlander03 dans le forum Langage SQL
    Réponses: 3
    Dernier message: 20/02/2007, 12h36
  4. Réponses: 2
    Dernier message: 19/03/2005, 23h09
  5. Comment comment définir une clef primaire dans une table??
    Par nek_kro_kvlt dans le forum Bases de données
    Réponses: 4
    Dernier message: 07/02/2005, 21h06

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