Aidez-moi à connecter les concepts d'héritage et relationnels

voix
7

Je discutais avec un copain programmeur de moi sur l'héritage et son utilisation dans la conception de modèles. Il est un grand partisan et je suis un peu plus tiède. La plupart du temps parce que je tendance à concevoir des systèmes de bas en haut: Base de données -> Application -> Présentation (honnêtement, je ne suis pas beaucoup plus d'un gars front-end, donc je laisse souvent la présentation tout à fait à quelqu'un d'autre). Je trouve que les systèmes de base de données relationnelle ne prennent pas en charge l'héritage sans beaucoup de 1-to-1 relations avec d'autres tables.

Si je suis la conception d'un point de vue conceptuel, un administrateur est un utilisateur est une personne. A partir de la mise en base de données, un administrateur est un utilisateur avec UserType = « Administrateur ». Concilier ces approches semble difficile pour moi, et donc j'utiliser seul héritage avec des objets non persisté.

Quel est le problème avec ma pensée? Pourquoi est-ce l'héritage d'un aspect souvent célèbre OO si elle a ces incompatibilités inhérentes avec des structures relationnelles traditionnelles? Ou, est-ce moi qui est pas l'héritage correctement à la cartographie des données relationnelles? Y at-il des indications là-bas qui pourrait éclaircir ce point pour moi?

Désolé pour la question décousue et merci d'avance pour vos réponses. Si vous ajoutez le code dans votre réponse, C # est ma « langue maternelle ».

Créé 26/08/2009 à 22:59
source utilisateur
Dans d'autres langues...                            


11 réponses

voix
5

Cela a été communément appelé l' impédance objet-relationnel Mismatch :

L' héritage du schéma - La plupart des bases de données relationnelles ne prennent pas en charge l' héritage de schéma. Bien qu'une telle fonction pourrait être ajoutée en théorie de réduire le conflit avec la POO, les promoteurs relationnels sont moins susceptibles de croire en l'utilité des taxonomies hiérarchiques et sous-typage parce qu'ils ont tendance à voir taxonomies ou les systèmes de classification à base fixé comme plus puissant et flexible que les arbres. OO préconise soulignent que l' héritage / modèles de sous - typage ne doivent pas être limitées aux arbres (bien que ce soit une limitation dans de nombreuses langues OO populaires tels que Java), mais des solutions OO non-arbre sont considérés comme plus difficiles à formuler que variation- base-set sur un thème des techniques de gestion préféré par relationnelle. Au moins, ils diffèrent des techniques couramment utilisées en algèbre relationnelle.

Voir aussi: Agile données , C2 Wiki

Créé 26/08/2009 à 23:06
source utilisateur

voix
3

Je dirais que le modèle d'héritage dans la question est erronée. Il est trop littéral, ou basé dans le monde réel. Oui, on pourrait dire que je suis un administrateur dans le monde réel et par conséquent un administrateur est une personne. Cependant, la conception et l' héritage objet devrait reposer plus large des comportements et partagés dans l'espace de code. Je vais plus la route que l'utilisateur a un rôle. Administrateur est un rôle, ou une instance d'un rôle défini à un certain état. Un utilisateur n'est pas une personne (votre traitement par lots peut avoir besoin d' un compte utilisateur par exemple).

Je recommande la lecture pensée d'objets par David Ouest pour une bonne introduction à l'objet design. Il ne couvre pas la relation d'objet Mismatch cependant, mais les gens ont déjà donné de nombreux liens vers des ressources sur ce sujet.

Créé 26/08/2009 à 23:27
source utilisateur

voix
3

Le fossé entre le paradigme relationnel et le paradigme OO est souvent discuté.

En gros, pour fournir une correspondance entre SGBDR et OO, vous devez sacrifier certaines capacités des deux systèmes. Vous devez décider de quel côté votre compromis est plus fortement pondéré vers.

Les deux paradigmes sont très puissants et utiles. Mais essayer de la carte entre eux est un problème non résolu de façon transparente.

Créé 26/08/2009 à 23:10
source utilisateur

voix
3

Vous devriez lire les modèles d'architecture d' entreprise d' application . Il vous montrera comment les modèles d'héritage peuvent et doivent être exprimées structures relationnelles.

La chose importante à retenir est l'héritage est chose de modélisation conceptuelle. structures relationnelles et le code OO ne sont que matérialisations de ces modèles conceptuels, et ne doivent pas être considérés comme l'alpha et finissent tout de l'orientation de l'objet.

Il y a un tutoriel sur ce genre de chose ici.

Créé 26/08/2009 à 23:08
source utilisateur

voix
1

Pourquoi est-ce l'héritage d'un aspect souvent célèbre OO si elle a ces incompatibilités inhérentes avec des structures relationnelles traditionnelles?

Ceci est une citation curieuse - pourquoi dites-vous que les structures relationnelles sont « traditionnelles »? Ils sont la norme dans un SGBDR, par nature, mais j'ai vu très peu de bibliothèques relationnelles dans le contexte d'une langue non-DB.

La raison OO est populaire est parce qu'il est une amélioration significative par rapport au modèle dominant de la procédure. En utilisant l' héritage, le code pourrait être plus fiable (par type de vérification), plus facilement modifiable (par spécialisations méthode) et plus testable (par des comportements primordial facile). Par rapport à un modèle de procédure, OO est beaucoup plus facile de développer des logiciels de haute qualité avec.

Il y a, bien sûr, des difficultés à correspondance entre l'OO et les modèles relationnels. On l' appelle le « décalage d'objet-relationnel », et a été nommé « le Vietnam de la science informatique » . Il existe différentes stratégies pour le stockage de données orientée objet dans une base de données relationnelle, mais aucun sont parfaits - les plus populaires dans l' usage moderne sont des cadres sur la base du modèle d'enregistrement actif .

Créé 26/08/2009 à 23:11
source utilisateur

voix
1

Il existe différents types d'héritage. Les développeurs peuvent penser en termes d'interfaces et le comportement.

Dans votre monde ce que cela signifie d'avoir un un « userType » de l'administrateur?

La sémantique vous mnight-entendre sont que du code voit quelque part que userType et autorise des actions pour les utilisateurs avec ce type. Alors peut-être un administrateur peut créer d'autres utilisateurs?

Dans ce cas, un développeur peut avoir une classe utilisateur

class User() { viewData(){ ...} ; signReport() {...} }

et un Adminstrator de classe avec une capacité supplémentaire

class Administrator()  extends User {  createUser() {...}; approvePurchase() {...} }

Un objet de type administrateur peut être utilisé partout où un utilisateur peut. Ce comportement polymorphique peut être utile lorsque implmenting. Maintenant, votre base de données prend en charge tout à fait plausible ce cas. Cependant qu'allez-vous faire lorsque les administrateurs ont besoin juste un peu de données supplémentaires pour mener à bien leur tâche spécifique? Par exemple, purchaseApproval () est jusqu'à une certaine limite, nous avons besoin de cette limite comme un nouveau champ, mais il applique uniquement aux administrateurs.

Je crois que les aspects comportementaux qu'implique votre concept « de type » sont très souvent associées à des données supplémentaires.

Créé 26/08/2009 à 23:06
source utilisateur

voix
1

Il y a plusieurs façons d'exprimer ce genre de relation en C #. bases de données relationnelles sont tout simplement plus limitée (qui peut être un avantage et un inconvénient). Lorsque vous concevez une hiérarchie d'objets qui va être persisté dans une base de données, je trouve qu'il est généralement plus facile de commencer par un schéma de base de données d'abord, puisque pratiquement tous les schémas de base de données peut être facilement mis en correspondance à l'objet des relations, alors que le contraire est pas nécessairement l'affaire.

Dans ce cas particulier, vous pouvez modéliser l'administrateur avec la composition. Votre table Administrateurs fournirait tout état d'administration supplémentaire, plus la clé de l'utilisateur approprié. L'utilisateur FK serait également votre Admins PK.

Créé 26/08/2009 à 23:06
source utilisateur

voix
0

Mise en veille prolongée simplifie l' héritage. Exemple

Créé 27/08/2009 à 01:32
source utilisateur

voix
0

Votre exemple spécifique d'un Admininstrator être un utilisateur avec un UserType « Administrateur » est un exemple de la « Single Héritage de Table » modèle. Ceci est mis en œuvre dans certains des grands ORM là - bas. En particulier , "Rails ActiveRecord" et Hibernate.

Créé 26/08/2009 à 23:16
source utilisateur

voix
0

les schémas de bases de données relationnelles ne vraiment Normalisé prennent pas en charge polymorphisme à moins que vous allez à l'extérieur de ce qui sont généralement considérés comme des « meilleures pratiques » dans le monde du DBA. Ce n'est pas un nouveau problème par tous les moyens et le problème lui-même a été résolu mille fois plus de plusieurs façons différentes.

La vraie question est en place lorsque vous commencez à travailler avec les données - si vous travaillez avec datasets, vous allez continuer à avoir des défis qui tentent de mettre en œuvre toute sorte de polymorphisme. Si toutefois vous mappez un ensemble d'entités de domaine à votre modèle relationnel, vous y trouverez de nombreux outils pour vous aider à surmonter les limites du schéma de base de données relationnelle.

Puisque vous êtes un développeur C #, vous devriez probablement commencer par la recherche dans les 2 projets suivants, l'un qui vient avec le dernier service pack .NET.

ADO.NET Entity Framework:

http://msdn.microsoft.com/en-us/library/bb386876.aspx

NHibernate:

http://nhforge.org/Default.aspx

Créé 26/08/2009 à 23:13
source utilisateur

voix
0

Oui, l'héritage est probablement pas l'outil approprié lorsque vous mapper vers et à partir de la base de données.

L'héritage est beaucoup plus utile lors de la construction des cadres, où vous avez différents types d'objets qui se comportent différemment, mais ils ont des éléments communs.

Par exemple, vous pourriez avoir des « messages » passé entre un serveur et un autre. Chaque message a sa propre logique, vous devez donc différentes classes (pour éviter une déclaration énorme interrupteur ()), mais il y a des parties communes, comme le fait que chaque message a besoin de savoir comment sérialiser / désérialiser lui-même dans un cours d'eau (ce qui est méthode, tous les sous-classes de message doit passer outre). En outre, ayant tous les messages hériteront message vous permettra d'avoir une liste, et aller un par un et appeler leur méthode de sérialisation, par exemple.

Mais si tout ce que vous faites est logique métier / DB typique, l'héritage résistera le plus probable dans votre chemin.

Créé 26/08/2009 à 23:11
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more