Group Members:

Nishit Gupta IIT2014502

Sachin Agarwal IIT2014501
Nikhil Ranjan IIT2014129
 This Project is a Web-based Portal which
performs the following:

Displays the Personal Profile of a student.

Displays the Academic Profile of a student which includes
the students current branch, semester, subjects
undertaken and respective scores of each subject.
Generates the result by using the information from the
Database.
Keeps a record of the official documents with/not with the
institute.
Displays the Rank List of a batch.
Other features like login system, changing password,
modifications or updations, additions of records (by
administrator) etc.
Table 1: user
3NF
user_type user_name password 1. No composite
attributes.
2. No partial
dependency.
3. No transitive relation.

Table 2: student
enroll_no name dob gender contact_no mail_id

3NF
1. No composite attributes
and no repeating
groups.
2. No partial dependency.
3. No transitive relation
However, the problem with this schema is that we can not
identify the branch and sem of the student and thus it
becomes difficult to relate it with subject table.
student(enroll_no) -> subject(sub_code, sub_name)
(not a good relation). Hence we have to add sem and
branch attributes in this table
Table 3: subject
enroll_no sub_code sub_name sem branch score

1NF
1. No composite attributes and no repeating groups.
Here, we dont have a primary key as we have multiple records for a
single enrollment no. No dependency of any type (partial / total)
Therefore, not in 2NF.
Secondly, from enroll_no->sub_code->sub_name/sem/branch. Hence
not in 3NF
We split this table into two to normalize.

Table 4: result
enroll_no total_score grade status

3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. enroll_no->total_score/grade/status.
3. No transitive relation.
Table 5: doc_status
Composite Primary Key

enroll_no doc_id doc_name doc_handler issue_date due_date

1NF
1. No composite attributes and no repeating groups.
2. We can get doc_name from doc_id only which is a partial dependency
on the key attribute. Hence, not in 2NF
3. No scope for 3NF

We split the table into two, one of which holds the doc_id
and doc_name only and other containing the details of
the documents.
 Table 1: user
3NF
user_type user_name password 1. No composite
attributes.
2. No partial
dependency.
3. No transitive relation.

Table 2: student
enroll_no name dob gender contact_no mail_id sem branch

3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. All non-key attributes are fully dependent on
enroll_no (primary key).
3. No transitive relation i.e from enroll_no, we can identify other attributes but
by non-key attributes we can define any other attribute.
Table 3: subject
sub_code sub_name sem branch Table is formed in such a way
that new subject can be
added.

3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. All non-key attributes are fully dependent on
sub_code i.e from sub_code we can get sub_name, sem and branch.
3. No transitive relation. From sub_code we can get sem/branch but from
sem we cant identify branch.
Table 4: marks Composite
Primary Key
enroll_no sub_code score

Flattened Table
3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. score is totally dependent on both enroll_no and
sub_code i.e from enroll_no alone we cant get score and same with
sub_code. However enroll_no and sub_code together relate to score.
3. No transitive relation.
Table 5: result
enroll_no total_score grade status

3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. enroll_no->total_score/grade/status.
3. No transitive relation.

Table 6: documents

doc_id doc_name

3NF
1. No composite attributes and no repeating groups.
2. Document Name (doc_name) is fully dependent on
Document ID (doc_id).
3. No transitive relation.
Table 7: doc_status

Composite Primary Key

enroll_no doc_id doc_handler issue_date due_date

Flattened Table

3NF
1. No composite attributes and no repeating groups.
2. No partial dependency. doc_handler, issue_date and due_date are
totally dependent of composite key attributes enroll_no and doc_id.
Both the key attributes define other attributes and we cant relate to
doc_handler, issue_date and due_date with only one key attribute.
3. No transitive relation.
 Admin can:
Login Securely choosing admin login option.
Add a new student record.
Modify an existing student record.
Have a glance of all student records in the
database at one place.
Search details of a specific student.
Issue a document to a student on request.
Submit a document back to the Exam-Cell
on being provided by the student.
Securely log out of the system.
 Student can:
Login Securely choosing student login option.
Check out his personal profile.
Manage account details like changing the
password.
Look for his/her batch report and see the rank list
according to marks/grade.
Look for all his details like marks in every subject,
his overall grade and his/her final result.
Check which documents are with the institute.
Can see the due date and issue date in case
the document is with the student.
Securely log out of the system.
 PHP
HTML5
CSS3
MySQL
Javascript
XAMPP
 Nikhil Ranjan IIT2014129
Back-end, PHP and Database Connectivity.
Nishit Gupta IIT2014502
Front-end, HTML5, Database Schema, SQL
Queries, Conceptual Design.
Sachin Agarwal IIT2014501
Front-end, CSS3, Logic developer, Relational
Database Model and Architecture.