8
votes

Meilleure approche pour architecte l'intégration de deux bases de données distinctes?

J'ai rencontré les questions suivantes au travail et je n'ai pas l'expérience ou la connaissance afin de leur répondre, j'espère que certains d'entre vous sont plus sages que nous pourrez me diriger dans la bonne direction , toutes les réponses seront grandement appréciées!

scénario

Nous avons deux aspects de l'entreprise utilisant des bases de données distinctes, des ressources humaines et des zones opérationnelles (HOMECARE).
Les ressources humaines gardent une trace des employés de la société, des modèles de changement de travail, de l'absence, de la rémunération, etc. HomeCare tient une trace des informations clientes, des visites à domicile, des dates de visite et de l'employé / s responsable de la visite.

Ces deux systèmes sont séparés et nous sommes actuellement en train de regarder des moyens de les intégrer.

En outre, nous examinons comment organiser notre code qui examine ces deux bases de données, dans des bibliothèques organisées réutilisables.

Nous avons trois applications à l'aide d'un humanResources.dll, responsable de la communication avec un contexte d'objet EF 4, contenu dans la bibliothèque. Le contexte de l'objet est presque une image miroir de la base de données tel qu'il se trouve.

questions

Nous sommes sur le point d'ajouter une quatrième application qui utilisera des données dans la base de données HR.
faisons-nous:

Créer un nouveau modèle de données EF, responsable de la fourniture d'informations que seule l'application a besoin, alors que dupliquer certaines entités communes telles comme employé.
ou

Ajouter les nouvelles entités / tables à la déjà grand modèle et accepter c'est va devenir grand.

à plus long terme, nous devons rejoindre les informations de modèle de décalage dans la base de données HR aux visites clientes dans la base de données des zones opérationnelles (HOMECARE) dans une 5ème application. < / p>
Nous avons une idée de ce que nous pourrions faire; Nous avons proposé ce qui suit:

créer un calque qui se trouve entre le Contexte de l'objet HumanResources et Contexte de l'objet HomeCare, responsable Pour rejoindre les deux ensembles de données ensemble.
Y a-t-il d'autres approches qui nous bénéficieraient?

architecture database-design integration facade entity-framework-4

1 commentaires

D'une manière ou d'une autre, cela sent comme un travail pour LDAP.

4 Réponses :

2
votes

On dirait que vous devez faire une grave modélisation de données.
Vous en avez certainement besoin pour le long terme pour que vous ne vous soyez pas dans des conflits graves. (S'il y a une chose qui aura un impact significatif sur votre capacité à soutenir / étendre les systèmes et à soutenir la croissance des entreprises - sa gestion des données). La bonne chose à propos de (business) Les données sont que vos intervenants de votre entreprise (ou devraient-ils être compris de manière appropriée et être motivés de manière appropriée pour vous soutenir. La valeur d'un tel exercice apportera devrait être une vente facile. Avoir une partie de cela en place à court terme aidera également.
Les sources de données fournies avec des packages Produits (commercial de la tablette) ne seront pas ouvertes au changement sans mettre ces systèmes à risque - mais cela ne signifie pas que vous ne pouvez pas utiliser l'ETL et d'autres bases de données pour créer des marchés de données qui apportent des données disparates ensemble. Dans ce type d'approche, la modélisation des données et la cartographie des données entre les systèmes seront importantes - mais aussi le calendrier.
Vous aurez plus de flexibilité avec les applications internes - mais vous voudrez peut-être résister à des changements tactiques à moins que vous n'ayez une raison très convaincante, sinon vous devrez probablement les réorganiser de toute façon.
Dans le cadre de cet exercice, vous voudrez considérer le Système d'enregistrement de chaque pièce de données - d'où vient-il? Qui le possède? Vous pouvez commencer à un niveau de haut niveau en élaborant un modèle de données conceptuel, cela traitera probablement plus avec des jeux de données logiques que des "colonnes" spécifiques.
Utilisez ces informations pour guider les décisions supplémentaires.
En termes d'approche immédiate (et de votre question): En termes généraux, il pourrait penser à mettre une couche d'abstraction entre vos systèmes et les données, de sorte que les applications soient amorties du changement lorsque cela se produise.

Créer un nouveau modèle de données EF, chargé de fournir des informations que seuls les besoins de l'application, tout en dupliquant certaines entités communes telles que l'employé.
Le gros problème avec la duplication reçoit les données dans un état qui est boueux - qui est le "réel" enregistrement. Cela peut facilement te tuer. Quels sont les avantages de cette approche dans votre contexte? Souhaitez-vous le faire dans une perspective de soutien? Facilité de développement?

8 commentaires

Bonjour Adrian, merci pour votre réponse. Le problème que nous sommes confrontés est que nous avons deux aspects de notre entreprise à fonctionner sur différentes bases de données. Chaque aspect a une grande variété d'applications que nous ne pouvons pas nous permettre de réécrire. Nous recherchons un moyen d'intégrer les deux bases de données sans passer de la terre, pour des projets futurs, à l'aide de l'Entité Framework 4 et C #

Je suppose donc que mapper les flux de données et la cartographie des données vous aideraient à gérer cette intégration. Je suppose que vous souhaitez intégrer les "données" - pas les bases de données physiques réelles; C'est une différence subtile que les gens ne voient pas toujours.

Ah oui, c'est correct. Nous sommes incapables de redéfinir les bases de données car elles ont trop d'applications utilisant chacune d'elles, la modification / la ré-écrivie n'est pas une option. - Une approche pour intégrer les données est ce que nous suivons.

Cela peut être fait avec beaucoup moins de travail que vous proposez.

@Steinberg - On dirait que vous en savez plus à ce sujet que moi, alors pourquoi ne pas mettre en place une réponse qui justifie réellement de telles affirmations?

@Adrian K, lisez la réponse sélectionnée. Il a une meilleure approche

Oui, c'est une bonne approche; Je suppose que je venais d'une perspective centrée sur la base de données de niveau inférieur :)

+1, @adrian K, votre solution a beaucoup de sens s'il commencait l'application à la terre. Mais parfois, lorsque vous avez des applications de production importantes qui fonctionnent déjà, il n'est pas toujours possible de remodeler la structure de données. C'est pourquoi le modèle de façade est génial - il vous permet d'intégrer votre application avec des systèmes hérités, sans devenir esclave de décisions de conception médiocres du passé.

12
votes

Implémentez le modèle de façade
Une façade est essentiellement un adaptateur pour un sous-système complexe. Depuis que vous avez deux sous-systèmes, je vous recommanderais de créer trois classes avec les fonctionnalités suivantes:

humanresourcesfacade : une classe qui enveloppe toutes les fonctionnalités "ressources humaines". Le travail de cette classe est d'exposer des méthodes qui exécutent chaque unité de travail que l'application des ressources humaines est responsable de l'expulsion d'aucune information sur l'application des ressources humaines au client.
HOMECAREFACADE : une classe qui enveloppe toute la fonctionnalité "HomeCare". Le travail de cette classe est d'exposer des méthodes qui exécutent chaque unité de travail que l'application HomeCare est responsable, sans exposer aucune information sur la base de données HOMECARE au client.
ApplicationFaCade : une classe qui enveloppe les deux humanresourcesfacade et HomeCarefaCade et fournit des méthodes publiques à vos clients qui n'ont pas besoin de connaissances sur le fonctionnement intérieur de l'une des deux façades imbriquées. Le travail de cette classe est de savoir: (a) lesquelles des deux façades imbriquées sont responsables de chaque appel client, (b) exécuter l'appel du client de l'applicationFaCadade en établissant un appel à la méthode appropriée sur la façade imbriquée et ( c) Traduire les données reçues de la façade imbriquée en format utilisable par le client et non dépendant des formats de données de la façade imbriquée. Je recommanderais d'utiliser un modèle d'objet POCO pour créer une représentation commune dans le code des données qui ne dépendent pas de la mise en œuvre réelle de la persistance. La technique du modèle de domaine que Adrian K a suggéré une bonne approche, mais si vous n'êtes pas familier avec les modèles et la méthodologie, cela pourrait finir par être très déroutant et prendre beaucoup plus de temps que les techniques plus intuitives. Une alternative consiste à simplement utiliser des objets de données et une mappeuse de données . Le mappeur de données, prend essentiellement les données d'une source de données et la transforme en un objet qui ne dépend pas de la source de données ou de l'objet MAPER. J'ai inclus un lien ci-dessous. Une chose que je voudrais préciser est que si je l'ai dit ApplicationFacade a trois emplois, je ne conseille pas que vous ne respectez pas le principe de responsabilité unique . Je ne veux pas dire que les besoins de la classe à faire toutes ces trois choses par lui-même, mais qu'il devrait encapsuler tout mécanisme vous décidez d'utiliser pour l'exécution de ce processus, et qu'aucune autre partie de l'application doit accéder à ces préoccupations de l'extérieur de la < code> ApplicationFacade . Par exemple, vos objets métier ne devrait pas savoir de quelle source de données qu'ils ont été construites - que l'information ne doit pas être accessible depuis un autre endroit que ce qui est encapsulé par le ApplicationFacade . Articles de référence Martin Fowler sur les façades application Martin Fowler sur les données cartographes Une libre, mais introduction complète au domaine Conception Driven
2 commentaires +1 Pour les façades de la persistance abstraite et de la référence au livre DDD sur INFOQ. +1, Bounty et réponse, merci beaucoup pour le moment où vous avez mis dans cette réponse! Cela a été une aide massive!
1 votes Cela dépend beaucoup de ce que vous entendez par intégration. Si vous souhaitez simplement combiner les différentes tables à des fins de déclaration, vous devez examiner un processus pour extraire et charger des données sélectionnées de chaque système dans une datawarehouse. Vous devrez définir un modèle de données commun pour les deux systèmes. Ces données peuvent alors être isolées pour les rapports. Si vous souhaitez qu'un système d'invoque les services ou récupérez les données d'un autre système, je vous recommanderais d'utiliser le modèle de SOA classique. Exposez les fonctions que vous souhaitez mettre à la disposition de l'autre système sous forme de services via du savon, des messages de repos ou similaires. Et obtenir les systèmes clients utiliser ces méthodes et uniquement ces méthodes pour envoyer ou récupérer des données. Évitez s'il est possible directement dans la base de données des systèmes étrangers, reproduisant les données d'un système à l'autre ou en faisant des appels d'API directs vers le système source. Le principe de guidage devrait être "Si je remplace System X avec System SuperX, quelle est sa facilité de maintenir les autres systèmes de travail". 1 commentaires +1, pour la suggestion de service Web et pour le principe directeur 0 votes Depuis que vous recherchez une solution à long terme, il s'agit d'une infrastructure d'affaires, je vous recommande de migrer vers LDAP . Avoir une lecture. 1 commentaires Pourriez-vous élaborer comment la LDAP pourrait être utilisée pour résoudre ce problème spécifique?

Articles qui pourrait vous intéresser : Correction d'un état incohérent immédiatement ou paresseusement lorsque des données sont demandées organisation grpc dans les microservices Microservices et concept de «point de défaillance unique» La langue anglaise est-elle un standard pour décrire un Webservice (Rest, SOAP etc.)?