Notes and Study Materials

Hierarchical Data Model in DBMS

 

 

The hierarchical model was developed in the 1960s to manage large amounts of data for complex manufacturing projects such as the Apollo rocket that landed on the moon in 1969.

Its basic logical structure is represented by an upside-down tree.

The hierarchical structure contains levels, or segments. 


A segment is the equivalent of a file system’s record type.

Within the hierarchy, a higher layer is perceived as the parent of the segment directly beneath it, which is called the child.

The hierarchical model depicts a set of one-to-many (1:M) relationships between a parent and its children segments. (Each parent can have many children, but each child has only one parent.)

 

Hierarchical Data Model in DBMS

 

Add a comment

Network Data Model in DBMS

 

 

The network model was created to represent complex data relationships more effectively than the hierarchical model, to improve database performance, and to impose a database standard.

In the network model, the user perceives the network database as a collection of records in 1:M relationships. However, unlike the hierarchical model, the network model allows a record to have more than one parent.

While the network database model is generally not used today, the definitions of standard database concepts that emerged with the network model are still used by modern data models.

 

Network Data Model in DBMS

 

Network Data Model In DBMS

Add a comment

Relational Database Model in DBMS

 

 

The relational model was introduced in 1970 by E. F. Codd. The relational model foundation is a mathematical concept known as a relation.

The relational model is implemented through a very sophisticated relational database management system (RDBMS).

The RDBMS performs the same basic functions provided by the hierarchical and network DBMS systems, in addition to a host of other functions that make the relational data model easier to understand and implement.


Arguably the most important advantage of the RDBMS is its ability to hide the complexities of the relational model from the user. The RDBMS manages all of the physical details, while the user sees the relational database as a collection of tables in which data are stored. The user can manipulate and query the data in a way that seems intuitive and logical.

Relational Database Model in DBMS

 

Add a comment

Entity Relationship Model in DBMS 

 

 

The conceptual simplicity of relational database technology triggered the demand for RDBMSs.

In turn, the rapidly increasing requirements for transaction and information created the need for more complex database implementation structures, thus creating the need for more effective database design tools.

 

Although the relational model was a vast improvement over the hierarchical and network models, it still lacked the features that would make it an effective database design tool.

Because it is easier to examine structures graphically than to describe them in a text, database designers prefer to use a graphical tool in which entities and their relationships are pictured.

 

Entity Relationship Model in DBMS

 

Thus, the entity relationship model in DMBS, or ER Model in DBMs, has become a widely accepted standard for data modeling.

 

Add a comment

The Object Oriented (OO) Data Model in DBMS 

 

 

Increasingly complex real-world problems demonstrated a need for a data model that more closely represented the real world.

In the object oriented data model (OODM), both data and their relationships are contained in a single structure known as an object.

In turn, the OODM is the basis for the object-oriented database management system (OODBMS).

 

Object Oriented OO Data Model in DBMS

The Components of the Object Oriented Data Model 

Add a comment

Degrees of Data Abstraction in DBMS

 

 

The database designer starts with an abstract view of the overall data environment and adds details as the design comes closer to implementation.

Data abstraction in DBMS can also be very helpful in integrating multiple (and sometimes conflicting) views of data as seen at different levels of an organization.

The ANSI/SPARC architecture (as it is often referred to) defines three levels of data abstraction: External, Conceptual, and Internal. 

 

Degrees of Data Abstraction in dbms 3 Schema Architecture

Degrees of Data Abstraction in DBMS

The External Model:

The external model is the end users’ view of the data environment.

The term end users refers to people who use the application programs to manipulate the data and generate information. End users usually operate in an environment in which an application has a specific business unit focus. Companies are generally divided into several business units, such as sales, finance, and marketing.

Each business unit is subject to specific constraints and requirements, and each one uses a data subset of the overall data in the organization.

Therefore, end users working within those business units view their data subsets as separate from or external to other units within the organization.

 

• The use of external views representing subsets of the database has some important advantages:

• It makes it easy to identify specific data required to support each business unit’s operations.

• It makes the designer’s job easy by providing feedback about the model’s adequacy. Specifically, the model can be checked to ensure that it supports all processes as defined by their external models, as well as all operational requirements and constraints.

• It helps to ensure security constraints in the database design. Damaging an entire database is more difficult when each business unit works with only a subset of data.

• It makes application program development much simpler.

The Conceptual Model:

Having identified the external views, a conceptual model is used, graphically represented by an ERD to integrate all external views into a single view.

The conceptual model represents a global view of the entire database as viewed by the entire organization. That is, the conceptual model integrates all external views (entities, relationships, constraints, and processes) into a single global view of the data in the enterprise.

The conceptual model yields some very important advantages.

• First, it provides a relatively easily understood bird’s-eye (macro level) view of the data environment.

• Second, the conceptual model is independent of both software and hardware. Software independence means that the model does not depend on the DBMS software used to implement the model.

• Hardware independence means that the model does not depend on the hardware used in the implementation of the model. Therefore, changes in either the hardware or the DBMS software will have no effect on the database design at the conceptual level. Generally, the term logical design is used to refer to the task of creating a conceptual data model that could be implemented in any DBMS.

The Internal Model:

Once a specific DBMS has been selected, the internal model maps the conceptual model to the DBMS. The internal model is the representation of the database as “seen” by the DBMS.

In other words, the internal model requires the designer to match the conceptual model’s characteristics and constraints to those of the selected implementation model.

An internal schema depicts a specific representation of an internal model, using the database constructs supported by the chosen database.

Because the internal model depends on specific database software, it is said to be software-dependent. Therefore, a change in the DBMS software requires that the internal model be changed to fit the characteristics and requirements of the implementation database model.

The Physical Model:

The physical model operates at the lowest level of abstraction, describing the way data are saved on storage media such as disks or tapes.

The storage structures used are dependent on the software (the DBMS and the operating system) and on the type of storage devices that the computer can handle.

The precision required in the physical model’s definition demands that database designers who work at this level have a detailed knowledge of the hardware and software used to implement the database design.

As noted earlier, the physical model is dependent on the DBMS, methods of accessing files, and types of hardware storage devices supported by the operating system.

 

 

When you can change the physical model without affecting the internal model, you have physical independence. Therefore, a change in storage devices or methods and even a change in operating system will not affect the internal model.

 

Degrees of Data Abstraction

 

You may also like:

Importance of the Data Models
Hierarchical Data Model
Network Data Model
Relational Database Model
Object Oriented Model
Other DBMS Questions

 

 

Add a comment

Table and its Characteristics:

 

 

A table is perceived as a two-dimensional structure composed of rows and columns. A table is also called a relation because the relational model’s creator, E. F. Codd, used the term relation as a synonym for a table. A Table is Primary Component in Relational Data Model.

The characteristics of a relational table are summarized as follows:

Add a comment

Types of Keys in DBMS

 

 

In the Relational Database Model, keys are important because they are used to ensure that each row in a table is uniquely identifiable. They are also used to establish relationships among tables and to ensure the integrity of the data.

 

Functional dependence:

The attribute B is functionally dependent on the attribute A if each value in column A determines one and only one value in column B.

Composite key:


Add a comment