SEMI-AUTONOMOUS HOMOGENEOUS WEB-BASED DISTRIBUTED …

e-ISSN: 2582-5208 International Research Journal of Modernization in Engineering Technology and Science

( Peer-Reviewed, Open Access, Fully Refereed International Journal )

Volume:03/Issue:09/September-2021 Impact Factor- 6.752 www.irjmets.com

www.irjmets.com @International Research Journal of Modernization in Engineering, Technology and Science

[1145]

SEMI-AUTONOMOUS HOMOGENEOUS WEB-BASED DISTRIBUTED

DATABASE SYSTEM FOR STUDENTS ACADEMIC RECORDS MANAGEMENT

(A CASE STUDY OF ADEKUNLE AJASIN UNIVERSITY, AKUNGBA-AKOKO)

Matthew O. Afolabi*1, Ojeyinka T.O*2

*1,2Department of Physics & Electronics and Department of Computer Science, Adekunle Ajasin

University, Akungba-Akoko, Ondo State, Nigeria

Corresponding Author- [email protected]

ABSTRACT

The primary objective of this project is to provide efficient integrated student academic record management

system (SARMS) for use in a Nigerian tertiary institution. The system’s framework describes the design and

development of a centrally managed database that is distributed across different units for end users. The

database is domiciled within the centrally accessible server as the backend on an integrated platform.

Operations on data such as querying, inserting, deleting, updating, appending and processing are carried out

locally at the distribution units. The central database hosts the actual data as a single physical copy while

logical copies of each data are available at the distribution outlets where data handling operations are carried

out.

Keywords: Database design, Academic, Systems Results processing.

I. INTRODUCTION

As of now, the problem of result processing is unique to each University. Different universities use various

patterns of grading systems. Differences exist in the number of courses available, the values of course units, the

types of course codes, the number and type of course prerequisites, variations in the systems of managing

continuous assessments and disparity in the styles of preparation of reports used by different institutions.

Every university has its unique style of preparation and presentation of processed students’ reports. As such, it

is practically difficult and awkward to port result processing system program in use by one University to

another. Every university requires a customized processing system in order to maximize processing time,

reduce computational errors, and achieve higher efficiency.

SARMS is an integrated academic record processing and management system which combines online course

registration, course management system and result processing systems platforms into a single one. It defines a

web-based (cloud-based), centrally-managed database management system in which data and record

management operations and results processing are distributed along several outlets. Each outlet consists of a

data processing computer with local copies of students records and is managed by each academic department

of the university. The central database has higher hierarchy (level) over each local processing units but the

local units operate at the same level. Each local database is connected to the central database for access

privileges and monitoring of all operations at the processing outlets. Students register for courses through the

internet into the central database but records processing are distributed across academic departments of the

institutions. The design of the integration of different modules of the SARMS allows simultaneous accesses by

multiple users starting from the students to the lecturers and even up to some members of the university

management staff. Adequate security of information from hackers is implemented with security features on the

cloud server end. The central server which houses the central database as well as all the processing outlets can

be located within the ICT building to avoid the cost of long distance network. Each processing outlet is managed

by an academic department through a data processing officer (DPO who is responsible for carrying out data

processing jobs in a department.

The system is research-based and adopts innovations and modern technologies to solve the problems involved

in real automatic processing and management of student academic records. The design and implementation of

SARMS preserves the culture of academic advising and counselling adopted by the Adekunle Ajasin University,

http://www.irjmets.com/

mailto:[email protected]





[1146]

Akungba-Akoko, and many other universities. It is flexible, customizable, multi-user (by all parties), interactive,

fully automatic and efficient. The development of this unified computerized system will save universities the

embarrassments on complaints from students and parents as a result of problems discovered in any one or

multiple portions of the currently detached result processing system. These complaints vary but include

inefficiencies, inaccuracies, time consumption, costs and inconveniencies. Using SARMS is less demanding.

Level coordinators will find it more convenient and comfortable to use.

The trends towards SMS started in the early 1990’s, when many schools started receiving donation from

western countries (Mingaine L., 2013). And on realizing that many companies had automated their tasks to

ease management, schools started to imitate these systems. For some schools they developed their systems

through the teachers while others got solutions from local vendors who developed specific tools for schools. In

most cases, many of these systems lacked support after completion. Some were made from early days MS

Access. Access to store or retrieve information became bottleneck as the records got larger. The consequence of

this is loss of data, inability to use the systems until they became obsolete.

1.2 Problem Statement The developers of student information management system at Adekunle Ajasin University has done a very good

job by providing databases, software and procedures for acquiring, storage and processing of students

academic records. However, the whole system runs on different platforms and portals (e.g. AAUA e-PORTAL,

AVERS, AAUA MOBILE, and AAUA e-CLEARANCE), with each one independent of another. There is no

streamlined, or standardized process for capturing, processing and storing student’s information which means

that the records are not centralized. This has given rise to disintegrated student information systems, the

consequence of which leads to errors and discrepancies in the output results. Lots of time and resources are

lost during results processing which allows inconsistencies and data redundancies within the entire system.

This work is sequel to an earlier work by [Afolabi & Ojeyinka]. The paper addressed and provided efficient

design and implementation of a database management system for students results processing. It focused on

elimination of common salient and minor errors associated to results processing and made contributions on

how to improve correctness, convenience, efficiency and scalability of students records processing especially as

the system gets expanded.

However, the major motivation in this study is that all the student information management subsystems could

be designed and implemented (not integrated) as one unified entity thereby reducing to a large extent the

occurrences of errors, time wastages, losses of information.

The aim of this study is to design and develop a unified single system, single database, single platform, single

portal, fully contained, efficient, interactive and easily accessible result processing system for managing student

academic records in tertiary institutions. The system features a central database where system administration,

central storage, monitoring and control can be implemented, and a number of distributed local records

processing units where updates, local storage, and processing of students results are carried out by each

academic department within the institution. The system is expected to achieve the following goals. Among the

objectives of this study is to 1) develop a central database that holds the physical data of students records, 2) to

develop local data processing units which are distributed across academic departments with links to the

physical data in the central database. 3) to design and implement central control and administration of student

records at the central server side where access rights and privileges are assigned with adequate security at

every level, 4) to process students results, student academic status and other local operations on records at

local units managed by academic departments, and to develop a unified portal for all operations on student

academic records according to the rights and privileges assigned to every user of the system within the

university.

II. METHODOLOGY

The proposed study encompasses the design of a framework and the development of an implementation

prototype for a distributed database management system whose control and administration is centralised at






[1147]

the highest hierarchy but allows for records processing and other data processing operations at each of the

distributed outlets of the system.

The project commences with information gathering. Here, samples of existing and new reports of students

records are collected and studied to understand how the various components could be designed within the

context of the project framework. A design structure is implemented using context-flow and data-flow

diagrams for the operational workflow of each object and its activities within the system, and to determine

what operations or reports should be available at every stage of the system operation.

Databases

Two common design concepts in database are 1) Centralised DBMS and 2) Distributed DBMS. In Centralised

DBMS data are stored at a central location (e.g. a database server) where data processing takes place. Other

computer now known as database clients (or terminals) simply sends/receives data from the server for

input/output. A distributed database (DDB) on the other hand has data located in more than one locations

where processing of data can be carried out. In a DDB, the reality is that different databases exist at multiple

nodes on the network and are managed by similar database management software (DBMS), but they appear to

the user as a single database.

Fig. 1: Centralised Database at Site 2

Fig. 2: Distributed Database at different sites

Security and administration issues are better handled in centralised DB [Kumar, C. et. al. (2014)]. CDB design

have the advantages to prevent theft and fraud, preserve confidentiality, integrity and privacy with fast

database availability. A CDB may suffer security breaches and disruption of operations on the records during

periods of downtimes and failures. However, having the data in many places versus one place means different

choices in terms of solution architecture and programming. Parallel processing of data on records can be

achieved in distributed database but not in centralised one. Although the system may experience some amount

of latency when data are retrieved from multiple servers but this amount of time depends on the configuration

and design of the database solution.






[1148]

Fig. 3: Users view of Distributed Database

Fig. 4: Programmers view of Distributed Database

A DDM allows distributed data storage which can be designed to expand in sizes as the amount of data

increases. Every organisation or designer of database often decides on any one of the two models to adopt. It is

not uncommon to see multiple systems, servers, or nodes configured to handle a given database application

instead of a single more robust system. However, both research and implementation approaches for a unified

centralised-distributed database design solution have not been well researched. For this reason, the benefits of

such combination are yet to be realised and utilised. The work of Wolfgang Hoschek on Template Query

Execution Plan [Wolfgang H. (2002)] applies a search space for a query to include the search results solution

from both the local database and the neighbour databases if there is any. This however is used in a pure

distributed database design alone - not a combined centralised and distributed database architecture.

SARMS Database Environment

The architecture of SARMS follows a Semi-autonomous homogeneous distributed database management

(SAHDDBMS). Data are physically distributed across different sites (departments, admission office, Students

affairs unit, Faculties, etc.). the nature of distributed data is homogeneous in that all the sites use the same

operation system and DBMS software. Each site is autonomous to the extent of performing local transactions

and query operations on local data but rely on the central server for initial access and final updates on data.






[1149]

SARMS architecture is peer-to-peer. Each site is semi-autonomous and supports data management, transaction

management and query processing. Each site represents a peer and can serves both as a client and as a server.

Distributed DBMS Architectures

DDBMS architectures are generally developed depending on three parameters −

• Distribution − It states the physical distribution of data across the different sites.

• Autonomy − It indicates the distribution of control of the database system and the degree to which each

constituent DBMS can operate independently.

• Heterogeneity − It refers to the uniformity or dissimilarity of the data models, system components and

databases.

Architectural Models

Some of the common architectural models are −

• Client - Server Architecture for DDBMS

• Peer - to - Peer Architecture for DDBMS

• Multi - DBMS Architecture

Client - Server Architecture for DDBMS

This is a two-level architecture where the functionality is divided into servers and clients. The server functions

primarily encompass data management, query processing, optimization and transaction management. Client

functions include mainly user interface. However, they have some functions like consistency checking and

transaction management.

The two different client - server architecture are −

• Single Server Multiple Client

• Multiple Server Multiple Client (shown in the following diagram)

2.1 RELATED WORKS

2.1.1 Technical Aspects of Integrated Management Information system for Educational Institutions

(Pougatchevet and Kulkarni, 2011) practically implemented the e-Management Control and Evaluation System

(e-MCES) in the University of Technology, Jamaica (UTech). The intention of the e-MCES is to provide a robust

yet flexible online tool for the University to measure how well it is able to achieve its strategic targets, while

providing a mechanism for communicating with each staff member their individual contribution to the success

of the institution. The system provides an accurate diagnosis of the educational reality and an objective

assessment of the impact of intervention policies to society. On the other hand, the information produced by

the system may be used as social control tool to press those responsible for managing the educational system to

produce necessary improvements. This study is very much related to the present study as both has the






[1150]

intention to improve the educational structure of a country for development of educational institution’s

strategy and policy, timely and precise analysis of information is essential.

In (Wokochaand Adebayo, 2012), the paper focused on developing a set of guidelines, which can be followed

for preparing the sites for the various server and computer rooms which will be setup in tertiary institutions in

Nigeria. These guidelines provide a generic framework for various aspects of Information Technology (IT) site

preparation, specifically for setting up server rooms in a local area network enable environment. The authors

aimed to establish a Management Information System in tertiary institutions, so that information can be

extracted from the operations systems to provide a stimulus for decision-making by the management. This

study is akin to the present study in a sense that it is also intended to provide ways to an education-related

institution for a more reliable and timely decision-making activities.

2.1.2 A Web student information system to automate record generation in institutions: A New

Approach and Implementation.

Maharishi (2013) provides a simple interface for maintenance of student information. It can be used by any

educational institute or colleges to maintain records of students easily. Achieving this objective is difficult using

a manual system as the information is scattered, can be redundant and collecting relevant information can be

very time consuming. All these problems are solved using this project. Throughout the project the focus has

been on presenting information in an easy and intelligible manner. The project is very useful for those who

want to know about Student Information Management Systems and want to develop software/websites based

on the same concept. The project provides facilities like online registration and profile creation of student thus

reducing paper work and automating the records generation process in an educational institution.

2.1.3 Alternative novel system for students

Ahmad et al (2010) Suggested to design a novel system for students, where alternative and essential solutions

was given to solve various problems. Presented the design of the database for student information system, the

computerization of the system means to change from manual to a computer-based system, to automate the

work and provide precision, efficiency, timelessness, economy and security. This resulted after undertaking a

detailed check of the Ayub Medical College's current manual student information system and analyzing its

deficiencies, found it is necessary to remove its shortcomings and provide an appropriate solution to the

problems encountered at the present time. A comprehensive database (AMCSIS) for the students was

introduced. The suggested algorithm can help the management to make a timely and effective decision. This

system is able to store vast data of the student and generate the report according to the necessity. As well, this

system enables to manage the information that carries the feature of easy to use and effective data control. The

approach of this system enables the user to get access to data in a flexible way through a graphical user

interface an easy to use.

This work used SSADMs with which the theoretical basis of the research was formulated.

III. MODEL DEVELOPMENT

A data model will be is developed to provide the structure and details of information to be stored and how the

information will be is used within the system. The data model includes conceptual data model which consists of

schema describing the entities and their relationships about the associations that exits between the entities. for

descriptions of tables and columns, object oriented classes, and XML tags which will be is used to capture the

details of the system of interest, logical data model for, and the physical data model to specify the physical

means by which the data is stored. An object relational model approach is adopted to develop the databases to

provide the convenience of the conventional entity relational model with the object model which can be used

with object-oriented programming languages. The benefits of this combination range from scalability to

support for rich data types.

The various activities proposed for the study are itemised below:

Application Description and preparation






[1151]

MODEL

These proposed architectural models for this work consist of 4 major actors (Super Administrator, School

Administrator, Staff and Students). The Staff role is breakdown into;

i. Faculty Officer, Lecturers, Bursar, Department Officer.

Each of them has a limitation to what they can do on the system except the Super Administrator who has

an overall control over every user.

The architecture is 2-tier based, which includes the 1) Centrally-managed Database, 2) the Distributed

processing units each with logical copies of central data, and 3) the interconnection networks that provides

links to the two levels of operations.

Level 2 - Centrally-managed Database: this level is higher in hierarchy of operations over level 1. It features a

centralized database architecture where physical data of students records reside. The data are kept in a central

server system. Both the management and access privileges to data within the CMD resides with the System

Administrator. The values of each data remains unchanged unless it is updated by its copy in any of the

distributed processing units (DPUs). Here, the database is highly normalized and runs queries related to the

functions of the Administrator. The database can be accesed for queries but restricts operations such as

insertion, deletion, update etc. as part of the system security. Data in the CMD are secured and available for use

in case there is a physical damage to the copies in any of the DPUs. A

Leve1 1: Distributed Processing Unit (DPU): A DPU consists of database system similar to that of the CMD.

Logical copies of data reside within the DPU and can be queried or processed on based on the processing

requests. Operations such as insertion, deletion, update are carried out through the DPU. Changes in the value

of data are updated in the CMD to maintain data consistency. Both the CMD and DPU contain the same

database. There are no duplicate data or data redundancies within the entire systems since data in the DPU are

logical copies of the data in the CMD. Each data processing unit within the institution is installed with a DPU

and connected to the CMD which is hosted by the ICT unit or the appropriate data centre. Level coordinators,

examination officers and course lecturers are linked remotely through wireless networks to the DPU system

hosted by the department. The results verification committees can download system-secured pdf documents of

updated results for onward verification at the departmental academic board meetings.

Layered Network (LN): The LN uses two layered networks layer 1 (LN1) and layer 2 (LN2) to link the DPU

database to the database in the CMD respectively. It snoops for changes in values of data in the DPU and

updates the replica in the CMD appropriately.






[1152]

Here, we created the physical database and the logical structures. The physical database designed in the first

phase was implemented in which database schema objects like table, indexes, views, etc. are created.

Fig 5: Proposed Architectural Model for the system

Fig. 6: The implementation of the project features the following integrated subsystems/modules which will be

accessible to all users through a single portal interface:

IV. SYSTEM DESIGN

Applications and Users layer: application layer mainly consists of content creation, content delivery,

education platform and education management and their interaction with users. Here we have divided the

Application layer into various managements to be used within the system.

The system consists of four major categories of users, namely: Administrator, Level Coordinators, Course

Lecturers, and Students.

1-Administrator: The Administrator is the general overseer of the system. His functions include;

Upload of Students Information: The students information consists of the Students Name, Matric number, Level,

Department and Gender.

Upload Staff/Lecturer Information: The staffs information needed include; Staff ID, Full name, Department and

Course(s) taken by the lecturer.

Register Courses Offered by each Department: The administrator can register all courses offered by each

department.






[1153]

Assign Course(s) to Registered Staff: The administrator will be able to assign course(s) to lecturers in a

particular department. Assign Level Coordinator to each departmental level: The administrator will be able to

assign level coordinator to each departmental level.

2. Course Lecturer: The course lecturer is one of the major users on the system. The task they perform include;

Upload Results for course(s) taken., View Results Uploaded.

3. Student: The student is the primary end user with the least privilege. The feature the student can access is;

Check own Results

4. Level Coordinator: The level coordinator is another user with more privilege. The task he can perform

include;

Process Results for Departmental level attached to, Upload Result for course(s) taken, Access all Students

Result in assigned level.

Fig. 7-: The proposed system architecture.

CGPA formula

GPA = ∑(𝑐𝑜𝑢𝑟𝑠𝑒 𝐺𝑃∗𝑐𝑜𝑢𝑟𝑠𝑒 𝑐𝑟𝑒𝑑𝑖𝑡𝑠)

∑ 𝑖𝑡𝐺𝑟𝑎𝑑𝑎𝑏𝑙𝑒 𝑐𝑟𝑒𝑑𝑠, GP= Grades Points / credits= credits [Afolabi & Ojeyinka].

Database Design

SARMS is designed as a hybrid centralized and distributed information management system. The system is able

to capture, validate, store, sort, classify, calculate, compute, summarize, retrieve, reproduce and communicate

operational data for student academic records within the university.

The database tables, using MySQL, were normalized for accuracy and ease of retrieval [Afolabi & Ojeyinka].

This research used SSADMs with which the theoretical basis of the research was formulated. The required data

including school information (department, courses, student personal details, semester details, lecturer details

etc.) were collected. The data collected was used to identify attributes, relationships, classes, entities (objects)

that describe, relate and interact with the system.

The front-end interface was designed using HTML5, CSS3 and JavaScript, while the backend functionalities are

powered by PHP server-side scripting language and MySQLi a relational database management system driver)

in designing the database which runs on a web server.






[1154]

Fig. 8: The Database – All Table

Fig. 9: Course Table

Fig. 10: Course Registration Table

Fig 11: All Tables in the Database






[1155]

Fig 12: All Tables in the Database

V. SYSTEM IMPLEMENTATION

We built and implemented the system on a web platform using PHP embedded in HTML and linked to MySQL

database with a PhpMyAdmin that can run on both WAMP and LAMP. PHP was preferred because of the ease of

use on diverse platforms with minimal change to the script; and for its compilation speed and efficiency. The

system includes “import” and “export” features to reduce the bulk of time taken to transfer large volumes of

data such as students’ registration data.

The system model indicates the activities performed on the system, which are

1. Course Registration: The Students register for courses.

2. Result Checking: The Students Check their Results for the Courses they took each Semester.

3. Result Uploading: The Lecturer upload Results for the Courses they take each Semester.

4. Operations: The administrator of the system performs the operation, such as; managing all students, staffs,

courses, and results.

The web-based centrally management distributed student’s management system why being implemented was

test run in all major web browsers such as Google Chrome and Mozilla Firefox browser. The implementation

modules have successfully improved an aspect of the student record management from being manual activities

to digitized ones on a dynamic page. Some of the modules in the portal that are shown in Figure 4.2 is the

Course Registration. Meanwhile, there are several other modules in the system. The system which was tested

using the Mozilla Firefox as the default browser was further tested on the Internet Explorer browser. This is to

estimate the ease with which the portal can be moved from one system or environment to another.

VI. IMPLEMENTATION RESULTS

The centrally managed distributed student management system is made up of web pages that interacts with the

users directly and responds accordingly.

Student Login Page: This section is where a student can login to his/her account on the platform. The student is

required to enter his/her username and password.

Admin Dashboard Page: This is the administrator dashboard page where he can view site statistics.

Fig. 6.1 Admin Dashboard






[1156]

Admin Add Staff Page: This is the section where the super administrator can add a staff, create a password for

them and also set their roles.

Fig. 6.2 Admin – Add Staff

Admin Upload Students Page: This is the page where admin will upload students in bulk. The uploaded file

should be in CSV excel file type

Fig. 6.3 Admin - Add Student

Admin Manage Students Page: In this section, an admin can manage all students (view, search, edit, delete

etc.).

Admin Add Lecturer Page: This is the page where admin will upload lecturers in bulk. The uploaded file

should be in CSV.

Figure 6.4: Administrator – Add Lecturer

Manage Lecturers Page: This is the page where admin will be able to manage all lecturers.

Fig. 6.5 Administrators – Manage Lecturers






[1157]

Admin Add Course Page: This is the page where admin will add courses. Courses can be added singly in this

page. Admin Upload Courses: this is the page where admin will be able to upload courses in bulk. The

uploaded file should be in CSV excel type

Fig. 6.6: Administrators – Upload Courses in Bulk

Admin Manages Courses: this is the page where admin will be able to manage courses.

Fig. 6.7: Administrators – Manage Courses will be able to manage faculties.

Admin Add Department: This is the section where an admin can add a department to a faculty in the

institution.

Fig. 6.8 Administrator –Add New Department

Admin Manages Departments: this is the page where admin will be able to manage all departments.

Fig. 6.9: Administrators – Manage Departments






[1158]

Level Coordinator View All Result: This is the page where level coordinators can view all spread results

based on the Academic Section selected.

Student Login: This is the section where student Login into their Account.

Fig 6.10: Student Login

Fig 6.11 : Student Dashboard after successful Login

Student Result: This is the Page students where student check their.

Student Check Result: This is the page where student see their results for each semester and session.

Fig 6.12: Display Student result

Student Check Outstanding Courses: This is the page where student see their outstanding courses for each

semester and academic session.

Fig 6.13: Display Student Outstanding courses






[1159]

Student Check GPA Summary:

This is the page where student see their Grade Point Average Summary for each semester and academic

session.

Fig 6.14: Display Student GPA Summary

Lecturer Login: This is the page where Course Lecturers Login to their Account.

Fig 6.15: Lecturer Login Page

Lecturer Dashboard: This is the page where Lecturer perform operations such as manage results, upload

result on their Account.

Fig 6.16 Lecturer Dashboard Page

Lecturer Dashboard: This is the page where Lecturer perform operations such as manage results, upload

result on their Account.






[1160]

Fig 6.17: Lecturer Result Upload Page

Lecturer Manage Result: This is the page where Lecturer see results, he uploads.

Fig 6.18: Lecturer Manage Result Page

Level Coordinator Manage Result: This is the page where level coordinators see results, he uploaded for all

students in his/her level and department assigned to.

Fig 6.19: Level coordinator Manage All Result Page

VII. CONCLUSION

An institution of learning like AAUA that processes and manages student’s information for immediate and

future use must strategize a means of alleviate the spreading of the information over numbers of disjoint

system, which causes data inconsistence by allowing students to make registration once while also checking

their results without the need to reenter same information (redundancy). This project covers the process of

developing a single unified system to replace the current disintegrated students results processing subsystems

currently in use at Adekunle Ajasing University, Akungba-Akoko. It helps reduce the friction involved in

managing student’s information which are, of course homogenous in nature.

The system provides an efficient means of processing, preserving and displaying students’ results, academic

records and other relevant notices to students. As part of its benefits, it is stress-free and speed-up the






[1161]

processing of students’ examination results. The system is flexible and runs on a web browser. It is reasonably

secure, it enforces data integrity from the use of a relational database management system; it minimizes data

redundancy and it is user-friendly. With this application, the processing of students’ results is automated,

thereby reducing processing time and increasing accuracy.

This project work was developed taking AAUA as a case study with intent of educating the society at large and

also to create a single platform that could be deployed in the institutions of higher learning for managing

student’s registration and results processing. Nevertheless, the researcher recommends the adoption of

procedures and techniques used in this work by institutions of learning in Nigeria.

Further work can be carried out to improve the system. For instance, the registration data and results

information of the students can be used to provide insights to the students performance in specific courses or

on the entire study undertaken by the students. Using this, the system can predict future performances of

students based on their previous academic information.

VIII. REFERENCES [1] Adekiigbe, A., & B.M.G, A. (2009). Journal of Computer Science and its Application, Vol. 16, No 2 Pp.45.

[2] Ahmad, Khan, Abd Alla& Beg, 2010, “Alternative Novel System Model for Students”.

[3] Ajith S.N and Hemalatha M, “Cloud Computing for Academic Environment,” International Journal

ofInformation and Communication Technology Research, Vol. 2, No. 2, pp.97-101, 2012.

[4] Ajith S.N and Hemalatha M, “Web Computing for Academic Environment,” International Journal

ofInformation and Communication Technology Research, Vol. 2, No. 2, pp.97-101, 2012.

[5] Akpasam Joseph Ekanem, Simeon Ozuomba and Afolayan J. Jimoh (2017), “Development of Students

Result Management System: A case study of University of Uyo”.

[6] Añulika, E. A., Bala, E., &Nyap, C. D. (2014). Design and Implementation of Result Processing System for

Public Secondary Schools in Nigeria. International Journal of Computer and Information Technology,

3(01), 120-127.

[7] Aranuwa F.O, Iwasokun G.B, B. K. Alese, A. and F. Thompson, “Statistical evaluation of the impact of ICT

on Nigerian universities”, International Journal of Education and Development using Information and

Communication Technology (IJEDICT), 2012, Vol. 8, Issue 1, pp. 104-120.

[8] Bellika J.G., Henriksen T.S., Yigzaw K.Y. (2015) The Snow System: A Decentralized Medical Data

Processing System. In: Fernández-Llatas C., García-Gómez J. (eds) Data Mining in Clinical Medicine.

[9] Brian, P. (2009). Oracle Database 11g: PL/SQL Fundamentals, (Vol. 10). Redwood City, California:

OracleUniversity Press.

[10] Ekpenyong, M. E. (2009). A Real-Time IKBS for Students' Results Computation. International Journal of

Physical Sciences, (Vol. 20, No. 3).

[11] Eludire, A.A. (2011). The Design and Implementation of Student Academic Record Management System.

Research Journal of Applied Sciences, Engineering and Technology, (Vol.3, No. 8, pp. 707-712).

[12] Erkoç, M. F., &Kert, S. B. (2011, June). Web computing for distributed university campus: A prototype

suggestion. In International Conference on Future of Education, Firenze.

[13] Eyo and Francis (2012), “A Software Application for University Students Result Processing”.

[14] Federal Government of Nigeria, (2004), Understanding Budget 2004, Federal Government of Nigeria.

[15] From <https://smallbusiness.chron.com/advantages-distributed-data-processing-26326.html>

[16] Grey, S. (2010). Mode of processing result System. Himachal Pradesh University Journal. Pg127.

[17] Hoschek, W. (2002). A Unified Peer-to-Peer Database Framework for XQueries over Dynamic Distributed

Content and its Application for Scalable Service Discovery (Doctoral dissertation, Vienna, Tech. U.).

[18] Kumar, C. S., Seetha, J., & Vinotha, S. R. (2014). Security Implications of Distributed Database Management

System Models. arXiv preprint arXiv:1401.7733.

[19] Liu, Fang, Tong, Jin, Mao, Jian, Bohn, Robert, Messina, John, Badger, Lee and Leaf, Dawn (2011)NIST Web

Computing Reference Architecture, Recommendations of the National Institute of Standards and


https://smallbusiness.chron.com/advantages-distributed-data-processing-26326.html





[1162]

Technology, NIST – National Institute of Standards and Technology, Information Technology Laboratory,

Web Computing Program, Special Publication 500-292, Gaithersburg.

[20] Maharishi (2013), “A Web student information system to automate record generation in institutions: A

New Approach and Implementation”.

[21] Makewa L. et al (2013), ICT in secondary school administration in rural southern Kenya: An educator’s

eye on its importance and use, International Journal of Education and Development

[22] McLeod, D., & Heimbigner, D. (1980, May). A federated architecture for database systems. In Proceedings

of the May 19-22, 1980, national computer conference (pp. 283-289). ACM.

[23] Milanpreet Kaur, Amandeep Kaur and Dr. Ravinder Singh Sawhney (2013, “A Web student information

system to automate record generation in institutions: A New Approach and Implementation”.

[24] Mingaine L. (2013), Challenges Encountered by Principals during Implementation of ICT in Public

Secondary Schools, Kenya, Journal of Sociological Research, Shanghai, China.

[25] Mircea, M., & Andreescu, A. I. (2011). Using web computing in higher education: A strategy to improve

agility in the current financial crisis. Communications of the IBIMA, 2011, 1-15.

[26] Mokhtar, S. A., Ali, S. H. S., Al-Sharafi, A., & Aborujilah, A. (2013, January). Web computing in academic

institutions. In Proceedings of the 7th international Conference on Ubiquitous information Management

and Communication (p. 2). ACM.

[27] Murphy, M. C., & McClelland, M. (2008). Computer Lab to Go: A “Web” Computing Implementation. In

Proc ISECON (Vol. 2008, No. 11, pp. 1-10).

[28] Natasha Gilani (). Advantages of Distributed Data Processing

[29] O’Donnell, E., & O’Donnell, L. (2014). A review of virtualization and web computing in higher education.

In M. Khosrow-Pour (Ed.), Encyclopedia of Information Science and Technology: IGI Global, 10, 7485-

7495, doi: 10.401018/978-1-4666-5888-2.ch737.

[30] Pougatchev and Kulkarni (2011), “Technical Aspects of the Integrated Management Information System

for Educational Institutions.” School of Computing and Information Technology of the Faculty of

Engineering and Computing at the University of Technology, Jamaica.

[31] Price, Scott (2009) “41% of Senior IT Leaders Don’t Know What Web Computing Is”,

https://loadstorm.com/2009/06/41-senior-it-leaders-dont-know-what-web-computing.

[32] Ukem, E. et al. (2012). A software application for university students results processing. Journal of

Theoretical and Applied Information Technology, Vol. 35 No.l:10.

[33] using Information and Communication Technology.

[34] Wokocha C.M and Adebayo E.I. “A Guide to Establishing Management Information System in Tertiary

Institutions in Nigeria.” Department of Computer Science, Federal College of Education (Technical),

Omoku, Rivers State, Nigeria, African Journal of Basic & Applied Sciences 4 (3): 83-88, 2012 ISSN 2079-

2034, 2012.

[35] Yaniv Pessach (2013). Distributed Storage: Concepts, Algorithms, and Implementations Concepts,

Algorithms, and Implementations

[36] Zhang J, W.Fang, J.Song (2009), “The Design and Realization of the Intelligentize Online Testing System

Based on Templates”, Knowledge Acquisition and Modeling, 2009. KAM '09.

[37] ZUKOWSKI, M., BONCZ, P. A., NES, N., AND HEMAN, S. MonetDB/X100 — A DBMS in the CPU Cache. IEEE

Data Eng. Bull. 28, 2 (2005), 17–22.


https://openlibrary.org/authors/OL7168640A/Yaniv_Pessach

Documents

SEMI-AUTONOMOUS HOMOGENEOUS WEB-BASED DISTRIBUTED …