Comment un objet peut-il orienté programmeur obtenir son/sa tête autour de la base de données de programmation?

Question

J'ai été la programmation en C# et en Java pour un peu plus d'un an et avoir une bonne connaissance de la programmation orientée objet, mais mon nouveau projet nécessite une base de données modèle. Je suis à l'aide de C# et de Linq qui semble être un outil très puissant, mais j'ai du mal avec la conception d'une base de données autour de mon approche orientée objet.

Mes deux questions principales sont:

Comment faire face à l'héritage de ma base de données? Disons que je suis en train de construire un personnel de l'affectation de l'application et j'ai une classe abstraite, de l'Événement. De l'Événement je tire les classes abstraites ShiftEvent et StaffEvent. J'ai ensuite classes concrètes Maj (dérivé de ShiftEvent) et StaffTimeOff (dérivé de StaffEvent). Il y a d'autres classes dérivées, mais pour la clarté de l'exposé elles sont suffisantes.

Je devrais avoir une table séparée pour ShiftEvents et StaffEvents? Je devrais peut-être des tables séparées pour chaque classe de béton? Ces deux approches semblent comme ils allaient me donner des problèmes lors de l'interaction avec la base de données. Une autre approche pourrait être d'avoir une table d'Événements, et ce tableau aurait nullable colonnes pour chaque type de données dans une de mes classes concrètes. Toutes ces approches se sentent comme ils pourraient entraver l'extensibilité en bas de la route. Plus que probablement, il existe une troisième approche que je n'ai pas considéré.

Ma deuxième question:

Comment dois-je traiter avec les collections et l'un-à-plusieurs liens dans un objet orienté vers?

Disons que j'ai les Produits de la classe et de l'une des Catégories de la classe. Chaque instance de Catégories contiennent un ou plusieurs produits, mais les produits eux-mêmes devraient avoir aucune connaissance de catégories. Si je veux mettre en œuvre dans une base de données, puis chaque produit aurait besoin d'un ID de catégorie qui correspond à la table catégories. Mais cela introduit plus de couplage que je préfère à partir d'un OO point de vue. Les produits ne savez même pas que les catégories existent, beaucoup moins un champ de données contenant un ID de catégorie! Est-il un meilleur moyen?

Answer 1

Linq to SQL à l'aide d'une table par classe de solution:

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/10/01/linq-to-sql-inheritance.aspx

D'autres solutions (comme mon préféré, LLBLGen) permettre à d'autres modèles. Personnellement, j'aime bien la seule table de la solution avec une colonne discriminante, mais c'est probablement parce que nous avons souvent de la requête à travers la hiérarchie d'héritage et donc de voir que la normale de la requête, alors que l'interrogation d'un type spécifique ne nécessite qu'un "où" le changement.

Tous dit et fait, je pense personnellement que la cartographie OO dans des tables est mettre la charrue avant les bœufs. Il y a eu continuelle valoir que la différence d'impédance entre les OO et les relations a été résolu... et il y a eu beaucoup de OO bases de données spécifiques. Aucun d'entre eux ont détrôné le puissant simplicité de la relation.

Au lieu de cela, j'ai tendance à concevoir la base de données avec l'application, dans l'esprit, la carte ces tables d'entités et de construire à partir de là. Certains trouvent cela comme une perte de OO dans le processus de conception, mais dans mon esprit, la couche de données ne devrait pas parler assez haut dans votre application ait une incidence sur la conception de l'ordre supérieur des systèmes, juste parce que vous avez utilisé un modèle relationnel pour le stockage.

Answer 2

J'ai eu le problème inverse: comment obtenir ma tête autour de OO après des années de conception de base de données. Venez pour que, une décennie plus tôt, j'ai eu le problème d'obtenir ma tête autour de SQL après des années de "structure" plate-fichier de programmation. Il y a juste assez de similitudes entre la classe et les données de l'entité de décomposition de vous induire en erreur en pensant qu'elles sont équivalentes. Ils ne sont pas.

J'ai tendance à être d'accord avec le point de vue qu'une fois que vous êtes engagé à une base de données relationnelle pour le stockage, alors vous devez concevoir un modèle normalisé et compromettre votre modèle d'objet lorsqu'elles sont inévitables. C'est parce que vous êtes plus limité par le SGBD que vous êtes avec votre propre code - la construction d'un compromis modèle de données est plus susceptibles de vous causer de la douleur.

Cela dit, dans les exemples donnés, vous avez le choix: si ShiftEvent et StaffEvent sont pour la plupart similaires en termes de caractéristiques et sont souvent traités ensemble en tant qu'Événements, alors je serais enclin à mettre en œuvre une seule Événements de la table avec une colonne de type. Unique vues de table peut être un moyen efficace pour séparer les sous-classes et sur la plupart des db plates-formes peuvent être mises à jour. Si les classes sont de plus en plus différents en termes d'attributs, puis une table pour chaque pourrait être plus approprié. Je ne pense pas que j'aime les trois tables idée:"a l'un ou none" les relations sont rarement nécessaires dans la conception relationnelle. De toute façon, vous pouvez toujours créer un affichage d'Événements comme l'union de deux tables.

De Produit et de la Catégorie, si une Catégorie ne peut avoir de nombreux Produits, mais pas vice-versa, alors la normale relationnelles pour représenter ce est pour que le produit contient un id de catégorie. Oui, c'est le couplage, mais c'est seulement le couplage des données, et ce n'est pas un péché mortel. La colonne doit probablement être indexés, de sorte qu'il est efficace pour récupérer tous les produits d'une catégorie. Si vous êtes vraiment horrifié par l'idée alors de faire semblant c'est un plusieurs-à-plusieurs relations et utiliser un ProductCategorisation table. C'est pas un gros problème, bien qu'il implique une relation potentielle qui n'existe pas réellement et susceptible d'induire en erreur la somone à venir de l'application dans le futur.

Answer 3

À mon avis, ces paradigmes (le Modèle Relationnel et de la programmation orientée objet) s'appliquent à des domaines différents, ce qui rend difficile (et inutile) d'essayer de créer un mappage entre eux.

Le Modèle Relationnel est une représentation des faits (tels que "A est une personne"), c'est à dire les choses intangibles qui ont la propriété d'être "unique". Il n'a pas de sens à parler de plusieurs "instances" de la même réalité - là est juste le fait.

La Programmation Orientée objet, est un paradigme de programmation détaillant un moyen de construire des programmes informatiques afin de répondre à certains critères (ré-utilisation, le polymorphisme, se cacher de l'information...). Un objet est généralement une métaphore de quelque chose tangible d'une voiture, un moteur, un gestionnaire ou une personne etc. Les choses tangibles ne sont pas des faits - il peut y avoir deux objets distincts à l'identique de l'état sans qu'il soit pour le même objet (d'où la différence entre égaux et == en Java, par exemple).

Printemps et d'outils similaires fournir l'accès à des données relationnelles par programme, de sorte que les faits peuvent être représentés par des objets dans le programme. Cela ne signifie pas que la programmation orientée objet et le Modèle Relationnel sont les mêmes, ou qui devrait l'être confondu avec eachother. Utiliser le Realational Modèle pour la conception de bases de données (collections de faits) et de la programmation orientée objet pour la conception de programmes d'ordinateur.

TL;DR version (Objet-Relationnelles, d'adaptation d'impédance distillée):

Faits = la recette sur votre réfrigérateur. Objets = le contenu de votre réfrigérateur.

Answer 4

Des Frameworks tels que

1. Hibernate http://www.hibernate.org/
2. JPA http://java.sun.com/developer/technicalArticles/J2EE/jpa/

pouvez vous aider de bien résoudre ce problème de l'héritage. par exemple http://www.java-tips.org/java-ee-tips/enterprise-java-beans/inheritance-and-the-java-persistenc.html

Answer 5

J'ai également obtenu de comprendre la conception de base de données, SQL, et en particulier les données centrée sur la vision du monde avant de s'attaquer à l'approche orientée objet. L'objet-relationnel-impédance de non-concordance de me déroute toujours.

La chose la plus proche que j'ai trouvé pour obtenir une poignée sur ce qu'elle est: à la recherche des objets non à partir d'un objet orienté progamming point de vue, ou même à partir d'une conception orientée objet, mais à partir d'une analyse orientée objet en perspective. Le meilleur livre sur les CHOSES que j'ai eu a été écrit au début des années 90 par Peter Coad.

Sur la base de données côté, le meilleur modèle pour comparer avec des CHOSES n'est pas le modèle relationnel de données, mais l'Entité-Relation (ER) modèle. Une ER modèle n'est pas vraiment relationnel, et il ne précise pas la logique de conception. Beaucoup de relationnel apologistes pense que c'est ER de la faiblesse, mais il est en fait sa force. ER est utilisé au mieux pas pour la conception de base de données, mais pour les besoins de l'analyse d'une base de données, autrement connu comme l'analyse des données.

ER de données, d'analyse et de CHOSES sont étonnamment compatibles les uns avec les autres. ER, à son tour, est assez compatible avec relationnelle de la modélisation de données et donc à la conception de base de données SQL. OOA est, bien sûr, compatible avec INONDATIONS et, partant, à la POO.

Cela peut sembler long chemin autour. Mais si vous garder les choses abstraites assez, vous ne perdrez pas trop de temps sur l'analyse des modèles, et vous trouverez qu'il est étonnamment facile de surmonter les différences d'impédance.

La chose la plus importante pour obtenir de plus sur le plan de l'apprentissage de la conception de base de données est ceci: le couplage de données comme la clé étrangère à la clé primaire de liaison vous opposé à votre question ne sont pas horrible du tout. Ils sont l'essence même de lier les données liées ensemble.

Il y a un phénomène de pré base et de pré orientée objet des systèmes appelé l'effet d'entraînement. L'effet d'entraînement est là qu'une apparence simple changement à un système finit par entraîner conséquent nécessaire évolution tout au long de l'ensemble du système.

La programmation orientée objet contient de l'effet d'entraînement principalement par le biais de l'encapsulation et de se cacher de l'information.

De données relationnelles, la modélisation permet de surmonter l'effet d'entraînement principalement grâce à des données physiques de l'indépendance et de la logique de données de l'indépendance.

Sur la surface, ces deux semblent comme fondamentalement contradictoire modes de pensée. Par la suite, vous allez apprendre à utiliser à bon escient.