Bonsoir,
Envoyé par
Miko95
pour le conseil que vous m'avez donné pour les noms (exemple du père et fils), est ce qu'il est nécessaire de créer une nouvelle table?
Créer une table des noms et une autre des prénoms ? Certes non ! Sinon il faudrait généraliser cette façon de faire pour l’ensemble des attributs de l’ensemble des tables... A l’inverse, je voulais vous signifier que la table PPhoneNumber des numéros de téléphone ne se justifiait pas plus qu’une table des prénoms, etc.
Injection de contraintes au niveau SQL :
Quand vous passerez du MLD au script de création des tables, vous définirez les contraintes simples à mettre en œuvre (outre évidemment l’intégrité référentielle).
Par exemple :
1
2
3
4
5
6
| CREATE TABLE PERSON
( IdPerson PLS_INTEGER NOT NULL
, ...
, Gender CHAR(1) NOT NULL CHECK (Gender in ( '1' , '2'))
, ...
) ; |
Respect des formes normales :
La 1NF est respectée car chaque attribut est de type scalaire (atomique).
Au sujet de la 2NF. Vous écrivez :
la règle 2NF est respectée de façon triviale (à cause de la présence d'une clé à un seul attribut ou de l'absence d'autres attributs à part la clé).
En fait, vous faites référence à une définition très affaiblie de la 2NF, car vous parlez de « la clé » alors que toutes les clés de la table sont concernées. Personnellement je fais référence à la définition donnée par son inventeur, Ted Codd :
A relation R is in second form normal if it is in first normal form and every non-prime attribute of R is fully dependant on each candidate key of R.
Concernant cette définition :
Dans le contexte SQL (vision déformée du Modèle Relationnel de Données inventé par Codd), vous pouvez remplacer « relation » par « table ».
Quant au concept de clé candidate, voyez la discussion entamée par highlander03, notamment le 4e post.
Un « non-prime attribute » est un attribut qui ne participe à aucune clé candidate de R.
Je rappelle au besoin la définition de la dépendance fonctionnelle totale (full dependency) :
Étant donné deux sous-ensembles d’attributs X et Y de l’en-tête d’une relation R, la dépendance fonctionnelle X → Y est totale (ou irréductible, ou élémentaire) si :
— Y est singleton (Y ne contient qu’un seul élément, c'est-à-dire un seul attribut de l’en-tête de R) ;
— La dépendance fonctionnelle n’est pas triviale, c'est-à-dire que Y n’est pas inclus dans X (tout ou partie) ;
— Il n’existe pas Z strictement inclus dans X tel que Z → Y.
Avant d’affirmer qu’une table respecte la 2NF, il est donc nécessaire d’avoir fourni la liste de ses clés candidates et pas seulement une d’entre elles.
Vous évoquez le cas de la table Appointment : Êtes-vous certain que la clé que vous avez retenue est satisfaisante ? En l’état, un médecin et un patient ne pourront se rencontrer qu’une seule fois... En revanche, au même moment, un patient pourra consulter plus d’un médecin et un médecin pourra recevoir plus d’un patient, tout cela fait un peu désordre...
Concernant la 3NF. Vous avez retenu la définition suivante :
la table doit être en 2NF et il faut que tout attribut autre que ceux de la clé ne dépende pas d'un autre ensemble d'attributs autres que la clé.
Là encore, vous mentionnez « la clé », alors que toutes les clés candidates de la table sont parties prenantes. Toujours de Ted Codd:
A relation R is in third form normal if it is in second normal form and every non-prime attribute of R is non-transitively dependant on each candidate key of R.
Dans ces conditions, votre problème a sa solution, alors que votre définition vous embarrasse, je vous cite :
La définition me pose un problème pour la table Person par exemple, car IdNumber n'est pas un attribut de la clé primaire(même si c'est une clé) et qu'il implique forcément tout autre attribut de la table car c'est une clé.
En passant, n’écrivez pas « il implique », mais « il détermine » (revoyez le 4e post de highlander03).
Au fait, quel est le rôle de l’attribut IdNumber ?
Et veuillez fournir l'inventaire complet des clés des tables, car en l'occurrence votre représentation graphique ne suffit pas.
Répondre avec citation
Partager