Database architecture describes how data will be introduced into the overall system, how it will be processed, stored and used by an organization or business. In many ways it can be compared to the blueprint for a house. The database architecture 'blueprint' describes how data will collected, integrated, aggregated and any other processes that will use that data for the organization. Included in this process is representing real-life business activities and entities as abstract data models. This is a necessary step before implementing a database design.
Similar to the house blueprint that describes how the house will be built from the choice of materials to the the sizes and style of the rooms and roofing, database architecture describes the many processes and structures that compromise the overall data system. This layout is critical to guiding how data flows through the system from beginning to end.
If the database architecture is not stable or robust, a failure at one point can create a wave of cascading failures that can cause the entire system to breakdown and result in expensive system outages and loss of productivity.
Without the guidance of a properly implemented database architecture design, common data operations might be implemented in a variety of different ways, rendering it difficult to understand and control the flow of data within such systems. This sort of process fragmentation is highly undesirable as it leads to increased costs, redundant efforts and overall system throughput. These sorts of difficulties may be encountered with rapidly growing enterprises and also enterprises that service different lines of business.
During the definition of the target state, the database architect breaks a subject down to the atomic level and then builds it back up to the desired form. This involves breaking the subject down by going through three traditional database architecture processes:
A summary-level data model that normally describes an entire enterprise. As it is highly abstract, the conceptual data model may also be referred to as a conceptual model.
The logical model refines the elements introduced by the conceptual data model and forms the basis of the physical data model. It typically describes data requirements from the business point of view. Logical data models help to define the detailed structure of the data elements in a system and the relationships between data elements.
Logical data models depict the logical entity types, typically referred to as entity types, the data attributes describing those entities, and the relationships between the entities.
Here are some common characteristics of a logical data model:
The physical data model visually represents the structure of the data as implemented by a persistent storage mechanism such as a relational database management system. The physical data model is concerned with the implementation of the data entities. It incorporates optimizations that may include partitioning or merging entities, duplicating data, creating identification keys and indexes.
Common characteristics of a physical data model:
The physical data model will also include other physical objects such as views, primary key constraints, foreign key constraints, indexes, security roles, store procedures, XML extensions, file stores, etc. Along with providing a visual representation of the database structure, a significant benefit of defining a physical data model is that the database schema can automatically be derived.
Reverse engineering refers to a process or function to create a logical and physical data model by extracting information from an existing data source. Reverse engineering results in a physical data model, a logical data model, or a combination of the two.
Various constraints and influences will have an effect on database architecture design. The main influences will include the overall organizational requirements, the techonology implemented, economics and business policies.
The enterprise requirements, expected and acceptable performance levels, reliability and transparent management of data. Also, the conversion of raw data such as transaction records and image files into more useful information forms through such features as data warehouses is also a common organizational requirement. One architecture technique is to split between managing transaction data and (master) reference data. Another technique is splitting data capture systems from data retrieval systems (as done in a data warehouse).
The database architecture and database design usually dictate the technology required, although some technology drivers will derive from existing organizational integration frameworks and standards, organizational economics, and existing site resources (e.g. previously purchased software licensing).
The financial requirements and budget must considered during the database architecture phase. It is possible that some solutions, while optimal in principle, may not be possible to implement due to their cost. External factors such as the business cycle, interest rates, market conditions, and legal considerations could all have an effect on decisions relevant to database architecture.
Business policies such as internal organizational policies, regulations, professional standards and any governmental laws may possibly may come into play. These policies and rules will help describe the manner in which enterprise wishes to process their data.
Data Processing Needs
These needs include accurate and reproducible transactions performed in high volumes, data warehousing for the support of management information systems (and potential data mining), repetitive periodic reporting, ad hoc reporting, and support of various organizational initiatives as required (i.e. annual budgets, new product development).
Parthian Systems is well-versed in database architecture and we can design a reliable, scalable database platform for you.