Discussion :

[robocop333]

Bonjour,
Svp, Je voudrai connaitre la liste complétte des régles de passage du modéle objet (diagramme de classe) vers un model relationnel (bdd relationnel).

Merci beaucoup.

Aussi j'aimerai savoir si les tables que j'ai obtenue à partir du diagramme de classe que voici:
http://uploads.imagup.com/member/1210353216_classe.png
Sont en 1ere et 2eme et 3eme forme normale.
Voici la liste des tables que j'ai:

Equipe( intitule, theme, date_creation, actif ).

Chercheur( matricule, intitule_equipe, est_chef_equipe, grade_recherche, grade_enseignement, prenom, nom, url_page_web,fax, adr_professionnelle, adr_personnelle, diplome, email, tel, date_naissance, actif, photo ).

Compte( login, matricule_chercheur, pass, est_admin ,date_creation_compte, date_derniere_connexion ).

Projet( code_projet, matricule_chef_projet, intitule_equipe, intitule, date_depart, date_fin, type_projet, resume, valide ).

Chercheur_Projet ( matricule_chercheur, code_projet ).

Publication( id, titre, domaine, type, resume, fichier, nbr_pages, acces, valide ).

Chercheur_Publication( matricule_chercheur, id_publication ).

Les tables dérivé de publication:
Polycopie( id_publication, maison_edition, annee )
Livre( ... ) etc .....

Mot_cle( mot_cle ).

reference_publication (mot_cle, id_publication ).
reference_projet (mot_cle, id_publication ).

Ces tables sont-elles en 3eme forme normale ?

Et est ce qu'on peut enlever la table mot-clé et utilisé seulement les tables intermédiaires en relation avec mot clé (càd: reference_publication et reference_projet) ? Car mot clé ne contient pas d'autre information en plus du mot_cle ...

Merci pour votre aide.

[fsmrel]

Bonsoir robocop333,


Je vous avais déjà répondu au mois de mars dernier, mais la discussion a été effacée. C’est bien la peine...

Concernant les règles de passage d’un diagramme de classes à un système de tables SQL, ce qu’on lit dans la référence que vous fournissez, n’est pas faux, mais effectivement plutôt informel et notoirement incomplet. Pour pallier, vous pourriez utiliser, les techniques utilisées pour Merise. Vous remplacez "Classe" par "Entité" et ça devrait aller. Voyez par exemple le document fourni par Cyril Gruau sur ce forum. Évidemment, il y a un petit temps d’adaptation pour s’habituer aux associations représentées par des ovales, mais on n’a rien sans rien. Vous pouvez aussi reprendre votre diagramme de classes avec Power AMC, il saura vous le traduire automatiquement en tables SQL.


Concernant les clés primaires de vos tables.

Prenez le cas par exemple de la table EQUIPE, elle a pour clé primaire {INTITULE}. Du point de vue théorique, cela est possible, mais du point de vue de l’application ça n’est pas à recommander. En effet, l’attribut INTITULE correspond à une propriété naturelle, non technique, donc sujette à modification, au gré de l’utilisateur. Si donc un intitulé change de valeur, cela doit être propagé jusqu’à la table CHERCHEUR (intégrité référentielle oblige), pour que chaque chercheur de l’équipe continue à référencer correctement celle-ci : définissez plutôt un attribut technique, non modifiable, qui devienne clé primaire de la table EQUIPE, tandis que la clé {INTITULE} sera ravalée au rang de clé alternative. Elle reste le point d’entrée pour la table EQUIPE, elle conserve sa propriété d’unicité mais elle n’est plus une référence directe pour la table CHERCHEUR.


Concernant la 1re forme normale

Je vous avais dit qu’elle avait l’air d’être respectée (je n’ai pas vérifié chaque attribut). Pour en avoir une définition et vérifier par vous-même, voyez par exemple http://www.developpez.net/forums/sho...7&postcount=38


Concernant les 2e et 3e formes normales

Je vous rafraichis la mémoire. Tout d’abord, pour savoir si une table est en 2NF ou 3NF, il faut mettre en évidence l’ensemble de ses clés candidates, car l’énoncé de cette 3NF fait référence à ces clés (pour savoir ce qu’est une clé candidate, reportez-vous à la discussion Courses hippiques).

Une table R est en deuxième forme normale si elle est en première forme normale et si chaque attribut n’appartenant pas à une clé candidate est en dépendance totale de chaque clé candidate de R.

Pour mémoire, une dépendance fonctionnelle A → B est totale s’il n’existe pas de sous-ensemble A’ strictement inclus dans A tel que A’ → B.

Une table R est en troisième forme normale si elle est en deuxième forme normale et si chaque attribut n’appartenant pas à une clé candidate ne dépend fonctionnellement que des seules clés candidates de R.

Indice :

Si l’attribut est_chef_equipe de la table CHERCHEUR entre dans la composition d’une clé étrangère utilisée pour une contrainte référentielle par rapport à la table EQUIPE, alors la table CHERCHEUR n’est pas 3NF (en admettant qu’elle soit 2NF).

Et est ce qu'on peut enlever la table mot-clé et utilisé seulement les tables intermédiaires en relation avec mot clé (càd: reference_publication et reference_projet) ? Car mot clé ne contient pas d'autre information en plus du mot_cle ...

Si la table MOT_CLE contient la liste des seuls mots-clés qu’on ait le droit d’utiliser, il faut évidemment la conserver. Sinon, si les mots-clés sont définis au niveau Projet ou Publication, vous pouvez supprimer la table, auquel cas, pour connaître la liste complète des mots-clés utilisés, une requête d’interrogation suffira. Cela dit, si vous conservez la table MOT_CLE, elle aura au moins deux attributs : Mot_Cle (clé alternative) et un attribut technique non modifiable, servant de clé primaire.

[robocop333]

Bonjour fsmrel,

Prenez le cas par exemple de la table EQUIPE, elle a pour clé primaire {INTITULE}. Du point de vue théorique, cela est possible, mais du point de vue de l’application ça n’est pas à recommander. En effet, l’attribut INTITULE correspond à une propriété naturelle, non technique, donc sujette à modification, au gré de l’utilisateur. Si donc un intitulé change de valeur, cela doit être propagé jusqu’à la table CHERCHEUR (intégrité référentielle oblige), pour que chaque chercheur de l’équipe continue à référencer correctement celle-ci : définissez plutôt un attribut technique, non modifiable, qui devienne clé primaire de la table EQUIPE, tandis que la clé {INTITULE} sera ravalée au rang de clé alternative. Elle reste le point d’entrée pour la table EQUIPE, elle conserve sa propriété d’unicité mais elle n’est plus une référence directe pour la table CHERCHEUR.

Si je définit un autre attribut (technique) pour la table "EQUIPE", cette dernière ne serai plus en 2eme forme normale (et donc pas en 3eme). Car cette attribut définit d'une manière unique un tuplet de la table. Et "Intitile" aussi le fait :/

Aussi y a le même problème pour la table CHECHEUR, le "matricule" qui est unique, et aussi l' "email",
Si je prend la clé candidate {matricule} ou bien {email}, cette table ne sera pas en 2eme forme normale.
Et si je prend comme clé {matricule, email}, cette table ne sera pas en 3eme forme normale.

Comment dois-je faire alors ?

Si la table MOT_CLE contient la liste des seuls mots-clés qu’on ait le droit d’utiliser, il faut évidemment la conserver. Sinon, si les mots-clés sont définis au niveau Projet ou Publication, vous pouvez supprimer la table

Ces mot_cle sont saisi lors de l'insertion d'une nouvelle publication, ou d'un nouveau projet.
Je peut donc supprimer la table MOT_CLE je crois,
non ?

Encore merci

[fsmrel]

Bonjour,

Si je définit un autre attribut (technique) pour la table "EQUIPE", cette dernière ne serai plus en 2eme forme normale (et donc pas en 3eme).

Reprenons la structure que vous proposez pour la table EQUIPE :

EQUIPE (INTITULE, THEME, DATE_CREATION, ACTIF)

Vous avez retenu {INTITULE} pour être la clé primaire de cette table (j’ai utilisé des accolades en plus du nom de l'attribut, car une clé primaire est un ensemble dont les éléments sont des attributs de la table).
Une clé primaire est un cas particulier de la clé candidate (pour la petite histoire, le concept de clé primaire ne figure plus dans la théorie relationnelle qu’à titre historique). Une fois de plus, je vous renvoie à la discussion Courses hippiques, pour savoir ce qu’est une clé candidate. Quoi qu’il en soit, une clé candidate a la propriété de participer à une dépendance fonctionnelle avec chaque attribut de la table :

DF1 : {INTITULE} → {INTITULE}
DF2 : {INTITULE} → {THEME}
DF3 : {INTITULE} → {DATE_CREATION}
DF4 : {INTITULE} → {ACTIF}

En notant que la dépendance fonctionnelle DF1 est triviale.

Si on définit un attribut technique ID_EQUIPE tel que {ID_EQUIPE} → {INTITULE} et {INTITULE} → {ID_EQUIPE}, alors, par transitivité, ce nouvel attribut est en dépendance fonctionnelle avec chaque attribut de la table (en outre il existe par définition la DF triviale {ID_EQUIPE} → {ID_EQUIPE}) :

DF5 : {ID_EQUIPE} → {ID_EQUIPE}
DF6 : {ID_EQUIPE} → {INTITULE}
DF7 : {ID_EQUIPE} → {THEME}
DF8 : {ID_EQUIPE} → {DATE_CREATION}
DF9 : {ID_EQUIPE} → {ACTIF}

Et la table possède EQUIPE possède désormais deux clés candidates, dont l’une {INTITULE} peut changer de valeur, au gré de l’utilisateur et l’autre non {ID_EQUIPE}, car on a dit "pas touche". Ainsi, si on a décidé que la table CHERCHEUR fait référence à la table EQUIPE, ça sera par le biais de {ID_EQUIPE}, invariant, et donc l’utilisateur pourra bricoler les valeurs de l’attribut INTITULE comme bon lui chante, cela n’aura aucun impact sur la table CHERCHEUR.

Mais vous affirmez que la mise en œuvre de l’attribut ID_EQUIPE implique de facto un viol de 2e forme normale. Une fois de plus, je vous invite à relire l’énoncé de la 2NF :

Une table R est en deuxième forme normale si elle est en première forme normale et si chaque attribut n’appartenant pas à une clé candidate est en dépendance totale de chaque clé candidate de R.

La table EQUIPE possède deux clés candidates :

CK1 : {INTITULE}
CK2 : {ID_EQUIPE}

Seuls les attributs suivants n’appartiennent pas à une clé candidate :

THEME, DATE_CREATION, ACTIF.

Les DF dans lesquels ces attributs sont impliqués sont les suivantes :

DF2 : {INTITULE} → {THEME}
DF3 : {INTITULE} → {DATE_CREATION}
DF4 : {INTITULE} → {ACTIF}
DF7 : {ID_EQUIPE} → {THEME}
DF8 : {ID_EQUIPE} → {DATE_CREATION}
DF9 : {ID_EQUIPE} → {ACTIF}

Les attributs THEME, DATE_CREATION et ACTIF sont-ils en dépendance totale vis-à-vis de chaque clé candidate ?

Je rappelle à nouveau qu’une dépendance fonctionnelle A → B est totale s’il n’existe pas de sous-ensemble A’ strictement inclus dans A tel que A’ → B.

Or {INTITULE} et {ID_EQUIPE} sont des ensembles singletons et ne comportent donc pas de sous-ensembles (non-vides) de la forme A’ → B.

Conclusion, les attributs "non clés" THEME, DATE_CREATION, ACTIF sont en dépendance totale vis-à-vis de l'ensemble des clés candidates de la table EQUIPE, à savoir CK1 et CK2 : cette table est en 2NF. Je vous laisse le soin de prouver qu’elle est, oui ou non, en 3NF.

Ces mot_cle sont saisi lors de l'insertion d'une nouvelle publication, ou d'un nouveau projet.
Je peut donc supprimer la table MOT_CLE je crois,
non ?

Vous pouvez.

[robocop333]

Salut fsmrel,

Conclusion, les attributs "non clés" THEME, DATE_CREATION, ACTIF sont en dépendance totale vis-à-vis de l'ensemble des clés candidates de la table EQUIPE, à savoir CK1 et CK2 : cette table est en 2NF. Je vous laisse le soin de prouver qu’elle est, oui ou non, en 3NF.

Je ne savais pas qu'une table peut avoir plusieurs clés candidates.
Faut il le préciser lors de l'implémentation des tables avec quelque chose ?
Et on n'utilise qu'une seul d'entre eux pour référencer les tables en relation avec cette table ?

Donc cette table dois être en 3NF, car tout attribut dépend directement de la clé, càd qu'aucun attribut ne dépend d’un autre attribut non clé.
THEME ne dépend que de INTITULE ou de ID_EQUIPE (et ces deux derniers sont des clés). Et même chose pour DATE_CREATION, et ACTF.
Donc je suppose qu'elle est en 3NF.

Ainsi pour la table CHERCHEUR qui a un attribut MATRICULE qui est unique, et un attribut EMAIL qui est aussi unique.
Si on considère que cette table a deux clés candidates (en l'occurrence: {MATRICULE} et une clé {EMAIL} ), alors elle est elle aussi en 3FN ?
Est ce que je me trempe ?

[fsmrel]

Bonjour robocop333,

Je ne savais pas qu'une table peut avoir plusieurs clés candidates.
Faut il le préciser lors de l'implémentation des tables avec quelque chose ?

Il faut bien entendu le préciser, car le système ne peut pas le deviner. Étant donné que SQL continue à utiliser le concept de clé primaire (Primary Key), les clés alternatives font l’objet de la clause UNIQUE (exemple avec SQL Server 2005) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Create Table EQUIPE (
    ID_EQUIPE      Integer       Not null
  , INTITULE       Varchar(48)   Not null
  , THEME          Varchar(48)   Not null 
  , DATE_CREATION  Datetime      Not null
  , ACTIF          Char(4)       Not null
         Check (ACTIF  IN ('vrai', 'faux', '????'))
  , PRIMARY KEY (ID_EQUIPE)
  , UNIQUE (INTITULE) ) ;

Dans l’instruction ci-dessus, {ID_EQUIPE} est clé primaire et {INTITULE} est clé alternative. L’une et l’autre sont clés candidates.

Et on n'utilise qu'une seul d'entre eux pour référencer les tables en relation avec cette table ?

Oui.

Exemple 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Create Table CHERCHEUR (
    ID_CHERCHEUR   Integer       Not null
  , ID_EQUIPE      Integer       Not null
  , NOM            Varchar(48)   Not null
  , PRENOM         Varchar(48)   Not null 
  , EMAIL          Varchar(48)   Not null 
  , Primary Key (ID_CHERCHEUR)
  , Unique (EMAIL)
  , Foreign Key (ID_EQUIPE) References EQUIPE (ID_EQUIPE) ) ;

Exemple 2. Même si c’est néfaste, pour les raisons que je vous ai fournies, vous avez le droit de coder :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Create Table CHERCHEUR (
    ID_CHERCHEUR      Integer       Not null
  , INTITULE_EQUIPE   Varchar(48)   Not null
  , NOM               Varchar(48)   Not null
  , PRENOM            Varchar(48)   Not null 
  , EMAIL             Varchar(48)   Not null 
  , Primary Key (ID_CHERCHEUR)
  , Unique (EMAIL)
  , Foreign Key (INTITULE_EQUIPE) References EQUIPE (INTITULE) )  ;

Exemple 3. Vous pouvez même doubler les références, mais vos données n’en seront pas plus intègres pour autant, et c’est tout aussi néfaste que dans l’exemple précédent. Qui plus est, horresco referens ! la 3NF est violée (exercice : pourquoi ?) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Create Table CHERCHEUR (
    ID_CHERCHEUR      Integer       Not null
  , ID_EQUIPE         Integer       Not null
  , INTITULE_EQUIPE   Varchar(48)   Not null
  , NOM               Varchar(48)   Not null
  , PRENOM            Varchar(48)   Not null 
  , EMAIL             Varchar(48)   Not null 
  , Primary Key (ID_CHERCHEUR)
  , Unique (EMAIL)
  , Foreign Key (ID_EQUIPE) References EQUIPE (ID_EQUIPE)
  , Foreign Key (INTITULE_EQUIPE) References EQUIPE (INTITULE) ) ;

Il est évident que seul l’exemple 1 est sensé.

Donc cette table dois être en 3NF, car tout attribut dépend directement de la clé, càd qu'aucun attribut ne dépend d’un autre attribut non clé.
THEME ne dépend que de INTITULE ou de ID_EQUIPE (et ces deux derniers sont des clés). Et même chose pour DATE_CREATION, et ACTF.
Donc je suppose qu'elle est en 3NF.

La table EQUIPE est effectivement en 3NF, puisque {THEME}, {DATE_CREATION} et {ACTIF} ne participent à aucune DF en tant que déterminants.

Ainsi pour la table CHERCHEUR qui a un attribut MATRICULE qui est unique, et un attribut EMAIL qui est aussi unique.
Si on considère que cette table a deux clés candidates (en l'occurrence: {MATRICULE} et une clé {EMAIL} ), alors elle est elle aussi en 3FN ?
Est ce que je me trempe ?

Il fait chaud, vous pouvez donc vous tremper. Plus sérieusement, vous dites que la table CHERCHEUR comporte les clés candidates {MATRICULE} et {EMAIL} et seulement celles-là. J’en déduis les règles suivantes, sur lesquelles vous devez vous prononcer avant de décider du niveau de normalité de la table :

Des chercheurs distincts peuvent :

(1) Faire partie de la même équipe.
(2) Être chefs de la même équipe.
(3) Cette équipe n’est pas nécessairement celle dont ils font partie.

Des chercheurs distincts peuvent avoir :

(4) Le même nom.
(5) Le même prénom.
(6) La même date de naissance.
(7) La même page web.
(8) Le même fax.
(9) La même adresse professionnelle.
(10) La même adresse personnelle.
(11) Le même téléphone.
(12) Le même grade dans le cadre de la recherche.
(13) Le même grade dans le cadre de l’enseignement.
(14) Le même diplôme.
(15) Le même statut d’activité.
(16) La même photo.

Bon courage et bonne trempette,

fsmrel

[robocop333]

Ok, merci beaucoup fsmrel, pour votre précieuse aide

[fsmrel]

De rien robocop333.

Mais vous n'avez toujours pas prouvé que la table CHERCHEUR est — ou n'est pas — en 3NF...