Definition of a Data Model
A model can be regarded as an abstraction of a real-life concept. Utilising a graphical model ensures that any discrepancies that arise can be resolved, as a graphical representation vividly illustrates facts or rules. Graphical models are characteristically more concise, precise, and devoid of ambiguity. Understanding and retaining information from a graphical model is generally more straightforward, and it enables the representation of more information compared to textual descriptions.
A data model can be perceived as a systematic representation of the structure, content, and presentation of data, reflecting a specific system in its most natural, intrinsic form. It is documented through a collection of relational definitions, relation relationships, graphical models, and cross-references. Formal techniques will be introduced to address the creation of formal, precise, and adaptable descriptions of an organization's data and information architecture. Different techniques are necessary to specify the data model at various architectural levels, with each level depicting a stage of transformation in terms of the complete data model.
The foundational principles of Data Analysis and Design techniques are grounded in relational and set theory. The mathematical nature of these techniques ensures a high level of precision. The methods employed in Data Analysis and Design are supported by a knowledge base, incorporating mathematically based structural and verification rules.
A Data Model illustrates objects and events along with the relationships between them, allowing for additional semantic description. The model is underpinned by formal rule theories and is graphical in nature, facilitating its comprehension. It can be employed to depict a business system at high or low levels (Existential, Conceptual, Logical, or Physical).
The grouping of data attributes into normalised relations and tables offers several advantages, including:
1. Enhanced data stability.
2. Facilitation of data growth.
3. Reduction in storage space.
4. Improved access and updating of data.
5. Embedded integrity of data.
Overview of Data Analysis & Design
The initial inquiry in the process pertains to the commencement point for data analysis and design. It is imperative to recognise that data analysis need not commence solely after the initiation of project management. Rather, data analysis should function as a guiding element to assist project management in instigating the appropriate projects and ascertaining the priorities of distinct business systems.
A data analyst assumes the responsibility of delineating the parameters of the business systems, including their content and context. The design of individual subsystems becomes feasible only after defining the context, content, and boundaries. To establish the system's context, it is necessary to identify schema boundaries, define the subschema, and determine sub-schema interdependencies. Context, in this context, refers to discerning the interfaces between various subsystems. Subsequently, this information collaborates with the Function Effect Back Tracking Algorithm to ascertain the priorities of diverse subsystems, paving the way for the initiation of detailed designs for each subsystem.
In a broader sense, data modelling involves determining the system's context through the enterprise data model, specifying the conceptual data model, detailing the logical data model, and crafting a physical model viable for implementation on a physical platform. Once the physical design phase commences, the actual construction and implementation of the business system can commence. It is vital to grasp that implementing and designing the data necessitates a comprehensive understanding of the underlying platform or physical environment.
At the conceptual level, the identification of objects and events occurs, accompanied by terminology description and the specification of entity dependencies. The specification of the logical data model involves decomposing the data structure and synthesising the data model, incorporating elements such as data assertions, entity attributes, attribute dependencies, and refining the logical data model. Subsequently, the model undergoes synthesis into a normalised data representation.
Constructing a physical data model encompasses specifying physical data constructs and optimising the operational utilisation of data. Upon implementing the physical data structures, tasks such as generating and compiling schema definitions, adding database controls, and populating data structures become imperative.
Data Analysis & Design of a Business System
The primary query that requires clarification is where the commencement of data analysis and design occurs. It is crucial to recognise that data analysis does not exclusively commence after the initiation of project management. Instead, data analysis should serve as a guide, assisting project management in initiating the appropriate projects and determining the priorities of various business systems.
A data analyst is tasked with defining the boundaries, content, and context of business systems. The design process for distinct subsystems can only commence once these elements – context, content, and boundaries – are precisely defined. To ascertain the system's context, it is imperative to identify schema boundaries, define subschemas, and determine sub-schema interdependencies. Context, in this context, involves identifying interfaces between different subsystems. This information, coupled with the Function Effect Back Tracking Algorithm, is then utilised to establish the priorities of various subsystems, paving the way for the detailed design of these subsystems.
In a broader sense, data modelling involves delineating the system's context through the enterprise data model, specifying the conceptual data model, defining the logical data model, and constructing a physical model amenable to implementation on a physical platform. The initiation of the physical design phase allows for the commencement of building and implementing the business system. It is imperative to underscore that implementing and designing data necessitates a comprehensive understanding of the underlying platform or physical environment.
Conceptually, the establishment of objects and events, description of terminology, and specification of entity dependencies form the foundation for data modelling. Specifying the logical data model involves decomposing the data structure and synthesising the data model, incorporating data assertions, entity attributes, attribute dependencies, and enhancing the logical data model. The model is then synthesised into a normalised data representation.
The construction of a physical data model entails specifying physical data constructs and optimising the operational utilisation of data. Once the physical data structures are implemented, schema definitions must be generated and compiled, database controls added, and data structures populated.
Data Analysis and Design of a Business System
While various approaches exist for designing a physical data model for implementation, a fundamental approach or methodology may be applied.
At a higher level, a Subschema Interdependency Diagram is crafted to define the subsystems or subprocesses integral to the system. Subsequently, a conceptual model, the Entity Dependency Diagram, is formulated for each of these subsystems, outlining their content and context. This conceptual model serves as the basis for revisiting and creating the optimal Subschema Interdependency Diagram, portraying the interfaces and dependencies between subsystems. In a conceptual data model, only entities and anticipated functional dependencies are depicted.
The optimal conceptual model acts as the starting point for creating an Attribute Dependency Diagram. This diagram identifies new business areas or systems that may alter the Subschema Interdependency Diagram. In a logical data model, the key sets and descriptive attributes for entities are defined, with functional dependencies specified between key sets on a logical model, not between entities.
The application of the Functional Effect Backtracking algorithm to the logical data model facilitates the creation of a more accurate Subschema Interdependency Diagram and, additionally, a System Ring Diagram. The System Ring Diagram illustrates the architectural priority of the implementation sequence of various subsystems. Business priorities must be considered when determining the implementation sequence of subsystems.
Once subsystem priorities are established, the synthesis algorithm is employed to develop a normalised data model for the Attribute Dependency Diagram. This normalised data model, on a logical level, is referred to as a Data Structure Diagram.
When creating the physical data model, careful consideration must be given to the environment or platform designated for system implementation. Different platforms exhibit preferences for distinct methods of normalising data.