--- Soumis par Rebecca Riordan ---
Sous catégories.
Lorsque vous créer un modèle de données, vous avez souvent à traiter de différents types de la même chose. Par exemple, un client peut être un individu ou une compagnie et l'information à conserver n'est pas nécessairement la même pour chaque cas. Les produits sont souvent de types différents, et vous ne désirez pas conserver les mêmes informations quand il s'agit de livres de quand il s'agit de logiciel: le livre possède un titre, un ou plusieurs auteurs, un éditeur, une date d'édition, un prix d'achat et un prix de vente, mais le logiciel possède un numéro de version, mais pas d'auteurs, et vous ne vous intéressez probablement pas à la date de parution.
À prime abord, une solution serait d'inclure tous ces attributs dans une seule table, et si à première vue cela semble simple, l'ajout de nouveaux éléments rapidement détériore le tout en ajoutant de nouveaux champs, sans parler de l'interface utilisateur qui devient horrible très rapidement.
Une meilleure solution et d'emprunter une technique du design orienté objet. en créant des sous-catégories. En termes relationnels, vous créez plusieurs tables, une table maîtresse qui contient l'information commune et des tables d'apports, une par sous-catégorie, qui peut alors contenir l'information spécifique à la sous-catégorie.
Télécharger OneToOne.zip
Cette base de données montre comment implémenter un tel modèle. L'entité première est Party, qui peut être un individu (Individual) ou une organisation (Organization). La table Party contient les champs communs aux deux sous-catégories, alors que les deux tables d'apports contiennent les informations spécifiques à chaque sous-catégorie qu'elles adressent. (La table Party est utilisé pour fournir les listes de combo box dans le formulaire de l'exemple.)
Noter que la clé primaire (j'utilise un Autonumber dans l'exemple) est assignée à la table Party, non aux tables d'apport. C'est une erreur commune, et cela rend la programmation plus complexe que nécessaire: Il n'y a pas de raison d'ajouter des identifications supplémentaires. De fait, la vie est plus aisée si ce n'est pas le cas.
Le formulaire de l'exemple, également appelé Party, démontre une façon de gérer l'interface. Les deux se superposent, un par type de sous-catégorie. Quand un utilisateur utilise un type depuis le combo box, le formulaire approprié est rendu visible. Dans cet exemple, cela arrive au cours de la procédure événementielle OnExit du combo box. Ce code est répété dans la procédure événementielle OnCurrent du formulaire pour gérer le cas de navigation dans la table par l'utilisateur.
La requête AllInOne montre comment joindre les tables ensemble à l'aide de joints externes. Il n'est pas souvent requis de ramasser toutes les entités de cette façon, mais cela peut se produire dans les cas où on n'utilise pas les sous formulaires et sous états.
