Studio III.2 Information systems modeling using IBMS tools

This studio uses the case study, Student Registration System, to walk through the whole process of using IBMS tools to model the system and to design its database.

Objective:

• Learn how to use IBMS/DFD tool to model an information system, to prepare for its database design, and to convert the DFD to SER model - where IBMS/SER and IBMS/OER tools can be used in modeling its data and designing its database.

Scenario: Student Registration System

(Adapted from K.C. Laudon and J.P. Laudon, Management Information Systems: Organization and Technology Forth Edition, Prentice-Hall, 1996)

Students submit registration forms with their name, identification number, and the numbers of the courses they wish to take. For each form, the registrar verifies that each courses selected is still open by referencing the course file. The file distinguishes courses that are still open from those that have been canceled or filled. Subsequently, the registrar determines which of student’s selections can be accepted or rejected. Then the registrar enrolls the student in the courses for which he or she has been accepted and updates the university’s course file with the student name and identification number and recalculate the class size. If maximum enrollment has been reached, the course is closed. The enrollment process also updates the student master file with information about new student or changes in address. The registrar then sends each student applicant a confirmation-of-registration letter listing the course for which he or she is registered and noting the course selections that could not be fulfilled.

A general procedure and rules in using IBMS/DFD tool:

When model a DFD for an information system, there are three steps to follow. The first step is to draw a context diagram (the DFD depicts the entire system as a single process with its inputs/outputs and external entities) for the system. The next step is to draw a detail DFD. The detail DFD can be obtained by decomposing the process into a successive level as desired. The IBMS/DFD supports the decomposition process at any number of levels. The last step is to define data requirements for the system. This step involves in defining data items and assigning data items to data stores and data flows.

To be able to convert a DFD to a SER model, the IBMS/DFD requires a context diagram for a modeled system.

In modifying a generated SER model, we keep all SER components that (1) are converted from data stores and (2) directly connect at least two components of (1). All others should be deleted.

Draw the context diagram

In drawing the context diagram of a system, we look at the system from the outside. Our attention is what are external entities and what are inputs/outputs. This system gets a registration form from a student, processes the form, and sends a confirmation-of- registration to the student. Therefore, its context diagram, as shown in Figure 3.1, consists of student as its external entity, registration form as its input, and confirmation-letter as its output.

Figure 2.1: The Context Diagram for the Student Registration System.

Draw the Detailed DFD

In this step, we look at the system from the inside. Our attention now is on what the inputs are transformed into, how the inputs are processed, what the outputs are created from, and how the outputs are prepared. To draw to detail DFD for this system with the inside perspective, we decompose the process in Figure 2.1 into three processes: process 1.0 Verify_Availability, process 2.0 Enroll_Student, and Process 3.0 Confirm_Registration. The process 1.0 gets requested courses from a registration form, verifies their availabilities using information from the course file, and produces accepted/rejected requested courses. The process 2.0 gets the output from the process 1.0, updates the course file and the student file, and produces a registration result. The process 3.0 gets the output from the process 2.0 and produces a confirmation letter. The detail DFD of this analysis is shown in Figure 2.2.

Figure 2.2: The detail DFD for Student Registration System.

Define data items of data stores

Suppose the above DFDs represent the design of the new system, we will move toward database design in the next important step. In doing so, all data items of data stores required for processes have to be defined.

• Define the following data items for the data store “course”: course_credit, course_days, course_id, course_name, ourse_times, course_building, course_capacity, course_closed/cancelled, course_registration, course_room.
• Define the following data items for the data store “student”: student_address, student_course_id, student_course_grade, student_id, student_name, student_course_semester.

Covert the DFD to SER model

We are now ready to covert the DFD into SER model. Please consult instructions on how to convert in the Studio I. The level 1 and 2 generated SER model from the conversion process are shown in Figure 2.3 and 2.4, respectively.

Figure 2.3: The level 1 generated SER model.

Figure 2.4: The level 2 generated SER model.

Modify the SER model

We next modify the level 1 generated SER by changing its name as shown in Figure 2.5. By following the above modification rules, we modify the level 2 SER generated model. The result of this modification is shown in Figure 2.6.

Figure 2.5: The level 1 modified SER model.

Figure 2.6: The level 2 modified SER model.

Design database using IBMS/SER and IBMS/OER tool

Before we start the next step, please note that the instructions on how to use IBMS/SER and IBMS/OER tools can be found in the database studios.

• Define equivalent data items: course_id = student_course_id
• Define the following FDs for the subject “student”: student_id ---> student_address, student_name ; student_course_id, student_course_semester, student_id ---> student_course_grade;
• Define the following FDs for the subject “course”: course_id ---> course_building, course_capacity, course_closed/cancelled, course_credit, course_days, course_name, course_registration, course_room, course_times;
• Map the SER model into the OER model:

  We may map the SER to OER model in Figure 2.7.

Figure 2.7: The generated OER model.

Modify the OER model and generate the database schema

The last step is to modify the generated OER model to generate the system database schema as desired.

Suppose we make the following modifications to the OER model:

• Remove the entity “OE_student_course_semester”
• Change the name of plural relationship “Student” to “Register”
• Change the name of entity “OE_student_id” to “Student”
• Redraw the OER model as shown in Figure 2.8

Figure 2.8: The modified OER model.

The database schema, generated from the OER in Figure 2.8, would consist of the following tables:

• Course (course_id, course_credit, course_days, course_name, course_times, course_building, course_capacity, course_closed/cancelled, course_registration, course_room)
• Student (student_id, student_address, student_name)
• Register (student_course_id, student_course_semester, student_id, student_course_grade)