Database Fundamentals: ER Modeling and Conceptual Design

Introduction to database management system
Database : data is stored in digital form.
CONCEPTUAL DESIGN USING ER( ENTITY RELATIONSHIP) MODEL
Fundamentals component of today database is tables.
Why do we need ER modeling ?
Database is embedded in information application
UOD
DATABASE REQUIREMENTS FUNCTIONAL REQUIREMENT
REQUIRMENTS/COLLECTON AND ANALYSIS


UOD : (universe of discourse) The portion of the real world relevant to the
database is sometimes referred to as the universe of discourse or as the database
mini world.

Requirements and collection and then analysis: in this we basically do requirement
analysis and finding the types of entity and their rules and relations with other
entity. That gives two types of requirements.

1. database requirement : we can say its data requirement. It is handled by the
DBMS. DBMS is called as engine. We need layering around this engine and this
layering is called as information application like a car which surrounds the engine.

2. functional requirement: this helps in the design of the application.

Theses are the DBMS independent process means that it does not depend whether
we are using the oracle database or IBM database type or MYSQL database or
whatever database we are using we have to understand UOD and come out with the
conceptual schema.

Database requirement → conceptual design → conceptual schema

Functional requirement → functional analysis → high level transaction
specification


The above design is the DBMS dependent process because the physical
organization of data in ORACLE and IBM may be different. That means they have
different access mechanism. This physical organization of data is called internal
schema.

Even the transaction will also be affected by the physical organization of the data.

Thus we programmer must know the physical organization of the data.
Physical
design
Conceptual
schema
Internal
schema
High level
Transaction
specification
Application
program
design
Transaction
implementation
software

Conceptual schema

It is the outcome of the high level conceptual design of the database. For this we
have to understand the UOD that is what can kind of data should be taken in the
UOD. Example of banking, in this there are accounts, customer or account holders
and there can some form of the monetary transaction. All these represent some
form of the data. Thus we will identify the relationship among the customer or
accounts entity etc. thus it includes the description of entity types. There can
certain constraint which can be imposed by the system( bank balance cannot be <
500) or the UOD ( like two trains have the arrival time same at the same plateform
number).

There is no implementation detail mentioned. We are not worried about how this
conceptual schema will implement.

The main behind conceptual design is ease of understanding. Thus the end user
( non technical users) must understand the conceptual schema.

Example of COMPANY database

Department : name , Did, ….

Department is the entity and name , Did are the attributes of the entity department.

Standard notation of representing entity and attributes

An entity represents an object of the real world that has the independent existence.
The independent existence means that the entity is independent of every other
entity in the system.

An entity has attributes – properties that describe it.

Kinds of attributes :

a. Simple attributes : it is the single attribute which defines its own characterstics.
Example like age attribute. No further decomposition can be possible.

b. Composite attributes : it is made up of two or more simple attributes of
composite attributes. Example name consist of first name and middle name and last
name.
Department
depart_name dept_id Manager


Single value attribute : A single valued attribute is one that holds a single value for
a single entity. Example: roll_number, name etc.

Multivalued attribute : Multivalued attribute is one that holds multiple values for a
single entity. Example: degree behold by a person (MS, PhD).

How multivalued attribute different from the composite attribute ?

Ans : a composite attribute is made of sub attributes like name is made up of first ,
middle and last name and all of them need not be the same type that is all of them
do not have the same value at the same time whereas the multivalued attribute say
color of the peacock have different values of color at the same.

Stored attribute : the attribute which just stored in the database. Example ,
datofbirth, we just give the date of birth to the system and stored in the system.

Derived attribute: the attribute whose value can be inferred from the value of the
other attribute. Example age is the derived attribute , given the date of birth minus
today dates gives the age of the attribute.

Null attributes : attributes that do not have applicable values are said to have null
values. A null value is different from 0 , missing value or unknown.

Entity types and Entity sets

An entity type defines a collection of different entities having the same type.
Example “department” of the company. A company consist of different
departments. But all of them have the same number of attributes or same attribute
structure. Thus entity type is a collection of all the different departments of the
company.

Any specific collection of entities of a particular type is called an entity set. For
example the entity set employee (all employees of a bank) and the entity set
customer (all customers of the bank).

An entity type describes the schema of the entity set.

Key attribute: the attribute which uniquely identifies the entity in the entity set.

Composite key : a collection of the attributes define the key, the set is called as
composite key.

A composite key should be minimal. No subset of the composite key should be
minimal.

Weak entity type: the entity type foe which we cannot define the key attributes.
For this type of entity, all the tuples have to totally participate in the relationship.

Domain of attributes

Domain of attributes basically defines the space in which the values of the specific
attribute lies. Example age can be lie between 1 to 70 or 80 but can never be
negative.

If the composite attribute have the value d1 , d2, …. then its domain id d1xd2x....
that is cartsisan product of the domains of individual attributes.

Relationship types relate two or more entity types and defines the relationship set.
Any given depiction of a relationship type is called as relation ship instance.

A relationship type of R defines the set of an association among the entity types.

Degree of relationship type : the number of the participating entity types in the
relationship type. There can be unary , ternary and binary relationship type.


Constraint on the relationship type: constraint which limit the possible
combination of entities that can participate in the relationship type.

Two types of the constraint on the relationship type:
cardinality ratio: N:1 , this means that the department can have any number of the
employees but the employee can only work for one department.
Participation constraint: M:N if every project has to be associated with a
department, then the “existence” of an instance of project entity type depends on the
existence of an instance of the handle relationship types. Total participation is
represented by double line.
Employee DepartmentWorks for
Departme
nt
Projecthandles

Attribute of the relationship type

Budget neither belongs to the department nor project. It just specifies the
budget of each of the project with respect to specific department.
Relationship attribute can be moved to one of the entity types.
Departme
nt
Projecthandles
Budget
Departme
nt
Projecthandles
Budget

Identifying relationships

Insurance record is a “weak entity set” which has no existence without its
association with the employee entity. The relationship insurance details is an
identifying relationship instance. The key of the employee will defines the
insurance record entity type. Not all the total participation relationship type
represents and identifying relationships. Example project and department
Employee Insurance
record
Insurance
details
PAN

Database Fundamentals: ER Modeling and Conceptual Design

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Database Fundamentals: ER Modeling and Conceptual Design

Similar to Database Fundamentals: ER Modeling and Conceptual Design (20)

Recently uploaded

Recently uploaded (20)

Database Fundamentals: ER Modeling and Conceptual Design