Chapter 3 Fundamentals of database System GTC 2014 E.

Chapter 3: Database Modeling

3.1.The Entity Relationship (ER) Model

3.1.1. The high-level conceptual model

 An entity-relationship model (ERM) is a model that provides a high-level description of a

conceptual data model.
 Data modeling that provides a graphical notation for representing such data models in the
form of entity-relationship diagrams (ERD).
 The whole purpose of ER modeling is to create an accurate reflection of the real world in a
database.
 The ER model doesn’t actually give us a database description. It gives us an intermediate
step from which it is easy to define a database.
 The E-R data model is based on a perception of a real world that consists of a set of basic
objects called entities. And of relationships among these objects.
 It was developed to facilitate database design by allowing the specification of an enterprise
schema, which represents the overall logical structure of a database.
 The E-R model is extremely useful in mapping the meanings and interactions of real-world
enterprises onto a conceptual scheme. Because of this utility, many database design tools
draw on concepts from the E-R model.
 A data model in which information stored in the database is viewed as sets of entities and
sets of relationships among entities. .
 There are three basic notions that the ER Model employs: entity sets, relationships, and
attributes.
3.1.2. Entities, Attributes, and Keys

Entities
 An entity is a thing or object in Real world.
 The entities (persons, places, things etc.) which the organization has to deal with.
Relations can also describe relationships.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 The name given to an entity should always be a singular noun descriptive of each
item to be stored in it. E.g.: student, NOT students.
 Every relation has a schema, which describes the columns, or fields, the relation itself
corresponds to our familiar notion of a table:
 A relation is a collection of tuples, each of which contains values for a fixed number
of attributes.
 An entity set is a collection of similar types of entities. An entity set may contain
entities with attribute sharing similar values. For example, a Students set may contain
all the students of a school; likewise a Teachers set may contain all the teachers of a
school from all faculties. Entity sets need not be disjoint.
 Entities are those entities which exist in the real world physically. Example: Person,
car, etc.

Entity Type
The entity type is a collection of the entity having similar attributes. The Student table have
each row as an entity and they are having common attributes i.e each row has its own value for
attributes Roll_no, Age, Student_name and Mobile_no. So, we can define STUDENT table as
an entity type because it is a collection of entities having the same attributes. So, an entity
type in an ER diagram is defined by a name(here, STUDENT) and a set of
attributes(here, Roll_no, Student_name, Age, Mobile_no). The table below shows how the
data of different entities (different students) are stored.

Types of entity type

Strong Entity Type: Strong entities are those entity types which has a key attribute. The
primary key helps in identifying each entity uniquely.

It is represented by a rectangle. In the above example, Roll_no identifies each element of the
table uniquely and hence, we can say that STUDENT is a strong entity type.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Weak Entity Type: Weak entity type doesn't have a key attribute. Weak entity type can't be
identified on its own.

 It depends upon some other strong entity for its distinct identity. This can be understood
with a real-life example. There can be children only if the parent exits. There can be no
independent existence of children.
 There can be a room only if building exits. There can be no independent existence of a
room.
 A weak entity is represented by a double outlined rectangle.

Example: If we have two tables of Customer(Customer_id, Name, Mobile_no, Age, Gender)

and Address(Locality, Town, State, Customer_id). Here we cannot identify the address
uniquely as there can be many customers from the same locality. So, for this, we need an
attribute of Strong Entity Type i.e ‘Customer’ here to uniquely identify entities of 'Address'
Entity Type.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Entity Set

Entity Set: An entity set is a collection or set of all entities of a particular entity type at any point in
time. The type of all the entities should be the same.
Entity Set is a collection of entities of the same entity type. In the above example of
STUDENT entity type, a collection of entities from the Student entity type would form an
entity set. We can say that entity type is a superset of the entity set as all the entities are
included in the entity type. Let's try to understand this with the help of an example.

Example 1: In the below example, two entities E1 (2, Angel, 19, 8709054568) and E2(4,
Analisa, 21, 9847852156) form an entity set.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Example 2: We can form another entity set by taking three entities from the table. (2, Angel,
19, 8709054568) , (3, Priya, 20, 9864257315) and (4, Analisa, 21, 9847852156) can also form
a entity set. Similary, we can form any combination of the entity set using any of the entities
from the entity type 'STUDENT'. Also, we can understand that if we take all the records to the
entity set we get the entity type 'STUDENT'. So, we can say that the entity type is the superset
of the entity set.

Attributes

 Properties used to describe each Entity or real world object.

 The items of information which characterize and describe these entities.
 Attributes are pieces of information about entities.
 The analysis must of course identify those which are actually relevant to the proposed
application.
 All attributes have values. For example, a student entity may have name, class, and age
as attributes.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 There exists a domain or range of values that can be assigned to attributes. For example,
a student's name cannot be a numeric value. It has to be alphabetic. A student's age
cannot be negative, etc.
 Attributes will give rise to recorded items of data in the database. At this level we need to
know such things as:
 Attribute name: Should be explanatory words or phrases.
 The domain: from which attribute values are taken (A domain is a set of values
from which attribute values may be taken.) Each attribute has values taken from
a domain. For example, the domain of Name is string and that for salary is real.
 Whether the attribute is part of the entity identifier (attributes which just describe
an entity and those which help to identify it uniquely).
 Whether it is permanent or time-varying (which attributes may change their
values over time).
 Whether it is required or optional for the entity (whose values will sometimes be
unknown or irrelevant).

Types of Attributes

 Simple/Atomic attribute − Simple attributes are atomic values, which cannot be divided
further. For example, E.g. emp_id, gender etc…
 Composite attribute − Divided into sub parts (composed of other attributes).
Composite attributes are made of more than one simple attribute.
For example, a student's complete name may have first_name and
last_name. E.g. Name, address,etc.
 Single-value attribute − Single-value attributes contain single value. For example –
DoB, Social_Security_Number., , Id.etc
 Multi-value attribute − Multi-value attributes may contain more than one values. For
example, a person can have more than one phone number, email_ address; address
several college degrees, etc.

 Derived attribute − Derived attributes are the attributes that do not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, average_salary in a department should not be saved directly in the database,
instead it can be derived. For another example, age can be derived from date_of_birth.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Keys

What are Keys in DBMS?

Keys in DBMS are an attribute or set of attributes which helps you to identify a row (tuple) in a
relation (table).
They allow you to find the relation between two tables. Keys help you uniquely identify a row in
a table by a combination of one or more columns in that table. Key is also helpful for finding
unique record or row from the table. Database key is also helpful for finding unique record or
row from the table.
There are different types of keys in DBMS these are:
Super Key: The Super key is a set of attributes which can uniquely identify a tuple. Super key is
a superset of the candidate key.

Eg. Table: employee

Emp_SSN Emp_No Emp_Name

12345 234 Hiwot

14583 235 kelem

13425 236 selam

The above tables have the following super keys. All of the following sets of super key are able to
uniquely identify a row of the employee table.

 { Emp_SSN}
 { Emp_No}
 { Emp_SSN, Emp_No}
 {Emp_SSN, Emp_Name}
 { Emp_SSN, Emp_No, Emp_Name }
 { Emp_No, Emp_Name }
Candidate Key: is a minimal super key with no redundant attribute. It selected from the sets of
super key. The Candidate key is an attribute or set of an attribute which can uniquely identify a
tuple. The Primary key can be selected from Candidate Key .There can be more than one super
key or candidate key in a table.

The following two sets of super keys are chosen from the above sets as there are no redundant
attributes in this set.

 { Emp_SSN}
Chapter 3 Fundamentals of database System GTC 2014 E.C

 { Emp_No}
Only these two sets are candidate keys as all other sets are having redundant attributes that are
not necessary for unique identification.

Primary key: is an attribute which uniquely identifies the records in a table. It is compulsory/
obligatory for every table. It is selected from candidate keys. This is done by database
administrator or designer. We can say that either { Emp_SSN} or { Emp_No } can be chosen as
a primary key for the table employee.

Alternate Key: This is the candidate key which is not chosen as the primary key of the table.
They are named so because although not the primary key, they can still identify a row.

Foreign key: is an attribute in a table that refers a value from another table to create relationship
between the tables.
It is a primary key from one table, which has a relationship with another table. It acts as a cross-
reference between tables.
Composite Key: Sometimes one key is not enough to uniquely identify a row. E.g. in a single
class Roll is enough to find a student, but in the entire school, merely searching by the Roll is not
enough, because there could be 10 classes in the school and each one of them may contain a
certain roll no 5. To uniquely identify the student we have to say something like “class VII, roll
no 5”. So, a combination of two or more attributes is combined to create a unique combination of
values, such as Class + Roll.

3.1.3. Relationships, Associations, and Constraints

Relationship
The association among two or more entities is called a relationship.
For example, an employee works at a department, a student enrolls in a course, teacher
teaches a student. Here, Works at, Enrolls and teaches are called relationships.

Relationship Set

.
A relationship set is a set of relationships of same type. A relationship set may be a unary
relationship set or binary relationship set or ternary relationship set or n-ary relationship set.
Relationship Attributes
In some cases, a relationship type can have attributes.
• Usually, in these cases, the attribute does not belong to any of the participating entities
(exclusively).
Chapter 3 Fundamentals of database System GTC 2014 E.C

• Because of that, we add the attribute on the relationship

Examples: – start_date: is an attribute that specifies the start date of an employee as a manager
of a department. It does not belong to employee or department exclusively. But, it belongs to
both of them; therefore we place it on the relationship “manages”.

Hours: is an attribute that specifies the number of hours an employee works on a project. It does
not belong to employee nor project exclusively. Therefore we place it on relationship
“works_on”.

Entity Roles

• In any relationship, entity has a role that specifies what it does in a relationship.
Example: In Employee “works_for” department relationship: – Employee Role:
“worker” (works in department) – Department Role: “Employer” (employs
employee)

• Entity roles can be written on relationship lines in ER Diagram. But they are
implicitly known.

Degree of Relationship

 The number of participating entities in a relationship defines the degree of the

relationship.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 The number of entity types that participate in a relationship.

 Unary:- degree 1
It is the relationship between the instances of a single entity type. It is also called a
recursive relationship.
Example
A person is married is a one-to-one relationship between the instances of Person entity
type of unary relationship.

Binary = degree 2
It is the relationship between the instances of two different entity types. Two entities will
participate in the relationship.

It exists when there is an association among two entities

Ternary = degree 3
A simultaneous relationship between the instances of three entity types with unique attributes is
called a ternary relationship.

It exists when there is an association among three entities.

n-ary
n-nary relationship: Tuples from arbitrary number of entity sets are participating in a
relationship.
Recursive Relationship
o Recursive Relationship is a relationship between an entity and itself.
o Recursive relationships describe relationships between two distinct entities in the same
entity type.
It is possible for an entity to have a relationship with itself; for example, an entity Staff could
have a relationship with itself, as one member of staff could supervise other staff. This is known
as a recursive or involute relationship, and would be represented in an entity-relationship
diagram as shown below.
A recursive relationship-for example, is-married-to in relates a particular EMPLOYEE to
another EMPLOYEE by marriage.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Cardinality of a Relationship

 Defines the number of entities in one entity set, which can be associated with the number
of entities of other set via relationship set.
 Another important concept about relationship is the number of instances/tuples that can
be associated with a single instance from one entity in a single relationship.
 The number of instances participating or associated with a single instance from an entity
in a relationship is called the cardinality of the relationship.

The major cardinalities of a relationship are:

 One-to-one: one tuple is associated with only one other tuple.

o E.g. Building -to- Location  as a single building will be located in a single location
and as a single location will only accommodate a single Building.
 One-to-many: one tuple can be associated with many other tuples, but not the reverse.
o E.g. Department-to-Student  as one department can have multiple students.
 Many-to-one: many tuples are associated with one tuple but not the reverse.
o E.g. Employee–to-Department: as many employees belong to a single department.
 Many-to-many: one tuple is associated with many other tuples and from the other side,
with a different role name one tuple will be associated with many tuples.
o E.g. Student–to-Course as a student can take many courses and a single course can
be attended by many students.

Participation refers to whether an entity must participate in a relationship with another entity to
exist.

Participation constraint specifies the existence of an entity when it is related to another entity
in a relationship type.

Participation can be total or partial (optional):

Chapter 3 Fundamentals of database System GTC 2014 E.C

Total Participation
Each entity in the entity set is involved in at least one relationship in a relationship set i.e. the
number of relationship in every entity is involved is greater than 0.
Consider two entities Employee and Department related via Works_For relationship. Now,
Eg. Every Employee works in at least one department therefore an Employee entity exist if it has
at least one Works_For relationship with Department entity. Thus the participation of Employee
in Works_For is total relationship.

Total Participation is represented by double line in ER diagram.

Partial Participation
Each entity in entity set may or may not occur in at least one relationship in a relationship set.
For example: Consider two entities Employee and Department and they are related to each other
via Manages relationship.
Eg. An Employee must manage a Department, he or she could be the head of the department.
But not every Employee in the company manages the department. So, participation of employee
in the Manages relationship type is partial i.e. only a particular set of Employees will manage the
Department but not all.

3.1.4. The ER Diagrams

Entity - Relationship Diagrams

 As one important aspect of E-R modeling, database designers represent their data model
by E-R diagrams.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 These diagrams enable designers and users to express their understanding of what the
planned database is intended to do and how it might work, and to communicate about the
database through a common language.
 Each organization that uses E-R diagrams must adopt a specific style for representing the
various components.

An Entity–relationship model (ER model) describes the structure of a database with the help of
a diagram, which is known as Entity Relationship Diagram (ER Diagram).

An ER model is a design or blueprint of a database that can later be implemented as a database.

The main components of E-R model are: entity set and relationship set

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes.

In terms of DBMS, an entity is a table or attribute of a table in database, so by showing

relationship among tables and their attributes, ER diagram shows the complete logical structure
of a database. Let’s have a look at a simple ER diagram to understand this concept.

Graphical Representations in ER Diagramming

 Entity is represented by a rectangle containing the name of the entity.

Weak entity

Strong Entity Weak Entity

 Connected entities are called relationship participants

 Attributes are represented by ovals and are connected to the
entity by a line.
 Oval Ova
Ovals Ovals
 s Ova
Multi-valued Composite Ova
Attribute
Attribute Attribute

 Multi-valued represented with double ovals

 A derived attribute is indicated by a dotted line. (……..)

Oval
Key s
Chapter 3 Fundamentals of database System GTC 2014 E.C

 Primary Keys are underlined.

 Relationships are represented by Diamond shaped symbols
 Weak Relationship is a relationship between Weak and Strong Entities.
 Strong Relationship is a relationship between two strong Entities.

Strong Relationship
Weak Relationship

Example of ER Diagram Representation

In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
 Chapter 3 Fundamentals of database System GTC 2014 E.C

attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.

An ER diagram has three main components:

1. Entity
2. Attribute
3. Relationship

Minimum cardinality tells whether the participation is partial or total.

1. If minimum cardinality = 0, then it signifies partial participation.
2. If minimum cardinality = 1, then it signifies total participation.
Chapter 3 Fundamentals of database System GTC 2014 E.C
Chapter 3 Fundamentals of database System GTC 2014 E.C

3.1.5 .Mapping ER-models to relational tables

ER Model to Relational Model
 ER Model, when conceptualized into diagrams, gives a good overview of entity-
relationship, which is easier to understand.
 ER diagrams can be mapped to relational schema, that is, it is possible to create
relational schema using ER diagram.
 We cannot import all the ER constraints into relational model, but an approximate
schema can be generated.
We may focus here on the mapping diagram contents to relational basics.
ER diagrams mainly comprise of −

 Entity and its attributes

 Relationship, which is association among entities.

There are some points for converting the ER diagram to the table:
 ER-to-Relational Mapping Algorithm

 Step 1: Mapping of Regular Entity Types

 Step 2: Mapping of Weak Entity Types

 Step 3: Mapping of Binary 1:1 Relation Types

 Step 4: Mapping of Binary 1:N Relationship Types.

 Step 5: Mapping of Binary M:N Relationship Types.

 Step 6: Mapping of Multivalued attributes.

 Step 7: Mapping of N-ary Relationship Types.

1. Mapping Strong Entity set with Simple attributes

The Strong Entity set becomes the table and the attributes of the Entity set becomes the table
attributes. The key attribute of the entity set becomes the primary key of the table.

 Create table for each entity.

 Entity's attributes should become fields of tables with their respective data types.
 Declare primary key.
Chapter 3 Fundamentals of database System GTC 2014 E.C

2. Mapping Strong Entity Set With Composite Attributes

The conversion is fairly simple in this case as well. The entity set will be the table and the simple
attributes of the composite attributes will become the attributes of the table while the composite
attribute itself will be ignored during conversion.

3. Mapping Weak Entity type

 Create table for weak entity set.
 Add all its attributes to table as field.
 Add the primary key of identifying entity set.
 Declare all foreign key constraints.

4. Mapping of Multivalued attributes.

The multivalued attribute is represented by a separate table.
Entity set with Multi-valued attributes will require two tables in the relational model.

For each multivalued attribute A, create a new relation R.

This relation R will include an attribute corresponding to A, plus the primary key attribute K-
as a foreign key in R-of the relation that represents the entity type of relationship type that
has A as an attribute.

5. Mapping Relationship Set to Table conversion

 A : Mapping of Binary 1:1 Relation Types

 For each binary 1:1 relationship type R in the ER schema, identify the relations S
and T that correspond to the entity types participating in R.
 There are three possible approaches:
 Foreign Key approach: Choose one of the relations-say S-and include a
foreign key in S the primary key of T. It is better to choose an entity type
with total participation in R in the role of S.
 Example: 1:1 relation MANAGES is mapped by choosing the
participating entity type DEPARTMENT to serve in the role of S, because
its participation in the MANAGES relationship type is total.
 Merged relation option: An alternate mapping of a 1:1 relationship type is
possible by merging the two entity types and the relationship into a single
relation. This may be appropriate when both participations are total.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 Cross-reference or relationship relation option: The third alternative is to set

up a third relation R for the purpose of cross-referencing the primary keys of the
two relations S and T representing the entity types.
B: Mapping of Binary 1:N Relationship Types.
 For each regular binary 1:N relationship type R, identify the relation S that
represent the participating entity type at the N-side of the relationship type.
 Include as foreign key in S the primary key of the relation T that represents the
other entity type participating in R.
 Include any simple attributes of the 1:N relation type as attributes of S.
C: Mapping of Binary M:N Relationship Types.
 For each regular binary M:N relationship type R, create a new relation S to
represent R.
 Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types; their combination will form the primary
key of S.
 Also include any simple attributes of the M:N relationship type (or simple
components of composite attributes) as attributes of S.

While converting the relationship set to a table, the primary attributes of the two entity sets
becomes the table attributes and if the relationship set has any attribute that also becomes the
attribute of the table.

 Create table for a relationship.

 Add the primary keys of all participating Entities as fields of table with their respective
data types.
 If relationship has any attribute, add each attribute as field of table.
 Declare a primary key composing all the primary keys of participating entities.
 Declare all foreign key constraints.

 Step 6: Mapping of N-ary Relationship Types.

 For each n-ary relationship type R, where n>2, create a new relationship S to
represent R.
 Include as foreign key attributes in S the primary keys of the relations that
represent the participating entity types.
 Also include any simple attributes of the n-ary relationship type (or simple
components of composite attributes) as attributes of S.
Chapter 3 Fundamentals of database System GTC 2014 E.C

3.2 Enhanced Entity Relationship (EER) Model

3.2.1 Inheritance
Inheritance is an important feature of Generalization and Specialization. It allows lower-level
entities to inherit the attributes of higher-level entities.

For example, the attributes of a Person class such as name, age, and gender can be inherited by
lower-level entities such as Student or Teacher.

Aggregation
 Aggregation represents a ‘has-a’ relationship between entity types, where one
represents the ‘whole’ and the other the ‘part’.
 An example of aggregation is the Car and Engine entities. A car is made up of an
engine. The car is the whole and the engine is the part.
 Representation of aggregation in ER diagrams A line with a diamond at the end is
used to represent aggregation.
 The ‘whole’ part must be put at the end of the diamond.
For example, the Car-Engine relationship would be represented as shown below:
Chapter 3 Fundamentals of database System GTC 2014 E.C

.
Generalization –
Generalization is the process of extracting common properties from a set of entities and create
a generalized entity from it.
It is a bottom-up approach in which two or more entities can be generalized to a higher level
entity if they have some attributes in common . In generalization two entities combine together
to form a new higher level entity.
In generalization, a number of entities are brought together into one generalized entity based on
their similar characteristics. For example, pigeon, house sparrow, crow and dove can all be
generalized as Birds.

Specialization

Specialization is the opposite of generalization.

In specialization, a group of entities is divided into sub-groups based on their characteristics.
Take a group ‘Person’ for example. A person has name, date of birth, gender, etc. These
properties are common in all persons, human beings.
But in a company, persons can be identified as employee, employer, customer, or vendor, based
on what role they play in the company.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Similarly, in a school database, persons can be specialized as teacher, student, or a staff, based
on what role they play in school as entities.
 Specialization is a process in which an entity is divided into sub-entities. You can think
of it as a reverse process of generalization,
 Specialization is a top-down process.

Union
A union relationship indicates either type; for example, a library member is either Faculty
or Staff or Student. Below are two examples that show how UNION can be depicted in ERD
– Vehicle Owner is UNION of PERSON and Company, and RTO Registered Vehicle is
UNION of Car and Truck
It means that 'Books', 'Chapters' and 'Articles' are sub-classes of the super-class 'Publication'.

'Books', 'Chapters' and 'Articles' are categories of 'Publication'

Chapter 3 Fundamentals of database System GTC 2014 E.C

3.2.4.. Mapping EER model to relational model

Mapping EER Model Constructs to Relations

Mapping Hierarchical Entities

ER specialization
Chapter 3 Fundamentals of database System GTC 2014 E.C

Generalization comes in the form of hierarchical entity sets.

Chapter 3 Fundamentals of database System GTC 2014 E.C

Mapping Process

 Create tables for all higher-level entities.

 Create tables for lower-level entities.
 Add primary keys of higher-level entities in the table of lower-level entities.
 In lower-level tables, add all other attributes of lower-level entities.
 Declare primary key of higher-level table

3.3.1 The Relational Model Concepts

Relation Data Model
In relational model, the data and relationships are represented by collection of inter-related
tables. Each table is a group of column and rows, where column represents attribute of an entity
and rows represents records.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Concepts
Tables − in relational data model, relations are saved in the format of Tables. This format stores
the relation among entities. A table has rows and columns, where a row represents records and
columns represent the attributes.
Tuple − A single row of a table, which contains a single record for that relation is called a tuple.
Relation instance − A finite set of tuples in the relational database system represents relation
instance. Relation instances do not have duplicate tuples.
Relation schema − A relation schema describes the relation name (table name), attributes and
their names.
Relation key − each row has one or more attributes, known as relation key, which can identify
the row in the relation (table) uniquely.
Attribute domain − every attribute has some pre-defined value scope, known as attribute
domain.
Sample relationship Model: Student table with 3 columns and four records.

Table: Student

Stu_Id Stu_Name Stu_Age

111 Ashish 23
123 Saurav 22
169 Lester 24
234 Lou 26
Table: Course
Stu_Id Course_Id Course_Name
111 C01 Science
111 C02 DBMS
169 C22 Java
169 C39 Computer Networks
Here Stu_Id, Stu_Name & Stu_Age are attributes of table Student and Stu_Id, Course_Id &
Course_Name are attributes of table Course. The rows with values are the records (commonly
known as tuples).
Chapter 3 Fundamentals of database System GTC 2014 E.C

In Relational Model/ Properties of Relational Databases

 Each row of a table is uniquely identified by a primary key (can be composed of one or
more columns).
 Data is stored in tables called relations.
 Relations can be normalized.
 In normalized relations, values saved are atomic values.
 Each row in a relation contains a unique value.
 Each column in a relation contains values from a same domain.
 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. This key is used to cross-reference tables.
 The 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.
Chapter 3 Fundamentals of database System GTC 2014 E.C

 A table is either a base tables (named relations) or views (Unnamed Relations).

 Only base tables are physically stores.
 Views are derived from base tables with SQL instructions like:
[select .. from .. where .. order by].

 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.
3.3.2 The Relational Constraints and Relational Database
Schemas

A database schema is a sketch of a planned database. It doesn’t actually have any data in it.

A database instance, on the other hand, is a snapshot of a database as it existed at a particular

time. Thus, database instances can change over time, whereas a database schema is usually static,
since it’s difficult to change the structure of a database once it is operational.

Database schemas and database instances can affect one another through a database management
system (DBMS). The DBMS makes sure that every database instance complies with the
constraints imposed by the database designers in the database schema.

Schemas and Instances

When a database is designed using a relational data model, all the data is represented in a form of
a table. In such definitions and representation, there are two basic components of the database.
The two components are the definition of the relation or the table and the actual data stored in
each table. The data definition is what we call the Schema or the skeleton of the database and the
relations with some information at some point in time is the Instance or the flesh of the database.

Schemas
Chapter 3 Fundamentals of database System GTC 2014 E.C

Schema describes how data is to be structured, defined at setup/design time (also called
"metadata"). Since it is used during the database development phase, there is rare tendency of
changing the schema unless there is a need for system maintenance which demands change to the
definition of a relation.

 Database Schema (Intension): specifies name of relation and the collection of the
attributes (specifically the Name of attributes).
 refer to a description of database (or intention)
 specified during database design
 should not be changed unless during maintenance
 Schema Diagrams: convention to display some aspect of a schema visually.
 Schema Construct: refers to each object in the schema (e.g. STUDENT)
E.g.: STUNEDT (FName,LName,Id,Year,Dept,Sex)

DBMS Instance

Definition of instance: The data stored in database at a particular moment of time is called
instance of database. In short, at a particular moment the data stored in database is called the
instance that changes over time when we add or delete data from the database

Instances

Instance: is the collection of data in the database at a particular point of time (snap-shot).

 Also called State or Snap Shot or Extension of the database.

 Refers to the actual data in the database at a specific point in time.
 State of database is changed any time we add, delete or update an item.
 Valid state: the state that satisfies the structure and constraints specified in the schema
and is enforced by DBMS.
Since instance is actual data of database at some point in time, changes rapidly. To define a new
database, we specify its database schema to the DBMS (database is empty). Database is
initialized when we first load it with data.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Relational Constraints/Integrity Rules

Types of integrity constraints:

Domain Integrity:
 No value of the attribute should be beyond the allowable limits.
 It performs data type check.
 It specifies that attribute must contain the data item according to defined data type, the
value of attribute must be available in the corresponding domain.
 The range of an attribute during relation creation. It also checks for the Null value
according to integrity check.
 The domain integrity states that every element from a table should respect the type and
restrictions of its corresponding attribute. A type can have a variable length which needs
to be respected. Restrictions could be the range of values that the element can have, the
default value if none is provided, and if the element can be NULL.
Entity Integrity:
 Rules state that primary key cannot contain a NULL value.
 A Primary key value to store unique values in a tuple or no any duplicate entries in the
primary key column.
Referential Integrity
 Referential integrity concern with the concept foreign key. A foreign key is used to create
a connection between two tables. Parent table (Referenced table) has a primary key, and
foreign key (referencing table) is used in the second table to create a connection with
parent table.
 Referential Integrity is a feature provided by relational DBMS that prevents users from
entering inconsistent data.
 Referential integrity means the foreign key in any referencing table must always refer to a
valid row in the parent/primary /referenced table.

 It specifies that "Foreign Key can be either a NULL value or should be the Primary Key
value of other relation
 1) We cannot delete any row from the primary table (Referenced table) if the same
row is available in referencing table. First, delete from/foreign key/ referencing table
and then from the parent/primary table.
 2) A row cannot be added first in foreign key/referencing table if the entry was not in
the parent/primary key /reference table.
User-defined Integrity/ Enterprise integrity
 Additional rules specified by the users or database administrators of a database are
combined.
 Business rules may dictate/state that when a specific action occurs further actions should
be triggered. For example, deletion of a record automatically writes that record to an
audit table.
Chapter 3 Fundamentals of database System GTC 2014 E.C

Relational Views

Relations are perceived as a table from the users’ perspective. Actually, there are two kinds of
relation in relational database. The two categories or types of relations are Base (Named) and
View (Unnamed) Relations. The basic difference is on how the relation is created, used and
updated:

1. Base Relation: A named relation corresponding to an entity in the conceptual schema,

whose tuples are physically stored in the database.
2. View (Unnamed Relation): A View is the dynamic result of one or more relational
operations operating on the base relations to produce another virtual relation that does not
actually exist as presented. So a view is virtually derived relation that does not
necessarily exist in the database but can be produced upon request by a particular user at
the time of request. The virtual table or relation can be created from single or different
relations by extracting some attributes and records with or without conditions.
Purpose of a view

 Hides unnecessary information from users: since only part of the base relation (Some
collection of attributes, not necessarily all) are to be included in the virtual table.
 Provide powerful flexibility and security: since unnecessary information will be hidden
from the user there will be some sort of data security.
 Provide customized view of the database for users: each users are going to be interfaced
with their own preferred data set and format by making use of the Views.
 A view of one base relation can be updated.
 Update on views derived from various relations is not allowed since it may violate the
integrity of the database.
 Update on view with aggregation and summary is not allowed. Since aggregation and
summary results are computed from a base relation and does not exist actually.