Data Design

The data design action

The data design action translates data objects defined as part of the analysis model into data structures at the component level and a database architecture at application level when necessary.

Data design at the architectural level

The data objects defined during software requirements and analysis are modeled using ER diagram and data dictionaries. The data design translates these data objects into data structures at the software component level and database architecture at the application level.

Nowadays, data architecture is not only limited to data structures at the program level and databases at application level but to many applications encompassing hundreds of gigabytes of data. The challenge for business has been to extract useful information from this data environment, particularly when the desired information is cross-functional. Hence data mining techniques or knowledge discovery in databases (KDD) has been developed to extract appropriate-business level information. But sometimes it seems to be difficult for data mining techniques with the existence of multiple databases, their different structures, the degree of detail contained with the databases. Hence an alternate solution Data Warehouse adds an additional layer to the data architecture.

A data warehouse is a separate data environment which is a large and independent database that encompasses some of the data that are stored in databases that serves the set of applications required by a business.

Data design at the component level

Data design at the component level focuses on the representation of data structures that are directly accessed by one or more software components. Recalling that requirements, analyses, and design often overlap, consider the following set of principles for data specification:

1. Systematic analysis of data

The systematic analysis principles applied to function and behaviour should also be applied to data representations of data flow and content should also be developed and reviewed similarly to functional requirements and preliminary design. Data objects should be identified, alternative data organizations should be considered and the impact of data modeling on software design should be evaluated.

2. Identification of data structures and operations

All data structures and the operations to be performed on each should be identified. The design of efficient data structures must take the operations to be performed on the data structures into account.

3. Use of data dictionary

A data dictionary should be established and used to define both data and program design.

4. Low-level design decisions

Low-level data design decisions should be defined until late in the design process. The overall data organization may be defined during requirements analysis, refined during data design work and specified in detail during component level design.

5. Information hiding and data access

The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. The concept of information hiding and the related concept of coupling essential for the quality of software design which proves the importance of separating the logical view of a data object from its physical view.

6. Library of data structures

A library of useful data structures and operations that may be applied to them should be applied.

7. Language support for abstract data types

A software design and programming language should support the specification and realization of abstract data types. The implementation of a sophisticated data structure can be made exceedingly difficult if no means for direct specification of the structure exists in the programming language chosen for implementation.