BACKGROUND/HISTORY OF WOLKITE UNIVERSTY

 The history of our campus Wolkite University doesn’t exceed much greater than 4 or 5 years
(doesn’t include its construction period). B/c it is a small aged and less experienced university,
WKU has experienced a lot of difficulties in many aspects including the problem we are trying
to solve right now i.e. the problem of not having automated schedule system. By the way,
compared with other experienced universities and university collages, we can point out the
following issues as a highly noticeable issues in Wolkite University:

1. Lack of automated systems in the campus. This include:

 Automated Student Management System
 Automated Lecturers Management System
 Automated Cafeteria Management System
 Automated Clearance System
 Automated Attendance System etc…
 Automated Schedule System
2. Lack of quick communication mechanisms in the campus.
3. Lack of automated information exchange system etc.

 The points, which we listed above are just introductions to the issues experienced in the past 5
years in Wolkite University. If we try to create a list of problems in the past 4 or 5 years of
WKU history, then tons of papers won’t be enough.
 There are some gradual changes in WKU in the past few years though. Some new systems are
being introduced, thanks to CCI department students and lecturers, they are trying to introduce
new systems which can minimize a lot of hard work and do work efficiently!
 There were efforts in changing the manual systems into more accurate, automatic, efficient, user
friendly and computerized systems in the past few years, and it is still going very well.

1
 SPECIFIC AND GENERAL OBJECTIVE OF OUR PROJECT
 Before going to the specific and general objectives of our database system, it is better to let the
reader know what is it that we are taking about? What exactly is the project that we are
working on?
 It is better to explain what our project’s concerns using a table so that the answer for the above
questions is answered in a well-organized and neat way.

 Name of the project
 What abilities does
the database have?
 Is it useful?
THE PROJECT
 Schedule System For Wolkite University
 It has the abilities to store automatically generated
or manually created schedules in a well-organized
and in such a way that data retrieval is easy and
user friendly.
 Yes! It is. It minimizes time waste and overlapping.

 When we came to the main point, as the question suggests, our objective or aim should be both
specific and general and yes we have a general and specific objective.
SPECIFIC OBJECTIVE
 Our specific objective is just to give a solution for the current issue in scheduling a lecture and
laboratory sessions (periods) to a specific time in such a way that there are no overlapping periods,
no time assigned more than the credit hours assigned for that subject.
GENERAL OBJECTIVE
 We’ve separated our general objectives into phases. We did this in order to make our general
objective manageable and time table based.

2
 Continued
OUR GENERAL OBJECTIVE (SEPARETED IN PHASES)
PHASE TIME (IN OBJECTIVE
THE NEXT...)
 Make the project came true. Test the project and fix
1 30 Days issues if found. Try to integrate the database with
other application programs. (For adding
functionalities)
2 2 Months  Make a fully functional Database System with a high
accuracy in doing its job.
3 3 – 6 Months  Try to distribute it to the end users for testing
purpose.
 End users may be:
 Universities
 High schools
 Any other organizations that may need an
automated schedule system.
4 7 Months  Collect user experience and add extra features.
5 10 – 12 Months  Try to merge the whole system into other related
software systems and create a larger system.

 Therefore, we can summarize our general objective into the Other Objectives
following statement: Develop:
 Our program’s general objective is to create a highly  Accurate
qualified and useful system that is capable of doing what  Close to Perfect
the end user required it to do in a satisfying, fast, easy  High Speed
way. And for the future, merge the system with other  High Quality
related systems in order to create an all-in-one system.  User Friendly
 Trust Worthy
System.

3
 DETAIL ANALYSIS OF THE EXISTING SYSTEM
 Before going to the details, we have to make
sure that one point is clear. We’ve tried to
analyze the existing system deeply but we
haven’t got all the information we need
because some of the information we need was
not given to us simply because it was not
publicly available for everyone who needed it.
 When we came back to the main point, the
existing system, which is the one applied in
order to solve the issue we are taking about
(i.e. the schedule system) is of course an
automated system. By automated system, we
mean that the existing system uses software,
database concepts and more in order to
implement a schedule system. Although it is
an automated system, it has a lot of
drawbacks.
 Let us take for example the last year’s
scenario (2014, 2007 G.C): As we’ve seen,
there was a lot of corrections to the schedule
time table because it has a lot of overlapping.
As we can remember there was at least one or
two changes to the schedule every week for
almost a month and a half. This is a big
problem which is not often expected from
automated computer systems.
4
 This problem still exists. By that, we mean
for instance,
 At the current times, we can point out the
following issues as a major drawbacks of
the existing system.
 The students may not have any idea
which schedule is correct and which
schedule is not.
 Because there are sudden changes in
schedules, this arises ambiguity in
such a way that a student may not
exactly know which schedule to
follow, which schedule to left
behind.
 Because a lot of overlapping exists,
there are confusions in both students
and lecturers.
 As of this days in Wolkite University,
issues described above still exist.
 Generally, the existing system has a lot of
drawbacks and problems as described
above.
 Note: we tried to get information about how
exactly the existing system works but this
information was not available to us.
 STATEMENT OF THE PROBLEM

 We’ve prepared two statements to explain what the problem is. One of the statement is in a short
form and the other explains the problem in a clearer and brief way.
STATEMENT 1
The first statement for the problem we are facing is:
 There is a problem of not having a fully functional scheduling and time tabling
system in Wolkite University. So design a database system which can address
this issue.
STETEMENT 2 (THE BRIEF ONE)

STATEMENT
OF THE PROBLEM

 The database keeps the class schedule timetable data. The database
holds the courses given to students, the instructor that teaches the
courses, the sections where courses are given. The instructor teaches
some specific course at specific time, day at some specific class room
(section). The database may contain some extra features such as
information about the manager which is controlling some specific
department, students class rooms etc. Some attributes contained by
the database include instructor’s personal information such as name,
SSN etc., course description such as: course name, course code, course
load etc. The database also contains other entities and attributes. This
are discussed latter.

5
 STAKE HOLDERS OF THE SYSTEM

 Currently, our stake holders are units (organs) found in Wolkite University, which are
working on the scheduling process and course time tabling. These units currently use the
system that we talked earlier (in section 3 of this text). As described, these are the stake
holders of our system when the final product is released.
 But as described in section 2 (specific and general objective section of this text), for the
future stake holders of our system may increase. By the time we release a fully functional
and general purpose scheduling system, our stake holders can be:
 High schools
 Universities
 Elementary and Junior schools
 Other organizations that may need a general purpose scheduling system
 Even our system’s stakeholders can be individuals. i.e. individuals may use the scheduling
system for their personal use.
 For the future the system may be a general purpose scheduling system. So its application
area may grow even further so as the stakeholders. So it may be hard to predict the
stakeholders of the system for the future because of the wide application area of the system.

6
 METHODOLOGIES THAT WE USED TO GATHER INFORMATION
 The first thing that we did before the
information gathering process is find out what
information do we exactly need in order to
accomplish this project, what things are helpful
and what things are not, what are the things that
need more priority than the others, etc.
 For instance, before we started the information
gathering process we point out the following
things that we believed are helpful for our
project.
 What is the currently being used
system?
 What drawbacks does the existing
system have?
 What are the good things that the
existing system have?
 What things can we use and what things
that we have to left from the existing
system?
 What are the major users of our system?
 What our end users need?
 What are the best way to follow in order
to make our system stable and user
friendly? etc.
 After we point out necessary points like the ones
listed above, then we started the information
gathering process.
 During the information gathering process we
used the following methods that we believed are
necessary in the information gathering process.
7
1. The first method that we used to gather
information is ask the end-users what exactly do
they need.
 We go to places that we believe our end
users may exist.
 We asked our end-users questions that
are specially prepared for them. We ask
them both individually and in a group
manner.
2. We give questionnaires for some students to
point out what issues exist in the existing
system.
a. The questionnaires ask the readers what
they have experienced from the existing
system. May be good or may be bad.
b. The questionnaires also ask the readers
to suggest what should be corrected in
the existing system.
3. We, the system developers also gathered to
analyze the existing system in a professional
way so that we get a better idea about the
existing system and a better understanding of
what our new system should be.
4. We asked some senior students (senior students
which lasted in this campus longer than we did)
to tell us some background/history about the
organization (Wolkite University) that we are
working with.
 Although the above points are the main methods we
used to gather information, we used other
information gathering methods like one-on-one
interviews, group interviews, facilitated sessions,
prototyping, etc. in order to gather information.
 BUSINESS RULE AND CONSTRAINTS
 Business rule of the organization related to
the system we are developing is as the
following:
 Business Rule for the Scheduling System:
 Duplicate and overlapping periods are
not allowed (This one is handled by the
software not the database itself).
 Course periods cannot be greater or less
than their dedicated credit hours.
 A single lecture class may not exceed
from two and half hours and a single
laboratory class may not exceed from
four hours.
 A lecturer cannot teach more than eight
hours per day.
 A lecturer may teach one or more classes
and one or more sections.
 A lecturer may teach more than one
course.
 Students may be thought by more than
one lecturers.
 The above are the main business rules that the
selected organization has but we also added
other business rules (In a manner which is
suitable with the organization’s business rule)
for quality purposes.
8
CONSTRAINTS ARE :
 To achieve the business rule of the
organization we selected we must use
constraints.
 The constraints that we used are listed
below and these constraints are not only
applied to the database system some of the
constraints are also used in the
implementing application software.
THE CONSTRAINTS
 Credit hour constraint.
 Day constraint.
 Student year constraint.
 Individual working hour constraint.
 Duplicate constraint.
 Overlap constraint.
 Laboratory and Lecture constraints.
 Time limit constraint.
 The above are main constraints used in
our system. There exist other constraints
which are used for small purposes.
 BASED ON OUR BUSINESS RULE…

Preliminary entities and

attributes:
 The following table contains entities, relationship types, participations, cardinality
ratios, etc. that we used for our system.
 In order to understand the table very well, it is better to follow the following
instructions.
1. Texts that are colored orange and green in the ‘RELATIONSHIP TYPE’
column, denote that the relationships which are the bold ones are owned by
other entities.
For example: The ‘manages’ in the ‘RELATIONSHIP TYPE’ column is
colored orange. So this indicates that the owner of the
‘manages’ relationship type is not the ‘Department’ entity.
When we say the ‘owner of the relationship’ we mean, from
where the relationship emerged? For Example, the
‘Manages’ relationship type is owned by the Instructor
entity not the Department. Therefore, the owner of the
relationship type is Instructor.
2. If the colors in the entities column and the relationship type column are the
same, then this indicates the there is an ownership relationship between
them.
3. The underlined attributes in the ‘ATTRIBUTES’ column indicate that they
are primary keys.

9
 Continued… ENTITY RELATIONSHIP RELATIONSHIP CONSTRAINTS ATTRIBUTES

MIN –
RELATIONSH RELATIONSH PART
CARDINALITY MAX
NO. ENTITY IP IP ICIPA ATTRIBUTES TYPE
RATIO (entity’s
TYPE WITH TION
side)

1. Name char
1 Collage Contains Department FULL 1:N (1,N)
2. Code varchar

Contains Course FULL 1:N (1,N) 1. Name char

2 Department
Manages Instructor FULL 1:1 (1,N) 2. Code varchar

Contains Department FULL N:1 (1,N) 1. Name char

Instructor FULL N:M (1,N) 2. Code varchar

3 Course
Teaches 3. Load char
Section FULL N:M (1,N)
4. Credit
int
Hours

1. First Name char

2. Last Name char

4 Student Studies In Section FULL N:1 (1,N)
3. ID varchar

4. Year int

Course FULL M:N (1,N) 1. First Name char

Teaches
5 Instructor Section FULL M:N (1,N) 2. Last Name char

Manages Department FULL 1:1 (1,N) 3. SSN int

10
 ER - DIAGRAM

11
 DESCRIPTION OF THE ER DIAGRAM
Introduction  In this section we are going to explain every relationship types and relationship constraints in a
clear manner.
 We want the reader to know that in order to make our system, the ‘Teaches’ relationship type and
the ‘Section’, ‘Instructor’, and ‘Course’ entities were enough. All other things that we need to make a
fully functional schedule system like, checking whether there is overlapping, automatic class
assignment, etc… are done by the software that work with the database.

Relationships THE ‘CONTAINS’ RELATIONSHIP TYPE AND ITS CONSTRAINTS

 This relationship shows that 1 collage may contain several departments. For instance: The CCI
The ‘contains’ r/ship
collage has four departments in it namely SE, CS, IS, IT.
 The (min, max) constraint for this relationship type is (1, N) this is because there is a minimum
of one collage. There may be more than one also. The same works for the department side.
 There is always a full participation. This is because if a collage exists, there is no way that the
collage may not have a department.

THE ‘MANAGES’ RELATIONSHIP TYPE AND ITS CONSTRAINTS

 This relationship shows that exactly 1 instructor manages 1 department.
The ‘manages’ r/ship
 The (min, max) constraint for this relationship type is (1, N) this is because there is at least one
department to be managed. This also works on the instructor’s side of the relationship
‘manages’.
 There is always a full participation in the department side of the relationship. This is because,
every department must have a manager. But in the Instructor’s side of the relationship, there is a
partial participation. And this is because, not all instructors can be a manager. Therefore, the
participation should be partial in order to fulfil this business rule.

12
 THE ‘CONTAINS’ RELATIONSHIP TYPE AND ITS CONSTRAINTS
 This relationship shows that 1 department may contain several courses. For instance: The
The ‘contains’ r/ship Software Engineering department contains many courses.
 The (min, max) constraint for this relationship type is (1, N) in both side of the relationship.
This is because there is a minimum of one department to contain specific courses. And N number
of maximum departments that has courses in them. plus, there is a minimum of one course to be
contained by a specific department. And N number of courses to be contained by a department.
 There is always a full participation in both sides. If there is a department, there must be a course
given by that department. And if there is a course, the vice versa works great.

THE ‘STUDIES-IN’ RELATIONSHIP TYPE AND ITS CONSTRAINTS

 This relationship shows that N number of students belong to exactly one section.
The ‘studies-in’ r/ship  The (min, max) constraint for this relationship type is (1, N) in both side of the relationship.
This is because there is a minimum of one student that belong to a specific section. Also there is
a minimum of one section for specific students.
 There is always a full participation in both sides. If there is a student, then that student has a
section and if there is a section, then there exist students that belong to that specific section.

THE ‘TEACHES’ RELATIONSHIP TYPE AND ITS CONSTRAINTS

 This is a n-ary relationship type. This relationship shows that M number of instructors teach N
The ‘teaches’ r/ship number of courses and N number of sections. Also the ‘teaches’ relationship type has three
properties that shows when the teacher teaches a course and in which section.
 The (min, max) constraint for this relationship type is (1, N) in all side of the relationship. This
is because there is one teacher in minimum to teach a course and a section. Also there is a
minimum of one section and one courses and N number of section and courses as maximum.
 There is always a full participation in all sides. If there is a lecturer, he/she must teach N
number of sections and N number of courses. If there is a section, there must be a lecturer and
courses assigned to that section. If there is a course, then there must be a lecturer to teach that
course.

13
 THE RELATIONAL SCHEMA (RELATIONAL MAPPING)

Preliminary entities and

attributes: COLLAGE
Code Name

DEPARTMENT
Code Name Collage Code Manager SSN

COURSE
Code Name Load Credit Hours Department Code

STUDENT
ID First Name Last Name Year Section Code

SECTION
Code Name Identifying Letter

INSTRACTOR
SSN First Name Last Name

TEACHERS
Instructor SSN Course Code Section Code Time Day Class Type

14
 4. As we can clearly see in the above relational schema, the tables used in our database are already
NORMALIZATION in normal form. So we don’t need any normalization at all!

QUERY CREATE TABLE Section

(
ALTER TABLE Teachers
ADD CONSTRAINT Course_to_Teachers FOREIGN KEY(Course_Code)
Code VARCHAR(10) PRIMARY KEY,
REFERENCES Course(Code)
Name CHAR(10),
CREATE DATABASE ScheduleSystem
Identifying_Letter VARCHAR(10)
USE ScheduleSystem ALTER TABLE Student
)
ADD CONSTRAINT Section_to_Student FOREIGN KEY(Section_Code)
CREATE TABLE Collage REFERENCES Section(Code)
CREATE TABLE Instractor
( (
code VARCHAR(10) PRIMARY KEY, ALTER TABLE Teachers
ssn VARCHAR(10) PRIMARY KEY,
Name CHAR(50) ADD CONSTRAINT Section_to_Teachers FOREIGN KEY(Section_Code)
First_Name CHAR(50),
) REFERENCES Section (Code)
Last_Name CHAR(10)
)
ALTER TABLE Department
CREATE TABLE Department
CREATE TABLE Teachers ADD CONSTRAINT Instractor_to_Department FOREIGN KEY(Manager_ssn)
(
( REFERENCES Instractor (ssn)
code VARCHAR(10) PRIMARY KEY,
Name CHAR(50), Instructor_ssn VARCHAR(10),
Course_Code VARCHAR(10), ALTER TABLE Teachers
Collage_code VARCHAR(10), ADD CONSTRAINT Instractor_to_Teachers FOREIGN KEY(Instructor_ssn)
Manager_ssn VARCHAR(10) Section_Code VARCHAR(10),
Time_ VARCHAR(20), REFERENCES Instractor (ssn)
)
Day_ VARCHAR(20),
Class_Type VARCHAR(10) --1st
CREATE TABLE Course PRIMARY KEY (Instructor_ssn, INSERT INTO Collage VALUES('WKUCCI','Comuting and informatics')
( Course_Code,Section_Code) --2nd
code VARCHAR(10) PRIMARY KEY, ) INSERT INTO Department VALUES ('SE','Software
Name CHAR(50), Engineering','WKUCCI','45')
Load_ CHAR(30), ALTER TABLE Department --3d
Credit_Hours INT, ADD CONSTRAINT Col_to_Dep INSERT INTO Instractor VALUES('45','Kebede','Abebe')
Department_Code VARCHAR(10) FOREIGN KEY(Collage_code) --4th
) REFERENCES Collage (Code) INSERT INTO Course VALUES('SENG','Fundamental
Programming','normal',7,'SE')
CREATE TABLE Student ALTER TABLE Course --5th
( ADD CONSTRAINT INSERT INTO Section VALUES ('A', 'Section A','SEA')
ID VARCHAR(10) PRIMARY KEY, Department_to_Course FOREIGN --6th
First_Name CHAR(50), KEY(Department_Code) INSERT INTO Student VALUES('CIR/061/07','Amanuel',
Last_Name CHAR(10), REFERENCES Department(Code) 'Gizachew','2008','A')
Year_ INT, --7th
Section_Code VARCHAR(10) INSERT INTO Teachers VALUES('45','SENG','A','4:00 AM','Monday','A')
)
i ii iii
15