Les bases de données appliquent trois types d'intégrité déclarative :
- Intégrité de domaine - le type du champ et la contrainte CHECK.
- Intégrité de clé - Contrainte PRIMARY KEY ou UNIQUE.
-
Référentiel integrity - FOREIGN KEY.
A clé identifie de manière unique les lignes de la table. Toutes les clés sont logiquement équivalentes, mais pour des raisons pratiques, l'une d'entre elles est choisie comme "primaire" et les autres sont considérées comme "alternatives" (il y a quelques complications impliquant les NULL, mais ne nous y attardons pas ici).
D'autre part, une FOREIGN KEY est une sorte de "pointeur" d'une table à une autre, où le SGBD lui-même garantit que ce "pointeur" ne peut jamais "dangle" . La clé étrangère références la clé (primaire ou alternative) de la table "parent", mais le point de terminaison "enfant" n'a pas besoin d'être lui-même une clé (et ne l'est généralement pas).
- Lorsqu'une ligne est modifiée ou supprimée de la table parente, ce changement est soit en cascade à la table fille (ON [UPDATE/DELETE] [CASCADE/SET NULL/SET DEFAULT]) ou l'opération entière est bloquée (ON [UPDATE/DELETE] RESTRICT).
- Si un enfant est inséré ou modifié, il est vérifié par rapport à la table parente pour s'assurer que cette nouvelle valeur y existe.
Les contraintes modifient le signification de données. Indices d'autre part, ne changent pas la signification des données - ils sont là uniquement pour permettre à l'utilisateur de s'exprimer. performance raisons. Certaines bases de données vous permettent même d'avoir une clé sans index sous-jacent, bien que ce soit généralement une mauvaise idée du point de vue des performances. Un index sous-jacent à la clé primaire est appelé "index primaire" et tous les autres index sont "secondaires".
BTW, il y a "index secondaire" et il y a "clé alternative", mais il n'existe pas de "clé secondaire".
Je ne sais pas exactement quel est votre objectif de conception, mais je suppose que quelque chose comme ceci serait un bon point de départ :
![enter image description here]()
Je ne vois pas l'intérêt d'extraire les détails dans des tableaux séparés. si ils sont toujours en relation 1:1 avec l'objet.
--- EDIT ---
Certaines questions que vous devrez vous poser avant de pouvoir arriver à une conception optimale de la base de données :
Existe-t-il une véritable relation 1:1 entre l'élément et le détail ou est-ce en fait 1:0..1 (c'est-à-dire que certains détails sont facultatifs ?).
- Si c'est 1:1, l'utilisation de colonnes est la représentation la plus naturelle. D'ailleurs, un SGBD décent n'aura aucun mal à gérer 100 colonnes.
- Si 1:0..1, vous devrez décider d'utiliser des colonnes pouvant contenir des NULL ou des tables séparées. Gardez à l'esprit que la plupart des SGBD sont très efficaces dans le stockage des NULL (typiquement juste un petit bitmap par ligne), donc séparer les données dans une table différente ne vous apportera pas grand chose, et en fait peut empirer substantiellement les performances des requêtes à cause du besoin accru de JOINing.
Tous les types de détails sont-ils prédéterminés (c'est-à-dire que vous pouvez dire en toute confiance que vous n'aurez pas besoin d'ajouter de nouvelles fonctionnalités à votre système d'information). types de détails plus tard dans le cycle de vie de l'application) ?
- Si oui, utilisez simplement des colonnes.
- Si ce n'est pas le cas, l'ajout de colonnes dans la grande base de données existante peut s'avérer coûteux. C'est à vous de déterminer si ce coût est suffisant pour justifier l'utilisation d'une table séparée.
Vous pouvez également envisager de généraliser tous les détails sous forme de paires nom/valeur et de les représenter dans une seule table 1:N (non représentée ici). Cette méthode est très souple et "évolutive", mais elle présente ses propres problèmes.
Comment comptez-vous interroger les données ? Il s'agit d'un élément important qui peut influencer considérablement le choix de l'approche "colonnes" ou "table séparée", l'indexation, etc...
BTW, le 1:0..1 avec des tables séparées peut être modélisé comme ceci...
![enter image description here]()
...et le 1:1 peut être modélisé comme ceci...
![enter image description here]()
...mais cela introduit une dépendance circulaire qui doit être gérée d'une manière spéciale (généralement par le biais de différer l'une des FOREIGN KEYs).
Les détails à l'échelle 1:N, bien sûr, sont une autre affaire et sont naturellement modélisés par des tableaux séparés.
Puisque vous dites que "détail 1" et "détail 2" sont 1 :(0..)1 et que "détail 3" est 1:N, votre modèle de données "mis à jour" ressemblerait probablement à quelque chose comme ceci :
![enter image description here]()
BTW, le modèle ci-dessus utilise identifier qui donnent lieu à des clés plus "naturelles". Non-identifiant L'approche relations / clés de substitution ressemblerait à ceci :
![enter image description here]()
Chaque approche a ses avantages, mais ce billet devient déjà un peu long ;) ...
