DATABASE PROJECT

SCHOOL OF INFORMATION TECHNOLOGY ENGINEERING

NAME ID
1, Yonas Degefu UGR/6959/15
2, Milkias Wakgari UGR/0422/15
3, Firaol Ayana UGR/5016/15
4, Fitale Tariku UGR/4074/15
5, Eyosiyas Bisrat UGR/2434/15
6, Alazar Andualem UGR/4511/15

Submitted to Instructor Kassahun

Submission Date 11/10/2016
 Table of Contents

1. Background

 Company Profile
 Mission
 Vision

2. Requirement Analysis

 Current Problems
 Planned Functions and Activities
 Goals of the New Database System

3. Conceptual Design

 Identification of Entities and Attributes of Each Entity

 Primary Keys and Attribute Types

4. Relationships Between Entities

 Primary Key and Foreign Key Relationships

 Relationship Constraints (Cardinality Ratio and Participation
Constraints)

5. Entity-Relationship (ER) Diagram

 Drawing the ER-Diagram

6. ER-Diagram to Relational Tables Mapping

 Mapping Rules

7. Implementation of Relational Tables

 SQL Table Creation Scripts

 Populating Tables with Data (At Least 10 Records per Table)

8. Data Manipulation Queries

 Insertion Queries and Retrieval Queries

 Update Queries and Deletion Queries
 INTRODUCTION
JUCS School, with its domain spanning from King Garden to the prestigious 12th-
grade diploma program, stands as a beacon of educational excellence in our
community. Established to provide a transformative learning experience, JUCS
School has been dedicated to nurturing academic achievement, fostering holistic
student development, and cultivating future leaders. Our institution prides itself on
offering a diverse array of programs and extracurricular activities aimed at
inspiring a passion for learning, instilling values of integrity and compassion, and
preparing students for success in their academic and personal pursuits.

Despite our commitment to excellence, JUCS School faces a pressing challenge

due to the absence of an online database system. Currently reliant on traditional
databases, the school encounters inefficiencies in managing student records, class
schedules, attendance, and communication with parents. This reliance on outdated
systems impedes administrative processes, limits data accessibility, and hampers
the ability to make informed decisions based on real-time information.

To address these challenges and enhance service delivery, JUCS School seeks to
implement a new online database system. The introduction of this system will
streamline administrative tasks, facilitate communication and collaboration among
stakeholders, and provide valuable insights for strategic decision-making. By
modernizing our database infrastructure, JUCS School aims to improve operational
efficiency, optimize resource allocation, and ultimately enhance the educational
experience for all students from King Garden to the 12th-grade diploma program.
 The problem JUCS currently facing
The identified problem lies in the inefficiency of the traditional database system
utilized by JUCS School. This antiquated approach, while once functional, no
longer adequately meets the evolving needs of our institution. The traditional
database setup lacks effectiveness in several key areas, including the management
of student records, class schedules, attendance tracking, and communication with
parents.

The reliance on outdated database systems poses significant challenges in

administrative processes, hindering our ability to efficiently access, update, and
utilize critical information. Without a centralized and accessible platform, tasks
become time-consuming and prone to errors, impeding the smooth operation of our
educational institution.

Moreover, the absence of real-time data access inhibits our capacity to make
informed decisions and respond promptly to emerging needs and challenges. As a
result, our ability to optimize resources, enhance collaboration among
stakeholders, and provide a high-quality educational experience to our students is
compromised.

In light of these challenges, it is imperative that we transition from traditional to

modern database solutions. By implementing an effective online database system,
we can streamline administrative workflows, improve data accessibility, and
empower our staff to make informed decisions based on accurate and up-to-date
information. This shift towards modernization will not only enhance the efficiency
of our operations but also contribute to the overall success and advancement of
JUCS School.
 Entities and Attributes
1) Student
a. Strong Entity
b. Attributes:
i. StudentID: Integer, unique identifier for each student (Primary
Key). (Atomic)
ii. FullName (Composite):
1. FirstName: String, the first name of the student (length:
1-50 characters). (Atomic)
2. LastName: String, the last name of the student (length: 1-
50 characters). (Atomic)
iii. DateOfBirth: Date, the birth date of the student. (Atomic)
iv. Gender: String, gender of the student (values: 'Male', 'Female',
'Other'). (Atomic)
v. Address (Composite):
1. Street: String, street address (length: 1-50 characters).
(Atomic)
2. City: String, city (length: 1-50 characters). (Atomic)
3. State: String, state (length: 1-50 characters). (Atomic)
4. PostalCode: String, postal code (length: 5-10 characters).
(Atomic)
vi. Contact Numbers: List of contact phone numbers of the student
(each number length: 10-15 characters). (Multivalued)
vii. Email: String, email address of the student (length: 5-50
characters, must be in valid email format). (Atomic)
c. Possible value types:
i. StudentID: Integer
ii. FirstName, LastName, Street, City, State: String
iii. DateOfBirth: Date
iv. Gender: String ('Male', 'Female', 'Other')
v. PostalCode: String (length: 5-10 characters)
vi. ContactNumbers: List of Strings (each number length: 10-15
characters)
vii. Email: String (length: 5-50 characters, valid email format)
d. No foreign keys.
2) Parent
a. Strong Entity
b. Attributes:
 i. ParentID: Integer, unique identifier for each parent (Primary Key).
(Atomic)
ii. FullName (Composite Attribute):

 FirstName: String, the first name of the student (length: 1-

50 characters). (Atomic)
 LastName: String, the last name of the student (length: 1-50
characters). (Atomic)

iii. PhoneNumber: String, phone number of the parent (length: 10-15

characters). (Atomic)
iv. Email: String, email address of the parent (length: 5-100
characters, valid email format). (Atomic)
v. Address: String, address of the parent (length: 1-255 characters).
(Atomic)
3) Teacher
a. Strong Entity
b. Attributes:
i. TeacherID: Integer, unique identifier for each teacher (Primary
Key). (Atomic)
ii. FullName (Composite Attribute):

 FirstName: String, the first name of the student (length: 1-

50 characters). (Atomic)
 LastName: String, the last name of the student (length: 1-50
characters). (Atomic)

iii. SubjectID: Integer, identifier for the subject taught by the teacher.
(Atomic)
iv. PhoneNumber: String, phone number of the teacher (length: 10-15
characters). (Atomic)
v. Email: String, email address of the teacher (length: 5-100
characters, valid email format). (Atomic)
vi. Address: String, address of the teacher (length: 1-255 characters).
(Atomic)
vii. HireDate: Date, the date of hiring of the teacher. (Atomic)
4) Class
a. Strong Entity
b. Attributes:
 i. ClassID: Integer, unique identifier for each class (Primary Key).
(Atomic)
ii. ClassName: String, name of the class (length: 1-50 characters).
(Atomic)
iii. Level: Integer, level of the class (values: 1-12). (Atomic)
iv. TeacherID: Integer, identifier for the teacher of the class (Foreign
Key referencing Teacher(TeacherID)). (Atomic)
5) Subject
a. Strong Entity
b. Attributes:
i. SubjectID: Integer, unique identifier for each subject (Primary
Key). (Atomic)
ii. SubjectName: String, name of the subject (length: 1-50 characters).
(Atomic)
iii. ClassID: Integer, identifier for the class to which the subject
belongs (Foreign Key referencing Class(ClassID)). (Atomic)
6) Exam
a) Weak Entity
b) Attributes:

i. ExamID: Integer, unique identifier for each exam (Primary

Key). (Atomic)
ii. SubjectID: Integer, identifier for the subject of the exam
(Foreign Key referencing Subject(SubjectID), Part of Composite
Key). (Atomic)
iii. StudentID: Integer, identifier for the student taking the exam
(Foreign Key referencing Student(StudentID), Part of Composite
Key). (Atomic)
iv. MidExam: Float, marks obtained in the midterm exam. (Atomic)
v. Assignment: Float, marks obtained in the assignment. (Atomic)
vi. FinalExam: Float, marks obtained in the final exam. (Atomic)
vii. TotalMarks: Float, total marks obtained in the exam. (Derived,
Atomic)

7) Grade
a. Strong Entity
b. Attributes:
i. GradeID: Integer, unique identifier for each grade (Primary Key).
(Atomic)
 ii. StudentID: Integer, identifier for the student (Foreign Key
hreferencing Student(StudentID)). (Atomic)
iii. TotalGrade: Float, total grade obtained by the student in the
subject. (Atomic)
iv. AverageGrade: Float, average grade obtained by the student in the
subject. (Atomic)
8) Attendance
a. Strong Entity
b. Attributes:
i. AttendanceID: Integer, unique identifier for each attendance record
(Primary Key). (Atomic)
ii. StudentID: Integer, identifier for the student (Foreign Key
referencing Student(StudentID)). (Atomic)
iii. Date: Date, date of the attendance. (Atomic)
iv. SubjectID: Integer, identifier for the subject (Foreign Key
referencing Subject(SubjectID)). (Atomic)
v. Status: String, attendance status of the student (values: 'Present',
'Absent', 'Late'). (Atomic)
9) Club
a. Strong Entity
b. Attributes:
i. ClubID: Integer, unique identifier for each club (Primary Key).
(Atomic)
ii. ClubName: String, name of the club (length: 1-50 characters).
(Atomic)
iii. Description: Text, description of the club. (Atomic)
10) TransportService
a. Strong Entity
b. Attributes:
i. TransportID: Integer, unique identifier for each transport service
(Primary Key). (Atomic)
ii. Route: String, route of the transport service (length: 1-100
characters). (Atomic)
iii. DriverName: String, name of the driver (length: 1-50 characters).
(Atomic)
iv. Capacity: Integer, capacity of the transport service. (Atomic)
11) Registration
a. Strong Entity
b. Attributes:
 i. EnrollmentID: Integer, unique identifier for each enrollment
(Primary Key). (Atomic)
ii. StudentID: Integer, identifier for the student (Foreign Key
referencing Student(StudentID)). (Atomic)
iii. ClassID: Integer, identifier for the class (Foreign Key referencing
Class(ClassID)). (Atomic)
iv. ClubID: Integer, identifier for the club (Foreign Key referencing
Club(ClubID)). (Atomic)
v. TransportID: Integer, identifier for the transport service (Foreign
Key referencing TransportService(TransportID)). (Atomic)
vi. Fee: Float, fee associated with the student's enrollment. (Atomic)
12) BoardMember
a. Weak Entity
b. Attributes:

i. BoardID: Integer, identifier for the school board (Foreign Key

referencing SchoolBoard(BoardID), Part of Composite Key).
(Atomic)
ii. TeacherID: Integer, identifier for the teacher (Foreign Key
referencing Teacher(TeacherID), Part of Composite Key). (Atomic)
iii. Position: String, position of the teacher in the board (values:
'Director', 'Unit Leader', 'Club Leader', 'Owner', etc.). (Atomic)

Entity relationships and Constraints:

1. Student-Parent Relationship

 Relationship: Student has Parent

 Type: One-to-Many
 Foreign Key: None
 Description: Each student has one or more parents.

2. Student-Class Relationship

 Relationship: Student enrolls in Class

 Type: Many-to-Many
 Foreign Key: StudentID, ClassID (in Registration)
 Description: Each student can enroll in multiple classes and each class can
have multiple students.

3. Student-Exam Relationship

 Relationship: Student takes Exam

 Type: One-to-Many
 Foreign Key: StudentID, SubjectID (in Exam)
 Description: Each student can take multiple exams for various subjects.

4. Student-Attendance Relationship

 Relationship: Student has Attendance

 Type: One-to-Many
 Foreign Key: StudentID, SubjectID (in Attendance)
 Description: Each student has attendance records for each subject.

5. Student-Club Relationship

 Relationship: Student enrolls in Club

 Type: Many-to-Many
 Foreign Key: StudentID, ClubID (in Registration)
 Description: Each student can enroll in multiple clubs and each club can
have multiple students.

6. Student-TransportService Relationship

 Relationship: Student enrolls in TransportService

 Type: Many-to-Many
 Foreign Key: StudentID, TransportID (in Registration)
 Description: Each student can use multiple transport services and each
transport service can serve multiple students.

7. Student-Grade Relationship

 Relationship: Student has Grade

 Type: One-to-Many
 Foreign Key: StudentID, SubjectID (in Grade)
 Description: Each student has grades for each subject.

9. Exam-Subject Relationship
 Relationship: Exam belongs to Subject
 Type: Many-to-One
 Foreign Key: SubjectID (in Exam)
 Description: Each exam belongs to one subject.

10. Teacher-Class Relationship

 Relationship: Teacher manages Class

 Type: One-to-Many
 Foreign Key: TeacherID (in Class)
 Description: Each teacher manages multiple classes.

11. BoardMember-Teacher Relationship

 Relationship: Teacher is a Board Member

 Type: One-to-Many
 Foreign Key: TeacherID (in BoardMember)
 Description: Each teacher can hold a position on the board.

12. Student-Registration Relationship

 Relationship: Student has Registration

 Type: One-to-Many
 Foreign Key: StudentID (in Registration)
 Description: Each student can have multiple registrations, each with
associated fees.

13. Class-Subject Relationship

• Relationship: Class has Subjects

• Type: One-to-Many

• Constraints: Kindergarten (KG1, KG2, KG3): Classes in this division can

only be assigned 7 subjects.

 Elementary (Level 1-8): Classes in this division can only be

assigned 9 subjects.
 High School (Level 9-12): Classes in this division can only be
assigned 12 subjects.
 Classes in this division can only be assigned 12 subjects.
ER- Diagram
Mapping
 Important queries
Insert Data
1. Insert a new student
INSERT INTO Student (StudentID, FirstName, LastName, Gender, DateOfBirth)
VALUES (11, 'Fira', 'Abebe', 'M', '2005-03-15');
2. Insert a new subject
INSERT INTO Subject (SubjectID, SubjectName, TeacherID)
VALUES (6, 'Physics', 4);
3. Insert a new exam record
INSERT INTO Exam (ExamID, SubjectID, StudentID, MidExam, Assignment,
FinalExam)
VALUES (56, 1, 11, 28, 19, 48);
Retrieve Data
4. Retrieve all students' information
SELECT * FROM Student;
5. Retrieve all subjects with their teachers
SELECT s.SubjectName, t.FirstName, t.LastName
FROM Subject s
JOIN Teacher t ON s.TeacherID = t.TeacherID;
6. Retrieve all exams for a specific student
SELECT * FROM Exam
WHERE StudentID = 1;
7. Retrieve the average final exam score for each subject
SELECT SubjectID, AVG(FinalExam) AS AverageFinalScore
FROM Exam
GROUP BY SubjectID;
8. Retrieve students who scored less than 30 in mid-exam for any subject
SELECT DISTINCT s.StudentID, s.FirstName, s.LastName
FROM Student s
JOIN Exam e ON s.StudentID = e.StudentID
WHERE e.MidExam < 30;
Update Data
9. Update a student's name
UPDATE Student
SET FirstName = 'Jane', LastName = 'Smith'
WHERE StudentID = 1;
10.Update the final exam score for a specific exam
UPDATE Exam
SET FinalExam = 50
WHERE ExamID = 6;
11.Update the teacher for a specific subject
UPDATE Subject
SET TeacherID = 5
WHERE SubjectID = 1;
Delete Data
12.Delete a student
DELETE FROM Student
WHERE StudentID = 11;
13.Delete an exam record
DELETE FROM Exam
WHERE ExamID = 56;
14.Delete all exams for a specific subject
DELETE FROM Exam
WHERE SubjectID = 3;
Complex Queries
15.Retrieve students and their total scores for all subjects
SELECT s.StudentID, s.FirstName, s.LastName, SUM(e.MidExam +
e.Assignment + e.FinalExam) AS TotalScore
FROM Student s
JOIN Exam e ON s.StudentID = e.StudentID
GROUP BY s.StudentID, s.FirstName, s.LastName
ORDER BY TotalScore DESC;