Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

Database for Student Registration SystemAt SIIT

Nakarin Netcharussaeng, Nichalin SuakkaphongSirindhorn International Institute of Technology

Thammasat UniversityPathum Thani l2l2l, Thailand

Apichat Tungthangthum, Pichet ChintrakulchaiAsian University of Science and Technology

Chonburi 20261. Thailand

Abstract

This paper presents the rectification of the student registration database systems ofSirindhorn International Institute of Technology (SIIT). The experience from using this registrationsystem shows that many amendments can be attained in order to benefit the users and the institute. Amajor anxiety at the first glance is about data protection. At present, the database used for studentregistration is the central database that the institute uses for many tasks such as student registration,student academic record, student profile, etc. Evidently, there is not much data protection control.Hence, if something adversely happened, the central database will be directly affected and maycollapse specially by those users who are not aware of the mistake when using computer-basedregistration. Unexpected problems might occur and may need a tremendous amount of work to rectifuproblems such as data inconsistency ofthe registration database.

l.Introduction that the data might be exposed to. The other

Sirindhorn Internationar Institute of case concerns updates which might change the

rechnorogv (srrr), rhammasat Universirv, uses l*lJ:"ff'y;""lll'"rl'irt:il:;:T ffi;:Microsoft Access version 2.0 as a databasemanagement program for its registration

the database against such threats specifically'

system. Due to the growth of the number of recovery' concuftency' security' and integrity

students, many registration works have been controls' Forthe stability of the database' using

successfully implemented and are well served one central database for registration is periloussince some situations may adversely happen,

from the use of the computerized database' such as a system crash. Since only one centralHowever flaws in the database have shown up database is used, the situation may reave thefrom time to time caused by the experience of database in an incorrect state in which recoverymany users' The flaws signal that data may not be possible. consequentry, one way toprotection measures should be improved to ensure a recoverable database is to be certainprotect the database against a variety ofpossible that every piece of information it contains canthreats (both deliberate and accidental)' For be reconstructed from some other informationexample, the system might crash in the middle stored in other praces-redundancy. The solutionof some unfinishedtransactions, thereby leaving we provide is that we create another databasethe central database in an unpredictable state. which is used only during the registrationconsider the case when two processes executing period. we will refeito this new database as theconcurrently interfere with one another, thereby registration database and the centrat databaseproducing incorrect results. Sensitive data might asthe main databasethroughout this paper.be exposed-or worse, changed by unauthorizedusers. The fact is there are indeed many risks

t 9

2. Problems2.1 Recovery

Before we go into the details of why weneed recovery controls, we would first like toclarif the meaning of recovery. In Date'swords [l], recovery is depicted as "Recovery indatabase system means, primarily, recoveringthe database itself-that is, restoring thedatabase to a state that is known to be correctafter some failure has rendered the current stateincorrect, or at least suspicious." There areseveral possible reasons for a transaction to failin the middle of the execution. For example,system crash (computer failure) may cause errorin the computer system during transactionexecution. Some transactions might violate theconcurrency control enforcement and thecontrol may decide to abort the transactionbecause it violates serializability or becauseseveral transactions are in a state of deadlock.Physical problems (media failure) may happensuch as head crash on the disk, fire or sabotage.For a system crash, the content in the buffermemory is a critical point. The state of anytransaction in a progress is not known; such atransaction did not successfully complete, andso must be undone (rolled back) when thesystem restarts. For example, while somestudents are updating the record a power failureoccurs. Hence. those unfinished transactionsmust be rolled back. For data protection whenmedia failure occurs, the backup copy ofregistration database is needed for restoration,there is no need for a roll back.

2.2 Concurrency

Registration database is a shared resource.We must expect and plan for the likelihood thatseveral users will attempt to access andmanipulate data at the same time. Withconcurrent processing involving updates, adatabase without concurency control will becompromised due to interference between users.Concurrency control allows many users toaccess and update the database simultaneouslywhile preventing partially completed updatesfrom happening. This technique is essential toour registration database, such as when more

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

than one student are registering the same coursewith a limited number of students in class.When the student decides to register on thecourse, the database integrity will check firstwhether or not the class is full by having onevariable used to store the number of studentswho have registered that course in the currentsemester. This situation can lead the databaseto the problem of lost updates. Assume that themaximum students in class to be 50 and thereare already 49 students registered. Student (A)wants to register the course so he checks tomake sure that the course is not yet full and 49is the number that appears to him. But beforehe can update the number to be 50, anotherstudent (B) also wants to register for this coursetoo. So B does the same operation as A; checksthe number of students and, if possible, thenupdates it. At this moment, before A updatesthe record, 49 is also read by B which indicatesthat he can register for this course since it is notfull yet. Hence the update by A is lost. Aninvalid result is obtained since after these twostudents register the course, the actual numberof students is 51, not 50 as it appears indatabase. It is not only lost update problems thatconcurrency control mechanism has to address,uncommitted dependency and inconsistentanalysis problems are also possible. Theseproblems aan cause the database to be ininconsistency state.

2.3 Security

After a workable application for theregistration database had been made, it is timeto concentrate on how to manage who can usewhich features and establish applicationsecurity. Security concerns ensuring that userscan do only what they are allowed to do. In theSIIT central database, all information concernedwith every student is kept in it. If no securitysystem is implemented into the system,tremendous problems will arise since a studentmight alter his academic record by changing hisgrades, his colleagues grades, or putting in acourse and grade in which he did not actuallyregister. Hence a security system is needed formaintaining a usable database for studentregistration.

20

security. Some constraints must be enforced toensure that authorized users are doing correctoperations, satisfing all constraints. Forexample, the institute enforces the constraintthat each student must register at least 9 creditsand must not exceed 22 credits per semester, orthat a student cannot register some courses asregrade if he has gotten a better than D+ gradefor that course. Another example is that somecourses have prerequisite courses in whichstudents must pass their prerequisite before hecan register the courses, etc.

3. Solutions to the Problems

By using a central database for studentregistration, many problems are likely to occurdue to unaware or deliberate action. All theerrors will be adversely directed to the centraldatabase. With the great importance that thecentral database is used for most instituteadministration work, a small database isimplemented in order to be used as a substituteduring the registration period. So any adverseaffect will only be confined to the registrationdatabase. Consequently, advantages concemingsecurity are also provided. Moreover, byseparating the registration database out, theinstitute can modifu or change the structure ofthe database easily, without too much concernabout its side effect on the central database.The registration database can be generatedeasily from the central database by transferringonly the necessary information for registration.Some information is transformed into moreappropriate form such as grades. Grades will betransformed into the form of regradable andcanreregis, as shown in Figure 1 and2. Hence,as shown in Figure 3, there will no longer beactual grades of each student in the registrationdatabase, but only flags to indicate whether hecan regrade or reregister or not. Anyunauthorized users who try to change the gradeswill fail since no grade is kept in the registrationdatabase. It is also more convenient for ourregistration database since the transformedgrade is more relevant to the objective of theregistration's query than the actual grade. Theinitializing procedure of registration database issimply depicted in Figure 4. From Figure 4, thetable "TREGISTER" and the table "TregisterW

Regradable" are doing an unmatch query to find

Thammasat Int. J. Sc. Tech.. Vol.3. No.2. Januarv 1999'

any student that might register later, after theregistration period. The result is appended backto table "TregisterW Regradable" which is thenexported to the registration database. All of theadbove processes are done by the registrar.Thetable "TregisterW Regradable" is used as anintermediate between the central and theregistration database. In addition, the gradeinformation in the table "TREGISTER" istransformed into regradable and canreregis,and appended to the table "TregisterW

Regradable". All of the student academicinformation in the previous semester is stored inthis table and will be used as reference only.During student registration, new records areadded in table "TableX" and this table will beexported back to the central database afterregistration period. There is no need to transferthe table "TregisterW Regradable" back to thecentral database since no change was made tothis table during registration period.

3.1 Solution for Recovery

Since we are using separate databases anyfailure that might cause the database to corruptis now limited only to the registration database,leaving the central database untouched. For thecase that registration database is collapsed, itcan easily be reconstructed within threeminutes, since it contains only information forregistration, it is then ready to be used again toprovide uninterrupted service during theregistration period. Furthermore, for anyterminated transaction. the transaction manageris used to provide the atomicity of importanttransactions. In other words, it guarantees thatif the transaction executes some updates and afailure occurs (whatever the cause) before thetransaction finishes (reach its plan), then thoseupdates will be undone. Thus, the transactioneither executes in its entirety or is totallycanceled. In this way a sequence of operationsthat is fundamentally non-atomic can be viewedas if it were atomic from this point of view. Thecommit transaction and rollback transaction arethe key to the way recovery works. For committransaction, it tells the Database ManagementSystem (DBMS) that the atomicity of theprocess has been thoroughly finished. Thedatabase is in a consistent state and the updatesmade by the process can now be made

2 l

that is fundamentally non-atomic can be viewedas if it were atomic from this point of view.The commit transqction and rollbacktransaction are the key to the way recoveryworks. For commit transaction. it tells theDatabase Management System (DBMS) that theatomicity of the process has been thoroughlyfinished. The database is in a consistent stateand the updates made by the process can now bemade permanent or committed. In contrast, thesignal of failure to end the transaction isindicated by the rollback transaction. Thedatabase might be in an inconsistent state andthe updates by that transaction must be undoneor rollback. A log will be maintained by thesystem about the details of all updateoperations. So, if it is necessary to undo anyspecific update, a log file will be used to updatevalue to its previous value. For SIIT, thetechnique of commit and rollback transaction isimplemented in Microsoft Visual Basic forAccess by using the reserved words BeginTrans,CommitTrans. and Rollback. These threefunctions are used for important transactionsthat might be able to compromise theconsistency of the database. For example, byusing these functions, when students decide toregister, the program adds the students to theinstitute record and updates the number ofstudents in class with a fallback recoveryagainst any failure. A clearer idea of theimportance of recovery might be depicted whenthe transaction is concerned with payment. Forexample, total tuition fee that student A mustpay is 40,000 Baht which he will pay in twoinstallments of 20.000 Baht each. While he isin the middle of the payment process, at time t1the transaction is terminated for some reasonjust after 20,000 Baht is deducted from hisbalance. Assume that the transaction did notcomplete yet since it needs to update the totalamount that he had paid, update that he pays bycash or check, and update the date that he hadpaid. As a result to the database, the transactiondid not complete and must be redo. The amountthat he still owes the institute now turns to be20,000 Baht instead of40,000 Baht. So he needsto prooess his payment again, and finds that heonly had to pay 20,000 Baht once instead of atotal of 40,000 Baht (the first 20,000 Bahtinstallment was not paid to the cashier yet, only

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

processed by the computer that he was going topay 20,000 Baht). If an atomicity is used for thepayment transaction, whenever a termination isforced on the transaction the whole transactionmust be undo- instead of redo only theincomplete transaction. Therefore this kind ofpayment transaction should be made asatomicity in order to avoid the inconsistency ofthe database

3.2 Solution for Concurrency

As mentioned before, without concurrencycontrol the problems of lost updates,uncommitted dependency, and inconsistentanalysis are expected to occur. Since theregistration database is a shared and classifiedresource, careful database management must beincorporated. Microsoft Access, provides threelevels of locking. These are record locking,table and recordset locking, and opening withexclusive access. For record locking, only therecord currently being edited is locked. Fortable and recordset locking, an entire table or alltables underlying a form are locked while anyuser is editing any record in the form. Finally,for opening with exclusive access, the entiredatabase is locked by a single user-change intosingle-user environment. Microsoft Accessautomatically locks the record currently beingedited even though the programmer did notpredefine the lock mechanism. In registrationdatabase, since we always operate under multi-user environment, the opening with exclusiveaccess is irrelevant and will not be mentionedtwice. The most used mechanism in ourregistration database is table and recordsetlocking. Since this database is a relationaldatabase and has a quite complicated relationand query, recordset will be used for most of thetime. As mentioned before about concurrency,the inconsistency about counting the number ofstudents in class can be solved by using tableand recordset locking which will be referencedas lock. As the students decide to register anycourse, the lock is made active so that countingthe number of students in each class is correct.The reason why the original system locks theentire table is that it uses one table to store allrecords of who had registered for whichcourses. Consequently, the counting method

also uses this table to count the number ofstudents for each class. ln other words, fromFigure 2, the central database uses the table"TREGISTER" to store and count the numberof students in each course by using student IDand section ID as criteria for counting thenumber ofstudents registered in each course. Inour new system, the registration database storesrecords in table "TRegiterW Regradable" whichis then used to count the number of students ineach course. DCount is used in Visual Basiccode. Hence, if these tables are locked whileany student is currently updating then, the lostupdates problem can be solved.

3.3 Solution for Security

In the past, the original system used tableTUSERS to store login name and password forthe registrar. As the registrar log on to thedatabase, the application only verifies loginname and password using ordinary Visual Basiccode to check the information in TUSERS.DlookUp is used to check the data in the table.Hence, if anyone is able to look into this table,he can find the login names and passwordseasily. If the registration database is notencrypted, anyone with a disk editor can viewthe contents of the file. Although the datawithin the file will not appear in an easy-to-readformat, the data is there and available forunauthorized individuals to see. Therefore, theencryption is used for the registration databaseeven though the performance of the applicationwill drop but it is necessary to keep itencrypted. In other words, another level ofsecurity is made from encrypting the database.Typically, the DBMS supports either or both oftwo broad approaches to data security. Theapproaches are known as discretionary andmandatory control. In the case of discretionarycontrol, a given user will get different authorityor privilege. Discretionary schemes are veryflexible. In contrast to discretionary, mandatorycontrol defines each data object to be labeledwith a certain classification level, and each useris given a specific level of clearance. A givendata object can then be accessed only by userswith the appropriate clearance. Consequently,mandatory control is rigid but appropriate to usewith a registration database. It is easier and

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

clearer to maintain a class of users than toconcentrate on individual users, since everystudent must have the same right. Login nameand password table will not be used, TUSERand new approach should be used here.Microsoft Access provides a very powerful andcomprehensive feature to maintain user account.The information on each clearance level ofuserand password, and access right for each objectwill be stored in the file SYSTEM.MDA. Thisfile is distinct from the database file whichMicrosoft Access uses to store informationdatabase security. The privileges of each levelwill be discussed in the next section.

3.4 Solution for Integrity

As mentioned before, integrity concernsprotection against authorized users. Forstudents they must be assigned the rights to readall that data and update only the tableTREGISTER since this table is used to storewho is registering which courses. Studentsmust not be able to view database application asin the design view to avoid any adversealteration by them. The other thing of concernis that students should not be allowed to use thetoolbar since it provides features beyond thenecessity of student registration. For theregistrar class of users, it depends on the policyof the institute to what the registrar is allowed todo as does the faculty class of users. The otherpolicies such as how many credits students mustenroll in each semester, the maximum numberof credits a student can register each semester,prerequisite, corequisite, etc, are deliberatelyignored from user privileges levels since itvaries from organization to organization.

4. Conclusion

So far, all fundamental problems have beencleared up. Security and stability of theregistration database have been solved.However, a lot of delicate improvements can beimplemented because the further use of thisregistration database in the future will tell whatis appropriate and what should be improved.User-interface is another area for improvementsince it can reduce the error that users mightmake but requires further work to produce an

23

appropriate and elegant design that suits theusers needs.

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

5. Reference

[l]Date, C. J. (1995), An Introduction roDatabase Systems, Addison-WesleyPublishing Company, Inc.

Figure l. Relationship of the Central Database

24

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

No No No NoNo No No NoNO NO NO NO

No No No NoNO No No NoNo Yes No NoNo Yes No No

No No Yes YesNO NO YCS Yes

NO NO NO NO

No NO No NO

No No No NoNO No Yes Yes

Figure 2. Grades Transformation Table

Figure 3. Relationship of the Registration Database

25

Thammasat Int. J. Sc. Tech., Vol.4, No.l, January 1999

figure 4. Pictograph ofthe Initialization ofRegistration database

26