MIS605 Assessment 2 Additional Case Information
Mis605 Assessment 2 Additional Case Information
In a Joint Application Development (JAD) session, the representatives of the Student Enrolment Officers and the Program Directors provided the following business rules:
- A Course can contain one or more Subjects.
- A Subject may belong to one or more Courses.
- There are one or more classes running for each Subject.
- One Class is delivered on one campus.
- One campus may run one or more Classes.
- A Program Director may be responsible for one or more Courses.
- One Course is under the responsibility of one and only one Program Director.
- A student must undertake a minimum of one Subject per Trimester.
- A student must undertake no more than five (5) Subjects per Trimester.
- A Class contains multiple students.
ABCU IT Support also provided:
- The System needs to be synchronized with Blackboard; enrolled students will be automatically added to the correct Subject in Blackboard.
- Student and staff login credentials are stored in a central database external to the System.
Paper For Above instruction
The development of an online student enrolment system for ABC University necessitates comprehensive process and data modelling to ensure it effectively meets the institution’s operational and strategic needs. This paper articulates the process and data diagrams, including context diagrams, data flow diagrams at various levels, an entity relationship diagram, and the subsequent physical database design, grounded in the detailed business rules and functional requirements provided.
Introduction
ABC University has experienced unprecedented growth, with over 50,000 students distributed across four campuses, necessitating the implementation of an efficient, automated enrolment system. The current manual process is labor-intensive and prone to errors, prompting the need for a system that automates course registration, fee payments, timetable management, and synchronization with external platforms like Blackboard. To realize these goals, proper modelling of business processes and data entities is crucial for designing a scalable, reliable system aligned with university policies and user needs.
Context Diagram
The context diagram provides an overarching view of the system, its external entities, and data exchanges. The primary external entities include Students, Student Enrolment Officers, Program Directors, Blackboard, and Campuses. Students interact with the system to Enrol in Subjects, view timetables, and make payments. Student Enrolment Officers manage courses, subjects, and student data. Program Directors oversee course offerings and update course information. Blackboard integration involves data synchronization concerning student enrolments. Campuses provide physical locations for classes and class schedules. The system facilitates login, data validation, processing enrolment requests, timetable generation, fee payment, and communication via email reminders, ensuring seamless data flow among these entities.
Level 0 Data Flow Diagram
The Level 0 DFD expands on the context diagram, illustrating high-level processes such as Student Management, Course Management, Enrolment Processing, Timetable Management, Payment Processing, and Notification Management. Data flows include Student Details, Course and Subject Information, Enrolment Requests, Schedule Data, Payment Data, and Reminders. Data stores support persistent storage of Student Records, Course Details, Enrolment Data, Timetables, and Payment Records. The diagram emphasizes process interrelations, data exchanges, and storage, offering stakeholders a clear understanding of system operations.
Level 1 Data Flow Diagrams
Three key processes—Enrolment Processing, Timetable Management, and Payment Processing—are decomposed into Level 1 DFDs for detailed analysis:
- Enrolment Processing: This process handles student requests to enroll/drop subjects, checks prerequisites, detects timetable conflicts, and updates enrolment records.
- Timetable Management: Creates, updates, and maintains class schedules across campuses, ensuring no clashes and reflecting current offerings.
- Payment Processing: Manages tuition fee transactions, verifies payment completion, and updates student financial records.
Each Level 1 DFD maintains balance with the Level 0 process, clearly illustrating data inputs, outputs, and storage points specific to each function, thus supporting precise system understanding and further development.
Entity Relationship Diagram (ERD)
The ERD encapsulates core entities such as Student, Course, Subject, Class, Campus, Program Director, Enrolment, Timetable, and Payment. Attributes include Student ID, Name, Date of Birth, Course ID, Subject Code, Class Schedule, Campus Location, and Payment Amount. Relationships are defined as follows:
- A Student enrolls in multiple Subjects via Enrolments.
- Subjects are associated with multiple Classes delivered across various Campuses.
- Courses comprise multiple Subjects, managed by a Program Director.
- Each Class is held at one Campus, which can host several Classes for the same Subject.
- Payment records link to Enrolments and Students, reflecting the billing process.
This ERD facilitates understanding of data dependencies, entity attributes, and relational structure, critical for implementing a normalized database.
Physical Data Storage and Justification
Based on system requirements—such as multi-user access, complex queries, data integrity, and scalability—the system should employ a relational database management system (RDBMS). Relational databases (e.g., MySQL, PostgreSQL) provide structured storage, enforce data integrity through constraints, support ACID properties for transactional reliability, and facilitate complex joins and queries essential in academic environments.
File systems lack the necessary features for transactional integrity, concurrency control, and efficient querying, making them unsuitable for a university enrolment system. RDBMSs ensure data consistency, security, and scalability, accommodating future expansion and integration with external platforms like Blackboard.
Relational Database Design (Normalized to 3NF)
The ERD entities are translated into tables, with primary keys, foreign keys, and appropriate attributes defined to eliminate redundancy and dependency anomalies:
- Student: StudentID (PK), Name, DOB, Email, Phone
- Course: CourseID (PK), CourseName, Description, ProgramDirectorID (FK)
- Subject: SubjectCode (PK), SubjectName, Description, PreRequisites
- Class: ClassID (PK), SubjectCode (FK), CampusID (FK), ScheduleTime
- Campus: CampusID (PK), Location, Name
- ProgramDirector: DirectorID (PK), Name, ContactDetails
- Enrolment: EnrolmentID (PK), StudentID (FK), SubjectCode (FK), ClassID (FK), EnrolmentDate, Status
- Payment: PaymentID (PK), EnrolmentID (FK), Amount, PaymentDate, PaymentStatus
The design adheres to Third Normal Form, ensuring no transitive dependencies and optimizing data integrity and query performance.
Conclusion
Through detailed process modelling, data flow analysis, and entity relationship design, a robust framework for ABC University's online enrolment system has been established. The proposed diagrams and database design align with operational policies and technological best practices, setting a solid foundation for implementation, testing, and future scalability.
References
- An Introduction to Database Systems. Pearson.