Post on 30-Jan-2018
BILKENT UNIVERSITY
ENGINEERING FACULTY
DEPARTMENT OF COMPUTER ENGINEERING
CS 352
DATABASE MANAGEMENT SYSTEMS
TERM PROJECT
Proposal Report
Buse Öter Gurur Dikmen Özge Dirlik 20701898 2070000 20802549
Group #2
http://studentinternshiptrackingsystemgroup2.wikispaces.com/
Table of Contents
Introduction........................................................................................................3
Problem Statement ............................................................................................3
Requirements......................................................................................................4
Limitations of System.........................................................................................5
Definitions...........................................................................................................6
ER Diagram........................................................................................................8
Data Dictionary..................................................................................................9
Conclusion........................................................................................................15
2
1. Introduction
This report defines our CS 352 project named as Student Internship Tracking System. Our
main aim is to build an internship tracking system as closely as possible. Our system will
store required information in order to complete a internship process. This report summarizes
our system architecture and gives a brief description about the system with the help of ER
Diagram.
2. Problem Statement
Student Internship Tracking System fundamentally coordinates the internships of students of
a specific university. The system will keep track of faculties, departments, secretaries,
students, companies, announcements and quotas.
According to the system, there are several faculties which have a unique faculty acronym such
as ENG for Engineering, a name and details. Each faculty has many departments which have
department acronym such as CS for Computer Engineering/Science, details about department
and also faculty acronym in order to store information of each department related with which
faculty. Moreover, there will be a secretary who has id, faculty acronym in order to know s/he
works for which faculty, department acronym, name, details, username and password, works
for only one faculty. In addition to the secretary, system keeps track of another person type
which is student. Students have student id, department acronym, year, cgpa apart from
personal information.
There will be different user types such as secretaries and students. Secretaries and students
will have different permissions while using the system. A secretary, will be able to open
3
quotas for specific companies and also secretary will have the right of deciding about quotas,
and s/he will provide announcements with id, status and a deadline to the students.
Students will be able to apply for registered companies’ quotas or add the self found
companies for their internship. Students will be able to see open quotas for their departments
or faculties and also they can apply quotas according to the availability of the desired quotas.
In addition to these, a student can accept or reject the quota which is announced. System
allows to students so as to change the status of the announcements which informs about
quotas. If a student rejects a quota, secretary will be able to assign this open quota to another
student. Moreover, a student can found a company for his internship. In such a situation,
system automatically assigns the found company to this specific student.
Furthermore, all events will be logged in order to prevent data loss and keep the system safe.
Also the system should be easily backed up. The system can also be implemented with using
data structures such as using files, however by using database for managing data; it will be
much more reasonable and efficient. It is obvious that the advantages of relational database
concept have proven, so we decided to design our system by using a relational database.
Rather than implementing our own database, using a well known database server application
is more feasible. We should also provide a user interface in order not to interact directly with
the database's storage and management details. We will manage an understandable and clear
user interface to provide easy and fast usage of the reservation system to users.
3. Requirements
The students can use the system as a guest or registered user. However, guest users cannot
make application for quotas only can see announcements.
The registered students is able to do the following functions:
4
>> Students apply for quotas (until the application deadline)
>> A student can accept or reject the quota.
>> A student have a quota for self found company by adding quota or company with the help
of secretary.
The secretary should have following management functionalities:
>> If a student reject a quota, the secretary can see this “open” quota and assign it to another
student.
>> A secretary is able to provide announcements.
>> A secretary can add new quotas or new companies.
Moreover, the system allows to do some of the followings;
>> Making multiple applications for a student will be possible.
>> Reaching the quota information of the registered companies will be possible.
>> Adding a self found company to the system will be possible.
>> Error checking will be available: While a student applying for a quota, the system checks
for asked information are filled completely or not. If it is not full, the system gives an error.
Also, if the student tries to make application for not available quota, system gives warning to
the student. The system updates the quotas according to new applications.
>> Notifications: The system notifies the registered users about the changes about the system
such as changes in quotas. For instance, a student reject a quota secretary is notified by the
system in order to announce it to another student.
4. Limitations of System
If a user wants to enter the system, they must have username and password. Without these
guest user can only see the announcements. Secretaries and the students have different access
of the system such as students cannot open quotas, they can only see open quotas and they can
5
accept or reject specific quotas or assignments. Moreover, secretaries decide whether a
student will get into that quota or not.
Students cannot enter the system with their student ID and password. They should have a
username and a password for this system.
If the specific quota is full then students cannot apply to this quota.
Every company has to have at least one unit according to the system because quotas opens
according to the units of companies for students of specific faculty or department.
5. Definitions
We have 14 entities which are company, registered company, self_found_company, unit,
quota, student, secretary, announcements, faculty, person, internship_aplication ,
registered_aplication, self_found_application and department. In this section, we will
explain what they do explicitly.
Company: Company has company id (comp_id), name, city which it locates and an address.
All companies have units. Each unit have unit_id, comp_id, name, quota_capacity,
quota_contact_person, quota_deadline, quota_internship_period. There is also registered
company and self_found_company which are inherited by company. Self_found_company
also has contact_person_name, contact_person_title. For regisered_companies, there should
be opened quotas and for self_found_companies, the student should find one company.
Quata: It has these attributes unit_id, quota_capacity, quota_contact_person, quota_id,
quota_deadline, quota_internship_period.
Student and secretary entities are actually a person entity.
Person: Person's attributes are social security number (ssn), name, password, username and
details.
6
Student: Student should have student id, department id (dept_id), year of the attendance to
the school and CGPA.
Secretary: Secretary has secretary id (sec_id), fac_acro and dept_id. Secretaries provides
announcements and every announcements must provided by a secretary.
Announcement: Every announcement has announcement id, deadline and status.
Internship Application: Internship application with attributes of the app_status, app_date,
internship_granted, app_id, end_date and start_date is received by the company and it must be
applied by a student. Also the registered_aplication and self_found_application entities are
Internship application.
Registered Application: It has quota_id and student_id attributes.
Self Found Application: Self_found_application has com_id, student_id attributes and
registered_aplication has quota_id, student_id attributes.
7
6. ER Diagram
7. Data Dictionary
8
7.1. Company:
Fields Domains Constraints Description
city Varchar (100) ------------------ City which company locates
comp_id Integer Primary Key Every company has unique ID
address Varchar (100) ------------------- Address of the company
name Varchar (50) ------------------- Name of the company
7.2. Registered Company:
Fields Domains Constraints Description
city Varchar (20) --------------------- City which company locates
comp_id Char (10) Primary Key Every company has unique ID
address Varchar (200) ---------------------- Address of the company
name Varchar (50) ----------------------- Name of the company
7.3. Self_Found_ Company:
Fields Domains Constraints Description
city Varchar (20) ---------------------- City which company locates
comp_id Char (10) Primary Key Every company has unique ID
address Varchar (200) ---------------------- Address of the company
name Varchar (50) ---------------------- Name of the company
contact_person_name Varchar (50) ----------------------- Name of the student’s advisor
contact_person_title Varchar (50) ----------------------- Advisor’s job at the
9
company
7.4. Unit:
Fields Domains Constraints Description
com_id Integer Not Null Company ID
name Varchar (100) ------------------------ Name of the unit
quota_capacity Integer ------------------------ Quota size
quota_contact_person Varchar (50) Not Null Contact person name for the quota
quota_deadline Varchar (8) Not Null Deadline to apply the quota
unit_id Char (10) Primary Key Id of the unit
quota_internship_period
Integer ------------------------ The internship date interval
7.5. Quota:
Fields Domains Constraints Description
quoto_id Integer Primary Key Quoto ID
quota_capacity Integer ------------------------- Quota size
quota_contact_person Varchar (50) ------------------------- Contact person name for the quota
quota_deadline Varchar (8) ------------------------- Deadline to apply the quota
unit_id Char (10) ------------------------- Id of the unit
quota_internship_period
Integer ------------------------- The interval of the date which student will do internship
7.6. Announcemnets:
Fields Domains Constraints Description
anno_id Integer Primary Key Announcement ID
status Varchar (20) ------------------------ Announcement is
10
accepted/rejected
deadline Varchar (8) Not Null End date of announcement to be valid
7.7. Faculty:
Fields Domains Constraints Description
fac_acro Varchar (10) Primary Key Acronym of the Faculty
fac_name Varchar (100) ------------------------- Name of the faculty
fac_details Varchar (200) ------------------------- Other details about the faculty
7.8. Department:
Fields Domains Constraints Description
dept_acro Char (10) Primary Key Acronym od the Department
fac_acro Varvhar (10) ------------------------- Acronym of the department
dept_details Varchar (200) ------------------------- Other details about the department
7.9. Person:
Fields Domains Constraints Description
ssn Char (12) Primary Key Social Security Number of the person
name Varchar (100) ------------------------- Name of the person
username Varchar (20) ------------------------- Username of the person to enter the system
password Varchar (20) ------------------------- Password of the person
11
to enter the system
details Varchar ------------------------- Details about the person
7.10. Secretary:
Fields Domains Constraints Description
ssn Integer Primary Key Social Security Number of the person
name Varchar (100) ------------------------- Name of the person
username Varchar (20) ------------------------- Username of the person to enter the system
password Varchar (20) ------------------------- Password of the person to enter the system
details Varchar (100) ------------------------- Details about the secretary
fac_acro Varchar (10) Not Null Acronym of the faculty that secretary works in
sec_id Char (10) Primary Key Secretary ID
dept_acro Char (10) ------------------------ the department ID of the secretary
7.11. Student:
Fields Domains Constraints Description
ssn Integer Primary Key Social Security Number of the person
name Varchar (100) ------------------------ Name of the person
username Varchar (20) ------------------------ Username of the person to enter the system
password Integer (20) ------------------------ Password of the person to enter the system
details Varchar (200) ------------------------- *******
student_id Char (10) Primary Key Student ID12
dept_acro Char (10) Not Null Department ID of the student
year Varchar (4) Not Null Year of the attendance to the school of the student
cgpa DOUBLE Not Null Cgpa of the student
7.12. Internship_Application:
Fields Domains Constraints Description
app_status Char (1) ‘A’ or ‘R’ Application is rejected or accepted
app_date Varchar (8) Not Null Application date
internship_granted Char (1) ‘Y’ or ‘N’ If the internship are rejected or not
app_id Char (10) Primary Key Application Id
end_date Varchar (8) Not Null The last day of the internship
start_date Varchar (8) Not Null The first day of the internship
7.13. Registered_ Application:
Fields Domains Constraints Description
app_status Char (1) ‘A’ or ‘R’ Application is rejected or accepted
app_date Varchar (8) Not Null Application date
internship_granted Char (1) ‘Y’ or ‘N’ If the internship are rejected or not
app_id Char (10) Primary Key Application Id
end_date Varchar (8) Not Null The last day of the internship
start_date Varchar (8) Not Null The first day of the internship
quota_id Char (10) Not Null Quota ID
student_id Char (10) Not Null Student ID
13
7.14. Self_Found_ Application:
Fields Domains Constraints Description
app_status Char (1) ‘A’ or ‘R’ Application is rejected or accepted
app_date Varchar (8) Not Null Application date
internship_granted Char (1) ‘Y’ or ‘N’ If the internship are rejected or not
app_id Char (10) Primary Key Application Id
end_date Varchar (8) Not Null The last day of the internship
start_date Varchar (8) Not Null The first day of the internship
student_id Char (10) Not Null Student ID
comp_id Char (10) Not Null Company ID
8. Conclusion
The Student Internship Tracking System provides many benefits over the traditional pen and
paper log books. Thanks to the system, students are much more comfortable can follow
internship opportunities. Moreover, quotas of companies can be reached by students.
Secretaries for an internship give information to students for registration. Connection is
established between student and companies more easily thanks to this system.
14