Database Systems

(ECEg4172)
Prepared by Kelele G.

1
 Chapter 2
Database Design

2
Outlines
• Introduction
• Database design steps
• Conceptual design
• Crow’s Foot Notation
• Relational Database Design
• Logical design
• Physical design

3
Introduction
• Database Design is a collection of processes that facilitate the designing,
development, implementation and maintenance of enterprise’s,
company’s’ or organization’s data management systems according to
a database model.
▪ Enterprise’s, company’s or organization’s have two major components in
their working environment.
1) Process:- can be handled through application software.
2) Data: - can be managed through database.
▪ Database model:- can be
1) Hierarchical data model
2) Network data model
3) Relational data model

4
 Cont.…
• Database design involves classifying data and identifying interrelationships.
• Properly designed databases have the following characteristics
1) Easy to maintain
2) Improve data consistency and
3) Avoid redundancy
4) High performance
• The two most common techniques used to design a database include:-
1) Entity-Relationship (ER) Modelling: It’s a graphical database design approach
that models entities, their attributes, and defines relationships among these
entities to signify real-life objects. Mostly used in database conceptual design.
2) Normalization: a techniques used in such a way that it decreases data
redundancy and dependency. Larger tables are divided into smaller tables and
are linked together using relationships. Mostly used in database logical
design.

5
 Database design steps Database Designing Steps
✓ Within the real world, there exists
App Development Steps many aspects(problems) that can be
converted into apps and database.
✓ Through interview, questionnaire,
observation and document analysis;
the requirements will get gathered
and the existing problems can be
clearer to the app developers and
database designer.
✓ While requirement analyzing,
problem’s process and data can be
separated effectively, and handled
separately. The processes will be
handled by the app developer, and
the data can be handled by the
database designer.

6
Requirement Analysis
• Done after requirement collection is done.
• Ambiguity and feasibility problems will get identified and will be
discussed with the stakeholders.
• Objects and their attributes will get identified.
• Interaction in between objects will get identified.

7
Conceptual Design
• Model data requirements in to develop a high-level description of the data
to be stored in the database
• This approach enables database designers to concentrate on specifying the
properties of the data, without being concerned with storage and
implementation details.
• Can be modelled using entity-relationship data model.
• The ER data model views the real-world aspects as a set of
▪ Objects (Entities), and
▪ Relationships among these objects.
• The three basic notions of the ER data model are:-
1) Entity
2) Attribute
3) Relationship

8
 Cont.…
• Entities are usually recognizable concepts, either concrete or abstract, such
as:
▪ Person, department, instructor, student, course, place, thing, or events which have
relevance to the database.
▪ Entity Set is a set consisting of the same type of entities that share same properties.
An entity is described using a set of attributes. All entities in a given entity set have
the same attributes.
▪ Instance is also known as Object, is an individual occurrence of an entity set.
▪ While analyzing problem, the entities are recognized by nouns and noun phrases.
• Entities can be classified as:-
1) Strong (independent) entity:- One that does not rely on other entities for
identification.
2) Weak (dependent) entity:- one that relies on other entities for identification.

9
 Cont.…
• A strong entity is an entity which has its own unique key that can uniquely
identify it from other similar entities and can exist in the database system
independently.
• A weak entity is uniquely identified with the help of other strong entity.
• A weak entity can not exist in the database system without a strong entity
which owns it.
• For example:-
1) Within flight booking, a booking entity can be created if and only if a customer
entity is created. Implies, a customer entity owns booking entity.
2) Within ecommerce, an order entity can be created if and only if a customer entity
is created. Implies, a customer entity owns order entity.
• Weak entity attribute/s are called discriminators.
10
 Cont.…
• Attributes are descriptive properties that are associated with an
entity.
▪ Value is a particular instance of an attribute.
▪ Domain of an attribute is the collection of all possible values an attribute can
have.
▪ For example:-
✓ A Person entity can be described by attributes first name, middle name, last name, birth
date and more . . .
✓ A Department can be described by attributes department name, department
description and more . . .
✓ A Course can be described by attributes course name, course code, course description,
credit hour and more . . .

11
 Cont.…
• Classification of Attributes
1) Identifiers:- more commonly called keys, that can uniquely identify an
instance of an entity. Each identifier are candidate key, and one of them can
be primary key.
2) Descriptors:- describes a non-unique characteristic of an entity instance.
▪ For example:-
✓A Student entity can be described by the attribute's student id, name, gender,
birth date, address etc. Here as you all know, within the UoG’s SIS, no two or
more students can have the same student id(means this student id uniquely
identifies a student, called identifier) but can have the same name or birth date
or gender, called descriptors.

12
 Cont.…
3) Composite attributes:- can be divided into smaller parts, which represent
more basic attributes with independent meanings.
▪ For example:-
✓A Student entity can be described by the attribute's student id, name,
gender, birth date, age, address, degree etc.
✓But here, the name can be divided into first name, middle name, and last
name independent attributes.
✓And, the address can be divided into street name, city, state, phone
number, email independent attributes.
4) Atomic attributes:- attributes that are not divisible are called simple or
atomic attributes. Such as student id, student's gender and student’s birth
date, age, and degree.

13
 Cont.…
3) Single-valued attributes:- most attributes have a single value for a
particular entity; such attributes are called single-valued.
▪ For example:-
✓Age, birth date are a single-valued attribute of a Student.
4) Multi-valued attributes:- some attribute may have multiple values.
▪ For example
✓a Student may not have a college degree, another Student may have one,
and a third Student may have two or more degrees; therefore, different
people can have different numbers of values for the degrees attribute.

14
 Cont.…
5) Derived attributes:- In some cases, two or more attribute values are
related.
▪ For example:-
✓The Age and Birth date attributes of a Student. For a particular Student
entity, the value of Age can be determined from the current date and the
value of that Student’s Birth date.
✓The Age attribute is hence called a derived attribute and is said to be
derivable from the Birth date attribute.
6) NULL Values:- In some cases, a particular entity may not have an applicable
value for an attribute.

15
 Cont.…
• Relationship represents an association between two or more entities.
▪ For example:-
✓A Department contains Students.
✓A Department contains Instructors.
✓An Instructors manages a department.
✓A Student takes courses.
▪ Classification of relationships:-
1) Degree of relationship:- describe the number of entity types that are
participating in a relationship type.
2) Cardinality of relationship:- the cardinality ratio for a binary
relationship specifies the maximum number of relationship instances
that an entity can participate .

16
 Cont.…
• Degree of relationship
1) Unary(recursive) relationship:- this kind of relationship is occurred when an
entity is related with itself.
2) Binary relationship:- this kind of relationship is occurred when two entities
are related to other.
3) Tertiary relationship: - this kind of relation is occurred when

17
 Cont.…
• Cardinality of relationship
a) one-to-one
b) one-to-many
c) many-to-many

▪ For example:-

18
 Cont.…
• ER data model is represented using ER-diagram symbols. Such as

19
 Cont.…
• Example-1:-
▪ A Department entity can be ▪ Associating the Department entity
represented like, Department with it’s attributes

▪ The attributes that can define the Code

Department entity
For:-
✓ Department code Code Name

Department
✓ Department name Name Description

✓ Department description Description

20
 Cont.…
• Example-2:-
▪ A Course entity can be represented ▪ Associating the Course entity with
like, Course it’s attributes

▪ The attributes that can define the Code

Course entity
For:-
✓ Course code Code Title

Course
✓ Course title Title Hour

✓ Course hour Hour

21
 Cont.…
• Example-3:-
▪A Student entity can be ▪ Associating the Student entity
represented like, Student with it’s attributes

▪ The attributes that can define the phone Id

Student entity Id Name

Name Gender

Gender Birthdate
Student
Birthdate Address

Address Age

Age email 22
 Cont.…
• More on Student entity:-
• The Student name can be divided • The Student addres can be divided
into subparts, more independent into subparts, more independent
attributes, such as first name, attributes, such as first name,
middle name, last name. middle name, last name.
representing it in a diagram representing it in a diagram
Firstname Streetname

Name Middlename City

Address State
Lastname

23
 Cont.…
• More on Student entity:-
• The Student age can be derived or • Finally, the Student will be
calculated from the Student birth represented like this,
date. Firstname phone email
Age
Middlename Id
Id
Lastname Name
Name
Streetname Gender
Gender Student
City Birthdate
Birthdate
State Address
Address
Age
24
phone
 Cont.…
• Example-4:- defining a relationship between the entities Department and Student.
▪ A Department contains Students. Lastname

Firstname
Name
Middlename
Code
Id
Contains Student
Gender
Name

Birthdate
Description Department Address
Age

email

City Streetname State phone

25
 Cont.…
• More on the relationship between the entities Department and Student.
▪ Adding cardinality, a Department can have one or more Students, and Lastname
a Student only have one Department. Firstname
Name Middlename
Code
1, * Id
Contains Student
Gender
Name
1
Birthdate
Description Department Address
Age

email

City Streetname State phone

26
 Cont.…
• Example-5:- defining a relationship between the entities Course and Student.
▪ A Department contains Students. Lastname

Firstname
Name
Middlename
Code
Id
Takes Student
Gender
Title

Birthdate
Hour Course Address
Age

email

City Streetname State phone

27
 Cont.…
• More on the relationship between the entities Course and Student.
▪ Adding cardinality, a Student can take one or more Courses, and a Lastname
Course can be taken by many Students. Firstname
Name
Middlename
Code
1,* Id
Takes Student
Gender
Title
1, *
Birthdate
Hour Course Address
Age

email

City Streetname State phone

28
 Cont.…
• Example-6:- defining a relationship between the entities Course and Department.
▪ A Department contains Courses.

Code
Has Department
Code

Name
Title

Description
Course
Hour

29
 Cont.…
• More on the relationship between the entities Course and Student.
▪ Adding cardinality, a Department can have one or more Courses, and a Course has
only one Department.

1
Code
Has Department
Code

Name
Title
1,*
Description
Course
Hour

30
 Cont.…
• The ER diagram that can define the relationship between Department, Course and Student will look like
the diagram below.
Lastname
Code Firstname
Department 1 Name
Name Middlename
1
Description 1, *
Contains Id
Student
1,* Gender
Has
Takes
Birthdate
Address
1, * 1, * Age
Code
Course
Title email
Streetname
Hour City State phone
31
 Cont.…
• More on the ER diagram, let’s say a Student can have one or more
phones, and can have also one or more emails.
▪ So, this requirement makes student’s phone as a multi-value attribute
of the Student entity.
▪ So, this requirement makes student’s email as a multi-value attribute of
the Student entity.

32
 Cont.…
• The ER diagram that can define the relationship between Department, Course and Student will look like
the diagram below.
Lastname
Code Firstname
Department 1 Name
Name Middlename
1
Description 1, *
Contains Id
Student
1,* Gender
Has
Takes
Birthdate
Address
1, * 1, * Age
Code
Course
Title email
Streetname
Hour City State phone
33
Crow’s Foot Notation
• Understanding a relationship and
cardinality between entities are vital
in modelling a database system.
• While working with the conceptual
database design, we can make it
more technical by defining the
existing entities' relationship
cardinality using crow’s foot
notation symbols.

34
 Cont.…
• The ER diagram that can define the relationship(a relationship defined with crow’s foot notations) between
Department, Course and Student will look like the diagram below.
Lastname
Code Firstname
Department Name
Name Middlename
Description
Contains Id
Student
Gender
Has
Takes
Birthdate
Address
Code Age

Title Course email

Streetname
Hour City State phone
35
Participation constraints in relationship
• Participation constraint specifies whether the existence of an entity
depends on its being related to another entity via the relationship type.
• There are two types of participation constraints:-
1) Total Participation
2) Partial Participation
• Total participation refers to, every instances of an entity type participating
a relationship, which will be represented using double line in the half-way
of totally participating entity type.
• Partial participation refers to, some instances of entity type participating
in a relationship, which will be represented using single line in the half-way
of partially participating entity type.

36
 Cont.…
• The ER diagram that can define the relationship(a relationship defined with crow’s foot notations) between
Department, Course and Student will look like the diagram below.
Lastname
Code Firstname
Department Name
Name Middlename
Description
Contains Id
Student
Gender
Has
Takes
Birthdate
Address
Code Age

Title Course email

Streetname
Hour City State phone
37
 Cont.…
Entity Type Relationship Type Entity Type Entity Type Relationship Type Entity Type

Department Has Course Department Has Course

R1 C1 D1 R1 C1
D1
R2 C2 D2 R2 C2
D2
R3 C3 D3 R3 C3

R4 C4 D4 R4 C4

- Department and Course are called Entity Type, Has is called - As you can see, in this relationship, all course
relationship type.
- D1 and D2(both called department entity set) are instances of instances are participated in the relationship,
Department Entity, and C1, C2, C3, C4(all called course entity set) called course entity has total participation, while
are instances of Course Entity. department instances D3 and D4 are not
- As you can see, in this relationship, all department and course
participating in the relationship, called
instances are participated in the relationship, called both have
total participation. department entity has partial participation. 38
Exercise
• Suppose a company manager wants a database system for his company and asked you to
develop it and gave you the following requirements.
✓The company is organized into departments. Each department has a unique name, a
unique number, and a particular employee who manages the department. We keep
track of the start date when that employee began managing the department. A
department may have several locations.
✓A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
✓We store each employee’s name, Social Security number, address, salary, gender, and
birth date. An employee is assigned to one department, but may work on several
projects, which are not necessarily controlled by the same department. We keep
track of the current number of hours per week that an employee works on each
project. We also keep track of the direct supervisor of each employee (who is
another employee).
✓We want to keep track of the dependents of each employee for insurance purposes.
We keep each dependent’s first name, sex, birth date, and relationship to the
employee.
39
Solution
• Analyzing the requirements:-
✓The company is organized into departments. Each department has a unique name, a
unique number, and a particular employee who manages the department. We keep
track of the start date when that employee began managing the department. A
department may have several locations.
✓A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
✓We store each employee’s name, Social Security number, address, salary, gender,
and birth date. An employee is assigned to one department, but may work on
several projects, which are not necessarily controlled by the same department. We
keep track of the current number of hours per week that an employee works on
each project. We also keep track of the direct supervisor of each employee (who is
another employee).
✓We want to keep track of the dependents of each employee for insurance purposes.
We keep each dependent’s first name, sex, birth date, and relationship to the
employee.

40
Cont.…

• An entity type Department has the

following attributes:-
✓Name(identifier, atomic, single-
valued)
✓Number(identifier, atomic, single-
valued)
✓Manager(descriptor, atomic, single-
valued)
✓Manager start date(descriptor,
atomic, single-valued)
This attribute shows, the Department entity has
✓Locations(descriptor, atomic, multi- a relationship with Employee entity.
valued)

41
Cont.…

• An entity type Project has the following

attributes:-
✓Name(identifier, atomic, single-
valued)
✓Number(identifier, atomic, single-
valued)
Department
✓Controlling department(descriptor,
atomic, single-valued)
✓Location(descriptor, atomic, single-
valued) This attribute shows, the Project entity has a
relationship with Department entity.

42
 This attribute shows, the Employee entity has a
relationship with Project(can participate in
Cont.… multiple projects) entity.

• An entity type Employee has the following

attributes:-
✓ Name(identifier, composite, single-
valued)
✓ SSN(identifier, atomic, single-valued)
✓ Department(descriptor, atomic, single-
valued)
✓ Address(descriptor, atomic, single-
valued)
✓ Supervisor(descriptor, atomic, single-
valued)
✓ Salary(descriptor, atomic, single-
valued) This attribute shows, the Employee entity has a
✓ Sex(descriptor, atomic, single-valued) relationship with Department entity.

43
 This attribute shows, the Dependent entity has a
Cont.… relationship with Employee entity.

• An entity type Dependent has the

following attributes:-
✓Dependent Name(identifier,
atomic, single-valued)
✓Birth Date(identifier, atomic, single-
valued)
✓Employee(descriptor, atomic,
single-valued)
✓Sex(descriptor, atomic, single-
valued)
✓Relationship(descriptor, atomic,
single-valued)

44
FINAL COMPANY’S DATABASE
CONCEPTUAL SCHEMA.

45
ER Diagram Tools
• Lucidchart
• Visio
• Gliffy
• Visual Paradigm
• SmartDraw
• SqlDBM
• DbDiagram
• Cacoo
• EdrawMax
• Draw.io

46
Relational Database
Design
Logical Design

47
 Example:- based on the above-mentioned Course entity, it
will be converted into relation or table as follows. Its table

Cont.…
name will the same as the entity name in conceptual
design, which is course.
Columns
• A RELATIONAL DATABASE is a type of
database that stores data in tables, so it can
be used in relation to other stored datasets.
▪ Often, data in a relational database is
code title hour
organized into relations called tables.
Table contains columns and rows. ECEg4172 Database Systems 3
▪ Tables can have hundreds, thousands,
sometimes even millions of rows of data, ECEg4182 Software Engineering 3
often called records.
▪ Tables can also have many columns of ECEg3143 OOP 3
data. Columns represents the entity’s
attributes and are labelled with a ECEg5193 Advanced Computer Networks 3
descriptive name.
▪ Structured Query Language (SQL), is a ECEg4192 Computer Network Security 3
standard language for interacting with
RDBMS.
ECEg4161 Micro-computer and 3
▪ For starting relational DB design Each
entities of conceptual design should be interfacing
converted into relation.

Can be called tuple, or row, or record. The actual data of DB is stored

in a row. In this table, there are 6 rows, which is 6 records of course. 48
Cont.…
• Properties of Relational Tables:- Example:- course table
▪ Values Are Atomic
code title hour
▪ Each Row is Unique(because of the
identifier attribute) ECEg4172 Database Systems 3
▪ Column Values are of the Same
ECEg4182 Software Engineering 3
Kind(have the same data type)
▪ The Sequence of Columns is ECEg3143 OOP 3
Insignificant
ECEg5193 Advanced Computer Networks 3
▪ The Sequence of Rows is Insignificant
▪ Each Column Has a Unique Name ECEg4192 Computer Network Security 3
▪ Every table should have a unique name
and should be named after the entity ECEg4161 Micro-computer and 3
name. interfacing

49
 Cont.…
• Examples of RDBMS:-
▪ Microsoft SQL Server
▪ MySQL
▪ Oracle
▪ IBM DB2
▪ Microsoft Access
▪ PostgreSQL etc.

50
Logical Design
• Logical design is the actual implementation of the database; the conceptual schema is
transformed from the high-level data model into the implementation data model using a
commercial DBMS.
• DBMSs use an implementation data mode. Such as
✓ Hierarchical data model
✓ Network data model
✓ Relational data model or
✓ Object relational data model
• The implicit goals of the design activity are information preservation and minimum
redundancy.
• Minimizing redundancy implies minimizing redundant storage of the same
information and reducing the need for multiple updates to maintain consistency
across multiple copies of the same information in response to real-world events that
require making an update

51
Cont.…
- High level description of data to be stored
- Modelled using ER data modelling
➢ Uses top-down design approach
(methodology) while identifying Entity.
- Conceptual Schema is the final output of this phase.
- DBMS independent

- Requires conceptual design

- Models detail implementation of a database
- Modelling handled using normalization
➢ Uses bottom-up design approach
(methodology) while identifying Entity.
- Logical Schema is the final output of this phase.
- DBMS dependent, implies the design should be
dependent upon specific data modeling.

52
 • Bottom-up Design Approach:- this kind of
Cont.… approach is the process of defining Attributes
that can define an entity at first, then specifying
the entity.
• Top-Down Design Approach:- this kind of approach is ▪ This kind of approach is mostly used on
the process of defining Entity at first, then identifying its logical database design/relation database
attributes. design.
▪ This kind of approach is mostly used on
requirement analysis and conceptual design Attr3 Attr3 Attr3 Attr4

Entity

Entity

Attr1 Attr2 Attr3 Attr4…

53
Functional Dependency
• Functional dependency is a constraint that determines the relation of one attribute to
another attribute in a database table.
▪ It helps in preventing data redundancy and gets to know about bad designs.
• Suppose that our relational database schema has n attributes A1, A2, ..., An. Or
relation(table) schema R = {A1, A2, ... , An}.
• A functional dependency, denoted by X → Y, between two sets of attributes X and Y that
are subsets of R specifies a constraint on the possible tuples that can form a relation
state r of R.
▪ The constraint is that, for any two tuples t1 and t2 in relation that have t 1[X] = t 2[X],
they must also have t 1[Y] = t 2[Y]. This is called functional dependency from X to Y.
X is called determinant attribute
Y is called dependent attribute
• A relation attributes should be full dependent on the primary key of the relation

54
Cont.…
• Example:- let’s see the course Example:- course table
relation/table.
▪ The course code is the only identifier code title hour
attribute in the relation, which is the
primary key. This implies primary ECEg4172 Database Systems 3
key(identifier) attribute identifies the
relation descriptors or the rest attributes ECEg4182 Software Engineering 3
of the relation.
▪ Such as code->title, the code attribute’s ECEg3143 OOP 3
value determines the title attribute’s
value.
ECEg5193 Advanced Computer Networks 3
▪ Let’s check the title for code
=“ECEg4172”; the title is =“Database
Systems”. ECEg4192 Computer Network Security 3
▪ FD: code->{title}, and code->{title, hour}
▪ In this example, if we know the course ECEg4161 Micro-computer and 3
code, we can obtain course title and its interfacing
credit hour

55
Normalization
• The normalization process that takes a relation schema through a
series of tests to certify whether it satisfies a certain normal form.
• Normalization of data can be considered a process of analysing the
given relation schemas based on their FDs and primary keys.
• It can be considered as a “filtering” or “purification” process to make
the design have better quality.
• Unsatisfactory relation schemas that do not meet certain conditions of the
normal form tests are decomposed into smaller relation schemas that meet
the tests and hence possess the desirable properties.

56
 Cont.…
• Redundancy means having multiple copies of same data in the database. This problem arises
when a database is not normalized.
▪ Redundant data results insertion anomalies, update anomalies and deletion anomalies
▪ Example:- Suppose a table of student details attributes are: student Id, student name,
faculty, department.

Id Name Department Faculty

GUR/1234/2021 Abebe Electrical and Computer Engineering Technology
GUR/1235/2021 Habtu Electrical and Computer Engineering Technology
GUR/1236/2021 Kassa Electrical and Computer Engineering Technology
GUR/1237/2021 kalab Electrical and Computer Engineering Technology
GUR/1238/2021 Tsegaye Electrical and Computer Engineering Technology

57
 Cont.…
• Insertion Anomaly:-
▪ If a student detail has to be inserted whose department is not being decided yet, then
insertion will not be possible till the time course is decided for student.
Id Name Department Faculty
GUR/1239/2021 Makda No data given Technology

▪ This problem happens when the insertion of a data record is not possible without adding
some additional unrelated data to the record.
• Deletion Anomaly:-
▪ If the details of students in this table is deleted, then the details of Faculties and departments
will also get deleted which should not occur by common sense.

58
 Cont.…
• Update Anomaly:-
▪ Suppose if the faculty name changes, then changes will have to be all over the
database which will be time-consuming and computationally costly.
Id Name Department Faculty
GUR/1234/2021 Abebe Electrical and Computer Engineering Technology
GUR/1235/2021 Habtu Electrical and Computer Engineering Technology
GUR/1236/2021 Kassa Electrical and Computer Engineering Technology
GUR/1237/2021 kalab Electrical and Computer Engineering Technology
GUR/1238/2021 Tsegaye Electrical and Computer Engineering Technology

Updating all these values is required

59
 Cont.…
• The normalization procedure provides database designers with the following:-
1) A formal framework for analysing relation schemas based on their keys and on the
functional dependencies among their attributes
2) A series of normal form tests that can be carried out on individual relation schemas so that
the relational database can be normalized to any desired degree
• The normalization process has five consequential normal forms:-
1) 1st Normal Form(1NF)
2) 2nd Normal Form(2NF)
3) 3rd Normal Form(3NF, or Boyce-Codd normal form (BCNF))
4) 4th Normal Form(4NF)
5) 5th Normal Form(5NF)
• The first three normal forms makes a database non-redundant, consistent and
high performance; thus, a database designer does not have about the 4th and 5th
normal forms.

60
 Cont.…
• Advantages of normalization
▪ Greater overall database organization will be gained.
▪ The amount of unnecessary redundant data is reduced.
▪ Data integrity is easily maintained within the database.
▪ The database and application design processes are much more flexible.
▪ Security is easier to manage.
▪ Improving data consistency.
▪ Minimizing the insertion, deletion, and update anomalies.

61
Definitions of keys and attributes
participating in keys:-

• KEYS in DBMS is an attribute or set of

attributes which helps you to identify a
row(tuple) in a relation(table).
• 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.
• Key allows you to establish a
Composite Key
relationship between tables.

62
 Cont.…
Every entity should be converted into
relation(table) while designing relational
database design. Here, the Department
• Example:- let’s see the Department entity is converted into relation as shown
entity. below.

code Name Description

ECEg Electrical Engineering description

MechEg Mechanical Engineering description

CiEg Civil Engineering description

ChemEg Chemical Engineering description

The Code and Name are identifier attributes of the

Department entity. They are unique.
63
Cont.…
• Primary key:-
▪ It is relation’s key which is used to identify one Code Name Description
and only one instance of an entity uniquely.
ECEg Electrical Engineering description
▪ Example:- An entity can contain multiple keys
as we saw in Department table. The key which MechEg Mechanical Engineering description
is most suitable from those lists become a
primary key. CiEg Civil Engineering description
▪ In the Department table, Code can be
primary key since it is unique for each
Department. In the Department table, we can ChemEg Chemical Engineering description
even select Name as primary key since they
are also unique.
▪ For each entity, selection of the primary key is
based on requirement and developers.
▪ Then, the primary key will be used as foreign
key to state the relationship with other entity.

64
Cont.…
• Composite key:-
▪ It is a combination two or more keys CourseCode StudentId Semester
that can identify a record from other,
ECEg4172 GUR/1234/2021 1
most they are two or more foreign keys
referenced in a relation. ECEg4161 GUR/1234/2021 1

65
Cont.…
• Candidate key:-
▪ A candidate key is a unique attribute or set Code Name Description
of an attribute which can uniquely identify
a tuple or record or instance of an entity. ECEg Electrical Engineering description
And one of the candidate keys will
designated as primary key and the others MechEg Mechanical Engineering description
are called secondary key.
▪ The remaining unique attributes except for CiEg Civil Engineering description
primary key are considered as a candidate
key.
▪ Here, Code and Name are the candidate ChemEg Chemical Engineering description
keys.
▪ In the table to the right, Code is the
primary key, but the Name is also unique
attribute.
▪ Every unique attribute in a relationship is
candidate key.

66
Cont.…
• Super key:-
▪ A super key is an attribute or set of an Code Name Description
attribute which can uniquely identify a tuple
or record or instance of an entity.
▪ A super key is a set of an attribute which can ECEg Electrical Engineering description
uniquely identify a tuple.
▪ Super key is a superset of a candidate key MechEg Mechanical Engineering description
▪ Example, In the Department table, the
Description of two Department can be the CiEg Civil Engineering description
same, but their Code can't be the same.
Hence, this combination can also be a key.
▪ The super keys could be{Code, (Code, Name, ChemEg Chemical Engineering description
(Code, Description), (Code, Name,
Description))etc.
▪ Any key such as super key, primary
key, candidate key etc. can be called
composite key if it has more than one
attributes.
▪ Super Key is a superset of Candidate key.

67
 Code Name Description

Cont.… ECEg Electrical Engineering description

MechEg Mechanical Engineering description

• Foreign key:-
▪ A foreign key is the column of the table which CiEg Civil Engineering description
is used to point to the primary key of another
table.
▪ Example:- see the ER diagram below and the Primary Key
relations represented to the right.
Foreign Key
▪ Representing this ER diagram, Department’s
relation primary key will be referenced within Code Title Hour DepartmentCode
the Course relation.
▪ The one’s side primary key goes to the many ECEg4172 Database 3 ECEg
side relation as a foreign key to express their Systems
relationship
ECEg4182 Software 3 ECEg
Engineering

ECEg3143 OOP 3 ECEg

68
First Normal Form(1NF)
• First normal form disallows multivalued attributes, composite
attributes, and their combinations.
• A relation is in 1NF iff:-
▪ The attributes are atomic (simple, indivisible) values and that the value of
any attribute in a tuple must be a single value from the domain values(data
types) of that attribute.
▪ Each column have a unique name.
▪ Duplicate rows, with same primary key is not allowed.
▪ Null values in a relation are avoided or minimized.
▪ Redundant data are avoided.

Note: Order of column or row doesn’t matter.

69
 Cont.…
Example:- let’s work with the following conceptual design.

70
 (a) Department schema
Cont.…
• Converting the Department entity
into relation and normalizing it with
1Nf or not.
(b) Department relation with sample data
1) It has no composite attribute
2) It has no multi-valued attribute Id Code Name Description

3) It has null value 1 ECEg Electrical Engineering description

• Code is the primary key, and Code , 2 MechEg Mechanical Engineering description
Name are candidate keys.
3 CiEg Civil Engineering description

4 ChemEg Chemical Engineering description

71
 Cont.… (a) Department schema

• But, we have also to represent the

relationship that Department entity has
with Course entity.
• In relational database, representing a (b) Department relation with sample data
relationship with relations is handled by
moving one’s entity primary key to the id Code Name Description CourseCode
relating entity.
1 ECEg Electrical Engineering description ECEg4172
• As you can see in the Figure(b),
department-course has one-many
relationship. So, for the purpose of 2 ECEg Electrical Engineering description ECEg4182
representing the relationship, department
information has represented redundantly,
results DB operation anomalies. 3 CiEg Civil Engineering description CiEg4182
• In 1NF, redundancy should be removed.
Thus, this schema Figure(a), can’t be 4 CiEg Civil Engineering description CiEg4182
Department’s schema because it contains
redundant records.
72
 Cont.… (a) Department schema

• Again, we have also to represent the

relationship that Department entity has
with Student entity.
(b) Department relation with sample data
• In relational database, representing a
relationship with relations is handled by id Code Name Description StudentId
moving one’s entity primary key to the
relating entity. 1 ECEg Electrical Engineering description GUR/1234/2021
• As you can see in the Figure(b),
department-student has one-many 2 ECEg Electrical Engineering description GUR/1235/2021
relationship. So, for the purpose of
representing the relationship, department
information has represented redundantly, 3 CiEg Civil Engineering description GUR/1236/2021
results DB operation anomalies.
• In 1NF, redundancy should be removed. 4 CiEg Civil Engineering description GUR/1237/2021
Thus, this schema Figure(a), can’t be
Department’s schema because it contains
redundant records.
73
 Cont.…
• The Department schema which is in 1NF with no composite
attributes only atomic attributes, with no multi-valued attributes only
singled-value attributes, no redundancy, and no attribute that can
contain null value.
• Thus, the final Department entity’s relation schema will be
represented as follow.

(a) Department schema

74
 (a) Course schema
Cont.…
• Converting the Course entity into relation and
normalizing it with 1Nf or not.
1) It has no composite attribute
2) It has no multi-valued attribute
3) It has null value
(b) Course relation with sample data
• Code is the primary key; it is also called
candidate key.
id Code Title Hour

1 ECEg4172 Database Systems 3

2 ECEg4182 Software Engineering 3

3 ECEg3143 OOP 3

75
 Cont.… (a) Department schema

• But, we have also to represent the

relationship that Course entity has Primary Key
with Department entity.
• In relational database, representing a
relationship with relations is handled (b) Course schema Foreign Key
by moving one’s entity primary key to
the relating entity.
• As you can see in the Figure(b),
course-department has many-one
relationship. So, for the purpose of (c) Course relation with sample data
representing the relationship,
Department’s primary key is repeated id Code Title Hour DepartmentCode
within the Course relation, which is
expected and correct. 1 ECEg4172 Database Systems 3 ECEg
• Figure(b) represents the correct 2 ECEg4182 Software Engineering 3 ECEg
course-department relationship in
relational database.
76
 Cont.… (a) Course schema Foreign Key Foreign Key

• Again, we have also to represent the

relationship that Course entity has with
Student entity.
(b) Course relation with sample data
• In relational database, representing a
relationship with relations is handled by id Code Title Hour DepartmentCode StudentId
moving one’s entity primary key to the
relating entity. 1 ECEg4172 Database 3 ECEg GUR/12/32
Systems
• As you can see in the Figure(b), Course-
Student has many-many relationship. 2 ECEg4172 Database 3 ECEg GUR/13/32
So, for the purpose of representing the Systems
relationship, course information has
represented redundantly, which results 3 ECEg3143 OOP 3 ECEg GUR/14/32
DB operation anomalies as a single
4 ECEg3143 OOP 3 ECEg GUR/15/32
course can be taken by many students.
• Figure(b) represents the relationship 5 ECEg3143 OOP 3 ECEg GUR/16/32
where one course can be taken by many
students. 77
 Cont.…
• Based on the above scenario, course-student relationship can not be represented as
it creates redundant course information.
• The Course schema which is in 1NF with no composite attributes only atomic
attributes, with no multi-valued attributes only singled-value attributes, no
redundancy, and no attribute that can contain null value.
• Thus, the final Course entity’s relation schema will be represented as follow. The
relationship between Department-Course which is one-many is done by referring
Department’s primary key within the Course schema instead of referring Course’s
primary key within Department’s schema because it creates redundant department
information.

(a) Course schema

78
 Cont.…
• Converting the Student entity into
relation and normalizing it with 1Nf or
not. The entity has
1) It has two composite
attributes, namely student’s
name(first name, middle
name, last name) and
address(state, city, street
name).
2) It has two multi-valued
attributes, namely email and
phone.
• Id is the primary key; it is also called
candidate key.
 Cont.…
• The Student entity will be represented as a relation as follows:-
(a) Student schema

(b) Student schema with sample data

Id Name Address Gender BirthDate Age Phone Email

1 X, Y, Z 123 M 2000 21 911, 912, 913 [email protected], [email protected],

[email protected]

2 A, B, C 124 M 2000 21 915 [email protected]

80
 Cont.…
• As you can in the previous slide, Figure(b),
▪ The Student relation has column called Name which contains three sub-attributes’ values.
Suppose you want to update student’s middle name whose Id is GUR/1234/2021, how can
you do it? It will be difficult.
• 1NF says, every relation’s column must have only an atomic attribute and should be single-
valued. Mostly, the probability of composite attribute becoming NULL is low; they are always
required. So, let’s remove the base attribute called Name and Address, and make the sub-
attributes as independent column like below and make them atomic attributes;
Street BirthD Ag
Id Fname Mname Lname State City name Gender ate e Phone Email

1 X Y Z Am Gon colleg M 2000 21 911, [email protected],

e 912, [email protected],
913 [email protected]

2 A B C Oro wol colleg M 2000 21 915 [email protected]

e
81
 Cont.…
• In 1NF rule, within a relation, a column must not be multi-valued because
performing database operations like reading and updating or deleting will make it
difficult. Thus, it should be removed and handled using another way.
• Here, within this relation there are two multi-valued attributes, namely phone
and email.
• So, lets deal with the phone attribute:-
• THE FIRST OPTION is, making into separate columns as phone1, phone2, phone3 .
. . . but the question is how many columns? How many student’s phone number
needed for registration? This should be clearly defined in the requirement.
• Mostly, multi-valued attributes are not all always mandatory; i.e., some students
have may have two or more phones others may have less.

82
 Cont.…

Street Birth
Id Fname Mname Lname State City name Gender Date Age Phone1 Phone2 Phone3 Email

1 X Y Z Am Gon colleg M 2000 21 911 912 913 [email protected],

e [email protected],
[email protected]

2 A B C Oro wol colleg M 2000 21 915 NULL NULL [email protected]

e

• In this Student relation, you can see that the phone columns are not so much unique and are
referring about the same context, and there are also NULL values of Phone2 and Phone3 for the
student whose Id is 2.
• In 1NF rule, NULL values within relation should be avoided, and columns should be unique.

83
 Cont.…
• THE SECOND OPTION is, making the Phone attribute atomic attribute, and creating multiple
records phone number for the student within the Student relation as shown below.
• As you can see, for the sake of representing student’s phone numbers, all other student’s
information are recorded redundantly. In 1NF rule, redundancy in a relation should be
removed.
Id Fname Mname Lname State City Streetname Gender BirthDate Age Phone1 Email

1 X Y Z Am Gon college M 2000 21 911 emails

1 X Y Z Am Gon college M 2000 21 912 emails

1 X Y Z Am Gon college M 2000 21 913 emails

2 A B C Oro wol college M 2000 21 915 emails

84
 (a) Student_Phone schema
Cont.…
• THE THIRD OPTION is, creating a new
associate relation that can store
students’ phone numbers. The
relationship cardinality is, a Student can
have many phone numbers, which is
one-many.
• The new relation is called (b) Student_Phone relation with sample data
Student_Phone, which is a descriptive
name that can described itself what is Id StudentId Number
intended for. 1 GUR/1234/2021 911
• The schema is shown to the right.
2 GUR/1234/2021 912
• Note that, every relations should have
an autoincrement value, mostly, called 3 GUR/1234/2021 913
Id in RDBMS so that can be easily
manipulated. 4 GUR/1235/2021 915

85
 (a) Student_Email schema
Cont.…
• Using the same scenario, the multi-
valued attributes Email is
decomposed into a new relational
schema as shown to the right.
• The schema is called Student_Email, (b) Student_Email relation with sample data
which is descriptive that can
describe by itself what is intended Id StudentId Email
for.
1 GUR/1234/2021 [email protected]
• Student_Email is an associate
relation which is created to store 2 GUR/1234/2021 [email protected]
and organize students’ emails. The 3 GUR/1234/2021 [email protected]
relationship is one-many, which is a
student can one or more emails. 4 GUR/1235/2021 [email protected]

86
 Cont.…
• But, we have also to represent the relationship that Student entity
has with Department entity.
• In relational database, representing a relationship with relations is
handled by moving one’s entity primary key to the relating entity.
• As you can see in the next slide, Figure(b), Student-Department has
many-one relationship. So, for the purpose of representing the
relationship, Department’s primary key is repeated within the
Student relation, which is expected and correct.
• Figure(b) represents the correct Student-Department relationship in
relational database.
87
 Cont.…

Primary Key
(a) Student schema Foreign Key

(b) Student schema with sample data

Id StudentId Fname Mname Lname State City Streetname Gender BirthDate Age DepartmentCode

1 X Y Z Am Gon college M 2000 21 ECEg

2 A B C Oro wol college M 2000 21 ECEg

88
 Cont.… (a) Course schema Foreign Key Foreign Key

• Again, we have also to represent the

relationship that Student entity has with
Course entity.
(b) Course relation with sample data
• In relational database, representing a
relationship with relations is handled by id Code Title Hour DepartmentCode StudentId
moving one’s entity primary key to the
1 ECEg4172 Database 3 ECEg 12
relating entity. Systems
• As you can see in the Figure(b), Course-
Student has many-many relationship. 2 ECEg4172 Database 3 ECEg 13
Systems
So, for the purpose of representing the
relationship, course information has 3 ECEg3143 OOP 3 ECEg 14
represented redundantly, which results
DB operation anomalies as a single 4 ECEg3143 OOP 3 ECEg 15
course can be taken by many students.
5 ECEg3143 OOP 3 ECEg 16
• Figure(b) represents the relationship
where one course can be taken by many
students. 89
 Cont.…
(a) Course schema

Primary Key

(b) Department schema

Primary Key

(c) Student schema Foreign Key Foreign Key

(d) Student schema with sample data

Id StudentId Fname Mname Lname State City Streetname Gender BirthDate Age DepartmentCode CourseCode

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4172

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4182

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4182

90
 Cont.…
• As you can see in the previous slide, Figure(d), student information is
created redundantly as records for sake of representing the courses
that the student takes.
• In the Figure(d) shows a student can take many courses. As you have
seen while relation design of the Course entity, we stated that the
Course relation has been represented course information redundantly
for the sake of a representing a Course can be taken by many student.
• The next slide will show the summary of the relationship in both
relations.

91
 Cont.…
id Code Title Hour DepartmentCode StudentId (a) Course schema
- As a course can be taken by many students, one
1 ECEg4172 Database Systems 3 ECEg GUR/12/32 course has been recorded many times(marked in blue)
for different students(see the student id)
2 ECEg4172 Database Systems 3 ECEg GUR/13/32

3 ECEg3143 OOP 3 ECEg GUR/14/32

(b) Student schema
4 ECEg3143 OOP 3 ECEg GUR/15/32 - As a student can be take many courses, one
student has been recorded many times(marked
5 ECEg3143 OOP 3 ECEg GUR/16/32 in blue) for different courses(see the course
code)
Id StudentId Fname Mname Lname State City Streetname Gender BirthDate Age DepartmentCode CourseCode

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4172

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4182

1 X Y Z Am Gon college M 2000 21 ECEg ECEg4182

92
 Cont.…
• As you can see in the previous slide, to represent the relationship
between Course-Student, moving one’s primary key to the other, in
either of them results the creation of redundant data.
• You can also say that the Course relation has multi-valued attribute
called StudentId or a Student relation has multi-valued attribute
called CourseCode,
• In 1NF rule, redundancy should be removed. To avoid such
redundancy that can created by many-many relationship within
entities, creating an Associate entity is the best solution, that will
contain each’s primary key.

93
 Cont.…
• Thus, the newly created relation called Student_Course will be, Figure(a):-

(a) Student_Course schema

Foreign Key Foreign Key

(b) Course schema

Primary Key

(c) Student schema

Primary Key
94
 A schema in 1NF
(a) Department schema (b) Student_Phone schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

95
Second Normal Form(2NF)
• A relation is in 2NF iff:-
▪ It is in 1NF.
▪ Every non-key attributes(Descriptors) should be fully functionally dependent on the
primary key, otherwise it should be in its own relation, or no partially dependent
attribute should exist within a relation.
• Partial Dependency is where an attribute in a table depends on only a part
of the primary key and not on the whole key. Mostly, this dependency is
occurred within associate relation.
• The full functional dependency occurs when all non-key attributes are
dependent on primary key.
• This 2NF creates new table based on full functional dependency. Full
functional dependent attributes are moved to another table with their
primary key.

96
 (a) Student_Course schema
Cont.…
• Example:- Suppose the Student_Course relation is
redefined to have course instructor information
who offers it, such as instructor name.
• The Student_Course relation schema is shown to
the right Figure(a). (b) Student_Course with sample data
• As you can see in the Figure(a), CourseCode and Id CourseCode StudentId InstructorName
StudentId are composite key, but each can’t
determine instructor’s information. 1 ECEg4172 12 Kelele G.
• Such as;
Does StudentId->InstructorName? 2 ECEg4161 12 Tigabu Y.
Let StudentId=12, what is the instructorName?
Three names while it should have been only one. 3 ECEg4171 12 Lake A.
Does CourseCode-> InstructorName?
Let CourseCode=ECEg4172, what is the
instructorName? Its is Kelele G. Form this, we can say
that instructorName is partially dependent only on
CourseCode not on both keys, which the primary
Keys of the Student_Course.

97
 Cont.…
• Solving the partial dependency:-

(a) Instructor schema (c) Student_Course schema

InstructorId InstructorName CourseCode StudentId InstructorId

(b) Instructor with sample data (d) Student_Course with sample data

InstructorId InstructorName CourseCode StudentId InstructorId

123 Kelele G. ECEg4172 12 123

124 Tigabu Y. ECEg4161 12 124

125 Lake A. ECEg4161 12 125

98
Example:- Normalize this schema which is in 1NF using 2NF.
(b) Student_Phone schema
(a) Department schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

99
According to the 2NF, the following schema is in 1NF. So, let’s check the functional dependency, finding
out partial dependency of attribute exist within a relationship. Accordingly, no attribute is dependent on
any partial primary key within a relation.
(b) Student_Phone schema
(a) Department schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

100
Third Normal Form(3NF)
• A relation is in 3NF iff:-
▪ It is in 2NF and
▪ It has no transitive dependency.
✓ Transitive Dependency is a type of functional dependency which happens when a non-
prime attribute/s(descriptors) depends on other non-prime attributes(descriptors)
rather than depending upon the prime attributes or primary key.
✓ Let say
X->Y,
Y->Z, by transitive dependency (indirectly), X->Z

101
 (a) Company schema
Cont.…
• Example:- lets see the relation to the right.
Figure(a).
▪ Company->CEO, implies when you know (b) Company with sample data
the company name, you will obtain the
CEO information.
Company CEO Age
▪ CEO->age, implies when you know the
company CEO, you will obtain the CEO’s Microsoft Mr. X 50
Age.
▪ By transitive dependency, Company-
>Age, implies when you know the Google Mr. X 56
company name, you will obtain the Age
information. But the Age is not directly
dependent on the company name. Apple Mr. y 45
▪ To solve this dependency, a new relation
should be created that can represent
CEO->age

102
 Cont.…
• Thus, a relation that can represent full functional dependency in
between CEO->Age
(a) CEO schema (c) company schema

(d) CEO schema with sample data (d) Company schema with sample data
Id CEO Age Company CEOId

1 Mr. X 50 Microsoft 1

2 Mr. X 56 Google 2

Apple 3
3 Mr. y 45
103
Example:- Normalize this schema which is in 2NF using 3NF.
(b) Student_Phone schema
(a) Department schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

104
According to the 3NF, the following schema is in 2NF. So, let’s check the transitive dependency, finding
out transitive dependency of attribute exist within a relationship. Accordingly, no attribute is dependent
on any non-primary attribute within a relation.
(b) Student_Phone schema
(a) Department schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

105
Finally, the following is the final logical schema for sis sample.

(a) Department schema (b) Student_Phone schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

106
 Cont.…
Exercise:- Normalize the following
company’s database conceptual
schema using the 1st three normal
forms!!

107
Physical Design
• Physical database design is the process of transforming a data model into the physical data
structure of a particular database management system (DBMS).
• The aim of physical database design is to decide how the logical database design will be
implemented.
• In short, physical design is a process of implementing a database on secondary storage with a
specific DBMS.
• Physical design involves:-
• Defining database’s data dictionary. This should be done before the actual database
implementation is done.
• Defining a set of the table structures, data types for fields, and constraints on these tables such as
primary key, foreign key, unique key, not null and domain definitions to check if data are out of
the range.
• Identifying the specific storage structures and access methods to retrieve data efficiently. For
example, adding a secondary index to a relation.
• Designing security features for the database system including account creation, privilege
granting/revocation, access protection, and security level assignment.
• It is handled using queries, such as SQL for RDBMS(will be presented in chapter 3).

108
Data Dictionary
• A data dictionary is used to catalog and communicate the structure and content
of data and provides meaningful descriptions for individually named data objects.
▪ It defines metadata about data in a database, a system, or data used by applications.
▪ It is used for:-
✓ Documentation:- provide data structure details for users, developers, and other stakeholders.
✓ Communication:- equip users with a common vocabulary and definitions for shared data, data
standards, data flow and exchange, and help developers gage impacts of schema changes.
✓ Application Design:- help application developers create forms and reports with proper data types and
controls, and ensure that navigation is consistent with data relationships.
✓ Systems Analysis:- enable analysts to understand overall system design and data flow, and to find where
data interact with various processes or components.
✓ Data Integration:- clear definitions of data elements provide the contextual understanding needed when
deciding how to map one data system to another, or whether to subset, merge, stack, or transform
data for a specific use.
✓ Decision Making:- assist in planning data collection, project development, and other collaborative efforts

109
 Cont.…
• The template which is used for defining database data dictionary is:-

Table Name
Field Name Data Type Key Required Field Size Description Example
Field1
Field2
Field3
Field4
.
.
.

110
 Cont.…
• Example:- Define the data dictionary for the following logical schema.
(a) Department schema (b) Student_Phone schema

(c) Student_Email schema (d) Course schema

(e) Student_Course schema

(f) Student schema

111
 Cont.…
• Solution:-
Department
Field Name Data Type Key Required Field Size Description Example
Id integer Unique Yes 10 DBMS auto-incremented 1
Code text Primary Key Yes 10 A unique code that can be “ECEg”
entered by user
Name text Unique Yes 30 A unique department “Electrical and
name that can be entered Computer
by user Engineering”
Description text - Yes 2000 A department description “Electrical and
that can be entered by Computer
user Engineering
is…”

112
 Cont.…
• Course
Field Name Data Type Key Required Field Size Description Example
Id integer Unique Yes 10 Database auto-incremented 1
Code text Unique, Yes 10 A unique course code that “ECEg417
Primary Key can be entered by user 2”
Title text - Yes 30 A course name that can be “Database
entered by user Systems”
Hour integer - Yes 1 A course credit hour that 5
can be entered by user
DepartmentC text Unique, Yes 10 A department code which “ECEg”
ode Foreign Key should be only referenced
from Department relation.

113
 Cont.…
• Student
Field Name Data Type Key Required Field Size Description Example

Id integer Unique Yes 10 Database auto-incremented 1

StudentId text Unique, Yes 10 A unique course code that can be entered by user “GUR/12/01”
Primary Key
Fname text - Yes 30 A student’s first name that can be entered by user “x”

Mname text - Yes 30 A student’s middle name that can be entered by user “y”

Lname text - Yes 30 A student’s last name that can be entered by user “z”

state text - Yes 30 State name that can be entered by user “Amhara”

City text - Yes 30 City name that can be entered by user “Gondar”

Streetname text - Yes 30 Street name that can be entered by user “College”

Gender text - Yes 8 State name that can be entered by user “Male”

Birthdate Date - Yes 20 A student’s birth date that can be entered by user “12/12/2000”

Age integer - Yes 2 System calculated student’s age 13

Department text Unique, Yes 10 A department code which should be only referenced “ECEg”
Code Foreign Key from Department relation.
114
 Cont.…
• Student_Course
Field Name Data Type Key Required Field Size Description Example
Id integer Unique Yes 10 Database auto- 1
incremented
StudentId text Foreign Key Yes 10 A code which should be “GUR/12/01”
only referenced from
Student relation.
CourseCode text Foreign Key Yes 10 A code which should be “ECEg4172”
only referenced from
Course relation.

115
 Cont.…
• Student_Phone
Field Name Data Type Key Required Field Size Description Example
Id integer Unique Yes 10 Database auto- 1
incremented
StudentId text Foreign Key Yes 10 A code which should be “GUR/12/01”
only referenced from
Student relation.
Number text Unique Yes 12 A phone hour that can be +25191112
entered by user.

116
 Cont.…
• Student_Email
Field Name Data Type Key Required Field Size Description Example
Id integer Unique Yes 10 Database auto- 1
incremented
StudentId text Foreign Key Yes 10 A code which should be “GUR/12/01”
only referenced from
Student relation.
Email text Unique Yes 12 A phone hour that can be “[email protected]
entered by user. m”

117