ER Model & Relational Model

ER modeling
• ER modeling: A graphical technique for understanding and organizing the data
independent of the actual database implementation.

• Entity: Any thing that may have an independent existence and about which we
intend to collect data.
Also known as Entity type. E.g.: Trainee

• Entity instance: a particular member of the entity type e.g. a particular trainee

• Attributes: Properties/characteristics that describe entities.eg: Trainee name,

Batchname, DOB, Address, etc.

• Relationships: Associations between entities.E.g.: Trainee belongs to a Batch

 Attributes
• The set of possible values for an attribute is called the domain of the attribute
Example:
– The domain of attribute marital status is having four values: single, married, divorced or
widowed.

– The domain of the attribute month is having twelve values ranging from January to
December.

• Key attribute: The attribute (or combination of attributes) that is unique for
every entity instance
– E.g.: the account number of an account, the employee id of an employee etc.

• If the key consists of two or more attributes in combination, it is called a

composite key
 Simple Vs composite attribute
• Simple attribute: cannot be divided into simpler components
E.g.: age of an employee

• Composite attribute: can be split into components

E.g.: Date of joining of the employee.
– Can be split into day, month and year
 Single Vs Multi-valued Attributes
• Single valued : can take on only a single value for each entity instance
E.g.: age of employee. There can be only one value for this.

• Multi-valued: can take up many values

E.g.: skill set of employee
 Stored Vs Derived attribute
• Stored Attribute: Attribute that need to be stored permanently.
• E.g.: name of an employee

• Derived Attribute: Attribute that can be calculated based on other

attributes.

• E.g. : years of service of employee can be calculated from date of joining

and current date
 Regular Vs. Weak entity type
• Regular Entity: Entity that has its own key attribute
(s).

E.g.: Employee, student ,customer, policy holder etc.

• Weak entity: Entity that depends on other entity for

its existence and doesn’t have key attribute (s) of its
own

E.g. : spouse of employee

 Entity-Relationship Model
• Example of an entity-relationship diagram
Record based data model – Relational data
model
 Relational model basics
• Data is viewed as existing in two dimensional tables known as relations

• A relation (table) consists of unique attributes (columns) and tuples (rows)

• Tuples are unique

• Sometimes the value to be inserted into a particular cell may be unknown, or it

may have no value. This is represented by a NULL

• Null is not the same as zero, blank or an empty string

• Relational Database: Any database whose logical organization is based on relational

data model.
• RDBMS: A DBMS that manages the relational database.
 Keys
• Candidate key
A Candidate key is a set of one or more attributes(minimal) that can uniquely
identify a row in a given table.
• Primary Key
During the creation of the table, the Database Designer chooses one of the
Candidate Key from amongst the several available, to uniquely identify row in
the given table.
• Alternate Key
The candidate key that is chosen to perform the identification task is called the
primary key and the remaining candidate keys are known as alternate keys.
No of Alternate Keys = No of Candidate Keys - 1
• Super Key
Any superset of a candidate Key is a super key.
 Key and Non-key Attributes
• Key Attributes
The attributes that participate in the Candidate key are Key Attributes

• Non-Key Attributes
– The attributes other than the Candidate Key
attributes in a table/relation are called Non-Key
attributes.
OR
– The attributes which do not participate in the
Candidate key.
 Example
Given a relation
Trainee(Empno, FirstName, LastName, Email, PhoneNo)

Candidate key:
{Empno},{Email},{PhoneNo},{FirstName,LastName}

Primary key:
{Empno}

Alternate Key:
{Email},{PhoneNo},{FirstName,LastName}

Super Key:
{Empno},{Empno,PhoneNo},{Email,FirstName}, etc…
 Foreign Key
• Foreign key
• A Foreign Key is a set of attribute (s) whose values are required to match values of a column in
the same or another table.

DEPT EMP
(Parent /Master/Referenced Table) (Child /Referencing Table)
•
Dept No Dept Name
Emp No Emp Name Edept No
D1 CSE 1 rajni D1

• Point to remember
– Foreign key values do not (usually) have to be unique.
– Foreign keys can also be null .
• Points to remember
– A Foreign Key is a set of attributes of a table,
whose values are required to match values of
some Candidate Key in the same or another table
– The constraint that values of a given Foreign Key
must match the values of the corresponding
Candidate Key is known as Referential constraint
– A table which has a Foreign Key referring to its
own Candidate Key is known as Self-Referencing
table
 E.F Codds Rules
• Codd's 12 rules
• Codd's 12 rules are a set of thirteen rules (numbered zero to
twelve) proposed by Edgar F. Codd, a pioneer of the
relational model for databases, designed to define what is
required from a database management system in order for it
to be considered relational, i.e., an relational database
management system RDBMS.[1][2] They are sometimes jokingly
referred to as "Codd's Twelve Commandments".
 E.F Codds Rules
• Rule 0: The system must qualify as relational, as a database,
and as a management system.
• For a system to qualify as a relational database management
system (RDBMS), that system must use its relational facilities
(exclusively) to manage the database.
• Rule 1: The information rule:
• All information in the database is to be represented in one
and only one way, namely by values in column positions
within rows of tables.
 E.F Codds Rules
•Rule 2: The guaranteed access rule:
•All data must be accessible. This rule is essentially a restatement of the fundamental
requirement for primary keys. It says that every individual scalar value in the database must be
logically addressable by specifying the name of the containing table, the name of the
containing column and the primary key value of the containing row.
•Rule 3: Systematic treatment of null values:
•The DBMS must allow each field to remain null (or empty). Specifically, it must support a
representation of "missing information and inapplicable information" that is systematic,
distinct from all regular values (for example, "distinct from zero or any other number", in the
case of numeric values), and independent of data type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.
• Rule 4: Active online catalog based on the relational model:
•The system must support an online, inline, relational catalog that is accessible to authorized
users by means of their regular query language. That is, users must be able to access the
database's structure (catalog) using the same query language that they use to access the
database's data.
 E.F Codds Rules
•Rule 5: The comprehensive data sublanguage rule:
•The system must support at least one relational language that Has a linear syntax
•Can be used both interactively and within application programs,
•Supports data definition operations (including view definitions), data manipulation
operations (update as well as retrieval), security and integrity constraints, and
transaction management operations (begin, commit, and rollback).
•Rule 6: The view updating rule:
•All views that are theoretically updatable must be updatable by the system. Rule 7:
High-level insert, update, and delete:
•The system must support set-at-a-time insert, update, and delete operators. This
means that data can be retrieved from a relational database in sets constructed of data
from multiple rows and/or multiple tables. This rule states that insert, update, and
delete operations should be supported for any retrievable set rather than just for a
single row in a single table.
•
 E.F Codds Rules
• Rule 8: Physical data independence:
• Changes to the physical level (how the data is stored, whether
in arrays or linked lists etc.) must not require a change to an
application based on the structure.
• Rule 9: Logical data independence:
• Changes to the logical level (tables, columns, rows, and so on)
must not require a change to an application based on the
structure. Logical data independence is more difficult to
achieve than physical data independence.
 E.F Codds Rules
• Rule 10: Integrity independence:
• Integrity constraints must be specified separately from application programs
and stored in the catalog. It must be possible to change such constraints as
and when appropriate without unnecessarily affecting existing applications.
Rule 11: Distribution independence:
• The distribution of portions of the database to various locations should be
invisible to users of the database. Existing applications should continue to
operate successfully : when a distributed version of the DBMS is first
introduced; and
• when existing distributed data are redistributed around the system.
• Rule 12: The nonsubversion rule:
• If the system provides a low-level (record-at-a-time) interface, then that
interface cannot be used to subvert the system, for example, bypassing a
relational security or integrity constraint.