tables de base de données sous-typage

Question

J'entends beaucoup sur les tables sous-typage lors de la conception d'une base de données, et je suis pleinement conscient de la théorie derrière eux. Cependant, je ne l'ai jamais réellement vu la table sous-typage en action. Comment pouvez-vous créer des sous-types de tables? J'utilise MS Access, et je suis à la recherche d'une façon de le faire dans SQL, ainsi que par l'interface utilisateur graphique (Access 2003).

Vive!

Answer 1

Un exemple simple serait d'avoir une table de personne ayant une clé primaire et quelques colonnes dans ce tableau. Maintenant, vous pouvez créer une autre table appelée étudiant qui a une clé étrangère à la table de personne (son supertype). Maintenant, la table étudiant a des colonnes supertype n'a pas comme GPA, Major, etc. Mais le nom, le nom et ce serait dans la table parent. Vous pouvez toujours accéder au nom de l'étudiant de retour dans la table de personne par la clé étrangère dans la table des étudiants.

Quoi qu'il en soit, rappelez-vous ce qui suit:

• La hiérarchie représente relation entre supertypes et sous-types
• a des attributs communs super-types
• sous-types ont des attributs uniques

Answer 2

Sous-types de tables est une chose conceptuelle dans les diagrammes de REE. Je ne l'ai pas vu un SGBDR (hors DBMSs objet-relationnel) qui prend en charge directement. Ils sont généralement mis en œuvre dans les deux

1. un ensemble de colonnes nullables pour chaque propriété du sous-type dans une seule table
2. Avec une table pour les propriétés de type de base et d'autres tables avec au plus une ligne par table de base qui contiendra les propriétés du sous-type

Answer 3

La notion de tableau sous-types est utile lorsque vous utilisez un mappeur ORM pour produire le sous-type heirarchy classe exactement les modèles du domaine.

Une table sous type aura à la fois une clé étrangère à sa mère qui est aussi la clé primaire de la table sous-types.

Answer 4

Gardez à l'esprit que dans la conception d'une application liée, comme une application d'accès, les sous-types imposent un lourd tribut en termes de jointures.

Par exemple, si vous avez une table supertype avec trois tables de sous-type et vous devez afficher les trois sous une forme unique à la fois (et vous devez montrer non seulement la date de supertype), vous vous retrouvez avec un choix d'utiliser trois jointures externes et Nz (), ou vous avez besoin d'un UNION ALL SELECT de trois déclarations mutuellement exclusives (un pour chaque sous-type). Aucune de ces sera modifiable.

J'allais coller un peu SQL à partir de la première application majeure où je travaillais avec des tables super / sous-type, mais regardant, le SQL est si compliqué, il serait tout simplement confondre les gens. Ce n'est pas tellement parce que mon application a été compliqué, mais il est parce que la nature du problème est complexe - présentant l'ensemble des données à l'utilisateur, à la fois super et sous-types, est par nature complexes. Ma conclusion de travailler avec elle était que je l'aurais été mieux avec une seule table de sous-type.

Cela ne veut pas dire que ce n'est pas utile dans certaines circonstances, juste que les formes liées d'accès ne font pas nécessairement facile de présenter ces données à l'utilisateur.

Answer 5

J'ai un problème similaire, je travaille sur.

Alors que la recherche d'un modèle reproductible, je voulais vous assurer que je n'ai pas abandonné l'intégrité référentielle, ce qui signifiait que je ne voudrais pas utiliser un (TABLE_NAME, PK_ID) solution.

Je finalement réglé sur:

Type de base Tableau: CLIENT

Tables Sous Type: personne, entreprise, GOVT_ENTITY

Je mets PRERSON_ID annulable, BUSINESS_ID et champs de GOVT_ENTITY_ID dans CLIENT, avec des clés étrangères sur chacune, et une contrainte de vérification qu'un seul est non nul. Il est facile d'ajouter de nouveaux types de sous, il faut juste ajouter la clé étrangère annulable et modifier la contrainte de vérification.