Hawassa UNIVERSITY

Daye campus

DEPARTMENT OF COMPUTER SCIENCE

Course module for Fundamentals of Database Systems

Prepared by: Senbeto K. (MSc)

Hawassa University
Feb, 2022
Bensa Dayye
 Fundamentals of Database Systems: Course Module 2021/2022

CHAPTER TWO
Database System Concepts and Architecture
Unit description:
In this unit Data Models, Schema and Instances, DBMS Architecture and Data Independence, Database
Language and Interface, the Database System Environment, and Classification of DBMS are contents to be
covered. To deliver these contents brain storming and interactive lecture, Peer teaching, group discussion,
presentation and class work methods are used.
I. Objectives: At the end of this unit students will be able to:
 Describe Data Models, Schema and Instances Database Language and Interface
 Describe The Database System Environment
 Described DBMS
II. Contents:
 Data Models, Schema and Instances
 DBMS Architecture and Data Independence
 Database Language and Interface
 The Database System Environment
 Classification of DBMS
III. Method of Teaching: brain storming, gap lecture, group discussion

2.1. Data Models, Database Schema and Database Instance

Data/Database model
The notion of a “data model” is one of the most fundamental in the study of database systems. A data
model is a notation for describing data or information. Data model describes an abstract way how data is
represented in an information system or a database management system.
 A data model is a collection of conceptual tools for describing data, data relationships, data
semantics, and consistency constraints in database.
 A data model is a description of the way that data is stored in a database. Data model helps to
understand the relationship between entities and to create the most effective structure to hold data.
Data Model is a collection of tools or concepts for describing
 Data
 Data relationships
 Data semantics
 Data constraints
The main purpose of Data Model is to represent the data in an understandable way.
 There are several types of data models.
 Entity–relationship (ER) model
 Relational model
 Hierarchical model or Network model
 The object-oriented data models.
In this course, we will focus on two popular data models: the entity-relationship model and the relational
model.

1. Entity–Relationship (ER) Model

The entity–relationship (E-R) model is a high-level data model. It is based on a perception of a real world
that consists of a collection of basic objects, called entities, attributes and of relationships among these
objects.

Prepared by Instructor Senbeto K. Page 2

 Fundamentals of Database Systems: Course Module 2021/2022

 Entity:-represents real-world objects or with physical or conceptual existence.

 (e.g., EMPLOYEE, PROJECT, STUDENT, COURSE) etc.
 Entity has some attributes which represents properties of entity.
 Such as EMPLOYEE’s [Name, EID, Address, Salary, birth-date, JobTitle]
 A relationship represents association among entities for example a “works on” relationship
between employee and project.

2. Relational Model
There are different ways of storing the data in a database. The way you are probably most familiar with is
storing data as rows in a table e.g., a list of names, addresses and phone numbers in Excel. This is the basis
of the relational model.

In a relational database, data is stored in tables (also called relations). Each table is physically separate
to other tables in the system. The relational model is a lower-level model. It uses a collection of tables to
represent both data and the relationships among those data. Its conceptual simplicity has led to its
widespread adoption; today a vast majority of database products are based on the relational model.
Designers often formulate database schema design by first modeling data at a high level, using the E-R
model, and then translating it into the relational model.

A table stores data about one specific entity in the mini-world represented by the database e.g. about
Customers. A row in a table represents an instance of the entity i.e. a row in the Customers table
represents one Customer record. A row in the Accounts table represents one Account record.

The columns in a table represent attributes of the entity. Therefore, the Customers table would have
columns for CustomerID, Name, PhoneNumber, Address.

CUSTOMERS
CustomerID Name PhoneNumber Address
1 Solomon Tesfay 04 123456 Kebele 7
2 ….

ACCOUNTS
Type Number Balance CustomerID
Savings 123456 5400 1
Current 278654 2000 1

Relational Model
➢ Terminologies originates from the branch of mathematics called set theory and predicate
logic and is based on the mathematical concept called Relation
➢ Can define more flexible and complex relationship
➢ Viewed as a collection of tables called →Relations‖ equivalent to collection of record types
➢ Relation: Two-dimensional table
➢ Stores information or data in the form of tables →rows and columns
➢ A row of the table is called tuple→equivalent to record
➢ A column of a table is called attribute equivalent to fields
➢ Data value is the value of the Attribute

Prepared by Instructor Senbeto K. Page 3

 Fundamentals of Database Systems: Course Module 2021/2022

➢ Records are related by the data stored jointly in the fields of records in two tables or files.
The related tables contain information that creates the relation
➢ The tables seem to be independent but are related somehow.
➢ Many tables are merged together to come up with a new virtual view of the relationship

Alternative terminologies
Relation = => Table = => File
Tuple = => Row = => Record
Attribute = => Column = => Field

3. Hierarchical Model
Developers recognized that data in a system as related to other data in the same system. This could be
modelled in hierarchies.
 The simplest data model
 Record type is referred to as node or segment. The top node is the root node. Nodes are arranged
in a hierarchical structure as sort of upside-down tree.
 A parent node can have more than one child node. A child node can only have one parent node
 The relationship between parent and child is one-to-many
 Relation is established by creating physical link between stored records (each is stored with a
predefined access path to other records)
 To add new record type or relationship, the database must be redefined and then stored in a new
form.

Eg 2. In hierarchical model, the customer record type would be at the top of the hierarchy.
Customer

has

Account

contains

Transaction
The legs on the links between the record types indicate a 1-to-many. This is the hierarchical structure. A
Customer has Accounts. An Account contains transactions.
A record is a collection of attributes or fields e.g. for Customer, the fields might be Name, Phone, Address.

Prepared by Instructor Senbeto K. Page 4

 Fundamentals of Database Systems: Course Module 2021/2022

For Account, the fields might be type (savings or current), account number and balance.
The tree represents parent-child relationships – one Customer can have many Account records associated
with it e.g. a savings Account and a current Account. An Account has Transactions associated with it (e.g.
deposit money, withdraw money).

4. Object-Oriented Model
The OO approach of defining objects that can be used in many programs is now also being applied to
database systems. An object can have properties (or attributes) but also behaviour, which is modelled in
methods (functions) in the object. The object-oriented data model, for example, extends the representation
of entities by adding notions of encapsulation, methods (functions), and object identity.

In an OO model, each type of object in the database’s mini-world is modelled by a class eg. Customer
class, Account class, like tables in the relational model. A class has properties (attributes). One advantage
of the OO model is sub-classes. For example, as there are different types of account, they can be modelled
as sub-classes of the Account class – SavingsAccount and CurrentAccount. This makes sense because the
different account types have some different behaviour e.g. gaining interest in a savings account but some
behaviour the same e.g. lodging or withdrawing cash. This is the inheritance concept of OO programming.

Diagram: class name at the top, properties in the middle, methods at the bottom.

SavingsAccount
Customer Account
InterestRate
CustomerID AccountNumber
Name Balance
PhoneNumber CustomerID CurrentAccount
Address
lodgeMoney OverdraftLimit
newCustomer withdrawMoney
removeCustomer
cashCheque
…

The database is seen as a collection of objects; objects that have similar properties are grouped into a class.
So, an entity is represented as a class. A class has attributes and behaviour. Subclasses inherits attributes
from the parent class

Example:
Department class – has attributes Department Number, Name, Manager
Employee class – has attributes Employee Number, Name, Salary
An instance of the Department class has one or more Employee members.
Manager is a sub-class of Employee – it inherits the attributes of an Employee.

Many developers are using OO databases now, but the relational model is still very widely used and
probably the most widely used.

 Assignment
1. Write the difference between the above four types of database models.

Prepared by Instructor Senbeto K. Page 5

 Fundamentals of Database Systems: Course Module 2021/2022

Database Schema
Database schema: is the overall description of the database, include explanation of the database
constraints that should hold on the database. A displayed schema is called a schema diagram. In the
schema diagram below, consider the schema of UNIVERSITY database.

STUDENT
StudentID Name Dept GPA

COURSE
CourseTitle CourseCode Credit_hours CourseOwnerDepartment

PREREQUISITE
CourseCode Prerequisite

SECTION
Section_identifier Course_number Semester Year Instructor

GRADE_REPORT
StudentID Section_identifier Semester Year Grade

We call each object in the schema—such as STUDENT or COURSE—a schema construct.

The Three level of schema according their abstraction: entity describes

 External schema: at the external level to describe the various user views. Usually uses the same
data model as the conceptual level.
 Conceptual schema: at the conceptual level to describe the structure and constraints for the
whole database for a community of users. Uses a conceptual or an implementation data model.
 Internal schema: at the internal level to describe physical storage structures and access paths.
Typically uses a physical data model.

Database Instances
The actual data in a database may change quite frequently. For example, the UNIVERSITY database
shown in above diagram changes every time we add a new student or enter a new grade. The data in the
database at a particular moment in time is called a database state or snapshot. It is also called the current
set of occurrences or instances in the database.

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.
 Since Instance is actual data of database at some point in time, changes rapidly.

Every time we insert or delete a record or change the value of a data item in a record, we change one state
of the database into another state. The distinction between database schema and database state is very
important. When we define a new database, we specify its database schema only to the DBMS. At this
point, the corresponding database state is the empty state with no data. We get the initial state of the
database when the database is first populated or loaded with the initial data. From then on, every time an
Prepared by Instructor Senbeto K. Page 6
 Fundamentals of Database Systems: Course Module 2021/2022

update operation is applied to the database, we get another database state. At any point
in time, the database has a current state. The DBMS is partly responsible for ensuring that every state of
the database is a valid state—that is, a state that satisfies the structure and constraints specified in the
schema. The DBMS stores the descriptions of the schema constructs and constraints—also called the
meta-data—in the DBMS catalog so that DBMS software can refer to the schema whenever it needs to.
The schema is sometimes called the intension, and a database state is called an extension of the schema.
Unlike database instance, the schema is not supposed to change frequently. Consider, we may decide to
add another data item to be stored for each record in a file, such as adding the Date_of_birth to the
STUDENT schema in university database above. This is known as schema evolution.

 Group discussion:
Discusses the main difference between the database schema and database instance?

2.2. DBMS Architecture and Data Independence

Three important characteristics of the database approach are (1) insulation of programs and data (program-
data and program-operation independence); (2) support of multiple user views; and (3) use of a catalog to
store the database description (schema). In this section we specify architecture for database systems, called
the three-schema architecture which was proposed to help achieve and visualize these characteristics.

The Three-Schema Architecture

The goal of the three-schema architecture is to separate the user applications and the physical database. In
this architecture, schemas can be defined at the following three levels:

1. The internal level has an internal schema, which describes the physical storage structure of the database.
The internal schema uses a physical data model and describes the complete details of data storage and
access paths for the database.
2. The conceptual level has a conceptual schema, which describes the structure of the whole database for
a community of users. The conceptual schema hides the details of physical storage structures and
concentrates on describing entities, data types, relationships, user operations, and constraints. A high-level
data model or an implementation data model can be used at this level.
3. The external or view level includes a number of external schemas or user views. Each external schema
describes the part of the database that a particular user group is interested in and hides the rest of the
database from that user group. A high-level data model or an implementation data model can be used at
this level.

Data Independence
The three-schema architecture can be used to explain the concept of data independence, which can be defined as
the capacity to change the schema at one level of a database system without having to change the schema at the
next higher level. We can define two types of data independence:
1. Logical data independence is the capacity to change the conceptual schema without having to change external
schemas or application programs. We may change the conceptual schema to expand the database (by adding a
record type or data item), or to reduce the database (by removing a record type or data item). In the latter case,
external schemas that refer only to the remaining data should not be affected.
2. Physical data independence is the capacity to change the internal schema without having to change the
conceptual (or external) schemas. Changes to the internal schema may be needed because some physical files had
to be reorganized—for example, by creating additional access structures—to improve the performance of retrieval
or update. If the same data as before remains in the database, we should not have to change the conceptual schema

Prepared by Instructor Senbeto K. Page 7

 Fundamentals of Database Systems: Course Module 2021/2022

2.3. Database Languages

In this section, it is explained how 'a data gets into a database system' and 'how the information gets to the users'.
More correctly formulated the following questions will be answered:
• How does an application interact with a database management system?
• How does a user look at a database system?
• How can a user query a database system and view the results in his/her application?
Data Definition Language (DDL)
For describing data and data structures a suitable description tool, a data definition language (DDL), is needed. With
this help a data scheme can be defined and also changed later.
Typical DDL operations (with their respective keywords in the structured query language SQL):
• Creation of tables and definition of attributes (CREATE TABLE ...)
• Change of tables by adding or deleting attributes (ALTER TABLE …)
• Deletion of whole table including content (!) (DROP TABLE …) etc
Data Manipulation Language (DML)
Additionally, a language for the descriptions of the operations with data like store, search, read, change, etc. the so-
called data manipulation, is needed.
Typical DML operations (with their respective keywords in the structured query language SQL):
• Add data (INSERT)
• Change data (UPDATE)
• Delete data (DELETE)
• Query data (SELECT) Etc….
Data Control Language (DCL)
A Data Control Language (DCL) is a computer language and a subset of SQL, used to control access to data in a
database.
Examples of DCL commands include:
• GRANT used to allow specified users to perform specified tasks.
• REVOKE used to cancel previously granted or denied permissions

2.4. DBMS Interfaces

❖ Menu-Based Interfaces for Browsing: These interfaces present the user with lists of options, called menus
that lead the user through the formulation of a request. Pull-down menus are becoming a very popular
technique in window-based user interfaces. They are often used in browsing interfaces, which allow a user
to look through the contents of a database in an exploratory and unstructured manner.
❖ Forms-Based Interfaces: A forms-based interface displays a form to each user. Users can fill out all of the
form entries to insert new data, or they fill out only certain entries, in which case the DBMS will retrieve
matching data for the remaining entries. Forms are usually designed and programmed for naive users as
interfaces to canned transactions.
❖ Graphical User Interfaces: A graphical interface (GUI) typically displays a schema to the user in
diagrammatic form. The user can then specify a query by manipulating the diagram. In many cases, GUIs
utilize both menus and forms. Most GUIs use a pointing device, such as a mouse, to pick certain parts of
the displayed schema diagram.
❖ Natural Language Interfaces: These interfaces accept requests written in English or some other language
and attempt to "understand" them. The natural language interface refers to the words in its schema, as well
as to a set of standard words, to interpret the request.
❖ Interfaces for Parametric Users: Parametric users, such as bank tellers, often have a small set of operations
that they must perform repeatedly. Systems analysts and programmers design and implement a special
interface for a known class of naive users.
❖ Interfaces for the DBA: Most database systems contain privileged commands that can be used only by the
DBA’s staff. These include commands for creating accounts, setting system parameters, granting account
authorization, changing a schema, and reorganizing the storage structures of a database.

Prepared by Instructor Senbeto K. Page 8

 Fundamentals of Database Systems: Course Module 2021/2022

The Database System Environment

 Reading Assignment
Read and prepare short notes about Database System Environment and Classification of Database
Management Systems

IV. Assessments:

1. A collection of data in the data base at the particular time?

o Database model
o Database instance
o Database schema
o Database architecture

2. What is database schema?

3. Responsible person who identifies the appropriate structure of the database.

Possible answers:

1. B
2. Schema: is the overall description of the database.
3. Database designer

Prepared by Instructor Senbeto K. Page 9

 Fundamentals of Database Systems: Course Module 2021/2022

CHAPTER THREE
Database Modelling
Unit description
In this unit E/R Model, Data Modeling using Entity Relationship, Database Design Using High level Data
Models, Entity types and Sets, Attributes and Keys, Database Abstraction, Relationships will be discussed.
To deliver these contents brain Storming and gap lecture, group discussion, question and answer methods
will be used. And the way of assessment will take place in the form of questioning and answer, group
work, individual assignment, lab assignment, test.
I.Objectives: At the end of this unit, students will be able to:
 Understand ER model
 Define Entity, Attributes, Keys, Relationships (components of ER Design)
 Differentiate the types of entity
 Differentiate E/R Diagram naming conventions, and Design issues
 Construct ERD
II. Contents:
3.1. Data Modeling using Entity Relationship (ER) Model
3.1.1. The high-level conceptual model
3.1.2. Entities, Attributes, and Keys
3.1.3. Relationships, Associations, and Constraints
3.1.4. The ER Diagrams
3.1.5. Mapping ER-models to relational tables
3.2. Enhanced Entity Relationship (EER) Model
3.2.1. Inheritance
3.2.2. Union
3.2.3. Aggregation and Association
3.2.4. Mapping EER model to relational model
3.3. The Relational Database Model
3.3.1. The Relational Model Concepts
3.3.2. The Relational Constraints and Relational Database Schemas
3.3.3. The Relational Operations
o Method of Teaching: brain storming, gap lecture, group discussion

3.1. Data Modeling using Entity Relationship Model (ER model)

The entity-relationship (E-R) data model perceives the real world as consisting of basic objects, called
entities, and relationships among these objects. It was developed to facilitate database design by allowing
specification of an enterprise schema, which represents the overall logical structure of a database. The E-
R data model is one of several semantic data models; the semantic aspect of the model lies in its
representation of the meaning of the data. The E-R model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema. Because of this
usefulness, many database-design tools draw on concepts from the E-R model.
Basic components of Entity-Relational (ER) Model includes:
1. Entities: real world physical or logical object
2. Attributes: properties used to describe each Entity or real-world object.
3. Relationship: the association between Entities
4. Constraints: rules that should be obeyed while manipulating the data.

Prepared by Instructor Senbeto K. Page 10

 Fundamentals of Database Systems: Course Module 2021/2022

4.1.1. Entities
The basic object that the ER model represents is an entity, which is a "thing" or ‘object’ in the real
world with an independent existence (that is distinguishable from all other objects). In ER model Entity
corresponds to entire table, not row and represented by Rectangle.

Entity Sets (Entity Types)

A database usually contains groups of entities that are similar. For example, a company employing
hundreds of employees may want to store similar information concerning each of the employees. These
employee entities share the same attributes, but each entity has its own value(s) for each attribute. An
entity type defines a collection (or set) of entities that have the same attributes.

An entity set is a collection (set) of entities that share the same properties, or attributes. The set of all
persons who are customers at a given bank, for example, can be defined as the entity set customer.
Similarly, the entity set loan might represent the set of all loans awarded by a particular bank. The
individual entities that constitute a set are said to be the extension of the entity set. Thus, all the individual
bank customers are the extension of the entity set customer. Entity sets do not need to be disjoint. For
example, it is possible to define the entity set of all employees of a bank (employee) and the entity set of
all customers of the bank (customer). A person entity may be an employee entity, a customer entity, both,
or neither.

For each attribute, there is a set of permitted values, called the domain, or value set, of that attribute. The
domain of attribute customer-name might be the set of all text strings of a certain length. A database thus
includes a collection of entity sets, each of which contains any number of entities of the same type.

4.1.2. Attribute
Each entity has attributes: the particular properties that describe it. For example, an employee entity may
be described by the employee’s name, age, address, salary, and job. Attributes are represented by oval
shape.
Types of Attributes
Several types of attributes occur in the ER model: simple versus composite; single-valued versus multi-
valued; and stored versus derived. First, define these attribute types and illustrate their use via examples.
Then after, introduce the concept of a null value for an attribute.

Composite versus Simple (Atomic) Attributes

Composite attributes 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 sub-divided into
City, Region, and Zip. Attributes that are not divisible are called simple or atomic attributes. The value
of a composite attribute is the concatenation of the values of its constituent simple attributes.
Composite attributes are useful to model situations in which a user sometimes refers to the composite
attribute as a unit but at other times refers specifically to its components. If the composite attribute is
referenced only as a whole, there is no need to subdivide it into component attributes. For example, if
there is no need to refer to the individual components of an address (Zip, Street, and so on), then the whole
address is designated as a simple attribute.

Single-valued Versus Multi-valued Attributes

Most attributes have a single value for a particular entity; such attributes are called single-valued. For
example, Age is a single-valued attribute of person. In some cases, an attribute can have a set of values
for the same entity—for example, Colors attribute for a car, or a college Degrees attribute for a person.
Prepared by Instructor Senbeto K. Page 11
 Fundamentals of Database Systems: Course Module 2021/2022

Cars with one color have a single value, whereas two-tone cars have two values for Colors. Similarly, one
person may not have a college degree, another person may have one, and a third person may have two or
more degrees; so different persons can have different numbers of values for the CollegeDegrees attribute.
Such attributes are called multivalued.

Stored Versus Derived Attributes

In some cases, two (or more) attribute values are related—for example, the Age and BirthDate attributes
of a person. For a particular person entity, the value of Age can be determined from the current (today’s)
date and the value of that person’s BirthDate. The Age attribute is hence called a derived attribute and
is said to be derivable from the BirthDate attribute, which is called a stored attribute. Some attribute
values can be derived from related entities; for example, an attribute NumberOfEmployees of a
department entity can be derived by counting the number of employees related to (working for) that
department.

Null Values
In some cases, a particular entity may not have an applicable value for an attribute. An attribute takes a
null value when an entity does not have a value for it. The null value may indicate “not applicable”—that
is, that the value does not exist for the entity. For example, one may have no middle name. Null can also
designate that an attribute value is unknown. An unknown value may be either missing (the value does
exist, but we do not have that information) or not known (we do not know whether or
not the value actually exists). For example, a CollegeDegrees attribute applies only to persons with college
degrees. For such situations, a special value called null is created.

Key attributes
A key attribute is an attribute or set of attributes in a relation that uniquely identifies each tuple in the
relation.

An important constraint on the entities of an entity type is the key or uniqueness constraint on attributes.
An entity type usually has one or more attributes whose values are distinct for each individual entity in
the entity set. Such an attribute is called a key attribute, and its values can be used to
identify each entity uniquely. For example, the Name attribute is a key of the COMPANY entity type in
because no two companies are allowed to have the same name. For the PERSON entity type, a typical key
attribute is Ssn (Social Security number). Sometimes several attributes together form a key, meaning that
the combination of the attribute values must be distinct for each entity. If a set of attributes possesses this
property, the proper way to represent this in the ER model that we describe here is to define a composite
attribute and designate it as a key attribute of the entity type.

Hence, it is a constraint that prohibits any two entities from having the same value for the key
attribute at the same time. It is not the property of a particular entity set; rather, it is a constraint on any
entity set of the entity type at any point in time. In ER diagrammatic notation, each key attribute has its
name underlined inside the oval.

Prepared by Instructor Senbeto K. Page 12

 Fundamentals of Database Systems: Course Module 2021/2022

Types of keys
 Super keys
 Candidate Keys
 Primary key
 Composite primary key.
 Alternate key
 Foreign key

 Reading assignment
Read and prepare short note about each type of keys listed above.

4.1.3. Relationships
The relationship between entities which exist must be taken into account when processing information. In
any business processing one object may be associated with another object due to some event. Such kind of

Prepared by Instructor Senbeto K. Page 13

 Fundamentals of Database Systems: Course Module 2021/2022

association is what we call a RELATIONSHIP between entity objects

➢ One external event or process may affect several related entities.
➢ Related entities require setting of LINKS from one part of the database to another.
➢ A relationship should be named by a word or phrase which explains its function
➢ Role names are different from the names of entities forming the relationship: one entity may take on
many roles, the same role may be played by different entities
➢ For each RELATIONSHIP, one can talk about the Number of Entities and the Number of Tuples
participating in the association. These two concepts are called DEGREE and CARDINALITY of a
relationship respectively.
Degree of Relationship
➢ An important point about a relationship is how many entities participate in it. The number of
entities participating in a relationship is called the DEGREE of the relationship.
➢ Among the Degrees of relationship, the following are the basic:
• UNARY/RECURSIVE RELATIONSHIP: Tuples/records of a Single entity are related
with each other.
• BINARY RELATIONSHIPS: Tuples/records of two entities are associated in a
relationship
• TERNARY RELATIONSHIP: Tuples/records of three different entities are associated
• And a generalized one: N-NARY RELATIONSHIP: Tuples from arbitrary number of
entity sets are participating in a relationship.
Cardinality of Relationship
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.
➢ ONE-TO-MANY, one tuple can be associated with many other tuples, but not the reverse.
➢ 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.
4.1.4. Relational Constraints (Integrity rules)
➢ Relational Integrity
• Domain Integrity: No value of the attribute should be beyond the allowable limits
• Entity Integrity: In a base relation, no attribute of a Primary Key can assume a value of
NULL.
• Referential Integrity: If a Foreign Key exists in a relation, either the Foreign Key value
must match a Candidate Key value in its home relation or the Foreign Key value must be
NULL.
• Enterprise Integrity: Additional rules specified by the users or database administrators of
a database are incorporated.

Weak entity type

• An entity that does not has a key attribute of their own are called weak entity types.
• It is an entity that cannot exist without the entity with which it has a relationship
• It is indicated by a double rectangle
• In contrast, regular entity types that do have a key attribute are sometimes called strong entity
types.

Prepared by Instructor Senbeto K. Page 14

 Fundamentals of Database Systems: Course Module 2021/2022

 Assessments:

1. Discuss the role of a high-level data model in the database design process.
2. Define the following terms: entity, attribute, attribute value, relationship instance, composite
attribute, multi-valued attribute, derived attribute, complex attribute, key attribute, value set
(domain).
3. What is an entity type? What is an entity set? Explain the differences among an entity, an entity
type, and an entity set.
4. E/R Diagram naming conventions, and Design issues

Prepared by Instructor Senbeto K. Page 15