Discussion :

[Zak Blayde]

Bonjour,

Habitué de la méthode Merise, j'ai encore du mal à mettre en place les relations en SQL.
Ma base est toute simple, j'ai trois tables : utilisateur, jour, et projet, chacune contenant une propriété du même nom.
Ils forment tout trois une ternaire :

A un jour, correspondent 1 à n utilisateurs, 1 à n projets
A un projet correspondent 1 à n utilisateurs, 1 à n jours
A un utilisateur correspondent 1 à n jours et projets

Sachant le jour, l'utilisateur et le projet, on peut déterminer un nombre d'heures.

Plus tard je devrais pouvoir afficher pour telle semaine cette fois-ci (en espérant que le format date puisse aider), le nombre d'heures par jour et par projet de chaque utilisateur.

J'ai donc créé pour l'association une table correspondre contenant jour, utilisateur et projet, ainsi que nombreheures.
Comment dois-je m'y prendre pour créer les relations entre toutes ces tables ?

Merci de votre aide.

[fsmrel]

L’association ternaire XYZ porteuse de la propriété NbHeures fera l’objet au niveau du modèle logique (MLD) d’une table XYZ, dont la structure ressemblera à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table XYZ 
(
    ProjetId         Integer   Not Null
  , UtilisateurId    Integer   Not Null
  , JourId           Integer   Not Null
  , NbHeures         Integer   Not Null
 , Primary Key (ProjetId, UtilisateurId, JourId)
 , Foreign Key (ProjetId) References Projet
 , Foreign Key (UtilisateurId) References Utilisateur
 , Foreign Key (JourId) References Jour
)  ;

Projet, Utilisateur et Jour étant les tables inférées des entités-types correspondantes.

Utilisez par exemple DBDesigner pour vérifier tout cela.

[dgi77]

L'association ternaire qui s'impose se substitue à toutes les associations binaires entre ces tables.

[Zak Blayde]

J'ai fait cette commande là pour créer ma table xyz (à la place du correspondre dont je parlais plus tôt) :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE xyz
(Jour date not null,
Utilisateur varchar(30) not null,
Projet varchar(10) not null,
NbHeures int not null,
primary key (Jour, Utilisateur, Projet),
FOREIGN KEY (Jour) REFERENCES jour(Jour),
FOREIGN KEY (Projet) REFERENCES projet(NomProjet),
FOREIGN KEY (Utilisateur) REFERENCES utilisateur(NomUtilisateur)
)

A votre avis c'est OK ?

J'ai changé les autres tables avant de la lancer. jour contient Jour, projet contient NomProjet, utilisateur contient NomUtilisateur.

[fsmrel]

Bonjour,

J'ai fait cette commande là pour créer ma table xyz (à la place du correspondre dont je parlais plus tôt) :

Code :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE xyz
(Jour date NOT NULL,
Utilisateur varchar(30) NOT NULL,
Projet varchar(10) NOT NULL,
NbHeures int NOT NULL,
PRIMARY KEY (Jour, Utilisateur, Projet),
FOREIGN KEY (Jour) REFERENCES jour(Jour),
FOREIGN KEY (Projet) REFERENCES projet(NomProjet),
FOREIGN KEY (Utilisateur) REFERENCES utilisateur(NomUtilisateur)
)

A votre avis c'est OK ?

J'ai changé les autres tables avant de la lancer. jour contient Jour, projet contient NomProjet, utilisateur contient NomUtilisateur.

A strictement parler, votre instruction CREATE TABLE est correcte. Mais elle présente des inconvénients à éviter à tout prix. Puisque vous avez évoqué Merise, je cite un maître, à savoir Yves Tabourier, qui a écrit :

"Un identifiant ne décrit rien, son rôle est de distinguer deux jumeaux parfaits".

Ensuite, selon votre instruction, en remontant au niveau MCD, NomUtilisateur est l’identifiant de l’entité-type UTILISATEUR et correspond vraisemblablement au nom de l’utilisateur. Dans cette hypothèse, une seule personne a le droit de s’appeler MARTIN. Par ailleurs, si un jour il faut modifier un nom parce que mal orthographié, par exemple SBOZNIETZ à changer en SBROZNIETZ, il faudra le faire non seulement dans la table UTILISATEUR, mais aussi dans toutes les tables y faisant référence (intégrité référentielle oblige), y-compris donc dans la table xyz, ce qui peut s’avérer compliqué et onéreux (ayez une pensée émue pour ceux dont la base de données est constituée de plus de mille tables dont certaines représentent quelques centaines de millions de lignes).

Au niveau physique, votre système n’est pas économique, car les index utilisés pour la clé primaire et les clés étrangères seront obèses et feront de l’accordéon (problème du VARCHAR).
=>
La structure de la table Utilisateur doit en fait ressembler à ceci :

Code :

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

1
2
3
4
5
6
CREATE TABLE Utilisateur (
    UtilisateurId    Integer       NOT NULL
  , NomUtilisateur   Varchar(30)   NOT NULL
  ,  ...
 , Primary Key (UtilisateurId)
 ;

Structure dans laquelle l’attribut UtilisateurId est dérivé l’identifiant de l’entité-type Utilisateur. Au besoin, dans la mesure où le nom de l’utilisateur doit vraiment être unique, vous ajoutez la clause "Unique (NomUtilisateur)" dans l’instruction CREATE TABLE. En l’occurrence, {NomUtilisateur} devient clé alternative de la table Utilisateur :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE Utilisateur (
    UtilisateurId    Integer       NOT NULL
  , NomUtilisateur   Varchar(30)   NOT NULL
  ,  ...
 , Primary Key (UtilisateurId)
 , Unique (NomUtilisateur)
 ;

Vous pouvez aussi méditer l’exemple du numéro Siren des entreprises, attribués par l’INSEE.

Ce que j’ai écrit concernant l’identification des utilisateurs vaut bien entendu pour les autres éléments identifiants. Prenez de bonnes habitudes.

[Zak Blayde]

Oui, j'avoue que j'ai pas pensé à créer un "NumUtilisateur" car ça concernera tout au plus une dizaine d'utilisateurs. Mais bon autant faire quelque chose de propre et d'évolutif, je vais donc refaire cela.