Database Management Systems

Introduction:

Database systems carry out an essential role in saving,

managing as well as recovering data from modern days to
secure information effectively. In this assignment, you will
begin to learn the basic ideas and tools in designing databases as
well as working with them.

Different database models ranging from relational, object-

relational, and NoSQL will be covered as well with a suggestion
of where each type is best used. Furthermore, we will discuss
data normalization as well as query optimization and transaction
processing ensuring for good quality of the data and
performance.

After completion of this assignment you will develop a good

understanding about what is American Census Information and
how it can be used in real world.

• A database can simply be defined as a structured set of data

that…
– is any collection of data stored in mass storage that can
serve as the data source for a variety of applications
– has the ability to emulate a variety of organizational
forms depending on the needs of the application
– the result of combining a variety of data collections into
single integrated collection – a ―consolidated‖ data
system
 • A database management system (DBMS) is a combination
of software and data made up of:
– Physical database—a collection of files that contain the
data
– Database engine—software that supports access to and
modification of the database contents
– Database schema—a specification of the logical
structure of the data stored in the database

Fig. 1 The elements of a database management system

Major concerns in Data Consolidation are:

1. Security: control of access to sensitive data is as important

an issue as the ability to share it.

To provide for this distinction of access privileges,

databases often rely on schemas and subschemas.
A schema is a description of the entire database structure,
a systematic organized framework, used by the database
software to maintain the database.
 2. Manageability: today, many databases are extremely large
and continue to grow.

Along with this growth come problems of misinformation

and misapplication of information.

3. Privacy and Rights: It is difficult to determine who has the

right to collect what kinds of information.

The Layered Approach to DB Implementation:

Expectation: Usually the ―end user‖ should be allowed to

concentrate on using the application for the job at hand.

Duty of the Database System: To present its information in terms

of the application NOT in computer scientific terms.

Solution: The layered approach to DB implementation

Layers of DBMS

1. End User: machine seen in terms of the application

2. Application Software: machine seen in terms of a
Highlevel language
3. Translator/Interpreter: machine seen in terms of the
Machine language
4. Actual Machine Hardware:

DBMS Access

End User Layer:

 The user requests information to the application software

Application Software Layer:

The application software passes the request to the DBMS

DBMS Layer:
The DBMS converts the request into a form understood by
the routines that actually manipulate the data in mass
storage.

Advantages of the Layered Approach –

By separating the functions of the application and the DBMS we

can achieve…

1. Simplified design process for the application programmer

o In the context of a distributed database (DB spread over
several machines in a network) the work of the application
program becomes extremely cumbersome
o The DBMS allows the application software to be
written as though the database was stored on a single
machine

2. Provide means for controlling access to the database

o The DBMS can use the entire schema for its internal
use but require that each user remain within the
bounds of his/her subschema

3. Data independence: the ability to change the database

organization without changing the application software o
To implement a change required by a particular user, one
needs only to change (a) the schema used by the central
 system, or (b) subschema of the users involved in the
change
o Allows the application to be written in terms of
simplified conceptual view of the database – the
database model
o The actual complexities of data manipulation can be
allocated to the DBMS
o The host language or the general purpose language
enhance the usability of the system by adding to the
original language

• Specialized database languages allow the user to specify the

structure of data; add, modify, and delete data; and query the
database to retrieve specific stored data
• The database schema provides the logical view of the data in
the database

The Relational Model

Tables = Relations <Stored Data>

Records = Tupples <Rows>
Fields = Attributes <columns>

One option is to organize into a single extended relation but that

would lack efficiency by creating duplicated information in
tupples
dedicated to a single attribute
risk information loss due to deletion of a tupple that also
delete related information that may still be needed;
reliance on partial tupples may point to a design flaw in the
application
 • In a relational DBMS, the data items and the relationships
among them are organized into tables
– A table is a collection of records
– A record is a collection of related fields
– Each field of a database table contains a single data
value
– Each record in a table contains the same fields

Fig. 2 Movie

• We can express the schema for this part of the database as

follows:
Movie (MovieId:key, Title, Genre, Rating)
Fig. 3 Customer

We can use a table to represent a collection of relationships

between objects

Fig. 4 Rents

• The Structured Query Language (SQL) is a comprehensive

database language for managing relational databases

E.G. Movie database SQL query:

Syntax: select attribute-list from table-list where condition

select Title from Movie where Rating = 'PG'
select Name, Address from Customer select *
from Movie where Genre like '%action%'
select * from Movie where Rating = 'R' order by Title

E.G. A database may contain

1. info about employees
2. info about jobs available in the company
3. info about relationship between employees and jobs
such as job history

The second option is to redesign the system by keeping the discrete

aspects of the relations (new and old) through data decomposition

Employee w/ 3 Attributes
EmpId JobTitle Dept

Decomposition into 2 Relations DB1:

EmpId JobTitle

DB2:
JobTitle Dept
Here, information is lost: can find the job title of the target
employee and a department having such a job but this does not
necessarily mean that the target employee works in that department
because several departments may have identical job titles

In other cases, NON_LOSS decomposition is possible.

See:
3 Relations Database (R3)

3 Relations Example: Employee:

EmpId Name Address SIN

Job:
JobId JobTitle SkillCode Dept

Assignment:
EmpId JobId StartDate TermDate

Generic Relational Operations:

1. Select records (tupples) having certain characteristics and

place them in a new relation. The SELECT operation extracts
Rows from a relation.
 NEW-1 <- SELECT from Employee where EmpId =
“34Y70”

2. Having SELECTed the tupples, (NEW-1), create a new relation

that contains the column of values from a certain attribute using
the PROJECT operation.

NEW-2 <- PROJECT JobTitle from NEW-1

Another example: when a mailing list is desired you might

query:

MAIL <- PROJECT Name, Address from Customers

3. Combine different relations into one new relation using the

JOIN operation.

For Example: Suppose we want to list all EmpId and

corresponding Depts…

Using the generic operations require 3 steps:

NEW-1 <- JOIN Assignment and Job where

Assignment.JobId = Job.JobId

NEW-2 <- SELECT from NEW-1 where

Assignment .TermDate = “*”

FINAL_LIST <- PROJECT Assignment.EmpId, Job.Dept

from NEW-2
--------------------------------
SQL: Structured Query Language
– Standardized data manipulation language – Lets
programmers learn one powerful query language and use it
on systems ranging from PCs to the largest mainframe
computers

The above example expressed in SQL looks like this:

Select EmpId, Dept from Assignment, Job where

Assignment.JobId = Job.JobId and Assignment.TermDate = ―*‖

Abstractly in SQL…

1. ―Select x, y from RA‖ is the PROJECT operation

2. ―Select x, y, z from RA where y = ―p‖ is the SELECT

operation

For example consider…

Select RA. Y, RB. Z from

RA, RB
where RA. x = RB. x

Interpretation:

JOIN RA and RB then

SELECT and PROJECT appropriate tupples and attributes as
identified in the ―Select‖ and ―where‖ clauses.

Other Examples of Modifying DB:

1. insert into RA values (‗p‘, ‗q‘, Employee:

‗r‘) ‗422R12‘, ‗Lloyd Burt‘,
333 Endless Avenue‘

2. delete from RA where x = ‗p‘ Employee:

Name = ‗Jerry Lee‘

3. update RA Employee:
Set y = ‗q‘ Address = ‗1812 Napoleon
Where x = ‗p‘ Crt.‘
Name = ‗Cora Young‘

Conclusion:
Over this exploration of database systems, we have explored the
complex world that is data management. We started very far back
at foundations of data models and SQL, quickly moved into the
juicy world of data warehousing through advanced topics like
analytics – bringing about a thorough understanding around why
databases sit right in the middle if not become core business
requirement for every modern digital company.

From relational and object-oriented databases, to NoSQL options,

we have learned facts about different types of processing systems
that fit distinct uses. We dealt with data consistency, trying to keep
the one right copy of truth(maintain data accuracy and integrity)
for things like normalizing tables/data-models and transaction
handling/processing. Begging questions of the gray-area between
laws, applying our creativity towards finding loopholes and not
solutions in the crosshairs law-makers had intended to touch
upon.Although we have maybe pushed into new frontiers when it
comes to data science (big)data-is-the-new-oil bashar!

We have practised and learnt through real-world examples, which

has provided exposure to hands-on scenarios on database
principles.

Appendix:
Data definitions: Things like ER diagrams, that show you what
entities are in your database and how those entities relate to one
another Those include detail about each of the attributes, what type
is its data — bolean, integer or string. How big it can be and all
constraints. How you ensured the integrity of your data (you
normalized it)

Design database: Relational design in the way that tables, columns

and relationships are structured. Data Flow Diagrams SQL Queries
you embedded to get data, insert and update on Data/Tables?

Technical Realization: The programming languages and database

management systems you employed. Your implementation code
snippets Process you followed to build and insert data into the
database
Test and validation: test cases you used to validate that your
database works properly The outcomes of your testing, like any
bugs or defects you exposed.

References:
1.www.boltic.io
2.db-book.com
3.totalassignemnthelp.com
4.wikipedia
5.ibm.com