Definition: Architecture Decision Record from where you should specialise the ADR SBBs regarding the Database Schema Design
Source: ISO/IEC/IEEE 42010:2022
Source reference: https://www.iso.org/standard/74393.html
Additional information: Database Schema Design is an important decision in IT architecture that involves creating a logical representation of the database structure. It involves defining the tables, columns, relationships, and constraints that make up the database. The schema design should be optimized for the specific needs of the application and should be flexible enough to accommodate future changes. A well-designed schema can improve performance, reduce data redundancy, and ensure data integrity. It is important to consider factors such as scalability, security, and data access when making database schema design decisions.
Example: Database Schema Design:
Decision: Utilizing a denormalized schema design for a reporting database to optimize query performance.
Rationale: Denormalizing the schema reduces the need for joins and improves query performance for reporting and analytics use cases, at the expense of increased data redundancy.
LOST view: Digital Solution Architecture Decisions Catalogue view
Identifier: http://data.europa.eu/dr8/egovera/DatabaseSchemaDesignGoal
EIRA traceability: eira:DigitalSolutionArchitectureDecisionGoal
ABB name: egovera:DatabaseSchemaDesignGoal
EIRA concept: eira:ArchitectureBuildingBlock
Last modification: 2023-06-15
dct:identifier: ADR-20230515180947754
dct:title: Architecture Decision Record about Database Schema Design
eira:adr_context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons.
eira:adr_decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how.
eira:adr_status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)]
eira:adr_consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture.
|
|
dct:modified | 2024-01-28 |
dct:identifier | ADR-20230515180947754 |
dct:title | Architecture Decision Record about Database Schema Design |
skos:example | Database Schema Design:
Decision: Utilizing a denormalized schema design for a reporting database to optimize query performance.
Rationale: Denormalizing the schema reduces the need for joins and improves query performance for reporting and analytics use cases, at the expense of increased data redundancy. |
eira:adr_context | The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. |
eira:adr_decision | The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. |
eira:adr_status | [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] |
eira:adr_consecuences | The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. |
eira:concept | eira:ArchitectureBuildingBlock |
eira:definitionSource | ISO/IEC/IEEE 42010:2022 |
eira:definitionSourceReference | https://www.iso.org/standard/74393.html |
skos:note | Database Schema Design is an important decision in IT architecture that involves creating a logical representation of the database structure. It involves defining the tables, columns, relationships, and constraints that make up the database. The schema design should be optimized for the specific needs of the application and should be flexible enough to accommodate future changes. A well-designed schema can improve performance, reduce data redundancy, and ensure data integrity. It is important to consider factors such as scalability, security, and data access when making database schema design decisions. |
eira:PURI | http://data.europa.eu/dr8/DatabaseSchemaDesignGoal |
dct:type | eira:DatabaseSchemaDesignGoal |
skos:definition | Architecture Decision Record from where you should specialise the ADR SBBs regarding the Database Schema Design |
eira:view | Digital Solution Architecture Decisions Catalogue view |
eira:eifLayer | N/A |
skos:broader | http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal |