Discussion :

[*alexandre*]

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.

[*alexandre*]

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)

[*alexandre*]

Ç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.

[*alexandre*]

Pour résumer

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

[vh]

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

[fsmrel]

Bonsoir,

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}

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.

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 ?

[vh]

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

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

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"

[fsmrel]

Bonjour,

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.

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).

[TheLeadingEdge]

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.

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 +

[fsmrel]

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 ?

[TheLeadingEdge]

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 :

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

[fsmrel]

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