Data integration modeling in software development lifecycle

The data integration model follows a common level of requirements and design abstraction refining that occurs when data is modeled in the software development lifecycle. Just as there are conceptual, logical, and physical data models, there are conceptual, logical, and physical data integration requirements that need to be captured at different points in the software development lifecycle, which may be demonstrated in the process model.

The following is a brief description of each model type, and a more complete definition of roles, steps, and model examples will be elaborated later in this chapter.

Conceptual data integration model definition. Creating a Data integration requirement presentation that is not implemented for the target system will serve as a basis for determining how they can be met.

Logical data integration model definition. At the dataset level, the detailed data integration requirements are presented, and the transformation rules and the target logical datasets are described in detail. These models are still considered to be technology-independent. At the logical level, the focus is on the real source table and the capture of the proposed Target store.

Physical data integration model definition. A detailed description of the data integration specifications generated at the component level. They should be presented in a component-based way, and can show how data will optimize processes through the data integration environment in selected development technologies.

Building models on top of reference architectures

Building the data model in the system development lifecycle is a relatively easy process. A conceptual data model usually has only one logical model, and a logical data model usually has only one physical model. Although the entities within a model can be further decomposed or normalized, it is rarely necessary to divide a data model into two separate models.

The process model has always been further divided into discrete functions. For example, in Figure 3, the top process of the data flow diagram is an internal and external diagram, which is further divided into several separate functional models.

Fig. 3 The traditional process model: Data Flow diagram.

The data integration model is also divided into functional model, which is based on the data integration Reference Architecture and the system development lifecycle State.

Figure 4 depicts how the conceptual, logical, and physical data integration models are decomposed.

Figure 4 The data integration model for the life cycle of the system development.