an integrated data model approach for e …fumblog.um.ac.ir/gallery/804/an integrated data model...

DISSERTATION On

AN INTEGRATED DATA MODEL APPROACH FOR

E-GOVERNANCE OF INFORMATION IN HIGHER

EDUCATION INSTITUTIONS

Thesis Submitted in the partial fulfillment of the requirements for the degree of

Master of Technology

In IT (Courseware Engineering)

Submitted By

Tanna Samanta

Roll Number: 000770101005 Examination Roll number: M69CWE10-03

Under Guidance of Mr. Sanjit Nandy

CMC Limited, Kolkata

SCHOOL OF EDUCATION TECHNOLOGY

FACULTY COUNCIL FOR UG AND PG STUDIES IN ENGINEERING AND TECHNOLOGY JADAVPUR UNIVERSITY

KOLKATA- 700032 2010

ii

Faculty Council for UG and PG studies in Engineering and Technology JADAVPUR UNIVERSITY, KOLKATA- 700032

Certificate of Recommendation

This is to certify that Tanna Samanta has completed her dissertation entitled “An

Integrated Data Model Approach for E-Governance in Higher Education

Institutes”, under the supervision and guidance of Mr. Sanjit Nandy, CMC Ltd,

Kolkata. We are satisfied with her work, which is being presented for the partial

fulfillment of the degree of Master of Technology in IT (Courseware

Engineering), Jadavpur University, Kolkata-700032.

Mr. Sanjit Nandy Teacher in Charge of Thesis

CMC Limited, Kolkata

Prof. Kalyankumar Datta

Electrical Engineering Department Programme Coordinator

M.Tech IT ( Courseware Engineering) School of Education Technology

Jadavpur University,Kolkata – 700 032

Prof. Samar Bhattacharya

Director, School of Education Technology Jadavpur University,Kolkata – 700 032

Prof. Niladri Chakraborty

Dean, Faculty Council for UG and PG studies in Engineering and Technology Jadavpur University,Kolkata – 700 032

iii

Faculty Council for UG and PG studies in Engineering and Technology JADAVPUR UNIVERSITY, KOLKATA- 700032

Certificate of Approval *

The foregoing thesis is hereby approved as a creditable study of M.Tech IT

(Courseware Engineering) and presented in a manner satisfactory to warrant its

acceptance as a prerequisite to the degree for which it has been submitted. It is

understood that by this approval the undersigned do not necessarily endorse or

approve any statement made, opinion expressed or conclusion therein but

approve this thesis only for the purpose for which it is submitted.

Final Examination for Evaluation of the Thesis _____________________________ _____________________________ _____________________________ Signature of Examiners

* Only in case the thesis is approved.

iv

Declaration of Originality and Compliance of Academic Ethics

I hereby declare that this thesis contains literature survey and original research

work done by the undersigned candidate, as part of Master of Technology in IT

(Courseware Engineering).

All information in this document have been obtained and presented in accordance

with academic rules and ethical conduct.

I also declare that, as required by these rules and conduct, I have fully cited and

referenced all material and results that are not original to this work.

Name : TANNA SAMANTA

Exam Roll Number : M69CWE10-03

Thesis Title : An Integrated Data Model Approach for

E-Governance of Information in Higher Education Institutes

Signature with Date :

v

AKNOWLEDGEMENTS

I would also like to convey my gratitude to my supervisor Mr. Sanjit

Nandy for his encouragement and kind help during the course of this work.

I would like to thank my advisor professor Samar Bhattacharya, Director,

School of Education Technology, whose help, encouragement and patience have

been invaluable. Without his guidance and constant help this thesis would not

have been completed.

I wish to thank Professor Kalyankumar Datta, Programme Coordinator for

his kind encouragement in completing this work. I am also indebted to professor

Pramatha Nath Basu and Arunasish Acharya for their immense help and valuable

comments during this work.

I also acknowledge the help and cooperation of all the teaching staffs, the

technical and nontechnical staffs of the School of Education Technology, Jadavpur

University in accomplishing this project.

I would like to thank my batch mates for their friendship and many

constructive comments.

Finally, I would like to express my immense gratitude to my loving parents

for their continuous support, encouragement and help.

TANNA SAMANTA

vi

TABLE OF CONTENTS

Executive Summary

1 Chapter 1: Introduction ............................................................................................... 1

1.1 Overview ............................................................................................................... 1

1.2 Summary of Literature Survey ......................................................................... 1

1.3 Brief Discusson on the Problem ....................................................................... 2

1.4 Objective and Constraints/ Assumption ........................................................ 3

1.5 Organization of thesis ........................................................................................ 4

2 Chapter 2: Literature Survey ..................................................................................... 6

3 Chapter 3: Problem Statement and Objective....................................................... 22

4 Chapter 4: Requirement Analysis/ Design / Implementation ........................... 25

4.1 Requirement Analysis ...................................................................................... 26

4.2 Design Methodology ........................................................................................ 27

4.2.1 Part - One: Functional Design and Subject Area Detection ............. 27

4.2.2 Part - Two: Construction of Data Flow Diagrams .............................. 31

4.2.3 Part - Three: Detection of Entities ......................................................... 88

4.3 Implementation ........................................................................................... 95

5 Chapter 5: Results and Interpretations ................................................................ 115

5.1 Results ............................................................................................................... 115

5.2 Interpretations of the Results ....................................................................... 133

6 Chapter 6: Conclusion and Future Scope............................................................. 136

7 Chapter 7: References/Bibliography ..................................................................... 137

Appendix....................................................................................................................... A.1

Appendix I: Table Structure of the warehouse ............................................... A.1

Appendix II: Test Data ....................................................................................... A.37

Appendix III: Screen Shots of Reports............................................................ A.45

vii

Executive Summary:

The purpose of this research work is to design and develop an integrated data

model to organize a data warehouse for the e-governance of information in higher

education institutes. This approach can enhance the information management

activity over there. It prevents users from recreating and gathering information

already available in the scenario and facilitates the exchange of information in the

institute community so that they can spend more time in analyzing and using the

information for the sake of learning enhancement and accomplishing institutional

mission. The proposed model is unique in the sense that it can be viewed as an

integrated one, or can be subdivided into different subject areas according to the

departmental needs.

Information is critical to the functioning of the higher education institutes from

two different yet related perspectives: teaching and administration. With the

application of data warehousing technology, the proposed model is also capable

of organizing the data in such a way that will provide information via reports to

the diverse group of users on role basis with the help of any reporting tool like BO

(Business Object), OBI (Oracle Business Intelligence) or Brio Query. Apart from

these, history data can also be maintained in this warehouse with a proper sink

with the current one and therefore trend analysis and assessment is likely to be

prepared from the data warehouse.

An Integrated Data Model Approach for E-Governance in Higher Education Institutions Page 1 of 140

1 INTRODUCTION

1.1 Overview:

The aim of this work is to build an integrated data model for e-governance

of information in higher education institutes. E-governance is the

governing of information electronically with the least physical intervention

for quick resolution and accurate administration. The motivation came

from the need of a structured data warehouse in the university

management system so that along with the others, the data driven courses

like e-learning activity can also be managed accurately.

Often, in our day-to-day life we just ignore some small information that

would be a valuable one in upcoming years and we spend a measurable

amount of time in digging out that information in later days. Same thing

happens to most of the institutes that are dependent mainly on data but

often ignores the storing this data in a proper way. These data could be a

valuable asset in the coming days. There comes the need of a structured

data warehouse that will maintain information necessary to meet academic

and administrative goals in the higher education institute management

system and can be helpful in conducting courses like e-learning.

1.2 Summary of Literature Survey:

In the way of applying the data warehousing concept in education institutes

or university, various approaches have been taken into account in different

research works, which are described briefly in chapter 2. Among them,

most of the approaches have considered the fact that data management in

the university information system must be organized in such a way, that

they should be able to provide valuable information as and when required.

Thus the application of data warehouse has been widely accepted by


several research institutes and organizations. But, most of them only

concentrated on a particular area for data mining purpose. As an example,

for student‟s and teacher‟s evaluation, the student data mart and faculty

data mart was considered and learning index was built to measure the

performance. In an approach, the data from LMS was also considered for

the evaluation purpose. All they lack is considering the academic and

administrative needs together so that information barriers among students,

faculty, administrators and other constituents can be set to minimal which

is the major aspect in this research work.

1.3 Brief Discussion on the Problem:

The most important aspect in the sake of data management is that, the

value and significance of information are often increased within context of

other information. Despite the availability of powerful computers,

advanced network and communication infrastructures, educational

decision maker still lack access to the critical information necessary for

decision making in different scenario. The reason is that the data integrity

is not maintained among different subsystems. Generally they are stored in

different operational databases with their respective basic structure and

standard. Below are a few examples of the problems with respect to this

structure:

If the university decides for a scholarship scheme for needy and

meritorious students availing courses, then the students need to

submit the details individually after the announcement, and

based on that decision would have been made.

This decision could be made within a few minutes without the student

intervention if the student information in the Student database and his

corresponding information in the Finance database were related and the

decision maker could have access to this required information for reporting

purpose only.


Access rate of a particular book in the library for a particular

course by the students

The respective teacher does not need to go and search in the library. He can

get this view himself through report if the repository for student and

library are logically or physically connected.

Sometimes, examination form is distributed among the students

on the basis of fees submitted for that semester. For that students

need to collect the proof of submission from the finance

department and show that to the examination department.

This problem can also be solved and students can collect the form from

online with their login id. If the two departments are connected on the

basis of a particular student id, then their access to the form will be given

on the status of their fees submission.

In this way effective data management with a proper data warehouse will

convert the general data into useful information for perfect course setup,

process management, student interest identification and evaluation of

students as well as the teaching process through e-governance.

1.4 Objective and Constraints/Assumption:

The main purpose of the proposed data model is to find a relation among

all the possible entities within the departments in the institute or university

that is required to organize and conduct any course by e-governance and

design a data model that will be virtually subdivided into different

schemas, but will act as a central hub to the institute‟s administrative

information system.

Since, the university has diverse needs and end users may vary depending

on the area of analysis, the model is designed to support a warehouse that

will provide information through reports with help of below separate

access mechanism:


Reporting Tool: Some ad hoc report templates have been generated

and the reports have been shown using the reporting tool BO

(Business Object) with Oracle 10g as a backend database.

Custom Query: Programs can be written to access the warehouse

using structured query language (SQL). Data can also be accessed by

writing full applications using Java, PowerBuilder etc.

The proposed model is based on some common processes that are being

conducted while attaining a course. These processes are shown via some

data flow diagrams that are discussed elaborately in chapter 4. Also the

relationship among the entities and their attributes are assumed on the

basis of their existence and activity in the course management curriculum.

This may vary according to the needs of the institute or university

management information system.

1.5 Organization of Thesis:

After the introduction of the research work and a brief discussion on the

summary of the literature survey with problem to be solved, objective,

constraints and assumption the organization of the rest of the thesis is as

follows:

Chapter two describes the literature survey.

Chapter three describes the problem statement and objective.

Chapter four describes the requirement analysis, design and the

implementation of the data model. The design part is subdivided

into three parts. The first part deals with the overall functional

design and requirement analysis and the second part deals with the

data flow diagrams and conceptual diagrams for the database level

implementation. The third part deals with the detection of the


entities and their functions in the database. The implementation

section contains the entire data model along with the relationship

among all the entities depicted from the previous procedures.

Chapter five describes the result along with test cases and

interpretations of the results.

Chapter six describes the conclusion of the entire work and future

scope.

Chapter seven contains the references made for this research work.

Appendix section is divided into three parts. Among these the first

section contains the table structures of the warehouse as designed

in the data model and the necessary constraints among them. The

second part contains the test data that have been provided for

generating the reports. The third section contains the snapshots of

the results made by the reporting tool BO and through custom

query via sqlplus.


2 LITERATURE SURVEY:

As a part of the data driven organization, education is an exemplary activity

that is increasingly being offered through the web. In their lifetime, the

education institutes gather huge amount of data during the process of

teaching, learning and management. For the need of university development

purpose, the DSS (Decision Support System) needs to be set up with proper

warehousing and mining technology. This can speed up the enhancement of

the education system to establish the perfect courses setup and to improve the

mechanism of teaching. A typical example of the extent of integration of the

technology of data warehouse, data mining etc, can be seen as a model of

university decision support depicted by Meijing Kong, Wan-Zhen Zhou,

Wen-Tao Wang and Hong-Bin Gao in [15] as below:

Figure 1: A model of university decision support (Adopted from [15])

In the above model, the data warehouse management system performs various

operations such as organization of data warehouse and abstraction of data.

Data mining gets useful information from this organization of data and

User (decision-making)

The man-machine conversion interface

Model base system

Knowledge base system

Decision information

Data mining

Data warehouse management system

Data Warehouse


satisfies various requirement of decision support system. The conversation

model of man and computer enables interactive interface containing user and

system. Thus by data mining from the great deal of data gathered by various

departments, proper decision can be made about the teaching plan and course

setting. But, if the decision and analysis is based on the data sets which are

dispersed among various departments and systems, many problem may arise

such as lack in uniformity in standard and organization. So, a proper

warehouse needs to be build up by taking into consideration the factors like

integrity, consistency and uniformity that will provide appropriate input to

this mining system and DSS [15].

From the above discussions, need of a proper warehouse is very prominent

as per the discussion in [15], but only mining technology is considered and

implemented over there. The relationship among the entities in a university

management system remained a concealed part of that work. Apart from this,

for the sake of a data warehouse, the mining technology needs input from data

base through various fact and dimension tables as per the entities identified in

the management system. Considering this circumstances, another approach

was taken by Marta Zorrilla in his work in [17] where design of a web house is

depicted which is adapted to support collaborative actions in e-learning so

that the integrated collaborative e-learning structure can be supported.

In web based learning, the user, that is the students and teachers are

provided with adequate tool recovering the limitations of temporal constraints

[17]. In the case of e-learning, the lack of student-educator relationship is

evident as the teacher does not directly controls the student activity and the

students also express their problems in a natural way. This problem is found

in different web based learning environment. It is very difficult and time

consuming for the educators to track all the student activities in detail and

assess accordingly to evaluate the structure of the course and its value in the


learning process [17]. Although, data mining technology in e-learning is a

challenging activity, different architectures have been proposed for

collaborative e-learning systems. A special three component architecture

(operational, collaborative and analytical) presented by Gartnet Group [26], for

CRM can be easily translated when dealing with e-learning environment [17].

It is assumed over there that the modules of the collaborative actions are the

results of the patterns obtained from analyzing the components that are

connected to the operational module. For the implementation of these

architectures and the interchange of information to work, a data web house is

needed that will contain the structured information of the web. As part of the

implementation of this web house, a model was proposed, containing some

necessary entities of the university management system and corresponding

dimension and fact tables for the construction of the warehouse. The purpose

of this model is to discover the information to be stored so that most intelligent

decisions can be made. Three main kind of information have been

distinguished for this model such as, information related to student, faculty,

enrollment and exam as well as course structure [17]. This is the information

which is independent of the communication channel chosen to learn (face to

face or e-learning). Another type is navigational information which is related

to user navigation gathered by web server such as session, time of stay in

pages etc [17]. The third type is web site structure and content information

[17]. The design is just concentrated on the faculty and the students and

proposes to analyze them separately. This can be used as the supporting

structure for any mining architecture. The following data marts are obtained:

Navigational data mart, Learning Data Mart, Teaching Data Mart and Course

Data Mart [17].

The above system can further be improved by implementing data marts for

other kind of information so that the overall information need can be satisfied

by the university decision makers and a generalized view can be obtained in


the global infrastructure of learning and teaching management. In fact, the

need of a proper data warehousing technology is very prominent at this point

of structured implementation need by the university decision maker.

A DW (Data Warehouse) system helps us to enhance the personalization and

content distribution. So, the use of data warehouse in e-learning is very helpful

in decision making process by the teachers and the administrators. Depending

on the analysis, the content structure can be modified according to the user

needs. In the recent years, university education is facing higher quality and

flexibility in teaching and environmental structure. The number of students

who are unable to follow the traditional method of learning due to time and

space constraint, has increased in a large account in the past few years in

higher education. So, learning method is also undergoing to a new approach,

which is student centered learning, providing the student more control over

his/her learning. Different software packages like the LMS (Learning

Management System), CMS (Content Management System), ELMS (Enterprise

Learning Management System) etc have been developed that enables the

management and delivery of learning content and facilitate anytime and

anywhere access to learning content by the students. However these systems

do not support data analysis directly, which can enable the teachers or

decision makers to evaluate the students according to their behavior over e-

learning platform. The use of DW technique can resolve the problem by

providing an integrated source of information gathering the data from these

heterogeneous systems.

In the progress of structuring the data needs of the education decision

makers, and in accordance with the discussed deficiencies depicted in the

previous works, a more sophisticated approach was found in the EDUCASE

decision support and data warehousing constituent group (Heise, 2007) [2 ] . A

business intelligence approach is taken over there to track the data of LMS and


other sources and store them in an intelligent manner so that it can be used for

decision making. As per the inclusion of LMS, E -learning can be defined as

any kind of learning by means of any kind of information and communication

technology (ICT). Each time a student logs on to the LMS, participates in an

online discussion or reads an electronic document, an electronic transaction is

performed. With each of the transaction data are captured by the LMS. The

value as well as importance of information increases within the perspective of

other information. The value of LMS tracking data can also be increased

within context of information from other module. Then this tracking data can

be associated with the measures of teaching effectiveness, such as results,

learning styles and student satisfaction. This information context creation is

possible when a deliberate business intelligence approach is followed to build

the warehouse [2]. As a practical implementation of this concept, a framework

based on Kimball‟s generic business intelligence framework within the context

of Higher Education Institute is shown as below:

Figure: 2

Source system

(E.g. LMS)

Source systems ETL Data Warehouse Analysis

Manual Input (E.g. survey

data from MS excel, MS

Access)

Source system (E.g. ERP)

Source system

(E.g. SIS)

Source system

(E.g. Finance)

Staging Conversion

(Extract - Transform -

Load)

Example of data marts

Example of data

Warehouse dimensions

Click-stream data mart

Student data mart

Alumni

Students

Lectures

LMS tools

Modules Results

Data Mart Repository

( Definition of source formulas etc.)

Ad-Hoc

Analysis

Standard measures data mart

Standard measures of online teaching effectiveness


In this model, data from sources are extracted, transformed and loaded in the

warehouse consisting of data marts. Data in the warehouse is then organized

in such a way to provide support for ad hoc analysis. Out of this some

effective measures for e-teaching effectiveness are consolidated to provide a

set of standard measures. EDUCASE maintains a directory of data warehouses

in higher education as part of the activities of EDUCASE decision support and

data warehousing constituent group (Heise, 2007) [2]. Enterprise Resource

Planning (ERP) systems, Student Information Systems (SIS), and learning

Management Systems (LMS) are typically source systems for the warehouse.

The EDUCAUSE HE data warehouse contains data marts such as alumni,

prospective students, modules and facilities. Most analyses drawn from these

data marts are designed to support decision-making on strategic level. Some

operational and micro-level decision support is provided in the form of

customer (student) relationship management (CRM) type of queries to enable

marketing and communication targeted specifically at potential students or

donors [2]. Mainly e-teaching effectiveness is considered with respect to some

measurement like, learning styles, student results and satisfaction. Also

measures of online behavior are also considered with respect to click stream

data mart, where total number of hits per student per module etc is calculated.

The above work mainly focused on LMS tracking data for micro level decision

making in the organization. Data mart concept is adopted here, but that does

not content all the data corresponding to various entities necessary for any

kind of operational decision making in the educational organization. In fact,

the logical integrated data model concept is still a bit away from their solution.

The same kind of approach is also taken by F. Araque1, A. Salguero1.

Martínez2, E. Navarro1 and M. Calero1 in their work related to the use of

warehousing for improving web based learning sites in [1]. Here the DW (Data


Warehouse) is fed by the data generated by students when navigating through

the platform. After that, On Line Analytical Processing (OLAP) is used to

generate valuable reports based on the analysis and help in the learning

evolution [1]. This would help to improve the relationship between the teacher

and the student. A generic functional architecture was proposed in [1] as

below:

Figure 3: Functional Architecture

Here the DW is fed by the data from e-learning platform. After that the Data

Mart is loaded with useful information necessary for analysis. The education

will be able to access the data mart data through an interface inside the

e-learning platform. This platform can be helpful in answering several

questions like how long the student is connected to the platform, which is the

most popular page, the connection percentage from university campus etc. A

multidimensional schema including activity, student, source, target and time

have been defined to implement this. OLAP servers are actually software tools

that help to prepare data for analysis, query processing, reporting and mining

[1]. An e-learning platform has also been developed using ASP.NET which is

based on learning modules. If data were extracted from the distributed data

sources, then they would need to be correlated at a particular point of time

Students

E-Learning Platform

Data

Warehouse Data mart OLAP

Data about

student navigation

Feed back data


before presenting to the user. But, in the DW it can be found in a central place.

In this way an approach has been taken into consideration by integrating the

DW concept and OLAP technique for the evolution and decision making in

e-learning.

In the above model, the DW and the data marts can only be implemented

using relational databases defining multidimensional structure. But, this

structural detail is not been considered as a major part of the generic

architecture proposed in [1] as well as in [2].

In another e-learning management initiative taken by technical university of

Graz to support multimedia method in engineering education has also

realized the need for establishment of central database because of the

problems concerning the cooperation between the administrational staff and

the education department [4]. They supported the following basic rules:

Data should be collected or manipulated electronically at the

responsible organization

Each data-item should exist only once in the system, no duplicates, no

transfers

Each person on the university should have a personal identification in

the system

The persons privileges in the system should depend on its functions on

the university

Only one central database should be used (for maintenance- and

support-reasons)

A very generic application model was proposed by them consisting of five

embedded layers that were also fully integrated in the E-R model as shown in

the next page.


Figure: 4

This model can be understood very easily by this example:

The identified person “X” is connected to

The function “Lecture-Manager” that is connected to

The role “Edit Lecture” of

The program “Lecture Management” that operates on

The data “Lectures” of the organization ”Z” department to which the

function belongs [4]

The goal of this model was to allow a much decentralized access management

for the system. The above considerations have partly described some of the

basic relational database design needs that would help towards defining an

integrated data model.

In the way of progress, another very different approach has been taken into

account towards the need of achieving a dynamic data model scheme. Today

many e-learning systems achieve high standards in delivering online courses

via web technologies and database system. But more or less, these systems are

based on rigid data model or schema that was predefined in the database to

provide data storage structure for contents. Many e-learning systems are

Identified persons

Functions

Roles

Programs

Data


supported with a backend database system. The database system works as the

storage of the contents data in the e-learning system. The use of a database

system provides fast retrieval of data information, and it stores the data in an

organized, logical and non-redundant manner [5]. In the database driven e-

learning system, this model can be crucial in analyzing the data requirement in

the system. The most concerned issue includes the inflexibility of the data

model that leads to unalterable contents data structure and its layout format,

because the attributes in the data model are expected to be hard coded during

the development in most cases [5]. To avoid such inflexibility and improve the

performance in the e-learning system, Chee Chern LIM, Man Hing YU, Jesse J.

JIN proposed an approach of generic data model scheme in the database

structure and interface design toolkit which allows the users to make

modifications on the data structure and the system has the ability to adapt

these changes [5]. Their work focused on the issues related to the design and

development of an e-learning system named Cyber Campus. Cyber Campus is

a web-based teaching and learning education system developed based on the

proposed generic data model scheme [5]. Most e-learning systems do not

allow alternation on the data structure after the completion of system

development. Thus, any small alteration in the database require large amount

of processing time. To overcome such problems, the proposed generic data

model contains two entities: FORM_PAGE and FORM_FIELD. FORM_PAGE

stores the contents in the presenting page, and FORM_FIELD stores data or

attributes in the form. Any alteration of the data structure will be solely on the

FORM_FIELD table, without further modification of codes in HTML form

page. It was developed with additional special layer interface in the e-learning

system.

Thus, the generic data model scheme was proposed with some relational

entities, which were implemented with some extra database layer connections

and some other additional portal, as well as technical requirement, which are


adopted by the e-learning system Cyber Campus. But, this approach can only

be taken after identification of entities based on the data requirement and their

relationships in the systems. Also additional cost may be an overhead to

achieve this kind of generic data model in the e-learning system. A need for an

integrated database level approach is still remains very necessary but,

concealed fact in all of the above discussions.

In the need of data warehouse as per the previous methodologies, apart from

the operational and strategic decision making another very important task like

content management process was also considered for which an approach was

taken by Sean Wolfgand Matsui Siqueira, Maria Helena Lima Baptista Braz

and Rubens Nascimento Melo in [24], in which two different content views

was noticed: operational and explorary. The operational view is used for

insertion, update and deletion of the content while the explorary view

provides the perception of the available content through the navigational

queries. A five layer architecture based on data warehouse approach was

proposed in [24] which consider learning content management as well as

learning metadata proposal standards, domain ontologies and personalized

hypermedia content presentation. The proposed architecture is shown below:

Figure: 5

DW system‟s architecture (at left) and e-learning proposed architecture (at right)

DW Integrated

LO Metadata

Managerial

View

Operational

View

Analytical

Applications

E-Learning

Application

s

Metadata

Ontology

Transformer’s Extractors Semantic compositions

Exploratory

View

Operational

View

Learning Objects Repositories

Production Systems

DM2 DM2 Domain LO

OS1 OS2 OS3

Atomic LO


The traditional data warehouse system is shown at the left side which

describes the flow of data from operational sources (OS), to the Data Marts

(DM) after extraction, cleansing and transformation. Analysis can be done

from the data of these data marts. In accordance with this DW architecture, a

five layer e-learning architecture is shown in the right side of which, the first

layer is for LO (Learning Object) repositories. Here we can find the atomic

LOs. They are actually the raw content as, they do not have any relationship

with other Los. The second layer is composed of structural-composed LOs.

They represent the composition of atomic LOs. In the third layer, we can the

integrated view of the objects and in the fourth layer the content can be seen

according to certain domain area. Finally, the fifth layer provides the

presentation of the LOs. It incorporates hypermedia concepts as well as

content personalization technique [24]. If the user makes a request to the e-

learning environment, the system checks the user profile and according to that

defines views over the LOs based on their relationships over layer three and

four and according to the role of the user. Thus, the content is presented

according to the user‟s profile following hypermedia modeling concepts [24].

Personalized content distribution technique shown in [24] can also be

adopted in personalized query distribution technique where a user or decision

maker will be provided with proper result or data set as per the role defined

for the user in the system because this warehouse is accessed by various users

of e-learning systems like educators, learners and decision makers for many

reasons.

An educational data warehouse comprises of information gathered from

heterogeneous, autonomous and distributed learning systems. One of the most

important tasks is to update the warehouse data in case of source information

changes. A view synchronized maintenance technique can be adopted to

update the warehouse as per the source changes in order to ensure integrity,

accessibility and availability of the afforded information as per the work of


Jalel Akaichi in [7]. An agent based approach was taken to reduce the effects of

schema changes in the system. One of the major tasks of the electronic data

maintenance system is to update the warehouse as per the source information

changes. This approach has the goal to preserve the maximum number of

effected view definitions by occurrence of learning information sources

schema changes [7]. It is assumed that the information sources are integrated

in the e-learning system via a wrapper. This wrapper converts their structure

into a common rational model [7]. This E-DWMS system contains two basic

modeling tools of which one permits to user the expression of view definition

evolution via an extended SQL called Evolvable SQL (E-SQL) and another for

the description of the information sources (MISD) and the relationships

between them [7]. The View Knowledge Base (VKB) is an agent, which

contains views definition expressed with preferences by users and described

by E-SQL. The Meta Knowledge Base (MKB) revealed by MISD, represent the

base for any operation of view rewriting or view synchronization process [7].

In collaborative learning scenario, multiple schemas can be formed by the

individual institutes to provide some common e-learning resources to the

collaborating communities. In such situation the views can be formed with the

help of E-SQL. The E-SQL view definition can then be stored in the View

Knowledge Base (VKB). The rules and constraints are embodied in the MKB

for schema changes. Thus the availability of e-learning informational sources

in collaborative learning scenario under schema changes was optimized

adopting the above agent based model.

Though most of all the models described till now do not really concentrates on

the relational database structure or the data warehouse model implementation

part at all, but, this fact has been considered partially in the work presented by

Darja Solodovonikova and Laila Niedrite in [9]. Here the data from WebCT log

files and WebCT internal data have been combined along with the university

MIS in order to provide suitable information to learning and administration.


The main purpose of this work was to evaluate the usage of WebCT at the

university. This was done with help of data warehouse where the sources

were Web log files and university MIS from which the data about courses,

student grades, study programs etc was extracted. The data warehouse was

implemented in the Oracle RDBMS. Data access was done by Oracle

Discoverer. Data loading was done on weekly basis. The warehouse star

schema presents the information about the structure and usage of the course. It

contains three fact tables like, Structure fact, usage fact, activity fact and

corresponding measurements and dimensions. The structure fact incorporates

the data about the course structure consisting of four dimensions: Time, Tool,

Course and teaching. The Usage fact table contains two measurements–

Number of registered students, Number of active students. This star schema

uses the dimensions Course and Time described above. The activity star

schema includes student activities in the WebCT during course acquisition [9].

This presents the usage information such as Hit number, Data amount and

Time which records student‟s usage. The overall source to warehouse loading

process as described in [9] is shown below:

Figure:6

Figure: The summarized loading process from WebCT data source

(Adopted from [9])

Log File

XML File

WebCT

database

WebCT Data

Source

Staging Area Data Warehouse

Table with proposed activity

informat ion (Table1)

Table with data about courses, users

and their roles

Table with course data and indices

(number and file size of tools)

Session Dimension

Activity Fact Table

Structure Fact Table

Usage Fact Table


As per the model, the data sources of the warehouse include the Web server

log file and the WebCT‟s internal database. The university management

system (MIS) which is a relational database is not shown over there as the data

are extracted following a very well known way in data warehousing. Data

from the log file are first processed and loaded into a database. The WebCT

internal database is not a relational database. To extract the user role from

there WebCT API is used. It transfers the data into an XML file. Data about the

course structure and the number of registered and active students are

extracted from the WebCT internal database and summarized and loaded into

a table via a specifically developed script.

Thus different approaches have been taken into account to provide the

sufficient use of data in educational institutes including those conducting e -

learning and corresponding technological applications have also been

considered. It is evident from the previous discussions that a warehouse is a

must for any kind of decision making in higher education institute. But, from

the models proposed till now have only taken into account the functional

aspect and few of them have proposed an elementary diagram of entities

involved in the organization to evaluate the student and teacher performance.

This is not the overall aspect of any higher education institute who also

conducts e-learning courses. As, there is a lack of direct contact between the

institute and the learners in e-learning, and also disparity in information

between various departments, there must be an integrated warehouse system

that will relate all the components of the organization like academic, student,

staff information, Finance and library etc. If we can establish a link between all

of these components, then it will be far easier for the institute to analyze any

kind of situation for strategic, tactical and operational decision making as well

as the students could perform different other functionalities other than studies

like issue library card, fill up the examination form of submit fees in a

smoothly manner.


Taking into account all of these aspects, an integrated data model approach

is proposed containing justified relation between some possible components of

an education institute.

This model can be subdivided into appropriate subject areas or schemas

providing sufficient privileges among them or can be applied as an integrated

one in the database. Thus the warehouse can be constructed comprising the

data coming from all of the components in a higher education institute

providing support to generate reports for any kind of decision making by

diverse users in the organization.


3 PROBLEM STATEMENT AND OBJECTIVE:

The problem to be solved is to generate an integrated data model for e-

governance of information in higher education institutes.

There is no institute or university, which is running without data. In fact they

are the lifeblood of the higher education institute. E-governance is the

management of these data through electronic means so that time and efforts

needed by manual intervention can be minimized for fast recovery of

necessary information from the system. The primary objective of the education

institutes is the preservation, advancement and distribution of knowledge. To

fulfill this objective, universities enable students, faculty and other co-workers

to collect, exchange and increase knowledge by creating and using information

in the form of data. On the other side, the administrative functions that

support and enable this knowledge development also rely heavily on this data.

This data dependency becomes inevitable in case of courses like e-learning. As

the student-teacher interaction is minimal here, a large amount of the

processes are only data driven. Most of the times, these data are only kept for

record keeping purposes and in an unorganized manner. In that case

information extraction really becomes a very tough job. The reason is that, to

become information data must be presented in a proper and structured way.

There comes the need of a well organized data warehouse and for that an

integrated data model that will contain the relationship among the entities and

there attributes in the education institute or university community.

If data are kept in a way that is readily understandable and accessible by the

required user, then they can spend less time on searching and collecting

information rather than using it. A good correlation is also possible among the


various departments if they can get standardized and synchronized

information instead of the scattered one. Also, data analysis will be an easier

one if statistics can be obtained from harmonized information out of the

history and current data. An integrated synchronized data repository would

therefore help the administrative as well as the other tasks easier and efficient

with respect to the one that is dependent on the separate and scattered data

without any synchronization.

The basic vision of the data model proposed in this work is to point out the

relationship between every single entity and their attributes necessary to

conduct a course in the university so that data duplicity can be set to minimal

and convenient access to the accurate and up-to-date information is possible.

This approach reduces the anomaly among the data and storage requirement..

Also this model is build in such a way, that department wise data can be

virtually kept in separate schemas and necessary access can be given to the

other departments so that data consistency can be maintained. Also, history

data can be maintained in synch with current one so that trend analysis and

other valuable information can be extracted out of it. In brief, the integrated

data model consist the following features:

Applicable relationship among all the possible entities

Minimal duplicate attribute

Flexibility of being implemented as an integrated one or can be

implemented as different schemas which will be maintained by

different group of administrators according to various departments.

Flexibility of structure capable of sharing of information among

different group of users via different schemas that will be controlled via

necessary grants. The model is presented as an integrated one and also

subdivided into different subject areas according to the different

departments in the university.


Capability of maintaining “Changed Data Capture” facility.

Capability of tracking history records with synchronization with the

current data.

Selection of attributes suitable for report generation activity both via

any reporting tool as well as custom query by means of Structured

Query Language.


4 REQUIREMENT ANALYSIS / DESIGN / IMPLEMENTATION:

The design of this research work is mainly concentrated on building the data

model to organize an integrated repository or data warehouse and the concept

of building this model is divided into three parts:

Requirement analysis

This part deals with the reporting needs of the users considering the

academic as well as management‟s expectation that helps in the

subsequent phases to figure out the subject areas and entities within

the university curriculum.

Design Methodology

This part is divided into three sub parts

The first part deals with the conceptual view of the overall

process and the applicability of the repository in the system

along with the subject areas.

The second part deals with the data flow diagrams to identify

the entities and understand the relationship among them

The third part consists of the conceptual view of the database

level implementation of the data stores or entities and the

schema level division of the integrated data stores.

Implementation

The third part deals with the actual data model concept that will be

applied in the data warehouse.


4.1 Requirement Analysis

Some of the reporting needs among the diverse users of the data

warehouse have been classified into three categories for the sake of this

research work as below:

From Academic point of View

The Student is promoted or not to the next semester so that

examination form can be provided to him

Fees submission for the semester is complete or not.

The student is eligible to appear for the supplementary exam or

he has covered the maximum chances for the exam.

The student can issue a book or not

Whether clearance can be given from all the necessary

departments to the student for passing out at the end of the

course.

Whether the student has submitted the fees for issuing the

library card.

If any fine is pending due to book submission in the library.

From the Educator‟s point of view:

The student‟s progress report is satisfactory or not.

What kind of book is most accessed by the student for a

particular subject?

What is the progress report of the backward class students?

Comparative study of access rates of the LMS and result.

How many students are availing the library?


From Management‟s Point of View

Need to launch a scheme for needy meritorious students.

Teaching Staffs availability for a particular subject.

What is the academic background of the students availing the

course?

Need for the course in a particular state or local area.

Attrition rate if any.

How many students are having multiple courses under same

university?

Comparative study between different courses by comparing

their results.

Visiting Staffs details.

Keeping in mind the above reporting requirement, design strategy of the

data warehouse and the data model have been decided in the subsequent

phases so that it can afford similar kind of other reporting needs also.

4.2 Design Methodology

4.2.1 Part – One: Functional Design and Subject Area Detection

While designing Part I, at first eight subject areas have been decided

considering some of the general processes like student admission,

examination procedure etc as below:

Academic

Faculty

Student

KMR

Library

Finance

Student assessment

General


The subject area “Academic” is for storing the entire academic details like

subject, course etc. “Faculty” subject area is for storing the faculty details.

In the same way, “Student” is for storing the student details. “KMR” is the

Key Muster Rolls that is for tracking the registration details of the students.

“Library” will manage all the transactional data and book detail related to

library. “Finance” is for storing the financial transaction related data.

“Student Assessment” is for storing all the records of the students for the

assessments including the examination details assigned to a course. At last,

“General” subject area is for storing the common information that will be

required by all the other subject areas for managing information.

These subject areas have been shown each as a separate schema that is

under the control of separate administrative groups. All of them share the

required information with the other schemas or administrative groups so

that data integrity and consistency is maintained.


The conceptual view incorporating these subject areas within the

repository has been depicted as a model as shown below:

Figure: 7 Integrated Data Warehouse/ Repository Model

Description

In the above diagram, data from the sources are kept in the repository

according to the predefined structure, which will be implemented as per

the data model that will be derived in the subsequent sections. Data can be

stored in the warehouse directly from the web or excel files or can be

Manual

Input (E.g.

Data from

excel, CSV

etc)

Web Data

Student

Student

Assessment

Academic

Faculty

Library

Finance

General (Contains the

synonyms of the shared tables if requi red along with the

common tables)

Integrated Repository View

Add-

Hoc Analysis

by Admin

Yearly

Report

Decision

Making

Web User

Access

Feedback

Academic Control

Examination Control

Administrative Control

KMR


stored manually. These data will be stored in different schemas according

to their subject areas that will be under the control of three administrative

groups mainly:

Academic Control

Examination Control

Administrative Control

Under academic control, there will be two schemas: Academic and Library.

Under Examination control there will be one schema namely Student

Assessment. Under Administrative control, there will be three schemas:

Student, Faculty, KMR and Finance. The common tables and the required

views will be represented by the General schema that will be shared by all

other schemas. Connectivity through proper grant will also be maintained

among all these schemas, so that data integrity is maintained. Having

implemented, this repository or warehouse can be used for several

purposes like, yearly report generation, Ad-hoc analysis by ad-hoc report

generation using any reporting tool or just by firing SQL queries to the

database, decision making by data mining and web users can also access

this database as per their needs decided by the administration body. These

web users can then provide input to the system as feedback provided

proper access is given to them. This integrated repository virtually divided

by separate schemas will be helpful in managing the information

requirement of the diverse group of users within the university with

maintaining proper security and access control as per the structure. Thus,

all the activities related to the academic and administrative aspects of the

institute will have convenient access to relevant, accurate and up-to-date

information across the community.


4.2.2 Part – Two: Construction of Data Flow Diagrams

Designing of part II consists of the Data Flow Diagrams (DFD) according to

the academic and administrative activities in the university. The DFD

construction is mainly divided into three levels: Level 0, Level 1 and Level

2.

Below is the detail of Level 0 DFD construction which considers a single

process considering all the activities within the university.

The following external entities have been considered that will provide

input to the process “University Management System” and will receive

corresponding outputs from it:

1) Entities:

Student

Faculty Council

Faculty

Administration Body

Finance

Examination Controller

Librarian

KMR

Department

Only a single process “University Management” has been considered that

will represent all the processes in the curriculum.

2) Processes:

University Management System


Data flows have been named as per the entities so that in and out flows can

be separated according to the entities. The standards adopted while

naming the data flows are described as below:

DO: Output from the entity Department.

DI: input to the Entity Department

LO: Output from the entity Library

LI: Input to the entity Library

FCO: Output from the entity Faculty Council

FCI: Input to the entity Faculty Council

SO: Output from the entity Student

SI: Input to the entity Student

AO: Output from the entity Administration Body

AI: Input to the entity Administration Body

FNO: Output from the entity Finance

FNI: Input to the entity Finance

KO: Output from the entity KMR

KI: Input to the entity KMR

FTO: Output from the entity Faculty

FTI: Input to the entity Faculty

ECO: Output from the entity Examination Controller

ECI: Input to the entity Examination Controller

The number of inputs and outputs for a single entity are shown along with

numbers in the corresponding line. Only two single line have been

considered for each entity for representing the in and out flows from and to

the “University Management System” process. The individual data flow

details corresponding to each entity are described in the next section.


3) Data Flows:

DO :

DO1: Course setup and details

DO2: Assign subject id to subject

DO3: Assign course id to course

DO4: Assign subjects to courses

DO5: Send Faculty requirement details

DO6: Subject and project assignment to Faculty

DO7: Subject List

DO8: Sends List of Paper setter, examinee and examiner

DO9: Sends Student Application

DO10: Sends the Faculty Information

DO11: Department wise expenditure details

DI:

DI1: Request for Faculty information

DI2: Approval Status

DI3: Recruited Faculty Details

DI4: Exam Ids and Examination Date

DI5: Selected candidate list and information

DI6: Request for Paper setter, examinee and Examiner List

LO:

LO1: Issue Library Cards to Faculty

LO2: Request the status of availability of the required book

LO3: Request the status of number of books issued by the

student


LO4: Issues Book according to availability and previous issue

status

LO5: Issues books for Faculty

LO6: Check submission date and calculates the fine if any

LI:

LI1: Book issue request

LI2: Sends Status

LI3: Sends Submitted Book

LI4: Receive deposited fine

LI5: Library Card Request for Faculty

LI6: Book issue request for Faculty

FCO:

FCO1: Send approval to Department

FCO2: Reviewed list

FCO3: Assign course id to course

FCO4: Assign subjects to courses

FCO5: Send Faculty requirement details

FCO6: Subject and project assignment to Faculty

FCI:

FCI1: Get the approval from Administrator

FCI2: Course setup details

FCI3: Faculty requirement details for review

FCI4: Recruited Faculty Details

FCI5: Request Applications for Candidates


SO:

SO1: Provides Details

SO2: Deposits fees for Admission and Registration

SO3: Deposit Fees for Library

SO4: Request for Book

SO5: Deposits fine if any

SO6: Submits book

SO7: Request the form

SO8: Submit the form along with exam fees

SO9: Submit exam papers

SO10: Deposits Fees for semester

SI:

SI1: Provides the student id

SI2: Generate Library Card-ID and Issues Library Card

SI3: Provide Book

SI4: Send fine details and submission status

SI5: Exam notice as per the instruction

SI6: Get the form

SI7: Generate and send the exam roll id and exam date

SI8: Generates and publishes the result

SI9: Send the receipt

AO:

AO1: Sends approval detail

AO2: Send approval for Faculty recruitment

AO3: Allocates Administrative Role

AO4: Provides instruction and information

AO5: Assign Start time and end time for a course in a session


AI:

AI1: Course setup details From Faculty for Approval

AI2: Get the reviewed staff requirement list

AI3: Recruited Faculty Details

AI3: Admitted student information

FNO:

FNO1: Sends library fees submission status

FNO2: Send the fees clearance status

FNO3: Sends Clearance for Admission

FNO4:Sends Calculated Reports and clearance

FNI:

FNI1: Send collected fess and request for library fees

submission status

FNI2: Request for course fees submission status

FNI3: Sends the collected fees to the Finance

FNI4: Fees Collection

FNI5: Collected Fees and other cost details

KO:

KO1: Provide Confirmation

KO2: Generate Student Id

KO2: Provides Registration id


KI:

KI1: Sends Details for verification

KI2: Request for Registration

FTO:

FTO1: Request for Library Card

FTO2: Request for Book

FTO3: Sends the faculty details

FTO4: Question Papers

FTO5: Send the marks details

FTO6: Send the evaluated papers along with marks

FTI:

FTI1: Get the Library Card

FTI2: Get the Book

FTI3: Recruitment confirmation

FTI4: Generate and send the Staff-ID

FTI5: Get the assignment detail

FTI6: Appointment for paper setter and evaluation

FTI7: Send the paper for evaluation

FTI8: Request for sessional marks and attendance records

FTI9: Provides the salary

ECO:

ECO1: Examination Date

ECO2: Send the list of examiners for evaluation

ECO3: Provides approval for publishing the result

ECO4: Send the eligibility status


ECO5: Instruction for form fill up and exam fees submission

ECO6: Send the Selected papers

ECI:

ECI1: Get the subject list

ECI2: Get the Question Papers

ECI3: Request for eligibility checking


Data Flow Diagram Level - 0 (Context Diagram):

Figure: 8

In the above diagram multiple lines have been indicated by a slash along

with the name and number beside the lines.

University Management

System

Student Librarian

Finance

Faculty

Faculty

Council

Admin istration

Body

Examination

Controller

Department

KMR

6DI 11DO

9SI

10SO

4AI

6LI

6LO

5AO

2KI

3KO 5FNI

4FNO

4FCI

6FCO

9FTI

7FTO

3ECI 7ECO


Data Flow Diagram Level – 1

At level 1 the entities remain the same as described in level 0. Only the

main process has been subdivided into six sub processes according to

which data flows have been decided. In the data flow diagrams, a single

line has been used for indicating the input or output from the individual

entity to individual process. If input or output is more than one, then this

number is shown along with the line. Later on the data flows have been

described in detail in the child diagrams where all the inputs and outputs

are shown. Below are the entity and process details:

1) Entity:

Student

Faculty Council

Faculty

Administration Body

Finance


Librarian

KMR

Department

2) Processes:

Student Admission

Library Management

Faculty Management

Student Assessment

Financial Transaction management

Academic


Data Flow Diagram (Consolidated) Level – 1

Figure: 9

In the above figure, to represent multiple lines, a slash has been used along with

the number beside the line.

Student

Librarian

Administration

Body

Faculty Council

Finance

Faculty

Examination

Controller

KMR

Library Management

Course Management

Faculty Management

Student

Assessment

Process

Admission

Financial

Transaction Management

Department

6

6

3 3

6 2

3

3

4

2

4

2

2

2

2

2

2

2

4

3

3 3

2

2

2

4


Data flow details of the above diagram are given in the child diagrams in the

coming sections.

Child Diagrams - Library Management:

Figure: 10

Details of the Child Diagram for Library Management:

Library

Management

Student

Librarian Finance

11) Provide

Book

9) Sends Status

4) Generate Library Card-

ID and Issues Library Card

5)

Request

for Book

7) Request the status of availability of the

required book

3) Sends library

fees submission status

8) Request the status of number of books

issued by the student

10) Issues Book according to

availability and previous issue

status

1) Deposit Fees

for Library

2) Send

collected

fess and

request for

library fees

submission

status

6) Book issue request

12) Submits book

13) Sends Submitted Book

14) Check

submission date

and calculates the

fine if any

15) Send

fine details

and

submission

status

16) Deposits fine i f

any

17) Receive deposited fine

Faculty

Request for Library Card

Library Card Request for Faculty

Issue Library Cards to Faculty

Get the Library

Card

Request for Book

Book issue request for Faculty

Issues books for Faculty

Get the Book

Submits the book


1) Entities:

Student

Faculty

Librarian

Finance

2) Processes:

Library Management

3) Data Flows:

3.1) Deposit Fees for Library

3.2) Send collected fess and request for library fees submission status

3.3) Sends library fees submission status

3.4) Generate Library Card-ID and Issues Library Card

3.5) Request for Book

3.6) Book issue request

3.7) Request the status of availability of the required book

3.8) Request the status of number of books issued by the student

3.9) Sends Status

3.10) Issues Book according to availability and previous issue status

3.11) Provide Book

3.12) Submits book

3.13) Sends Submitted Book

3.14) Check submission date and calculates the fine if any

3.15) Send fine details and submission status

3.16) Deposits fine if any

3.17) Receive deposited fine

3.18) Request for Library Card

3.19) Library Card Request for Faculty

3.20) Issue Library Cards to Faculty


3.21) Receives the library card

3.22) Book issue request for Faculty

3.23) Issues books for Faculty

3.24) Receives the book

3.25) Submits the book

According to the data flows, the student first deposits fees for library to the

Library Management System. The fees are then sent to Finance and fees

submission status is requested. Finance sends the library fees submission

status to Library Management System. Receiving the status, library card is

generated and issued to the student. After receiving the library card,

student request for book issue. Book issue request is sent to the librarian.

Librarian requests for the status of the availability of the book from the

Library Management System. Also the status of number of books issued by

the student is requested. Status is then sent to the librarian. Then librarian

issues book according to the status. Book is provided to the student.

Student then submits the book on, before or later the due date. The

submitted book is sent to the librarian. Librarian calculates the fine if any.

Then the fine details and submission status is sent back to the student from

the system. The student deposits the fine. The librarian receives the

deposited fine. The faculty also requests for issuing the library card to the

Library Management System. The library card issue request is sent to the

librarian. Librarian issues card for faculty. Then faculty receives the library

card. He then requests for book issue. The librarian receives the book issue

request for faculty. He then issues books for faculty. The faculty then

receives the book. After that he submits the book when required. In this

way, the Library Management System is depicted for identifying the data

Stores that are introduced in the Level 2 Data Flow

Diagrams.


Child Diagram - Course Management:

Figure: 11

Details of the Child Diagram for Course Management:

1) Entities:

Administration Body

Faculty Council

Department

2) Processes:

Course Management

Course

Management

Faculty

Council

1) Course setup and

details

4) Sends approval detail

Assign Start t ime and end time for

a course in a session Assign subject id

to subject

Administration

Body Department

2) Course setup details for

approval

3) Course setup details From

Faculty for Approval

5) Get the approval

from Administrator

6) Send approval

to Department

7) Approval

Status

Assign course id

to course

Assign subjects

to courses


3) Data Flows:

3.1) Course setup and details

3.2) Course setup details for approval

3.3) Course setup details From Faculty for Approval

3.4) Sends approval detail

3.5) Get the approval from Administrator

3.6) Send approval to Department

3.7) Approval Status

3.8) Assign course id to course

3.9) Assign subject id to subject

3.10) Assign subjects to courses

3.11) Assign Start time and end time for a course in a session

According to the data flows, at first course setup details are sent from the

department to the Faculty Council via course management system for

approval. Then Faculty Council sends these to Administration Body for

approval. Then the approval to Faculty Council is sent via Administration

Body. Then Faculty Council sends this approval status to Department.

Then Department sends the course id along with the subject id and course-

subject assignment detail to Course Management System. Then the

administration body sends the course start time and end time for a session

to the course management system. Based on these data flows data stores

have been shown in the level 2 DFD in the next phase.


Child Diagram - Faculty Management:

Figure: 12

Faculty Management

Administration

Body

Faculty Council

5) Send approval for

Faculty recruitment

7) Sends

Details

11) Allocates Role for

faculty

12) Provides Role Id

Department

14) Subject and project

assignment to Faculty

2) Faculty requirement

details for review

3) Reviewed list

4) Get the reviewed faculty requirement

list

Faculty

6) Recruitment

confirmation

8) Generate and send

the staff_ID

9) Recruited Faculty

Details

10) Recruited Faculty Details

9) Recruited

Faculty Details

1) Send Faculty

requirement details

15) Get the assignment

detail


Details of the Child Diagram for Faculty Management:

1) Entities:

Student

Faculty

Librarian

Finance

2) Processes:

Faculty Management

3) Data Flows:

3.1) Send Faculty requirement details

3.2) Faculty requirement details for review

3.3) Reviewed list

3.4) Get the reviewed staff requirement list

3.5) Send approval for Faculty recruitment

3.6) Recruitment confirmation

3.7) Sends Details

3.8) Generate and send the staff-ID

3.9) Recruited Faculty Details

3.10) Recruited Faculty Details

3.11) Allocates Role for faculty

3.12) Provides Role Id

3.13) Subject and project assignment to Faculty

3.14) Get the assignment detail

According to the data flows, at first faculty requirement details are sent

from the Department to the Faculty Management Process. Then it is sent to


the Faculty Council for review. Faculty Council sends the reviewed list to

the system. Then this reviewed faculty requirement list is sent to the

Administration Body for approval. Administration Body then sends the

approval. Then confirmation is send to the corresponding faculty for

recruitment. After that, faculty sends his details to the Faculty Management

System. Then Staff-id is generated by the system and it is then sent to the

faculty for his unique identity. The recruited faculty details are then sent to

the corresponding Department. At the same time role is allocated for the

faculty by the Administration Body. Then corresponding role-id is given to

the faculty. After all the processes are done, then subject or project

assignments are given to the faculty by the Department. Faculty receives

the assignment details from the Faculty Management System.

Thus, considering the above general data flows, the data stores are decided

and the details are given in the level - 2 DFD for Faculty Management in

the next phase.


Child Diagrams – Student Assessment:

Figure: 13

Student

Assessment Process

Student

Examination

Controller

Finance

Faculty

Department

4) E

xam

Ids an

d E

xam

inatio

n D

ate

1)

Subje

ct L

ist

4)

Req

ues

t fo

r P

aper

set

ter,

exam

inee

and E

xam

iner

Lis

t

5)

Lis

t of P

aper

set

ter,

exam

inee

and e

xam

iner

3) Examination Date

7) Q

uestio

n P

apers

8) Get the Question Papers

9)

Sen

d t

he

Sel

ecte

d p

aper

s

10)

Inst

ruct

ion f

or

form

fil

l up

and e

xam

fee

s su

bm

issi

on

13) Request the form

14) Request for eligibility checking

15) R

equest fo

r sessional m

arks an

d atten

dan

ce reco

rds

16) S

end th

e mark

s details

17)

Sen

d t

he

elig

ibilit

y st

atus

20) Get the form

21) Submit the form

along with exam fees

19)

Sen

d t

he

fees

cle

aran

ce s

tatu

s

18)

Req

ues

t fo

r co

urs

e fe

es s

ubm

issi

on

stat

us

22) Generate and send the exam roll id and

exam date

23) Submit exam papers

24) S

end th

e list of ex

amin

ers for ev

aluatio

n

25) S

end th

e pap

er for ev

aluatio

n

26) S

end th

e evalu

ated p

apers alo

ng w

ith m

arks

27) Provides approval for

publishing the result

28) Generates and

publishes the result

21.1

) S

end t

he

coll

ecte

d f

ees

to t

he

Fin

ance

Dep

artm

ent

12) Exam notice as per the

instruction

6) Appointment for paper setter and

evaluation

2) Get the subject list


Details of the Child Diagram for Student Assessment:

1) Entities:

Student

Faculty


Finance

Department

2) Processes:

Student Assessment

3) Data Flows:

3.1) Send the Subject List

3.2) Get the subject list

3.3) Send the Examination Date

3.4) Request for Paper setter, examinee and Examiner List

3.5) List of Paper setter, examinee and examiner

3.6) Appointment for paper setter and evaluation

3.7) Question Papers

3.8) Get the Question Papers

3.9) Send the Selected papers

3.10) Instruction for form fill up and exam fees submission

3.11) Get the Exam Ids and Examination Date

3.12) Exam notice as per the instruction

3.13) Request the form

3.14) Request for eligibility checking

3.15) Request for sessional marks and attendance records

3.16) Send the marks details

3.17) Send the eligibility status


3.18) Request for course fees submission status

3.19) Send the fees clearance status

3.20) Get the form

3.21) Submit the form along with exam fees

3.22) Generate and send the exam roll id and exam date

3.23) Submit exam papers

3.24) Send the list of examiners for evaluation

3.25) Send the paper for evaluation

3.26) Send the evaluated papers along with marks

3.27) Provides approval for publishing the result

3.28) Generates and publishes the result

3.29) Send the collected fees to the Finance

According to the data flows, at first the subject list is sent from the

department to the Examination Controller via the Student Assessment

process. Examination Controller then sends the examination date to the

Student Assessment process. Then request for paper setter, examinee and

examiner list comes to the Department and the Department sends the list.

According to the list appointment for paper setter and evaluation is sent to

the Faculty. Faculty sends the question papers to Examination Controller.

Examination Controller then sends the selected papers to the Student

Assessment process along with the instruction for form fill up.

Examination id and examination date is then sent to Department. The

student gets the examination notice as per the instruction and he then

requests for form. The Examination Controller is then requested for the

eligibility checking of the students to appear for the exam. The Faculty is

requested for sending the sessional marks and attendance record of the

students. Faculty sends the details requested. The Examination Controller

then sends the eligibility status and the Finance is request for sending the

course fees submission status. Finance sends the clearance. The student


then receives the form and then he submits the form along with the

examination fees. After that examination roll-id is generated and sent to the

student. The student then appears for the exam and submits the

examination papers. These papers are then sent to the list of examiners

among the faculties for evaluation. Examiners then send the evaluated

papers along with the marks. Examination Controller then provides

approval for publishing the result. The student then gets the result. The

examination fees submitted by the students are then sent to finance.

Thus, based on the above data flows for student assessment, data stores

have been depicted which are shown in the level 2 DFD for Student

Assessment process in the next phase.


Child Diagram – Admission Process:

Figure: 14

Details of the Child Diagram for Admission Process:

1) Entities:

4) Administration Body

5) Faculty Council

6) Department

7) KMR

8) Finance

9) Student

Admission

Administration

Body Student

KMR

Finance

5) Provides Details

6) Sends Details for

veri fication

Faculty Council

11) Fees Collection

1) Provides

instruction and

Information

7) Provide

Confirmation

8) Generates

and sends the Student Id

9) Provides

the student id 10) Deposits fees for

Admission and Registration

3) Selected

Candidate List

12) Clearance for Admission

14) Request

for Registratio

n

15) Provides Registration

id

Department

2) Sends Student Application

2)

Applications for

Candidates

13) Admitted

student list

4) Selected Candidate List


2) Processes:

10) Admission Process

3) Data Flows:

3.1) Provides instruction and Information

3.2) Applications for Candidates l

3.3) Selected Candidate List

3.4) Selected Candidate List

3.5) Provides Details

3.6) Sends Details for verification

3.7) Provide Confirmation

3.8) Generates and sends the Student Id

3.9) Provide Student id.

3.10) Deposits fees for Admission and Registration

3.11) Clearance for Admission

3.12) Admitted student list

3.13) Request for Registration

3.14) Provides Registration id

According to the data flows, at first the Administration Body provides the

information and instruction for admission. Then the application for

candidates comes to the Faculty Council. Faculty Council sends the

selected candidate list to the Admission Process. Then the selected

candidate list is sent to the Department. After that the selected students

provide their details to the Admission process. The KMR then sends the

details for verification. After receiving the request, Admission process

sends confirmation after verification. After receiving the confirmation KMR

generates and sends the student id for the student. Student id is then


provided to the student. Then the student deposits fees for admission and

registration. Collected fees are then sent to Finance. Finance then sends

clearance for admission. Finally the admitted student list is sent to the

Administration Body. After that KMR is requested for registration. KMR

generates and sends the registration id for the students.

Thus, based on the data flows for Admission process data stores have been

decided which is shown in the level 2 DFD for Admission Process in the

next phase.


Child Diagram –Financial Transaction Management:

Figure: 15

Details of the Child Diagram for Admission Process:

1) Entities:

Student

Faculty Council

Faculty

Finance

Department

Financial Transaction

Management

Student

Faculty

1)

Dep

osi

ts F

ees

for

sem

este

r

2)

Sen

d th

e re

ceip

t

Department

Request for Faculty information

Sends the faculty information

Provides the salary

Department wise

expenditure details

Faculty Council

Other development

Cost Details

Finance

Collected Fees

and other cost

details

Calculated

Reports and

clearance


2) Processes

Financial Transaction Management

3) Data Flows:

Deposits Fees for semester

Send the receipt

Request for Faculty information

Sends the faculty information

Provides the salary

Department wise expenditure details

Other development Cost Details

Collected Fees and other cost details

Calculated Reports and clearance

According to the data flows, the student submits the course fees and gets

the receipt from the Finance through Financial Transaction Management

process. The Finance requests the Department for the faculty detail and

provides salary to faculty after the department sends the faculty

information. Department wise expenditure details are sent from the

Department to the Financial Transaction Management Process. Other

development cost details are sent from the Faculty Council to the Financial

Transaction Management Process. The Finance gets the collected fees and

other details from the Financial Transaction Management Process and then

sends the calculated reports and provides clearance.

Based on the above data flows, data stores have been decided that are

shown in level 2 DFD for Financial Transaction Management process.


Specifications for Data Flow Diagram (Level - 2):-

All the entities for level 2 DFD are same as that of level1 DFD. The newly

added components are data stores according to which in and out data

flows of the data stores have been named as DSI and DSO respectively. For

entities, the data flow has been shown as two separate lines for input and

output for a single entity. The data flows have also been named according

to the entities with „I‟ or „O‟ at the end indicating input or output. The

number if inputs or outputs from a single entity have been shown along

with their names. To represent multiple lines, a slash has been used along

with the number beside the line.

Details for Library Management Data Flow Diagram (Level - 2):-

1) Entities:

Student

Faculty

Finance

Librarian

2) Process

Library Management

3) Data Stores

L_Card_Issue

Library_Code

Book_Issue_List

Subject_Material_Detail

Main_Book_List

Sub_Book_List


4) Data Flows:

The standards adopted while naming the data flows are described

as below:

SO: Output from the entity student


LO: Output from the entity Library





DSI1: Input to the data store Library_code

DSI2: Input to the data store Subject_Material_Detail

DSI3: Input to the data store Main_Book_List

DSI4: Input to the data store Sub_Book_List

DSI5: Input to the data store L_Card_Issue

DSI6: Input to the data store Book_Issue_List

DSO1: Output from the data store Library_code

DSO2: Output from the data store Subject_Material_Detail

DSO3: Output from the data store Main_Book_List

DSO4: Output from the data store Sub_Book_List

DSO5: Output from the data store L_Card_Issue

DSO6: Output from the data store Book_Issue_List

Description of the data flows:

SO:

SO1: Deposit Fees for Library

SO2: Request for Book

SO3: Submits book

SO4: Deposits fine if any


SI:

SI1: Generate Library Card-ID and Issues Library Card

SI2: Provide Book

SI3: Send fine details and submission status

LO:

LO1: Request the status of availability of the required book

LO2: Request the status of number of books issued by the

student

LO3: Issues Book according to availability and previous issue

status

LO4: Check submission date and calculates the fine if any

LO3: Issue Library Cards to Faculty

LO4: Issues books for Faculty

LI:

LI1: Book issue request

LI2: Sends Status

LI3: Sends Submitted Book

LI4: Receive deposited fine

LI3: Library Card Request for Faculty

LI4: Issue Library Cards

FNO:

FNO1: Sends library fees submission status

FNI:

FNI1: Send collected fess and request for library fees

submission status


FTO:

FTO1: Request for Library Card

FTO2: Request for Book

FTO3: Submits the book

FTI:

FTI1: Get the Library Card

FTI2: Get the Book

DSI:

DSI1: Code for Library

DSI2: Subject material details and issue details

DSI3: Main Book Details

DSI4: Sub Book Details

DSI5: Library card issue details

DSI6: Book Issue details and fine amount details

DSO:

DSO1: Library Code

DSO2: Status of subject material issue

DSO3: Main Book Details

DSO4: Sub Book Details

DSO5: Library card issue details

DSO6: Book availability status and fine amount


Library Management Data Flow Diagram (Level -2):-

Figure: 16

Library Management System

Student

Faculty

Librarian

Finance

L_Card_Issue Library_Code

Main_Book_List

Book_Issue_List

Sub_Book_List

Subject_Material_Detail

3FTO 2FTI

3SI

4SO

6LI

6LO

1FNO

1FNI

DSI5: Library card issue

details

DSO5: Library card issue

details

DSI1: Code

for Library

DSO1: Library

Code

DSI2: Subject material details

and issue details

DSO2: Status of

subject material issue

DSI3: Main

Book Details

DSO3: Main

Book Details

DSI4: Sub

Book Details

DSO4: Sub

Book Details

DSI6: Book Issue details and fine amount

details

DSO6: Book availability status and

fine amount


Details for Course Management Data Flow Diagram (Level - 2):-

1) Entities:

Faculty Council

Department

Administration Body

2) Processes:

Course Management

3) Data Stores:

Course

Subject

Department

Course_Session_Allocation

Course_Department_Rel

Subject_Course_Rel

Faculty_Council

Stipend_Detail

4) Data Flows:

The standards adopted while naming the data flows are described as

below:



DI: Input to the entity Department

DO: Output from the entity Department



DSI1: Input to the data store Faculty_Council


DSI2: Input to the data store Department

DSI3: Input to the data store Course

DSI4: Input to the data store Course_Department_Rel

DSI5: Input to the data store Subject

DSI6: Input to the data store Subject_Course_Rel

DSI7: Input to the data store Course_Session_Allocation

DSI7: Input to the data store Stipend_Detail

DSO1: Output from the data store Faculty_Council

DSO2: Output from the data store Department

DSO3: Output from the data store Course

DSO4: Output from the data store Course_Department_Rel

DSO5: Output from the data store Subject

DSO6: Output from the data store Subject_Course_Rel

DSO7: Output from the data store Course_Session_Allocation

DSO8: Output from the data store Stipend_Detail


AO:

AO1: Assign Start time and end time for a course in a session

AO2: Sends approval detail

AI:

AI1: Course setup details From Faculty for Approval

DO:

DO1: Assign subjects to courses

DO2: Assign course id to course

DO3: Assign subject id to subject

DO4: Course setup and details


DI:

DI1: Approval Status

FCO:

FCO1: Send approval to Department

FCI:

FCI1: Course setup details for approval

FCI2: Get the approval from Administrator

DSI:

DSI1: Faculty Council Details

DS2: Department detail

DSI3: Course Details

DSI4: Department wise course details

DSI5: Subject Details

DSI6: Course wise subject assignment

DSI7: Course start time and end time for session

DSI8: Stipend Information

DSO:

DSO1: Faculty Council Details

DSO2: Department id

DSO3: Course name and code

DSO4: Department wise course details

DSO5: Subject name and code

DSO6: Course wise subject details

DSO7: Course timing for a session

DSO8: Stipend detail with stipend id


Course Management Data Flow Diagram (Level -2):-

Figure: 17

Course

Management

Faculty

Council

Admin istration

Body Department

Course_Department_Rel


Faculty_Council

Department

Course

Subject

Subject_Course_Rel

1FCO

2FCI

4DO 1DI 2AO

1AI

DSI4:

Department wise

course details

DSO7:

Course timing for a

session

DSI7: Course

start t ime and end time for

session

DSO1: Faculty

Council Details

DSI1: Faculty

Council Details

DSI5: Subject

Details

DSO5: Subject

name and code

DSI3:

Course

Details

DSO3:

Course name

and code

DSO4:

Department wise course

details

DSI6: Course wise

subject assignment

DSO6: Course wise subject

details

DSI2:

Department detail

DSO2:

Department id

Stipend_Detail

DSI8: Stipend

information

DSO8: Stipend Detail

with stipend id


Details for Faculty Management Data Flow Diagram (Level -2):-

1) Entities:

Faculty Council

Faculty

Administration Body

Department

2) Processes

Faculty Management

3) Data Stores

Faculty_Information

Faculty_Contact_Detail

Faculty_Address_Detail

Faculty_Role

Role_Code

Administrative_Role_Allocation

P_Faculty_Lecture_Details

Post_Guide_Allot

Faculty_Subject_Allocation

Visiting_Faculty_Information

4) Data Flows:


below:










DSI1: Input to the data store Role_Code

DSI2: Input to the data store Faculty_Information

DSI3: Input to the data store Faculty_Address_Detail

DSI4: Input to the data store Faculty_Contact_Detail

DSI5: Input to the data store Faculty_Role

DSI6: Input to the data store Faculty_Subject_Allocation

DSI7: Input to the data store Administrative_Role_Allocation

DSI8: Input to the data store P_Faculty_Lecture_Details

DSI9: Input to the data store Post_Guide_Allot

DSI10: Input to the data store Visiting_Faculty_Information

DSO1: Output from the data store Role_Code

DSO2: Output from the data store Faculty_Information

DSO3: Output from the data store Faculty_Address_Detail

DSO4: Output from the data store Faculty_Contact_Detail

DSO5: Output from the data store Faculty_Role

DSO6: Output from the data store Faculty_Subject_Allocation

DSO7: Output from the data store


DSO8: Output from the data store P_Faculty_Lecture_Details

DSO9: Output from the data store Post_Guide_Allot

DSO10: Output from the data store Visiting_Faculty_Information


AO:

AO1: Send approval for Faculty recruitment

AO2: Allocates Role for faculty


AI:

AI1: Get the reviewed staff requirement list

AI1: Recruited Faculty Details

DO:

DO1: Send Faculty requirement details

DO2: Recruited Faculty Details

DI:

DI1: Recruited Faculty Details

FCO:

FCO1: Reviewed list

FCI:

FCI1: Faculty requirement details for review

FCI2: Recruited Faculty Details

FTO:

FTO1: Generate and send the staff-ID

FTI:

FTI1: Provides Role Id

FTI2: Recruitment confirmation

FTI2: Generate and send the staff-ID

FTI2: Get the assignment detail


DSI:

DSI1: Role code details

DS2: Information of faculty

DSI3: Address details of faculty

DSI4: Contact details of faculty

DSI5: Role allocation details for faculty

DSI6: Subject allocation details of faculty

DSI7: Administrative role Allocation details

DSI8: Number of lectures delivered by part time faculty

DSI9: Guide allocation details

DSI10: Visiting faculty details

DSO:

DSO1: Role code details

DSO2: Information of faculty

DSO3: Address details of faculty

DSO4: Contact details of faculty

DSO5: Faculty role

DSO6: Coordinator name for a subject

DSO7: Administrator name

DSO8: Number of lectures delivered by part time faculty

DSO9: Guide name

DSO10: Visiting faculty details


Faculty Management Data Flow Diagram (Level -2):-

Figure: 18

Faculty

Management

Faculty Council Administration

Body

Faculty Department

Faculty_Subject_

Allocation P_Faculty_Lecture_

Details

Visiting_Faculty_Information Post_Guide_Allot


Faculty_Address_Detail

Faculty_Information

Role_Code

Faculty_Contact_Detail

Faculty_Role

2AI

2AO

1FCO

2FCI

2DO

1DI 1FTO

4FTI

DSI7: Administrative role

Allocation details

DSO7: Administrator name

DSI8: Number of lectures delivered

by part t ime faculty

DSO8: Number of lectures

delivered by part t ime faculty

DSI6: Subject allocation

details of faculty

DSO6: Coordinator name for a subject

DSI9: Guide allocation

details

DSO9: Guide

name

DSI10: Visiting

faculty details

DSO10: Visiting

faculty details

DSI3: Address details of

faculty

DSO3: Address

details of faculty

DSO2: information of

faculty

DSI2: Information

of faculty

DSI1: Role

code details DSO1: Role code

details

DSI5: Role allocation details for

faculty

DSO5:

Faculty role

DSO4: Contact details of

faculty

DSI4: Contact details of

faculty


Details for Student Assessment Data Flow Diagram (Level -2):-

1) Entities:

Student

Faculty Council

Faculty

Administration Body

Finance


Librarian

KMR

Department

2) Processes

Student Admission

Library Management

Faculty Management

Student Assessment

Financial Transaction management

Academic

3) Data Stores

Grade_Detail_Semester

Marks_Obtained


Assesment_Detail

Attendence_Record

S_Exam_Roll_No


Grade_Detail

Grade_Detail_Course

Exam_Fees_Submission

LMS_Data

4) Data Flows:


as below:









ECI: Input to the entity Examination Controller

FECO: Output from the entity Examination Controller

DSI1: Input to the data store Assesment_Detail

DSI2: Input to the data store Exam_Fees_Submission

DSI3: Input to the data store S_Exam_Roll_No

DSI4: Input to the data store Semester

DSI5: Input to the data store LMS_Data

DSI6: Input to the data store Grade_Detail

DSI7: Input to the data store Attendence_Record

DSI8: Input to the data store Marks_Obtained

DSI9: Input to the data store Grade_Detail_Semester

DSI10: Input to the data store Grade_Detail_Course

DSO1: Output from the data store Assesment_Detail


DSO2: Output from the data store Exam_Fees_Submission

DSO3: Output from the data store S_Exam_Roll_No

DSO4: Output from the data store Semester

DSO5: Output from the data store LMS_Data

DSO6: Output from the data store Grade_Detail

DSO7: Output from the data store Attendence_Record

DSO8: Output from the data store Marks_Obtained

DSO9: Output from the data store Grade_Detail_Semester

DSO10: Output from the data store Grade_Detail_Course


ECO:

ECO1: Send the Examination Date

ECO2: Send the list of examiners for evaluation

ECO3: Provides approval for publishing the result

ECO4: Send the eligibility status

ECO5: Instruction for form fill up and exam fees submission

ECO6: Send the Selected papers

ECI:

ECI1: Get the subject list

ECI2: Get the Question Papers

ECI3: Request for eligibility checking

SO:

SO1: Request the form

SO2: Submit the form along with exam fees

SO3: Submit exam papers


SI:

SI1: Exam notice as per the instruction

SI2: Get the form

SI3: Generate and send the exam roll id and exam date

SI4: Generates and publishes the result

DO:

DO1: Send the Subject List

DO2: List of Paper setter, examinee and examiner

DI:

DI1: Get the Exam Ids and Examination Date

DI2: Request for Paper setter, examinee and Examiner List

FNO:

FCO1: Send the fees clearance status

FNI:

FCI1: Request for course fees submission status

FCI2: Send the collected fees to the Finance

FTO:

FTO1: Send the evaluated papers along with marks

FTO1: Send the marks details

FTO1: Sends the Question Papers

FTI:

FTI1: Send the paper for evaluation

FTI2: Request for sessional marks and attendance records

FTI3: Appointment for paper setter and evaluation


DSI:

DSI1: Assessment details

DS2: Examination fees detail and submission detail

DSI3: Examination roll number of the students

DSI4: Semester code and description

DSI5: LMS access details for the students

DSI6: Grade and corresponding points detail

DSI7: Attendance record of the students

DSI8: Marks obtained in each subject by each student

DSI9: Semester wise grade detail of the students

DSI10: Grade obtained by the students in the course

DSO:

DSO1: Assessment details

DSO2: Exam fees submission status

DSO3: Examination roll number

DSO4: Semester code and description

DSO5: LMS access details for the students

DSO6: Grade and corresponding points detail

DSO7: Attendance record of the students

DSO8: Marks for each subject

DSO9: Result of the students in semester

DSO10: Grade of the student in a course


Student Assessment Data Flow Diagram (Level -2):-

Figure: 19

Student

Assessment Process

Examination

Controller

Student

Finance Faculty

Department

Marks_Obtained

Semester

Assesment_Detail

Exam_Fees_Submission

Attendence_Record

Grade_Detail_Semester

Grade_Detail LMS_Data

Grade_Detail_Course

S_Exam_Roll_No

6ECO

3ECI 1FNO

2FNI

2DO

2DI

3FTO

3FTI

3SO

4SI

DSO8: Marks for

each subject

DSI8: Marks obtained in each subject by each

student

DSO9: Result of the students in semester DSI9: Semester wise grade detail of the students

DSI1: Assessment

details

DSO1: Assessment details DSI7: Attendance record

of the students

DSO7: Attendance

record of the students DSI4: Semester code and description

DSO4: Semester code and

description

DSO3: Examination roll

number

DSI3: Examination roll

number of the students

DSO6: Grade and

corresponding points detail

DSI6: Grade and corresponding points

detail

DSI2: Examination fees

detail and submission detail

DSO2: Exam fees

submission status

DSO5: LMS access

details for the students

DSI5: LMS access details

for the students

DSO10: Grade of the student in a course

DSI110: Grade obtained by

the students in the course


Details for Admission Data Flow Diagram (Level -2):-

1) Entities:

Student

Faculty Council

Administration Body

Finance

KMR

Department

2) Processes

Student Admission

3) Data Stores

Registration_Detail_Hist

Registration_Detail

Student_Contact_Detail

Student_Stipend_Issue_Detail

Student

Student_Admission_Detail

Student_Qualification_Detail

4) Data Flows:


as below:












KI: Input to the entity KMR

KO: Output from the entity KMR

DSI1: Input to the data store Student

DSI2: Input to the data store Student_Contact_Detail

DSI3: Input to the data store Student_Qualification_Detail

DSI4: Input to the data store Student_Admission_Detail

DSI5: Input to the data store Student_Stipend_Issue_Detail

DSI6: Input to the data store Registration_Detail

DSI7: Input to the data store Registration_Detail_Hist

DSO1: Output from the data store Student

DSO2: Output from the data store Student_Contact_Detail

DSO3: Output from the data store Student_Qualification_Detail

DSO4: Output from the data store Student_Admission_Detail

DSO5: Output from the data store Student_Stipend_Issue_Detail

DSO6: Output from the data store Registration_Detail

DSO7: Output from the data store Registration_Detail_Hist


AO:

AO1: Provides instruction and Information

AI:

AI1: Admitted student list


DO:

DO1: Sends Student Application

DI:

DI1: Selected Candidate List

FCO:

FCO1: Selected Candidate List

FCI:

FCI1: Applications for Candidates

KO:

KO1: Generate and sends the Student Id

KO2: Provide Confirmation

KO3: Provides Registration id

KI:

KI1: Sends Details for verification

FNO:

FNO1: Clearance for Admission

FNI:

FNI1: Fees Collection

SO:

SO1: Provides Details

SO1: Deposits fees for Admission and Registration


SI:

SI1: Provides the student id

DSI:

DSI1: Student detail

DS2: Contact details of the students

DSI3: Student qualification detail

DSI4: Student admission detail

DSI5: Stipend detail of the student

DSI6: Registration number of the students

DSI7: Details of the previous student id associated with

registration number for a student

DSO:

DSO1: Student detail

DSO2: Contact details of the students

DSO3: Student qualification detail

DSO4: Student admission detail

DSO5: Stipend detail of the student

DSO6: Registration number of the students

DSO7: Number of student ids for a registration number


Admission Process Data Flow Diagram (Level -2):-

Figure: 20

Admission Administration

Body

Faculty Council Finance

Student KMR

Department

Registration_Detail Student_Contact_Detail

Student

Student_Admission_Detail

Student_Qualification_Detail

Registration_Detail_Hist

Student_Stipend_Issue_Detail

3KO

1KI

1SI

2SO

1AO

1AI

1FCO

1FCI

1DI

1DO

1FNI

1FNO

DSO7: Number of student ids

for a registration number DSI7: Details of the previous student id associated

with registration number for a student

DSO6: Registration

number of the students

DSI6: Registration number of the

students

DSI2: Contact details of the

students

DSO2: Contact details

of the students

DSO4: Student

admission detail

DSO5: Stipend detail of the

student

DSI4: Student admission

detail

DSI5: Stipend detail of the

student DSI3: Student qualification

detail DSO3: Student qualification

detail

DSO1: Student

detail

DS1I: Student

detail


Details for Financial Transaction Management Data Flow Diagram

(Level-2)

1) Entities:

Student

Faculty Council

Finance

Department

Faculty

2) Processes

Financial Transaction Management

3) Data Stores

Salary_P_Faculty

Course_Fees_Detail

Other_Development_Cost

Total_Revenue

Salary_F_Faculty

4) Data Flows:


below:












DSI1: Input to the data store Course_Fees_Detail

DSI2: Input to the data store Salary_F_Faculty

DSI3: Input to the data store Other_Development_Cost

DSI4: Input to the data store Salary_P_Faculty

DSI5: Input to the data store Total_Revenue

DSO1: Output from the data store Course_Fees_Detail

DSO2: Output from the data store Salary_F_Faculty

DSO3: Output from the data store Other_Development_Cost

DSO4: Output from the data store Salary_P_Faculty

DSO5: Output from the data store Total_Revenue


DO:

DO1: Sends the faculty information

DO1: Department wise expenditure details

DI:

DI1: Request for Faculty information

FCO:

FCO1: Other development Cost Details

FCI:

FCI1:


FNO:

FNO1: Calculated Reports and clearance

FNI:

FNI1: Collected Fees and other cost details

SO:

SO1: Deposits Fees for semester

SI:

SI1: Send the receipt

FTI:

FTI1: Provides the salary

DSI:

DSI1: Course Fees collection detail

DS2: Salary details for permanent faculty

DSI3: Other development cost details

DSI4: Salary details for part time faculty

DSI5: Total revenue details

DSO:

DSO1: Course fees submission status of the students

DSO2: Salary details for permanent faculty

DSO3: Other development cost details

DSO4: Salary details for part time faculty

DSO5: Total revenue details


Financial Transaction Management Data Flow Diagram (Level -2):-

Figure: 21

Financial Transaction

Management

Student Department

Faculty Council

Faculty

Course_Fees_Detail Other-Development_Cost

Salary_P_Faculty

Salary_F_Faculty

Total_Revenue

1SI

1SO

1FCO

1FCI

2DI

1DO

1FTI

Finance 1FNI

1FNO

DSO1: Course Fees collection

detail

DSI1: Course fees submission status of the

students

DSO3: Other development

cost details

DSI3: Other development

cost details

DSI2: Salary details for permanent

faculty

DSO2: Salary details

for permanent faculty

DSI5: Total revenue

details

DSO5: Total

revenue details

DSI4: Salary details for part

t ime faculty

DSO4: Salary details for part t ime

faculty


4.2.3 Part – Three: Detection of Entities

In this phase of design, consolidating the ideas from requirement analysis

and the DFD, eight subject areas and corresponding entities have been

decided that will act as the backbone for the integrated data model as given

below:

Subject Area

Name and

Functionality

Entity Name Functionality

Academic

( This subject

area is for

storing the

academic

information

like course,

subject etc)

Course For storing course related

information along with course id.

Subject For storing subject related

information along with subject id.

Department For storing department related

information along with department

id.

Course_Department_Rel To maintain relation between course

and department.

Course_Session_Allocation To indicate course start and end

time for a session

Subject_Course_Rel For maintaining course wise subject

allocation

Faculty_Council For storing faculty council

information.

Student

( This subject

area is for

storing

student

details)

Student For storing student information

Student_Contact_Detail For storing student‟s contact details.

Student_Qualification_Detail For storing student‟s qualification

details.

Student_Admission_Detail For storing student‟s admission

related information.

Student_Stipend_Issue_Detail For storing student‟s stipend issue

related information.

Stipend_Detail For storing the stipend related

information in the institute.


Student

Assessment

( This subject

area is for

storing

student

assessment or

examination

details)

Assessment_Detail For storing Assessment related

information

Semester For storing semester id and name.

Grade_Detail_Semester For storing marks obtained by each

student in a particular semester for a

course.

S_Exam_Roll_No For storing examination roll number

of the students.

Grade_Detail_Course For storing the grades obtained by

each student in a course.

Marks_Obtained For storing marks obtained by each

student in each subject of a semester

for a course.

LMS_Data For storing necessary information

extracted from LMS.

Grade_Detail For storing the grade point related

information

Attendence_Record For storing attendance records of the

students.

Exam_Fees_Submission For storing exam fees submission

status of the students.

Faculty

( This subject

area is for

storing

faculty

information)

Faculty_Information For storing faculty information.

Faculty_Contact_Detail For storing Faculty‟s contact

information

Faculty_Role_Allocation For maintaining faculty‟s

designation and responsibility

details.

Administrative_Role_Allocation For maintaining different

administrator‟s details.

Visiting_Faculty_Information For storing visiting faculty‟s

information.

P_Faculty_Lecture_Details For tracking number of lectures

delivered by part time faculty.

Post_Guide_Allot For storing details of post

graduation guide allocation


Faculty_Role For storing the role id and

corresponding details.

Faculty_Subject_Allocation For maintaining the subject lists

assigned to a faculty.

Finance

( This subject

area is for

storing the

financial

transaction

related

information)

Course_Fees_Detail, For storing the course fees given by

students according to each semester.

Salary_P_Faculty For storing the salary issue details to

the part time faculty.

Other_Development_Cost For storing other development cost

for organizing a course.

Total_Revenue For storing the total revenue details.

Salary_F_Faculty For storing salary issue details to the

permanent faculty.

Library

(This subject

area is for

storing

information

related to

library)

Main_Book_List For storing distinct book details

L_Card_Issue For storing library card issue details

Sub_Book_List For storing individual book details

according to main book list.

Book_Issue_List For storing the book issue details.

Library_Code For storing the code for library.

Subject_Materil_Detail For storing the subject material ids

and corresponding issue details.

KMR

(KMR stands

for Key

Muster Rolls.

This subject

area is for

storing

Registration_Detail For storing the registration details of

the students. This table will be

updated with the student id if the

student gets admission in the

university for other courses. This

table will store the registration id

along with current student id.


registration

details of the

students)

Registration_Detail_Hists For storing the registration details

history of the students. This table

will be populated if the student gets

another admission in the same

university for different course. Then

the student id will be changed for

that student and the old student id

along with the registration number

will be populated in this table. This

is for tracking the statistics of having

multiple courses under same

university.

General ( This subject

area is for storing

information that is

required by

all the other subject areas)

Session_Detail For storing the session id and the session information like 2008-09.

Month For storing the month details along

with month id and number of days in that month according to different

years.


The subject areas and corresponding entities are shown as a conceptual

diagram as below:

Figure: 22 A Conceptualize View of Entity Details Along With Subject

Areas

In the above diagram, the subject areas are shown in the oval shaped objects and

corresponding entities are shown in the rectangular objects with separate colors.

Student

Finance

Student

Assessment

Registration_Detail

Registration_Detail_Hists

Assessment_Detail,

Semester,

Grade_Detail_Semester,

Semester,

S_Exam_Roll_No,

Grade_Detail_Course,

Marks_Obtained,

LMS_Data, Grade_Detail,

Attendence_Record,

Exam_Fees_Submission,

Marks_Before_Review

Course_Fees_Detail,

Salary_p_Faculty,

Other_Development_Cost,

Total_Revenue,

Salary_F_Faculty

Main_Book_List, L_Card_Issue,

Sub_Book_List, Book_Issue_List,

Library_Code,

Subject_Materil_Detail

Student, Stipend_Detail

Student_Contact_Detail,

Student_Qualification_Detail,

Student_Admission_Detail,

Student_Stipend_Issue_Detail,

KMR

Academic

Library

Session_Detail,

Month

Faculty

Faculty_Information,

Faculty_Contact_Detail,

Faculty_Role_Allocation,

Post_Guide_Allot, Faculty_Role,

Faculty_Subject_Allocation,

Administrative_Role_Allocation,

Visiting_Faculty_Information,

P_Faculty_Lecture_Details,

Role_Code

Course, Subject,

Department,

Course_Department_Rel,

Course_Session_Allocation,

Subject_Course_Rel,

Faculty_Council

General


In accordance with the above diagram, conceptual views of the schemas and

corresponding table details have been visualized. In this diagram, the relation

between the schemas has been shown with arrows indicating the shared tables

among them. The schemas along with their entities are shown in the can shaped

objects. The shared tables of any particular schema are shown via the oval shaped

objects. The source schemas for these shared tables are shown via arrows with

proper color as per the target schema. The schema names have been decided as

per the subject area names as below:

Academic

Library

Student

Student Assessment

Finance

KMR

Faculty

General

Apart from the other schemas, the General schema contains two independent

tables among which the Session_Detail will be shared by all the other schemas. So,

it is not shown explicitly in the diagram. Another one, Month table will be shared

by Finance schema. Apart from the two tables along with the General schema, all

the other schemas and their corresponding shared tables are shown via a diagram

in the next page. The direction of arrow indicates the flow of information from

source schema to target schema.


A conceptual diagram of the schemas in the integrated repository is given below:

Figure: 23

Assessment_Detail, Semester, Grade_Detail_Semester,

S_Exam_Roll_No, Grade_Detail_Course, Marks_Obtained, LMS_Data, Grade_Detail,

Attendence_Record, Exam_Fees_Submission, Marks_Before_Review

Course, Subject, Department, Course_Department_Rel,

Course_Session_Allocation,

Subject_Course_Rel,

Faculty_Council

Main_Book_List, L_Card_Issue, Sub_Book_List, Book_Issue_List,

Library_Code,

Subject_Materil_Detail

Student, Student_Address, Student_Contact_Detail,

Student_Qualification_Detail, Student_Admission_Detail,

Stipend_Detail, Student_Stipend_Issue_Detail

Course_Fees_Detail, Salary_p_Faculty, Other_Development_Cost, Month,

Total_Revenue, Salary_F_Faculty

Faculty_Information, Faculty_Contact_Detail,

Faculty_Role_Allocation, Role_Code, Post_Guide_Allot, Faculty_Role, Faculty_Subject_Allocation, Administrative_Role_Allocation,

Visiting_Faculty_Information,

P_Faculty_Lecture_Details

Registration_Detail Registration_Detail_Hist

Academic

Library

Student_Assessment

Student

KMR

Faculty

Session_Detail,

Semester,

Student, Subject


Subject, Course,

Faculty_Information, Student

Student

Course,

Semester

Semester, Department,

Student, Course,


Department, Student, Course, Faculty_Council,

Subject

Finance


4.3 Implementation

The implementation part contains the actual data model incorporating the

entity details and along with their attributes and relations between them.

Strategy for Implementation:

The most critical part of this implementation was to find out all the attributes

necessary for e-governance in the university and the relation among the

attributes to construct the integrated data model.

To overcome such difficulties, the following strategy has been adopted:

At first the data model has been subdivided into different subject

areas as detected in the design phase.

Attributes of each entity in a specific subject area have been decided

along with their significance so that unique identifier of any particular

entity can be decided.

Relation among the entities in a particular subject area has been

decided so that foreign keys can be decided for each of the entities.

Shared entities from each schema have been detected while defining

the relationship among them. Thus integrity and atomicity is

maintained in the model.

Combining the individual subject areas, the integrated data model has

been constructed.


Along with the integrated one, data model has also been shown for the

following:

Academic

Student

Student Assessment

Finance

Library

Faculty

General

KMR

The integrated data model named as “Main” is shown in the next page as a

combination of these subject areas. The data model for individual subject

areas along with their description are given in the subsequent pages.


Data Model for Subject Area: Main

Figure: 24 All the attributes along with PK – FK relationship are also shown in the

model for individual subject areas.

This integrated data model comprises of different subject areas for which the

detailed description is given along with the model in the coming sections.


Data Model for Subject Area: Academic

Figure: 25

Description:

The entities directly monitored by Academic will be Department, Subject,

Course, Subject_Course_Rel, Faculty_Council, Course_Session_Allocation,

Course_Department_Rel. Apart from these the required entities from other

subject area will be Session_Detail from General, and semester from

Student_Assessment.

In the subject area Academic, the details for various courses, their subjects,

different departments and their relations are shown via primary key(PK) and

foreign key(FK) relationship. Course will contain the details related to

courses with a unique identifier course_id, course name, duration, course

mode, approval detail, degree associated with the course and total

expenditure. Also there will be an active_flag to indicate if the course is still


valid. In this way history data about courses can be tacked. Subject details

such as subject id, subject name and subject type i.e. theory or sessional for

these courses are stored in the subject table.

The Subject_Course_Rel table contains the relationship between the course

and the subject. Here, for a single course id there will be multiple subject id

for a particular semester and in a particular session. The semester id will be

taken from the semester table of Student Assessment schema. The course id

and the subject id can be repeated in different session id. The session id is

taken from Session_Detail table of General schema.

Similarly course start time and end time for different courses will be kept in

the table Course_Session_Allocation for different session id. This start time

and end time will be different for different phases of the course. It will be

mentioned as per first year or second year as per the course curriculum and

course duration. There will be many to many relation between course and

session entity, as a single course will be assigned under different sessions

like 2007, 2008 etc. Similarly a single session will have multiple courses

under it.

Department table will contain the department name and department id as

unique identifier for each department. This table will also contain the faculty

council id that is to be taken from Faculty_Council table. Theis table contains

the faculty council id and name line Engineering or Science etc.

The Course_Department_Rel table will be used to specify the relation

between course and department, which is many to many. A single course

will be assigned to a particular department in a particular session. So, for a

particular session id there will a single entry for a course id and multiple

entries for the department id. A single department can have multiple courses


but a single course will be assigned to a single department only in a

particular session.

In this way academic information can be kept in a manner so that current

data and history data can be stored in an efficient and useful way to generate

necessary information.

Subject Area: Student

Figure: 26


Description:

The entities directly monitored by Student subject area are Student,

Student_Contact_Detail, Student_Qualification_Detail,

Student_Admission_Detail and Student_Stipend_Issue_Detail and

Stipend_Detail. Apart from these the required entities from other subject

area will be Semester from Student Assessment, Course from Academic and

Session_Detail from General.

Student entity will contain the student details like student name, date of

birth, monthly family income etc. along with the unique identifier student id

for each student which is the class roll number for a particular student. This

will be derived from the following:

x - Admission Type (New or readmission)

x - Admission Mode (Regular or distance)

xx - year of admission

xxx - Course id

xxx - Faculty id

xxx - unique number among the students

Student_Contact_Detail will contain the contact information related to

students. Contacts will be separated by particular contact ids. For a single

student, there will be a single contact id. If grant for the student table is

required from any other subject area then it can be given without sharing the

personal address or contact details. The student table contains the contact id

as a foreign key.

Student_Qualification_Detail table is for storing the student qualification

details. There will be a unique identifier qualification id in the

Student_Qualification_Detail table for each student that will different for


different student id. The student table will contain this qualification id as a

foreign key in the student table.

Student_Admission_Detail stores the admission detail like date of

admission, session id, course id, admission mode and necessary charges

collected while admission from each student. This table contains the relation

between the student and the course entity for a particular session. If a

student gets registered for a particular course in a session, and later changes

the course, then another new row will be inserted into the table for that

student with different student id.

Stipend_Detail stores the information regarding various kinds of stipends

available with their corresponding unique id. This table also stores the

information regarding stipend amount, frequency of issue that is monthly or

yearly etc along with the eligibility criteria. Student_Stipend_Issue_Detail

contains the stipend issue details for the students who are eligible for it. The

stipend amount and the issue date with issue status are stored for a

particular student id with active flag to indicate the current record.


Subject Area: Faculty

Figure: 27

Description:

The entities directly monitored by Faculty are Faculty_Information,

Faculty_Address_Detail, Faculty_Contact_Detail, Faculty_Role_Allocation,

Post_Guide_Allot, Faculty_Role, Faculty_Subject_Allocation, Role_Code

Administrative_Role_Allocation, Visiting_Faculty_Information and

P_Faculty_Lecture_Details.Apart from these the required entities from other

subject area are Session_Detail and Month from General, Department and

Subject from Academic and Student from Student.


The Faculty_Information table contains the information about the faculty like

faculty name, qualification etc.The Faculty_Contact_Detail is for storing

contact details of faculty with a unique contact id for each faculty. The

Faculty_Information table will contain this contact id as a foreign key against

the individual staff_id indicating the relation between the faculty and his

contact.

The P_Faculty_Lecture_Details table contains the number of lectures given

by a particular part time faculty for a subject in a month for a session

indicated by month key and session id with staff id and corresponding

subject id.

The Role_Code contains the different roles or designation assigned to faculty

and unique identifier for that role as role code id. The same role id can be

shared by different faculties and at the same time more that one role can be

assigned to any individual faculty. These details are stored in Faculty_Role

table where staff id is assigned with individual role code id for a particular

department in a session along with role start date and end date. The active

flag will indicate whether the faculty is still active in that role or not.

The Administrative_Role_Allocation is for storing the administrative role

code id and corresponding staff id along with the division that will indicate

the faculty council or department for which the role is assigned along with

active flag to indicate the current assignment.

The Post_Guide_Allot table is for maintaining the guide allocation details for

postgraduate students along with start date and end date. The active flag

will indicate whether the guide is still allotted for that particular student.

This table will contain the staff id and student id and session id as foreign

key for maintaining the relation.


Faculty_Subject_Allocation table contains the staff id and subject id along

with the session id as foreign keys for denoting the subject allocation for

faculty. This table also maintains the allocation start date and end date. Any

particular faculty can be assigned multiple subjects. So, for a staff id, there

can be multiple subject id. Similarly, same subject id can be assigned to

multiple faculties at the same time. So, the relation between faculty and

subject is many to many. The Visiting_Faculty_Information table contains

the information of visiting staffs with visitor id as the unique identifier for

each visiting faculty.

Subject Area: Student Assessment

Figure: 28


Description:

The entities directly monitored by Student Assessment are

Assessment_Detail, Semester, Grade_Detail_Semester, S_Exam_Roll_No,

Grade_Detail_Course, Marks_Obtained, LMS_Data, Grade_Detail,

Attendence_Record and Exam_Fees_Submission. Apart from these the

required entities from other subject areas are Session_Detail from General,

Subject and Course from Academic Student from Student and

Faculty_Information from Faculty.

All the assessment details including the sessional exam and semester exam

details are stored in the Asesment_Detail table with unique identifier

assessment id for each assessment along with assessment start date and end

date. The subject id and semester id (if required) acts as the foreign key in

this table for maintaining the relation of assessment id with subject and

course. This table also contains the assessment summary along with the

assessment type indicating weekly, monthly, sessional evaluation or

semester exam. The A_Mode field is for indicating whether the assessment is

for supplementary or regular exam. The marks obtained by the students for

these assessments are stored in the Marks_Obtained table for a particular

student id along with assessment id and session id. The subject id, semester

id and course id are also included in this table as foreign keys so that

reporting tasks becomes easier. As, after population, this will be larger

compared to other tables so, to reduce access time for reporting, the above

foreign keys are included. This table also contains the field review which

contains a review id that will be generated if the student requests for review.

This id will be populated into another table along with the other details

which will contain the marks before and after review against that particular

id. The changed marks will be updated in the Marks_Obtained table. In this

way, history data maintenance will be easier. The status field is for denoting


the status failed or passed. The Attempt field is to denote the number of

attempts made by the student to pass the exam or assignment of a particular

subject id in a semester. In different attempts, the assessment id will be

different, but the attempt filed will be updated accordingly to track the

marks obtained in the regular or supplementary exam.

Re_Assessment_Allowed field denotes if reassessment is allowed for the

student for that particular assignment id. This will be decided according to

the attempt field. If attempt field reaches the maximum limit for appearing

in an exam, them reassessment will not be allowed further.For more that one

attempt, the marks obtained in the maximum attempt will be considered for

a particular subject id, course id and session id.

The Semester table will contain the unique identifier for each semester as

semester id and the name of that semester.

The Grade_Detail_Semester table contains the Semester grade points average

or SGPA of each student for a particular semester. The semester id, session id

and student id are foreign keys here to denote SGPA obtained by the student

uniquely. Status field denotes three kind of states i.e. X for failed, XP for

passed with blockage and P for passed. The end_date is the end date of the

semester and the completion date is the date when the status becomes P.

The Grade_Detail_Course table contains the DGPA (Degree Grade Point

Average) along with percentage of marks obtained by each student for a

particular course id in a session. The status field denotes if the course is

completed or not by the student. Here end_date denotes the date when the

student completes the course.

The S_Exam_Roll_No table contains the exam roll number of the students

with respect to a particular student id, course id and semester id for a session

id that are the foreign keys in this table.


The attendance records of the students are maintained by the

Attendence_Record table where attendance of each student will be kept for a

particular student id, session id, semester id and subject id that are the

foreign keys in this table.

The meaning of the grade points given to the students for the assignments

are kept in the Grade-Detail table that contains the grade and corresponding

grade point with percentage of marks obtained for that grade and

performance according to that drage.

The LMS_Data table contains the unique identifier st_code for a particular

student id, subject id and session id to maintain the login date and the

duration spent by the student in accessing the LMS for any particular

subject.

The Exam_Fes_Submission table contains the individual fees details

submitted by the student for a semester in a session. Also along with

semester fees submitted for any particular paper or assignment are also

maintained here with completion status. The last date of fine submission

and form fill up are stored here optionally.

In this way, the student assessment details are stored in a structured and

convenient way.


Subject Area: Library

Figure: 29

Description:

The entities directly monitored by Library will be Main_Book_List,

L_Card_Issue, Sub_Book_List, Book_Issue_List, Library_Code,

Subject_Materil_Detail. Apart from these the required entities from other

subject area will be Session_Detail from General, and Student from Student,

Subject from Academic and Faculty_Information from Faculty.

The Library_Code table contains the code for the libraries i.e. main library or

departmental library etc with unique identifier l_code.

The L_Card issue table contains the library card issue details with unique

identifier as card number or L_Card_Id for faculty and the students. With

card submission date and active flag to indicate if the card is still valid


against that particular student id or staff id. The student id, staff id and

session id will be the foreign key in this table.

The Main_Book_List contains the individual book details along with unique

identifier M_Book_Id for each book and corresponding book title, subject,

author, publisher and number of copy for that particular type of book.

The Sub_Book_List contains the unique identifier S_Book_Id for each copy of

a particular type of M_Book_Id that is the foreign key in this table. This table

also contains the L_Code as a foreign key to indicate the location of that book

along with its edition, price and availability status for issue.

The Book_Issue_List table contains the book issue details along with

L_Card_Id against which the book is issued and issue date, due date,

submission status, fine if applicable and fine submission status. According to

the book issue details in this table, the corresponding availability status will

be updated in the Sub_Book_List table.

The Subject_Material_Detail table contains the subject material details and

the issue status of that material with unique identifier material id along with

subject id as the foreign key in this table.This table also contains the issue

date and the number of material with material type i.e. CD or DVD etc.

.


Subject Area: Finance

Figure: 30

Description:

The entities directly monitored by Finance will be Course_Fees_Detail,

Salary_p_Faculty, Other_Development_Cost, Total_Revenue,

Salary_F_Faculty. Apart from these the required entities from other subject

area will be Session_Detail and Month from General, and semester from

Student_Assessment, Student from Student, Faculty_Information from

Faculty and Course and Department from Academic.


Course_Fees_Detail will contain the course fees submission details of a

student for a particular semester id, course id and session id that are the

foreign keys in this table. The total fees submitted by the student with due

amount are also kept in this table along with the fees submission status. This

status will be complete or incomplete according to amount of submission of

the total fees of a particulars semester. Fees_Sub_Date will be updated

according to fees submission.

The Salary_F_Saculty table contains the salary details of the permanent

faculties according to month and corresponding year. The staff id, month

key, department id and session id are the foreign keys for this table.

The Salary_P_Faculty table contains the salary details of the part time

faculties for a particular staff_id, department_id, month id and session id

that are the foreign keys in that table.

The Other_Developemnt_Cost table contains the corresponding departments

and session information will be stored to keep track of the expenditure of

that particular department.

Other_Development_Cost will contain the details of the extra development

costs according to department, course and session and month. The

corresponding ids are the foreign keys in this table.

Total_Revenue table will be used to keep track of the total expenditure and

revenue according to a particular month and corresponding year.


Subject Area: KMR

Figure: 31

Description:

The entities directly monitored by KMR will be Registration_Detail

Registration_Detail_Hist. Apart from these the required entities from other

subject area will be Session_Detail from General and Student from Student.

The Registration_Detail contains the registration id for a particular student

along with student name and student id, session id and date of registration.

This registration id will remain same for all the other courses attained by the

student in the same university. So, if the student gets admitted in another

course then a new student id will be assigned to him. Then this

Registration_Detail table will be updated with that new student id and

before updating, the old record for that registration id will be moved to

another table called Registration_Detail_Hist. Thus the history record will be


kept for a student availing multiple courses under same university. The

Active_Flag denotes if the student id for that registration id is still active or

not. So, in the Registration_Detail table the active_flag will be „Y and in the

Registration_Detail_Hist table, the active_flag will be „N‟ for all the records.

Subject Area: General

Figure: 32

Description:

The entities directly monitored by General are Session_detail and Month.

These two tables are used by all the other subject area for their respective

purposes. The Session_detail table contains the session id and session

description The Month table contains the month key as unique identifier for

each month along with the month id, corresponding year, month name and

total days in that month.

This model has been build using the data modeler tool ERwin version 7.2.

And reports have been generated using some test data that have been

prepared using the reporting tool BO (Business Object).

The individual table details for the entire model are given in the Appendix

section in Appendix I for reference.


5 RESULTS AND INTERPRETATIONS:

In this phase, at first the integrated data model has been physically

implemented into the database with Oracle 10g as backend and been divided

into eight schemas according to the subject areas. Then, some standard

reporting needs have been considered as per the requirement analysis and test

cases have been organized according to that. The result has been obtained in

two different modes:

Through custom query via SQL with Oracle 10g as a backend

database.

Using BO reporting tool as front end with the help of pre

organized reporting templates with Oracle 10g as a backend

database.

Some of the snapshots of the results both from SQLPLUS and BO are given in

the Appendix section in A III.

5.1 Result

Test Case 1:

To check whether the student is promoted or not to the next

semester so that examination form can be provided to him

Result:

Custom query:

Select student_id, Session_id, Semester_id, promoted from Grade_Detail_Semester where student_id='0009002011002' and semester_id=1 and session_id='2009-10';


Via BO:

Test Case 2:

To check whether fees submission for the semester is complete or

not.

Result:

Custom query (For a particular student):

select student_id, course_id, semester_id, session_id, Status_Fees_Submission from finance.Course_Fees_Detail where student_id='0009002011003' and semester_id=2

and session_id='2009-10';

Custom query (For all students of a particular course):

select student_id, course_id, semester_id, session_id, Status_Fees_Submission from finance.Course_Fees_Detail where semester_id=2

and session_id='2009-10';


Via BO (For a particular Student):

Via BO (For all the student of a particular course):

Test Case 3:

To check whether the student is eligible to appear for the

supplementary exam or he has covered the maximum chances

for the exam.

Result:

Custom query:

select student_id, course_id, session_id, semester_id, Re_Assessment_Allowed from Marks_Obtained

where student_id='0009002011005' and Assesment_Id=(select Assesment_Id from Assesment_Detail

where Subject_ID=(select Subject_ID


from Academic.Subject where Subject_Name='Principle of Programming

Language') );

Via BO:

Test Case 4:

To check whether The student can issue a book or not

First we need to check the book is available or not

Secondly we need to check whether the student has issued

max number of books:

Result:

Custom query (to check whether the book is available or not):

select S_Book_ID,Status from Sub_Book_List where S_Book_ID in(select S_Book_ID from Sub_Book_List where M_Book_ID=(select M_Book_ID from Main_Book_List where Book_Title='Mathematics' and Author='R. Grewal') and L_Code=(select L_Code from Library_Code where L_Type='Main Library') );

Custom query (to check whether the student has issued maximum number of

books):

select Book_Issue_List .L_Card_ID, student_id,count(s_book_id) from Book_Issue_List,


l_card_issue where Status!='Submitted' and l_card_issue.l_card_id= Book_Issue_List.l_card_id group by Book_Issue_List .L_Card_ID,student_id having Book_Issue_List .L_Card_ID='LMain011002';

Via BO( to check whether the book is available or not):

Via BO (to check whether the student has issued maximum number of books):

Test Case 5:

To check the list of all the books of a particular type in the main

irrespective of issued or non issued:

Result:

Custom query:

select S_Book_ID,Status from Sub_Book_List where S_Book_ID in(select S_Book_ID from Sub_Book_List where M_Book_ID=(select M_Book_ID from Main_Book_List where Book_Title='Mathematics' and Author='R. Grewal') and L_Code=(select L_Code from Library_Code

where L_Type='Main Library');


Via BO:

Test Case 6:

To check how many copies of a particular book are available in

the main library for issuing.

Result:

Custom query:

select M_Book_ID,count(1) from Sub_Book_List

where S_Book_ID in(select S_Book_ID from Sub_Book_List where M_Book_ID=(select M_Book_ID from Main_Book_List where Book_Title='Mathematics' and Author='R. Grewal') and L_Code=(select L_Code from Library_Code where L_Type='Main Library') ) and Status='Available' group by M_Book_ID;

Via BO:


Test Case 7:

To check if clearance can be given from library for submitting the

library card.

Result:

Custom query:

select card_submission_status from l_card_issue where student_id='0007001011001' and l_code= 'Main001';

Via BO:

Test Case 8:

To check the number of books with status overdue and get the

calculated fine amount for them

Result:

Custom query:

select S_Book_ID, (trunc(sysdate)-Due_Date)*.5 fine from Book_Issue_List where l_card_id='LMain011002' and status='Overdue';


Via BO:

Test Case 9:

To check the marks obtained the students of a particular course

in the class test

To check the marks obtained all the test by all the student of a

particular course

Result:

Custom query (For class test):

select student_id, ass_mode, avg(Marks_or_Grade_Points) from student_assessment.marks_obtained marks_obtained, student_assessment.assesment_detail assesment_detail

where marks_obtained.Assesment_Id= assesment_detail.Assesment_Id

and student_id in(select student_id from student.student where course_id=‟MT001‟)

group by student_id,ass_mode having ass_mode='Class Test';

Custom query (For all the tests of a course):

select student_id, ass_mode, avg(Marks_or_Grade_Points) from student_assessment.marks_obtained marks_obtained, student_assessment.assesment_detail assesment_detail

where marks_obtained.Assesment_Id= assesment_detail.Assesment_Id

and student_id in(select student_id from student.student where course_id=‟MT001‟)

group by student_id,ass_mode;


Via BO (For class test):

Via BO (For all the tests):

Test Case 10:

To check what kind of book is most accessed by the student for a

particular subject

Result:

Custom query:

select subject,count(1) from Book_Issue_List, Main_Book_List, Sub_Book_List where Book_Issue_List.s_book_id=Sub_Book_List.s_book_id and Sub_Book_List.M_Book_ID=Main_Book_List.M_Book_ID

group by subject order by count(1) desc;

Via BO:


Test Case 11:

To check How many students of a course are availing the library

Result:

Custom query:

select course.course_name, count(distinct book_issue_list.l_card_id) from book_issue_list, L_Card_Issue, student.student_admission_detail student_admission_detail, Academic.course course where book_issue_list.l_card_id=L_Card_Issue.l_card_id and L_Card_Issue.student_id=student_admission_detail.student_id and student_admission_detail.course_id=course.course_id

group by course.course_name having course.course_name='MTech. in IT Courseware Engineering';

Via BO:

Test Case 12:

To check the course wise count of students who are using the

library

Result:

Custom query:

select course.course_name, count(distinct book_issue_list.l_card_id) from book_issue_list, L_Card_Issue, student.student_admission_detail student_admission_detail,


Academic.course course where book_issue_list.l_card_id=L_Card_Issue.l_card_id and L_Card_Issue.student_id=student_admission_detail.student_id and student_admission_detail.course_id=course.course_id

group by course.course_name;

Via BO:

Test Case 13:

To check the progress report of the backward class students

according to class tests for a particular course

Result:

Custom query:

select student_id, assesment_id, Marks_or_Grade_Points, grade from student_assessment.marks_obtained where Assesment_Id in(select assesment_id from assesment_detail Where ass_mode='Class Test') and student_id in(select student.student_id from student.student, student.student_admission_detail where category!='General' and course_id=‟MT001‟);

Via BO:


Test Case 14:

To check the progress report of the backward class students

according in all tests for a particular course

Result:

Custom query:

select student_id, ass_mode, avg(Marks_or_Grade_Points) from student_assessment.marks_obtained marks_obtained, student_assessment.assesment_detail assesment_detail where marks_obtained.Assesment_Id= assesment_detail.Assesment_Id and student_id in(select student.student_id from student.student, student.student_admission_detail where category!='General' and student_admission_detail.course_id=‟MT001‟)

group by student_id,ass_mode;

Via BO:

Test Case 15:

To check the Comparative study of access rates of the LMS and

result of the students


Result:

Custom query:

select b.student_id, b.subject_id, b.duration, a.Marks_or_Grade_Points from (select student_id, st_code, subject_id, sum(duration) duration from LMS_Data group by student_id,subject_id,st_code) b, (select student_id, Marks_or_Grade_Points from marks_obtained where subject_id='MET011' and course_id='MT001' and assesment_id in(select assesment_id from assesment_detail where ass_mode='Semester Exam') ) a

where a.student_id=b.student_id;

Via BO:

Test Case 16:

To check the needy, meritorious students result for launching a

scheme for them


Result:

Custom query:

select grade_detail_semester.student_id, semester_id, SGPA from grade_detail_semester, student.student_admission_detail, student.student where grade_detail_semester.student_id in( select student_id from student.student where MonthllyFamily_Income<=10000) and student.student_id=student.student_admission_detail.student_id and student.student.student_id=grade_detail_semester.student_id and student.student_admission_detail.course_id='MT001';

Via BO:

Test Case 17:

To check the subject allocation for teaching staffs so that

availability of the staff for a particular subject can be decided.

Result:

Custom query:

select staff_id,count(subject_id) from staff_subject_allocation where Allocation_End_Date is NULL or Allocation_End_Date>sysdate

group by staff_id;


Via BO:

Test Case 18:

To check the academic background of the students availing the

course

Result:

Custom query:

select student.student_id, course_id, degree from student, student_qualification_detail, student_admission_detail where student_admission_detail.student_id=student.student_id and student.qualification_id=student_qualification_detail.qualification_id and student_admission_detail.course_id=‟MT001‟;

Via BO:


Test Case 19:

How many out-of-state students are availing the course

Result:

Custom query:

select course.course_name, a.No_Of_Students from(select count(distinct student.student_id) No_Of_Students from student, student_contact_detail, student_admission_detail where student.Contact_Detail_Id

=student_contact_detail.Contact_Detail_Id and student_contact_detail.state_name!='West Bengal' and

student_admission_detail.student_id=student.student_id and student_admission_detail.course_id='MT003') a, academic.course

where course_id=‟MT003‟;

Via BO:

Test Case 20:

To check the State wise student division for a particular course


Result:

Custom query:

select state_name, count(distinct student.student_id) No_Of_Students from student, student_contact_detail, student_admission_detail where student.Contact_Detail_Id =student_contact_detail.Contact_Detail_Id and student_admission_detail.student_id=student.student_id and student_admission_detail.course_id='MT003'

group by state_name;

Via BO:

Test Case 21:

To check the areas within the state from where the students are

availing the course

Result:

Custom query:

select distinct city_name from student, student_contact_detail, student_admission_detail where student.Contact_Detail_Id=student_contact_detail.Contact_Detail_Id and student_admission_detail.student_id=student.student_id and student_admission_detail.course_id='MT001';


Via BO:

Test Case 22:

To check how many students are having multiple courses under same

university and their previous and current courses

Result:

Custom query:

select count(distinct S_Registration_ID) Registration_ID from KMR.Registration_History; select student_admission_detail.student_id, course_id previous_Course from student.student_admission_detail student_admission_detail, Registration_History where student.student_admission_detail.student_id=Registration_History.student_id and S_Registration_ID in(select distinct S_Registration_ID from Registration_History);

Via BO:


Test Case 23:

To check the areas within the state from where the students are

availing the course

Result:

Custom query:

select distinct city_name from student, student_contact_detail, student_admission_detail where student.Contact_Detail_Id=student_contact_detail.Contact_Detail_Id and student_admission_detail.student_id=student.student_id and student_admission_detail.course_id='MT001';

Via BO:

5.2 Interpretations of the Result

Results obtained from the test cases via BO and sqlplus shows the justified

relationship and strong integrity among the entities in the data model

proposed for the institute.

The results have been obtained via two means. One set of results has been

obtained from reporting tool BO. This is for the users who need not know

the background relationship among the entities. The templates in the


reporting tool and the relationship among the entities according to the data

model will be defined by the database administrators or anyone suitable

for this responsibility. The end users will only place their needs and they

will get the report accordingly. Thus the model supports the data security

issue by providing role-based access to information. Another kind of report

is shown via sqlplus by placing custom query. This is for the users who

have the thorough knowledge of the database. Also they can prepare

report templates for different end users needs. Apart from BO, any

reporting tool or applications can be used for data access and reporting

purpose. In this way, the model supports the needs of diverse users in the

higher education institute community.

Test case one to test case six has been organized keeping in mind the

academic needs. Sample reports have been shown regarding student‟s

promotion to the next semester, book issue details in the library, exam fees

submission status etc. Results have been obtained accordingly combining

different schemas and their corresponding entities.

Test case seven to fifteen have been organized considering the needs of the

educators on student‟s progress report, library usage, book usage in the

library etc. Here also result shows the relation among the entities of various

schemas such that they are acting as an integrated repository in case of

information extraction. Different kind of tracking mechanism has become

simple with this data structure as implemented according to the data

model.

Test case sixteen to twenty three have been organized according to the

management‟s needs on teaching staff allocation details, financial and

academic background of the students, state wise student distribution, out

of state student count etc so that they can make a proper analysis out of it

and make suitable decision about course management, student


management, institutional development etc. The benefits of one of the main

features of the proposed data model in this work, history data maintenance

is also evident from the results. Students, having multiple courses under

same university have also been identified from the

Registration_Detail_Hist table. It maintains history data about the student‟s

registration if the student avails multiple courses under same university. In

the same way trend analysis is shown by tracking the student‟s contact

details and also via other entities.

Thus considering the report outcomes and flexibility of information access

from the warehouse which have been tested with some sample data shown

in the Appendix II section, it is clear that a major pitfall of data

management and information extraction have been overcome by the data

model proposed in this work


6 CONCLUSION AND FUTURE SCOPE:

This paper discusses several benefits of a warehouse in e-governance activity

for information management in higher education institutes and various

aspects of their information needs. In accordance with that an integrated data

model has been proposed as a backbone of this warehouse. The most

important outcome of this model is flexible and integrated reporting that talks

about how the institutes will become proactive based on current trends. This

also makes them enable to forecast on the prospective careers for the students

by making the management activity relatively smooth.

Data warehousing is the most emerging technology in today‟s information

driven world. A vast number of organizations from different sectors are using

it to transform useless data into useful information for their business needs.

Naturally there is a vast area of work in this field to make the education

system and corresponding institutes in sink with this information evolution

activity. The data model presented in this work can be further improved by

incorporating various other aspects of information needs and making it more

generalized to fit into any of the higher education institutes seeking

structured information storage. Integration with the LMS and financial

transaction management system etc are the areas, which can be elaborated

further to achieve better integration and collaboration within the arena of

educational management system.


7 REFERENCES:

[1] F. Araque1, A. Salguero1, L. Martínez2, E. Navarro1 and M. Calero1 “Data

Warehousing for Improving Web-based Learning Sites” iJET – Vol. 2, No. 4, 2007

[2] Van Dyk, L “A Data Warehouse Model for Micro-Level Decision Making in Higher

Education” The Electronic Journal of e-Learning Volume 6 Issue 3, pp.235-

244, 2008

[3] Kebin Huang1 Feimin Li1 Ming Zhao2 Feng Wang1 Xiaoshuang Xu1

“Design and Implement On E-learning Behavior Mine System”

On Second International Conference on Genetic and Evolutionary

Computing -- IEEE DOI 10.1109/WGEC.2008.89, 2008

[4] Isidor Kamrat, Franz Haselbacher “E-Learning Initiative Based on a WEB-

Data- Based University Information Management System” Proceedings of the

International Conference on Computers in Education (ICCE‟02), IEEE, 2002

[5] Chee Chern LIM, Man Hing YU, Jesse J. JIN “GENERIC E-LEARNING DATA

STRUCTURE AND WEB TEACHING”

[6] José Paulo Leal1, Ricardo Queirós “Integration of E-Learning Systems with

Repositories of Learning Objects”.

[7] Jalel Akaichi “E-learning data warehouse maintenance system for

collaborative learning availability resources optimization” International

Journal of Education and Development using Information and Communication

Technology (IJEDICT), Vol. 3, Issue 3, pp. 16-29, 2007.


[8] Zuzana Bizonova, Daniel Ranc, Matilda Drozdova, Expected graduation:

“Model Driven E-learning Platform Integration”, September 2008

[9] Darja Solodovņikova and Laila Niedrīte “Using Data Warehouse Resources for

Assessment of E-Learning Influence on University Processes”

[10] Biswas P and Ghosh S.K. (2007) “A Novel Approach to Define Performance

Metrics for Students’ and Teachers’ Evaluation” The Electronic Journal of e-

Learning Volume 5 Issue 2, PP 87 – 102, 2007

[11] Michael Boehnlein, Markus Plaha, Achim Ulbrich-vom Ende “Case Study -

Building A Data Warehouse For Higher Education In The Course Of

Microstrategy’s University Program”

[12] Adeel Javed , Maqbool Uddin Shaikh , Baber Majid Bhatti “Conceptual Model

for Decision Support System Based Business Intelligence OLAP Tool for

Universities in Context of E-Learning” Proceedings of the World Congress on

Engineering and Computer Science 2008 WCECS 2008, San Francisco, USA

PP 22 - 24, October 2008

[13] Oleg Rostanin1, Klaus-Dieter Schewe2, Bernhard Thalheim3, Alexei

Tretiakov2 “Managing the Data in Electronic Learning Systems” Proceedings of

the IEEE International Conference on Advanced Learning Technologies

(ICALT‟04) 0-7695-2181-9/04, IEEE, 2004

[14] Rui Luís, David Simões, Nuno Horta “A Multi-Level Model for Tracking

Analysis in E-Learning Platforms” Proceedings of the IEEE International

Conference on Advanced Learning Technologies (ICALT‟04) 0-7695-2181-

9/04, IEEE, 2004


[15] Meijing Kong, Wan-Zhen Zhou, Wen-Ta0 Wang, Hong-Bin Gao “The

Application Study Of The Data Mining Technology In University Dss” Proceedqs

of the Third International Conference on Machine Learning and Cybernetics,

Shanghai, 26-29 August 2004, 0-7803-8403-2/04, IEEE, 2004

[16] SU-LAN ZHANG, JI-FU ZHANG “A New Classification Mining Model Based

On The Data Warehouse “

[17] Marta Zorrilla, Universidad de Cantabria “Data Webhouse to support web

intelligence in e-learning environments” This work has been partially supported

by Spanish Mininstry of Education under proect N2004-05873" and

"TIC2002-01306" 0-7803-9017-2/05: IEEE, 2005

[18] Xi-Qian Chen, Zhong-Xian Chi, Xiu-Kun Cao “Applying Dp To Etl Of Spatial

Data Warehouse” Proceedlngs Of The Third International Conference On

Machine Learning And Cybernetics, Shanghai, 26-29, August 2004

[19] Alex G. Büchner, David Patterson “Call for a Pedagogical Domain Knowledge

Model” Proceedings of the 15th International Workshop on Database and

Expert Systems Applications (DEXA‟04) 1529-4188, IEEE, 2004

[20] Anilia Lourenqo, Joaquim Gonqalves, Orlando Belo “Agent -Based Knowledge

Extraction Services Inside Enterprise Data Warehousing Systems Environments”

1529-4188/01, IEEE, 2001

[21] Sylvain Delisle “Towards a Better Integration of Data Mining and Decision

Support via Computational Intelligence” Proceedings of the 16th International

Workshop on Database and Expert Systems Applications (DEXA‟05) 1529-

4188/05, IEEE, 2005


[22] Daniela Resende Silva, Marina Teresa Pires Vieira: “Using Data Warehouse and

Data Mining Resources for Ongoing Assessment of Distance Learning”

[23] Shanli Wang “Research on a New Effective Data Mining Method Based on Neural

Networks”

[24] Sean Wolfgand Matsui Siqueira, Rubens Nascimento Melo, Maria Helena

Lima Baptista Braz “E-Learning Content Warehouse Architecture” IADIS

International Conference WWW/Internet, 2002

[25] C. Gombiro, W. Munyoka, S. Hove, G. Chengetanai, and C. Zano “The Need

For Data Warehousing In Sharing Learning Materials” Journal of Sustainable

Development in Africa (Volume 10, No.2) ISSN: 1520-5509, 2008

[26] Inc. Elizabeth Shahnam. META Group: “The customer relationship management

ecosystem”.

An Integrated Data Model Approach for E-Governance of Higher Education Institutions Page A.1 of A.49

APPENDIX I: TABLE STRUCTURE

Table Structures for different subject areas are given below:

SUBJECT AREA: ACADEMIC

Table : Subject

Name Datatype Null

Option

Comment Is

PK

Is

FK

Subject_ID VARCHAR2(20) NOT

NULL

This is unique identifier of the subject. Yes No

Subject_Name VARCHAR2(100) NULL Name of the subject No No

Subject_Type VARCHAR2(30) NULL Theory or Seasonal No No

Active_Flag CHAR NULL It is used to denote if the subject id is still

active or it was used previously. It will be

'Y' if active, otherwise, 'N'.

No No

Table: Course

Name Data type Null

Option

Comment Is

PK

Is

FK

Name Datatype Null

Option

Comment Is

PK

Is

FK

Course_ID VARCHAR2(20) NOT

NULL

This is the unique identifier of the

course.

Yes No

Course_Name VARCHAR2(100) NULL Name of the course. No No

Course_Duration VARCHAR2(20) NULL Duration of the course. No No

Approval_Detail VARCHAR2(300) NULL This is the path of a linked list which

will contain the approval detail like,

Department Resolution Number,

Faculty, Executive Council, Court etc.

No No


C_Mode VARCHAR2(20) NULL Course will be conducted in full time,

distance or part time mode.

No No

Degree VARCHAR2(60) NULL What will be the degree that will be

offered to the student after completing

the course, like, 'B.Tech' or 'M.Tech'

etc.

No No

Total_Fees NUMBER NULL Total fees for availing the course. No No

Active_Flag CHAR NULL This will be used to denote if the

course is still active or not.

No No

Table: Course_Session_Allocation

Name Datatype Null

Option

Comment Is PK Is FK


NULL

This is the unique identifier of

the course.

Yes Yes

Session_ID VARCHAR2(20) NOT

NULL

Unique identifier of the session. Yes Yes

C_Year VARCHAR2(20) NOT

NULL

C_Year will be like 1st year or

second year or 3 year or 4th Year

etc

Yes No

Session_Start_Time DATE NULL This is the start time of a course

for a particular session.

No No

Session_End_Time DATE NULL This is the end time of a course

for a particular course.

No No

Table: Subject_Course_Rel

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

This is unique identifier of the

subject.

Yes Yes



NULL

This is the unique identifier of the

course.

Yes Yes

Semester_ID VARCHAR2(20) NOT

NULL

Unique identifier for a semester. Yes Yes

Table: Faculty_Council

Name Datatype Null

Option

Comment Is

PK

Is

FK

FC_ID VARCHAR2(30) NOT

NULL

This is the unique identifier of the Faculty

council like ENG, SC or ARTS.

Yes No

FC_NAME VARCHAR2(50) NULL Name of the Faculty Council like,

Engineering, Science or Arts

No No

Table: Course_Department_Rel

Name Datatype Null Option Comment Is

PK

Is

FK

Department_ID VARCHAR2(30) NOT NULL Unique identifier of the

department.

Yes Yes

Course_ID VARCHAR2(20) NOT NULL This is the unique identifier

of the course.

Yes Yes

Session_ID VARCHAR2(20) NOT NULL Unique identifier of the

session.

Yes Yes

SUBJECT AREA: STUDENT ASSESSMENT

Table: Assessment_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

Assesment_Id VARCHAR2(20) NOT Unique identifier of the Yes No


NULL assignment.


NULL



NULL


subject.

No Yes


NULL

Unique identifier for a semester. No Yes

Assesment_Summary VARCHAR2(100) NULL This is a path of the linked list

containing the details of the

assessment.

No No

Assess_Type VARCHAR2(20) NULL This will be Weekly Evolution

or Monthly Evolution or

Sessional Or Semester Exam.

No No

A_Mode VARCHAR2(20) NULL Mode will be regular or

Supplementary.

No No

Date_Assesment_Start DATE NULL Start date of the assignment No No

Date_Assesment_End DATE NULL End date of the assignment. No No

Max_Attempt_allowed INTEGER NULL Maximum attempts allowed to

complete the assignment.

No No

Table: Marks_Obtained

Name Datatype Null

Option

Comment Is

PK

Is

FK

Assesment_Id VARCHAR2(20) NOT

NULL

Unique identifier of the

assignment.

Yes Yes


Student_ID VARCHAR2(20) NOT

NULL

Unique identifier of the student.

This is the student class roll

number. This will be derived

from the following:

x - Admission Type (New or

readmission)

x - Admission Mode (Regular or

distance)


xxx - Course id

xxx - Faculty id

xxx - unique number among the

students

Yes Yes


NULL

Unique identifier of the session. No Yes


NULL


subject.

No Yes

Semester_ID VARCHAR2(20) NULL Unique identifier for a semester. No Yes

Course_ID VARCHAR2(20) NULL This is the unique identifier of

the course.

No Yes

Marks_or_Grade_Points NUMBER NULL Marks or grade points obtained

in a semester or class test.

No No

Review VARCHAR2(20) NULL This is the ID for review if

review request is raised.

No No

Status VARCHAR2(20) NULL Whether the student has passed

or failed in the exam

No No

Grade VARCHAR2(20) NULL Overall grade obtained in the

exam.

No Yes

Active_Flag CHAR NULL It is used to denote whether a

particular assignment is

completed by the student or not.

If i t is complete, then this flag

will be 'N'. Otherwise it will be

No No


'Y'.

Staff_ID VARCHAR2(20) NULL This will be a multivalued field.

Because more than one Staff can

review a paper.

No Yes

Attempt INTEGER NULL This will track the number of

attempts by a student to

complete any assignment.

Also mode of the exam can also

be decided from this. If attempt

is greater than one, then it is

supply exam.

No No

End_Dt DATE NULL Date on which the student has

cleared the assignment.

No No

Re_Assessment_Allowed VARCHAR2(20) NULL This will be used to denote if

reassessment is allowed if the

student is not able to complete

the assignment in the current

attempt

No No

Table: Grade_Detail_Semester

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL



NULL



NULL

Unique identifier of the student. This

is the student class roll number. This



readmission)


Yes Yes


distance)


xxx - Course id

xxx - Faculty id


students

SGPA VARCHAR2(20) NULL This is used to denote the semester

grade point average. This will be

calculated by calculating the over all

grade of the subjects which can be

obtained by taking the individual

assessment_ids assigned for a

particular subject and making a sum.

Then the sum of individual grades for

subjects assigned for a semester can be

taken to calculate the grade for the

semester.

No No

Status VARCHAR2(20) NULL X- Failed

XP - Passes with blockage

P - Passed and promoted

No No

End_Dt DATE NULL Date on which the student completes

or partially completes the semester.

No No

Promoted VARCHAR2(20) NULL This is used to denote if the student is

promoted or not to the next semester.

The value will be 'Y' if promoted, and

'N' if not promoted.

No No

Completion_Date DATE NULL Date on which the student completes

the semester. This will be NULL until

the student completes the exam.

No No


Table: Attendence_Record

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of the student. This is

the student class roll number. This will be

derived from the following:


readmission)


distance)


xxx - Course id

xxx - Faculty id


Yes Yes


NULL




NULL

This is unique identifier of the subject. No Yes

Attendence NUMBER NULL Total attendance of the student for the

particular subject

No No

Table: Semester

Name Datatype Null

Option

Comment Is PK Is FK


NULL

Unique identifier for a

semester.

Yes No

Semester_Name VARCHAR2(20) NOT

NULL

Name of the semester. No No


Table: S_Exam_Roll_No

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of the student. This is

the student class roll number. This will be





xxx - Course id

xxx - Faculty id


Yes Yes

Exam_Rol_No VARCHAR2(30) NOT

NULL

This is the unique identifier of the student

with respect to the exam.

This will be derived as follows:

xxxxxx - course id

x - semester id

x - mode

xxx - part of student roll no.

Yes No


NULL

This is the unique identifier of the course. Yes Yes


NULL



NULL



Table: Grade_Detail_Course

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

This is the unique

identifier of the course.

Yes Yes


NULL


session.

Yes Yes


NULL


student. This is the

student class roll number.

This will be derived from

the following:

x - Admission Type (New

or readmission)

x - Admission Mode

(Regular or distance)


xxx - Course id

xxx - Faculty id

xxx - unique number

among the students

Yes Yes

DGPA NUMBER NULL This is used to denote the

degree grade points

average. This will be

calculated and populated

on the basis of the grade

points obtained in the

semesters.

No No

Status VARCHAR2(20) NULL This is used to denote

status whether the

student completed the

course successfully or

not.

No No


End_Dt DATE NULL Date on which the

student completes the

course.

No No

Attempt INTEGER NULL This is the number of

attempts in case the

student gets year lack.

No No

Percentage_Of_Marks_Obtained NUMBER NULL Percentage of marks

obtained in the course.

No No

Table: Grade_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

Grade VARCHAR2(20) NOT

NULL

This is the grade which

is given as per the

performance in the

exam.

Yes No

Grade_Point INTEGER NULL This is the grade point

given as per the grade.

No No

Percentage_Of_Marks_Obtained NUMBER NULL This is the percentage of

marks obtained with

respect to a particular

grade.

No No

Performance VARCHAR2(50) NOT

NULL

This is used to denote

performance according

to the grade.

No No


Table: LMS_Data

Name Datatype Null

Option

Comment Is

PK

Is

FK

St_Code VARCHAR2(20) NOT

NULL

This Code will be generated as a

combination of Subject_Id,Course_Id,

Section_Id and student id.

Yes No

Student_ID VARCHAR2(20) NULL Unique identifier of the student. This is the

student class roll number. This will be





xxx - Course id

xxx - Faculty id


No Yes


NULL

This is unique identifier of the subject. No Yes

Session_ID VARCHAR2(20) NULL Unique identifier of the session. No Yes

Log_Date DATE NULL Date on which the student accesses the LMS. No No

Duration VARCHAR2(20) NULL Duration during which the student was

logged on to the page.

No No

Table: Exam_Fees_Submission


PK

Is

FK

Session_ID VARCHAR2(20) NOT NULL Unique identifier of the

session.

Yes Yes


Student_ID VARCHAR2(20) NOT NULL Unique identifier of the

student. This is the student

class roll number. This will

be derived from the

following:

x - Admission Type (New

or readmission)

x - Admission Mode

(Regular or distance)


xxx - Course id

xxx - Faculty id

xxx - unique number

among the students

Yes Yes

Semester_ID VARCHAR2(20) NOT NULL Unique identifier for a

semester.

Yes Yes

Assesment_Id VARCHAR2(20) NOT NULL Unique identifier of the

assignment.

Yes Yes

Exam_Fees NUMBER NULL Fees for the exam. No No

Grade_Card_Fees NUMBER NULL Fees for grade card. No No

Form_Fees NUMBER NULL Fees for examination form. No No

Status_Form_Fillup VARCHAR2(20) NOT NULL Form fill up status:

complete or incomplete.

No No

Late_Fine NUMBER NULL Late fine for form fill up if

any.

No No

Submission_Date DATE NULL Submission date of the

exam fees along with the

form.

No No

Completion_Status VARCHAR2(20) NOT NULL Completion status of the

examination fees

submission and form fill

up.

No No

Last_date_Fine_Sub DATE NULL Last date of fine submission No No


for form fill up.

Last_date_Form_Fillup DATE NULL Last date of form fill up. No No

SUBJECT AREA: FACULTY

Table: Faculty_Information

Name Datatype Null

Option

Comment Is PK Is FK

Staff_ID VARCHAR2(20) NOT NULL Unique identifier of

the staff.

Yes No

Staff_First_Name VARCHAR2(50) NOT NULL First name of the staff. No No

Staff_Middle_Name VARCHAR2(50) NULL Middle name of the

staff.

No No

Staff_Last_Name VARCHAR2(50) NOT NULL Last name of the staff. No No

Gender CHAR NOT NULL Gender of the staff. No No

Qualification VARCHAR2(60) NOT NULL Qualification of the

staff.

No No

Marital_Status VARCHAR2(20) NOT NULL Marital status

(married or

unmarried) of the

staff.

No No

Contact_ID VARCHAR2(20) NOT NULL Unique identifier of

the contact details of a

staff.

No Yes

University_joining_date DATE NULL The date on which the

staff has joined the

university.

No No


Date_Left_University DATE NULL The date on which the

staff has left the

university. This will

remain NULL until

the staff leaves the

university.

No No

L_Mode VARCHAR2(20) NULL Part time or Full Time No No

Retirement_Date DATE NULL This is the date of

retirement for the full

time staffs.

No No

Agreement_Period VARCHAR2(30) NULL This is for part time

teachers. For full

timer, this will be

NULL

No No

Subject_List VARCHAR2(300) NULL List of subjects which

can be taught by a

particular Academic

Staff.

No No

Table: Faculty_Contact_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

Contact_ID VARCHAR2(20) NOT

NULL

Unique identifier of the contact

details of a staff.

Yes No

Addrss_type CHAR(18) NULL Address type of the staff like

permanent or present.

No No

Address_Detail VARCHAR2(100) NULL Address detail of the staff. No No

Country_Name VARCHAR2(50) NOT

NULL

Country name where the Staff

resides.

No No

City_Name VARCHAR2(50) NULL City name where the staff

resides.

No No


ZIP_Code VARCHAR2(20) NULL ZIP code of the place where the

staff resides.

No No

State_Name VARCHAR2(50) NULL Name of the state where the staff

resides.

No No

Mobile_No VARCHAR2(20) NOT

NULL

Mobile number of the staff. No No

Residence_Phn_No VARCHAR2(30) NOT

NULL

Residence phone number of the

staff.

No No

E_mail_Address VARCHAR2(100) NOT

NULL

e-mail address of the staff. No No

Table: Administrative_Role_Allocation

Name Datatype Null

Option

Comment Is

PK

Is

FK

Create Statement

Staff_ID VARCHAR2(20) NOT

NULL

Unique identifier of

the staff.

Yes Yes Staff_ID

VARCHAR2(20)

NOT NULL

R_Code_ID VARCHAR2(20) NOT

NULL

Unique identifier of a

particular role.

Yes Yes R_Code_ID

VARCHAR2(20)

NOT NULL


NULL


the session.

Yes Yes Session_ID

VARCHAR2(20)

NOT NULL

Active_Flag CHAR NOT

NULL

This will denote if

the staff is still active

with the particular R-

code-id.

Yes No Active_Flag

CHAR NOT

NULL

Division VARCHAR2(100) NOT

NULL

This Can be FC_ID

or Department_id.

Department_id will

be for the

administrators of the

No No Division

VARCHAR2(100)

NOT NULL


department .FC_ID

will be for the

administrators of the

faculty council.

Role_Start_Date DATE NULL The date on which

the staff is assigned

the particular role.

No No Role_Start_Date

DATE NULL

Role_End_Date DATE NULL The date on which

the assignment of the

staff ends for that

particular role.

No No Role_End_Date

DATE NULL

Table: Role_Code

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of a particular role. Yes No

Role_Description VARCHAR2(50) NOT

NULL

Register, Dean, Professor, Head of the

department, Assistant professor etc

No No

Role_Type VARCHAR2(30) NOT

NULL

This can be Administration or

Teaching

No No

Table: Post_Guide_Allot

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of the staff. Yes Yes


NULL



class roll number. This will be



Yes Yes


readmission)

x - Admission Mode (Regular

or distance)


xxx - Course id

xxx - Faculty id

xxx - unique number among

the students


NULL


Assignment_Start_date DATE NULL The date on which the staff is

assigned as a guide of a

postgraduate student.

No No

Assignment_End_Date DATE NULL The date on which the

assignment for the particular

staff ends as a guide of a

postgraduate student.

No No

Active_Flag VARCHAR2(20) NULL Is used to denote if the staff is

still active as a guide.

No No

Table: P_Faculty_Lecture_Details

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL



NULL

This is unique identifier of the subject. Yes Yes


Mon_key VARCHAR2(20) NOT

NULL

Unique identifier of a particular

month.

No Yes

No_Of_Lectures INTEGER NULL Number of lectures given by the staff

for a particular period or month.

No No


Table: Faculty_Subject_Allocation

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL



NULL



NULL


subject.

Yes Yes

Allocatrion_Start_Date DATE NULL The date on which the staff is

assigned as a coordinator of a

particular subject.

No No

Allocation_End_Date DATE NULL The date on which the assignment

for the particular sta ff ends as a

coordinator of a particular subject.

No No

Table: Faculty_Role

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of the staff. No Yes


NULL


role.

No Yes

Department_ID VARCHAR2(30) NULL Unique identifier of the

department.

No Yes


Role_Start_Date DATE NULL The date on which the staff is

assigned a particular role.

No No

Role_End_Dt DATE NULL The date on which the role

assignment ends for the staff.

No No


Active_Flag VARCHAR2(20) NOT

NULL

This is used to denote if the staff is

still active in his role.

No No

Table: Visiting_Faculty_Infromation


PK

Is

FK

Visitor_ID VARCHAR2(20) NOT NULL Unique identifier of a

visiting staff.

Yes No


department.

No Yes

First_Name VARCHAR2(100) NOT NULL First name of a visiting

staff.

No No

Middle_Name VARCHAR2(100) NULL Middle name of a visiting

staff.

No No

Last_Name VARCHAR2(100) NOT NULL Last name of a visiting

staff.

No No

Gender CHAR(18) NULL Gender of the staff. No No

Qualification VARCHAR2(100) NOT NULL Qualification of the

visiting staff.

No No

Visiting_Date DATE NULL The date on which the

staff visits the University.

No No

Reason VARCHAR2(300) NOT NULL The reason of visiting. No No

Subjects_Monitored VARCHAR2(300) NOT NULL The subjects which will be

monitored by the visiting

staff.

No No

Associated_Organization VARCHAR2(100) NOT NULL The organization with

which the visiting staff is

associated currently.

No No


SUBJECT AREA: FINANCE

Table: Course_Fees_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL



NULL



NULL

This is the unique identifier of

the course.

Yes Yes


NULL




from the following:


readmission)


distance)


xxx - Course id

xxx - Faculty id


students

Yes Yes

Total_Fees_Submitted NUMBER NULL Total fees submitted for a

particular semester till date.

No No

Amount_Due NUMBER NULL Amount of fees due by the

student for a particular semester.

No No

Fees_Sub_Date DATE NULL Date of fees submission. No No

Status_Fees_Submission VARCHAR2(20) NOT

NULL

This is used to denote whether

the fees submission is complete

or not for a particular semester.

No No


Table: Salary_P_Faculty

Name Datatype Null Option Comment Is PK Is FK

Staff_ID VARCHAR2(20) NOT NULL Unique identifier of the staff. Yes Yes

Department_ID VARCHAR2(30) NOT NULL Unique identifier of the

department.

Yes Yes

Mon_key VARCHAR2(20) NOT NULL Unique identifier of a

particular month.

Yes Yes

Session_ID VARCHAR2(20) NULL Unique identifier of the

session.

No Yes

Amount_Paid NUMBER NULL Amount paid to the full time

staff.

No No

Table: Salary_F_Faculty

Name Datatype Null

Option

Comment Is

PK

Is FK


NULL



NULL


month.

Yes Yes


department.

No Yes


Amount_Paid NUMBER NULL Amount paid to the full time

staff.

No No

Table: Other_Development_Cost

Name Datatype Null

Option

Comment Is PK Is FK

Department_ID VARCHAR2(30) NOT

NULL


department.

Yes Yes



Course_ID VARCHAR2(30) NULL This is the unique identifier of

the course.

No Yes

Reason VARCHAR2(100) NULL Reason for the cost. No No

Amount_Spent NUMBER NULL Amount spent for the reason. No No

Mon_key VARCHAR2(20) NULL Unique identifier of a particular

month.

No Yes

Table: Total_Revenue

Name Datatype Null

Option

Comment Is

PK

Is

FK

Department_ID VARCHAR2(30) NOT

NULL


the department.

Yes Yes


NULL


the session.

Yes Yes


NULL

This is the unique

identifier of the

course.

Yes Yes


NULL

Unique identifier of a

particular month.

Yes Yes

Total_Fees_Collected NUMBER NULL Total fees collected

from the students.

No No

Other_Cost NUMBER NULL The other cost for

different reasons.

No No

Total_Development_Expenditure NUMBER NULL Total development

expenditure.

No No


SUBJECT AREA: STUDENT

Table: Student

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL



class roll number. This will be



readmission)

x - Admission Mode (Regular

or distance)


xxx - Course id

xxx - Faculty id

xxx - unique number among

the students

Yes Yes

Gender CHAR NOT

NULL

Gender of the student. No No

ST_First_Name VARCHAR2(50) NULL First name of the student. No No

ST_Middle_Name VARCHAR2(50) NOT

NULL

Middle name of the student. No No

ST_LAST_NAME VARCHAR2(100) NULL Last name of the student. No No

DOB DATE NULL Date of birth of the student. No No

Active_Flag CHAR NULL This is used to denote whether

the student is still active.

No No

MonthllyFamily_Income NUMBER NULL Monthly Family income of the

student.

No No

Contact_Detail_Id VARCHAR2(20) NULL Unique identifier for the

contacts of a particular student.

No Yes

Qualification_ID VARCHAR2(20) NULL Unique identifier of the No Yes


qualification details of the

student.

Category VARCHAR2(20) NULL General or SC ST or OBC or

other backward class category

No No

Working_Status VARCHAR2(200) NULL Whether the student works for

any organization.

No No

Marital_Status VARCHAR2(20) NOT

NULL

Marital status of the student. No No

Table: Student_Qualification_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

Qualification_ID VARCHAR2(20) NOT

NULL


qualification details of

the student.

Yes No

Degree VARCHAR2(20) NULL Primarily it is the degree

hold by the student

before joining the course

in the university.

No No

Year_Of_Passing DATE NULL Year of passing for the

degree hold by the

student.

No No

Percentage_of_Marks_Obtained NUMBER NULL Percentage of marks

obtained by the student

while accomplishing the

degree.

No No

University VARCHAR2(100) NULL Name of the university

from which the student

have obtained his

previous degree.

No No

College_or_School VARCHAR2(200) NULL Name of the college or

school from which the

No No


student have obtained

his previous degree.

Table: Student_Contact_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

Contact_Detail_Id VARCHAR2(20) NOT

NULL

Unique identifier for the

contacts of a particular

student.

Yes No

Guardian_Name VARCHAR2(100) NULL Name of the guardian of the

student.

No No

Mobile_No VARCHAR2(30) NOT

NULL

Mobile number of the student. No No

Residence_Phn_No VARCHAR2(30) NOT

NULL

Residence phone number of

the student.

No No

Local_Guardian_Name VARCHAR2(20) NULL Local guardian name of the

student.

No No

E_Mail_Address VARCHAR2(100) NULL E-mail address of the student. No No

Address_Type VARCHAR2(20) NULL Address type (permanent or

present) of the student.

No No

City_Name VARCHAR2(50) NULL Name of the city where the

student resides.

No No

Country_Name VARCHAR2(50) NULL Name of the country where

the student resides.

No No

State_Name VARCHAR2(50) NULL Name of the state where the

student resides.

No No

ZIP_Code VARCHAR2(20) NULL ZIP code of the place where

the student resides.

No No

Other_Address_Detail VARCHAR2(200) NULL Other address detail of the

student.

No No


Table: Student_Stipend_Issue_Detail

Name Datatype Null

Option Comment Is

PK Is

FK


NULL Unique identifier of the student. This is the

student class roll number. This will be



x - Admission Mode (Regular o r distance)


xxx - Course id

xxx - Faculty id


No Yes

Stipend_Id VARCHAR2(20) NULL Unique identifier of the stipend. No Yes


Eligible_For_Stipend VARCHAR2(20) NOT

NULL If the student is elig ible for any further

stipend. If he fin ishes taking the total

amount, then this field will be 'No'.

No No

Stipend_Amount NUMBER NULL Amount of stipend given to the student No No

Issued_Amount NUMBER NULL Amount issued by the student on the issue

date. No No

Due_Amount NUMBER NULL No No

Issue_Date DATE NULL Dat on which the stipend is given to the

student. No No

Status VARCHAR2(20) NOT

NULL Status of the issue of stipend to the student

and further details. No No

Active_Flag VARCHAR2(20) NOT

NULL To indicate the current record of the student

receiving stipend. On next issue, this flag

will be 'N' and a new record will be inserted

with active flag 'Y'.

No No

Table: Stipend_Detail

Name Datatype Null

Option Comment Is

PK Is

FK Create Statement

Stipend_Id VARCHAR2(20) NOT

NULL Yes No Stipend_Id

VARCHAR2(20) NOT

NULL

Detail VARCHAR2(100) NOT Details of the No No Detail


NULL stipend. VARCHAR2(100) NOT

NULL

Amount NUMBER NULL Amount to be

given as stipend. No No Amount

NUMBER NULL

Stipend_Division VARCHAR2(20) NOT

NULL Monthly or

yearly or

quarterly etc.

No No Stipend_Division

VARCHAR2(20) NOT

NULL

Column: Student_Admission_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL




from the following:


readmission)


distance)


xxx - Course id

xxx - Faculty id


students

Yes No


NULL


Course_ID VARCHAR2(20) NULL This is the unique identifier of the

course.

No Yes

A_Mode VARCHAR2(20) NULL This is the mode of admission.

This can be full time, part time or

distance.

No No

Date_Admission DATE NULL This is the date of admission of

the student.

No No

Admission_Type VARCHAR2(20) NULL This can be New admission or

Readmission

No No


Admission_Test_Marks NUMBER NULL This is the marks obtained in the

admission test by the student.

No No

Admission_Fees NUMBER NULL Fees of admission. No No

Fees_Registration NUMBER NULL Fess for registration during

admission.

No No

Fees_Library NUMBER NULL Fees for library during admission. No No

Submission_Status VARCHAR2(20) NOT

NULL

Submission status of the different

fees during admission.

No No

Caution_Money NUMBER NULL Caution money submitted during

admission.

No No

Other_Charges NUMBER NULL Other charges submitted during

admission.

No No

Submission_Date DATE NULL Submission date of the fees for

admission and other charges.

No No

SUBJECT AREA: LIBRARY

Table: L_Card_Issue

Name Datatype Null

Option

Comment Is

PK

Is

FK

L_Card_ID VARCHAR2(20) NOT

NULL

Unique identifier of the library

card issued to the students.

Yes No

L_Code VARCHAR2(20) NOT

NULL

Unique identifier of the Library

(Whether it is main or

departmental)

No Yes

Staff_ID VARCHAR2(20) NULL Unique identifier of the staff. No Yes

Student_ID VARCHAR2(20) NULL Unique identifier of the student.



from the following:


No Yes


readmission)


distance)


xxx - Course id

xxx - Faculty id


students


NULL


Issue_Date DATE NULL Dat on which the card is issued

to the student.

No No

Active_Flag CHAR NULL It is used to denote if the library

card is still active with respect to

that particular student.

No No

Card_Submission_Date DATE NULL Dat on which the card is

submitted in the library. It is

NULL until the card is

submitted.

No No

Card_Submission_Status VARCHAR2(20) NULL It is used to denote if the card

submission is complete or not.

No No

Table: Library_Code

Name Datatype Null

Option

Comment Is

PK

Is

FK

L_Code VARCHAR2(20) NOT

NULL

Unique identifier of the Library (Whether it

is main or departmental)

Yes No

L_Type VARCHAR2(20) NULL Whether departmental or Main No No


Table: Subject_Material_Detail

Name Datatype Null

Option

Comment Is

PK

Is FK

Material_Id VARCHAR2() NOT

NULL

Unique identifier of the materials

present in the library.

Yes No


NULL

This is unique identifier of the subject. Yes Yes

Material_Type VARCHAR2(40) NULL This can be CD or DVD No No

Num_Material INTEGER NULL Number of materials present in the

library.

No No

Student_ID VARCHAR2(20) NULL Unique identifier of the student. This

is the student class roll number. This



readmission)


distance)


xxx - Course id

xxx - Faculty id


students

No Yes

Issue_Date DATE NULL Date on which the material is issued

to the student.

No No

Status VARCHAR2(20) NOT

NULL

Available/Issued No No


Table: Book_Issue_List

Name Datatype Null

Option

Comment Is

PK

Is

FK

S_Book_ID VARCHAR2(20) NOT

NULL

Unique identifier of the books. Yes Yes

L_Card_ID VARCHAR2(20) NOT

NULL

Unique identifier of the library

card issued to the students.

Yes Yes

Issue_Date DATE NULL The date on which the book is

issued to the student.

No No

Due_Date DATE NULL The date on which book is to be

returned by the student.

No No

Submission_Date DATE NULL The date on which the book is

submitted to the library.

No No

Fine NUMBER NULL Fine amount if the book is not

submitted in time.

No No

Status VARCHAR2(20) NULL Submitted or Due or Overdue. No No

Fine_Submission_Date DATE NULL Date on which the fine is

submitted to the library.

No No

Table: Sub_Book_List

Name Datatype Null

Option

Comment Is

PK

Is

FK

S_Book_ID VARCHAR2(20) NOT NULL Unique identifier of the books. Yes No

M_Book_ID VARCHAR2(20) NOT NULL Unique identifier of a particular type

of book.

No Yes

L_Code VARCHAR2(20) NOT NULL Unique identifier of the Library

(Whether it is main or departmental)

No Yes

Edition VARCHAR2(20) NOT NULL The edition of the book. No No

Status VARCHAR2() NULL Available or Issued or Reference

Copy.

No No


Price NUMBER NULL Price of the book. No No

Table: Main_Book_List


PK

Is

FK

M_Book_ID VARCHAR2(20) NOT NULL Unique identifier of a

particular type of book.

Yes No

Book_Title VARCHAR2(100) NULL Title of the book. No No

Subject VARCHAR2(100) NOT NULL Subject of the book. No No

No_Of_Copy INTEGER NULL Number of copies available in

the library for that particular

kind of book.

No No

Author VARCHAR2(400) NULL Author of the book. No No

Publisher VARCHAR2(200) NULL Publisher of the book. No No

SUBJECT AREA: GENERAL

Table: Month

Name Datatype Null

Option

Comment Is PK Is FK

Mon_key VARCHAR2(20) NOT NULL Unique identifier of a particular

month.

Yes No

Month_ID VARCHAR2(20) NOT NULL Month id of a month. e.g. 1, 2 or 3

etc.

No No

M_Year INTEGER NOT NULL Year of the month e.g. 2010 or 2009

or 2008 etc.

No No

Month_Name CHAR(18) NULL Name of the month e.g. January,

February etc.

No No

Total_days INTEGER NULL Total days in a month. No No


Table: Session_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK


NULL

Unique identifier of the session. Yes No

Session_Description VARCHAR2(20) NOT

NULL

Description of the session like

2009-10 or 2008-09 etc.

No No

SUBJECT AREA: KMR

Table: Registration_Detail

Name Datatype Null

Option

Comment Is

PK

Is

FK

St_First_Name VARCHAR2(400) NOT

NULL

First Name of the student Yes No


NULL

Middle Name of the Student Yes No

ST_Last_Name VARCHAR2(20) NOT

NULL

Last Name of the Student Yes No

S_Registration_ID VARCHAR2(20) NOT

NULL

Registration number of a student. Yes No

Date_Registration DATE NOT

NULL

Date on which the registration is

done.

Yes No


NULL



number. This will be derived from

the following:


readmission)


distance)


No Yes


xxx - Course id

xxx - Faculty id


students



NULL

It is used to denote whether the

student still exists in the

university.

No No

Table: Registration_Detail_Hist

Name Datatype Null

Option

Comment Is

PK

Is

FK

St_First_Name VARCHAR2(400) NOT

NULL

First Name of the student Yes Yes


NULL

Middle Name of the Student Yes Yes

ST_Last_Name VARCHAR2(20) NOT

NULL

Last Name of the Student Yes Yes

S_Registration_ID VARCHAR2(20) NOT

NULL

Registration number of a student. Yes Yes

Date_Registration DATE NOT

NULL

Date on which the registration is

done.

Yes Yes


NULL



number. This will be derived from

the following:


readmission)


distance)

No Yes



xxx - Course id

xxx - Faculty id


students



NULL

This used to denote whether the

registration id is still active or not

in the university.

No No


APPENDIX II: TEST DATA

The following are the few sample set of data has been used for testing purpose:

SUBJECT AREA ACADEMIC:

COURSE_ID COURSE_NAME

MT001 MTech. in IT Courseware Engineering

MT002 MTech. in IT Courseware Engineering

MT003 MTech. in IT Software Engineering

PG004

Post Graduate Deploma in Courseware

Engineering

UG005 COmputer Science Engineering

DEPARTMENT_ID DEPARTMENT_NAME FC_ID

11 School Of Education Technology Engg

SUBJECT_ID SUBJECT_NAME S_TYPE

MET011 Mastering in Multimedia Development Theory

CWE011 Principle of Courseware Engineering Theory

SWE011 Principle of Software Engineering Theory

MTL024 Multimedia Lab Sessional

ENM023 Engineering Mathematics Theory

PRM009 Principle of Programming Language Theory

ALG024 Principle of Algo Theory

PGL024 Pogramming Lab Sessional

GRM009 Principle of Graphics Theory

DBMS024 Data Base Management System Theory

MAUT023 Multimedia Authoring Theory

CMUN004 Principle of Communication Theory

SWT004 Software System Development Theory

ENG005 Engineering Graphics Theory

ELC0006 Principle of Electronics Theory

SWT011 Software System Development Theory

DRW0006 Engineering Drawing Theory

ELC0007 Electrical Engineering Theory

SWT012 Software Testing Theory

SYS0007 System management Theory

DBA008 Database System Theory

SUBJECT_ID SESSION_ID COURSE_ID SEMESTER_ID

MET011 2007-08 MT001 1

CWE011 2009-10 MT001 1

SWE011 2009-10 MT001 1

MTL024 2009-10 MT002 1

ENM023 2009-10 MT002 1

PRM009 2009-10 MT002 1


ALG024 2009-10 MT003 1

PGL024 2009-10 MT003 1

DBMS024 2009-10 MT003 1

GRM009 2009-10 MT004 1

MAUT023 2009-10 MT004 1

CMUN004 2009-10 MT003 1

SWT004 2009-10 MT004 1

ENG005 2004-05 UG005 1

ELC0006 2004-05 UG005 1

SWT011 2004-05 UG005 1

DRW0006 2004-05 UG005 1

ELC0007 2005-06 UG005 1

SWT012 2005-06 UG005 1

SYS0007 2005-06 UG005 1

DBA008 2005-06 UG005 1

SUBJECT AREA: STUDENT

STUDENT_ID ST_FIRST_NAME ST_LAST_NAME ST_MIDDLE_NAME

0007001011001 Amit Pandey Kumar

0009001011002 Suresh Pandey Kumar

0009001011003 Dipu Dolui Kumar

0009001011004 Dipa Das Snigdha

0009001011005 Lisha Ray Sinha

0009002011001 Nilu Pandey Kumar

0009002011002 Anish Dutta Roy

0009002011003 Nilesh Dolui Kumar

0009002011004 Aparna Mohanti Roy

0009002011005 Nila Ray Sinha

0009003011001 Amitav Roy Kumar

0009003011002 Animesh Dolui Kumar

0009003011003 Ajit Hansda Kumar

0009003011004 Natasha Roy Rani

0009003011005 Archana Ray Sinha

0009004011001 Dinesh Tribadi Kumar

0009004011002 Avisek Sengupta Kumar

0009004011003 Nikhil Gain Kumar

0009004011004 Mala Gupta Sen

0009004011005 Susmita Das Nag

0004005011001 Amit Pandey Kumar

0004005011002 Suresh Pandey Kumar

0004005011003 Dipu Dolui Kumar

0004005011004 Dipa Das Snigdha

STUDENT_ID COURSE_ID SESSION_ID DATE_ADMISSION

0007001011001 MT001 2007-08 03/31/2007 00:00:00

0009001011002 MT001 2009-10 03/31/2009 00:00:00

0009001011003 MT001 2009-10 03/31/2009 00:00:00

0009001011004 MT001 2009-10 03/31/2009 00:00:00

0009001011005 MT001 2009-10 03/31/2009 00:00:00


0009002011001 MT002 2009-10 03/31/2009 00:00:00

0009002011002 MT002 2009-10 03/31/2009 00:00:00

0009002011003 MT002 2009-10 03/31/2009 00:00:00

0009002011004 MT002 2009-10 03/31/2009 00:00:00

0009002011005 MT002 2009-10 03/31/2009 00:00:00

0009003011001 MT003 2009-10 04/30/2009 00:00:00

0009003011002 MT003 2009-10 04/30/2009 00:00:00

0009003011003 MT003 2009-10 04/30/2009 00:00:00

0009003011004 MT003 2009-10 04/30/2009 00:00:00

0009003011005 MT003 2009-10 04/30/2009 00:00:00

0009004011001 PG004 2009-10 04/01/2009 00:00:00

0009004011002 PG004 2009-10 04/01/2009 00:00:00

0009004011003 PG004 2009-10 04/01/2009 00:00:00

0009004011004 PG004 2009-10 04/01/2009 00:00:00

0009004011005 PG004 2009-10 04/01/2009 00:00:00

0004005011001 UG005 2004-05 04/30/2004 00:00:00

0004005011002 UG005 2004-05 04/30/2004 00:00:00

0004005011003 UG005 2004-05 04/30/2004 00:00:00

0004005011004 UG005 2004-05 04/30/2004 00:00:00

SUBJECT AREA: KMR

STUDENT_NAME STUDENT_ID S_REGISTRATION_ID SESSION_ID

Amit Kumar Pandey 0007001011001 JU04ENGUG0050001 2004-05

Suresh Kumar Pandey 0009001011002 JU04ENGUG0050002 2004-05

Dipu Kumar Dolui 0009001011003 JU04ENGUG0050003 2004-05

Dipa Snigdha Das 0009001011004 JU04ENGUG0050004 2004-05

Lisha Sinha Ray 0009001011005 JU09ENGMT0010005 2009-10

Nilu Kumar Pandey 0009002011001 JU09ENGMT0020001 2009-10

Anish Roy Dutta 0009002011002 JU09ENGMT0020002 2009-10

Nilesh Kumar Dolui 0009002011003 JU09ENGMT0020003 2009-10

Aparna Roy Mohanti 0009002011004 JU09ENGMT0020004 2009-10

Nila Sinha Ray 0009002011005 JU09ENGMT0020005 2009-10

Amitav Kumar Roy 0009003011001 JU09ENGMT0030001 2009-10

Amitav Kumar Roy 0009003011002 JU09ENGMT0030002 2009-10

Ajit Kumar Hansda 0009003011003 JU09ENGMT0030003 2009-10

Natasha Rani Roy 0009003011004 JU09ENGMT0030004 2009-10

Archana Sinha Ray 0009002011005 JU09ENGMT0020005 2009-10

Dinesh Kumar Tribadi 0009004011001 JU09ENGPG0040001 2009-10 Avisek Kumar

Sengupta 0009004011002 JU09ENGPG0040002 2009-10

Nikhil Kumar Gain 0009004011003 JU09ENGPG0040003 2009-10

Mala Sen Gupta 0009004011004 JU09ENGPG0040004 2009-10

Susmita Nag Das 0009004011005 JU09ENGPG0040005 2009-10


SUBJECT AREA: LIBRARY

M_BOOK_ID BOOK_TITLE NO_OF_COPY AUTHOR PUBLISHER SUBJECT

M00001 Mathematics 5

R.

Grewal JK Publishers

Engineering

Mathematics

M00002 Mathematics 5 P Dutta AK Publishers Mathematics

M00003 Software Engineering 5

Rajib Dutta JK Publishers

Software Engineering

M00004

Data Base

Management System 5

AmitDutta JK Publishers

Data Base

Management System

M_BOOK_ID S_BOOK_ID STATUS PRICE L_CODE EDITION

M00001 SM0001 Issued 235.00 Main001 7th

M00001 SM0002 Issued 235.00 Main001 2nd



M00001 SM0005 Available 235.00 Main001 7th



M00002 SD0008 Reference 235.00 Dep001 7th













STUDENT_ID L_CODE L_CARD_ID STAFF_ID ISSUE_DATE

0007001011001 Main001 LMain011001 NA 06/17/2007 00:00:00

0007001011001 Dep001 LDep011001 NA 06/24/2007 00:00:00

0009001011002 Main001 LMain011002 NA 06/24/2009 00:00:00

0009001011002 Dep001 LDep011002 NA 06/24/2009 00:00:00

0009001011003 Main001 LMain011003 NA 06/24/2009 00:00:00

0009001011003 Dep001 LDep011003 NA 06/24/2009 00:00:00

0009001011004 Main001 LMain011004 NA 06/24/2009 00:00:00

0009001011004 Dep001 LDep011004 NA 06/24/2009 00:00:00

0009001011005 Main001 LMain011005 NA 06/24/2009 00:00:00

0009001011005 Dep001 LDep011005 NA 06/24/2009 00:00:00

0009002011001 Main001 LMain02011001 NA 06/24/2009 00:00:00

0009002011001 Dep001 LDep02011001 NA 06/24/2009 00:00:00


0009002011002 Main001 LMain02011002 NA 06/24/2009 00:00:00

0009002011002 Dep001 LDep02011002 NA 06/24/2009 00:00:00

0009002011003 Main001 LMain02011003 NA 06/24/2009 00:00:00

0009002011003 Dep001 LDep02011003 NA 06/24/2009 00:00:00

0009002011004 Main001 LMain02011004 NA 06/24/2009 00:00:00

0009002011004 Dep001 LDep02011004 NA 06/24/2009 00:00:00

0009002011005 Main001 LMain02011005 NA 06/24/2009 00:00:00

0009002011005 Dep001 LDep02011005 NA 06/24/2009 00:00:00

0009003011001 Main001 LMain03011001 NA 06/24/2009 00:00:00

0009003011001 Dep001 LDep03011001 NA 06/24/2009 00:00:00

0009003011002 Main001 LMain03011002 NA 06/24/2009 00:00:00

0009003011002 Dep001 LDep03011002 NA 06/24/2009 00:00:00

0009003011003 Main001 LMain03011003 NA 06/24/2009 00:00:00

0009003011003 Dep001 LDep03011003 NA 06/24/2009 00:00:00

0009003011004 Main001 LMain03011004 NA 06/24/2009 00:00:00

0009003011004 Dep001 LDep03011004 NA 06/24/2009 00:00:00

0009003011005 Main001 LMain03011005 NA 06/24/2009 00:00:00

0009003011005 Dep001 LDep03011005 NA 06/24/2009 00:00:00

0009004011001 Main001 LMain04011001 NA 06/24/2009 00:00:00

0009004011001 Dep001 LDep04011001 NA 06/24/2009 00:00:00

0009004011002 Main001 LMain04011002 NA 06/24/2009 00:00:00

0009004011002 Dep001 LDep04011002 NA 06/24/2009 00:00:00

0009004011003 Main001 LMain04011003 NA 06/24/2009 00:00:00

0009004011003 Dep001 LDep04011003 NA 06/24/2009 00:00:00

0009004011004 Main001 LMain04011004 NA 06/24/2009 00:00:00

0009004011004 Dep001 LDep04011004 NA 06/24/2009 00:00:00

0009004011005 Main001 LMain04011005 NA 06/24/2009 00:00:00

0009004011005 Dep001 LDep04011005 NA 06/24/2009 00:00:00

NA Main001 LMain005011001 005011001 06/24/2005 00:00:00

NA Dep001 LDep005011001 005011001 06/24/2005 00:00:00

NA Main001 LMain006011002 006011002 06/24/2005 00:00:00

NA Dep001 LDep006011002 006011002 06/24/2006 00:00:00

NA Main001 LMain003011001 003011001 06/24/2003 00:00:00

NA Dep001 LDep003011001 003011001 06/24/2003 00:00:00

NA Main001 LMain003011002 003011002 06/24/2003 00:00:00

NA Dep001 LDep003011002 003011002 06/24/2003 00:00:00

NA Main001 LMain104011001 104011001 06/24/2003 00:00:00

NA Dep001 LDep104011001 104011001 06/24/2003 00:00:00

S_BOOK_ID L_CARD_ID ISSUE_DATE DUE_DATE SUBMISSION_DATE STATUS

SM0001 LMain011002

06/16/2009

00:00:00

06/23/2009

00:00:00 06/23/2009 00:00:00 Submitted

SM0001 LMain011002 04/24/2010

00:00:00 05/01/2010

00:00:00 Due

SM0002 LMain011002 04/24/2010

00:00:00 05/01/2010

00:00:00 Due

SM0003 LMain011002

04/20/2010

00:00:00

04/28/2010

00:00:00 Overdue


SM0004 LMain011002 04/20/2010

00:00:00 04/28/2010

00:00:00 Overdue

SM0006 LMain02011001

04/27/2010 00:00:00

05/03/2010 00:00:00 Due

SM0011 LDep02011001

04/27/2010

00:00:00

05/03/2010

00:00:00 Due

SM0012 LDep02011002 04/27/2010

00:00:00 05/03/2010

00:00:00 Due

SD0013 LMain02011003

04/27/2010 00:00:00

05/03/2010 00:00:00 Due

SM0016

LMain0201100

5

04/27/2010

00:00:00

05/03/2010

00:00:00 Due

SM0017 LDep02011005 04/27/2010

00:00:00 05/03/2010

00:00:00 Due

SM0014 LMain03011001

04/13/2010 00:00:00

05/19/2010 00:00:00 05/19/2010 00:00:00 Submitted

SM0019 LDep02011005

04/13/2010

00:00:00

05/19/2010

00:00:00 05/19/2010 00:00:00 Submitted

SUBJECT AREA: STUDENT ASSESSMENT

ASSESMENT_ID SESSION_ID SUBJECT_ID ASS_MODE ASSESS_TYPE SEMESTER_ID

E-MET011 2009-10 MET011 Semester Exam Regular 1

CT01-MET011 2009-10 MET011 Class Test Regular NA

CT02-MET011 2009-10 MET011 Class Test Regular NA

E-ENM023 2009-10 ENM023

Sessional

Exam Regular 1

E-MTL024 2009-10 MTL024 Semester Exam Regular 1

E-SWE011 2009-10 SWE011 Semester Exam Regular 1

E-CWE011 2009-10 CWE011

Semester

Exam Regular 1

E-PRM009 2009-10 PRM009 Semester Exam Regular 1

E-ALG024 2009-10 ALG024 Semester Exam Regular 1

E-PGL024 2009-10 PGL024

Sessional

Exam Regular 1

E-DBMS024 2009-10 DBMS024 Semester Exam Regular 1

E-GRM009 2009-10 GRM009 Semester Exam Regular 1

E-MAUT023 2009-10 MAUT023

Semester

Exam Regular 1

E-CMUN004 2009-10 CMUN004 Semester Exam Regular 1

E-ENG005 2004-05 ENG005 Semester Exam Regular 1

E-ELC0006 2004-05 ELC0006

Semester

Exam Regular 1

E-SWT011 2004-05 SWT011 Semester Exam Regular 2

E-DRW0006 2004-05 DRW0006 Semester Regular 2


Exam

E-ELC0007 2005-06 ELC0007 Semester Exam Regular 3

E-DBA008 2005-06 DBA008 Semester Exam Regular 4

E-SYS0007 2005-06 SYS0007

Semester

Exam Regular 4

E-SWT012 2005-06 SWT012 Semester Exam Regular 3

STUDENT_ID SESSION_ID SEMESTER_ID SGPA STATUS ATTEMPT

0004005011001 2004-05 1 9 P 1

0004005011001 2004-05 2 9 P 1

0004005011001 2005-06 3 8 P 1

0004005011001 2005-06 4 9 P 1

0004005011002 2004-05 1 7.5 P 1

0004005011002 2004-05 2 7 P 1

0004005011002 2005-06 3 8 P 1

0004005011002 2005-06 4 8.5 P 1

0004005011003 2004-05 1 8 P 1

0004005011003 2004-05 2 8 P 1

0004005011003 2005-06 3 8 P 1

0004005011003 2005-06 4 8.5 P 1

0004005011004 2004-05 1 7.5 P 1

0004005011004 2004-05 2 7 P 1

0004005011004 2005-06 3 7 P 1

0004005011004 2005-06 4 7 P 1

0009001011002 2009-10 1 8 P 1

0009001011003 2009-10 1 7.66 P 1

0009001011004 2009-10 1 6.66 P 1

0009001011005 2009-10 1 6.66 P 1

0009002011001 2009-10 1 7 P 1

0009002011002 2009-10 1 6.66 P 1

0009002011003 2009-10 1 8 P 1

0009002011004 2009-10 1 8.33 P 1


0009002011005 2009-10 1 NA XP 1

STUDENT_ID

COURSE_ID

SESSION_ID

DGPA STATUS ATTEMPT

PERCNT_OF_

MARKS_OBTAINED

00040050

11001 UG005 2004-05 8.75 Complete 1 87.50 0004005011002 UG005 2004-05 7.75 Complete 1 77.50

0004005011003 UG005 2004-05 8.15 Complete 1 81.50 00040050

11004 UG005 2004-05 7.15 Complete 1 71.50


APPENDIX III: SCREEN SHOTS

Below are some of the screen shots for the reports generated by reporting tool

Business Object and Sqlplus :

Construction of the report template:

Report for Student Promotion( Test Case1) from BO:

Report for Student Promotion( Test Case1) from Sqlplus:


Report for Course Fees Submission( Test Case2) from BO:

Report for Course Fees Submission( Test Case2) from sqlplus:

Report for Course Reassessment ( Test Case3) from BO:


Report for Course Reassessment ( Test Case3) from sqlplus:

Report for book availability ( Test Case4) from BO:

Report for book availability ( Test Case4) from sqlplus:


Report to check the course wise count of students who are using the library

( Test Case12) from BO:


( Test Case12) from sqlplus:


Report to check How many out-of-state students are availing the course(

Test Case19) from BO:


( Test Case19) from sqlplus:

an integrated data model approach for e …fumblog.um.ac.ir/gallery/804/an integrated data model...

Documents