THIAGARAJAR COLLEGE OF ENGINEERING, MADURAI 625 015.

Department of Computer Science and Engineering

18CS440 – Database Management Systems – Database Application

School Database Management Systems

19C025 Gokulnath S
19C050 Madhavan V P
19C101 Srijith B

1 Introduction
This project aims to computerize the operations of the student database of a
School. Features include managing attendance details,student details,group
details,Employee details and marks secured by them. The participation of the
students in various extracurricular activities are also incorporated.

2 Application Users

The users of the system are the teaching staff, administrative

staff, placement coordinator, students. Teaching staff can update the
mark and attendance details of the students . The administrative staff can
update the fees details paid by the students in each year. All the users can
view the detail

3 Functions Overview
The following functionality will be supported by the student database
management system.

1. Attendance updating and view.

2. Student details and view.
3. Group details and view.
………………………………………………………………………………………………………

4. Marks updating and view

5. Fee collection and pending fee

4 Detailed Functional Requirements

4.1 Attendance updating and view.
Teaching staff records the attendance detail of the students
for the subjects handled by them. In case of default, attendance can be updated by
the teaching staff by considering the allowable on duty leave. Based on the
attendance percentage, the students are allowed to take the semester examinations.
All the users can view the details of the attendance.

4.2 Student details and view.

Teaching staff records the detail of the students like blood
group , address , parent’s name and phone number handled by them. In case of
default, it will all be updated by the staffs into the database. Based on the students
id, we can get the detail of the particular student . All the users can view the details
of the attendance.

4.3 Group details and view.

Group details will be assigned to the students before they
enter their respective classes.if you want to know the students under the group
“Computer science”,then you have to enter “computer science”in the clause. All
the users can view the details of the attendance.

4.4 Marks updating and view.

Teaching staff records the marks of the students for the
subjects handled by them. In case of default, marks can be updated by the teaching
staff by considering the marks the students got for their exams. Based on the marks
percentage, the students are allowed to pass the current year. All the users can view
the details of the attendance.

4.5 fee collection and pending fee

office enity have all the fee details of the student as the record
and students can pay the fee and view the pending fees
Page 2 of 29
………………………………………………………………………………………………………

5 Entities and Relationships

5.1 Entities and Relationships

Entities:
i. School
ii. Student
iii. Attendence
iv. Staff
v. Sports
vi. Office
vii. Subject
viii. Employee
ix. Exam

Relationships:
i. Belongs
ii. Is-a
iii. Teaches
iv. Participate
v. Enroll
vi. Handles
vii. Take
viii. Consist
ix. Manage

Page 3 of 29
………………………………………………………………………………………………………

6 Entity Relationship Diagram

Page 4 of 29
………………………………………………………………………………………………………

7.Schema Diagram

7. 1 ER to Relational model
1.Student Entity into Student Relation

Explanation: As student entity is a strong entity, it is converted directly with all its
attributes as the column and entity name as the schema name
Schema Structure : Student ( s_id, s_name, age, father_name, fa_ph_no, d_o_b,
grp, st_name, place, phone_no, st_id,code)

Page 5 of 29
………………………………………………………………………………………………………

2.Attendance entity

Explanation: As attendence entity is a strong entity, it is converted directly with all

its attributes as the column and entity name as the schema name
•Schema Structure : Attendence ( date,status,s_id,st_id)

3.Staff entity
Explanation: As staff entity is a strong entity, it is converted directly with all its
attributes as the column and entity name as the schema name
Schema Structure : Staff( exp,id,ph no,d_o_j)

Page 6 of 29
………………………………………………………………………………………………………

4.sports entity

Explanation: As sports entity is a strong entity, it is converted directly with all its
attributes as the column and entity name as the schema name
Schema Structure : Sports( sp_name,captian,coach)

5.office entity

Explanation: As office entity is a weak entity, it is converted with primary key of

the strong entity acting as the foreign key in the table.
Page 7 of 29
………………………………………………………………………………………………………

Schema Structure : office(s_id,reciep_no,status,fee_amnt)

6.subject entity

Explanation :As subject entity is a strong entity, it is converted directly with all its
attributes
as the column and entity name as the schema name.
Schema Structure : subject(code,name)

6.exam entity

Explanation: As exam entity is a weak entity, it is converted with

primary key of the strong entity acting as the foreign key in the table.
Page 8 of 29
………………………………………………………………………………………………………

Schema Structure : exam( s_id,code,venue,date)

8.employee entity

Explanation: As employee entity is a strong entity, it is converted directly with all

its attributes as the column and entity name as the schema name.
Schema Structure : employee( emp_id,address,st_name,place,ph_no)

participate Relationship into participate Relation

Explanation: As the participate relationship exists between two strong entities
student and Sports it is a strong relationship with many-to-many relationship. ‘A
many-to-many relationship set is represented as a schema with attributes for the
primary keys of the two participating entity sets and any descriptive attributes of
the relationship set’.
Schema Structure: Participate (s_id,sp_id,achievements )

Page 9 of 29
………………………………………………………………………………………………………

7.2 Relational diagram

Page 10 of 29
………………………………………………………………………………………………………

Page 11 of 29
………………………………………………………………………………………………………

8.Functional Dependencies and Normalization

Table Name: Student

S_id -> S_name, S_id -> age, S_id -> D_O_B, S_id -> Father_name, S_id -> phone no, S_id
-> st_name, S_id -> grp
Father_name -> Fa_ph_no, st_name -> place.

Table Name: Sports

Sp_name -> captain, Sp_name -> Coach

Table Name: Subject

Code -> Name

Table Name: Staff

St_id -> St_name, st_id -> age, St_id -> D_O_J, St_id -> sub_code,
St_id -> ph no, St_id -> place.

Table Name: Office

St_id -> Fee_amt, St_id -> Receipt_no, Receipt_no -> status

Table Name: Participate

S_id , Sp_name -> Achievement

Table Name: Cls teacher

Std,sec -> st_id

Table Name: Attendance

Date, S_id -> St_id, Status

Table Name: Marks

S_id -> Tamil, English, maths, physics, chemistry, biology, computer.

Page 12 of 29
………………………………………………………………………………………………………

Table Name: Exam

S_id, code -> venue, date

Table Name: Employee

Emp_id -> emp_name, Emp_id -> St_name, Emp_id -> ph no
St_name -> place.

NORMAL FORMS
TABLE NAME:STUDENT
1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
The table has some partial dependencies. Fa_ph_no is depend on Father name and
place depends on St_name. So, decompose the table into smaller tables
Now , all the entries are fully functional dependent on primary key.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

TABLE NAME :SPORTS

1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
Captain and Coach are fully functionally dependent on primary key Sp_name. So,
it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Page 13 of 29
………………………………………………………………………………………………………

TABLE NAME :SUBJECT

1NF:

This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on primary key. So, it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Table name:Staff
1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on primary key St_id. So, it satisfies
2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

TABLE NAME:OFFICE
1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
Status is not depend on primary key. So, decompose into smaller tables
Now, the tables are in 2NF.

3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Page 14 of 29
………………………………………………………………………………………………………

Table NAME:PARTICIPATE
1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent. So, it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

TABLE NAME:CLS TEACHER

1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on Composite primary key Std, sec.
So, it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

TABLE NAME:ATTENDANCE
1NF:
This table satisfies the condition of 1NF
(i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on composite keys Date and S_id. So,
it satisfies 2NF
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Page 15 of 29
………………………………………………………………………………………………………

Table Name: MARKS

1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on primary key St_id. So, it satisfies
2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Table NAME :EXAM

1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.
2NF:
All Entries are fully functionally dependent on composite keys St_id and code. So,
it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.
TABLE NAME: EMPLOYEE
1NF:
This table satisfies the condition of 1NF (i.e.) the entries have atomic values.

2NF:
The table has some partial dependencies. Place depends on St_name. So,
decompose the table into smaller tables
Now, the entries are fully functionally dependent. So, it satisfies 2NF.
3NF:
This table has no transitive dependencies. So, automatically it is in 3NF.

Page 16 of 29
………………………………………………………………………………………………………

9. Data Dictionary

9.1 subject
Subject relation

Page 17 of 29
………………………………………………………………………………………………………

Page 18 of 29
………………………………………………………………………………………………………

Page 19 of 29
………………………………………………………………………………………………………

10 Complete Database for Student Database Management Systems

10.1 Attendance

10.2 class

10.3 Employee

10.4 EXAM

Page 20 of 29
………………………………………………………………………………………………………

10.5 OFFICE

10.6 PARTICIPATION

10.7 SPORTS

10.8 STUDENTS

10.9 SUBJECTS

Page 21 of 29
………………………………………………………………………………………………………

10.10 STAFFS

Page 22 of 29
………………………………………………………………………………………………………

Page 23 of 29
………………………………………………………………………………………………………

Data Manipulation – SQL queries

Page 24 of 29
………………………………………………………………………………………………………

Page 25 of 29
………………………………………………………………………………………………………

Page 26 of 29
………………………………………………………………………………………………………

Page 27 of 29
………………………………………………………………………………………………………

Page 28 of 29
………………………………………………………………………………………………………

Page 29 of 29