Professional Documents
Culture Documents
UNIVERSITY OF COLOMBO
FACULTY OF GRADUATE STUDIES
Submitted for the fulfillment of requirements as Assignment for the module User Centered Database Design
By Evan Pathiratne
EXECUTIVE SUMMARY
This documentation is relating to database design proposed to be the backend of a new computerized automation system. The automated system is envisioned to improve the operational functions within the organization.
This does not include any information related to database development or deployment, or any specifications on the computerized automation software package, but a high level overview primarily focusing on the database. The activities involved in why such a database is selected and how it will aid the automation system.
The company chosen is Institute of Chemistry Ceylon. This is the only local academic institute providing chemistry lectures for post A/L students. It has no direct competitors but competes for the target market of school leavers with institutions such as APIIT and ACBT.
The institute has taken a forward step into reengineering their business processes by initially computerizing some of its core business functions. Some of which include student management. This document contains a proposed database design for that computerized system. In order to get an overview of the operations currently undertaken at the institute interviews were conducted.
Afterwards the findings were analyzed and the database design was derive. Extended Entity Relationship (EER) Diagrams were used to get a high level overview of the database model. Afterwards the logical and physical models were created.
TABLE OF CONTENTS
The institute provides a economically beneficial but also very effective and up-to-date courses in chemistry (biology and mathematics is also taught as support modules).Several students after the completion of this four level graduate courses have gone to do their higher level degrees such as masters and PhD to countries like France and the US. This shows that the institute and its education program is proven internationally as well.
The institute provides a four level degree programs that is equivalent to a local university B.Sc. special degree program. This is an opportunity for the post A/L students who was unable to transfer to local universities to get a certified chemistry degree from an internationally and locally recognized institute at an affordable price.
President
Vice President
Course Coordinator
Lecturers
Mentor
Network Administrator
Lab Instructor
Operations Conducing of lectures related to the field of chemistry. Marking attendance currently manually has opted for an automated attendance tracking barcode system to be implemented. Preparing effective time table schedules for the institute lecturers. Module evaluation in terms of the course structure and its contents. Evaluation done by two criteria, written exams and practicals. (It is to be noted that the panel of lecturers in the institute decide the weighted percentages of written and practical exam marks for each module that the students undertakes.) Lectures are conducted in different faculties. These faculties each have one course program (Ex- Analytical Chemistry Stream, Electro Chemistry Stream, Organic Chemistry Stream Etc.) Each study stream will have different modules that will be taught lecturers. Lecturers get aid from lab instructors for practicals, and students have computer lab facilities to do there assignments and analytical functions .Network administrators are present in the computer labs. Student carrier guidance program done through an appointed mentor (this is optional for students) which will help the students in figuring out their paths in the field of chemistry.
The student enrolment is done in a traditional way (totally paper based). The course coordinator of the institute handles all inquires related to prospects and selects the qualified students and enrolls them to the institute. Different registries are kept for different faculties. Also different batches are kept in different registry books. No proper records are kept on different modules. Whenever a need for a module description arises the course coordinator and subject specialty lecturer discusses the module contents (examination criteria, number of credits, pass marks) and publishes them on institute journals/ brochures and publications.
Students usage of computers in labs and experiment desks in laboratories is done without any senior member supervision. Any vacant experiment desk available will be used. There is no option of pre booking assets for scheduled use for any practical.
This is the case for lecture hall booking as well. The current process does not allow lecturers to view available laboratory rooms or lecture halls to conduct lecture sessions or practical sessions. The process currently is completed by communication between lecturer and course coordinator verbally.
Student attendance records are not kept. There is currently no process for marking and storing student attendance to lecture sessions or practical sessions.
4. Room booking for lecturers and asset bookings (Computers and laboratory experiment desks) for students can be automated and made more efficient.
Maintain student performance to the highest standards by supporting them, providing them more control over institute assets in a controlled manner.
This will inadvertently create a general concise that this institute is maintaining international standards amongst internal and external student communities. This is important when competing with secondary competitors such as IT and business degree offering institutes such as APIIT, ANC and ACBT.
Each of the above mentioned modules will cover those respective areas under its operation. (Detailed EER diagrams representing the data flows and entities is given in chapter 5) The database model however will not store any data related to payroll functions or library functions since that is currently managed through a separate system and a separately built database.
10
Summary -This was done at the initiation phase of the project to get an overall company view from a managers perspective and to get to know the scope of the problems found. The information discussed in 1st and 2nd chapters was documented through the findings in this interview. And also an overall idea on the business transactions that the institute uses was identified.
Second Interview Interviewee- Course Coordinator Date-2010/04/05, Monday (Phone Interview) Time -2.30 p.m
Summary -To identify the core processes in the institute and understand how it is being carried out. The student enrolment process, how the assessments are marked? How are the student information kept? were found out from this interview .The information found from this interview is documented is reflected on the EER diagrams in chapter 5. The core processes involved and the difficulties faced when committing to a fully manual transaction management system was identified from this interview.
From this phase of the project the requirements for the database was identified. This lead to the formation of the functional requirements for the database
11
Users of the system will be, 1. Student Enrolments Module (Student, Course coordinator) 2. Exams and Grading Module (Student, Lecturer, Exam Supervisor, Course coordinator) 3. Room Booking Module (Lecturer, Exam Supervisor, Course coordinator) 4. Asset Booking Module (Student) 5. Student Attendance Module (Student via attendance tracking system)
12
13
Logical Reasoning
Student related some attributes that require lengthy data store requirements have to be kept as data type string. A multi valued attribute was not placed because it will create unnecessary additional tables Student mentoring is an optional service for a student. Hence partial dependency There is only one course coordinator having administrative rights to update the time tables. One faculty contains a section of modules. These modules are a study stream for a student. Lecturer determines the written and practical percentages for the modules.
14
15
Logical Reasoning
Marks entity is categories as a weak entity because without the module it relates do not exist all the marks are no longer needed to be kept of it. This weak entity however has a relationship with lecturer as well. Course coordinator needs to validate the recheck submit request from student before it is sent to the lecturers to avoid unnecessary request. Such data has to be stored separately. The number of time a module exam has been rechecked also needs to be stored hence its presented as an attribute on the relation. The exam supervisors are not lecturers so they have to be stored separately. The give their feedback on student performance on the exam(such as plagiarism offences) that is needed for lecturer to perform penalizations on exam marks. This feedback is stored separately for later use (in occasions such as student evaluations)
16
17
Logical Reasoning
The entities within room booking also need to be uniquely identified by its own ID. Hence the relationship is U instead of a normal disjoint. Surrogate keys will be in use.(Later depicted in relational schema) Updates relates to the users making bookings and updating the details of it. Only one network administrator and one lab instructor is given access privileges for making bookings.
18
19
Logical Reasoning
Timeslot is a multi valued attribute because different timeslot data has to be stored for every booking that is made. The data on this attribute will be represented in a separate relation in the relational schema. Many lab instructors are working in one lab. But for one computer lab only one network administrator is present. The test labs are for students research work. And data related to that has to be stored separately.
20
21
Logical Reasoning
Attendance has to be keep track of for both lecture session as well as practical session, hence two separate entities. Each entity has to be uniquely identified from each other instead on joining them as a session entity. (If this was done a common primary key has to be used to identify both lab and lecture sessions)
22
23
24
2. Exam & Marks Module a. Student(StdID, FirstName, LastName, StdEmail, StdAddress, StdPhone, StdQualification) b. Module(ModuleID, ModuleName, LecPercentage, PracPercentage, Mod_Description, MarkedBy, OverseenBy ) [ MarkedBy foreign key field is the primary key LecID of the Lecturer entity. It has been renamed here to improve understandability and readability] [ OverseenBy foreign key field is the primary key SupervisorID of the ExamSupervisor entity. It has been renamed here to improve understandability and readability] c. Modules_Taken(StdID, ModuleID, AttemptNo)
25
d. Lecturer(LecID, LecName, LecPhone, LecEmail, LecAddress, LecQualification) e. ExamSupervisor(SupervisorID, SupName, SupEmail, SupAddress, SupPhone) f. Marks(ModuleID, MarksID, WrittenExMarks, PracMarks, StdID, LecID) g. FeedbackGiven(SupervisorID, LecID, Feedback) h. Course_Cordinator(Co_CordinatorID, Co_CordinatorName, Co_CordinatorEmail, Co_CordinatorPhone ) i. ExamTimeTable(ExTimeTbID, ModuleName, Date, StartTime, EndTime, Co_CordinatorID) j. Lec_Refer_ExTmTable(LecID, ExTimeTbID) k. Award(AwardID, AwardName, Year, UpdatedBy, StdID) [UpdatedBy foreign key field is the primary key Co_CordinatorID of the Course_Cordinator entity. It has been renamed here to improve understandability and readability] l. RecheckApplication(RecheckID, Notes, StdID, ReferredBy) [ReferredBy foreign key field is the primary key Co_CordinatorID of the Course_Cordinator entity. It has been renamed here to improve understandability and readability] m. Pass_Recheck_Request(Co_CordinatorID, LecID, RecheckID) 3. Room Booking Module a. Lecturer(LecID, LecName, LecPhone, LecEmail, LecAddress, LecQualification) b. Room_Booking(BookID, Date, Start_Time, End_Time, NoOfParticipants, Notes) c. Lecture_Hall(LHallID, Purpose, Request_by, BookID, UpdatedBy) [UpdatedBy foreign key field is the primary key Co_CordinatorID of the NetworkAdministrator entity. Its has been renamed here to improve understandability and readability] d. Computer_Lab(ComLabID, NumberOfPCs , ComPractical_Info, BookID, UpdatedBy) [UpdatedBy foreign key field is the primary key NetAdminID of the Course_Cordinator entity. Its has been renamed here to improve understandability and readability]
26
e. Chemistry_Lab(ChemLabID, NumberOfDesks , NumberOfInstr, ChemPractical_Info, BookID, UpdatedBy ) [UpdatedBy foreign key field is the primary key LabInsID of the LabInstructor entity. Its has been renamed here to improve understandability and readability] f. Lecturer_RoomBooking(LecID, BookID) g. Course_Cordinator(Co_CordinatorID, Co_CordinatorName, Co_CordinatorEmail, Co_CordinatorPhone ) h. NetworkAdministrator(NetAdminID, NetAdminName, NetAdminAddress, NetAdminEmail, NetAdminPhone ) i. LabInstructor(LabInsID, LabInsName, LabInsEmail, LabInsAddress, LabInsPhone) 4. Asset Booking Module a. Test_Lab(LabID, LabType, LabSize, LabLocation) b. Computer_Lab(ComLabID, NumberOfPCs, ComPractical_Info, LabID) c. Chemistry_Lab(ChemLabID, NumberOfDesks, ChemPractical_Info, NumberOfInstr, LabID) d. NetworkAdministrator(NetAdminID, NetAdminName, NetAdminAddress, NetAdminEmail, NetAdminPhone ) e. LabInstructor(LabInsID, LabInsName, LabInsEmail, LabInsAddress, LabInsPhone) f. ComLab_Manage(ComLabID, NetAdminID, DateOfAssignment) g. LabIns_Worksin(ChemLabID, LabInsId, DateOfAssignment) h. BookingSchedule(ScheduleID, ScheduleType, Date, LabID) i. Session(SessionID, ScheduleID) j. TimeSlot(SessionID, TimeSlot) k. Std_Ses_Res_Booking(StdID, ResourceID, SessionID) l. Student(StdID, FirstName, LastName, StdEmail, StdAddress, StdPhone, StdQualification) m. Resource(ResourceID, ResourceType, ResourceLocation, LabID) n. Computer(MachineID, Brand, Speed, HardDisk, Memory, ResourceID) o. Experiment_Desk(DeskID, DeskSize, ResourceID)
27
5. Student Attendance Module a. Student(StdID, FirstName, LastName, StdEmail, StdAddress, StdPhone, StdQualification) b. LectureSession(LecSes_ID, LecSes_Title) c. LecSes_Attendance(StdID, LecSes_ID, Attend_Date) d. PracticalSession(Prac_ID, Prac_Title) e. PracSes_Attendance(StdID, Prac_ID, Par_Date ) f. Module(ModuleID, ModuleName, LecPercentage, PracPercentage, Mod_Description) g. LecSes_PracSes_Module(LecSes_ID, Prac_ID, ModuleID)
Next page details the physical models of the identified relational schemas.
28
29
30
31
32
9.0 CONCLUSION
The proposed database design is mainly targeted at aiding the institute in supporting it daily transactions. The database will act as a single point of storage for institutes essential data, its main hub. The design stages of the project were the most complex in this project due to the fact each module was done by separate designers. Initially several guidelines and standards were agreed upon (Ex-naming conventions) to avoid confusion when ER views are integrated.
The whole project was done having the 3NF database model in mind even from the initial stages. This saved the team time because automatically the tables were in its 3NF form.
ACKNOWLEDGEMENTS
My group appreciates the guidance and tutoring provided by the module lecturer Mr. Rukshan Manchanayake, who aided us in understanding the basic concepts of database modeling and how it could be viewed from a manager business perspective. The practical approach shown by him in his lectures by using case studies and many inclass exercises aided us in understanding these concepts better.
The following cooperate web site has been used in the compilation of this research and analysis paper , further information can be obtained from it. Institute of Chemistry Ceylon (2010). [Online]. http://www.ichemc.com/ [Accessed 21th April 2010]
33