Database Architectures

Definitions

The typical responsibilities of a Database Architecture are to:

Fulfill Requirements.
Provide an overall database structure and set of mechanisms that fulfill all architecturally significant requirements regarding persistent data.
Drive Designs & Implementations.
Influence and constrain the designs and associated implementations of the database(s).
Improve Communication.
Improve communication among the database’s stakeholders concerning the the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales.
Build Consensus.
Produce a formally documented consensus amoung the database’s stakeholdlers (e.g., members of the customer, development, and subcontractor organizations) concerning the:
- Architectural patterns and styles to be reused on the database,
- Top-level strategic logical and physical structures (i.e., major functions, classes, processes, components, their responsibilities, and their relationships) of the database,
- Most important, pervasive architectural mechanisms of the database, and
- Associated rationales.
Estimate Costs.
Provide input (e.g., number, size, and complexity of system components and mechanisms) for estimating the costs related to the database(s).
Enable Scheduling.
Provide a basis (e.g., components, mechanisms) for estimating the schedule of the database’s development or life-cycle cycle’s phases, builds, and milestones.

The typical contents of a database architecture are:

Database architectural style and patterns (e.g., object vs. relational database, local vs. distributed databases).
Logical database schema.
Physical database schema.
Major database-related architectural mechanisms.
Major technology and associated vendor selections.

These contents can be in the form of:

The typical stakeholders of a Database Architecture are:

Producers:
- Architecture Team (Overall Application)
- Database Team (Database Architecture)
- Security Team (Database Security)
Evaluators:
- Architecture Evaluation Team
- Customer Organization, which evaluates the architecture for feasibility and appropriateness
Approvers:
Maintainers:
- Architecture Team
- Database Team (Database Architecture)
- Security Team (Database Security)
Users:
- Database Team, which uses the database architecture during the design and implementation of the databases and associated data components.
- Independent Test Team, which uses the various architectures during the development of integration and functional tests.
- Software Development Team, which uses the various architectures during the design and implementation of the software components.

A database architecture typically is produced during the following phases:

A database architecture typically can be started if the following preconditions hold:

The typical inputs to a database architecture include:

Work Products:
- A relatively complete version of the application vision statement is available.
- Domain Model Document
- System Requirements Specification
- Glossary
Stakeholders:
- Domain Experts
- Database Vendor Representatives

A database architecture is typically constrained by the following conventions: