Chapter - 1
Uploaded by
Bethelhem AshenafiChapter - 1
Uploaded by
Bethelhem AshenafiAmbo University
Institute of Technology
Department of Computer Science
Instructor Tadele D
1
Ambo University
Chapter 1
Fundamentals of Database System
(CoSc2071)
Instructor Tadele D
2
Ambo University
Fundamentals of Database System
Introduction to DB system
1.1What is Database?
Database
a collection of logically related data or records w/c is
designed to manage large data set/ records of an organization.
used to organize the data in the form of table, schema, views,
and reports, etc.
using it to easily retrieve, insert, and delete the information
Ex. College DB- used to organizes the data about the admin,
staff, students and faculty etc
Instructor Tadele D
3
Ambo University
Fundamentals of Database System
What is data?
Data
Known facts that can be recorded & have an implicit meaning.
Ex
name
Telephone number w/c may recorded in an indexed address
address of people bookusing PC & SW like access / excel.
Such like collection of related data with an implicit meaning is form a
db.
Instructor Tadele D
4
Ambo University
Fundamentals of Database System
1.2. Basics of Database
Database
Is represent some aspect of the real world w/c is called
mini world.
Is logically coherent collection of data with some
inherent meaning.
is defined & populated with data for a specific purpose
Play critical role in almost all areas of activities that use
computer including business, e-commerce,
engineering, education, etc.
Instructor Tadele D
5
Ambo University
Fundamentals of Database System
Database management system
is a software package designed to define, manipulate, retrieve and manage
data in a database of an organization using standard method/queries.
also called DBMS
receives instruction from a DBA & based on such instruction load, retrieve
or modify existing data from the system.
DBMS
is a SW package w/c facilitate the creation & maintenance of computerized
db.
or a collection of programs that enables users to create &maintain db . Ex.
MySQL, Oracle, PostgreSQL, Microsoft Access, SQL Server, RDBMS,etc
Instructor Tadele D
6
Ambo University
Fundamentals of Database System
DBMS
provides an interface to perform various operations like
database creation / creating a table in the database , storing data
in it, updating data in it, and a lot more.
provides protection and security to the database.
it also maintains data consistency.
That means, it allows:
Data definitions
Data updation
Data retrieval
User administration
Instructor Tadele D
7
Ambo University
Fundamentals of Database System
manages the interaction between the end user and the database
Instructor Tadele D
8
Ambo University
Fundamentals of Database System
• Data Definition:
– Standard commands through w/c data structures are
defined.
– i.e. the commands that used for creation, modification, and
removal of definition that defines the data in the database
of the organization.
– It assist storing the metadata details in the db.
• Data Up-dation:
– is used for the insertion, modification, and deletion of the
actual data in theInstructor
database.
Tadele D
9
Ambo University
Fundamentals of Database System
• Data Retrieval:
– is used to identify & extract data from a database, based on
a query provided by the user or application.
– enables the fetching of data from a database to use by
applications for various purposes.
• User Administration:
– is used for registering and monitoring users, maintain data
integrity, enforcing data security, dealing with concurrency
control, monitoring performance and recovering
information corrupted by unexpected failure
Instructor Tadele D
10
Ambo University
Fundamentals of Database System
a general purpose DBMS SW is facilitate:
the processes of defining
the processes of constructing database among various users
the processes of manipulating & application
the processes of sharing
Defining a db
Involves specifying data type, structures, & constraints of the data
to be stored in the db.
Instructor Tadele D
11
Ambo University
Fundamentals of Database System
DB definition/description
is an information w/c stored by DMBS in the form of db
catalog / dictionary.
Constructing DB
Is the process of storing data on some storage medium that
controlled by DBMS.
Instructor Tadele D
12
Ambo University
Fundamentals of Database System
Manipulating DB
Includes function such as:
querying the database to retrieve specific data,
updating the db to reflect changes in the main-world,
Generating reports for fixed query processing which
is defined during application development.
Instructor Tadele D
13
Ambo University
Fundamentals of Database System
Characteristics of DBMS
– It uses a digital repository established on a server to store and
manage the information.
– It can provide a clear and logical view of the process that
manipulates data.
– It contains automatic backup and recovery procedures.
– It contains ACID properties w/c used to ensure accuracy,
completeness, & data integrity during transaction. i.e. it
maintain data in a healthy state in case of failure.
Instructor Tadele D
14
Ambo University
Fundamentals of Database System
– It can reduce the complex relationship between data.
– It is used to support manipulation and processing of data.
– It is used to provide security of data.
– It can view the database from different viewpoints according to
the requirements of the user
Instructor Tadele D
15
Ambo University
Fundamentals of Database System
Advantage and Disadvantage of DBMS
Advantage of DBMS
– Controls database redundancy
• control data redundancy b/c it stores all the data in one single
database file
– Data sharing
• Authorized users share a data among multiple users
– Easily Maintenance
• Easily maintainable due to the centralized nature of the db
system. Instructor Tadele D
16
Ambo University
Fundamentals of Database System
– Reduce developmental time & maintenance.
– Backup
• It provides backup and recovery subsystems which create
automatic backup of data from hardware and software failures
and restores the data if required
– multiple user interface
• It provides different types of user interfaces like graphical user
interfaces, application program interfaces
Instructor Tadele D
17
Ambo University
Fundamentals of Database System
Disadvantage of DBMS
– Cost of Hardware and Software
• It requires a high speed of data processor and large memory size to run
DBMS software.
– Size
• It occupies a large space of disks and large memory to run them
efficiently.
– Complexity
• It create additional complexity & requirement
– Higher impact of failure
• Its failure is highly impact the db system b/c since all the data stored in
a single db, its failure cause loss of data forever.
Instructor Tadele D
18
Ambo University
Fundamentals of Database System
Database development life cycle
There are several steps in designing a db system. The major steps are:-
Planning
Data requirement & analysis
Define problems and constraints
Data base design phase
DBMS selection
proto typing
Implementation
Testing
Operational maintenances
Instructor Tadele D
19
Ambo University
Fundamentals of Database System
In planning phase:
Identifying information gap in an organization
and proposed a db solution to solve the problem.
general operating environment
its mission
its structure
work to be done
Resource it have, and
money to pay for all
Instructor Tadele D
20
Ambo University
Fundamentals of Database System
Data requirement and analysis phase
During Data requirement and analysis
Concentrates more on fact finding about the problem /
opportunity.
includes feasibility analysis, requirement determination
and structuring, and selection of best design method.
NB: At this point, db designer focused on:
Information needs and information sources.
Instructor Tadele D
21
Ambo University
Fundamentals of Database System
Define problems and constraints
At this phase it needs to answer the following question:
How does the existing system function and what problem it
has?
What input does the system require?
What reports does the system generate?
How the system output used?
What are the operational relationships among business
units?
What are the limits and constraints imposed on the system?
Instructor Tadele D
22
Ambo University
Fundamentals of Database System
Data base design phase
this phase take more emphasis in db development life
cycle.
that means, at this phase:
gather user requirements
model of the db created by using E/R mode based on
user requirement
Conceptual model become convert into logical db
model
use relation model
Instructor Tadele D
23
Ambo University
Fundamentals of Database System
Normalize the relational model of the db
Implement the normalized relations as table in
a relational db- this is the physical db design &
implementation
Choose a DBMS.
Use MS- SQL server &a desk top r/n at DBMS
This phase further divided in to three sub- phase,
such as:
Instructor Tadele D
24
Ambo University
Fundamentals of Database System
a. conceptual design
Concise description of entities & relationship b/n
entities
No implementation / physical detail consideration
Used to elicit & structure all information requirements
b. logical design
a higher level conceptual abstraction with selected
specific data model to implement data stricture
Instructor Tadele D
25
Ambo University
Fundamentals of Database System
attribute s
primer key
foreign key
Mapping E/R diagram in to
relational schema.
Instructor Tadele D
26
Ambo University
Fundamentals of Database System
c. physical design
involves the actual design of a db according to
the requirement that established during
modelling
names table
names column
names column data types
Instructor Tadele D
27
Ambo University
Fundamentals of Database System
DBMS selection
At this point, it emphasis on:
selection of appropriate DBMS to support db
application
design user interface & application program
using selected DBMS
Instructor Tadele D
28
Ambo University
Fundamentals of Database System
proto typing
building a working model of a db application:
to identity features of a system that work well ,or
inadequate
to suggest improvements / even add new features
clarify user requirements
evaluate feasibility of a particular system design
Ex. Of prototype dev’t stapes :
Instructor Tadele D
29
Ambo University
Fundamentals of Database System
Instructor Tadele D
30
Ambo University
Fundamentals of Database System
Implementation
physical realization of db & application designed
use DDL of DBMS to created db schemas & empty db files
use DML to create any specified user views
Testing
exciting application program with the intent of finding
error
use carefully planned test strategies & realistic data
Instructor Tadele D
31
Ambo University
Fundamentals of Database System
• N.B. Testing can’t show absence of faults, but show
software faults if present.
demonstrate db & application program to be working
according to requirement
Operational maintenances
monitoring performance of the system & maintaining the
system
if performance falls, it requires reorganization of the db &
incorporates new requirements in to the db application.
Instructor Tadele D
32
Ambo University
Fundamentals of Database System
General patterns of db development life cycle are:
Instructor Tadele D
33
Ambo University
Fundamentals of Database System
1.3. File organization
File
is a collection of records.
record – can be accessed using primary key.
frequency of access the records can be determined by the type of
file organization.
File organization
is a logical relationship among various records.
an approach that used to describe the way in which the records are
stored.
Some of the file organization approaches are:
Manual based approach
file based approach
Database approach
Instructor Tadele D
34
Ambo University
Fundamentals of Database System
1.3. File organization Vs Data base approach
Before the advent of computerized file
handling system their is manual file handling
system w/c depends the use of:
file cabinet
drawer
Pen & pepper etc.
Instructor Tadele D
35
Ambo University
Fundamentals of Database System
Manual file handing system and its limitation
In manual file based approach:
Data storage & retrieval follows the primitive & traditional way of
information handling.
I.e. data storage & retrieval will be performed by using human labour.
it use cards & papers
To access data it needs to index the system
Inserting & retrievable is done by searching right cabinet then file and
finally information.
file store in one more cabinets
Instructor Tadele D
36
Ambo University
Fundamentals of Database System
Limitation of manual file handing system
Some of the limitation in manual file handing
system includes:
Less secure
Not sharable
Highly porne to error
Difficult to update retrieval data & integrate data
Have data but it is d/ct to compile the information
Cross reference is d/ct
Instructor Tadele D
37
Ambo University
Fundamentals of Database System
So, to overcome this limitation of manual file
handing system, there are two computerized
approach. Such as:
1. file based approach –decentralized
2. data base approach – centralized
In file based approach
file is collection of recodes w/c contains logically
related data
Instructor Tadele D
38
Ambo University
Fundamentals of Database System
also called traditional file based system.
is an early attempt to computerize the manual filing system.
is decentralized computerized data handing method
a collection of application program is used to provide
service for user
Every application program w/c provides service to the end
user define & manage its own data. b/c of this, it subject to
a serious of data duplication problem.
Instructor Tadele D
39
Ambo University
Fundamentals of Database System
File-Based Approach
16
16
Instructor Tadele D
40
Ambo University
Fundamentals of Database System
Limitations of this approach are:
limited data sharing
lengthy development & maintenance time
duplication / redundancy of data
data dependency on the application
Incompatible file formats b/n d/t application & program
creating inconsistency.
the most significant problem w/c experienced in file
based approach of data handing is anomalies
Instructor Tadele D
41
Ambo University
Fundamentals of Database System
There are three types of anomalies
1. Modification anomalies
a problem w/c experienced when one / more data valve is
modified on one application program but not on other w/c
containing the same data set.
2. Deleting anomalies
A problem that to be encountered when one record set is
deleted from one application but remain untouched in other
application program w/c contains the same record set.
Instructor Tadele D
42
Ambo University
Fundamentals of Database System
3. insertion anomalies
a problem w/c experienced when new data item to
by recorded, & the recording isn’t mode in all
application.
Data base approach
Data base
is a shared collection of logically related data w/c
designed to meet information needs of an
organization.
Instructor Tadele D
43
Ambo University
Fundamentals of Database System
Characteristic of db approach
is a centralized system
contain data description w/c called data dictionary or system
catalogue
is a self descriptive collection of integrated records b/c of it
contains information about data.
is designed once & used simultaneously by many users.
Unlike file based approach, it has a program w/c is data
independent
Separation of data definition from application.
Instructor Tadele D
44
Ambo University
Fundamentals of Database System
i.e application isn’t affected by change made on data structure &
file organization
each db application will be perform the combination of:
creating db
reading db
updating db
deleting db
store information centrally
allow user to retrieve & update information
Instructor Tadele D
45
Ambo University
Fundamentals of Database System
• Purpose /Benefits of db approach
a. Data can be shared
Two / more users access & use the same data instead of storing
data in redundant manner.
b. Improve accessibility of data.
By using SQL, the users easily access data without having
programming experience
c. Reducing data redundancy
Isolated data is integrated in db to decrease redundancy of data
which stored at different application
Instructor Tadele D
46
Ambo University
Fundamentals of Database System
d. inconsistency can be avoided
Controlling data redundancy will be avoid inconsistency of data
in the db
e. provide transaction support
Basic demands of any transaction are implanted in a full scale
DBMS
f. integrity can be maintained
Data at different application will be integrated together with
additional constraints to facilitate shared data resource
Instructor Tadele D
47
Ambo University
Fundamentals of Database System
g. security measures can be enforced
Shared data can be secured by having different levels of data
security mechanism.
h. improve decision
Database will provide useful information for right decision
making.
i. centralized information control
Data can be controlled and managed at central level
Instructor Tadele D
48
Ambo University
Fundamentals of Database System
Instructor Tadele D
49
Ambo University
Fundamentals of Database System
Instructor Tadele D
50
Ambo University
Fundamentals of Database System
Limitations and risks of db approach
Introduction of new professional and specialized
personnel
complexity in designing and managing data
high cost to be incurred to development and
maintain system
complex backup and recovery services from user
perspective
Reduce performances due to centralization and
data independence.
High impact on the system when failure occurs to
the central system.
Instructor Tadele D
51
Ambo University
Fundamentals of Database System
DBMS vs File system
In DBMS In File System
•the user is not required to write the •the user write the procedures for
procedures. managing the database.
•gives an abstract view of data that •provides the detail of the data
hides the details representation and storage of data.
•provides a crash recovery mechanism •doesn't have a crash mechanism, so if
the system crashes the contents of the
file will lost
•provides a good protection •very difficult to protect a file under the
mechanism. file system.
•contains a wide variety of •can't efficiently store and retrieve the
sophisticated techniques to store and data
retrieve the data.
Instructor Tadele D
52
Ambo University
Fundamentals of Database System
1.4 Users and actor of database system
• User of all db system may divided in to:
those who actually use & control, the content w/c
is called actors on the scene
those who enable the db to development & the
DBMS sw to be designed implemented called
workers behind the scene
Instructor Tadele D
53
Ambo University
Fundamentals of Database System
Some of the user & actors of db system are:
DBA
responsible to oversee, control & manage db resource
i.e db itself DBMS & other related sw
responsible to authorizing access to db
coordination & monitoring the use of the db
responsible for determining of acquiring HW and SW resources
accountable for problems like poor security, poor performance of the
system
involves in all steps of DB development
Instructor Tadele D
54
Ambo University
Fundamentals of Database System
DBD
identifies the data to be stored and choose the appropriate
structures, constraints and functions to represent & stored
data
understand user requirement and choose user – views of the
db
communicate with end – user and understand their needs
involves in design phase before implementation of db system
Instructor Tadele D
55
Ambo University
Fundamentals of Database System
Application developer
Sw programmer who design & implement the
application programs w/c to be used an interface
for db system & for maintaining the db
the one who code, test , document &maintaining
the application program
also determine interface to retrieve, insert,
update& delete data in db
Instructor Tadele D
56
Ambo University
Fundamentals of Database System
End –user
Worker who access db frequently for various purpose
use data for queries , reports & some of them actually
to update db content
Are deferent groups such as:
Casual user
users who access db occasionally
users how use sophisticated db queries to satisfy
their needs
Instructor Tadele D
57
Ambo University
Fundamentals of Database System
Naive / parametric user
make up a large section of the end-user population
unaware of DBMS
only access db based on their access level & demand
use standard &pre-specification types of queries
E.X - bank – teller
- Reservation clears
Instructor Tadele D
58
Ambo University
Fundamentals of Database System
sophistication user
users who familiar witch structure of db
&facilities of the DBMS
familiar with system capabilities
have complex requirements
have higher level of quires
E.X -business analysts, Engineers, scientist etc.
Instructor Tadele D
59
Ambo University
Fundamentals of Database System
Instructor Tadele D
60
Ambo University
Fundamentals of Database System
stand alone user
mostly maintain personal dbs using ready to use package
application
ex. a tax program user that creates his / her own internal db
So, actors on the scene:
DBA
DBD
End – user
Instructor Tadele D
61
Ambo University
Fundamentals of Database System
Worker behind the scene
DBMS designer & implementers
tool developer
Expects who dev ’p sw package that facilitate db
system designing & use
e.x
• code generator
• independent se vendors
Instructor Tadele D
62
Ambo University
Fundamentals of Database System
operators &maintenance personnel
System administrators who responsible for
actually running & maintaining hw & sw of db
system
Instructor Tadele D
63
Ambo University
Fundamentals of Database System
The End!
Thank you!!
Instructor Tadele D
Ambo 64
Chapter 2
Database system architecture
Instructor Tadele D
65
Ambo University
Fundamentals of Database System
2. DBMS Architecture
DBMS design - depends upon its architecture.
The basic client/server architecture:
is used to deal with a large number of PCs, web servers, database servers
and other components that are connected with networks.
i.e. it consists of many PCs and a workstation which are connected via
the network.
DBMS architecture
- depends upon how users are connected to the database to get their request
done.
- used in design, development, implementation, and maintenance of a
database.
Instructor Tadele D
66
Ambo University
Fundamentals of Database System
Types of DBMS architecture
Database architecture
can be exists as uni-tire or multi tire.(tire/layer-is physical unit, where the code/ process runs)
logically, three types such as:1-Tier architecture, 2-tier
architecture and 3-tier architecture.
1-Tier architecture
is simplest of database architecture, where the client, server, and
database all reside on the same machine.
i.e. the db is directly available to the user & the user directly use
the DBMS.
Instructor Tadele D
67
Ambo University
Fundamentals of Database System
i.e. any change done directly on the database itself.
is used for development of the local application, in w/c
programmers can directly communicate with the database for the
quick response.
Its disadvantages
is only one user can access the system at a given time via the local
client.
Do not support remote/ distributed access for data
resources.
Instructor Tadele D
68
Ambo University
Fundamentals of Database System
2-Tier architecture
is the same as basic client-server model.
The presentation layer runs on a client and the data stored on the server.
In 2-tire architecture
applications on the client end can directly communicate with the database at the
server side.
it uses API's like: ODBC (Open Database Connectivity) which allows the client-
side program to call the DBMS.
user interfaces and application programs are run on the client-side.
server side is responsible to provide the functionalities like: query processing
and transaction management.
client-side application establishes a connection with the server side to
communicate with the DBMS.
Instructor Tadele D
69
Ambo University
Fundamentals of Database System
also added security to the DBMS as it is not exposed to the end user directly.
Fig. 2-tier architecture
Instructor Tadele D
70
Ambo University
Fundamentals of Database System
3-Tier architecture
contains another layer between the client and server.
It has presentation layer, application layer and database server.
is used in case of large web application.
In 3-tire architecture
client can't directly communicate with the server.
application on the client-end interacts with an application server (DMBS) which
further communicates with the database system.
That means, an application layer is responsible for communicating the user's
request to the DBMS system and send the response from the DBMS to the user.
It also processes functional logic, constraint, and rules before passing data to the
user or down to the DBM.
Instructor Tadele D
71
Ambo University
Fundamentals of Database System
end user has no idea about the existence of the database beyond the application server.
database also has no idea about any other user beyond the application.
Fig.3-Tier architecture
Instructor Tadele D
72
Ambo University
Fundamentals of Database System
2.1 Data Model schemas and instances
Database design focuses on:
how database structure will be used to store and manage end-user data.
Database schema
is the overall design of the database.
i.e. is the formal description of the structure of database w/c supported by DBMS
represents the logical view of the entire database by using the visual diagram.
divided into database tables in the case of Relational Databases
i.e. contains schema objects like table, foreign key, primary key, views, columns,
data types, stored procedure, etc.
Instructor Tadele D
73
Ambo University
Fundamentals of Database System
Instance
is the set of information / data currently stored in a database at a specific time.
Model
is an abstraction of a more complex real - world object or event.
Data Modeling
is the first step / process of the database design / creations.
it refers to the process of creating a specific data model:
− w/c clarifies communication by reducing the complexities of database design to
more easily understood abstractions that define entities and the relations among
them.
Instructor Tadele D
74
Ambo University
Data Modeling (cont….)
Used by database designer to communicate with applications programmers and
end users.
is an iterative and progressive process.
Data Model
are fundamental entities to introduce abstraction in a DBMS.
define how data is connected to each other and how they are processed and
stored inside the system.
relatively simple representation of more complex real-world data structures
graphical.
represents data structures and their characteristics, relations, and constraints.
Instructor Tadele D
75
Ambo University
Data Modeling (cont….)
Data model
a blueprint that containing all the instructions to build a database that will
meet all end-user requirements. This blueprint is narrative and graphical in
nature.
contains both text descriptions in plain, unambiguous and clear language,
useful diagrams depicting the main data elements.
contain at least the following components:
− A description of data structure that will store the end-user data.
− a set of enforceable rules to guarantee the integrity of the data.
− a data manipulation methodology to support the real-world data
transformations.
Instructor Tadele D
76
Ambo University
Data Modeling (cont….)
Importance of data models
A communication tool that facilitates interaction among the designer,
applications programmer, and end user.
Instructor Tadele D
77
Ambo University
Data Modeling (cont….)
2.2 Over view or Basic building blocks of data model
Some of the basic building blocks of data models are:
− entities, attributes, relationships, and constraints
An entity
Is anything (a person, a place, a thing, or an event) about which data are to
be collected and stored.
Represents a particular type of object in the real world.
An attribute
A characteristic of an entity.
Instructor Tadele D
78
Ambo University
Data Modeling (cont….)
A relationship
Describes an association among entities.
Data models use three types of relationships, such as:
One-to-many, many-to-many, and one-to-one which shortly represent as
1:M or 1..*, M:N or *..*, and 1:1 or 1...1, respectively.
A constraint
A restriction which placed on the data.
Are important because they help to ensure data integrity.
Normally expressed in the form of rules. For example:
− A student’s GPA must be between 0.00 and 4.00.
Instructor Tadele D
79
Ambo University
Data Modeling (cont….)
Types of data model
Some of the data models are:
− Hierarchical and Network Models
Hierarchical model
Was developed in the 1960s to manage large amounts of data for complex
manufacturing projects.
Logical its structure represented by an upside-down tree.
Contains levels, or segments.
Instructor Tadele D
80
Ambo University
Data Modeling (cont….)
A segment is the equivalent of a record type file systems.
In hierarchy model
a higher layer is perceived as the parent of the segment
child node is the segment which directly beneath to the parent
of the segment
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. Instructor Tadele D
Ambo University
81
Data Modeling (cont….)
Network model
Was created to represent complex data relationships more effectively
than the hierarchical model, to improve database performance, and to
enforce a database standard.
The user perceives the network database as a collection of records in 1:
M relationships.
But unlike the hierarchical model, the network model allows a record
to have more than one parent.
Definitions of standard database concepts that emerged with the
network model areInstructor
still usedTadeleby
D modern data models.
82
Ambo University
Data Modeling (cont….)
In network model
Ex.
Schema, which is the conceptual organization of the entire database as viewed by the
database administrator.
Subschema, which defines the portion of the database “seen” by the application
programs that actually produce the desired information from the data contained within
the database.
Data manipulation language (DML), which defines the environment in which data
can be managed and to work with the data in the database.
Data definition language (DDL), which enables the database administrator to define
the schema components. Instructor Tadele D
Ambo University
83
Data Modeling (cont….)
As information needs grew and required more sophisticated
databases and applications, the network model replaced by the
relational data model.
Relational Model
was introduced in 1970 by E. F. Codd
Produced an “automatic transmission” database to replace
the “standard transmission” databases.
Instructor Tadele D
84
Ambo University
Data Modeling (cont….)
Its foundation is a mathematical concept known as a relation /
table which composed of intersecting rows and columns. Each row
in a relation is called a tuple. Each column represents an attribute.
Implemented through a very sophisticated relational database
management system (RDBMS) which performs 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.
Instructor Tadele D
85
Ambo University
Data Modeling (cont….)
One of the most important advantage of the RDBMS
Its ability to hide the complexities of the relational model from the user.
i.e. RDBMS manages all of the physical details, while the
user sees the relational database as a collection of tables in which data
are stored.
RDBMS
Uses SQL to translate user queries into instructions for retrieving the
requested data.
Instructor Tadele D
86
Ambo University
Data Modeling (cont….)
In relational data model
Tables are related to each other through the sharing of a common attribute
Ex. CUSTOMER table contain a sales agent’s number /code that is also
contained in the AGENT table .
Instructor Tadele D
87
Ambo University
Data Modeling (cont….)
Entity Relationship Model
B/c of no features in relational model that make it an effective
database design tool, the Entity Relationship Model is
produced.
Represent data modeling structures graphically than to describe
them in text.
Database designers prefer to use a graphical tool to represent
entities and their relationships. B/c of this, entity relationship
(ER) model become get a widely accepted standard for data
modeling.
Instructor Tadele D
88
Ambo University
Data Modeling (cont….)
ER model
The first produced in 1976.
It was the graphical representation of entities and relationships in a
database structure.
Are normally represented in an entity relationship diagram (ERD),
which uses graphical representations to model database components.
based on:
Entity
Entity – which represented in the ERD by a rectangle
Instructor Tadele D
89
Ambo University
Data Modeling (cont….)
When ERD is applying to the relational model, an entity is mapped
to a relational table. Each row in the relational table is known as
an entity instance or entity occurrence in the ER model.
Entity - described by a set of attributes
For example, an EMPLOYE entity will have attributes such as
the first name, middle name, and a last name,
Relationship
Relationships - which describe associations between two
entities.
Instructor Tadele D
90
Ambo University
Data Modeling (cont….)
ER model
Uses the term connectivity / cardinality ratio to label the
relationship types.
The three types of relationships which used to illustrated the
relationship among two entities are: one-to-many (1:M), many-
to-many (M:N), and one-to-one (1:1). For example , EMPLOYEE
manages a DEPARTMENT, EMPLOYEE
works DEPARTMENT, STUDENT enrolls COURSE, etc.
See the figure below
Instructor Tadele D
91
Ambo University
Data Modeling (cont….)
EMPLOYEE DEPARTMENT
manages
STUDENT COURSE
Enrolls
Object-Oriented (OO) Model
Object-oriented (OO) model
is the basis for the object-oriented database management system
(OODBMS).
Instructor Tadele D
92
Ambo University
Data Modeling (cont….)
In OODM – both data and their relationships are contained
in a single structure known as an object.
An object
An abstraction of a real-world entity.
It be considered equivalent to an ER model’s entity.
• Represents only one occurrence of an entity.
It’s properties are described by attributes
Ex. PERSON object includes the attributes Name, sex, and
Date of Birth.
Which share similar characteristics are grouped in classes.
Instructor Tadele D
93
Ambo University
Data Modeling (cont….)
A class is a collection of similar objects with shared structure
(attributes) and behavior (methods).
For example, consider an object representing bank account.
• Contains instance variables number and balance.
• Contains a method pay-interest which adds interest to
the balance.
Under most data models, changing the interest rate entails
changing code in application programs. But in the object-
oriented model, this only entails a change within the pay-
interest method.
Instructor Tadele D
94
Ambo University
Data Modeling (cont….)
Classes are organized in a class hierarchy which resembles an
upside-down tree in which each class has only one parent.
Ex, the CUSTOMER class and the EMPLOYEE class share a parent
PERSON class.
Inheritance is the ability of an object within the class hierarchy
to inherit the attributes and methods of the classes above it.
For example, two classes, CUSTOMER and EMPLOYEE, can be created
as subclasses from the class PERSON. In this case, CUSTOMER and
EMPLOYEE will inherit all attributes and methods from PERSON class.
Instructor Tadele D
95
Ambo University
Database System Concepts and Architecture
2.3 Architecture and Data Independence
Degrees of data abstraction
A database designer starts with an abstract view of the overall data
environment and adds details as the design comes closer to implementation.
Using levels of abstraction can also be very helpful in integrating multiple
views of data as seen at different levels of an organization.
In early 1970s, the American National Standards Institute (ANSI) Standard
Planning and Requirements Committee (SPARC) defined a framework for data
modeling based on degrees of data abstraction.
Instructor Tadele D
96
Ambo University
Database System Concepts and Architecture (cont….)
Major purpose of a database system architecture
The system hides is to provide users with some level of an
abstraction view of the system which some time referred as
architecture of the system .
i.e. is to support data abstraction so that different users can
perceive data at their preferred level of detail.
• certain details of how data is stored and maintained. i.e.
Complexity should be hidden from database users.
•The ANSI/SPARC architecture defines three levels of data abstraction,
such as: external, conceptual, and internal.
Instructor Tadele D
97
Ambo University
Database System Concepts and Architecture (cont….)
(a) Internal level /Physical Level:
Once a specific DBMS has been selected, the internal model maps the
conceptual model to the DBMS.
Internal model
is the representation of the database by DBMS.
It requires the designer to match the conceptual model’s characteristics
and constraints to those of the selected implementation model.
Internal schema should map the conceptual model to the relational model
constructs. I.e. entities in the conceptual model are mapped to tables in the
relational model.
Instructor Tadele D
98
Ambo University
Database System Concepts and Architecture (cont….)
For example, if a relational database has been selected, the internal schema
is expressed using SQL, the standard language for relational databases.
Software-dependent. I.e. It depends on specific database software. So, the
change in the DBMS software requires that the internal model be changed to
fit the characteristics and requirements of the implementation database
model.
But it is hardware-independent. i.e. unaffected by changing computer on
which the software is installed.
Therefore, a change in storage devices or even a change in operating systems
will not affect the internal model.
Instructor Tadele D
99
Ambo University
Database System Concepts and Architecture (cont….)
(b) Conceptual Model
having identified the external views
Graphically represented by an ERD to integrate all external views
into a single view.
Represents a global view of the entire database as viewed by the
entire organization.
That is, conceptual model integrates all external views
(entities, relationships, constraints, and processes) into a
single global view of the data in the enterprise.
Instructor Tadele D
100
Ambo University
Database System Concepts and Architecture (cont….)
Also known as a conceptual schema.
is the basis for the identification and high-level description of the main data
objects
Next highest level of abstraction.
Provides bird’s-eye view of the data environment.
Describes the structure of the whole database including what data are stored
for a community of users.
Hides the details of physical storage structures and concentrates on
describing entities, data types, relationships, user operations, and constraints.
Is independent of both software and hardware.
Instructor Tadele D
101
Ambo University
Database System Concepts and Architecture (cont….)
Software independence means the model does not
depend on the DBMS software used to implement the
model.
Hardware independence means the model does not
depend on the hardware used in the implementation of
the model.
Instructor Tadele D
102
Ambo University
Database System Concepts and Architecture (cont….)
In conceptual level
either the hardware or the DBMS software will have no effect
on the database design
Generally, logical design is used to refer to the task of creating
conceptual data model that could be implemented in any DBMS.
ER model
The most widely used conceptual model.
Illustrated with the help of the ERD.
Instructor Tadele D
103
Ambo University
Database System Concepts and Architecture (cont….)
Instructor Tadele D
104
Ambo University
Database System Concepts and Architecture (cont….)
(c) External Model
The end users’ view of the data environment. End users refer to
people who use the application programs to manipulate the data
and generate information.
High level of abstraction.
Describes part of the database for a particular group of users and
hides the rest of the database from that user group.
E.g. tellers in a bank get view of customer accounts, but not
payroll data.
Independent of both HW &SW
Instructor Tadele D
105
Ambo University
Database System Concepts and Architecture (cont….)
Fig: The three levels of data abstraction level
Instructor Tadele D
106
Ambo University
Database System Concepts and Architecture (cont….)
Summary of the levels of data abstraction
Instructor Tadele D
107
Ambo University
The end .
Thank you!!!
Instructor Tadele D
108
Ambo University
Chapter three
Entity-Relationship (ER) Model
109
Entity-Relationship (ER) Model(cont....)
E-R Model
Entity-Relationship model
Is a popular high-level conceptual data model.
i.e. is the most widely used conceptual model w/c
is the basis for the conceptual schema.
is used for the conceptual design of database
applications. i.e. many database design tools employ
its concepts.
110
Entity-Relationship (ER) Model(cont....)
Entities
Corresponds to entire table, not row
Represented by Rectangle containing the entity’s name.
Refers to the entity set.
Entity UniversityStudent
Primary key
PK StudentID
Attribute StudentName
StudentDOB
StudentAge
111
Entity-Relationship (ER) Model(cont....)
Attributes
•Represents the property used to describe an entity or a relationship
•Represented by Oval and connected to the entity with a line. ID.No
•Each oval contains the name of the attribute it represents.
Simple attribute cannot be subdivided.
•Examples: Age, Sex, and Marital status
Composite attribute can be further subdivided to yield additional attributes.
•Examples:
•ADDRESS kebele, City, District, Zone, State
•PHONE NUMBER Area code, Exchange number
112
Entity-Relationship (ER) Model(cont....)
A single-valued attribute can have only a single value.
•Examples:
A person can have only one social security number.
A manufactured part can have only one serial number.
Multi-valued attributes can have many values.
•Examples:
A person may have several college degrees.
A household may have several phones with different numbers
Multi-valued attributes are shown by a double line circled to the
entity.
113
Entity-Relationship (ER) Model(cont....)
A derived attribute is not physically stored within the database;
but, it is derived by using an algorithm.
• Example: AGE can be derived from the data of birth and the current
date.
Relationships
• Represents the association that exist between several entities
Enroll
Represented by Diamond-shaped symbols.
A relationship’s degree - indicates number of associated entities
or participants.
114
Entity-Relationship (ER) Model(cont....)
A unary relationship exists when an association is maintained
within a single entity.
A binary relationship exists when two entities are associated.
A ternary relationship exists when three entities are
associated.
Connectivity
The term connectivity is used to describe the relationship
classification (e.g., one-to-one, one-to-many, and many-to-
many).
115
Entity-Relationship (ER) Model(cont....)
Constraints
•Represent the constraint in the data
•is usually expressed as an E-R diagram
•Represented by line as such like :
•Before working on the conceptual design of the database, one has to answer
the following basic questions:- What are the entities and relationships in the
enterprise?
•What information about these entities and relationships should we store
in the database?
•What are the integrity constraints that hold? Constraints on each data
with respect to update, retrieval and store.
116
Entity-Relationship (ER) Model(cont....)
Represent this information pictorially in ER diagrams, then map
ER diagram into a relational schema.
3.4 The ER diagrams
Present the diagrammatic notation w/c associated with the Entity-
Relationship (ER) Model.
is widely used in database design
Represent conceptual level of a database system
Describe things and their relationships in high level
117
Entity-Relationship (ER) Model(cont....)
Developing an E-R Diagram
•Designing conceptual model for the database is not a linear
process but an iterative activity where the design is refined
again and again.
•To identify :- Entities,
•Attributes,
•Relationships, and Constraints on the data,
•There are different set of methods used during the
analysis phase.
118
Entity-Relationship (ER) Model(cont....)
•These include information gathered by…
Interviewing end users individually and in a group
Questionnaire survey
Direct observation
Examining different documents
•Basic E-R model is graphically depicted and
presented for review.
The process is repeated until the end users and
designers agree that the E-R diagram is a fair
representation of the organization’s activities and
functions.
119
Entity-Relationship (ER) Model(cont....)
•Checking for Redundant Relationships in the ER Diagram.
•Relationships between entities indicate access from one entity
to another -
•Therefore possible to access one entity occurrence from another
entity occurrence even if there are other entities and
relationships that separate them - This is often referred to as
Navigation of the ER diagram.
•Validating an Entity-Relationship (ER) Model against
requirement of the user.
120
Entity-Relationship (ER) Model(cont....)
Graphical Representation in E-R Diagram
Entity
• Is represented by a RECTANGLE containing the name of the entity.
Strong Entity
• Two types ,such as strong and weak
Weak Entities
• is an entity that its existence-dependent and
• Has a primary key that is partially or totally derived from the parent
entity in the relationship.
• Its existence indicated by a double rectangle.
Weak entity
• Inherits all or part of its primary key from its strong counterpart.
121
Entity-Relationship (ER) Model(cont....)
Connecting entities are called relationship
participants
Attributes
•Are represented by ovals and are connected to the
entity by a line.
122
Entity-Relationship (ER) Model(cont....)
•A derived attribute is indicated by a DOTTED LINE. (…)
PRIMARY KEYS are underlined.
Relationships are represented by DIAMOND shaped
symbols.
Weak Relationship is a relationship between Weak and
Strong Entities
123
Entity-Relationship (ER) Model(cont....)
•Strong Relationship is a relationship between two
strong Entities.
124
Entity-Relationship (ER) Model(cont....)
•Example 1: Build an ER Diagram for the following
information:
A student record management system will have the following
two basic data object categories with their own features or
properties:
Students will have an Id, Name, Dept, Age, GPA and Course
will have an Id, Name, Credit Hours
Whenever a student enrols in a course in a specific Academic
Year and Semester, the Student will have a grade for the course.
125
Entity-Relationship (ER) Model(cont....)
126
Entity-Relationship (ER) Model(cont....)
•Exercise: Build an ER Diagram for the following information:
A Personnel record management system will have the following
two basic data object categories with their own features or
properties:
Employee will have an Id, Name, DoB, Age, Tel and
Department will have an Id, Name, Location
•Whenever an Employee is assigned in one Department, the
duration of his stay in the respective department should be
registered.
127
Entity-Relationship (ER) Model(cont....)
Example 2
Build an ER Diagram for the following information:
Patients
•Name, Address, Phone #, Age
Drugs
•Name, Manufacturer , Expiration Date
Patients are prescribed drugs
•Dosage, # Days
128
Entity-Relationship (ER) Model(cont....)
Answer for Example 2
Addr Name
Name Age
Manuf
Patients Drug
Phone
Exp
Prescrib
ed
Dosage #days
129
Entity-Relationship (ER) Model(cont....)
Classifications Relationship within the relational database
As already discuss relationships are classified as – 1:1,, 1:M,, M:N
1. One-to-one relationship:
one entity can be related to only one other entity, and vice versa..
If the relationship between A and B satisfies the one-to-one mapping
constraint from A to B, then:
- an entity in A is related to at most one entity in B,
- an entity in B is related to at most one entity in A.
– For a one-to-one relationship between two entity sets E and F, key(E) and
key(F) are both keys for the relationship set.
130
Entity-Relationship (ER) Model(cont....)
131
Entity-Relationship (ER) Model(cont....)
Example 2:- A customer is associated with at
most one loan via the relationship borrower.
– A loan is associated with at most one customer
via borrower.
132
Entity-Relationship (ER) Model(cont....)
E.g.: Relationship Manages between Staff and
branch.
•The multiplicity of the relationship is:
One branch can only have one manager
One employee could manage either one or no
branches
133
Entity-Relationship (ER) Model(cont....)
2. One-To-Many Relationships
is easily implemented in the relational model by putting
the primary key of the 1 side in the table of the many side
as a foreign key.
In the one-to-many relationship:-
a loan is associated with at most one customer via borrower.
a customer is associated with several (including 0) loans via
borrower
134
Entity-Relationship (ER) Model(cont....)
135
Entity-Relationship (ER) Model(cont....)
•E.g.: Relationship Leads between staff and project.
•The multiplicity of the relationship:-
One staff may Lead zero or more project(s).
One project is led by one staff
136
Entity-Relationship (ER) Model(cont....)
3. Many-To-Many Relationship
is not supported directly in the relational environment.
However, M:N relationships can be implemented by creating
a new entity in 1:M relationships with the original entities.
•A customer is associated with several (possibly 0) loans via
borrower.
•A loan is associated with several (possibly 0) customers via
borrower.
137
Entity-Relationship (ER) Model(cont....)
138
Entity-Relationship (ER) Model(cont....)
•E.g.: Relationship Teaches between instructor and course.
•The multiplicity of the relationship:-
One Instructor teaches one or more Course(s).
One course is thought by Zero or more Instructor(s).
139
Entity-Relationship (ER) Model(cont....)
Participation constraint of a relationship
•Specifies whether the existence of an entity depends
on its being related to another entity via the
relationship type.
•There are two distinct participation constraints with
respect relationship type, namely:-
Total Participation and
Partial Participation
140
Entity-Relationship (ER) Model(cont....)
Total participation constraints require the participation of every entity in
the relationship.
•It is displayed by a double line.
•Partial participation constraints(displayed by a single line).
•Participation of EMPLOYEE in “manages” relationship with
DEPARTMENT, is partial participation since not all employees are
managers.
•Participation of DEPARTMENT in “Manages” relationship with
EMPLOYEE is total since every department should have a manager.
Employee Department
141
Entity-Relationship (ER) Modeling
modeling
Is the first step in the database design.
it serving as a bridge between real-world
objects and the database model.
Conceptual models are used in the conceptual
design of databases, while relational models are
used in the logical design of databases.
Entity-Relationship (ER) Modeling (cont……)
Entity-Relationship model (ERM)
Is a popular high-level conceptual data model.
Form the basis of an ERD which represents the conceptual
database as viewed by the end user.
modeling tools that used to develop ERDs which form the
basis for successful database design and implementation.
ERDs
– depict the database’s main components, such as: entities,
attributes, and relationships.
Entity-Relationship (ER) Modeling (cont……)
• various notations such as Chen notation and the newer
Crow’s Foot and UML notations used with ERDs
• Chen notation and the newer Crow’s Foot notations are
used to introduce some basic Entity-Relationship (ER)
Modeling concepts
• But Some conceptual database modeling concepts are
expressed by using only the Chen notation
• However Unified Modeling Language (UML) notations
Are popular in both database and software design.
Entity-Relationship (ER) Modeling (cont……)
Beyond database design it specifies detailed design
of software modules and their interactions using
various types of diagrams.
Important part of UML is class diagrams w/c are
similar in many ways to the ER diagrams.
In class diagrams, operations on objects are specified,
in addition to specifying the database schema
structure. Operations can be used to specify the
functional requirements during database design.
Entity-Relationship (ER) Modeling (cont……)
• Generally
– Chen notation favors conceptual modeling.
– Crow’s Foot notation favors a more implementation-
oriented approach.
– UML notation can be used for both conceptual and
implementation modeling.
• Entities
– Is the representation of real world object.
– It refers to the entity set w/c is the corresponds to a table
in ERM
Entity-Relationship (ER) Modeling (cont……)
• Both in Chen and Crow’s Foot notations, an entity is
represented by a rectangle containing the entity’s
name,
• See the picture below for more illustrations
• Chen & Crow’s Foot is represent student entity &
attribute
Entity-Relationship (ER) Modeling (cont……)
Required and Optional Attributes
• Required Attributes
– is an attribute that must have a value. i.e. it cannot be left
empty. As shown in Crow’s Foot there are two boldfaced
attributes ,such STU_LNAME and STU_FNAME are require data
entries because all students have a first name and a last name.
But students might not have a phone number and an e-mail
address .so, those attributes are not presented in boldface in
the entity box.
• optional attribute
– is an attribute that does not require a value. i.e. it can be left
empty.
Entity-Relationship (ER) Modeling (cont……)
• Domains
is the set of possible values for a given attribute.
For ex1, domain for the grade point average (GPA) attribute is
(0,4) because the lowest possible GPA value is 0 and the highest
possible value is 4.
Ex 2. the domain for the gender attribute consists of only two
possibilities: M or F
Attributes may share a domain. For instance, a student address and
a
professor address share the same domain of all possible addresses.
Entity-Relationship (ER) Modeling (cont……)
In fact, the data dictionary may let a newly declared attribute inherit
the characteristics of an existing attribute if the same attribute name
is used.
• For example, the PROFESSOR and STUDENT entities may each have
an attribute named ADDRESS, therefore it share a domain.
• Identifiers (Primary Keys)
• Is one or more attributes that uniquely identify each entity
instance. ERM uses identifiers.
• In the relational model, such identifiers are mapped to primary
keys (PKs) in tables. Such like Identifiers which map to primary key
are underlined in the ERD.
Entity-Relationship Modeling(ERM) (cont……)
• Key attributes / identifiers are use this format:
– TABLE NAME (KEY_ATTRIBUTE 1, ATTRIBUTE 2,
ATTRIBUTE 3, ... ATTRIBUTE n)
– Ex. CAR entity represent as:
• CAR (CAR_ECODE, CAR_VIN, MOD_CODE,
CAR_YEAR, CAR_COLOR)
Entity-Relationship Modeling(ERM) (cont……)
• Database Design Using ERM.
Entity-Relationship Modeling(ERM) (cont……)
• The first step of database design is requirements collection and
analysis (see the above diagram for more illustration). During this
step, the database designers interview prospective database users
to understand and document their data requirements w/c is called
set of users’ requirements. The requirements should be specified in
detailed and complete form as possible. In parallel with specifying
the data requirements, it needs to specify the known functional
requirements of the application w/c consist of the user-defined
operations that will be applied to the database, including both
retrievals and updates.
Entity-Relationship Modeling(ERM) (cont……)
• In software design, it is common to use data flow diagrams,
sequence diagrams, scenarios, and other techniques to specify
functional requirements.
Once the requirements have been collected and analyzed, the
next step:
Is creating a conceptual schema for the database, using a
high-level conceptual data model.
This step is called conceptual design.
Entity-Relationship Modeling(ERM) (cont……)
Conceptual schema
Is a concise description of user’s data requirements.
It includes detailed descriptions of entity types, relationships,
and constraints.
Expressed using the concepts provided by the high-level data
model because the concepts do not include implementation
details.
High-level conceptual schema
Also used as a reference to ensure that all users’ data
requirements are met and do not have conflict.
Entity-Relationship Modeling(ERM) (cont……)
Approach that enables database designers to concentrate on
specifying the properties of the data only. This makes a
conceptual database design easier and good.
After conceptual schema design, the basic data model
operations:
used to specify the high-level user queries and operations w/c
identified during functional analysis.
Serves to confirm the conceptual schema meets all the
identified functional requirements.
Entity-Relationship Modeling(ERM) (cont……)
The next step in the database design is logical design or
data model mapping
in w/c the actual implementation of the database, using
a commercial DBMS such as the relational or the object-
relational database model.
so at this step the conceptual schema is transformed
from the high-level data model into the implementation
data model.
Entity-Relationship Modeling(ERM) (cont……)
The last step is the physical design
at this step internal storage structures, file organizations,
indexes, access paths, and physical design parameters for the
database files are specified.
In parallel with these activities, application programs are
designed and implemented as database transactions
corresponding to the high-level transaction specifications
Entity-Relationship Modeling(ERM) (cont……)
Entity Types, Entity Sets, Attributes, and Keys
Entity-Relationship (ER) Model - describes data as entities,
relationships, and attributes.
Entities and Attributes
Entities and Their Attributes.
The basic object that represents by Entity-Relationship
(ER) Model - is an entity, which is a thing in the real
world with an independent existence.
Entity-Relationship Modeling(ERM) (cont……)
An entity
is may be an object with a physical existence (for ex, a
particular person, car, house, or employee), or
an object with a conceptual existence (for instance, a
company, a job, or a university course).
Each entity
has attributes(i.e particular properties that describe it|). For
example, an EMPLOYEE entity -described by the employee’s
name, age, addresses, salary, and job.
Entity-Relationship Modeling(ERM) (cont……)
A particular entity
will have a value for each of its attributes.
The attribute values - that describe each entity become a
major part of the data stored in the database.
Example Employee entity- has four attributes and their value
of attributes are Alsan, 26, Addis Ababa, 112,5115678
Phone
Age
Address
Name
Employee
Entity-Relationship Modeling(ERM) (cont……)
Several types of attributes in the Entity-Relationship (ER)
Model:
simple versus composite,
single-valued versus multi-valued, and
Stored versus derived.
Entity-Relationship Modeling(ERM) (cont……)
Composite versus Simple (Atomic) Attributes
Composite attributes
Attribute that can be divided into smaller subparts, which
represent more basic attributes with independent meanings.
For example, the Address attribute of the EMPLOYEE
entity can be subdivided into State, Zone, District, City,
and Kebele.
Entity-Relationship Modeling(ERM) (cont……)
Simple or atomic attributes
Attributes that is not divisible.
For example FName, salary, Sex, etc
Single-Valued versus Multi-valued Attributes
Single value attributes
Attribute that have single values for a particular entity.
For example, Age is a single-valued attribute of a person
Entity-Relationship Modeling(ERM) (cont……)
Multi-valued attributes
Attribute that have different a set of values for a particular
entity.
for instance, a Colors attribute for a car, or a College
degrees attribute for a person
Entity-Relationship Modeling(ERM) (cont……)
Stored versus Derived Attributes
Derived attribute
In some cases, two or more attribute values are related.
For example, the Age and Birth date attributes of a person.
For a particular person entity, the value of Age can be determined
from the current date and Birth date of person’s. Hence, the Age
attribute is called a derived. I.e. It derivable from the Birth date
attribute, which is called a stored attribute.
Some attribute values can be derived from related entities.
For example, an attribute Number_of_employees of a DEPARTMENT
entity can be derived by counting the number of employees related to
the department.
Entity-Relationship Modeling(ERM) (cont……)
NULL Values attribute.
In some cases, a particular entity may not have an
applicable value for an attribute.
For ex, the Apartment_number attribute for a single family
home is NULL. I.e. only the address applies to addresses
that apartment buildings and not to other.
Or is used if the value of an attribute for a particular entity
is Unknown or it is not known whether the attribute value
exists.
For ex, if the Homophone attribute of a person is NULL.
Entity-Relationship Modeling(ERM) (cont……)
Complex Attributes.
An attribute that resulted when composite and multi-valued
attributes arbitrarily nested. For example, if a person can
have more than one residence and each residence can have
a single address and multiple phones.
Entity-Relationship Modeling(ERM) (cont……)
Entity Types, Entity Sets, Keys, and Value Sets
Entity Types
A database usually contains similar groups of entities. For example, a
company employing hundreds of employees which share the same
attributes, but each entity has its own value(s) for each attribute.
Describes the schema for a set of entities that share the same
attribute/structure.
Defines a collection of entities that have the same attributes. But each
entity type in the database is described by its name and attributes.
Example, two entity types: EMPLOYEE and COMPANY, and a list of some
of the attributes.
Entity-Relationship Modeling(ERM) (cont……)
Entity set
collection of entities of a particular entity type
example of entity set
EMPLOYEE COMPANY
Name, Age, Salary Name, Headquarters, President
e1 c1
Girma ,55, 4000.00 Birr Microsoft,Addis Ababa,Alsan
e2
Mhamad ,55, 4500.00 Birr
e3 c2
Awash Bank, Hawsa, Tesfaye
Hunde, 45,6000.00 Birr\
.
. .
. .
. .
. .
Entity-Relationship Modeling(ERM) (cont……)
Keys
Attributes/constraint on the entities of an entity type is the
key or uniqueness constraint.
• Constraints whose values are distinct for each
individual entity in the entity set. Or its values can be
used to identify each entity uniquely.
For example, the Name attribute is a key of the COMPANY
entity type because no two companies are allowed to have
the same name.
Simple and composite key attributes
Entity-Relationship Modeling(ERM) (cont……)
Simple key attribute
Is an attribute its values can be used to identify each entity uniquely.
For example an attribute student-ID is used to uniquely identify student.
Entity-Relationship Modeling(ERM) (cont……)
Composite key attributes
An entity type that may have more than one key attribute i.e. such key
attribute may be composite.
For example Flight_ID is a composite key attribute w/c component
attributes Flight_Number and Date. It required to uniquely identify
individual occurrences of Flight
Entity-Relationship Modeling (ERM) (cont……)
Value Sets
Specifies set of values that may be assigned to that attribute for each
individual entity by using the basic data type such as integer, Boolean,
floating, enumeration, etc.
Each simple attribute of an entity type is associated with a value set
(or domain of values), which specifies the set of values that assigned
to the attribute for each individual entity.
For example1, the value set of the Age attribute of EMPLOYEE to be
specify by the set of integer numbers between 16and 70.
Example 2, the value set for the Name attribute to be specify by the
set of strings of alphabetic characters
Entity-Relationship Modeling(ERM) (cont……)
Relationship Types, Relationship Sets, Roles, and Structural Constraints
Relationship
is an association among the instances of one or more entity types.
Relationship Type
Represents an association between objects
Identifies the relationship name and the participating entity types
Identify a meaningful association between (or among) entities.
Is denoted /displayed by a diamond-shape symbol.
Connected to the participating entity types by straight lines
Unary relationship type
Binary relationship type
Ternary relationship type and Recursive relationship types
Entity-Relationship Modeling(ERM) (cont……)
Recursive relationship type
the same entity type participates more than once in the relationship
type
Role names are then necessary to distinguish different roles
Relationship Set:
The current set of relationship instances represented in the database
Each relationship instance in the relationship set associates one
EMPLOYEE entity and one DEPARTMENT entity
The current state of a relationship type
For example, Relationship between EMPLOYEE and DEPARTMENT
Entity-Relationship Modeling(ERM) (cont……)
Role
Participation of an entity type in a relationship type
Each entity type - that participates in a relationship type plays a particular role in the relationship.
Role name signifies such role that a participating entity from the entity type plays in each
relationship.
For example, in the WORKS_FOR relationship types:
• EMPLOYEE plays the role of employee or worker and DEPARTMENT plays the role of department or
employer.
Role name becomes essential for distinguishing the meaning of the role that each participating
entity plays when the same entity type participates in more than one relationship type in different
roles.
Entity-Relationship Modeling(ERM) (cont……)
Structural constraints
Is specify minimum and maximum numbers on the participation of each entity
type in a relationship type
Is the combination of the cardinality ratio and participation constraints.
Cardinality ratio
Specifies maximum number of relationship instances that entity can participate
in
Possible cardinality ratios for binary relationship types are 1:1, 1: N, and M: N.
Participation constraint
Specifies whether existence of entity depends on its being related to another
entity.
Two types, such as: Total and partial Participant
Entity-Relationship Modeling(ERM) (cont……)
Weak entity type
Entity types that do not have key attributes of their own
Do not have identifier of their own.
Its existence depends on some other entity type w/c is
called the identifying or owner entity type.
It has no meaning in the ER diagram without the entity on
which it depends
Displayed by Double Rectangle
But regular entity types are called strong entity types
Entity-Relationship Modeling(ERM) (cont……)
ER Diagrams, Naming Conventions
The end !
Thank you!!!
Chapter 5
The Relational Data Model and the
Relational Algebra
182
Relational Data Model and the Relational Algebra
Relational model
introduced by E. F. Codd in 1970 based on predicate logic and set
theory.
Predicate logic
used extensively in mathematics, provides a framework in which
an assertion (statement of fact) can be verified as either true or
false.
For example, suppose that a student with a student ID S/234/06 is
named Hunde Dhuguma. This assertion can easily be demonstrated
to be true or false. 183
Relational Data Model and the Relational Algebra
Set theory
is a mathematical science that deals with sets, or groups of things, and
is used as the basis for data manipulation in the relational model.
For example, assume that:
set A contains three numbers: 16, 24, and 77 & represented as A (16,
24, and 77).
Set B contains four numbers: 44, 77, 90, and 11, and represented as B
(44, 77, 90, and 11).
Based on this, the intersection of A and B result set with a single
number, 77 which expressed as A _ B = 77. In other words, A and B
share a common value, 77.
184
Relational Data Model and the Relational Algebra (cont...)
Based on these concepts, the relational model has three well-
defined components:
1. A logical data structure represented by relations.
2. A set of integrity rules to enforce that the data are remain
consistent over time.
3. A set of operations that defines how data are manipulated.
185
Relational Data Model and the Relational Algebra (cont...)
Logical view of data
Database stores and manages both data and metadata. i.e. DBMS
manages and controls access to the data and the database structure.
Such an arrangement—placing the DBMS between the application and
the database—eliminates most of the file system’s inherent limitations.
In fact, the database structures required by both the hierarchical and
network database models often become complicated and diminish
efficient database design.
The relational data model changes all of that limitation by allowing the
designer to focus on the logical representation of the data and its
relationships, rather than on the physical storage details.
186
Relational Data Model and the Relational Algebra (cont...)
Relational model enables to view data logically rather than
physically.
Relational database model is much easier to understand than
the hierarchical and network models.
Relational tables and Their Characteristics
Logical view of the relational database is facilitated by the
creation of data relationships based on a logical relation.
Because a relation is a mathematical construct, end users find
it much easier to think of a relation as a table.
187
Relational Data Model and the Relational Algebra (cont...)
Table
Is perceived as a two-dimensional structure composed of rows and
columns.
Also called a relation because the relational model’s creator, E. F.
Codd, used the term relation as a synonym for table.
Is a persistent representation of a logical relation, that is, a relation
whose contents can be permanently saved for future use.
Contains a group of related entity occurrences, that is, an entity set.
For example, a STUDENT table contains a collection of entity
occurrences, each representing a student.
188
Relational Data Model and the Relational Algebra (cont...)
Characteristics of a Relational Table
A table is perceived as a two-dimensional structure composed of
rows and columns.
Each table row (tuple) represents a single entity occurrence within
the entity set.
Each table column represents an attribute, and each column has a
distinct name.
Each row/column intersection represents a single data value.
All values in a column must conform to the same data format.
Each column has a specific range of values known as the attribute
domain.
The order of the rows and columns is immaterial to the DBMS.
Each table must have an attribute or a combination of attributes
that uniquely identifies each row
189
Relational Data Model and the Relational Algebra (cont...)
Ex.
Table name: STUDENT
190
Relational Data Model and the Relational Algebra (cont...)
Sometimes rows are referred to as records and columns as
fields, table as files. Such substitution of terms is not always
appropriate. B/c database table is a logical rather than a
physical concept, and the terms file, record, and field describe
physical concepts.
In the above student table
STUDENT table is perceived to be a two-dimensional
structure composed of three rows (tuples) and seven columns
(attributes).
191
Relational Data Model and the Relational Algebra (cont...)
Each row in the STUDENT table describes a single entity occurrence
within the entity set. (The entity set is represented by the STUDENT
table).
For example, row 3 in student table describes a student named Ebafi
Rabira.
Given the table contents, the STUDENT entity set includes three
distinct entities (rows), or students. Each column represents an
attribute, and each column has a distinct name.
All of the values in a column match the attribute’s characteristics. For
example, the grade point average (STU_GPA) column contains only
STU_GPA entries for each of the table rows.
192
Relational Data Model and the Relational Algebra (cont...)
Data must be classified according to their format and
function. Although various DBMSs can support different data
types, most support at least the following:
Numeric. Numeric data are data on which meaningful
arithmetic procedures perform. For example, in student table
above, STU_HRS and STU_GPA are numeric attributes.
Character. Character data, also known as text data or string
data, can contain any character or symbol not intended for
mathematical manipulation. Example STU_FName and
STU_Class are character attributes.
193
Relational Data Model and the Relational Algebra (cont...)
Logical. Logical data can only have true or false (yes or no) values. In
student table above, the STU_TRANSFER attribute uses a logical data format.
The column’s range of permissible values is known as its domain. Because
the STU_GPA values are limited to the range 0–4, inclusive, the domain is [0,
4].
The order of rows and columns is immaterial to the user.
Each table must have a primary key. In general terms, the primary key (PK)
is an attribute (or a combination of attributes) that uniquely identifies any
given row. In this case, STU_NUM (the student number) is the primary key.
194
Relational Data Model and the Relational Algebra (cont...)
Keys
In the relational model, keys are important b/c 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.
It consists of one or more attributes that determine other attributes. For
example, an invoice number identifies all of the invoice attributes, such as
the invoice date and the customer name.
The key’s role is based on a concept known as determination. In a
database table context, the statement “A determines B” indicates that if the
value of attribute A is know, it is possible to determine the value of attribute
B.
195
Relational Data Model and the Relational Algebra (cont...)
For example, knowing the STU_NUM in the STUDENT
table means possible to determine the FName, grade point
average, DOB, and so on of that student’s.
Shorthand notation for “A determines B” is A → B. If A
determines B, C, and D, writes A → B, C, D.
Therefore, using the attributes of the STUDENT table,
represent the statement “STU_NUM determines
STU_FNAME” by writing:
STU_NUM → STU_FNAME
196
Relational Data Model and the Relational Algebra (cont...)
In fact, the STU_NUM value in the STUDENT table determines all
of the student’s attribute values. For example:
STU_NUM → STU_FNAME, STU_LNAME, STU_DOB,
STU_TRANSFER.
But, STU_NUM is not determined by STU_LNAME because it is
quite possible for several students to have the same name.
The principle of determination is very important because it is used in
the definition of a central relational database concept known as
functional dependence. The term functional dependence can be
defined most easily this way: the attribute B is functionally dependent
on A if A determines B.
197
Relational Data Model and the Relational Algebra (cont...)
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.
The functional dependence definition can be generalized to
cover the case in which the determining attribute values occur
more than once in a table.
198
Relational Data Model and the Relational Algebra (cont...)
Attribute A determines attribute B (that is, B is
functionally dependent on A) if all of the rows in the table
that agree in value for attribute A also agree in value for
attribute B.
More than a single attribute used to define functional
dependence; that is, a key may be composed of more than one
attribute. Such a multi-attribute key is known as a composite
key. Any attribute that is part of a key is known as a key
attribute.
199
Relational Data Model and the Relational Algebra (cont...)
For instance, in the STUDENT table, the student’s Fname
would not be sufficient to serve as a key. On the other hand, the
combination of first name, last name, and other is very likely to
produce unique matches for the remaining attributes.
For example:
STU_FNAME, STU_LNAMESTU_HRS, STU_CLASS
STU_GPA, STU_DOB
Given the possible existence of a composite key, the notion of
functional dependence can be further refined by specifying full
functional dependence:
200
Relational Data Model and the Relational Algebra (cont...)
If the attribute (B) is functionally dependent on a composite
key (A) but not on any subset of that composite key, the
attribute (B) is fully functionally dependent on (A).
Super key is any key that uniquely identifies each row. In short,
the super key functionally determines all of a row’s attributes. Ex.
In the STUDENT table, the super key could be any of the
following:
STU_NUM
STU_NUM, STU_FNAME
201
Relational Data Model and the Relational Algebra (cont...)
In fact, STU_NUM, with or without additional attributes, can be a
super key even when the additional attributes are redundant.
A candidate key can be described as a super key without
unnecessary attributes. Composite key, for example STU_NUM,
STU_LNAME, is a super key, but it is not a candidate key because
STU_NUM by itself is a candidate key. If the student’s Social
Security number included as one of the attributes in the STUDENT
table in above, both STU_SSN and STU_NUM can be candidate
keys because either one
202
Relational Data Model and the Relational Algebra (cont...)
The two is uniquely identify each student. Primary key is the
candidate key chosen to be the unique row identifier. A primary key
is a super key as well as a candidate key.
Within a table, each primary key value must be unique to ensure
that each row is uniquely identified by the primary key. In that case,
the table is said to exhibit entity integrity. To maintain entity
integrity, a null (that is, no data entry at all) is not permitted in the
primary key. So, Nulls can never be part of a primary key. More over
there is a rare case in which nulls cannot be avoided when working
with non-key attributes.
203
Relational Data Model and the Relational Algebra (cont...)
Note: A null is no value at all. It does not mean a zero or a
space. A null is created when press the Enter key or the Tab key
to move to the next entry without making a prior entry of any
kind. In fact, the existence of nulls in a table is often an
indication of poor database design. Nulls, if used improperly, can
create problems because they have many different meanings. For
example, a null can represent:
An unknown attribute value.
A known, but missing, attribute value.
A “not applicable” condition.
204
Relational Data Model and the Relational Algebra (cont...)
Depending on the sophistication of the application
development software, nulls can create problems when
functions such as COUNT, AVERAGE, and SUM are used.
In addition, nulls can create logical problems when relational
tables are linked.
In relational database the table share common attributes
which enable the tables to be linked together.
205
Relational Data Model and the Relational Algebra (cont...)
206
Relational Data Model and the Relational Algebra (cont...)
For example PRODUCT and VENDOR tables in the above
two table share a common attribute via VEND_CODE. A
relational database can also be represented by a relational
schema. A relational schema is a textual representation of the
database tables where each table is listed by its name
followed by the list of its attributes in parentheses. During the
representation of relational database by relational schema the
primary key attribute becomes underlined.
207
Relational Data Model and the Relational Algebra (cont...)
Example
PRODUCT (PROD_CODE, PROD_MANU-DATE, PROD_PRICE,
PROD_EXPIE- DATE)
VENDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE,
VEND_PHONE)
The link between the PRODUCT and VENDOR tables which indicated by the
line represent the relational diagram. And it is equivalent of the relationship line
in an ERD. This link is created when the two tables share an attribute with
common values. I.e. primary key of one table (VENDOR) appears as the
foreign key in a related table (PRODUCT).
208
Relational Data Model and the Relational Algebra (cont...)
A foreign key (FK) is an attribute whose values match the
primary key values in the related table. For example,
VEND_CODE is the primary key in the VENDOR table, and it
occurs as a foreign key in the PRODUCT table. VENDOR table
does not contain foreign key b/c it does not connect with other
table.
209
Relational Data Model and the Relational Algebra (cont...)
If the foreign key contains either matching values or nulls, the table
use of that foreign key is said to bet referential integrity. In other
words, referential integrity means that if the foreign key contains a
value, that value refers to an existing valid tuple (row) in another
relation. For example the referential integrity is maintained between
the PRODUCT and VENDOR tables
Finally, a secondary key is a key that is used strictly for data
retrieval purposes. Suppose customer data are stored in a
CUSTOMER table in which the customer number is the primary key.
210
Relational Data Model and the Relational Algebra (cont...)
Data retrieval for a customer can be facilitated when the
customer’s last name and phone number are used. In this
case, the primary key is the customer number; the secondary
key is the combination of the customer’s last name and
phone number. However, the secondary key does not
necessarily yield a unique outcome. For example, a
customer’s last name and home telephone number could
easily yield several matches where one family lives together
and shares a phone line.
211
Relational Data Model and the Relational Algebra (cont...)
212
Relational Data Model and the Relational Algebra (cont...)
Integrity rules
Relational database integrity rules are very important to good database
design. Summary of integrity rules
213
Relational Data Model and the Relational Algebra (cont...)
214
Relational Data Model and the Relational Algebra (cont...)
215
Relational Data Model and the Relational Algebra (cont...)
Entity integrity: CUS_CODE is primary key in CUSTOMER
table. So, the primary key column has no null entries, and all
entries are unique. Similarly, AGENT_CODE is the primary key
AGENT table, and this primary key column is also free of null
entries.
Referential integrity: AGENT_CODE in the CUSTOMER table
is a foreign key, which links entries in the CUSTOMER table to
the AGENT table. To avoid nulls special codes such as flags is
used to indicate the absence of some value
216
Relational Data Model and the Relational Algebra (cont...)
Other integrity rules are NOT NULL and UNIQUE
constraints that can be enforced in the relational model.
The NOT NULL constraint can be placed on a column
to ensure that every row in the table has a value for that
column.
The UNIQUE constraint is a restriction placed on a
column to ensure that no duplicate values exist for that
column
217
Relational Data Model and the Relational Algebra (cont...)
Relational set operators
The data in relational tables has limited value unless it
manipulated to generate useful information.
Basic data manipulation in the relational model.
Relational algebra defines the way of manipulating table
contents using the eight relational operators: such as SELECT,
PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE,
PRODUCT, and DIVIDE. However, DBMS support some of the
key relational operators such as SELECT, PROJECT, and JOIN.
218
Relational Data Model and the Relational Algebra (cont...)
Using relational algebra operators on existing relations
(tables) produces new relations. For instance:
SELECT produce values for all rows found in a table that
satisfy a given condition. I.e. it can be used to list all of the row
values, or it can yield only those row values that match a
specified criterion. In other words, SELECT yields a horizontal
subset of a table.
PROJECT produces all values for selected attributes. In other
words, PROJECT yields a vertical subset of a table. For more
illustration look the following diagram 1 & 2
219
Relational Data Model and the Relational Algebra (cont...)
220
Relational Data Model and the Relational Algebra (cont...)
221
Relational Data Model and the Relational Algebra (cont...)
UNION combines all rows from two tables, excluding duplicate
rows.
INTERSECT produce only the rows that appear in both tables. It
cannot use if one of the attributes is numeric and one is character.
222
Relational Data Model and the Relational Algebra (cont...)
• Properties of relational databases
– Each row of a table is uniquely identified by a primary key – w/c
composed to one or more columns.
– Each tuple in a relation must be unique
– Group of columns, that uniquely identifies a row in a table is called a
candidate key
– Entity integrity rule of the model- states that no component of the primary
key may contain a null value.
– A column or combination of columns that matches the primary key of
another table is called a foreign key- w/c used to cross-reference tables.
32
Relational Data Model and the Relational Algebra (cont...)
– Referential integrity rule of the model –states that for every
foreign key value in a table there must be a corresponding
primary key value in another table in the database or it
should be null.
– All tables are LOGICAL ENTITIES
– A table is either a BASE TABLES (Named Relations) or
VIEWS (Unnamed Relations)
– Only Base Tables are physically stores
33
Relational Data Model and the Relational Algebra (cont...)
– VIEWS are derived from BASE TABLES with SQL instructions like:
[SELECT .. FROM .. WHERE .. ORDER BY]
– Is the collection of tables
• Each entity in one table
• Attributes are fields (columns) in table
– Order of rows and columns is immaterial (irrelevant).
– Entries with repeating groups are said to be un-normalized
– Entries are single-valued
– Each column (field or attribute) has a distinct name
• All values in a column represent the same attribute and have the same data
format
34
Relational Data Model and the Relational Algebra (cont...)
• Requirements for a table to qualify as a relation
It must have a unique name
Every attribute value must be atomic (not multi-valued, not
composite)
Every row must be unique (can’t have two rows with exactly the
same values for all their fields)
Attributes (columns) in tables must have unique names
The order of the columns must be irrelevant
The order of the rows must be irrelevant
NOTE: all relations are in 1st Normal form
35
The end
Thank you!!
227
Chapter- 4
Database Design, Functional
Dependancy and Normalization
1
Database Design(cont….)
Database design
− is the process of coming up with different kinds of specification for the
data to be stored in the database.
− consists of two parallel activities:
the first activity involves the design of the data content, structure, and
constraints of the database.
the second activity relates to the design of database applications.
• It is one of the middle phases in information systems development where the
system uses a database approach.
• Design is the part which used to describe how the data should be perceived at
different levels and finally how it is going to be stored in a computer system.
2
Database Design(cont….)
Information System with Database application consists of several tasks which
include:-
•Planning of Information systems Design
•Requirements collection & Analysis,
•Design (Conceptual, Logical and Physical Design)
•Testing
•Implementation
•Operation and Support
3
Database Design(cont….)
Out of these, a database system can be focused on the Design part which
further sub divided into three sub-phases. Such as:
1. Conceptual Design
2. Logical Design, and
3. Physical Design
In general, one has to go back and forth between these tasks to refine/
improve a database design. As such like:
4
Database Design(cont….)
In developing a good database design, it needs to answer the following
questions, such as:
What are the relevant Entities for the Organization
What are the important features of each Entity
What are the important Relationships
What are the important queries from the user
What are the other requirements of the Organization and the Users.
5
Database Design(cont….)
Conceptual Database Design
Is the process of constructing a model of the information used in an
enterprise, independent of any physical considerations.
is the source of information for the logical design.
involves two parallel activities
1. The first activity is design conceptual schema w/c examines the data
requirements and produces a conceptual database schema .
2. The second activity is design transaction and application w/c examines
the database applications and produces high-level specifications for
these applications.
6
Database Design(cont….)
Its main goal is to produce a conceptual schema for the database that
is independent of a specific DBMS.
Mostly it uses a high-level data model such as the ER or EER model to
describe the data at this level.
it considered as an iterative refinement process until the most suitable
design is reached.
After the completion of Conceptual Design one has to go for refinement
of the schema, which is verification of Entities, Attributes, and
Relationships.
7
Database Design(cont….)
• Conceptual design revolves around discovering and analyzing
organizational and user data requirements
• The important activities are to identify:
– Entities
– Attributes
– Relationships
– Constraints
• And based on these components develop the ER model using :
– ER diagrams
• (already we discuses those things in chapter
three)
8
Database Design and Normalization
Logical Database Design and Normalization
Logical design
is the process of constructing a model of the information used in an
enterprise based on a specific data model (e.g. relational, hierarchical or
network or object), but independent of a particular DBMS and other
physical considerations.
is the process of map (or transform) the conceptual schema from the
high-level data model into the data model of the chosen DBMS.
Normalization process:
Collection of Rules to be maintained
Discover new entities in the process
Revise attributes based on the rules and the discovered Entities
9
Database Design and Normalization(cont….)
Converting/ mapping ER Diagram to Relational Tables
• Three basic rules to convert ER into tables or relations:-
• Rule 1: Entity Names will automatically be table names.
• Rule 2: Mapping of attributes: attributes will be columns of the respective
tables.
Atomic or single-valued or derived or stored attributes will be columns.
Composite attributes: the parent attribute will be ignored and the
decomposed attributes (child attributes) will be columns of the table.
Multi-valued attributes: will be mapped to a new table where the
primary key of the main table will be posted for cross referencing.
• Rule 3: Relationships: relationship will be mapped by using a foreign key
attribute.
10
Database Design and Normalization(cont….)
• Foreign key is a primary or candidate key of one relation used to create
association between tables.
• For a relationship with One-to-One Cardinality:
– post the primary or candidate key of one of the table into the other as a
foreign key.
• In cases, if one entity is having partial participation on the relationship, it is
recommended to post the candidate key of the partial participants to the total
participant, to save some memory location due to null values on the foreign
key attribute.
• E.g.: for a relationship between Employee and Department where employee
manages a department, the cardinality is one-to-one.
11
Database Design and Normalization(cont….)
• Here the PK of the Employee can be posted to the Department
or the PK of the Department can be posted to the Employee.
• But the Employee is having partial participation on the
relationship "Manages" b/c not all employees are managers of
departments.
• So, it is recommended to post the primary key of the employee
to the department table as a foreign key.
• For a relationship with One-to-Many Cardinality:
– the primary key or candidate key from the “one” side Post
as a foreign key attribute to the “many” side. 12
Database Design and Normalization(cont….)
• E.g.: For a relationship called “Belongs To” between Employee
(Many) and Department (One) the primary or candidate key of
the one side such as the Department should be posted to the many
side which is Employee table.
• – For a relationship with Many-to-Many Cardinality:
– create a new table (which is the associative entity) and
– post primary key or candidate key from the participant entities
as foreign key attributes in the new table along with some
additional attributes.
• The same approach should be used for relationships with degree
greater than binary. 13
Database Design and Normalization(cont….)
• For a relationship having Associative Entity property:
– in cases where the relationship has its own attributes (associative
entity)
• create a new table for the associative entity and
• post primary key or candidate key from the participating entities as
foreign key attributes in the new table.
• Example: to illustrate the major rules in mapping ER to relational schema:
Employee ,Department and Project information.
– Employee: Eid, Name, Salary,Tel.
– Department: Did, Dname, Dloc.
– Project: Pid, Pname, PFund
14
Database Design and Normalization(cont….)
• Employee works for department.
– where an employee might be assigned to manage a department.
– Employee may participate on different projects within the
organization.
– An employee may assigned to lead a project where the starting
and ending date of his/her project leadership and bonus will be
registered.
• So, the relationship become represent by ER –diagram as follows:
15
Database Design and Normalization(cont….)
16
Database Design and Normalization(cont….)
• After drawn the ER diagram, the next step is map the ER into relational
schema, then the rules of the relational data model can be tested for each
relational schema.
• Mapping can be done for the entities followed by relationships based on
the rule of mapping.
it has been done as follows:
• Mapping EMPLOYEE Entity:
– i.e. Employee table with EID, Salary, FName and LName being the
columns.
– The composite attribute Name will be ignored as its decomposed
attributes (FName and LName) are columns in the Employee Table.
– The Tel attribute will be a new table as it is multi-valued.
17
Database Design and Normalization(cont….)
18
Database Design and Normalization(cont….)
• Mapping the MANAGES Relationship:
As the relationship is having one-to-one cardinality, the PK or CK of one
of the table can be posted into the other. But based on the recommendation,
the Pk or CK of the partial participant (Employee) should be posted to the
total participants (Department).
• So, adding the PK of Employee (EID) in the Department Table as a foreign
key. B/c of this another name give to the foreign key which is MEID, mean
"managers employee id".
• this will affect the degree of the Department table as follows:
19
Database Design and Normalization(cont….)
• Mapping the PARTICIPATES Relationship:
As the relationship is having many-to-many cardinality, it
need to create a new table and post the PK or CK of the
Employee and Project table into the new table. B/c of this a
descriptive new name give for the new table like:
• Emp_Partc_Project to mean "Employee participate in a
project".
20
Database Design and Normalization(cont….)
• Mapping the LEADS Relationship:
– As the relationship is associative entity, create a table for the
associative entity where the PK of Employee and Project tables will be
posted in the new table as a foreign key.
• So, the new table will have the attributes of the associative entity as
columns. B/c of this, a descriptive new name give for the new table like
Emp_Lead_Project to mean "Employee participate in a project".
21
Database Design and Normalization(cont….)
• At the end of the mapping, there is the following relational schema (tables)
for the logical design phase.
22
Database Design and Normalization(cont….)
• Example 2
Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)
Combined, these are a composite primary key
(uniquely identifies the order line)…
individually they are foreign keys (implement
M:N relationship between order and product)
23
Database Design and Normalization(cont….)
• Normalization
• Database normalization
– is a series of steps followed to obtain a database design that allows for
consistent data storage and efficient access of data in a relational
database.
– is the process of efficiently organizing data in a database with two
goals
– Such as :-
• to eliminate / reduce data redundancy
– for example, storing the same data in more than one table
• ensure data dependencies
Reduce risk of data becoming inconsistent. 24
Database Design and Normalization(cont….)
• NORMALIZATION
– is the process of identifying the logical associations
between data items and designing a database that will
represent such associations but without suffering the
update anomalies such as:
1. Insertion Anomalies
2. Deletion Anomalies
3. Modification Anomalies
25
Database Design and Normalization(cont….)
• Normalization is a formal process for deciding which attributes should be
grouped together in a relation
• Normalization:
– The process of decomposing unsatisfactory "bad" relations (with
anomalies) by breaking up their attributes into smaller relations.
– Primarily a tool to validate and improve a logical design so that it
satisfies certain constraints that avoid unnecessary duplication of
data
• Normal form:
– Condition using keys and FDs of a relation to certify whether a relation
schema is in a particular normal form
26
Database Design and Normalization(cont….)
• Normalization
– may reduce system performance since data will be cross referenced
from many tables.
– So, de-normalization is sometimes used to improve performance, at
the cost of reduced consistency guarantees.
• All the normalization rules will eventually remove the update anomalies
that may exist during data manipulation after the implementation.
• Update anomalies
– type of problems that occur in insufficiently normalized table.
– includes
27
Database Design and Normalization(cont….)
• Insertion anomalies
– An "insertion anomaly" is a failure to place information about
a new database entry into all the places in the database.
In a properly normalized database, information about a new entry
needs to be inserted into only one place in the database.
• Deletion anomalies
– A "deletion anomaly"
» is a failure to remove information about an existing
database entry when it is time to remove that entry.
In a properly normalized database, information about an old,
to-be-gotten-rid-of entry needs to be deleted from only one
place in the database
28
Database Design and Normalization(cont….)
• Modification anomalies
– A modification of a database involves changing
some value of the attribute of a table.
In a properly normalized database table, whatever
information is modified by the user, the change will
be effected and used accordingly.
• So, the purpose of normalization is to reduce the chances for
anomalies to occur in a database.
• Example of problems related with anomalies.
29
Database Design and Normalization(cont….)
30
Database Design and Normalization(cont….)
• Deletion Anomalies:
If employee with ID 16 is deleted then information about skill C++
and the type of skill is deleted from the database. Then, there is no any
information about C++ and its skill type.
• Insertion Anomalies:
If there is a new employee with a skill called Pascal. Impossible to
decide weather Pascal is allowed as a value for skill and no clue about
the type of skill that Pascal should be categorized as.
• Modification Anomalies:
if the address for Helico is changed from Piazza to Mexico.
It need to look for every occurrence of Helico and change the value of
School_Add from Piazza to Mexico, which is prone to error.
31
Database Design and Normalization(cont….)
Physical Database Design
Physical design
– is the process of choosing specific file storage structures
and access paths for the database files to achieve good
performance for the various database applications.
physical implementation of the upper level design of the
database with respect to internal storage and file structure
of the database for the selected DBMS.
– involves choosing the particular data organization
techniques.
36
Database Design and Normalization(cont….)
– is the process of producing a description of the
implementation of the database on secondary
storage w/c :
• defines specific storage or access methods used by
database that enables to achieve efficient access to the
data and estimate of storage space.
• Describes base relations, file organizations, and indexes
• and design to achieve any associated integrity
constraints and security measures
36
Database Design and Normalization(cont….)
• Consider physical database design from three aspects:
– What techniques for storing and finding data exist.
– Which are implemented within a particular DBMS .
– Which might be selected by the designer for a given application knowing the
properties of the data.
Reason for physical database design is to indicate:
1. How to map the logical database design to a physical database design.
2. How to design base relations for target DBMS.
3. How to design enterprise constraints for target DBMS.
4. How to select appropriate file organizations based on analysis of transactions.
5. When to use secondary indexes to improve performance.
6. How to estimate the size of the database
7. How to design user views
8. How to design security mechanisms to satisfy user requirements.
37
Database Design and Normalization(cont….)
• Physical database design
– is the process of producing a description of the implementation
of the database on secondary storage.
– describes the base relation, file organization, and indexes used
to achieve efficient access to the data, and any associated
integrity constraints and security measures.
Describes the storage structures and access methods used to
achieve efficient access to the data.
– is concerned with the how but Logical database design is
concerned with the what.
– Its Sources of information is logical data model and
documentation that describes model.
38
Database Design and Normalization(cont….)
• Steps in physical database design
1. Three step to translate logical data model for target DBMS
i. Design base relation
ii. Design representation of derived data
iii. Design enterprise constraint
2. Four step to Design physical representation
i. Analyze transactions
ii. Choose file organization
iii. Choose indexes
iv. Estimate disk space and system requirement
39
Database Design and Normalization(cont….)
3. Design user view
4. Design security mechanisms
5. Consider controlled redundancy
6. Monitor and tune the operational system
Translate logical data model for target DBMS
– is emphasized on translation of logical data model to produce a
relational database schema that can be implemented in in the target
DBMS from the logical data model.
– It includes creating data dictionary based on the logical model and
information gathered.
40
Database Design and Normalization(cont….)
– It need to know functionality of target DBMS
• How
– To create base relations
– To define PKs, FKs, and Alternate key
– To required data ( NOT NULL)
– To define Referential integrity constraints
– To define Enterprise constraints
• After the creation of the data dictionary, the next activity is to
understand the functionality of the target DBMS and ensure all
necessary requirements are fulfilled for develop intended
database.
41
Database Design and Normalization(cont….)
– To represent base relations which identified in logical data
model in target DBMS.
For each relation define:
• the name of the relation;
• a list of simple attributes in brackets;
• the PK and appropriate Alternate key and FKs.
• a list of any derived attributes and how they should be
computed;
• referential integrity constraints for any FKs identified.
42
Database Design and Normalization(cont….)
For each column/attribute it need to define:
• its domain, its data type, length and any constraints on the domain;
• an optional default value for the attribute it the attribute can hold
nulls.
– To design Representation of Derived Data
To decide how to represent any derived data of the logical data model
in the target DBMS.
• Produce list of all derived columns / attribute from logical data
model and data dictionary.
• Derived column can be stored in database or calculated every time
it is needed.
43
Database Design and Normalization(cont….)
– Design enterprise constraints
To design enterprise constraints for target DBMS.
• Some DBMS provide more facilities than others for defining enterprise
constraints.
• Example:
CONSTRAINT StaffNotHandlingTooMuch
CHECK (NOT EXISTS (SELECT staffNo
FROM PropertyForRent
GROUP BY staffNo
HAVING COUNT(*) > 100))
Analyze transactions
To understand the functionality of the transactions that run on the database and
to analyze the important transactions.
44
Database Design and Normalization(cont….)
– Attempt to identify :
• transactions that run frequently and will have a significant impact on
performance;
• transactions that are critical to the business;
– It need to know high-level functionality of the transactions, such as:
• attributes that are updated;
• search criteria used in a query.
– To focus on areas that may be problematic:
1. Map all transaction paths to relations.
2. Determine which relations are most frequently accessed by transactions.
3. Analyze the data usage of selected transactions that involve these
relations.
45
Database Design and Normalization(cont….)
Choose file organizations
– To determine an efficient file organization for each base relation.
– File organizations include Heap, Hash, Indexed Sequential Access
Method (ISAM), B+-Tree, and Clusters.
– Some DBMSs may not allow selection of file organizations.
Choose indexes
– To determine whether adding indexes will improve the performance of
the system.
– One approach is to keep tuples unordered and create as many
secondary indexes as necessary.
46
Database Design and Normalization(cont….)
– Another approach is to order tuples in the relation by specifying a
primary or clustering index.
– In this case, choose the attribute for ordering or clustering the tuples as:
• attribute that is used most often for join operations - this makes
join operation more efficient, or
• attribute that is used most often to access the tuples in a relation in
order of that attribute.
– If ordering attribute chosen is key of relation, index will be a primary
index; otherwise, index will be a clustering index.
– Each relation can only have either a primary index or a clustering
index.
– Secondary indexes provide a mechanism for specifying an additional
key for a base relation that can be used to retrieve data more efficiently.
47
Database Design and Normalization(cont….)
• Estimate disk space requirements
– To estimate the amount of disk space that will be required by the
database.
• Design User Views
– To design the user views that were identified during the Requirements
Collection and Analysis stage of the database system development
lifecycle.
• Design Security Measures
– To design the security measures for the database as specified by the
users.
48
Database Design and Functional Dependency
• Functional Dependency (FD)
– Before definition application of normalization, it need understand
"functional dependency."
• Data Dependency
– The logical associations between data items which point database
designer in the direction of a good database design are referred as
determinant or dependent relationships.
• Functional Dependency (FD)
– Two data items A and B are said to be in dependent relationship if
certain values of data item B always appears with certain values of data
item A.
49
Database Design and Functional Dependency(cont….)
– The notation is: A → B which is read as; B is functionally
dependent on A.
– A → B holds if whenever a given tuple has the same value for
A, it must have the same value for B.
– Since the type of Wine provide depends on the type of
Dinner, it is possible to say, Wine is functionally dependent
on Dinner.
» Dinner → Wine
50
Database Design and Functional Dependency(cont….)
• Example 2
Dinner Type of Wine Type of Fork
Meat Red Meat Fork
Fish White Fish Fork
Cheese Rose Cheese Fork
• In general, a functional dependency is a relationship among
attributes. In relational databases, there is a determinant that
governs one other attribute or several other attributes.
• FDs are derived from the real-world constraints on the
attributes
50
Database Design and Functional Dependency(cont….)
• Partial Dependency
– If an attribute which is not a member of the primary key is
dependent on some part of the primary key (if it has
composite primary key) then that attribute is partially
functional dependent on the primary key.
• Example:
– Let {A,B} is the Primary Key and C is no key
attribute.
– Then if {A,B} → C and B --> C
– Then C is partially functional dependent on {A,B}
51
Database Design and Functional Dependency(cont….)
• Full Dependency
– If an attribute which is not a member of the primary key is
not dependent on some part of the primary key but the
whole key (if it has composite primary key) then that
attribute is fully functionally dependent on the primary
key.
• Let {A,B} is the Primary Key and C is no key attribute
• Then if {A,B} → C and B → C and A → C does hold
• Then C Fully functionally dependent on {A,B}.
52
Database Design and Functional Dependency(cont….)
Transitive Dependency
• In mathematics and logic
– a transitive relationship is a relationship of the following form:
• "If A implies B, and if B implies C, then A implies C."
– Example:
• If Mr X is a Human, and if every Human is an Animal, then Mr X must be
an Animal.
• Generalized way of describing transitive dependency is that:
– If A functionally governs B, AND If B functionally governs C, THEN A
functionally governs C . Provided that neither C nor B determines A
– i.e. In normal notation:
53
Database Design and Normalization(cont….)
• Steps in Normalization
– There is various levels or steps in normalization called Normal Forms.
• NB. Level of complexity, strength of the rule and decomposition increases
when move from one lower level Normal Form to the higher.
• A table in a relational database is said to be in a certain normal form if it
satisfies certain constraints.
• Normalization towards a logical design consists of the following steps:
1. Un-normalized Form:
• identify all data elements
54
Database Design and Normalization(cont….)
2. First Normal Form:
• find the key that help to find all data.
3. Second Normal Form:
• remove part-key dependencies. Make all data dependent on the
whole key.
4. Third Normal Form
• remove non-key dependencies. Make all data dependent on nothing
but the key.
55
Database Design and Normalization(cont….)
• First Normal Form (1NF)
– Requires that all column values in a table are atomic.
– (e.g., a number is an atomic value, while a list or a set is not).
– There are two ways of achieving this:-
1. Putting each repeating group into a separate table and
connecting them with a primary key-foreign key relationship.
2. Moving this repeating groups to a new row by repeating the
common attributes.
– If so then Find the key with which you can find all data.
56
Database Design and Normalization(cont….)
• Definition: A table (relation) is in 1NF
– If:
• There are no duplicated rows in the table. Unique
identifier
• Each cell is single-valued (i.e., there are no repeating
groups).
• Entries in a column (attribute, field) are of the same
kind.
• Example for First Normal form (1NF )
57
Database Design and Normalization(cont….)
58
Database Design and Normalization(cont….)
• FIRST NORMAL FORM (1NF)
– Remove all repeating groups.
– Distribute the multi-valued attributes into different rows and
– identify a unique identifier for the relation so it is said a relation in relational database.
59
Database Design and Normalization(cont….)
• Second Normal form 2NF
– No partial dependency of a non key attribute on part of the primary key.
– This will result in a set of relations with a level of Second Normal Form.
– Any table that is in 1NF and has a single-attribute (i.e., a non-composite)
key is automatically also in 2NF.
• Definition: a table (relation) is in 2NF
– If:
• It is in 1NF and
• If all non-key attributes are dependent on the entire primary key. i.e.
no partial dependency.
60
Database Design and Normalization(cont….)
• Example for 2NF:
• Business rule: Whenever an employee participates in a project, he/she will be
entitled for an incentive.
• This schema is in its 1NF since we don’t have any repeating groups or
attributes with multi-valued property.
• To convert it to a 2NF
– it need to remove all partial dependencies of non-key attributes on part
of the primary key.
61
Database Design and Normalization(cont….)
– {EmpID, ProjNo} -->EmpName, ProjName, ProjLoc,
ProjFund, ProjMangID, Incentive.
• But in addition to this we have the following dependencies:
– FD1: {EmpID}--> EmpName
– FD2: {ProjNo}--> ProjName, ProjLoc, ProjFund,
ProjMangID
– FD3: {EmpID, ProjNo} -->Incentive
• some non-key attributes are partially dependent on some part
of the primary key.
62
Database Design and Normalization(cont….)
– This can be witnessed by analyzing the first two functional
dependencies (FD1 and FD2).
– Thus, each Functional Dependencies, with their dependent
attributes should be moved to a new relation where the
Determinant will be the Primary Key for each.
63
Database Design and Normalization(cont….)
• Third Normal Form (3NF )
– Eliminate Columns Dependent on another non-Primary Key.
– If attributes do not contribute to a description of the key, remove
them to a separate table.
– This level avoids update and delete anomalies.
• Definition: a Table (Relation) is in 3NF
– If :
• It is in 2NF and
• There are no transitive dependencies between a primary key and
non-primary key attributes.
64
Database Design and Normalization(cont….)
• Example for (3NF)
– Assumption: Students of the same batch (the same year) live in one
building or dormitory.
65
Database Design and Normalization(cont….)
– This schema is in its 2NF since the primary key is a single attribute.
– Let’s take StudID, Year and Dormitory and see the dependencies.
– StudID --> Year AND Year Dormitary
• And Year can not determine StudID and
• Dormitary can not determine StudID Then transitively StudID-->
Dormitory
• To convert it to a 3NF we need to remove all transitive dependencies of
non key attributes on another non-key attribute.
• The non-primary key attributes, dependent on each other will be moved to
another table and linked with the main table using Candidate Key- Foreign
Key relationship.
66
Database Design and Normalization(cont….)
67
Database Design and Normalization(cont….)
• Generally, even though there are other four additional levels of
Normalization, a table is said to be normalized if it reaches 3NF.
• A database with all tables in 3NF is said to be Normalized Database.
• Mnemonic for remembering the underlying principle for normalization up
to 3NF can be the following:-
– No Repeating or Redundancy: no repeating fields in the table.
– The Fields Depend Upon the Key: the table should solely depend on
the key.
– The Whole Key: no partial key dependency.
– And Nothing But The Key: no inter data dependency.
– So Help Me Codd: since Codd came up with these rules.
68
Database Design and Normalization(cont….)
• Graphical illustration of different phases of normalization
69
Database Design and Normalization(cont….)
• Benefits of Normalization
– Less storage space
– Quicker updates
– Less data inconsistency
– Clearer data relationships
– Easier to add data
– Flexible Structure
70
Database Design and Normalization(cont….)
• Drawbacks of Normalization
– Requires data to see the problems
– May reduce performance of the system
– Is time consuming,
– Difficult to design and apply and
– Prone to human error
70
The end
Thank you!!!
71
Lab (chapter -6)
SQL
(structured Query Language)
1
Introduction to SQL
SQL
– is a query Language w/c provides a higher-level declarative language
interface. Or
– Is a query language that allows users to specify the conditions.
– used for storing & managing data in RDBMS
It is the standard language for commercial RDBMSs.
– enables a user to create, read, update and delete relational databases
and tables.
All RDBMS like MySQL, Oracle, MS Access and SQL Server use
SQL as their standard database language.
– allows a users to query the database in a numbers of ways
2
Introduction to SQL(cont……)
Query is a user request to retrieve data or information with a
certain condition
When user wants to get some information from db file,
they can issue a query by specifies certain condition. Then
the program searching all records in the db file and select
those records that satisfy the condition. Finally the result of
the query stored in the form of a table.
3
Introduction to SQL(cont……)
SQL query
– includes references to tuples variables and the attributes of those
variables
– is a comprehensive database language that includes statements for data
definition, queries, updates, constraint specification, and view
definition.
. Hence, it is both a DDL and a DML
i.e. It includes
data definition language (DDL) – which is statements that specify and
modify database schemas.
data manipulation language (DML)- which is statements that
manipulate database content.
3
Introduction to SQL(cont…)
• Also it has facilities for defining views on the database, for
specifying security and authorization, for defining integrity
constraints, and for specifying transaction controls.
• It also has rules for embedding SQL statements into a general-
purpose programming language such as Java, COBOL, C# or
C/C++.
• Generally SQL and its variations have been implemented as
interfaces to many commercial relational DBMSs, including
Microsoft’s SQL Server and Access, Oracle’s and Relational db.
4
Introduction to SQL(cont…)
SQL
uses the terms table, row, and column w/c correspond to
relation, tuple, and attribute for the formal relational
model.
The main SQL command for data definition is:
CREATE TABLE: used to create a table.
ALTER TABLE: modifies a table after it was created.
DROP TABLE: removes a table from a database.
5
Introduction to SQL(cont…)
CREATE TABLE Statement
Things to consider before create table are:
type of data
table name
what column(s) will make up the primary key
names of the columns
CREATE statement syntax:
• CREATE TABLE <table name>
• ( field1 datatype ( NOT NULL ),
• field2 datatype ( NOT NULL )
• );
6
SQL: Attributes Types
7
Introduction to SQL(cont…)
ALTER TABLE Statement
To add or drop columns on existing tables.
ALTER TABLE statement syntax:
• ALTER TABLE <table name>
• ADD attr datatype;
• or
• DROP COLUMN attr;
8
Introduction to SQL(cont…)
• DROP TABLE Statement
– Has two options:
CASCADE: Specifies that any foreign key constraint violations that
are caused by dropping the table will cause the corresponding
rows of the related table to be deleted.
RESTRICT: blocks the deletion of the table of any foreign key
constraint violations would be created.
• DROP TABLE statement syntax:
• DROP TABLE <table name> [ RESTRICT|CASCADE ];
9
Introduction to SQL(cont…)
• Example:
FoodCart
• CREATE TABLE FoodCart (
• date varchar(10), date food profit
• food varchar(20),
• profit float
• ); FoodCart
• ALTER TABLE FoodCart ( date food profit sold
• ADD sold int
• );
FoodCart
• ALTER TABLE FoodCart(
• DROP COLUMN profit date food sold
• );
• DROP TABLE FoodCart;
10
Introduction to SQL(cont…)
DML Commands
INSERT: adds new rows to a table.
UPDATE: modifies one or more attributes.
DELETE: deletes one or more rows from a table.
11
Introduction to SQL(cont…)
INSERT Statement
To insert a row into a table, it is necessary to have a value for each attribute, and
order matters.
INSERT statement syntax:
• INSERT into <table name>
• VALUES ('value1', 'value2', NULL);
Example: INSERT into FoodCart
VALUES (’02/26/08', ‘pizza', 70 );
Food chart
date food sold date food sold
02/25/08 Pizza 350 02/25/08 Pizza 350
02/26/08 Sandwich 500 02/26/08 Sandwich 500
02/26/08 Pizza 70
12
Introduction to SQL(cont…)
UPDATE Statement
To update the content of the table:
• UPDATE statement syntax:
– UPDATE <table name> SET <attr> = <value>
– WHERE <selection condition>;
• Example: UPDATE FoodCart SET sold = 349
WHERE date = ’02/25/08’ AND food = ‘pizza’;
• Food cart
date food sold date food sold
02/25/08 Pizza 350 02/25/08 Pizza 349
02/26/08 Sandwich 500 02/26/08 Sandwich 500
02/26/08 Pizza 70 02/26/08 Pizza 70
13
Introduction to SQL(cont…)
DELETE Statement
To delete rows from the table:
• DELETE statement syntax:
– DELETE FROM <table name>
– WHERE <condition>;
• Example: DELETE FROM FoodCart
WHERE food = ‘Sandwich’;
• Food cart
date food sold
02/25/08 Pizza 349 date food sold
02/26/08 Sandwich 500 02/25/08 Pizza 349
02/26/08 Pizza 70 02/26/08 Pizza 70
• Note: If the WHERE clause is omitted all rows of data are deleted from the
table.
14
Introduction to SQL(cont…) SQL
SQL - Statements, Operations, Clauses
SQL Statements:
Select
SQL Operations:
Join
Left Join
Right Join
Like
SQL Clauses:
Order By
Group By
Having 15
Introduction to SQL(cont…)
SELECT Statement
A basic SELECT statement includes 3 clauses
• SELECT <attribute name> FROM <tables> WHERE <condition>
• SELECT
– Specifies the attributes that are part of the resulting relation
• FROM
– Specifies the tables that serve as the input to the statement
• WHERE
– Specifies the selection condition, including the join condition.
• Note: that you don't need to use WHERE
16
Introduction to SQL(cont…)
SELECT Statement
Using a “*” in a select statement indicates that every attribute of the input
table is to be selected.
• Example: SELECT * FROM … WHERE …;
To get unique rows, type the keyword DISTINCT after SELECT.
• Example: SELECT DISTINCT * FROM … WHERE …;
17
• Example:
• Person 2) SELECT weight FROM person
WHERE age > 30;
Name Age Weight Weight
Harry 34 80 80
Sally 28 64 54
George 29 70
80
Helena 54 54
Peter 34 80
1) SELECT * 3) SELECT distinct weight
FROM person FROM person
WHERE age > 30; WHERE age > 30;
Name Age Weight Weight
Harry 34 80 80
Helena 54 54 54
Peter 34 80
18
Introduction to SQL(cont…)
Join operation
A join can be specified in the FROM clause which list the two input
relations and the WHERE clause which lists the join condition.
Example:
Emp Dept
ID State ID Division
1000 CA 1001 IT
1001 MA 1002 Sales
1002 TN 1003 Biotech
19
Introduction to SQL(cont…)
Join operation
inner join = join
SELECT *
FROM emp join dept (or FROM emp, dept)
on emp.id = dept.id;
Emp.ID Emp.State Dept.ID Dept.Division
1001 MA 1001 IT
1002 TN 1002 Sales
20
Introduction to SQL(cont…)
Join operation
left outer join = left join
SELECT *
FROM emp left join dept
on emp.id = dept.id;
Emp.ID Emp.State Dept.ID Dept.Division
1000 CA null null
1001 MA 1001 IT
1002 TN 1002 Sales
21
Introduction to SQL(cont…)
Join operation
right outer join = right join
SELECT *
FROM emp right join dept
on emp.id = dept.id;
Emp.ID Emp.State Dept.ID Dept.Division
1001 MA 1001 IT
1002 TN 1002 Sales
null null 1003 Biotech
22
Introduction to SQL(cont…)
Like operation
Pattern matching selection
% (arbitrary string)
SELECT *
FROM emp
WHERE ID like ‘%01’;
finds ID that ends with 01, e.g. 1001, 2001, etc
23
Introduction to SQL(cont…)
_ (a single character)
SELECT *
FROM emp
WHERE ID like ‘_01_’;
finds ID that has the second and third character as 01, e.g. 1010,
1011, 1012, 1013, etc
24
Introduction to SQL(cont…)
• The ORDER BY Clause
Ordered result selection
desc (descending order)
SELECT *
FROM emp
order by state desc
puts state in descending order, e.g. TN, MA, CA
25
Introduction to SQL(cont…)
asc (ascending order)
SELECT *
FROM emp
order by id asc
puts ID in ascending order, e.g. 1001, 1002, 1003
26
Introduction to SQL(cont…)
The GROUP BY Clause
The function to divide the tuples into groups and returns an aggregate for
each group.
Usually, it is an aggregate function’s companion
• SELECT food, sum(sold) as total Sold
• FROM FoodCart
• group by food;
• FoodCart
date food sold food Total sold
•
02/25/08 Pizza 349 Sandwich 500
02/26/08 Sandwich 500 Pizza 419
02/26/08 Pizza 70
27
Introduction to SQL(cont…)
The HAVING Clause
The substitute of WHERE for aggregate functions
Usually, it is an aggregate function’s companion
SELECT food, sum(sold) as totalSold
FROM FoodCart
group by food
having sum(sold) > 450;
• FoodCart
date food sold food Total sold
•
02/25/08 Pizza 349 Sandwich 500
02/26/08 Sandwich 500
02/26/08 Pizza 70
28
Introduction to SQL(cont…)
• Aggregate Functions
• Are used to provide summarization information for SQL statements,
which return a single value.
COUNT(attr)
SUM(attr)
MAX(attr)
MIN(attr)
AVG(attr)
• Note: when using aggregate functions, NULL values are not
considered, except in COUNT(*) .
29
Introduction to SQL(cont…)
• Food cart
date food sold
02/25/08 Pizza 349
02/26/08 Sandwich 500
02/26/08 Pizza 70
COUNT(attr) -> return # of rows that are not null
Ex: COUNT(distinct food) from FoodCart; -> 2
SUM(attr) -> return the sum of values in the attr
Ex: SUM(sold) from FoodCart; -> 919
MAX(attr) -> return the highest value from the attr
Ex: MAX(sold) from FoodCart; -> 500
30
Introduction to SQL(cont…)
• Food cart
date food sold
02/25/08 Pizza 349
02/26/08 Sandwich 500
02/26/08 Pizza 70
MIN(attr) -> return the lowest value from the attr
Ex: MIN(sold) from FoodCart; -> 70
AVG(attr) -> return the average value from the attr
Ex: AVG(sold) from FoodCart; -> 306.33
Note: value is rounded to the precision of the datatype
31
The end
Thank you!!!
32
You might also like
- Information Technology: "Student Management System"No ratings yetInformation Technology: "Student Management System"18 pages
- Group Assignment - Formal Language TheoryNo ratings yetGroup Assignment - Formal Language Theory8 pages
- Project Proposal: (Property Management System)100% (1)Project Proposal: (Property Management System)12 pages
- Introduction To Data Management: Chapter 1, Pratt & Adamski100% (1)Introduction To Data Management: Chapter 1, Pratt & Adamski25 pages
- Chapter 2-Simple Searching and Sorting Algorithms100% (1)Chapter 2-Simple Searching and Sorting Algorithms21 pages
- Computer Architecture and Organization Chapter 1No ratings yetComputer Architecture and Organization Chapter 164 pages
- What Is Not Data Mining - Ex: Generation of Attendance Report (Of A Course) From Registration Cards. - Student Table (STD)No ratings yetWhat Is Not Data Mining - Ex: Generation of Attendance Report (Of A Course) From Registration Cards. - Student Table (STD)33 pages
- CSC 101-CSC 111 - Introduction To Computer Science - Lecture 4100% (1)CSC 101-CSC 111 - Introduction To Computer Science - Lecture 429 pages
- Prepared By: CS8661 Internet Programming Lab ManualNo ratings yetPrepared By: CS8661 Internet Programming Lab Manual89 pages
- Design and Implementation of Movie Reservation SystemNo ratings yetDesign and Implementation of Movie Reservation System103 pages
- Chapter One: Introduction To Object-Oriented ProgrammingNo ratings yetChapter One: Introduction To Object-Oriented Programming16 pages
- Assosa University College of Computing and Informatics Department of Computer ScienceNo ratings yetAssosa University College of Computing and Informatics Department of Computer Science22 pages
- Mettu University: Fundamental of Database SystemNo ratings yetMettu University: Fundamental of Database System30 pages
- TTLM - M11 Complete Database Bachup and RecoveryNo ratings yetTTLM - M11 Complete Database Bachup and Recovery73 pages
- Source Code Program in C For Relocation Loader100% (2)Source Code Program in C For Relocation Loader6 pages
- Network Device and Configuration ManualNo ratings yetNetwork Device and Configuration Manual128 pages
- Supermarket Management DataBase System Group11 ProjectNo ratings yetSupermarket Management DataBase System Group11 Project12 pages
- Fundamentals of Database System - Module - CHapter - One100% (1)Fundamentals of Database System - Module - CHapter - One19 pages
- School of Informatics and Electrical Engineering: Hachalu Hundessa CampusNo ratings yetSchool of Informatics and Electrical Engineering: Hachalu Hundessa Campus12 pages
- Pulkit Dhakar 18BCON697 Salesforce PracticalNo ratings yetPulkit Dhakar 18BCON697 Salesforce Practical93 pages
- Operating Manual: Mic+ Ultrasonic Sensors With One Analogue OutputNo ratings yetOperating Manual: Mic+ Ultrasonic Sensors With One Analogue Output3 pages
- Function of Local Assessment Operations Officer IIINo ratings yetFunction of Local Assessment Operations Officer III4 pages
- Wireless Transmission of Audion & Data Using LaserNo ratings yetWireless Transmission of Audion & Data Using Laser60 pages
- 2.1 Extended Lesson Plan Introduction To Engineering Design ProcessNo ratings yet2.1 Extended Lesson Plan Introduction To Engineering Design Process14 pages
