Vous voudrez peut-être envisager un modèle de données de type/sous-type. Cela ressemble beaucoup aux classes/sous-classes dans la programmation orientée objet, mais beaucoup plus difficile à mettre en œuvre, et aucun SGBDR (à ma connaissance) ne les prend en charge de manière native. L'idée générale est :
- Vous définissez un Type (Bâtiment), créez une table pour lui, donnez-lui une clé primaire
- Vous définissez deux sous-types ou plus (ici, Hôpital, Clinique, École, Université), créez des tables pour chacun d'eux, faites des clés primaires… mais les clés primaires sont aussi des clés étrangères qui référencent la table Bâtiment
- Votre table avec une colonne "ObjectType" peut maintenant être construite avec une clé étrangère sur la table Building. Vous devrez rejoindre quelques tables pour déterminer de quel type de bâtiment il s'agit, mais vous devrez le faire de toute façon. Cela, ou stocker des données redondantes.
Vous avez remarqué le problème avec ce modèle, n'est-ce pas ? Qu'est-ce qui empêche un bâtiment d'avoir des entrées dans deux ou plusieurs des tables de sous-type ? Heureux que vous ayez demandé :
- Ajoutez une colonne, peut-être "BuildingType", à Building, dites char(1) avec les valeurs autorisées de {H, C, S, U} indiquant (duh) le type de bâtiment.
- Créer une contrainte unique sur BuildingID + BuildingType
- Avoir la colonne BulidingType dans les sous-tables. Placez-y une contrainte de vérification afin qu'elle ne puisse jamais être définie que sur la valeur (H pour la table Hôpitaux, etc.) En théorie, cela pourrait être une colonne calculée ; en pratique, cela ne fonctionnera pas à cause de l'étape suivante :
- Construire la clé étrangère pour relier les tables en utilisant les deux colonnes
Voila :étant donné une ligne BUILDING définie avec le type H, une entrée dans la table SCHOOL (avec le type S) ne peut pas être définie pour référencer ce bâtiment
Vous vous souviendrez que j'ai dit que c'était difficile à mettre en œuvre.
En fait, la grande question est :est-ce que cela vaut la peine d'être fait ? S'il est logique d'implémenter les quatre (ou plus, au fil du temps) types de bâtiments en tant que type/sous-type (autres avantages de la normalisation :un emplacement pour l'adresse et d'autres attributs communs à chaque bâtiment, avec des attributs spécifiques au bâtiment stockés dans les sous-tables), cela vaut peut-être la peine de faire des efforts supplémentaires pour construire et entretenir. Si ce n'est pas le cas, vous revenez à la case départ :un modèle logique difficile à mettre en œuvre dans le SGBDR moderne moyen.
