4. To demonstrate the analysis and development of
Accounts Department Computerization Software.
Aim
PPROLOGUEROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
5. Technical
Audience
PPROLOGUEROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Programmers / System Analysts / Project Managers / Database Designers
/ Post Graduate Students / People concerned with Educational Institutions
Accounts and all those willing to take up the challenges of Information
Systems Design
6. Dr. A. K. Ramani
Prof. & Head, School of Computer Sc., & IT,
DEVI AHILYA UNIVERSITY
www.scs.dauniv.ac.in
Project Guide
PPROLOGUEROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
8. Project Initiation
PPROLOGUEROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Need :
a. Accounting work is tedious.
b. A huge amount of money is involved.
c. Error is not tolerable.
Requirement :
a. A system which can make the work simple.
b. Make the accounting work less error prone.
c. Have the reports as fast as possible.
9. Project Development
PPROLOGUEROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Follow the Database approach to Information
Systems Design and Development.
• External Schema
• Conceptual Schema
• Logical Schema
• Physical Schema
• Implementation
10. Organizational Scenario
Problems with the existing system
Functionality of the organization
Information Systems Architecture
Enterprise Data Model
The External Schema
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
11. The institute – business entity whose major
function is to provide education
Accounts Department – Unit of IIPS
concerned with all the accounting work (work
related to finances)
Accounts Department’s zone of influence is
institute wide – hence, it’s efficient working is
a must as any failure will have institute wide
repercussions.
Organizational Scenario
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
12. Major Divisions in the Accounts Section –
Income : mainly fees collection , other sources of income include
collection from people other than students, fines, revaluation fees,
etc.
Expenditure : concerned with any and all kind of expenditure work
relating to the institute. Such expenditure includes Electricity and
Water Bills, Salaries to staff and Honorarium to Visiting Faculty
and Guests, Books, Furniture, Equipment, Computers, etc.
Cash Book Maintenance : a daily statement of the income and
expenditure. This cash book is a basic compilation of the income
and expenditure.
Entirely manual
A similar entry is made at possible three places (ex. Fees
Receipt, Daily Fees Collection and Student Fees Record)
The maintenance of these ledgers and proper compilation of data
is difficult and cumbersome.
There is no timely presentation of facts
Organizational Scenario ( contd.)
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
13. Strategic Planning Factors
Goals
Develop a preliminary understanding of the business situation .
Develop a model for Fees Collection, Expenditure, salary and cash book
Document existing system .
Analyze the functions involved in the running of the existing system and their
database needs.
Develop an application that automates and extends the traditional system
Critical Success Factors
Ease of operation
Minimal need for intervention:
Availability of updated records
Management Support
Problem Areas
Fast Response
Security
Backups and Contingency Plans
Maintenance of records
Information Systems Architecture
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
14. Corporate Planning Objects
Organizational Units
Income
Expenditure
Cash Book Maintenance
Organizational Locations : single organizational location
Business Functions
Income
Fees Receipts
Fines and other receipts
Reports – Daily Fees Collection , Student Fees Record , Demand Draft List , No
Dues , List of Students who have paid Fees
Expenditure
Cheque Issuing Register
Maintenance of Ledgers for various expenditure heads
Salaries for faculty and staff
Visiting Faculty Honorarium
Maintenance of Cash Book
Information Systems Architecture…
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
15. STUDENT
STUDENT FEES RECORD
OTHER INCOME RECORD
DAILY FEES COLLECTION
STAFF
CHEQUE ISSUING REGISTER
LEDGER
SALARY & INCOME TAX STATEMENT
The Entities
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
16. Fees Receipt
Receipt Generation
Daily Fees Collection Book
Individual Student Financial Record
Foreign Currency Register
Expenses
Cheque Issuing/Payment Register
Head of Expenditure
Cash Book Maintenance
Salary and Income Tax Slips for IIPS faculty and staff
Student Record Maintenance
Staff Record Maintenance
Login and Registration Services
Information Systems
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
17. The Enterprise Data Model
PROLOGUE
EEXTERNALXTERNAL SSCHEMACHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
ExpenditureExpenditure
Head
Fees Record
Daily Fees
Collection
(DFC)
Register
entered in
generated for
Other Receipt
Record
contains
Cash Book
entered in
Is under
entered
in
entered in
StaffSalary Slip Income
Tax Slip
generated for
Ledger
updates
Visiting
Faculty
contains
19. STUDENT
STUDENT FEES RECORD
OTHER INCOME RECORD
DAILY FEES COLLECTION
STAFF
CHEQUE ISSUING REGISTER
LEDGER
SALARY & INCOME TAX STATEMENT
The Entities Revisited
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
20. Entities Revisited (contd.) – New Entities Added
LOGIN – for user authentication
COURSES – information about the various
courses and their roll information
FCREGISTER – to keep track of Foreign
Currency
SEMFEES – to note the fees of each batch’s
semester, category wise
OTHERRECEIPTS – to keep track of Cash
incomes
HEADS OF EXPENDITURE – which heads
of expenditure are allowed
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
21. Relationship Definitions
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUEIncome
Entities
Student Student
Fees
Record
Other
Receipts
Daily Fees
Collection
DD List Foreign
Currency
Register
Category Course Sem
Fees
Cash
Book
Student is for belongs to enrolle
d for
Student
Fees
Record
is for entered
in
alters
Other
Receipts
entered
in
Daily Fees
Collection
entered
in
generates updates
DD List generate
s
Foreign
Currency
Register
alters depends
on
Category belongs to depends
on
Course enrolled
for
depend
s on
Sem Fees depends
on
depends
on
Cash Book updates
22. Relationship Definitions
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Expenditure
Entities
Expendit
ure
Expenditu
re Head
Visiting
Faculty
Ledger Staff Salary Slip Income Tax
Slip
Cash
Book
Expenditure is for updates entered
in
Expenditure Head is for contains contains
Visiting Faculty contains
Ledger update
s
Staff contains generated
for
generated
for
Salary Slip generated
for
Income Tax Slip generated
for
Cash Book entered
in
24. Definitions of Attributes
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
NAME DOMAIN DESCRIPTION NULL
Enrollment Number Enrollment Number
Identifies each and every student of the
university uniquely
No
Roll Number Roll Number
Identifies each student of the institution
uniquely
No
Program Program
Program for which the student is
enrolled in the institute
No
Course Program
Program for which the student is
enrolled in the institute
No
ID Identification ( 2 Chars )
Identifies each course by characters
(ex. MCA by ‘IC’,etc.)
Batch Number The year in which the student has joined
Category Category Category of the Student No
Name Name Name of the Student No
Father’s Name Name Name of the Father of the Student No
Permanent Address Address Permanent Address of the Student No
Permanent Telephone
Number
Telephone Number
Permanent Telephone Number of the
Student
Local Address Address Local Address of the Student No
25. Definitions of Attributes contd…
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Local Telephone Number Telephone Number Local Telephone Number of the Student
Caution Money Amount Caution Money that the student has deposited No
Caution Money Refund Boolean
Indicates whether the caution money has been
returned or not
No
Semester Semester Semester w.r.t. a program No
DFC Number Number Number in the Daily Fees collection Register No
Fees Amount Indicates the amount of fees No
Due/Excess Fees Amount Indicates any due or excess fees
Tuition Fees Amount Indicates the amount of tuition fees
Caution Money Amount Indicates the amount of Caution Money
Library Fees Amount Indicates the amount of Library fees
Hostel Fees Amount Indicates the amount of Hostel fees
Sports Fees Amount Indicates the amount of Sports fees
Placement Fees Amount Indicates the amount of Placement fees
University Fees Amount Indicates the amount of University fees
26. Examination Fees Amount Indicates the amount of Examination fees
Misc Fees Amount Indicates the amount of Misc. fees
Library Fine Amount Indicates the amount of Library fine collected
Hostel Fine Amount Indicates the amount of hostel fine collected
Other Fine Amount Indicates the amount of other fine collected
Remarks Text Remarks
Date Date Indicates a particular date No
Serial Number Number The Serial Number of a register No
Receipt Number Number The Receipt Number of some fees No
Demand Draft Number DD Number The Demand Draft Number for any fees deposited No
Demand Draft Date Date Date of issue of the Demand Draft No
Bank Name and Branch
Bank Name &
Branch
The name and branch of the bank issuing the
demand draft
No
US$ Fees Amount Fees paid in US $ by any student
Total Fees Amount Total Fees paid No
Employee Number Identification Identifies every employee uniquely No
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Definitions of Attributes contd…
27. GpI Amount Amount of Group Insurance deducted
IT Amount Amount of Income Tax deducted
Loan Inst Amount Amount of Loan Installments deducted
Misc Subtractions Amount Amount of misc subtractions
Total Salary Amount Amount of total salary payable No
Cheque Number Chq Number
The Cheque number through which any payments are
made
No
Cheque Date Date Date in which Cheque was issued No
Identification Identification Identifies each expenditure head uniquely No
Head of
Expenditure
Text Heads of expenditure No
Budget provision Amount Budget provision for that head of expenditure No
Balance Amount Balance amount left in the budget provision No
Cheque Book
Number
Number Identifies each Cheque book uniquely No
Name of
firm/person
Text Name of firm/person to whom the Cheque is issued No
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Definitions of Attributes contd…
28. Purpose Text Purpose of issuing the Cheque No
Date of Bill Date Date of the bill No
Order Number Number Order Number corresponding to the bill No
Voucher
Number
Number
Voucher Number as corresponding to the entry in
the cash book
No
Serial Number Number Serial Number in the cash book entry No
Debit Amount Indicates the Debit Amount in Ledger No
Credit Amount Indicates the Credit Amount in Ledger No
UserName Username User Name of the person No
Password Password Password of the person No
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Definitions of Attributes contd…
29. Domain Constraints
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Name Data Type Allowable Characters Format
Enrollment Number Enrollment Number Alphabets and Digits XX-99-999999
Roll Number Roll Number Alphabets and Digits XX-99-999
Program Program None
Program can be of any one of the following :
1. M.C.A. 6 yr.
2. M.M.S. 5 yr.
3. M.M.S. 2yr.
4. B. Com. 3 yr.
Category Category None
Category can be any one of the following
1. Foreign National
2. N.R.I.
3. N.R.I. sponsored
4. Payment
5. Local
6. SC
7. ST
8. OBC
9. Sports
10. DAVV Employee
Name String Alphabets
Address Address Alphabets and Digits
Telephone Number Number 99999………
Amount Amount Digits and decimal point …..999.99
Boolean Boolean Yes / No
30. Semester Semester None
Semester values can range from 1 to 12
depending the program
1.MCA (1-12)
2.MMS 5yr (1-10)
3.MMS 2yr (1-4)
4.B. Com. (1-6)
Number Number Digits 99999…..
Fees Item Fees Item None
Fees Item can be any one of the following :
1.Tuition Fees
2.Caution Money
3.Library
4.Hostel Fees
5.Sports
6.Placement
7.University Fees
8.Miscellaneous
Date Date Digits DD/MM/YYYY
Text String Alphabets and Digits
DD Number Number Digits
Bank Name and
Branch
String Alphabets and Digits
Identification Number Digits
Salary Grade Grade Digits and -
Class Class 1 – 4
Account Number Number Digits
Month Number Digits 1 – Year12
Year Year Digits 9999
Cheque Number Number Digits
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Domain Constraints (contd.)
31. • Business Rule: An entry can be made in the cash book only for an
entry in the Daily Fees Collection or in the Expenditure.
Constrained Object: CASH BOOK (Entity)
Constraining Object: DFC and EXPENDITURE (Entities)
• Business Rule: Monthly Salary and Income Tax slip is not
generated for Visiting Staff.
Constrained Object: Post (Attribute of Staff)
Constraining Object: MONTHLY SALARY SLIP and INCOME TAX SLIP
(Entities).
• Business Rule: Expenditure can only be for a stated Expenditure
Head.
Constrained Object: EXPENDITURE (Entity)
Constraining Object: EXPENDITURE HEAD (Entity).
Operational Constraints
PROLOGUE
EXTERNAL SCHEMA
CCONCEPTUALONCEPTUAL SSCHEMACHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
32. LOGIN
STUDENT FEES RECORD
DAILY FEES COLLECTION
STUDENT
OTHER RECEIPTS
FOREIGN
CURRENCY
REGISTER
SEM FEES
COURSE
CATEGORY
ente
rs
fees
enters
collectio
n
alte
r
depend
s on
is
for
depend
s on
belong
s to
enrolle
d for
enter
ed in
enter
ed in
DD LIST
generate
s
CASH BOOK
update
s
VISITING
FACULTY LEDGER
STAFF EXPENDITURE
entered
in
EXPENDITURE
HEAD
is
und
er
update
scontai
ns
contai
ns
SALARY
SLIP
generate
d for
generate
d for
INCOME
TAX SLIP
R
R
R
Post
R
R
Operational Constraints
EER Model
33. Input Output Screens
Transactions that will be run on the
system
Entity Identification and description
Relational Schema
The Logical Schema
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
34. Fees Receipt
Input Screen – will provide an interface to the user to enter the details of the fees.
Transactions – The system should perform the necessary checks from the
various relations about the data , make entries into the tables concerned ( SFR,
DFC, and Cash Book).
Fees Receipt Output– will be in the form of a printed receipt which will show the
details and amount of fees paid.
Salary Slip and Income Tax Slip Generation
Input Screen – to enter the details of the salary and income tax of various staff
members
Transactions – enter the details in the database (MSS,ITS)
Output – will be in the form of a printed salary and income tax slip
Input / Output Screens and Transactions
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
35. PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Expenditure
Input Screen – to enter the details of expenditure like the name of firm
, particulars , Cheque number, etc.
Transactions – entry into required fields in the database.
Output – No such printed output is generated for every transaction.
Output may be seen in the form of reports.
Record Entry – Record Entry is to provide an interface to enter the
details of persons connected with the system in any way. Such
persons are Students, Staff Members and authorized users of the
system. Once the details of a Student or Staff have been entered, it
requires no further entering in the system.
Input / Output Screens and Transactions
36. PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Reports – The accounts department has to generate a number of
reports either daily, monthly, yearly, or at any given time. Such
reports include
Daily Fees Collection Report – The DFC report include a list of the
fees collected on a daily basis. It contains all the records of the fees
that have been collected on one single day.
Details of Bank Draft Paid – On a daily basis, the drafts are organized
on three basis
Drafts of State Bank of Indore, Bhanvarkuan Branch
Drafts of State Bank of Indore, any other Branch
Drafts of other Banks
These have to be recorded separately and a list has to be prepared.
Daily Expenditure Report – The Daily Expenditure Report includes the
details of all the cheques paid (expenditure is only through cheques) to
any person/firm on the given particular day.
Cash Book – The cash book is to be prepared on a daily basis having
the entries of the incomes and expenditures of that particular day.
Input / Output Screens and Transactions
37. Transforming ER into relations
Functional Dependencies
Normalization
Relational Model
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
38. Transforming ER into Relations
Taking an entity from the EER Diagram
STUDENT FEES
RECORD
Roll
Se
m
Receipt
Number
Old
Receipt
Number
Tuition
Fees
Cautio
n
Money
Library
Fees Hoste
l
Fees
Sports
Fees
Placement
Fees
Examination
Fees
Universit
y Fees
Total
Fees
Paid
Pound Fees
USD Fees
Misc Fees
Bank
Branch
Due/Exces
s
DD Date
DD
Number
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
39. Transforming ER into Relations
The relation that can be made from the entity
ROLL SEM RECEIPTNUMBER OLDRCPTNO TUITION_FEES
CAUTION_MONEY LIBRARY_FEES HOSTEL_FEES SPORTS_FEES
PLACEMENT_FEES UNIVERSITY_FEES EXAMINATION_FEES
MISC USD_FEES POUND_FEES TOTAL_FEES_PAID
DUE_EXCESS DDNUMBER DDDATE BANKBRANCH
STUDENT FEES RECORD
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
40. Similarly, for the entity Student
ROLL NUMBER ENROLLMENT NUMBER PROGRAM NAME
FATHER’S NAME PERMANENT ADDRESS PER. TELEPHONE NUMBER
LOCAL ADDRESS LOCAL TELEPHONE NUMBER CATEGORY
CAUTION MONEY CMONEYREFUND DDNUMBER DDDATE
STUDENT
Transforming ER into Relations (contd.)
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Similarly, other Entities have been mapped in to relation.
42. Functional Dependencies (contd.)
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
ROLL NUMBER ENROLLMENT NUMBER PROGRAM NAME
FATHER’S NAME PERMANENT ADDRESS PER. TELEPHONE NUMBER
LOCAL ADDRESS LOCAL TELEPHONE NUMBER CATEGORY
CAUTION MONEY CMONEYREFUND DDNUMBER DDDATE
STUDENT
The Student relation
Partial Dependency exists. All fields can be determined from both Roll
Number and Enrollment Number. Removed through Normalization.
Total 4 relations contain dependencies.
43. Normalization
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LLOGICALOGICAL SSCHEMACHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EPILOGUE
Only those relations Normalized that have dependencies.
Consider the case of Student as previously given.
ROLL NUMBER ENROLLMENT NUMBER
FATHER’S NAME PERMANENT ADDRESS PER. TELEPHONE NUMBER
LOCAL ADDRESS LOCAL TELEPHONE NUMBER CATEGORY
CAUTION MONEY CMONEYREFUND DDNUMBER DDDATE
STUDENT
ROLL NUMBER PROGRAM NAME
ROLL ENROLL
Similarly for all those relations , normalization was done .
Number of relations became 20
44. Designing Physical Records and
Denormalization
Final Relations
Indexes
The Physical Design
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PPHYSICALHYSICAL DDESIGNESIGN
IMPLEMENTATION
EPILOGUE
45. Designing Physical Records Denormalization
Physical Records is a group of fields stored in adjacent
memory locations and retrieved together as a unit.
Denormalization is the process of transforming normalized
relations into unnormalized physical record specifications.
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PPHYSICALHYSICAL DDESIGNESIGN
IMPLEMENTATION
EPILOGUE
Consider the same entity Student that was Normalized earlier.
Just for removing the dependency, should we store
Enrollment Number separately whereas Enrollment Number is
stored for being printed on the reports ?
Hence, we recombine both the relations back to form the
relation STUDENT
Denormalization reduced the number of relations to 17
46. Final Relations
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PPHYSICALHYSICAL DDESIGNESIGN
IMPLEMENTATION
EPILOGUE
CATEGORY
COURSES
SEM FEES
STUDENT
STUDENT FEES RECORD
OTHER RECEIPTS
DAILY FEES COLLECTION
DD LIST
FOREIGN CURRENCY REGISTER
CASH BOOK
STAFF
EXPENDITURE
EXPENDITURE HEAD
VISTING FACULTY
LEDGER
SALARY SLIP
INCOME TAX SLIP
17 Final Relations that are to be implemented.
47. Sample Indexes
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PPHYSICALHYSICAL DDESIGNESIGN
IMPLEMENTATION
EPILOGUE
Entity : Daily Fees Collection
Index : Date_DFC or ReceiptNumber
Justification : It can be inferred that the
transactions with this relation will take
place in the serial order of the above
attributes.
Entity : Student
Index : Roll Number
Justification :The records of students are
entered as per their roll numbers. The
system will normally use the latest entry of
the roll numbers.
48. • Snapshots of the working system
• Hardware and Software Requirements
Implementation
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IIMPLEMENTATIONMPLEMENTATION
EPILOGUE
49. Implementation
The splash screen
The Login screen
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IIMPLEMENTATIONMPLEMENTATION
EPILOGUE
50. Implementation
The menu options after a successful login
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IIMPLEMENTATIONMPLEMENTATION
EPILOGUE
82. Intel Pentium 3 1 GHz
128 MB RAM
20 GB Hard Disk Drive
other standard Components
Microsoft Windows 2000 Professional
Oracle 8i Enterprise Edition
Microsoft Visual Basic 6.0 Enterprise Edition
Microsoft Word 2000
Microsoft PowerPoint 2000
Hardware and Software Requirements
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IIMPLEMENTATIONMPLEMENTATION
EPILOGUE
83. • Preprinted Stationary – Rs. 3000 /-*
( for 6 months )
• Blank Stationary – approx. Rs.
300 /-* per month
• Manpower – already existent
• Other costs - negligible
Cost vs. Benefit
OPERATIONAL COSTS
• Approx Rs. 1 cr.* deposited one
month earlier.
• Interest savings (earnings ?) for 6
months
• = 1cr. * 10% * 1/12
• = approx. Rs. 88,000 /-* approx.
BENEFITS
Total = Rs. 4,800/-* Total = Rs. 88,000 /-*
FIXED COSTS
• Computer – Rs. 50,000 /-*
• Printer – Rs. 12,000 /-*
BENEFIT IN 1st
YEAR = 1,76,000 – 71600 = 1,04,400 /-*
BENEFIT IN 2nd YEAR onwards =1,76,000 –9600 = 1,66,400/-*
* Monetary values are approximate and may not correspond with
actuals.
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
84. Other Benefits
‘My job has been made easier. I don’t have to do same entry n
number of times’
- Bhupendra Verma , Accountant
‘This is the first time that I can exactly state how much fees has been
collected on a daily basis and I know that there are three students as
of now who have not paid their fees till date’
- Dr. A. K. Ramani , Director
‘Receipt looks nice’
- Vivek Thakore , MCA X Sem
‘It’s good to know that something that we have done is of benefit to
our institute.’
- Jyandeep Tripathi and Vijyendra , Development Team
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
85. Payment of fees through various counters –
seems nice, but does the current system
require it ?
Data Warehousing and Implementation for
Decision Support Systems
Mobile Version Implementation – let parents
know whether their wards have paid the
fees or not . Depends on technological
advancement. A far fetched idea.
Providing a web based interface for
depositing fees as well as viewing other
financial information.
Future Enhancements and known issues
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
86. References
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
• Understanding SQL
By Martin Gruber
Sybex BPB Publications
ISBN : 81-7029-644-7
• Oracle 8 The Complete Reference
By George Koch , Kevin Loney
Tata McGraw Hill ( Oracle Press Edition )
ISBN : 00-7463-229-9
• Database Systems Concepts ( Third Edition )
By Abraham Silberschatz , Henry F. Korth , S. Sudarshan
The McGraw Hill Companies Inc.
ISBN : 00-7044-756-X
• Mastering Visual Basic
Evangelos Petrousos
BPB Sybex Publications
ISBN : 81-7656-031-6
• Modern Database Management ( Fifth Edition )
By Fred R. McFadden , Jeffrey A. Hoffer , Mary B. Prescott
Addison Wesley Longman , Pearson Education Asia
ISBN : 81-7808-085-0
• Accounting information Systems
By Martin Gruber
Sybex BPB Publications
ISBN : 81-7029-644-7
• Interaction with the accounts
department personnel , staff members
and students of the institute.
87. Lessons Learned
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
Always commit to what the user wants – you
may have a better and technically more sound
idea, but customer is the king.
Avoid Scope Creep. – know the requirements
beforehand and have a sign off before
developing the product.
Find if training is to be provided – develop help
manuals and delegate this task to someone
who can do it better.
Have a good knowledge of the tools that are
anticipated to be used in the software
development.
,etc.
88. Skills Discussion
PROLOGUE
EXTERNAL SCHEMA
CONCEPTUAL SCHEMA
LOGICAL SCHEMA
PHYSICAL DESIGN
IMPLEMENTATION
EEPILOGUEPILOGUE
After successfully implementing Database Projects , the following skills can
be said to have been developed
Business Systems Understanding ( knowing that a change is required
and it will be a positive change) .
Business Systems Modeling ( understanding the current systems,
understanding the alterations / modifications and properly documenting
the proposed system )
Using computer based tools to map the business model
Overseeing the implementation
Providing training to personnel
Additional skills attained
Project Management Skills.
Intelligence , tact , communications , etc.
Proper understanding of the tools that will be used for developing the
system
The art of making the consumer happy.
89. Thank You
International Institute of Professional Studies
Devi Ahilya University
Khandwa Road Campus, Indore – 452001, M.P., India
www.davv.ac.in http://dauniv.ac.in www.iips.edu
iipsedu@sancharnet.in
Notes de l'éditeur
Hello friends ,
Today’s topic for discussion is the accounts department software development for educational institutes. The accounts software for an educational institution poses some additional typical challenges in that the traditional system is unable to handle. We shall see them in the slides that will follow.
I will be taking up the case study of Accounts Department Computerization Initiative undertaken at the International Institute of Professional Studies, that is, IIPS. IIPS is a premier educational institute located at Indore imparting quality education in the field of Computer Science and Management. It is an autonomous educational Institute of the Devi Ahilya University. The oldest programmes that are running at IIPS are the integrated 6 year Masters in Computer Applications and the 5 year integrated Masters in Management Sciences. Some new programmes have also been started like the MTA , MAPRM and B Com (Hons).
This presentation will be all about how the accounts software of the IIPS was designed and implemented following the database approach to the design and implementation of information systems.
The presentation outline is as follows.
I will be introducing this presentation in the prologue which will include the aim, the expected audience, the project guide, the team members, the need and requirement of the project and the development methodology used.
Following this I will shift to the External Schema which will aim at documenting the existing system while simultaneously highlighting the need for a new system and preparing the Enterprise Data Model for the new System.
The conceptual Schema will take over the documented new system to be implemented and will lead to a model of the new system to be developed. The Entity Relation Diagram will be an outcome of this stage which we will discuss in detail.
The logical Schema will be a software oriented implementation of the conceptual schema and will lead to the development of the relations that should be implemented. Normalization of such relations identified will be done so as to reduce the anomalies during the implementation.
The physical schema will highlight the Denormalization of the relations .
The implementation will show the snapshots of the actual working system. All the menus will be discussed in detail.
And finally, I will conclude with a cost benefit analysis of the information system developed and benefits that the various stakeholders have achieved by the use of this system.
Now let me introduce this presentation to you.
The aim of this presentation is to demonstrate the analysis with design and development of the Accounts department computerization software at IIPS. I believe the situation will be nearly the same for all educational institutes in India with slight modifications to what has been developed to suit individual needs.
The recommended audience for this presentation is ……
The project guide is Prof. A. K. Ramani , BE ME PhD , Director of the IIPS , DAVV.
The team members for developing this project were Jyandeep Tripathi and myself Vijyendra Singh Niranjan
Now let us come to the need for automating the accounting the process. The needs of developing this software are
a.
b.
c.
The major broad based requirements that were identified from the main stakeholders of this system are
a.
b.
c.
In developing this software, the team has followed the Database approach to information systems design and development, the major part of which are :
1.
2.
3.
4.
5.
Now I will come to the External Schema. The external Schema consists of the following five parts
1
2
3
4
5
We will discuss each of them one by one.
The organizational Scenario.
Before developing any database oriented system, the organization scenario of the automation task is studied and documented in detail. Here are the major points of the organizational scenario that were documented.
1
2
3
The accounts department can be divided into the following major sections
Income
Expenditure
Cash Book
The major disadvantage of the system results from the fact that it is an entirely manual system which is of traditional inheritance. Hence,
1.
2.
3.
These and many other disadvantages call for a change in the traditional system.
Now, we will discuss the strategic planning factors . SPF consists of three parts – the goals , the critical success factors and the problem areas in development of the system.
The goals
The Critical Success Factors
The problem areas are
In the corporate planning objects we identify the broad organizational units , the organizational locations – whether a single or a distributed location and the business functions .
Entities are any person , place , object or event of interest to the organization .
The broad level entities that have been identified are as follows.
These are not the final entities as there may be changes during the system development as we will see shortly.
The information systems that are to be developed are documented as follows :--
The EDM is the final stage of the External Schema . This EDM identifies how the organization works and how the tasks or the entities are dependent on each other.
Here we can notice a broad distinction between the income section and the Expenditure section with the Cash Book providing a connection between them.
Now let us come to the conceptual schema.
In conceptual schema we will discuss the entities in detail, following which we will discuss the relationship between the entities. This will lead to the relationship definitions following which the structural and the operational constraints will be identified.
All this will lead to the development of an Enhanced Entity Relation Model.
The entities shown above are the broad level entities that have been identified during the earlier phase of the external schema. But are these enough ? We will find that we require some more entities to map our system.
Thus some of the new entities added are shows .
Login is added because any computerized information system must have a proper authentication mechanism.
In the EDM, we had seen that the income and the expenditure entities were separated by the cash book. Here we define the relation amongst the income entities .
For example – a Student Fees record is for a student .
a Student belongs to a Category
a student is enrolled for a Course
Similarly we define the relationship amongst the expenditure entities as shown.
Expenditure is under an Expenditure Head
Expenditure updates a Ledger
Expenditure is entered in Cash Book
No we come over to the structural constraints . The structural constraints consists of the following three parts
1.
2.
3.
We will discuss each one of them in the following slides.
Definition of Attributes :
in this step, we define all the attributes irrespective of their entities. Such a definition includes the Name of the attribute , it’s domain, a short description and whether it can hold a null value or not.
Ex. Enrollment Number has the domain Enrollment Number , this domain will be described shortly – it identifies each and every student of the university uniquely and can never be null for this system.
The list of attributes surely increases linearly with the increase in the number of entities in the system.
Now, we define the domain constraints for each domain listed in the attribute table. The definition of the domain constraints is given by the Name of domain , the Data type , The allowable characters and the format.
For example – taking the Enrollment Number domain – the format is predefined for the Devi Ahilya University as being of the format – XX-99-999999 like DC-97-059834
The domain constraints are continued.
The Operational Constraints :- The operational Constraints identify the constraints that affect the business.
Let us take the business rule -An entry can be made in the cash book only for an entry in the Daily Fees Collection or in the Expenditure.
Here the Constrained Object is the CASH BOOK (Entity)
And the Constraining Object is the DFC and EXPENDITURE (Entities)
This is the Enhanced entity relation diagram for the system to be developed.
/// As in the EDM here also we can see a distinction between the income entities and the expenditure entities.
As there is a shortage of space, we were not able to fit in the attributes of the entities.
The EER model marks the end of the conceptual phase. We will use this EER model to develop our system further is the logical and the physical schemas.
// describe the entities as the model proceeds.
In the logical schema, we have the following major points :
1.
2.
3.
4.
We will discuss them all in detail in the coming slides.
The input / output screens and transactions are shown as follows
// read ,
// read
// read
In the relational model, we first transfer the ER diagram into relations, following which we identify the functional dependencies between the attributes of relation and then normalize the relations so that there are no dependencies.
As there are a large number of entities , it is not possible to discuss the above procedure with all of them, so, we will just take an example of each of the process.
In the step of the transforming of the entities from the ER into relations, we pick up an entity from the ER diagram. Let us take the Student Fees Record entity. The entity looks like the one described above.
Converting the entity to a relation, we get the following relation.
Similarly, we can do the same for the entity student.
Let us consider the entity DD LIST . This entity has the attributes : DD DATE , DD Number , Bank and Branch , Amount and Print Date .
We can see that this entity has no partial dependency as all the attributes are fully functionally dependent on the primary key.
If we take the case of the entity Student , we find that a partial dependency exists as all fields can be determined by both Roll Number and the Enrollment Number.
This partial dependency may lead to anomalies.
In the normalization process , we break relations that have partial dependencies.
We can break the relation student into the relations Roll Enroll and Student as shown.
The process of normalization completed the phase of the Logical Schema.
The step of physical design consists of the following three parts
1.
2.
3.
We will discuss each one of them in detail in the slides that will follow.
// read
The final relations that are to be implemented are as follows . There are 17 final relations in all that will be required to implement the system under discussion.
Indexes are required for faster access of data.
Considering the entity Daily Fees Collection, we can have an index on the DAtE_DFC of the Receipt Number.
The process of identifying the final relations and the indexes completes the physical design process.
In the implementation section , I will show you the snapshots of the actual working system followed by the hardware and the software requirements for the development of this system.
The splash screen and the login screen .
Only those users who have proper authorization by a user name and a password can use this system.
These are the menu options for the income part of the system. The various sub items of the menus and their use is discussed further.
Fees receipt is the screen that is used to print a receipt to a student who has paid the fees. The receipt of fees is in the form of a demand draft only.
After entering the roll number, the information about the student appears on the right hand side. The other details are filled by the operator.
This is how the fees receipt looks like.
For entering receipts from other persons, this form is used. Here , receipts can also be made for any cash receipts.
For reprinting a receipt or for canceling it, only the receipt number is required.
For the entry of student record and for modifying it, a multipurpose form has been made which allows the addition of new records, deletion of records and modification of existing records.
The fees information entry has a provision for entry of fees for each batch , course , year ( for graduation and post graduation) and the categroy.
The fees collected during a particular duration can be seen through the fees collection report
The fees collection report also shows fees collected in foreign currency as shown.
We also have a provision for providing the list of students who have not deposited their fees as of yet, by entering the batch number and the semester for the fees collection duration.
We can also see a list of the students who have paid their fees and in how much quantity.
These are the menu items of the expenditure section . We will discuss them one by one.
The staff information entry has a provision for entering the details of the staff that is required for the purpose of the accounts . This includes the type of staff , name , designation and the a/c number along with the salary details.
The information can also be edited if there is a change in the designation , account number or the salary details.
We can enter the various budget heads. There are 47 fixed budged heads and other can be entered from 48th number onwards.
The budget head list shows the various budget heads along with the provision and the balance remaining.
The cheque issuing register is used for issuing cheques for various expenses of the institute.
We have provided a separate section for entering salary . The one shown above is for the visiting faculty salary.
For the salary entry , we just provide the month , year and the type of the faculty .---
Following which we can iterate through all the staff members of that category of staff
If any additional payment is to be provided to the staff , it can be done through the additional salary entry.
Advances are given to various persons for carrying out the work of the institute . A record of all the advances given out are maintained.
When the advances are settled, the information is entered if any excess expenditure is done and a cheque is issued, else a receipt number is entered verifying that excess amount has been deposited.
The salary slips to the staff members are also issued in the format shown.
A salary report , Income tax report , Provident Fund report and the individual faculty salary report can also be viewed.
The salary report for a particular month for a particular category of staff can be viewed.
How much income tax was cut from the salary of the staff members for a particular month can also be displayed.
Same is the case with the provident fund.
We can also see the salary details of individual staff members regarding all payments made to them till date.
This is the format of the cheque issuing report giving details of all expenditure incurred during each particular day.
This is the format of the cash book showing the incomes and expenditure for a particular day.
The implementation of this system had the following requirements :
read.
This marks the end of the implementation phase .
Each information to be of benefit to the organization must result in a net monetary benefit. The cost and benefit analysis in monetary terms for this information system can be made as follows.
Thus , we find that there is a net monetary gain for the organization.
There are other benefits apart from the monetary aspect . These are best recollected by the experiences of persons associated with the system ..
Read
No information system can claim to the best in itself and complete. There are always some enhancements that can be made to it. Here are some of them that the development team has identified.
Read
The references :
1. McFadden , Hoffer and Prescott offer a very interesting reading of the database development process and their process is very simple and good and is a required reading for any database oriented information systems developer.
2. Korth and associates are a standard reading on the database concepts
3. Mastering Visual Basic was very helpful along with MSDN library on the nitty gritty aspects of visual basic programming.
4. Reading Koch and Loney provided a help on the database implementation aspect using oracle.
5. Understanding SQL is a very simple reading for learning SQL commands and their intricacies.
6. Some sections of the Accounting Information System provided help on how to develop an automated accounting system
7. and finally, the most important help was provided by the various stakeholders of the projects – The Director of the institute , the accounts staff , the teachers and students of the IIPS.
It is always a good practice to document the lessons learnt during the project and a comprehensive list is built up at the end. The most important lessons that were learnt by the development team during the implementation of the system are as follows
1.
2.
3.
4.
Read.
This marks the end of todays discussion. For any furthur queries and comments, please contact at the above addresses. Thank you.