Bonsoir,
Concernant votre diagramme :
La table que nommez « utilisateurs » est en réalité
la table
des utilisateurs. En français, son nom doit être au singulier et en majuscules, à savoir « Utilisateur » (ou en lettres capitales : « UTILISATEUR », ce que je continuerai du reste à faire, surtout pour des raisons de lisibilité). Même chose pour les autres tables : ENTITE, MATERIEL, etc. Pour éviter les problèmes avec les langages de programmation et les SGBD, on évite quand même l’emploi des accents.
Sur le lien connectant UTILISATEUR et VALIDEUR_SUCC, il y a un Mandatory en trop (|| au lieu de |o).
C'est bon je l'ai corrigé
BonNumero n’est pas un nom de champ, mais un nom d’attribut (ou de colonne en SQL, comme avec MySQL Workbench).
Cela dit, les attributs dont les noms figurent dans l’en-tête (
header) d’une table correspondent à des données qui peuvent être naturelles ou artificielles. Voyez la table UTILISATEUR Le nom d’un utilisateur, son prénom, son pseudo, sont des données
naturelles, leur fonction est de
décrire l’utilisateur, ces données sont
modifiables par celui ou celle qui met à jour la base de données. L’attribut Id (UtilisateurId dans mes diagrammes) pour sa part
ne décrit rien, il est purement
artificiel, son rôle est de garantir une contrainte d’unicité, à savoir que deux lignes n’existeront pas en double dans la table, donc que l’algèbre relationnelle ne sera pas prise en défaut (le corps (
body) d’une table est un ensemble, tout comme du reste l’en-tête). C’est pour cela que vous avez défini la clé de la table UTILISATEUR à partir de l’attribut Id. Etant donné que cet attribut ne décrit rien, qu’il est purement technique, il est inconnu de l’utilisateur final, et il n’y a aucune raison pour qu’il change de valeur.
Pour la table BON, c’est la même chose. L’attribut Id (BonId dans mes diagrammes) est artificiel, non modifiable, sans signification et inconnu de l’utilisateur, il sert pour la clé de la table. Je suis parti du principe que l’utilisateur a quand même certainement besoin de numéroter les bons : c’est à cet effet que j’ai mis en œuvre l’attribut BonNumero : l’utilisateur en fait ce qu’il veut, simplement on garantit quand même le principe de l’unicité en faisant de cet attribut une clé alternative (clause SQL UNIQUE) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
| CREATE TABLE BON
(
BonId INT NOT NULL
, TechnicienId INT NOT NULL
, MaterielId INT NOT NULL
, BonNumero INT NOT NULL
, BonDate DATE NOT NULL
, BonHeure TIME NOT NULL
, BonLibelle VARCHAR(48) NOT NULL
, CONSTRAINT BON_PK PRIMARY KEY (BonSortieId)
, CONSTRAINT BON_AK UNIQUE (BonNumero)
, CONSTRAINT BON_TECH_FK FOREIGN KEY (TechnicienId)
REFERENCES TECHICIEN_HOTLINE (TechnicienId)
, CONSTRAINT BON_MATERIEL_FK FOREIGN KEY (MaterielId)
REFERENCES MATERIEL (MaterielId)
) ; |
Cela dit, si ça ne gêne pas l’utilisateur de ne pas avoir la maîtrise de la numérotation, alors vous pouvez faire l’économie de BonNumero. Il pourra voir BonId mais avec interdiction d’en changer la valeur.
Pourquoi un utilisateur aura t-il besoin d'insérer des numéros de bon, je laisse cela a BonID
Vous pouvez aussi lire ce que j’ai écrit au sujet des
clés primaires.
Je suis parti du principe que les matériels n’étaient pas tous présents dans les succursales, cas des matériels affectés à la hotline, ou arrivant de chez le fournisseur ou n’étant plus en service. A vous de voir : si tout matériel est affecté à ce que vous appelez une entité, alors la table MATERIEL_EN_SUCC peut disparaître.
Vous êtes en plein dans mon schéma, c'est exactement le cas, les matériels ne son pas tous présent dans les succursales, ils peuvent êtres affectés à la hotline ou bien neuves et encore hors service.
Maj faites !!!
Identifying relationship correspond à ce que l'on appelle l’identification relative, dont on se sert entre autres pour traduire la généralisation/spécialisation. Dans ce cas, la clé primaire de chaque table spécialisée (TECHNICIEN_HOTLINE, VALIDEUR_HOTLINE, VALIDEUR_SUCC) est aussi clé étrangère par rapport à la table contenant les données communes (UTILISATEUR) : revoyez les
structures tabulaires que je vous ai déjà présentées.
L’identification relative sert aussi pour l’identification des tables dont les données ont été externalisées depuis une autre table : par exemple, les lignes d’une facture représentent une propriété multivaluée de la facture, c’est à la vie à la mort (cf. la relation de composition en UML)... La table des lignes de facture est en toute logique identifiée relativement à la facture.
Voyez par exemple le 4e exemple de
Dénormalisation vs amélioration (optimisation) ou encore
ici et
là.
Partager