Professional Documents
Culture Documents
ORGANIZATIONAL STRUCTURE
INTRODUCTION
A collection of related data is usually called database. In order to assist in the
maintenance and utilization of databases on large scale, we then use DBMS for these
purposes. DBMS stands for Database Management System. A Database scientist named
as Charles, in the late 1960s introduced the DBMS. In 1960 IBM bought IMS - Information
Management System for the purpose of large scale databases. Edgar Codd in 1970 at
IBM introduced new database named as RDBM i.e. Relational Database Management
System. After the advent of these databases, SQL came into being in 1980. In early 1990
we then saw the new and advanced databases coming to fulfill the needs of the
technological industry, which includes DB2 and Oracle.
DATA
An entity or raw facts or figures are known as data. There is a need to record day to day
operational activities in the organization for the effective decision making, for this
purpose we have to store the data of those activities somewhere in the system, and that
record is known as Data.
TASK OF DATA MANAGEMENT
Data Capture: A data have to be associated with some task relevant to the activity.
Data Classification: Data have to be classified according to the nature when
recorded.
Data Storage: Data should have to be stored properly.
Data Arranging: It is important to arrange data in proper order/format.
Data Retrieval: There is a frequent need of data for the certain processes, for this
purpose it is important to create some indexes which are easy for the retrieval of
data.
Data Maintenance: Up to Date data is a back bone for the decision making process
in the organization, for this purpose data should be up to date and maintained
properly.
Data Editing: Editing means to re-arrange the data for the beneficial use of it.
DBMS
A Database Management System is a collection of program/software that enables user to
create and maintain data effectively and efficiently. DBMS is a general purpose software
program that facilitates the process of defining, creating, and manipulating database for
specific applications or programs.
CHARACTERISTICS OF DBMS
Information system should be designed in such an interactive way to fetch data for
the specific. purpose without writing a new piece of code.
Data should be co-related to other data to meet rapid changing environment.
Integration between different data scattered in different programs should be easy.
Concurrent access should be available.
Automatic recovery feature has to be provided to overcome the problem in the
case of system failures.
DBMS UTILITIES
Data Loading Utility: It allows data to load from one format to standard format without
writing any code.
Backup Utility: It allows data to back up periodically to secure data in the case of crashes
and system failure.
Recovery Utility: It is one of the important utility, which allows reconstructing the correct
state of database from backup.
Monitoring Tools: It allows to optimized database access and monitor performance so
that internal schema can be changed.
File Organization: It allows data to reconstruct from one type to another.
FILE SYSTEM VS DBMS
File system is a collection of data. To manage the file, user has to write the
procedures, whereas in DBMS user is not required to write the procedure.
File system show the details of the data presentation and data storage, whereas
DBMS provides abstract view.
File system did not provide efficient storing and retrieving of data. DBMS is efficient
in providing operations of storage and retrieving the data, it has wide varieties of
techniques to do the tasks.
Concurrent access creates problem in file, where DBMS provide effective
concurrent access to the user at the same time.
There is no crash recovery mechanism in file system, where DBMS has a great tool
to recover data from catastrophes.
Under file system it is difficult to protect a file. Whereas DBMS has a good
mechanism for protection.
ADVANTAGES OF DBMS
Data Independency: There should no exposition to a program details, DBMS only provide
abstract view of data and hide all details which are not specific for the user.
Efficient Data Access: There are a variety of sophisticated techniques available in DBMS
to store and retrieve data efficiently.
Data Integrity & Security: DBMS enforces data integrity for the purpose of unauthorized
access to data.
Data Administration: Data redundancy can be minimized to centralize the data, which
reduces the retrieval time.
Concurrent Access: DBMS can provide multiple users at a time to perform certain task on
a single table or multiple tables, without losing any information.
Crash Recovery: DBMS protects user from system failure to save important data and
time.
FUNCTIONS OF DBMS
Data Definition: For the purpose of defining the structure of data, DBMS provides
function for this. It includes modifying and defining the structure, the type and size of the
fields and the various constraints.
Data Manipulation: Whenever we define the structure of the data, we then need to
insert, modify or delete the data. These important functions are part of the DBMS.
Data Security & Integrity: There are certain modules in DBMS which handles data
security and integrity with efficient manners.
Data Recovery & Concurrency: There is always a chance of failure due to some reasons,
for this reason DBMS provide function which recover data on the time of crash or some
failure. DBMS also handles concurrent access at a time.
Performance: To optimize the queries in the database is one the important function of
DBMS.
ROLE OF DATABASE ADMINISTRATOR
DBMS has typically 3 main users:
1. End User It is the one who uses the database and actually input data in the
system for the purpose of business activities. The end user does not need to know
anything about the organization of the database in the physical level.
2. Programmer/Developer This person has the knowledge about the data and its
structure and can manipulate the data using certain program or piece of code.
3. Database Administrator DBS This person is considered as the super user of
the system. DBA can perform many functions in the organization as follows:
Defining the Schema: DBA defines the structure of the database in the
application. DBA has to determine what data needs to be presented in the
system and how this data should be organized.
Liaising with Users: DBA should have to interact with the end user
continuously to cope with rapidly changing requirements.
Defining security & Integrity Check: DBA defines security checks and put
integrity checks accordingly.
Defining Backup/Recovery Procedures: DBA defines backup and recovery
procedures to maintain the database for the organization. Defining backup
specifies what data needs to be backed up and when it needs to be backed
up.
Monitoring Performance: DBA should have to monitor the performance of the
queries frequently and take such measures which optimized all the queries in
the application.
ARCHITECTURE OF A DBMS
A commonly used view of data approach is the three level architecture suggested by
ANSI/SPAC (American National Standards Institute/Standards Planning and Requirements
Committee). ANSI/SPAC produced an interim report in 1972 followed by a final report in
1977. The report proposed an architectural framework for databases. Under this
approach, a database is considered containing data about an enterprise. The three levels
of architecture have three different views of data:
of the database. It is overall a community view of the database and it includes all the
information of data that is going to be represented in the database. This view can also be
defined by the conceptual schema which includes definitions of each o the various types
of data.
INTERNAL VIEW
It is the view about the actual physical storage of data. It tells us how and what data is
stored in the database. Efficiency consideration is the most important at this level, and
the data structures are chosen to provide an efficient database.
The separation of the conceptual view from the internal view enables us to provide a
logical description of the database without the need to specify physical structures. This is
often called physical data independence. Separating the external views from the
conceptual view enables us to change the conceptual view without affecting the external
views. This separation is sometimes called logical data independence.
DATA INDEPENDENCE
It is the capacity to change the schema at one level without changing the schema at
another level. Two types are:
1- Logical Data Independence: it is the capacity to change the schema without
changing the external schema.
2- Physical Data Independence: it is the capacity to change the internal schema
without changing the conceptual schema.
Types of Databases and Database Applications
Traditional Applications:
Numeric and Textual Databases
More Recent Applications:
Multimedia Databases
Geographic Information Systems (GIS)
Data Warehouses
Real-time and Active Databases
Many other applications
DATA MODEL
Model is an abstraction, which hides superfluous details from the user. Whereas data
modeling is use to represent entities of interest and their relationship in the database.
Data model is a collection of concept that can be used to describe the structure of a
database which provides the necessary means to achieve the abstraction. It consists of:
Data types
Relationships
Constraints
TYPES
1.
2.
3.
4.
5.
ADVANTAGES
o it represent data in simplified form
o manipulation of record is simplified with key attributes to retrieve data
o different type of relationship with other tables is easy
NETWORK MODEL
In this type of model, data is represented by links which can be considered as pointers.
ADVTANGES
o representations of relationships between entities is implemented using pointers
which allows the arbitrary relationship
o it is easy as compared to hierarchical
o data manipulation is also easy
HIERCHICAL MODEL
A hierarchical data model is a data model which the data is organized into a tree like
structure. The structure allows repeating information using parent/child relationships:
each parent can have many children but each child only has one parent. All attributes of
a specific record are listed under an entity type.
ADVANTAGES
o
o
o
o
DBMS Languages
Used by the DBA and database designers to specify the conceptual schema of a
database.
In many DBMSs, the DDL is also used to define internal and external schemas
(views)
In some DBMSs, separate storage definition language (SDL) and view definition
language (VDL) are used to define internal and external schemas.
SDL is typically realized via DBMS commands provided to the DBA and database
designers
DBMS Interfaces
Stand-alone query language interfaces
Example: Entering SQL queries at the DBMS interactive SQL interface (e.g.
SQL*Plus in ORACLE)
Programmer interfaces for embedding DML in programming languages
User-friendly interfaces
Menu-based, forms-based, graphics-based, etc.
DBMS Programming Language Interfaces
Programmer interfaces for embedding DML in a programming languages:
Embedded Approach: e.g embedded SQL (for C,C++, etc.), SQLJ (for Java)
Procedure Call Approach: e.g. JDBC for Java, ODBC for other programming
languages
Database Programming Language Approach: e.g. ORACLE has PL/SQL, a
programming language based on SQL; language incorporates SQL and its data
types as integral components.
CENTRALIZED DBMS
CLIENTS
Appropriate interfaces provided through a client software module which access and
utilize the server with various resources.
Clients server maybe machines which are diskless or other PCs or workstations
with disks with only client software installed.
Network maybe connected to the server.
(LAN: local area network, wireless network, etc.)
DBMS SERVER
Function is to provide database query and services of transaction to the clients.
Relational DBMS servers are often called SQL servers, query servers, or transaction
servers
Applications running on clients utilize an Application Program Interface (API) to
access server databases via standard interface such as:
o ODBC: Open Database Connectivity standard
o JDBC: for Java programming access
For ODBC or JDBC, there must be an installation of appropriate client and server
module on both clients and server side.
TWO TIER CLIENT-SERVER ARCHITECTURE
A client program may connect to several DBMSs, sometimes called the data
sources.
In general, data sources can be files or other non-DBMS software that manages
data. Other variations of clients are possible: e.g., in some object DBMSs, more
functionality is transferred to clients including data dictionary functions,
optimization and recovery across multiple servers, etc. (Unit DB1)
THREE TIER CLIENT-SERVER ARCHITECTURE
Very common for applications which are web based.
Intermediate Layer called Application Server or Web Server:
It stores those data which are related to business logic and web connectivity of the
software which later used to access corresponding data from database server.
Acts like a conduit for sending partially processed data between the database
server and the client.
Three-tier Architecture Can Enhance Security:
Database server only accessible via middle tier
Clients cannot directly access database server
Classification of DBMSs
One-to-one Relationships
One-to-many Relationships
Many-to-many Relationships
For example, suppose that you have a table called employees that contains each
persons Social Security number, name, and the department in which he or she works.
Suppose that you also have a separate table called departments, containing the list of all
available departments, made up of a Department ID and a name. In the employees
table, the Department ID field matches an ID found in the departments table. (Unit
DB2)
One-to-One Relationships
In a one-to-one relationship, a key appears only once in a related table. The employees
and departments tables do not have a one-to-one relationship because many employees
undoubtedly belong to the same department. A one-to-one relationship exists, for
example, if each employee is assigned one computer within a company. (Unit DB2)
One-to-Many Relationships
In a one-to-many relationship, keys from one table appear multiple times in a related
table. (Unit DB2)
Many-to-Many Relationships
The many-to-many relationship often causes problems in practical examples of
normalized databases, so much so that it is common to simply break many-to-many
relationships into a series of one-to-many relationships. In a many-to-many relationship,
the key value of one table can appear many times in a related table. So far, it sounds like
a one-to-many relationship, but heres the curveball: The opposite is also true, meaning
that the primary key from that second table can also appear many times in the first
table. (Unit DB2)
NORMALIZATION
To make life easier, normalization is a set of rules for database administrators. It is the
way to organize your database in such an efficient way then for future growth you can
use the table where appropriately required.
The sets of rules used in normalization are called normal forms. If your database design
follows the first set of rules, its considered in the first normal form. If the first three sets
of rules of normalization are followed, your database is said to be in the third normal
form. (Unit DB2)
FIRST NORMAL FORM
The rules are as follows:
If you need to look at your tables and see whether you have more fields that can be
broken down further and that arent dependent on a key. (Unit DB2)
DESIGN PROCESS
Important and crucial part of any application is to give it forethought before
implementing it. Same is the case with database application in which design process
must include a thorough evaluation of your database. What data should hold and where
it relates, most importantly it is scalable or not.
One should follow these steps:
Define objectives
Design the structure (tables, fields)
Discern relationships
Define business rules
Create application
E-R MODEL
In ER model we used to represent real world situation using concepts which are used by
people. In this model we define a real world object representation at logical level. ER
model has no facilities to describe machine-related aspects. In this model we capture the
logical structure of database by indicating the grouping of data into entities. The ER
model also supports a top-down approach by which details can be given in successive
stages. (Unit DB3)
Entity: An entity is something which is described in the database by storing its data; it
may be a concrete entity or a conceptual entity.
Entity set: An entity set is a collection of similar entities.
Attribute: An attribute describes a property associated with entities. Attribute will have
a name and a value for each entity.
Domain: A domain defines a set of permitted values for an attribute.
DATA INTEGRITY
There are certain rules on which data is accepted and becomes valid. Data integrity is
one such enforcement rule that ensures the data is valid and correct. Keys play an
important role in maintaining data integrity. The various types of keys that have been
identified are:
Candidate key
Primary key
Alternate key
Composite key
Foreign Key
Candidate key
An attribute or set of attributes that uniquely identifies a row is called a Candidate key.
This attribute has values that are unique
Vehicle (Unit DB3)
Primary Key
The Candidate key that you choose to identify each row uniquely is called the Primary
key.
Alternate Key
A Candidate key that is not chosen as a Primary key is an Alternate key.
Composite Key
In certain tables, a single attribute cannot be used to identify rows uniquely and a
combination of two or more attributes is used as a Primary key. Such keys are called
Composite keys.
Foreign Key
When a primary key of one table appears as an attribute in another table, it is called the
Foreign key in the second table A foreign key is used to relate two tables.
Weak entity:
A weak entity does not have a distinguishing attribute of its own and mostly are
dependent entities, which are part of some another entity. A weak entity will always be
related to one or more strong entities. They can be also understood as multi-valued
attributes.
Entity types
Relationship types
Attributes and its domain
Primary and alternate keys
Integrity constraints
Depending on the size of the database application to be build, we may produce one local
conceptual data model for each user view. We assume that we only need to build one
conceptual data model. The following are the steps that we need to perform to build the
conceptual data model. (Unit DB4)
STEP 1.1: Identify Entity Types
Identify main objects, which are required for the model, is the first step to be performed.
This can be obtained from user requirements specification.
We have identified seven entity types for our model: Customer, Employee, Product,
Order, Invoice, Delivery, and Supplier.
Step 1.2: Identify Relationship Types
Next, we need to determine the important relationships that exist between the entity
types that have been identified. Relationships are identified by examining the
transactions that are needed by the users in the requirements specification. The
relationships are typically described using a verb. Use of ER diagram helps to visualize
the relationship and the model more effectively. We need also to include the cardinality
and the participation constraints of relationship types in the diagram. The descriptions of
this information need to be documented for the refinement and validation purposes.
Between
Between
Between
Between
Between
Between
Step 1.3: Identify and Associate Attributes with Entity or Relationship Types
After identifying the entity and relationship types, the next step is to identify their
attributes. It is important to determine the type of these attributes. Attributes can be
categorized as simple or composite, single or multi-valued, and derived attributes. Again,
we need to document the details of each identified attribute.
For our model, the list of attributes for the defined entities is as follows:
Customer CustNo, Name, CustAddress,TelNo, Balance
Employee EmpNo, Name, TelNo, Position, Gender, DOB, Salary
Order OrderNo, OrderDate, OrderAddress
Invoice InvoiceNo, Date, DatePaid, OrderNo;
Product ProductNo,Name,UnitPrice, QtyOnHand, ReorderLevel, SuppNo
Delivery DeliveryNo, DeliveryDate, OrderNo, ProductNo;
Supplier SuppNo, Name, SuppAddress, TelNo, ContactPerson
Check for the presence of any redundancy in the model as an important step to perform.
The common checking for the redundancy is to re-evaluate the 1:1 relationship. If the
entities in the relationship are similar, then we need to merge them together as one
entity, and may need to redefine the primary key. This type of problem typically exists
when we have more than one user view.
Step 1.7: Validate Conceptual Model against User Transactions
We have to ensure that the conceptual model supports the transactions required by the
user view.
Step 1.8: Review Conceptual Data Model with User
User involvement during the review of the model is important to ensure that the model is
a true representation of the users view of the enterprise. (Unit DB4)
LOGICAL DESIGN
Main focus of logical design phase is to map out and validate the step 1 i.e. conceptual
data model on the logical structure. The detail descriptions of the steps are presented
below:
Step 2: Build and Validate Logical Data Model
The main objective of this step is to translate the conceptual data model into logical data
model. The activities involved in this process include defining the relations, the
relationship, and integrity constraints. ER model is the source representing the
conceptual data model and normalization as an important technique used for the
validation in the logical design phase. The following are the activities involved in this
phase.
Step 2.1: Derive Relations for Logical Data Model
Firstly, we create a set of relations for the logical data model based on ER model
produced in the prior design phase to represent the entities, relationships, and key
attributes.
Each entity is classified as strong or weak entity type. The relationship is examined for
its relationship type (1:1, 1:M, M:N) and its cardinality (minimum and maximum
occurrence) and participation (optional or mandatory).
PHYSICAL DESIGN
In the physical design phase, there involve processes which produce description for the
implementation of databases using a defined DBMS on secondary storage. The
description includes those factors: information, storage structure, methods of access and
security mechanism. The key focus of this stage is performance in terms of efficiency
and simplicity. In physical design we take care of those steps to ensure that all key
functions perform well and simple to implement. If there arise a complexity in the
implementation phase, we may change the logical data, for the improvement in
performance and efficiency.
The output from the logical design phase consisting of all the documents that provide
description of the process of the logical data model such as ER diagram, relational
schema, data dictionary are important sources for the physical design process. Unlike
the logical phase which is independent of the DBMS and implementation consideration,
the physical phase is tailored to a specific DBMS and is dependent on implementation
details. (Unit DB4)
Step 3: Translate logical database design for target DBMS
This step concerns with mapping the logical data model to the target DBMS. Our focus is
to produce a relational database schema that can be implemented in the target DBMS.
All process performed for every step of design need to be documented for easy
maintenance.
Step 3.1: Design Base Tables
We begin with designing the base relations that have been identified in the logical data
model in the target DBMS. For each of these relations, we need to define the attributes,
and entity constraint for primary and referential constraints for foreign keys. For each of
the attributes, among the information that we need to define in the target DBMS include
the domain, data types and default value.
Step 3.2: Design Representation of Derived Data
It is also important in this stage to decide how to represent the derived attributes which
normally should not be in the base relation.
Step 3.3: Design Remaining Business Rules
Besides the entity and referential integrity constraint, the design of business rules as the
general constraint for the target DBMS is also important to ensure the accuracy of the
information systems functionality.
Step 4: Design File Organizations and Indexes
Since one of the key focus of the physical design phase is on the performance efficiency,
determining the optimal file organization and indexes is a crucial task. Among the steps
that need to be taken are as follows:
Step 4.1: Analyze Transactions
Understanding that each functionality of the transactions that will run on the database is
vital.
REFERENCES
Figure 2c." (n.d.): n. pag. A Simplified Database System Environment. Web.
<http://courses.cse.tamu.edu/yurttas/csce310/CN/EN/01.pdf>
Database Management Systems." RDF Database Systems (2015): 9-40. Conceptual Data
Model. Web. <http://www.nirulanice.com/uploads/materials/UNIT%20I.pdf>
Unit DB1: Database Management System. Web.
< http://www.nirulanice.com/uploads/materials/UNIT%20I.pdf>
Unit DB2: Understanding the Database Design Process. Web
< http://public.wsu.edu/~arola/356/spring09/meloni_15.pdf>
Unit DB3: The Relational Data Model and Relational Database. Web.
< http://www.nirulanice.com/uploads/materials/UNIT%20II%20A.pdf>
Unit DB4: Design Methodology. Web.
< http://www.tankonyvtar.hu/hu/tartalom/tamop412A/20110021_53_database_system/CMDB5103_Database_System_07.pdf>