Database Architecture

The Database Management Systems (DBMS) architecture as envisioned as ANSI/SPARC, introduces a conceptual framework known as the Three Level DBMS Architecture, This framework defines the overall Database description at three distinct levels: the internal level the conceptual level, and the external level.

Each of the levels play a unique role.

• Internal Level (Physical Level) - At the lowest level of data abstraction, the internal level also referred to as the physical level, pertains to the physical representation of the database on the machine. It delves into how the data is physically stored and organized on the storage media. This level encompasses the optimization of runtime performance and efficient utilization of storage space. Topics addressed include techniques for allocating storage space for data, indexes and defining data access paths, implementing data compression and encryption methods and strategically placing records for optimal retrieval.
• Conceptual Level (Logical Level) - The conceptual level or the logical level focuses on the logical structure of the entire database. It answers questions about what data is stored, what is the relationship between various data elements and provides a comprehensive view of user requirements without going into the physical implementation details, this level abstracts away the complexities of the physical data storage structures and enables the users to interact with the database with a high level representation of the database that aligns with their conceptual understanding.
• External Level (View Level) At the highest level of abstraction, the external level, also referred to as the view level caters to the user’s understanding of the database. In many cases the users of the applications need not access the entire database, but just a subset of the data tailored for their specific needs. The external level permits users to access data customized to their requirements, allowing the same dataset to be presented differently to various users simultaneously. This flexibility provides a robust security mechanism by concealing parts of the database from specific users, effectively hiding attributes that are not relevant to their view.

In the three level Database Management Systems (DBMS) architecture, the schema of the database is described at each of these levels. Consequently the architecture is also referred to as the Three Level Schema Architecture with each level having it’s own schema.

• The internal level features an internal schema, describing the physical storage structure of the database.
• The conceptual level encompasses a conceptual schema, outlining the structure of the entire database, providing a comprehensive view.
• The external level consists of external schemas or user views, each tailored to the requirements of a particular user or user group. These views hide the remainder of the database, ensuring that users are only exposed to relevant data.

The Database Management Systems (DBMS) in collaboration with the Operating System, manages the physical level, whenever a user at the external level issues a request for new external view, the DBMS performs a process called as mapping, transforming the request into corresponding operations at the conceptual and internal levels. This mapping ensures that the data retrieval and presentation aligns with the user needs.

The primary advantage of the Three Level Architecture is it’s ability to provide data independence. Data independence is the capacity to modify the schema at on level without the need to alter the data at other levels, it can be categorized in two ways.

• Logical Data Independence - This enables us to make changes to he conceptual schema without affecting the external schemas or application programs. Modifications to the conceptual level could include constrains, addition or removal of data items, or other alterations, all of which can occur without affecting the external view.
• Physical Data Independence - This enables enables to make changes to the physical level without making changes to the conceptual or the external level, This could include creation of additional access structures, alterations in storage structures, or similar changes without affecting the higher-level schemas.

It is difficult to attain Logical Data Independence when compared to Physical Data Independence

As most applications rely on the logical structure of the database, so making any changes on the logical level will necessitate changes on the application side too.

In essence, the core objective of a database system is to provide data abstraction, concealing the intricacies of data storage and organization from users. This abstraction is realized through the use of a data model, which serves as an abstract model describing how data is represented and utilized within the system. A data model comprises data structures and conceptual tools that define the structure of the database, encompassing data types, Database Relationships, and Database Constraints.

A data model not only defines the structure of data but also specifies a set of operations that can be performed on the data. It consists of both data model theory, a formal description of data structure and usage, and data model instances tailored to specific applications. The process of applying data model theory to create a data model instance is known as data modeling.

Data models can be categorized based on the concepts they employ to represent database structure. Three primary types of data models include:

• High-Level or Conceptual Data Models: These models focus on the abstract, logical representation of data and its relationships, independent of implementation details. They are designed to provide a high-level understanding of data organization and are often used during database design and planning.
• Representational or Implementation Data Models: These models bridge the gap between high-level conceptual models and low-level physical models. They aim to represent data structures and relationships in a manner that is closer to the actual implementation, facilitating the translation of conceptual models into physical database designs.
• Low-Level or Physical Data Models: These models detail the physical storage and implementation of data in the database system. They encompass aspects such as storage mechanisms, access methods, and indexing techniques, providing the foundational structure for data storage and retrieval.

In recent years, the semi-structured data model has gained prominence as a means of representing data that does not conform to rigid, structured schemas. In this model, data items of the same type are not constrained to have identical sets of attributes, allowing for flexibility in data representation. Semi-structured data is often self-describing, with schema information embedded within the data itself. This model is particularly relevant for handling sources like the web, where data lacks strict schema constraints, and flexibility in data representation is essential.

The emergence of semi-structured data modeling has several motivations:

• Handling data sources like the web, which do not adhere to traditional database schemas.
• Facilitating flexible data exchange between heterogeneous databases with varying structures.
• Enabling easy data discovery and storage, even in scenarios where data types are diverse and dynamic.
• Simplifying querying without prior knowledge of data types.

Notably, XML (Extensible Markup Language) serves as a prominent means of representing semi-structured data. It allows the definition of schemas using XML schema language, enabling varying levels of schema flexibility over data elements.