Data Analysis and Design
Data forms the centre of any decision making process in any business, and the data needs to be available at the right time and in the right format. This is particularly relevant in the process of evaluating a package, any change in a business process or change of the physical platform results in data changes. This plays an important role in Data Analysis and Design.
Data Analysis & Design Manual
Definition of a Data Model
A model can be seen as an abstraction of a real life concept. Using a graphical model ensures that any discrepancies that occur can be solved due to the fact that a graphical representation depicts a fact or rule more clearly. Models are more concise and precise and without ambiguity. It is easier to understand and remember a graphical model, and more information can be represented on a model than textual descriptions.
A data model can be seen as a systematic representation of the construct, content and representation of data. This represents a particular system in itÂ’s most natural, intrinsic form. It is documented as a set of relational definitions, relation relationships, graphical models and cross references. Formal techniques will be introduced to deal with the creation of formal, precise and flexible descriptions of the data and information architecture of an organisation. Different techniques are needed to specify the data model at various architectural levels. Each level will depict a stage of transformation in terms of the complete data model.
The foundation of the Data Analysis and Design techniques is based upon relational and set theory. The mathematical nature of the techniques makes them extremely precise. The techniques in the Data Analysis and Design methods are supported by a knowledge base, consisting of mathematically based structural and verification rules.
A Data Model depicts objects and events and the relationship between these objects and events. It also allows additional semantic description. The model is based on formal rule theories and is graphical of nature. The model is easy to understand and can be used to depict a business system on a high or low level (Existential, Conceptual, Logical or Physical level).
The fact that data attributes are being grouped into normalised relations and tables offers the following benefits:
-
High data stability.
-
Ease of growth of data.
-
Reduction in storage space.
-
Improved access and updating of data.
-
Embedded integrity of data.
​
Overview of a Data Analysis & Design
The first question that needs to be answered is where does data analysis and design start? It is important to realise that data analysis does not necessarily start only after project management has been initiated. Data analysis should be used as a guide to help project management initiate the correct projects as well as to determine the priorities of the different business systems.
A data analyst can define the boundaries of the business systems as well as the content and context. The design of the different subsystems can only start once the context, content and boundaries are defined. To determine the context of the system we need to determine what the schema boundaries are, define the subschema and determine the sub-schema interdependencies. Context can be defined as identifying what the interfaces are between the different subsystems. This information is then used in conjunction with the Function Effect Back Tracking Algorithm to determine the priorities of the different subsystems, only then can the detailed design of the different subsystems start.
In general, to model data means to determine the context of a system in terms of the enterprise data model, specify the conceptual data model, specify the logical data model and construct a physical model that can be implemented on a physical platform. Once the physical design phase has started, building and implementation of the business system can commence. It is important to realise that implementation and design of the data cannot be done without having a good understanding of what the platform or physical environment consists of.
On a conceptual level, we establish what the objects and events are, describe the terminology and specify the entity dependencies. Specifying the logical data model involves decomposing the data structure and synthesising the data model. Synthesising the data model involves the establishment of data assertions, attributes of entities, attribute dependencies and improving the logical data model. The model then gets synthesised into a normalised data representation.
To construct a physical data model involves specifying physical data constructs and optimise the operational usage of data. When the physical data structures are implemented, schema definitions need to be generated and compiled, database controls need to be added and data structures need to be populated.
Data Analysis and Design of a Business System
Although there are several approaches to designing a physical data model to be implemented, a basic approach or recipe can be used.
On a high level, a Subschema Interdependency Diagram will be created to define the subsystems or sub processes involved in the system. A conceptual model, the Entity Dependency Diagram, of each of these subsystems will then be drawn up to define the content and context of each of these business areas. The conceptual model will then be used to revisit and create the ideal Subschema Interdependency Diagram. This will then depict the interfacing between the subsystems and the dependency between them. On a conceptual data model, only the entities and the anticipated functional dependencies between the entities will be depicted.
The ideal conceptual model will be the entry point for creating an Attribute Dependency Diagram. From an ADD, new business areas or systems can be identified and which will alter the Subschema Interdependency Diagram. In a logical data model, the key sets and descriptive attributes for the entities are defined. The functional dependency is between the key sets of the entities on a logical model and not between the entities.
Through applying the Functional Effect Back Tracking algorithm to the logical data model, a more accurate Subschema Interdependency Diagram can be created and additionally a System Ring Diagram can be created. The System Ring Diagram will depict the architectural priority of the implementation sequence of the different subsystems.
The business priority of the subsystems should be taken into account, when determining the implementation sequence of the subsystems.
Once the priorities of the subsystems are determined, the synthesis algorithm can be used to create a normalised data model for the Attribute Dependency Diagram. The normalised data model will be on a logical level and is called a Data Structure Diagram.
When creating the physical data model, the environment or platform that will be used to implement the system on must be taken into account. Different platforms prefer different ways of normalising data.