Data Models and Database Environment

Databases and database systems are an essential component of everyday life in this modern society. In a daily life of an organization, most encounter several activities that involve some interaction with a database. Databases play a critical role in almost all areas where computers are used, including business, electronic commerce, engineering, medicine, law, education, and library sciences.

Business rules are commonly used in creating a DBMS for it is where the daily activities of each organization are identified. One of the most disturbing problems of database design is designers, programmers, and end-users see data in different ways. These different views of the same data can lead to a database design that does not reflect the organizations actual operation, failing to meet the user’s needs and data efficiency requirements.


The Importance of Data Models

Data models are illustrations, usually graphical, or more complex real-world data arrangements. A model’s real function is to help understand the complexities of the real-world environment. In the database environment, a data model represents data structures and their characteristics, relations, constraints, and transformations.

The terms data model and database models are used interchangeably. The term database model is used to refer to the implementation of a data model in a specific database system. Data models can enable interaction among the designer, the applications programmer, and the end-user. A powerful data model can foster better-quality understanding of the organization for which the database design is developed. This significant part of data modeling was summed up neatly by a client who wanted to have a database.

A good database model depends on the data model created. Data model can be effective through the different business rules cited by the client itself.

video courtesy of youtube


Data Model Basic Building Blocks

The basic building blocks of all data are the:


An entity is anything about which data are to be collected and stored. It can be a person, a place, a thing, or an event. An entity may be physical objects, such as employees, students, customers and/or products.


An attribute is the characteristic of entity. For example, an entity EMPLOYEE can be described by the attributes last name, first name, position, and salary. The attributes are the equivalent of the fields found in the file system.


A relationship describes the association among entities. For example, a relationship exists between teachers and students, client and agent, customers and products. There are three types of relationship that data model uses: one-to-many, many-to-many, and one-to-one.

  • One-to-Many (1:M, 1:*) For example, an artist can create many different masterpieces, but each one of them are created by only one artist.
  • Many-to-Many (M:N, M:M, *:*) For example, a student can take many classes and on the other hand each class can be taken my many students.
  • One-to-One (1:1) For example, a one big company with many branches may require that each branch should be managed by a single employee or manager.



A constraint is a restriction placed on the data. They are important for they help to ensure data integrity. They are normally expressed in rules such as:

  • The students’ grade should accept numbers from 00 to 5.00
  • The employee last name must contain a maximum of 10 letters only
  • The staff’s salary must have a value starting from 6,000 to 15,000



Business Rules

A business rule is a brief, accurate, and definite description of policy, procedure, or principle.  It is derived from a detailed description of a company/organization’s operations, which is a great help to create and enforce actions within the company/organization’s environment. Properly written business rules are used to define entities, attributes, relationships, and constraints. In order for a business rule to be effective, it should be easily understood and widely disseminated to ensure that the every person in an organization shares a common interpretation of the rules.

The main sources of business rules are the employees of a certain organization itself like managers, policy makers, and other organization’s employees who are involve in the decision-making of an organization. The business rules are written for documentation such as procedures, standards, or operations manuals. The most direct source of business rule are the end-users. Business rule can be taken from them through direct interview with them.

Identifying and documenting business rules are important when designing a database design for these reasons:

  • Normalize the organization’s view of data
  • Communication tools between users and designers
  • Allow the designer to understand the nature, part, and scope of the
  • Allow the designer to understand business processes
  • Allow the designer to develop proper relationship participation rules and constraints and to create an accurate data model

However, not all business rules can be modeled but business rules can be enforced by application software.

video courtesy of youtube


The Evolution of Data Models

  1. The Hierarchical Model

The hierarchical model is a restricted type of network model. Data is represented as collections of records and relationships are represented by sets. The hierarchical model allows a node to have only on one parent. It can be represented as a tree graph, with records appearing as nodes, also called segments, and sets as edges.




2. The Network Model

Data is represented as collections of records, and relationships are represented by sets. Relationships are explicitly modeled by sets, which become pointers in the implementation. The records are organized as generalized graph structures with records appearing as nodes and sets as edges in the graph.



3. The Relational Model

The relational model was introduced by E.F. Codd (of IBM) in 1970 in his landmark paper “A Relational Model of Data for Large Shared Databases”. The relational data model is being implemented through a sophisticated relational database management system (RDBMS).The RDBMS manages all the physical details, while the user sees the relational database as a collection of tables in which data are stored and can be manipulated through the use of query languages.

Data and relationships are represented as tables, each of which has a number of columns with a unique name. Each table is a matrix consisting of series of rows and columns intersection. Tables in a relational database are also called relations, for tables are related other through the sharing of a common entity characteristic, they are values in a column).


4. The Entity Relationship Model

The entity-relationship model is a graphical representation entities and relationships. Through these graphical representation the entity relationship (ER) model, or ERM, has become a widely accepted standard for data modeling. It has emerged as one of the main techniques for database design and forms the basis for the database design methodology.

The ER was first introduced in 1976 by Peter Chen which became popular because it complemented the relational model concepts. The relational data model and the ERM were combined to provide the foundation for a tightly structured database design. The ER is normally represented in an Entity Relationship Diagram (ERD).



5. The Object-Oriented (OO) Model

In the object-oriented data model (OODM), both the data and their relationships are contained in a single structure known as object. It extends the definition of an entity to include not only the attributes that describe the state of the object but also the actions that are associated with the object, that is, its behavior. The object is said to encapsulate both state and behavior.

Levels of Architecture

  • The External or View Level

The external model is also known as the User Logical Level. It has an external schema or user schema which describes the part of the database that a particular user group is interested in and hides the rest of the database from that user group. It is the user’s view of the database; describe the part of the database that is relevant to each other.


  • The Conceptual Level

The conceptual model is also known as the Community Logical Level or the Logical Level. It describes the structure of the whole database for a community of users.  This level describes what data is stored in the database and the relationships among the data. The conceptual level has a conceptual schema which hides the details of physical storage structures and concentrates on describing entities, data types, relationships, user operations, and constraints.

  • The Internal Level

It describes the physical storage structure of the database. It has an internal schema, which uses a physical data model and describes the complete details of data storage and access paths for the database. This level describes how the data is stored in the database.


Schemas, Instances, and Database State

     The description of a database is called the database schema, which is specified during database design and is not expected to change frequently. Most data models have certain conventions for displaying schemas as diagrams, which is called schema diagram. Each object in the schema is called a schema construct.

The schema diagram displays only some aspects of a schema, such as the  names of record types and data items, and some types of constraints.



Data Independence

     It is defined as the capacity to change the schema at one level of database system without having to change the schema at the next higher level.


  1. Logical data independence is the capacity to change the conceptual schema without having to change the external schemas or application The conceptual schema maybe change to expand the database (adding a record type or data item), to change constraints, or to reduce the database (removing a record type or data item).
  2. Physical data independence is the capacity to change the internal schema without having to change the conceptual The external schemas need not to be changed as well. Changes in the internal schema may be needed because some physical files were recognized. For example – creating additional access structures – to improve the performance of retrieval or update. If the same data as before remains in the database, then the conceptual schema should not be change.



DBMS Languages


In many DBMS where no strict separation of levels is maintained, the DDL is used by the Database Administrator and by the database designer to define both schemas. It allows the DBA to describe and the name the entities, attributes, and relationships required for the application, together with any associated integrity and security constraints. The DDL is used to define a schema or to modify an existing one. It cannot be used to manipulate data. DDL is a collection of instructions and commands used to define and describe data and data relationships in a specific database. The language used to describe the contents of the database (e.g. attribute names, data types – “metadata”). Basic functions include;



The DML is a language that provides a set of operations to support the basic data manipulation operations on the data held in the database. Data manipulation operations usually include insertion of new data into the database, modification of data stored in the database, retrieval of data contained in the database and deletion of data from the database.

Once the database schemas are compiled and the database is populated with the data, users must have some means to manipulate the database. Usual manipulations include retrieval, insertion, deletion, and modification of the data.

The DML is also known as query language. It is a language for accessing and manipulating the data organized by the appropriate data model. DML is a language used to form commands for input, edit, analysis, output, reformatting and others. Some degree of standardization has been achieved with SQL (Standard Query Language). Basic functions include:



Roles in the Database Environment


The Data Administrator (DA) is responsible for the management of the data resource including database planning, development and maintenance of standards, policies, and procedures, and conceptual/logical database design.

The Database Administrator (DBA) is responsible for the physical realization of the database, including physical database design and implementation, security and integrity control, maintenance of the operational system and ensuring satisfactory performance of the applications for users.




  • Logical Database Designer is concerned with identifying the data (entities and attributes), the relationships between the data, and the constraints on the data that is to be stored in the The logical database designer must have a thorough and complete understanding of the organization’s data and its business rules.
  • Physical Database Designer decides how the logical database design is to be physically These involves:
    • Mapping the logical database design into a set of tables and integrity constraints;
    • Selecting specific storage structures and access methods for the data to achieve good performance;
    • Designing any security measures required on the



Once the database has been implemented, the application programs that provide required functionality for the end-users must be implemented. This is the responsibility of the application developers. The application developers work from a specification produced by systems analysts.




The end-users are the clients for the database, which has been designed and implemented. End-users maybe classified according to the way they used the system:

  • Naïve Users are typically unaware of the They access the database through specially written application programs which attempt to make the operations as simple as possible. They invoke database operations by entering simple commands or choosing options from a menu.
  • Sophisticated Users is familiar with the structure of the database and the facilities offered by the Some sophisticated end-users may even write application programs for their own use.