Bonsoir,
Tout en commentant la réponse de Paprick, je propose ici une approche « relationnelle » qui pourra intéresser les plus jeunes, mais aussi les anciens comme Escartefigue et CinePhil qui seront en droit d’opposer d’éventuelles critiques...
Envoyé par
Paprick
une fort belle étoile !
Forcément, car c’est bientôt Noël !
Envoyé par
Paprick
Vous l'aurez compris, Looping se contente de retirer, dans la clé primaire de l'association, l'identifiant de la classe d'entités ciblée par la CIF.
Certes ! Mais à mon sens il serait préférable de ne minimaliser les clés qu’une fois toutes les CIF prises en compte. Je m’explique. Je passe dans le Relationland où je me sens plus à l’aise, et là j’utilise la panoplie des outils me permettant de structurer les données sous forme de relvars (variables relationnelles), traduites ensuite en SQL sous forme de tables.
Si au beau pays qu’est Merise on exploite les règles de gestion pour produire un MCD où figurent les CIF et autres contraintes (exclusion, inclusion, etc.), au Relationland on exploite bien sûr aussi ces règles, mais c’est dans un 1er temps pour produire toutes les dépendances fonctionnelles qu’on peut en inférer (les dépendances multivaluées et les dépendances de jointure n’interviendront que lors des dernières étapes de normalisation, c’est-à-dire vérification de la quatrième et de la cinquième formes normales). Les dépendances fonctionnelles sont en effet les briques de base qui serviront pour bâtir l’édifice.
Etapes de travail au Relationland
1re étape : collecter les règles de gestion, comme en Merise (Escartefigue et CinePhil seront d’accord !)
2e étape : traduire ces règles de gestion en dépendances fonctionnelles.
Si je reprends mon message précédent, la toute 1re règle qui se présente est la suivante, ayant servi pour définir l’association PARTICIPER du MCD (cf. Figure 1) :
(RG1) Lors de la course C, le jockey J monte le cheval H, qui à cette occasion a le numéro N, et supporte le poids P.
Après avoir retourné cet énoncé (moyennement formel, un peu ambigu) dans tous les sens, la traduction sous forme de dépendance fonctionnelle dans la langue du Relationland est la suivante :
(DF1) {course, jockey, cheval, numero} → {poids}
Ou encore, pour reprendre la dernière image du message précédent de Paprick :
(DF2) {course, jockey, cheval} → {poids, numero}
Maintenant, parmi les règles de gestion figurent les CIF
CIF1 : COURSE X JOCKEY → CHEVAL
CIF2 : COURSE X CHEVAL → JOCKEY
CIF3 : COURSE X CHEVAL → NUMERO
CIF4 : COURSE X NUMERO → CHEVAL
Et je m’empresse de les traduire à leur tour sous forme de dépendances fonctionnelles :
(DF3) {course, jockey} → {cheval}
(DF4) {course, cheval} → {jockey}
(DF5) {course, cheval} → {numero}
(DF6) {course, numero} → {cheval}
L’ensemble des dépendances fonctionnelles dont je dispose est désormais le suivant :
(DF1) {course, jockey, cheval, numero} → {poids}
(DF2) {course, jockey, cheval} → {poids, numero}
(DF3) {course, jockey} → {cheval}
(DF4) {course, cheval} → {jockey}
(DF5) {course, cheval} → {numero}
(DF6) {course, numero} → {cheval}
3e étape : calculer les fermetures dépendances fonctionnelles.
Il s’agit pour chaque dépendance fonctionnelle de produire le plus grand ensemble d’attributs qui en constituent le dépendant (la partie droite de la DF). Pour calculer les fermetures, on peut utiliser les axiomes d’Armstrong, ou pour gagner du temps se servir par exemple de l’algorithme du seau à dépendants, proposé par Bernstein en 1976. Le résultat est le suivant, DF par DF :
F1+ = {course, jockey, cheval, numero}+ = {course, jockey, cheval, numero, poids}
F2+ = {course, jockey, cheval}+ = {course, jockey, cheval, numero, poids}
F3+ = {course, jockey}+ = {course, jockey, cheval, numero, poids}
F4+ = {course, cheval}+ = {course, jockey, cheval, numero, poids}
F5+ = {course, numero}+ = {course, jockey, cheval, numero, poids}
Chaque fermeture contient l’en-tête de la variable relationnelle PARTICIPER, c’est-à-dire qu’elle est en droit de postuler à être clé candidate de cette variable.
4e étape : déterminer les clés candidates de la variable relationnelle PARTICIPER.
Comme annoncé, chaque fermeture contenant l’en-tête de la variable relationnelle PARTICIPER peut postuler à être clé candidate de cette variable :
K1 = {course, jockey, cheval, numero}
K2 = {course, jockey, cheval}
K3 = {course, jockey}
K4 = {course, cheval}
K5 = {course, numero}
Les ensembles K3, K4 et K5 peuvent prétendre à être clés candidates, car irréductibles (en ôter un attribut leur ferait perdre la propriété d’unicité).
K1 et K2 sont recalées car réductibles (K3, K4, K5 en sont des sous-ensembles).
Pour résumer, les clés candidates de la variable PARTICIPER sont les suivantes :
K3 = {course, jockey}
K4 = {course, cheval}
K5 = {course, numero}
Ce travail terminé, on peut enfin passer à la déclaration de la variable (en Tutorial D) :
VAR PARTICIPER BASE RELATION
{course INTEGER,
jockey INTEGER,
cheval INTEGER,
numero INTEGER,
poids NUMERIC (4,2)}
KEY {course, jockey}
KEY {course, cheval}
KEY {course, numero}
;
Ce à quoi, pour être complet, il faut bien sûr ajouter les clés étrangères.
En traduisant en SQL :
CREATE TABLE PARTICIPER
(
course INTEGER,
jockey INTEGER,
cheval INTEGER,
numero INTEGER,
poids NUMERIC (4,2)
, CONSTRAINT PARTICIPER_K1 UNIQUE (course, jockey)
, CONSTRAINT PARTICIPER_K2 UNIQUE (course, cheval)
, CONSTRAINT PARTICIPER_K3 UNIQUE (course, numero)
)
;
Pour qu’il n’y ait pas de jalouses parmi les miss clés candidates, aucune n’est élue miss clé primaire (la norme SQL n’est pas contre, idem par exemple pour PostgreSQL ou SQL Server) : au nom du rasoir d’Ockham (« Pluralitas non est ponenda sine necessitate »), le concept de clé primaire est à considérer comme obsolète et ça fait belle lurette que C. J. Date l’a fait disparaître de la théorie relationnelle. La clé primaire serait plus égale que les autres ? En faire le choix relèverait d’arguments en fait psychologiques.
Envoyé par
Paprick
dans la mesure où plusieurs clés sont potentiellement candidates, comment exprimer celle que l'on souhaite retenir pour le MLD et le schéma relationnel correspondant ?
...
dans la mesure où toutes les CIF pourraient être prises en compte, comment choisir parmi les clé candidates... et comment exprimer ce choix dans le MCD ?
Or donc, ayant allègrement passé le concept de clé primaire au rasoir d’Ockham, je n’ai plus à choisir, à élire une miss clé primaire ravalant les autres au rang de dauphines (clés alternatives)...
No primary key!
Bref :
Envoyé par
Paprick
le code SQL est correct...
Oui, il n’est pas faux, mais toutefois incomplet du fait de la non prise en compte de règles de gestion qu’il faudra réinjecter sous forme de clés alternatives...
Partager