Design patterns for data integration

Abstract

Purpose -The application landscapes of major companies all have their own complex structure. Data have to be exchanged between or distributed to the various applications. Systemizing different data integration patterns on a conceptual level can help to avoid uncontrolled redundancy and support the design process of data integration solutions. Each pattern provides a solution for certain data integration requirements and makes the design process more effective by reusing approved solutions. Proposes identifying these patterns. Design/methodology/approach -After a broad literature review data were obtained from interviews and documentary sources. Ten semi-structured interviews were conducted within four different companies operating in the financial service industry. EAI-and IT-architects as well as project managers and CTOs were involved in these interviews. Findings -Five different data integration patterns were identified. Solutions for upcoming data integration requirements can be designed using these patterns. Advantages and disadvantages as well as typical usage scenarios are discussed for each identified data integration pattern. Research limitations/implications -In order to identify data dependencies, to detect redundancies and to conduct further investigations, a consistent methodology for the description of application landscapes has to be developed. The presented design patterns are one part of this methodology only. The approach in this paper only considers data integration while in reality there are also other integration requirements like functional or process-oriented integration. Practical implications -The identified design patterns help practitioners (e.g. IT-architects) to design solutions for data integration requirements. They can map the conceptual patterns to company specific technologies or products to realize the solution physically. Originality/value -The design patterns are indifferent from any technology or products which ensure a broad application. Business requirements (e.g. requirement for autonomous processing) are considered first when designing a data integration solution.

Managing the business benefits of product data management: the case of Festo

“…The central PDM system distributes product data for newly introduced products and when existing products are modified. The target systems then hold a local copy (see Schwinn and Schelp, 2005) of the global product data.…”

Spatial data fusion in Spatial Data Infrastructures using Linked Data

“…In this article, spatial data fusion refers to the synthesis of spatial data from multiple sources to extract meaningful information with respect to a specific application context. Therefore, the understanding of data fusion proposed here includes what others describe as conflation (e.g., Saalfeld 1988, Ruiz et al 2011, data integration (e.g., Devogele et al 1998, Walter and Fritsch 1999, Schwinn and Schelp 2005 or data concatenation (e.g., Kiehle et al 2007, Longley et al 2010.…”

“…These approaches can be discriminated (Figure 1) based on the application field, the level of automation, the operation frequency, the matching level, the underlying data model and the spatio-temporal orientation of the input data (Yuan and Tao 1999, Schwinn and Schelp 2005, Ruiz et al 2011. The corresponding process implementations can be further distinguished based on the input and output data structures they support, the applied matching strategies, their computational performance or other common quality measures.…”

Design Examination through Pattern Characteristic Identification: A New Kain Punca Potong (KPP) Weaving Design

“…To ensure that the design patterns produced are accurate and long-term relevant, they should be independent of specific design fabric implementations. This is because pattern designing is very precise when it comes to examining the pattern arrangement of shapes and lines [10]. KPP flaunt different structures compared to other fabrics.…”