2011 International Conference on Electrical Engineering and Informatics 17-19 July 2011, Bandung, Indonesia

Academic IS for Higher Education Institutions: The Design of Speedy Courses Registration Transaction

Function Veronica S. Moertini#1, Tety Yuliaty*2, Wisnu Rumono*3

#Informatics Department, * Information Technology Bureau Parahyangan Catholic University, Bandung, Indonesia

1moertini, 2yuliaty, 3wisnu@home.unpar.ac.id

Abstract— Developing Academic IS (AIS) for HEIs is a highly complex task as many issues need to be resolved, such as how to provide course registration transaction function that provide speedy access for thousands of students. This paper discusses the function design to resolve the issue, which involves database physical, algorithm of data pre-processing for course eligibility computation and personalized user interface design. The design has been implemented in the AIS and used in Parahyangan Catholic University Indonesia successfully. Keywords— academic information systems, speedy course registration function, physical database design.

I. INTRODUCTION The use of online Academic Information System (AIS) in the higher education institutions (HEIs) has been becoming necessity in order to provide better services for the students (to access information 24/7 online) as well as to increase the institutions efficiencies. However, developing AIS for HEIs is a highly complex task as many issues need to be resolved (see our previous research result [1] in order to obtain a high quality product. As stated in [2], to manage IS quality, quality checklist and metrics must be defined, which could be stated as critical success factors (CFS), where must be defined in the requirement stage and then resolved in the next stages. We have formulated CFS for AIS where it states that AIS must provide speedy course registration transaction (with elapsed time is at most 1 second) and easy-user friendly interface for the students [1]. To achieve the performance standard, the main challenge is: While the function might be executed by hundreds of concurrent students, it must also perform complex computation in determining the course eligibility for each student with lots of access to the SIA database tables (as the eligibility would be determined based on their past grades, courses enrolled, etc.). Therefore, the research is aimed to find the function design that meets the performance standard. Although AIS has been widely needed, through literature study, there are only very limited research results, such as presented in [3]. We find no research result discussing such function design that must be resolved by specific approaches.

The paper is presented in the following order: The related literature study result, the proposed method, followed by the implementation evaluation, and conclusion.

II. LITERATURE STUDY Indonesia regulation [4] outlines that HEIs must apply credit semester system, where every semester students must enrol a number of credit courses (any course is weighted by credits). Undergraduate students must complete between 144 to 160 credits, master 36 to 50 credits, and doctorate at least 40 credits. Grade of any course is given on alphabetical index (A, B, C, D, and E, where E means fail). Based on literature study of many HEIs curriculum, we found that in applying the system, the HEIs implement course prerequisite based on the past students course enrollment and grades. In the university of case study, Unpar, the prerequisite could be classified into: (1) Number of passed credits, (2) the grade of previously enrolled course(s), (3) cumulative index of student and (4) parallel enrollment (certain courses must be enrolled together with other certain courses) [5]. The stages of designing databases for information systems are conceptual, logical and physical design [6]. While the main goal of the first two are to provide database that guarantee the completeness, integrity and accuracy of the data stored, the physical is to guarantee the database performance (such as speed and scalability). Hence, physical database design is a significant activity in designing the course registration function that extensively accesses database tables and is used by hundreds of concurrent users.

Data mining algorithms are intended to analyze very large size and possibly complex data. It is common that before presenting the dataset to a data mining algorithm, the dataset is preprocessed offline to reduce data size [7]. The preprocessed dataset with smaller size then could be mined (clustered, classify, etc.) faster. The idea of performing data preprocessing offline to speed up the mining process would be adopted in our proposed method to speed up the registration transactions.

In e-commerce, specifically e-CRM techniques, the concept of personalization has been used to strengthen the relationship

G7 -1

978-1-4577-0752-0/11/$26.00 ©2011 IEEE

between the merchants with customers [8], where web pages, email and other messages sent to customers are created by understanding individual’s need. To provide better services for the students, in the SIA course registration function, the concept of personalization would be applied by “understanding” students past grades and courses enrolled, then present the registration form based on individuals past achievement.

III. METHODS PROPOSED In designing course registration function that supports speedy transaction, the important issues that need to be resolved are: (1) How to design the transaction function that would be executed speedily by hundreds of concurrent users, as hundreds of students might conduct the registration at the same time. (2) How to design user interface that support easy and fast transactions. The main challenge comes from issue (1), as it involves course eligibility computation for each course and every student. On checking whether a student would qualify to enroll a certain course, the more complex its prerequisites, the more computations and disk I/O utilization required. As there could be hundreds of open courses that must be checked for every student, where as there are thousands of students, checking the prerequisite online could degrade the transaction speed greatly due to the time complexity of the algorithms and high disk I/O while accessing the database tables. Hence, we adopt data preprocessing concept to resolve the issue.

By considering the issues, in the case of AIS with centralized database, our proposed designs are:

(1) Physical database design: To avoid tables join operations and reduce the disk I/O, several tables are denormalized and many attributes are designed to have derived values. Horizontal partitioning is also implemented.

(2) Course eligibility preprocessing algorithm design: An algorithm is designed to “preprocess” (offline) the courses eligibility for every student. Therefore, during the online transactions, there is no need to check the course prerequisite.

(3) User interface design: The result of offline computation (“preprocessed courses”) for each student is then displayed in a “personalized form” to support fast and easy transactions.

A. Database Design We found that the main issue which must be resolved in providing fast course registration transaction for hundreds of concurrent users, where the intranet bandwidth is abundant, is disk I/O access. As the transaction data is stored in a database, the main focus is designing the database providing fast tables’ access. Hence, the physical database design is critical stage. In this section, we briefly discuss the result of conceptual and relational database design as the physical design corresponds to the result of these stages.

The Conceptual Design. Some part of the SIA database conceptual model is shown in Fig. 1. (Note: The relations that are not modeled in Fig. 1 are the departments’ transactions of opening courses either for internal or other department students).

Fig.1. Some part of the E-R diagram of AIS database. The main attributes of the entities and relations of the ER diagram shown in Fig. 1 are: Faculty: IdFac(PK), FacName. Dept: IdDept(PK),DeptName. Lecturer: IdLect(PK), LecName, Title. AcadYear: IdAY(PK), Sem, Year, Desc. Student: IdStu(PK), StuName. Course: IdC(PK), CName, credits. openclass: Class, RegTime, RegAppr, RegApprTime, ChangeTime, ChangeStatus, ChangeAppr, ChangeApprTime, AssignGrade, MidExGrade, FinalExGrade, FinalGrade, FinalIdxGrade. Prerequisite: Ncredits, IdxGradeReq, ParallelStatus, Formula. Tuition: Bill1, Pay1Time, Bill2, Pay2Time, Fine-1, Fine-2. The Logical Design. The E-R diagram shown in Fig. 1 is converted to relational diagram by following the rules described in [9]. The diagram consists of 9 relations depicted on Table I. To be brief, the diagram is not presented here. Physical Database Design. As it has been mentioned, here the physical design is the most important stage in designing database with speedy access. Therefore, detailed discussion would be given in this section. Volume and Transaction Analysis: Table I presents the result of the analysis. As shown in the table, there are several relations that would be accessed by high number of concurrent users, so this must be resolved.

TABLE I DATABASE RELATION ANALYSIS

Relation Vol Access Freq Concurrent Users

Faculty, Dept, Lecturer

Low R Low Low (*)

AcadYear Low R High High (**) Student,Course Medium R High High Prerequisite Medium R High High Tuition Medium R High High Open-class High R, I, U,

D High High

Note: Vol = Volume, Freq = frequency, (*) Low = less than 50, (**) High = up to 1000 concurrent users. R = read, I = insert, U = update, D = delete. The high number of concurrent users accessing the three relations is discussed as follows:

AcadYear: Only one record (containing the current semester-year) is accessed highly during the registration period. Tuition: The aim in accessing the records in this table is to check the student tuition payment for the current semester. open-class: In determining whether the course open is eligible for a student, depending on the prerequisite, a complex computation for checking the eligibility of the course is sometime needed. The design: The target transaction elapsed time is at most 1 second (counted since the SQL query is received by the DBMS and commit is done, the data transmission time overhead is not counted). In attempting to achieve the target, the following is the analysis and design: (1) The students statuses (active in the current semester, have

pay the bills, has registered courses, etc.) are very important. There are several main functions in the AIS that frequently evaluate the students’ status. If the statuses are computed online (by reading the course registration transactions in the last semester and tuition payment transactions on the current semesters), it would slow down the transaction. Therefore, a new relation, namely StdStatus, is created. It has derived attributes (the statuses of students that are computed before the period of course registration).

(2) The statistic of student grade (number of credits passed, average of grades in a semester, average of cumulative grade, etc.) is also frequently needed by the transaction function (such as to check the eligibility of a class based on the course prerequisite). If they are computed online which also involve tables join, it would slow down the function performance. Therefore, a new relation, GradeStat, is also created.

(3) The OpenClass relation contains many attributes that are highly accessed by two different AIS functions in the different period. The attributes related to course registrations are highly accessed at the course registration period, while the ones related to student grades are accessed in the grading period. By applying vertical partitioning technique [9], a new relation, namely Grade, is then created having the attributes related to student grades.

(4) To reduce the number of concurrent users accessing OpenClass, we then create many new denormalized relations, which are used to temporarily store registration transactions (during the registration period), namely RegisTrans_NNN and ChangeRegTrans_NNN where NNN denotes the IdDept (i.e. RegisTrans_071, RegisTrans_071, etc.). By this design, the course registration and change registration transactions in a department are stored in a separate physical table to reduce disk I/O contention. Then, the OpenClass relation is used to store the final courses enrolled by the students.

(5) To avoid of joining of many tables and for storing pre-computed of open classes and their eligibility statuses (whether a class could be enrolled) for every active student (in the current semester), we design two new relations, which are StdRegisClass and

StdChangeRegisClass. Both relations have the attributes of IdStu, IdCourse, and EligibleStatus. During the registration or change registration period, at any time only one table is read and the records are presented in the application registration form.

The final relational diagram after conducting the physical database design is shown in Fig. 2 (Note: to reduce the figure complexity, here, Student relation is drawn twice), where as the main attributes of the relations are given in Table II.

1

0..*

AcadYear

Student

Lecturer

Dept

Faculty

1

1..*

0..*

1…*

1…*

1

StdStatus

Tuition

Course

Perequisite

GradeStat

OpenClass

Grade

10..*

11

1

0..*

1

1 1..*

1

1

1..*

1

1..*

1

0..*

1

1

0..*

1…* 1..*

1..*

StdRegisClass

StdChangeRegisClass

RegisTrans_NNN

ChangeRegisTrans_NNN

Student 111 1 1..*1..*

1..*

1

*

1

Fig. 2 Some part of relational diagram of the Academic IS

database. TABLE III

THE MAIN ATTRIBUTES OF THE ADDITIONAL RELATIONS AFTER PHYSICAL DESIGN STAGE

Relation Main Attributes OpenClassStd IdOC (PK), IdStu(FK), IdLec(FK),

IdAY(FK), IdCourse, Class, RegTime, RegAppr, RegApprTime, ChangeTime, ChangeStatus, ChangeAppr, ChangeApprTime.

Grade IdG (PK), IdOC (FK), AssignGrade, MidExGrade, FinalExGrade, FinalGrade, FinalIdxGrade.

Tuition IdT(PK), IdStu(FK), IdAY(FK), Bill1, Pay1Time, Bill2, Pay2Time, Fine-1, Fine-2.

StdStatus IdStat(PK), IdAY(FK), Active, Bill1Stat, Bill2Stat, TotalBillStat

Prerequisite IdP(PK), IdCourse(FK), Ncredits, IdReqCourse(FK), MinGradeReq, IdParalelCourse(FK), Formula

GradStat IdGS(PK), IdStu(FK), IdAY(FK), CreditsEnrolled, CreditsPassed, AvgGradeSem, AvgGradeCum, CreditsBestEval1, AvgGradeBestEval1, CreditsBestEval2, AvgGradeBestEval2.

StdRegClass IdRC(PK), IdStu(FK), IdAY(FK), IdCourse(FK), EllibleStatus

StdRegChangeClass IdRC(PK), IdStu(FK), IdAY(FK), IdCourse(FK), RegisStatus, EllibleStatus

RegisTrans_NNN IdStu(FK), IdAY(FK), IdCourse(FK), RegisTime

Relation Main Attributes

ChangeRegisTrans_ NNN

IdStu(FK), IdAY(FK), IdCourse(FK), ChangeStatus, ChangeRegisTime

B. Prepocessing of Courses Eligibility Algorithm Design The offline computation algorithm for preparing the open classes and their eligibility statuses of each open- course for every student is given on Fig. 3. This algorithm is executed before the course registration period. (The algorithm for preparing the eligibility for change course registration is analogous to this, therefore it is not presented here.)

Algorithm: Preprocesing student eligibility of enrolling classes Description: Compute the student-enrolling eligibility status for

each open classes. Input relation: OpenClass, Grade, Course, Prerequisite, StdStatus, GradeStat Output relation: StdRegisClass Steps: (1) For each record in Student where StdStatus.Active = ’Y’ on

current semester (2) For each record in OpenClass open by the student’s

department, get the IdCourse (3) Set the default ellibity status to ’Y’ (4) Using IdCourse search the course prerequites in

Prerequisite (5) If there is credits pass, check its ellibility by reading

GradStat, upate the ellibility accordingly (6) If there is passed course, check its ellibility by reading

Grade, upate the ellibility accordingly (7) If there is paralel course do nothing //paralel enrolling

would be checked online (8) Write IdStudent, class attributes and the elligibility status

(’Y’ or ’N’) in StdRegisClass

Fig. 3 The off-line computation algorithm for preparing the classes eligibility statuses for each student

C. User Interface Design: Personalized and Self-explanatory Form

To support fast and easy transactions, each student would get a form that he/she could easily use by clicking the course. The form is also “personalized”, in the sense that each student would get courses and the eligibility statuses (to be enrolled) displayed in the form depending on their past grades or transcript. Hence, the form for one student may differ to the others. Different colors are used for presenting the eligibility of the courses for the student: green represents that it is eligible, while yellow is otherwise. The student would not be able to select the yellow ones (depending on the Department policy and specific consideration, then surrogate lecturer may enroll it for the student). See Fig. 4 for an example of the form (used to register courses in a short semester).

Fig. 4 An example of a student course registration form.

IV. RESULT AND EVALUATION Advantages. The user interface design (personalized form) has helped students and surrogate lecturers to conduct course registration easily and speedily. When the form was first launched in the second semester of 2008/2009, without reading manuals and training, students are able to register courses online. (The complaints received were about other problems, such as “unrecorded” registrations. After we traced the transaction logs, we found that the students did not complete the transaction).

To evaluate the transaction times, we measure the elapse time since the SQL command to store the transactions is received (by the DBMS) until it is completed. Table III depicts the data for the last 3 academic years. It is shown that the average transaction time is less than 1 sec (1000 msec).

TABLE IIIII THE COURSE REGISTRATION TRANSACTION ELAPSED TIME

Year Sem #Trans

Avg (msec)

MinT (msec)

MaxT (msec)

2008/ 2009

2 2378 40.3 2 1307

2008/ 2009

3 1247 14.4 1.2 306

2009/ 2010

1 2221 43.5 2.1 762.9

2009/ 2010

2 7367

46.6 1.7 802.4

2009/ 2010

3 1252 14.3 1.19 307.7

2010/ 2011

1 8534

54.5 1.3 973.1

2010/ 2011

2 8035

51.2 2.2 1102.3

Disadvantages. The method that we propose require the departments to strictly follow the procedures defined (open the courses before the offline courses eligibility computations is conducted). We experienced problems when in the middle of the course registration period, a few departments opened additional courses. Although it was then solved by

temporarily ‘shutdown’ the system during the computation of the courses eligibility, problems remained: Students already registered courses and approved by the surrogate lecturer were unable to add the newly open courses. It then had to be handled manually.

V. CONCLUSIONS In designing AIS course registration function with a centralized database that supports speedy transaction for hundreds of concurrent users, the three important components are physical database, algorithm for computing course eligibility offline, as well as personalized and self-explanatory user interface design. These designs have been implemented in SIA which has been operating for several semesters and supported the speedy transaction. Our designs have some drawback though, that the academic procedure must be strictly followed (courses must be opened before the registration period).

The method that we propose is suitable for SIA with centralized database. For future research, other methods are necessary to be developed, such as the ones suitable for distributed databases as universities might develop integrated information systems with several databases.

REFERENCES [1] V. S. Moertini, T. Yuliaty, W. Rumono, B. S. Tjhia, “The Academic

MIS Model Used in Higher Education to Resolve Typical Problems in Indonesia: A Case Study”, International Journal of Information Systems in the Service Sector (IJISSS), http://www.igi-global.com/ijisss, Accepted.

[2] M.A. Fuller, J.S. Valacich, J.F. George, Information Systems Project Management: A Process and Team Approach, Chap. 8. USA: Pearson Education, Prentice Hall, 2008.

[3] I.S. Suwardi, D.S.Permatasari, “New Integration Model of Information System on Higher Education Institution”, in Proc. of the Intl. Conf. on Electrical Engineering and Informatics, 2007, paper.

[4] Ministry of Education, Keputusan Menteri Pendidikan Nasional R.I. Nomor 232/U/2000 Tentang Pedoman Penyusunan Kurikulum Pendidikan TInggi dan Penilaian Hasil Belajar Mahasiswa, Jakarta: Republic of Indonesia, 2000.

[5] Universitas Katolik Parahyangan (Unpar), Petunjuk Kegiatan Akademis Tahun Akademik 2008/2009, Bandung: Unpar, 2008.

[6] T. Conolly, C. Begg, Database Systems A Practical Approach to Design, Implementation and Management, 3rd ed., USA: Addison Wesley Pub., 2002.

[7] J. Han & M. Kamber, Data Mining: Concepts and Techniques, 2nd ed. USA: Morgan Kauffman, 2006.

[8] K. C. Laudon, C. G. Traver, e-commerce: Business. Technology. Society. 6th ed, Chap. 6. USA: Pearson Education, Prentice Hall, 2010.

[9] J. A. Hoffer, M. B. Prescott, F. R. McFadden, Modern Database Management, 6th ed. Chap. 6. USA: Prentice Hall, 2007.