Conceptual / Internal Mapping:

The conceptual/internal mapping defines the association between the abstract view and stored database. It specifies how conceptual records and fields are represented at the internal level. If stored data is changed with structural point of view, then the conceptual mapping must be changed accordingly so that the conceptual plan can remain steady.

External / Conceptual Mapping:

An external/conceptual mapping defines the correspondence between a particular external view and the conceptual view. In general, the differences that can exist between these two levels are similar to those that can exist between the conceptual view and the stored database. For example, fields can have different data types, fields and record names can be changed, several conceptual fields can be combined into .a single field. Any number of external views can exist at the same time. Any number of users can share a given external view and different external views can overlap each other.

Database can he viewed at three levels. The levels form three-level architecture and are depicted by three models. The models refer to the permanent structure of the database, not to the data that is stored at any given moment. A database model is a collection of tools. It may include a type of diagram and specialized vocabulary for describing the structure of the database.

The purpose of the three-level architecture is to separate the way the database is physically represented from the way the user thinks about it.

External Level:

The external level consists of different external views of the database. Each external view represents the view of a particular user about the system. Different users interact with the system in different ways. Each user is interested in only some of the attributes and relationships. A database stores many attributes and entities but different users may not be aware of all entities and attributes.

Different views may have different representations of the same data. For example, one user may think that dates are stored in the form (month/day/year), while another may think they are represented as (year/month/day). Some views might include virtual or calculated data. Virtual data is the data that is not actually stored in database but created when needed.

Logical or Conceptual Level:

The logical or conceptual level describes the data stored in the database and the relationships among the data. This is the middle-level view in the three-level architecture. This level contains the logical structure of the entire database as seen by the DBA. It is complete view of the data requirements of the origination that is independent of any storage configuration. The theoretical level represents:
• All attributes, entities, and their association
• Constraint on the data
• Semantic information regarding the record data
• Protection and integrity information

The conceptual leve1 supports each external view, it means that any data required by different users must he deliverable from the conceptual level However, this level must not contain any storage-dependent details.

Internal or Physical Level:

This level describes the physical representation of the database on the computer. It describes how the data is stored in database.

The internal level covers the physical implementation of the database to achieve optimal run-time performance and storage utilization. It covers the data structures and file organization used to store data on storage devices.

It works with the operating system access methods like file management techniques for storing and retrieving data records, to place the data on the storage devices, build the indexes, retrieve the data, and so on.

Three Level Architecture

The internal level is concerned with such things as:
• Storage space allocation for data and indexes
• Record description for storage (with stored size for data items)
• Record placement
• Data compression and data encryption techniques

Dr. E. F. Codd worked to improve the working of DBMSs for handling large volumes of data. He applied the rules of mathematics for solving the problems of earlier database models. Some important problems were:
• Data integrity
• Data redundancy

Dr. Codd presented a paper “A Relational Model of Data for Large Shared Databanks” in June I 970 that contained 12 rules. A DBMS that satisfies these rules is called a full Relational Database Management System (RDBMS). The term “Relation” is also derived from the “Set theory” of mathematics.

In a relational model, data is stored in relations. Relation is another term used for table. A table in a database has a unique name that identifies its contents. Each table can he called an intersection of rows and columns. An important property of table is that the rows are unordered. A row cannot be identified by its position in the table. Every table must have a column that uniquely identifies each row in the table.

Advantages of a Relational Database Model:

Some important advantages of a relational database model are as follows:

1. Data Integrity:

It allows data integrity from field level to table level to avoid duplication of records. It detects records with missing primary key values at the relationship level to ensure valid relationships between tables.

2. Data Independence:

The implementation of database will not be affected by changes made in the logical design of the database or changes made in the database software.

3. Data Consistency &. Accuracy:

Since multiple level check and constraints are built-in, data is accurate and consistent.

4. Easy Data Retrieval & Sharing:

Data can be easily extracted from one or more than one tables. Data can also be easily shared among users.

The Network Model

1. Characteristics of Network Model:

The characteristics of a network DBMS are:

2. Data record types are represented as a network:

In this model, data record types are represented as a network.

3. Each sub-module can have one or more super-modules:

Since multiple parent-child relationships are supported, child (sub-module) record type could have more than one parent (super) record types.

4. Represents a set of related records:

The sets that support multiple parent-child relationships and the structure of the records have to be specified in advance.

5. Complex Structure:

Since multiple parent-child relationships are supported, database structure
becomes very complicated.

6. Relationships are Pre-defined:

The network database implements sets that support multiple parent-child relationships. The sets have to be specified in advance. In the tradeoff between flexibility and performance, a network model is not very flexible to reorganize hut has high performance Levels.

7. Difficult to reorganize:

The network database is very difficult to be reorganized because inserting or deleting a record would involve tracing the pointers and changing the appropriate links.

8. Navigation done by the programmer:

The programmer will have to write 3GL programs for specifying the relationship and direction to navigate into the database. To access records, the programmer has to navigate the database record-by-record.

9. 3GL Inadequate for Handling Sets:

The records in a network model are processed one set at a time. 3GLs handle only one record at a time and hence are inadequate for handling the sets.

10. Query Facility not Available:

Network database management systems do not have any query facility. So 3GL programs will have to he written specifying the path and the relationship.

Consider the application used for Production Planning in automobile manufacturing companies. The model of the database is shown in the following figure. The automobile manufacturer manufactures various models of cars. Each car model is decomposed into its assemblies (Engine, Body and Chassis). Each assembly is further decomposed into sub-assemblies (valves, spark plugs…), and so on. If the manufacturer wants to generate the Bill of Materials for a particular model of an automobile, the hierarchic data model would be suitable because the bill of materials for a product has a hierarchical structure. Each record represents a particular part and since the records have a parent-child relationship each part is linked to its subpart.

The Hierarchical Model

Characteristics of Hierarchical Model:

The characteristics of a hierarchical DBMS are as follows:

1. Representation of Data as Hierarchical Trees:

The hierarchical database is characterized by parent-child relationships between records. A record type R1 is said to be the parent of record type R2 if R1 is one level higher than R2 in the hierarchical tree. The root of the hierarchy is the most important record type and all records at different levels of the hierarchy are dependent on the root.

2. Each Sub-Module has only one Super-Module:

Each child record (sub-module) has only one parent record (super-module). The parent record can have one or more children record types.

3. Represents a set of Related Records:

There can be one or more than one record occurrence for a given record type. When one writes into the database, only one occurrence of the record type is written. Similarly, whenever a record is retrieved from the database only one occurrence of the record type is retrieved.

4. Hierarchy through Pointers:

In a hierarchical database, pointers link the records. Pointers determine whether a particular record occurrence is a parent or a child record. The path from the parent to the child is maintained through pointers.

5. Simple Structure:

The database is a simple hierarchical tree. The parent and child records are stored close to each other on the disk, minimizing disk input and output.

6. High Performance:

The parent-child relationship is stored as pointers from one record to another. So navigation through the database is very fast resulting in high performance.

7. Pre-defined Relationship between Record Types:

Record types at different levels of the hierarchy are dependent on the root. Root is the most important record type in the hierarchy.

8. Difficult to Reorganize:

It is difficult to reorganize the database because the hierarchy has to be maintained. Each time a record type is inserted or deleted the pointers have to be manipulated to maintain the parent-child relationship.

9. More Complex Real life Requirements:

The hierarchical DBMS is based on a simple parent-child relationship, but real life applications are more complex and cannot be represented by a hierarchical structure. For example, in an order-processing database, a single order might participate in three different parent-child relationships linking the order to the customer who placed the order, the items ordered and the sales person who took the order. This complex structure cannot be represented in a hierarchical structure.

Analyze User Environment:

The first step in designing a database is to understand and analyze the current user environment. The designer should closely study the current system and its outputs. He should also interview different users to know their current and future requirements.

Develop Logical Data Model:

After analyzing the user environment, the designer develops a logical data model for the organization. This data model consists of all entities, attributes and relationships. The designer also determines the following things:
• Types of applications and transactions
• Types of databases access
• Volume of transactions
• Volume of data
• Frequency of databases access
• Budgetary restrictions
• Performance requirements

Choose a DBMS:

The designer chooses a particular database management system on the basis of logical data model. The selected DBMS should satisfy all requirements and constrains identified in the logical data model.

Map Logical Model to DBMS:

The designer maps the logical data model to available data structure of the selected database management system.

Develop Physical Model:

The designer creates the exact layout of data according the facilities of selected DBMS and available resource of software and hardware.

Evaluate Physical Model:

The designer evaluates the physical model by checking the performance of applications and transactions. The designer may implement a particular portion of the database to validate the user views and to validate the performance effectively.

Perform Tuning:

Tuning is performed to improve the performance of database. Different modifications are made to the physical model if required.

Implement Physical Model:

If evaluation is satisfying then the designer implements the physical model and the database becomes functional.

Staged Database Design

The above figure shows that different steps can be repeated at different stages of the development process. For example, the database designer can review the user environment during the development logical model. While mapping the logical model to physical model, he can change his selection of DBMS. Similarly, if an error occurs and he has to tune the system, he may need to change the DBMS or remap the logical model. Even at the last step, he may review all steps from the very beginning.

System development life cycle (SDLC) is a conventional way for developing an. information system. It consists of many steps and involves different persons. Different step of SDLC are as follows:

Phases of System Development Life Cycle

Preliminary Investigation:

Preliminary investigation is the first phase of System Development Life Cycle. The main objective of this phase is to identify deficiencies and requirements in the user’s current environment. An important result of the preliminary investigation is whether the system to be developed is feasible or not.
Feasibility is determined on the following parameters:
• Whether current technical resources or technology is available in the developer’s organization or in the market which is capable of handling the user’s requirements.
• Whether economically or financially the system is cost effective
• How effectively the user wil1 operate this software, once installed.

Feasibility Study Report is produced at the end of this phase. A final acceptance of the proposed system is taken from the user. Once the proposed system is accepted, the next phase is started.

Requirement Analysis:

In this phase, the current business system is studied in detail to find out how it works and where the improvements are required. It also includes the detailed study of the various operations performed by the system and their relationship within and outside the system. The analyst and the user work closely during the complete analysis phase. A detailed document is prepared at the end of this phase called the requirement specifications.

System Design:

The requirement analysis phase provides the requirements of the system. The next phase is to design the new system to satisfy these requirements. The design phase states how a system will meet the requirements identified during the systems analysis phase as mentioned in the Requirements Specifications.
Few of the activities carried out during the design phase are:
• Identification of data entry forms along with the data elements
• Identification of reports and outputs of the new system
• Design the form or display as expected in the system. This may be done on paper or on a computer display, using any design tools.
• Identification of data elements and tables for database creation
• Procedures for deriving the output from given input.

The document produced at the end of this activity is called the Design Specification. The detailed design specification is given to the programmers to start software development.

Software Development:

In this phase, the actual coding of the programs is done. Programs are tested using dummy data. Programmers also prepare the documentation related to the programs explaining how and why a certain procedure was coded in a specific way.

System Testing:

After the programs are tested individually, the system as a whole is tested. During system testing phase, all software modules are integrated and tested to ensure that they are running according to the specifications in Requirement Specification. Special test data is prepared as input for processing. The results are examined to ensure that they are correct.

System Implementation:

In this phase, the developed system is installed for use. Before the actual usage of the system, the following activities are performed.
• User personnel are trained to operate the system.
• The data files needed by the system are constructed.

System Maintenance:

The system may become less useful if any change occurs in the user environment. The software may be modified for its effective use; the activity of system maintenance may vary depending on the scale of modifications and enhancements.

The development of a complete database application is a lengthy and complicated process. Different strategies can be used to develop database applications. Following is a brief discussion about different strategies and steps performed during this process:

General Strategies:

A database application is developed to satisfy the requirements of the user. It is very important to understand these requirements in detail. The application should be developed according to the expectation of the user. Different techniques are used to find the requirements and needs of the users such as interviews. These requirements should he defined as early as possible in the development process.
There are two strategies for developing a database application:
1. Top-Down Development
2. Button-up Development

Top-Down Development:

This strategy starts with general issues and moves to specific issues. First of all, we find out the general goals of the organization and the means by which these goals can be achieved. We also define the requirements that must be satisfied to reach these goals. This study gives an abstract data model of the system.

Using this model, we move to detailed and specific issues. This process identifies a particular databases and related application to be developed. Finally, the high-level data mcde1 is transformed into low-level models and all identified systems, databases and applications are developed.

Bottom-Up Development:

This strategy starts with specific issues and moves to general issues. We begin identifying a specific system to be developed. After this, we find out the requirements by studying the existing system and by interviewing different users.

(1) Application Programmers:

Application programmer is the person who is responsible for implementing the required functionality of database for the end user. Application programmer works according to the specification provided by the system analyst.

(2) End Users:

End users are those persons who interact with the application directly. They are responsible to insert, delete and update data in the database. They get information from the system as and when required. Different types of end users are as follows:

Naive Users: Naive users are those users who do not have any technical knowledge about the DBMS. They use the database through application programs by using simple user interface. They perform all operations by using simple commands provided in the user interface.

Example: The data entry operator in an office is responsible for entering records in the database. He performs this task by using menus and buttons etc. He does not know anything about database or DBMS. He interacts with the database through the application program.

Sophisticated Users: Sophisticated users are the users who are familiar with the structure of database and facilities of DBMS. Such users can use a query language such as SQL to perform the required operations on databases. Some sophisticated users can also write application programs.

(3) Database Administrator:

Database administrator is responsible for, managing the whole database system. He designs creates and maintains the database. He manages the users who can access this database, and controls integrity issues. He also monitors the performance of the system and makes changes in the system as and when required.

(1) Personal Computer Database:

Personal computer databases are specially designed for single user. The user may be using stand-alone desktop computer or laptop. The representatives of a medical company may use laptop computers when working in the market. This computer may use a simple database application in which the records of customers are stored. Some important decisions about the development of personal computer database applications are as follows:
• It should he purchased or developed within the organization?
• It should be developed by end user or a professional in information system?
• Required data and the design of database
• Selection of DBMS for database application
• Synchronization of personal computer database with other databases
• Accuracy of data in personal computer database
Personal computer databases are widely used. A problem with this database application is that it is difficult to share quickly. For example, if the head of medical company wants to get complete information of his customers, it cannot be done quickly as it is stored on the laptop computers of different representatives.

(2) Workgroup Database:

A workgroup is a team of people who work on the same project collectively. A workgroup normally consists of less than 25 people. A type of database that is specially designed to support workgroups is known as workgroup database.

The people in the workgroup are connected with one another through local area network (LAN). The database is stored on a central computer called server. All members of the workgroup can share this database.
Workgroup databases provide many facilities but arise some problems also. The main problems are of security and integrity of data when the data is updated concurrently. Some important decisions about workgroups databases are as follows:
• Database optimization to satisfy the requirements of different members of workgroup
• Concurrency control -
• Decision about where different operation should take place i.e. on server computer or workstation computer.

(3) Department Database:

A functional unit in an organization is known as department. For example an organization may have marketing, production and accounting departments. A department normally consists of 25 to 100 people. Department databases are specially designed to support the functions of a department.
Some important decisions about department databases are as follows:
• Database design for efficient performance to handle a large number of users and transactions
• Proper security to protect data against unauthorized access
• Database tools for complex environment
• Ensuring data redundancy and consistency if same data is used in different departments
• The need for distributed database if users are geographically away from one another.

(4) Enterprise Database:

A type of database that is specially designed to support the functions of whole organization or mans’ departments of an organization is known as enterprise database. The most important enterprise database is known as data warehouse. The contents of a data warehouse are derived from many operational database like personal computer, workgroup and department databases.

Suppose a university has many departments like Computer Science, Biology, Agriculture, Chemistry etc. Each department is using a department database to maintain the functions of in the department. The Vice Chancellor, however, needs to get the information of different departments frequently. In order to satisfy this requirement, a data warehouse can be developed for the whole university in VC office. The data warehouse will extract the databases of different departments periodically.

Some important decisions about department databases are as follows:
• Distribution of data among various locations in the corporate structure
• Maintenance of standards for data names, definitions, and formats