CHAPTER TWO

Data Models
DATA MODELLING OVERVIEW
▪ In the previous Chapter, we described that Database Design focuses on how the
database structure will be used to store and manage end-user data.
What is Data Modelling?
▪ On the other hand, Data Modelling is the first step in designing a database and
refers to the process of creating a specific data model for a determined
problem domain.
What is a Data Model?
▪ A data model is a conceptual representation of the data structures that are
required by a database. The data structures include:
▪ data objects
▪ the associations between data objects
▪ the rules which govern operations on the objects.
DATA MODELLING OVERVIEW
▪ A data model is a relatively simple representation, usually graphical, of
more complex real-world data structures.
▪ The data model focuses on:
▪ what data is required
▪ how it should be organized

▪ To use a common analogy, the data model is equivalent to an architect's

building plans.
▪ A data model is independent of hardware or software constraints. It
focuses on representing the data as the user sees it in the “real world”.
DATA MODELLING OVERVIEW
▪ It serves as a bridge between the concepts that make up real-world
events and processes and the physical representation of those concepts
in a database.
▪ The data model has two outputs:
▪ Entity-relationship diagram which represents the data structures in a
pictorial form.
▪ Because the diagram is easily learned, it is valuable tool to communicate the
model to the end-user.
▪ Data document: This document that describes in details the data objects,
relationships, and rules required by the database.
▪ The data document provides the details required by the database developer to
construct the physical database.
DATA MODELLING OVERVIEW
▪ Done properly, the final data model is an effect “blueprint” containing all the
instructions to build a database that will meet all end-user requirements.
▪ An implementation-ready data model should contain at least the following
components:
▪ A description of the 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.

▪ The data model is an abstraction; you cannot draw the required data out of the
data model.
▪ For example, think of a house plan or blueprint, you cannot live in a blueprint and
architects consider blueprints before constructing a building.
 THE IMPORTANCE OF DATA MODELS
▪ A data model’s main function is to help you understand the complexities of the real-world environment.
▪ The goal of the data model is to make sure that the all data objects required by the database are
completely and accurately represented. Because the data model uses easily understood notations and
natural language, it can be reviewed and verified as correct by the end-users.
▪ The data model is also detailed enough to be used by the database developers as a “blueprint” for
building the physical database.
▪ The information contained in the data model will be used to define the relational tables, primary and
foreign keys, stored procedures, and triggers.
▪ The data model also acts as a communication tool to facilitate interaction among the designer, the
applications programmer, and the end user. End-users have different views and needs for data from the
designers and programmers. A well-developed data model can even foster improved understanding of
the organization.
COMPONENTS OF DATA MODELS
There are four (4) component of a database model:
▪ Entity: an entity is anything (a person, a place, a thing, or an event) about which data are to
be collected and stored. An entity represents a particular type of object in the real world.
▪ Attribute: an attribute is a characteristic of an entity.
▪ Relationship: a relationship describes an association among entities. Relationships can be
thought of as verbs, linking two or more nouns.
▪ Constraint: a constraint is a restriction placed on the data.
Example: department and a course are some of the important components of any academic
institution. In that case:
▪ the department and course are entities,
▪ the department name, course name, course code, etc. are attributes of these entities,
▪ a department has multiple courses and a course has a department is the relationship between these
entities
 RELATIONSHIPS: THE BASIC CHEN ERD

Database Systems 6e / Rob & Coronel 2- 8

 RELATIONSHIPS:
THE BASIC CROW’S FOOT ERD

Database Systems 6e / Rob & Coronel 2- 9

COMPONENTS OF DATA MODELS
▪ Entities and relationships can both have attributes. E.G. an employee entity
might have an Identity Number (ID Number) attribute; the proved
relationship may have a date attribute.
▪ Every entity (unless it is a weak entity) must have a minimal set of uniquely
identifying attribute(s), which is called the entity's primary key.
▪ Entity-relationship diagrams don't show single entities or single instances of
relations. Rather, they show entity sets and relationship sets.
▪ Entity-relationship diagrams don't show single entities or single instances of
relations. Rather, they show entity sets and relationship sets. For example: a
particular song is an entity. The collection of all songs in a database is an
entity set.
TYPES OF RELATIONSHIPS
▪ One-to-one (1:1): One entity from entity set A can be associated with at
most one entity of entity set B and vice versa.
▪ One-to-many (1:M): One entity from entity set A can be associated with
more than one entities of entity set B however an entity from entity set
B, can be associated with at most one entity of entity set B.
▪ Many-to-one (N:1): More than one entities from entity set A can be
associated with at most one entity of entity set B, however an entity
from entity set B can be associated with more than one entity from
entity set A.
▪ Many-to-many (M:N): One entity from A can be associated with more
than one entity from B and vice versa.
TYPES OF RELATIONSHIPS
▪ As a general rule, to properly identify the relationship type, you should
ask two questions:
▪ How many instances of B are related to one instance of A?
▪ How many instances of A are related to one instance of B?
▪ For example, you can assess the relationship between student and class
by asking two questions:
▪ In how many classes can one student enrol?
▪ How many students can enrol in one class?
 CONSTRAINTS
▪ A constraint is a restriction or rule placed on the data. Constraints are important
because they help to ensure data integrity. Constraints are normally expressed
in the form of rules.
▪ They can apply to a column, a whole table, more than one table or an entire
schema.
▪ The schema is the conceptual organization of the entire database. There are
there are mainly three types of schemas:
▪ External Schema - database users’ view
▪ Conceptual Schema - database administrators’ view
▪ Internal Schema - database developers’ view
▪ The internal schema is composed of the physical schema and the logical
schema.
 CONSTRAINTS
▪ Five Types of Constraints:
▪ NOT NULL: value in a column must not be NULL.
▪ UNIQUE: value(s) in specified column(s) must be unique for each row in a table.
This constraint ensures that each rows for a column must have different value.
▪ PRIMARY KEY: combination of a NOT NULL and a UNIQUE constraint. value(s)
in specified column(s) must be unique for each row in a table and not be NULL;
normally each table in a database should have a primary key - it is used to
identify individual records.
▪ FOREIGN KEY: ensure the referential integrity of the data and value(s) in
specified column(s) must reference an existing record in another table (via
primary key or unique constraint). Referential integrity means that if the
foreign key contains a value, that value refers to an existing valid tuple (row) in
another relation
▪ CHECK: ensures that the value stored in a column meets a specific condition.
BUSINESS RULES
▪ From a database point of view, the collection of data becomes
meaningful only when it reflects properly defined business rules.
▪ A business rule is a brief, precise, and unambiguous description of a
policy, procedure, or principle within a specific organization.
▪ Business rules apply to any organization that stores and uses data to
generate information.
▪ Business rules help to create and enforce actions within any
organization’s environment.
▪ Properly written business rules are used to define entities, attributes,
relationships, and constraints.
BUSINESS RULES
▪ Business rules can apply to people, processes, corporate behavior and computing
systems in an organization, and are put in place to help the organization achieve its
goals.
▪ Data can be considered significant only after business rules are defined, without them
the data is just records. However, to a business they are the characteristics that are
defined and seen by the company.
▪ To be considered true, business rules must be in writing and kept up to date.
▪ Sources of business rules are: managers, policy makers, department managers,
written documentation, procedures, standards, operation manuals, and interviews
with end-users.
▪ Business Rules give the proper classification of entities, attributes, relationships, and
constraints.
BUSINESS RULES
▪ As a general rule in database design, the noun in a business rule will translate into an entity in
the model and a verb (active or passive) associating nouns will translate into a relationship
among the entities.
▪ Business rules should be considered as bidirectional. There are two questions to ask to properly
identify a relationship in a business rules:
▪ How many instances of B are related to one instance of A?
▪ How many instances of A are related to one instance of B?

▪ Examples of business rules:

▪ Departments ------offers---------Course
▪ Course----------generates---------Class
▪ Professor --------teaches----------Class

▪ There are several protocols to the way business rules are written. Not every protocol has to be
followed.
CHARACTERISTICS OF BUSINESS RULES
▪ Business rules are brief, precise, and unambiguous descriptions of a policies,
procedures, or principles within a specific organization
▪ They apply to any organization that stores and uses data to generate information
▪ They are description of operations that help to create and enforce actions within that
organization’s environment
▪ They must be rendered in writing
▪ They must be kept up to date
▪ Sometimes they are external to the organization
▪ They must be easy to understand and widely disseminated
▪ They describe characteristics of the data as viewed by the company
IMPORTANCE OF BUSINESS RULES
▪ Business rules promote the creation of an accurate data model.
▪ They help standardize the company’s view of data.
▪ They can be a communication tool between users and designers.
▪ They allow the designer to:
▪ understand the nature, role, and scope of the data
▪ understand business processes
▪ develop appropriate relationship participation rules
▪ identify all constraints
▪ create an accurate data model.
 EXAMPLES OF BUSINESS RULES
▪ Suppose there was a single company responsible for handling student
applications to different universities and it had the following business
rules:
▪ Each student can submit one application per university.
▪ Each application is submitted by only one student.
▪ Each university can be associated with one or more applications and each
application is associated with only one university
▪ Each application must include two or more recommendations and each
recommendation is included with only one application.

▪ From the above business rules identify all the entities and relationships
among the entities and draw a relational data model that include:
▪ All the entities
▪ At least three (3) attributes for each entity
▪ All the relationships among the entities
EVOLUTION OF DATA MODELS
▪ Hierarchical
▪ Network
▪ Relational
▪ Entity relationship
▪ Object oriented
EVOLUTION OF DATA MODELS
EVOLUTION OF DATA MODELS
HIERARCHICAL MODEL
▪ Developed in the 1960s to manage large amounts of data for complex
manufacturing projects
▪ Its basic logical structure is represented by an upside-down “tree”
▪ The hierarchical structure contains levels, or segments. A segment is
the equivalent of a file system’s record type.
▪ The hierarchical model employs two main data structuring concepts:
records and parent-child relationships (PCR).
▪ A record is a collection of field values that provide information on an
entity or a relationship instance.
HIERARCHICAL MODEL
▪ Records of the same type are grouped into record types. A record type
is given a name, and its structure is defined by a collection of named
fields or data items. Each field has a certain data type, such as integer,
real, or string.
▪ A parent-child relationship type (PCR type) is a 1:N relationship
between two record types. The record type on the 1-side is called the
parent record type, and the one on the N-side is called the child record
type of the PCR type.
▪ An occurrence (or instance) of the PCR type consists of one record of
the parent record type and a number of records (zero or more) of the
child record type as shown in the diagram below.
HIERARCHICAL MODEL
HIERARCHICAL MODEL
HIERARCHICAL MODEL
HIERARCHICAL MODEL
▪ The hierarchical model depicts a set of one-to-many (1:M) relationships
between a parent and its children segments:
▪ Each child has only one parent except root node.
▪ Each parent can have many children ordered from left to right.

▪ In the hierarchical model, M:N relationships between record types

cannot be directly represented, because parent-child relationships are
1:N relationships, and a record type cannot participate as child in two or
more distinct parent-child relationships.
▪ An M:N relationship may be handled in the hierarchical model by
allowing duplication of child record instances.
HIERARCHICAL MODEL
▪ A tree is defined by path that traces parent segments to child segments, beginning from the left.
▪ A hierarchical path is an ordered sequencing of segments tracing hierarchical structure. A hierarchical
path is a sequence of nodes N1, N2, ..., Ni, where N1 is the root of a tree and Nj is a child of Nj-i for j =
2, 3, ..,i of a hierarchical tree occurrence.
▪ A hierarchical occurrence tree of the PCR type consists of one root node of the parent record type and
a number of records (zero or more) of the child record type.
▪ A hierarchical occurrence tree can be represented in storage by using any of a variety of data
structures. However, a particularly simple storage structure that can be used is the hierarchical record,
which is a linear ordering of the records in an occurrence tree in the pre-order traversal of the tree.
▪ The pre-order traversal order produces a sequence of record occurrences known as the hierarchical
sequence (or hierarchical record sequence) of the occurrence tree
▪ The pre-order traversal can be obtained by applying a recursive procedure called the pre-order
traversal, which visits nodes depth first and in a left-to-right fashion.
 CHARACTERISTICS OF HIERARCHICAL
MODEL
▪ One record type called the root in the hierarchical model does not participate as
a child type in any PCR type.
▪ Every record type except the root participates as a child record type in exactly
one PCR type.
▪ A record type can participate as parent record type in any number (zero or more)
of PCR types.
▪ A record type that does not participate as parent record type in any PCR type is
called a leaf of the hierarchical schema.
▪ If a record type participates as parent in more than one PCR type, then its child
record types are ordered. The order is displayed, by convention, from left to right
in a hierarchical diagram
 HIERARCHICAL MODEL
Advantages Disadvantages
▪ It promotes data sharing. ▪ Complex implementation requires knowledge of
physical data storage characteristics.
▪ Parent/Child relationship promotes conceptual
simplicity. ▪ Navigational system yields complex application
development, management, and use; requires
▪ Database security is provided and enforced by
knowledge of hierarchical path.
DBMS.
▪ Changes in structure require changes in all
▪ Parent/Child relationship promotes data integrity.
application programs.
▪ It is efficient with 1:M relationships.
▪ There are implementation limitations (no multi-
parent or M:N relationships).
▪ There is no data definition or data manipulation
language in the DBMS.
▪ There is a lack of standards.
▪ Difficult to manage
NETWORK MODEL
▪ The Network Model was created to represent complex data
relationships more effectively than the hierarchical model, to improve
database performance, and to impose a database standard.
▪ The Network Model replaces the hierarchical tree with graph thus
allowing more general connection with the nodes.
▪ In the network model, the user perceives the network database as a
collection of records in 1:M relationships.
▪ The network model allows a record to have more than one parent.
NETWORK MODEL
 NETWORK MODEL
Advantages Disadvantages
▪ Conceptual simplicity is at least equal to that of ▪ System complexity limits efficiency—still a
the hierarchical model. navigational system.
▪ It handles more relationship types, such as M:N ▪ Navigational system yields complex
and multi-parent. implementation, application development, and
management.
▪ Data access is more flexible than in hierarchical
and file system models. ▪ Structural changes require changes in all
application programs
▪ Data Owner/Member relationship promotes data
integrity.
▪ There is conformance to standards.
▪ It includes data definition language (DDL) and data
manipulation language (DML) in DBMS.
RELATIONAL MODEL
▪ The Relational Model represented a major breakthrough for both users and
designers.
▪ Its conceptual simplicity set the stage for a genuine database revolution.
▪ The Relational Model stores data in a matrix composed of intersecting rows
and columns referred to as a relation (tables). Each row in a relation is called
a tuple.
▪ The relational database is a collection of tables in which data are stored.
▪ Tables are related to each other through the sharing of a common attribute.
▪ A relational diagram is used to represent the relational database’s entities,
the attributes within those entities, and the relationships between those
entities.
RELATIONAL DIAGRAM
 RELATIONAL DATABASE KEYS
Key Type Definition
Composite Two or more attributes that uniquely identify a row in a database table
key
Super key A set of attributes within a table that uniquely identifies each row
within a table.
Candidate A super key with no redundant attributes. Candidate keys are defined
key as the set of fields from which primary key can be selected.
Primary key A candidate key that is selected to uniquely identify each record (row)
in a relation (table). It is the main key of the table.
Secondary A candidate key which is not selected for primary key. Secondary keys
Key are used strictly for data retrieval purposes
Foreign Key An attribute or set of attributes within one relation (table) that
matches the candidate key of another relation (table)
RELATIONAL DATABASE KEYS
RELATIONAL DATABASE KEYS
▪ Composite Key: EMPLOYEE_ID, EMPLOYEE_NAME or SSN, EMPLOYEE_NAME
▪ Super key: EMPLOYEE_ID or EMP_PASSPORT_NUM or LICENCE_NUMBER or
SSNN or a combination of these fields with other fields e.g. SSN,
EMPLOYEE_NAME
▪ Candidate key: EMPLOYEE_ID or EMP_PASSPORT_NUM or
LICENCE_NUMBER or SSN
▪ Primary key: EMPLOYEE_ID
▪ Secondary key: EMP_PASSPORT_NUM or LICENCE_NUMBER or SSNN
▪ Foreign Key: DEPARTMRNT_NUMBER
 RELATIONAL MODEL
Advantages Disadvantages
▪ Structural independence is promoted by the use ▪ The RDBMS requires substantial hardware and
of independent tables. Changes in a table’s system software overhead.
structure do not affect data access or application
▪ Conceptual simplicity gives relatively untrained
programs.
people the tools to use a good system poorly, and
▪ Tabular view substantially improves conceptual if unchecked, it may produce the same data
simplicity, thereby promoting easier database anomalies found in file systems.
design, implementation, management, and use.
▪ It may promote “islands of information” problems
▪ Ad-hoc query capability is based on SQL. as individuals and departments can easily develop
their own applications.
▪ Powerful RDBMS isolates the end user from
physical-level details and improves
implementation and management simplicity.
ENTITY RELATIONAL MODEL
▪ The Relational Model (ER) was a vast improvement over the hierarchical and
network models, it still lacked the features that would make it an effective database
design tool.
▪ Because it is easier to examine structures graphically than to describe them in text,
database designers prefer to use a graphical tool in which entities and their
relationships are pictured.
▪ The ER model is a form of graphical representation of entities and their
relationships in a database structure that quickly became popular because it
complemented the relational data model concepts.
▪ The relational data model and ERM combined to provide the foundation for tightly
structured database design.
▪ ER models are normally represented in an entity relationship diagram (ERD), which
uses graphical representations to model database components.
ENTITY RELATIONAL MODEL (2)
▪ An entity is represented in the ERD by a rectangle, also known as an entity box.
▪ The ER model uses the term connectivity to label the relationship types. The
name of the relationship usually is an active or passive verb. For example:
▪ a PAINTER paints many PAINTINGs
▪ an EMPLOYEE learns many SKILLs
▪ a STUDENT attends/enrol/registers/takes/has many CLASSES
▪ There are two different types of representing relationships using two ER
notations:
▪ Chen Notation - relationships are represented by a diamond connected to the related
entities through a relationship line. The relationship name is written inside the diamond.
▪ Crow’s Foot - connectivity are represented by symbols. For example:
▪ 1 is represented by a short line segment
▪ M is represented by the three-pronged crow’s foot
CHEN VS CROW’S FOOT NOTATION
 THE ENTITY RELATIONAL MODEL
Advantages Disadvantages
▪ Visual modelling yields exceptional conceptual ▪ There is limited constraint representation.
simplicity.
▪ There is limited relationship representation.
▪ Visual representation makes it an effective
▪ There is no data manipulation language.
communication tool.
▪ Loss of information content occurs when
▪ It is integrated with dominant relational model.
attributes are removed from entities to avoid
crowded displays. (This limitation has been
addressed in subsequent graphical versions.)
OBJECT ORIENTED MODEL (OOM)
▪ Increasingly complex real-world problems demonstrated a need for a data model
that more closely represented the real world.
▪ OOM modelled both data and their relationships in a single structure known as
an object.
▪ It is the basis for the object oriented database management system (OODBMS).
▪ An Object is described by its factual content like relational model’s entity.
▪ The object’s description includes information about relationships between facts
within object and relationships with other objects, unlike relational model’s
entity.
▪ Subsequent OOM development allowed an object to also contain operations.
▪ Object becomes basic building block for autonomous structures.
OBJECT ORIENTED MODEL
OBJECT ORIENTED MODEL
▪ In this entity-relationship diagram, a customer’s phone number
attribute is a collection that can contain zero to ten phone numbers.
▪ A customer’s address is modelled as a single “Address” object, which
contains the attributes Street, City, State, and Zip.
▪ The Address object associated with a customer is also used by any
Purchase Order objects associated with that customer.
▪ In a Purchase Order, the customer’s address is used as the shipping
address.
▪ A Purchase Order contains as an attribute a collection of one or more
Line Items. Each Line Item refers to a Stock Item.
OBJECT ORIENTED MODEL: COMPONENTS
▪ Object is abstraction of a real-world entity.
▪ Attributes describe the properties of an object.
▪ Objects that share similar characteristics are grouped in classes.
▪ Classes are organized in a class hierarchy.
▪ Inheritance is the ability of an object within the class hierarchy to
inherit the attributes and methods of classes above it.
 THE ENTITY RELATIONAL MODEL
Advantages Disadvantages
▪ Semantic content is added. ▪ Slow development of standards caused
▪ Visual representation includes semantic vendors to supply their own
enhancements, thus eliminating a widely
content.
accepted standard.
▪ Inheritance promotes data integrity.
▪ It is a complex navigational system.
▪ Both structural and data independence.
▪ There is a steep learning curve.
▪ High system overhead slows transactions.
▪ Lack of market penetration.
END OF CHAPTER 2
 DATABASE DESIGN

RELATIONAL DATA MODEL

SUB TOPIC
2.1 Relational databases
2.1.1 Relational databases and RDBMS
2.1.2 Some popular RDBMS packages
2.1.3 Components of a relational database structural terminology:
(Relation, Tuple, Cardinality, Attribute, Degree, Primary key, Domain)
2.1.4 Application areas of RDBMS (airlines, banking, universities, telecomm.)
2.1.5 Properties of tables in a relational database
2.1.6 Characteristics of relation scheme:
(Relation name, Attribute name, Domains)
2.1.7 Relation instance
2.1.8 Relation keys: primary key, candidate key, and foreign key
2.1.9 Two important integrity rules: Entity integrity & Referential integrity
2.2.10 Application of concepts of relational database using an appropriate
desktop database by creating tables.
2
2.1.1 RELATIONAL DATABASE MODEL
 Relational database is a collection of tables
 Heading: table name and column names

 Body: rows, occurrences of data

Heading

Student (table name)

StdSSN StdLastName StdMajor StdClass StdGPA
123-45-6789 WELLS IS FR 3.00
124-56-7890 NORBERT FIN JR 2.70
234-56-7890 KENDALL ACCT JR 3.50
Body 3
2.1.2 RDBMS
 A relational database management system
(RDBMS) is a program that lets you create,
update, and administer a relational database.
 Most commercial RDBMS's use the Structured
Query Language (SQL) to access the database,
although SQL was invented after the
development of the relational model and is not
necessary for its use.

4
2.1.2 SOME POPULAR RDBMS PACKAGES
1. Oracle RDBMS
2. IBM DB2
3. Microsoft SQL Server
4. SAP Sybase ASE
5. Teradata
6. ADABAS
7. MySQL
8. FileMaker
9. Microsoft Access 5
2.1.13 COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY
Relation
•a table with columns and rows

Tuple (row of record)

•a row of a relation

Cardinality of a relation (number of rows)

•the number of tuples it contains

Attribute (column or field)

•a named column of a relation

Degree of a relation (number of columns)

•number of attributes it contains

Primary key (unique identifier)

•the candidate key that is selected to identify tuples uniquely within the relation

Domain (pool of values of specific attributes of relation) 6

•the set of allowable values for one or more attributes
2.1.13 COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY

Primary key: sid

Degree: 5 Domain of age: Integer

Cardinality : 6

7
2.1.13 COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY
Exercise:

Table name: Animal_Vaccination

Identify:
a. Name of the relation.
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column Type.
e. Suitable domain for column Date of Birth.
8
2.1.4 APPLICATION AREA OF RDBMS
 Airlines : reservations, schedules
 Banking : all transactions

 Universities : registration, grades

 Sales : customers, products, purchases

 Manufacturing : production, inventory, orders,

supply chain
 Human resources: employee records, salaries, tax
deductions

9
2.1.5 PROPERTIES OF TABLES IN A
RELATIONAL DATABASE

Values Column values

are are of the same
kind
atomic

The sequence The sequence

of rows is of columns is
insignificant insignificant

Each Each
column
row is must have
a unique
unique name 10
2.1.6 CHARACTERISTICS OF RELATION
SCHEME
Relation scheme
Named relation defined by a set of attribute and
domain name pairs.

Characteristics:
a. Relation name
b. Attribute name
c. Domains

Syntax:
RelationName (attribute-1, attribute-2…attribute-n) 11
2.1.6 CHARACTERISTICS OF RELATION
SCHEME
Example:
Table name: Animal_Vaccination

Animal_Vaccination (ID, Name of Animal, Type, Date of Birth, Vaccinated?,

Keeper)

12
2.1.7 RELATION INSTANCE
 A tuple at a specifc moment of time
 Eg: Student (StudentId, firstName, lastName, courseId)
 The relation instance for Student:
 (L0002345, Jim, Black, C002)
 (L0001254, James, Harradine, A004)
 The relation instance changed when the tuple is updated,
deleted or inserted

13
2.1.8 RELATION KEYS
1) Candidate key
- Any set of one or more columns whose combined values are
unique among all occurrences (i.e., tuples or rows).
- No component of a candidate key is allowed to be null.
- There can be any number of candidate keys in a table.

14
2.1.8 RELATION KEYS
2) Primary key (identifier)
- Any candidate key of that table which the database
designer arbitrarily designates as "primary".
- The primary key may be selected for convenience,
comprehension, performance, or any other reasons.

3) Foreign key (referential)

- A set of one or more columns in any table which may
hold the value(s) found in the primary key column(s) of
some other table.

15
2.1.8 RELATION KEYS

16
2.1.8 RELATION KEYS

17
2.1.8 RELATION KEYS
Exercise:

Identify:
i. candidate key
ii. primary key

18
2.1.9 INTEGRITY RULES
 Data integrity means that the data values in the
database are correct and consistent.
 Integrity constraints provide a way of ensuring that changes
made to the database by authorized users do not result in a
loss of data consistency

 Data integrity is enforced in the relational model by:

1)Entity integrity
2)Referential integrity

19
2.1.9 INTEGRITY RULES
1) Entity Integrity
- states that “for every instance of an entity, the value of the
primary key must exist, be unique, and cannot be null”
- Without entity integrity, the primary key could not fulfill its
role of uniquely identifying each instance of an entity

2) Referential Integrity
- states that “every foreign key value must match a primary
key value in an associated table”
- ensures that we can correctly navigate between related
entities
20
2.1.9 INTEGRITY RULES
Exercise:

1)What is the primary key for each of the table?

2)What is the foreign key?
3)Write relation scheme for both tables. 21
EXERCISE

Identify:
a. Suggest suitable name for the relation. Senior_Citizen, Member, Neighbour
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column Last Name.
e. Suitable domain for column City.
22
f. Suitable domain for column Age.
EXERCISE

Identify:
a. Suggest suitable name for the relation.
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column ID.
e. Suitable domain for column Class.
23
f. Suitable domain for column Mark.