Discussion :

[DiverSIG]

Bonjour,

Dans mon modèle de base de données, j'ai une table Paramètres, avec sa clé primaire, et une table Unités, avec sa clé primaire.
Entre les deux, je crée une table Paramètre_Unité, ou je met la clé primaire des paramètres, et pour chaque paramètre, les clé primaires des unités valides pour ce paramètre. Ceci dans l'idée de pouvoir empêcher l'utilisateur de pouvoir sélectionner par exemple le paramètre température et lui associer l'unité kilogramme !

Question : Pour être le plus rigoureux dans la conception, est ce que dans cette table intermédiaire il est nécessaire de créer un champ clé primaire (de type autoincrement) ?

Merci,

Nico

[escartefigue]

Bonjour,

La réponse est oui concernant le titre, car une clef primaire est obligatoire, et non concernant la façon de l'obtenir, car une table associative n'a pas d'identifiant propre : son identifiant est issu des types d'entité qui participent à l'association.

Mais surtout, il ne faut pas modéliser une base de données en réfléchissant sur les tables (le comment), mais en créant des types d'entités et des associations conformes aux règles de gestion (le quoi).
Les tables sont obtenues automatiquement à partir des entités et associations.

Ainsi, si on a les règles de gestion suivantes
R001 : un paramètre utilise au moins une unité de mesure
R002 : une unité de mesure peut être utilisée pour plusieurs paramètres

Alors le MCD est comme suit :



Ce qui donne automatiquement, si on utilise un logiciel de modélisation et qu'on choisit un SGBD (ici PostGreSQL), le script DDL suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE TABLE PARAM(
   PARAM_ident INTEGER,
   PARAM_LIBELLE VARCHAR(50) NOT NULL,
   PARAM_TRUC VARCHAR(50) NOT NULL,
   PRIMARY KEY(PARAM_ident)
);
 
CREATE TABLE UNITE(
   UNITE_IDENT SERIAL,
   UNITE_CODE CHAR(5) NOT NULL,
   UNITE_LIBELLE VARCHAR(50) NOT NULL,
   PRIMARY KEY(UNITE_IDENT),
   UNIQUE(UNITE_CODE)
);
 
CREATE TABLE utiliser(
   PARAM_ident INTEGER,
   UNITE_IDENT INTEGER,
   PRIMARY KEY(PARAM_ident, UNITE_IDENT),
   FOREIGN KEY(PARAM_ident) REFERENCES PARAM(PARAM_ident) ON DELETE CASCADE ON UPDATE CASCADE,
   FOREIGN KEY(UNITE_IDENT) REFERENCES UNITE(UNITE_IDENT) ON DELETE CASCADE ON UPDATE CASCADE
);

[fsmrel]

Bonjour Nico,

En complément de ce qu’a écrit escartefigue :

est ce que dans cette table intermédiaire il est nécessaire de créer un champ clé primaire (de type autoincrement) ?

Non, ça serait un cautère sur une jambe de bois, ça n’empêchera pas d’associer la température au kilogramme. Si la table Parametres a par exemple pour clé primaire la colonne ParamId et si la table Unites a pour clé primaire la colonne UniteId, la clé primaire de la table Parametre_Unite est constituée de la paire {ParamId, UniteId}, les colonnes ParamId et UniteId constituant respectivement les clés étrangères en relation avec les tables Parametres et Unités.

A l’utilisateur de faire attention à ce qu’il fait !

[escartefigue]

En complément, relativement à ceci :

Question : pour être le plus rigoureux dans la conception, est ce que dans cette table intermédiaire il est nécessaire de créer un champ clé primaire (de type autoincrement) ?

Tant qu'à faire d'être rigoureux, autant l'être aussi quant aux termes utilisés

En informatique un champ est une zone de saisie d'un formulaire ou une zone d'édition d'un état.
Dans une table d'une base relationnelle, il n'y a pas de champs, il y a des colonnes ou attributs.

Par ailleurs, le type d'une colonne (et non pas d'un champ) définit le contenu pour lequel il est prévu. On distingue les types caractères, numériques, dates, géographiques, etc.
Autoincrement est une fonctionnalité de MySQL/MariaDB permettant d'appliquer la propriété de calcul automatique d'une valeur unique d'une colonne de type numérique.
Dans d'autres SGBD, cette fonctionnalité s'implémente avec le mot clef "identity" (DB2, PostGreSQL, SQL server, SyBase"), "counter" (Access).
Certains SGBD ne la proposent pas, par exemple SQLIte.
En général, on choisit une colonne de type integer (small, integer, big) pour lui appliquer la propriété identity/auto_increment/counter, car c'est le type le plus concis et le plus performant.

Enfin, plutôt que "table intermédiaire", on parle de "table associative", puisqu'il s'agit de tables issues d'une association du modèle conceptuel entité/association

[fsmrel]

@ Nico

Encore en complément des excellents conseils d’escartefigue, il serait opportun que vous vous imitiez à la modélisation conceptuelle et à celle des bases de données.

- Etudier le chapitre 7 de l’ouvrage fondamental de Dominique Nanci(RIP) :

Modélisation conceptuelle des données (au paragraphe LII-D)

- Vous entraîner avec l’excellent et gratuit Looping qui fait l’unanimité et avec lequel escartefigue vous a fourni un exemple de MCD (voir le post #2 de la discussion).

Cf. forum Looping

Bon courage !