Bases de Données Relationnelles (suite)

Relations

Le simple fait de stocker l’identifiant d'une occurrence de table comme propriété d'une occurrence d’une autre table n’est pas suffisant en soit pour décrire une relation entre les tables concernées. C’est une erreur ; une erreur extrêmement commune et répandue.

Vous devez décrire correctement à votre Système de Gestion de Base de Données le comportement naturel de vos entités et de leurs relations.

Comme vous le savez, il est impératif que les données contenues dans vos bases soient les plus cohérentes possibles. Vous devrais alors prendre soin dés le début à ce que votre base de données dans sa structure même n’accepte pas les incohérences les plus évidentes.

Pour ce faire il faut d’abord être à l’aise avec les relations que vous allez pouvoir rencontrer.

Nous distinguerons deux types de relations : des relations « d’appartenance », que nous appellerons Agrégations ainsi que des relations de « constitution », que nous appellerons Compositions.

L’agrégation et la composition sont des concepts récurrents du génie logiciel. Vous les retrouverez à chaque fois que vous manipulerez des entités. Qu’ils s’agissent de tables comme ici, mais aussi d’objets !

Agrégation

Sous ce nom un peut étrange se cache en fait le type de relation le plus courant ; le plus simple à comprendre et donc, à utiliser.

Une agrégation décris un lien d’affiliation entre une entité A et une entité B. Il s’agit d’une relation unilatérale, car elle n’est décrite que dans l’entité affiliée.

Prenons par exemple des Catégories et des Articles. On peut naturellement dire qu’un article est affilié à une catégorie, car ce dernier sera contenu dans une catégorie. La catégorie quand à elle ne sait pas qu’elle contient cet article. Du moins pas directement car dans notre base de données, le lien entre l’article et sa catégorie est enregistré du coté de l’article.

Reprenons notre exemple sur nos constructions en LEGO. Nous avons dit auparavant qu’un thème contenait des constructions. A fortiori une construction est affiliée à un thème.

Ici vous devez lire ce schéma de la façon suivante :

« Une Construction est forcément affiliée à un Thème.
A un Thème est affilié 0 ou plusieurs Constructions. »

Le plus simple, et le plus évident sera alors de stocker au sein de notre table CONSTRUCTION le numéro d’identifiant du thème à laquelle la construction est affiliée. Nous appellerons donc ce nouveau champ à stocker : une clé étrangère (Foreign Key en anglais).
Clé étrangère car faisant référence à la clé primaire d’une occurrence de la table THEME.

Nous verrons plus loin comment décrire cette clé étrangère lors de la création des tables de notre exemple.

Lire la suite