Data models in Database Management Systems (DBMS) play a pivotal role as architectural blueprints, translating abstract concepts into practical structures. These models are essential for ensuring data accuracy, integrity, and efficiency throughout storage and retrieval processes. Conceptualising data models requires a delicate balance between simplicity and complexity, capturing the essence of real-world entities and their interconnections.
From conceptual to logical to physical models, each stage contributes to the smooth operation of the database ecosystem. Data models empower organizations to navigate vast data landscapes with precision, unveiling insights and facilitating informed decision-making. With their intricate arrangement of tables, keys, and relationships, data models infuse vitality into databases, turning raw data into actionable intelligence. Step into the captivating world of data models, where each model narrates a distinctive tale of organisation, efficiency, and innovation.
Data Models in DBMS are basically divided into three categories:
- Conceptual Data Model
- Representational Data Model
- Physical Data Model
1. Conceptual Data Model
This offers a top-level depiction of the business or analytical processes supported by a system. It outlines the required data types, interrelationships between various business entities, and related business regulations. Conceptual data models primarily target business executives, aiding them in understanding system functionality and verifying alignment with business requirements. These models remain independent of specific databases or application technologies.
2. Representational Data Model
This data model specifically portrays the logical aspect of the database, omitting the representation of its physical structure. The representational data model directs attention primarily to the database’s design phase. One commonly utilised representational model is the Relational model, which encompasses Relational Algebra and Relational Calculus. Within the Relational Model, data and their relationships are predominantly depicted using tables. Although it’s a theoretical concept, its practical implementation occurs in the Physical Data Model.
3. Physical Data Model
A logical model forms the foundation for developing a physical data model, outlining how data gets stored in a physical database. Physical models are tailored to the database management system (DBMS) or application software being utilised, defining the structures utilised by the database or file system to store and manage data. This encompasses tables, columns, fields, indexes, constraints, triggers, and other DBMS components. Database designers leverage physical data sources to craft designs and generate schemas for databases.
The Hierarchical Model stands as the initial DBMS model, arranging data in a hierarchical tree structure. It begins from the root, housing root data, and progressively extends into a tree structure by adding child nodes to parent nodes. This model adeptly illustrates real-world relationships such as food recipes or website sitemaps.
This data modelling option was once popular in mainframe databases but is less utilised today. Network data models are built upon hierarchical ones by permitting child records to link with multiple parent records, facilitating many-to-many node relationships. The Conference/Committee on Data Systems Languages (CODASYL), a defunct technical standards group, embraced a network data model specification in 1969, hence the reference to the network technique as the CODASYL model.
-
Entity-Relationship Model
This model depicts the relationships among real-world entities akin to the network model but without direct reliance on the database’s physical structure. Typically, it’s employed for conceptual database design.
In this context, entities representing people, places, and things around which data is centred possess specific attributes forming their domain collectively. Additionally, the cardinality, indicating the relationships between entities, is also delineated.
The relational model, the most prevalent, organises data into tables, termed relations, comprised of columns and rows. Each column denotes an attribute of the entity, like price, zip code, or birth date, and collectively, these attributes form a domain. A specific attribute or combination thereof is designated as a primary key, which can be referenced in other tables as a foreign key.
Each row, also known as a tuple, contains data pertaining to a distinct instance of the entity, such as an individual employee. Furthermore, the model accommodates various types of relationships between tables, encompassing one-to-one, one-to-many, and many-to-many relationships.
-
Object-Oriented Data Model
During the 1990s, alongside the evolution of object-oriented programming and the emergence of object databases by software vendors, object-oriented data modelling gained traction. This approach bears resemblance to the Entity-Relationship (ER) method in its representation of data, attributes, and relationships, but it introduces the abstraction of entities into objects.
Objects sharing common attributes and behaviours can be organised into classes, with new classes capable of inheriting attributes and behaviours from existing ones. Despite this, object databases have remained niche technologies, primarily suited for specific applications, thus restricting the widespread adoption of object-oriented modelling.
-
Object-Relational Data Model
Hybrid database model merges the ease of use found in the relational model with certain advanced features of the object-oriented database model. Essentially, it enables designers to integrate objects within the conventional table format.
Supported languages and call interfaces encompass SQL3, vendor-specific languages, ODBC, JDBC, and proprietary call interfaces, which serve as extensions of the languages and interfaces utilised by the relational model.
This model presents the database as a table comprising rows and columns, offering a straightforward structure. However, accessing data necessitates reading the entire table, rendering the process slow and inefficient.
-
Semi-Structured Data Model
The semi-structured model represents an advancement over the relational model, blurring the distinction between data and schema. For instance, web-based data sources exhibit this characteristic, where the website’s schema and data cannot be readily distinguished.
Within this model, certain entities may lack attributes, while others may possess additional attributes. This flexibility extends to both storing data and defining attributes. For instance, attributes can accommodate either atomic values or collections of values.
The Associative Data Model divides data into two components. Entities, which have independent existence, and associations, which represent relationships between these entities. These components are referred to as items and links, respectively.
The Context Data Model comprises multiple models, such as the network model and relational models. By leveraging this model, we can undertake diverse tasks that are not achievable using any single model alone.
This encapsulates the different data models within DBMS.