The context diagram analysis from the system to define the entities outside the system, it is a high level view of the diagram, context diagram shows the overall system takes an only process of the external entity surrounds, input and output major representative works for data flows. However, context diagram easiest understood by the user, it shows the clear data flow of the system inside or outside the system boundary, also context diagram should be drawn before data flow diagram.
The context diagram show on figure1 represents National Hostelling Association, customer phone to the booking office to beds booking and they need to registration the beds booking process and stored their details to the database. In addition, the individual hostel receives the e-mail from the system that is the new order of the beds booking information.
1.2) Aims and objectives of the system
The National Hostelling Association requires a computerised system to carry out all the tasks:
Beds bookings registration
Search for free beds on a particular date
Identify available beds for booking
Process fee payments
Automatically send e-mail when a new booking is made
Aggregate financial records of bookings
In further development, National Hostelling Association also requires a website allowing association members to book their own accommodation via the website.
1.3) Data Flow Diagram for the system including:
1.3.1) Beds booking registration
Guest applies for beds booking phone to the book office and records the personal details (address, identity card and mobile phone number), staff will confirm the booking through the booking record, and the details will be storage to database as new customer.
1.3.2) Search for free beds on a particular date
Staff can search an available room for the customer from the room record; staff can checks the database confirm that searching an available room in a specific date.
1.3.3) Identify available beds for booking
Any beds booking will mark in the system, when a guest applies for beds booking, the system will checks for the number of the free beds in the hostel, staff can block the beds and the information (guest details, room number) will send to the check-in record.
1.3.4) Process fee payment
Guest phone to booking office, the system searches the information of the customer and checks the fee, the system will according to the booking information collect the fee and the information of the payment will send to the payment record.
1.3.5) Automatically send e-mail when a new booking is made
When a new booking is made an e-mail will be automatically sent to the relevant hostel giving the name of the guest, date of the first night they are staying and the number of nights they are staying.
1.3.6) Aggregate financial records of bookings
Staff accesses the payments database; it contains booked information of the customers, and then the payments details used for financial process and the financial records stored into revenue database.
1.4) Dataflow descriptions
Fig.2 Data Flow Diagram of Beds Booking System
There are five symbols data flow diagrams and they are external entity, data flow, process and data store, the external entity is a start or end of the data flow, they can outside the system and they are physical items. The external entity is like an oval and they are unique identifier and significant, to provides ease of view in the data flow diagram, external entities can duplicate in the diagram prevent cross between the data flow.
The shape as rectangular boxes that contain number is a sequence of process, which is shows the data flow operation during the data flow diagram of the system, it means the data flow order of the system where the data process occurs.
The line contain an arrow is data flow; it is showing the direction of the data and have a description on it. For example, the customer completed the registration and then process booking, the data flow is an arrowhead with "process booking" beside the arrow to describe what the information in the data flow included.
The symbol with an open ended narrow rectangular is a data store; data store is a place that save the information in the system, they usually use the letter "M" and "D" to indicate, "M" means manual data store and "D" means computer data store, each data store contain a number can Cross reference a list of data items.
The data flow diagram on above shows the high level data flow, data flow diagram is a technique to develop a system, when analysis the system and to show the data flow we need to produce a data flow diagram, if need detailed in the process, it can break down to many sub-process. However level one of data flow diagram label as main process of the system, in level one data flow diagram can further study and break down into many sub-processes, it is as know as level two data flow diagram. In level two data flow diagram is detailed showing the process of the analysis and it can break down to lower data flow diagram. Moreover, most data flow diagram analysis will stopped in level two data flow diagram and unusual breakdown into level three data flow diagram, the top to down expansion is the purpose in data flow diagram, to produce a data flow diagram of the system, context diagram should be build first.
1.5) Data store contents
Customers in data store content include customer name, customer ID, customer contact telephone number, date of birth
Bookings in data store content include hostel name, booking date, booking time, number of night, number of beds
Payments in data store content include customer name, hostel name, invoice number, fee information
Revenue in data store content include booking records, payments information
1.6) External entity definitions
Customer: This is a guest of the beds booking
Individual Hostel: This is the relevant hostel of the customer who booked
2) Data model detail of hostelling association's bed booking system
2.1) Entity Relationship Diagram of the system
Fig.3 Entity Relationship Diagram of Beds Booking System
In the figure above is the entity relationship diagram, the rectangular box with name and linked up by a line is the relationship involve within the entities, line linked up two entities represent they have related relationship that the first entity relate to the second and the second entity relate to the other entity. In the figure relationship have three types; they are one-to-one, one-to-many and many-to-many. Each entity has the minimum set of attributes, this attributes identify uniquely so we called primary key, and an attribute that is the primary key of one relation but appears as an attribute in another relation called a foreign key.
In the entity relationship diagram above, one customer has many booking, so customer and booking is one-to-many relationship, one hostel has many booking then the relationship is one-to-many and many booking by the customer only one payment so the relationship is many-to-one.
2.2) Entity descriptions for all entities in Entity Relationship Diagram
Entity
Attributes
Customer
Customer name, Telephone number, Date of birth, Address, Registration day, , Mobile phone number, Fax number, Gender, Identity card number, E-mail address
Hostel
Hostel name, hostel address, hostel telephone number
Booking
Booking time, hostel name, number of night
Payment
Payment date, payment amount, payment method
2.3) Entities of Primary and foreign keys
Entity
Primary Key (PK)/Foreign Key (FK)
Customer
Customer ID (PK), Hostel ID (FK), Booking ID (FK), Customer name, Telephone number, Date of birth, Address, Registration day, , Mobile phone number, Fax number, Gender, Identity card number, E-mail address
Hostel
Hostel ID (PK), Customer ID (FK), Hostel name, Hostel address, Hostel telephone number
Booking
Booking ID (PK), Booking time, Hostel name, Number of night
Payment
Payment ID (PK), Customer ID (FK), Payment date, Payment amount, Payment method
2.4) Optionality and degree of relationships between entities
Fig.4 exactly one and optional relationship
In the figure 4, each customer may book zero, one or many booking, and also each booking must be booked by one and only one customer.
Fig.5 exactly one and mandatory relationship
In figure 5, each customer must be paying one payment and exactly payment must be paid by one customer.
Fig.6 exactly one and optional relationship
In figure 6, each hostel may many or none booking and many or none booking booked in one hostel.
Fig. 7 exactly one and mandatory relationship
In figure 7, each booking must booked one or more than one bed and one or many bed booked in one booking.
3) Entity Life History Diagram of National Hostelling Association
Fig. 8 Entity Life History for National Hostelling Association
Entity Life History provides a third view of the system design of single event of the sequence of action. It shows the time sequence action in the system and shows how the entity is born and end. It provides the complete life of the entity from the creation to the deletion and changes for the sequence in each event and any entity has their life cycle.
3.1) Phone to booking office
The customer phone to booking office to beds booking, the booking staff will checks the customer information of the customer existing or not, if customer not existing in the system will processes registration of beds booking.
3.2) Check association membership
The Hostelling Association only accept customer to book the beds. Therefore, booking staff verify the membership of the customer. For the new customer, receptionist will provide the association membership to the customer. The customer needs to provide personal information to the booking staff for association membership processing. For the existing customer, the customer can update their personal profile or request for beds booking.
3.3) Book Bed
The customer requests for the beds booking. The booking staff will provide the beds booking form to the customer. The customer needs to choosing the beds booking date, hostel and number of staying for availability checking. If there is an available for booking, the booking staff will confirm the booking and stored the booking information to the database and send e-mail to relevant hostel for beds Reservation.
3.4) Confirm Bed
When the bed booking confirmed, the booking information will send to relevant hostel by e-mail, also the bed booked will reserved.
3.5) Process fee payment
The booking staff will collect the beds booking information from the booking database. When customer completed the bill payment, the system will generate the invoice number and receipt will send to the customer.
3.6) Check out
Customer will finish the day they staying; and then all the data process will be completed in this stage.
4) Database design for the bed booking system
Database design is a process of detailed data model of a database, the logical data model contains the necessary logical and physical design of the physical storage and required to produce a design in data definition language and also it can used to create a database. However, database design also used in whole database designing and not only physical or logical design, the application to queries with database application is database management system.
4.1) Normalization Process
Database logical design including relationship between data tables, this purpose is to optimization the core database; good logical database design can enhanced the database efficiency in whole system. On the other hand, poor logical database design is interfere with effectiveness in overall system.
The logical database design and normalization will use some formal method to convert the data into multiple associated data table with narrow datasheet in a normalized database. The data tables with the width data tables this as known as un-normalized normal form. In addition, normalization provides many benefits such as quick sort, indexing, improve the insert, update, and delete statements, less null values reduce inconsistency of data and increase database compaction.
4.2) Un-normalized form data
Customer Name, Gender, Day of Birth, Fax Number, Mobile Phone Number, Telephone Number, Address, E-mail Address, ID card Number, Hostel Name, Hostel Address, Hostel Phone Number, Booking Date, Booking Time, Booking Hostel Name, Number of Night, Beds Number, Payment Amount, Payment Method, Payment Day, Booking Staff Name)
4.3) First Normal Form
A relation is first normalization if and only if every non-key attribute is functionally dependent upon the primary key.
The first normal form is the normalization used in the database as a regular form. The first normalization is to repeat to exclude the appearance, the approach is the information required in both the database of each field can only store a single value, and each record must be able to use a unique key to be identified.
Bold = Primary Key Underscore = Foreign Key
Customer (Customer ID, Customer Name, Gender, Day of Birth, Fax Number, Mobile Phone Number, Telephone Number, Address, E-mail Address, ID card Number, Booking Hostel Name, Number of Night, Booking Staff Name)
Payment (Payment ID, Payment Amount, Payment Method, Payment Day, Customer Name, Hostel Name, Booking Date, Number of Night)
4.4) Second Normal Form
A relation is in second normalization if and only if it is in fist normalization and every non-key attribute is fully functionally dependent on the primary key.
Customer (Customer ID, Booking ID, Payment ID, Hostel ID, Customer Name, Gender, Day of Birth, Fax Number, Mobile Phone Number, Telephone Number, Address, E-mail Address, ID card Number, Booking Staff Name)
Hostel (Hostel ID, Customer ID, Booking ID, Hostel Name, Hostel Phone Number)
Booking (Booking ID, Customer ID, Hostel ID, Booking Date, Booking Time, Number of Night)
Payment (Payment ID, Customer ID, Payment Amount, Payment Method, Payment Day)
4.5) Third Normal Form
A relation is in third normalization if and only if it is in second normalization and every non-key attribute is non-transitively dependent on the primary key.
Customer (Customer ID, Customer Name, Gender, Day of Birth, Fax Number, Mobile Phone Number, Telephone Number, Address, E-mail Address, ID card Number)
Hostel (Hostel ID, Customer ID, Booking ID, Hostel Name, Hostel Phone Number)
Booking (Booking ID, Customer ID, Hostel ID, Booking Date, Booking Time, Number of Night)
Payment (Payment ID, Customer ID, Payment Amount, Payment Method, Payment Day)
Invoice (Invoice ID, Payment ID, Customer ID)
Booking Staff (Booking Staff ID, Booking Staff Name)
5) Data Dictionary in database design
Customer
Column
Data Type
Description
Customer_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Customer_name
VARCHAR(20)
[Name of the Customer], cannot be null
Day_of_birth
DATE
[Stores birthday in year, month, and day values] , cannot be null
Gender
VARCHAR(1)
{M=male, F=female}, cannot be null
Address
VARCHAR(300)
[Address of the Customer] , cannot be null
Fax no
INTEGER
[Fax Number of the Customer]
E-mail address
VARCHAR(70)
[E-mail Address of the Customer] , cannot be null
Mobile_phone_no
INTEGER
[Mobile phone number of the Customer] , cannot be null
Tel_no
INTEGER
[Telephone number of the Customer]
ID_card_no
VARCHAR(10)
[ID Card Number of the Customer] , cannot be null
Hostel
Column
Data Type
Description
Hostel_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Hostel_name
VARCHAR(20)
[Name of the Hostel], cannot be null
Hostel_Address
VARCHAR(300)
[Address of hostel] , cannot be null
Customer_ID
VARCHAR(20)
FK
Hostel_Phone_no
INTEGER
Phone number of hostel, cannot be null
Booking_ID
VARCHAR(20)
FK
Booking_Date
DATE
[Stores booking date in year, month, and day values] , cannot be null
Booking_Time
INTEGER
[Stores booking time in number], cannot be null
Number_of_Night
VARCHAR(10)
[Customer booking hostel number of night] , cannot be null
Booking
Column
Data Type
Description
Booking_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Customer_ID
VARCHAR(20)
FK
Hostel_ID
VARCHAR(20)
FK
Booking_Date
DATE
[Stores booking date in year, month, and day values] , cannot be null
Booking_Time
INTEGER
[Stores booking time in number], cannot be null
Number_of_Night
VARCHAR(10)
[Customer booking hostel number of night] , cannot be null
Payment
Column
Data Type
Description
Payment_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Customer_ID
VARCHAR(20)
FK
Payment_Amount
INTEGER
[Stores payment amount in number], cannot be null
Payment_Day
DATE
[Stores payment date in year, month, and day values] , cannot be null
Payment_method
VARCHAR(20)
[Bill payment method], cannot be null
Invoice
Column
Data Type
Description
Invoice_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Payment_ID
VARCHAR(20)
FK
Customer_ID
VARCHAR(20)
FK
Booking Staff
Column
Data Type
Description
Booking_Staff_ID
VARCHAR(20)
PK [unique identifier], cannot be null
Booking_Staff_Name
VARCHAR(20)
[Booking office staff name], cannot be null
5) Prototype of user interface for beds booking system
5.1) Login to the system
Fig. 9 Login Menu
This is a login menu of beds booking system, booking staff need to login to the system to operation for beds booking, the password must be started with a character, symbol and number, and also the password lengths must be eight characters. The failure login will count in the system log, user successfully login the failure count will reset to zero. In addition, if user more than five times failure login, the system will automatically disable the account temporary, the disabled account only database administrator to reset password.
Fig. 10 System menu
After successful login to the system, user have permission to access the system, there are six functions of the system, they are create customer, search hostel free beds, process fee payments, add beds booking, search customer and edit customer details, the booking staff can accesses all the functions by their account
5.2) Searching for hostels with free beds on a particular date
Fig. 11 Search free beds function
When user successful login to the system and they click the search hostel free beds button in the system menu, the interface will shows search beds function, user need to enter the free beds number to search, and also they need choose the particular date for the search, after entered the information for the bed searching, press the process button to next step or press back button to previous step.
Fig. 12 Search beds results
The search beds result will shows the beds number wilt hostel name and particular date, the available for the booking with specific date and beds hostel will shows the results in the hostel name pull down menu, user can use the results to booking beds for the customer, in the screen press ok will go to add beds booking screen.
5.3) Processing a bed booking for an existing customer
Fig. 13 Add beds booking screen
When user successful login to the system and searched the beds result in search free beds process, the screen will shows beds booking menu for exist customer. However, in the search results process after pressed OK button can go to this menu, booking staff need to fill the customer ID, choose the booking staff name for the booking, and also they need enter the number of the beds booking, choose the hostel name and number of night the customer stay. In addition, this add beds booking process not available provides the booking date by the user, user must be after the search results by date and beds number and pressed the OK button in figure 12, it is the only way to add beds booking for existing customer.
Fig. 14 Beds booking successful
This is the successful booking screen, after entered the booking information in the figure 13, and pressed the Next button, the successful booking message will shows on the screen.
5.4) Adding a new customer
Fig. 15 Error checking in new customer registration
To adding a new customer in the system, after login to the system and choose create customer in the system menu, the new customer registration screen will appears and booking staff need to filled all customer information, in the customer ID fill, the customer ID is generated by the system, user cannot change the customer ID in this process, when completed enter all of the information for the new customer registration, to avoid the blank fill of new customer registration, the system will check for the all fill to avoid missing of the information, all information in the fill must be enter.
Fig. 16 New customer registration
After checked all information of the new customer registration are correct, press Confirm button to next step and also can press Exit button to quit the new customer registration, but all of the information entered will not be saved.
Fig. 17 Customer registration successful
After confirmed the information for the customer registration are correct and pressed the button, the message will shows on the screen to the user customer successful added.
6) Project Review
6.1) detail your system design of the bed booking system
This project introduces the whole system design cycle and the standard documentation for system development needs to do. The objective for this project is to help the Hostelling Association migrate the paper work system to the electronic database system. After analysis the current system requirements, the new system will handle all existing function to replace the old system such as create customer database, search free beds by criteria and aggregate financial records of bookings. However, if the user submits the positive feedback of the system and they vote for the web booking feature to reduces their workload, the system may further development in future, the web booking may be allow association member to book their own accommodation via the association's website. In the beds booking system, it can provide a better operation for booking staff and provides accuracy booking information to the customer.
The beds booking system is developed by Structured Systems Analysis and Design Method (SSADM), it is a standard in early 80s and widely used in the UK government of system analysis and application design method, SSADM combine text and graphics throughout the life cycle of system design, it's from the initial design concept to the actual application of physical design. SSADM mainly used three techniques to develop the system; they are logical data modeling, data flow modeling and entity behavior modeling.
In task 1 of the project, it's used data flow modeling to develop a context diagram from the National Hostelling Association, it is define the external entities that away from the system and determine the context diagram to produce the data flow diagram, it can let developer very clear view to know the detailed data flow processes and data storage.
In task 2 and task 3, based on the data flow modeling and used entity behavior modeling technique to produce the entity relationship diagram, before produce database design of the system, in order able to communicate with users, database design commonly used a abstract graphical database to help in the design and as known as business model, also the entity relationship diagram is mostly used by developer because it very suitable in the analysis step.
In task 4, its need to design a database for beds booking system, in this phase used logical data modeling and using third normalization to produce physical database design, this step need to very clear the data in which table to increasing system performance.
After understanding the data flow and booking procedure, the program development can think the function of the system to cope with the database design and fulfill the user requirement, a simply user interface let user easy to understand the system function and can help user to familiar with the system and satisfactory when using.
6.2) Privacy and security issues
The National Hostelling Association collected customer information is used to reservation service only, when booking office receive a call for booking beds, for a new customer they need to registration for first time booking, this action is target with special offers or contact the customer if any problems with their booking and . However, the customer information entered to the system, only booking staffs have permission to access, and also the booking office has responsibilities to ensure customer any privacy under protect. In addition, National Hostelling Association respect customer personal information and privacy, it will be consistent with internationally recognized protection of personal data guidelines, even may over this guidelines as a standards. On the other hand, National Hostelling Association will ensure booking staff to training for information security and privacy course. Again, all data will be collected and used for identification and retention of records to collect data, sending customer information about different products and services information.
When the information of the customer entered to the system and confirmed the beds booking, the booking staff need customer to process fee payment in the central booking office, as a result, technical problems cannot solve all kinds of payment, bank transfer is the only way processes the fee payments in this stage. However, when customer booked the beds in the booking office, the booking information with the payment fee will stored into payment database, staff need to update the fee payment of the customer and they only can operate in the payment function in the system, after the booking done, the booking fee information of the customer only shows on the screen when booking staff entered the payment menu. In addition, after booking staff verified the payment amount of the booking and the booking staff will tell the payment amount to the customer, customer need to bank transfer money to the booking office account within three days and phone to the booking office to confirm the payment, after confirmed the payment of the customer, booking staff need to login to the payment menu and update the payment status. For the further development of the system in process fee payment, Visa or PayPal will be supported in online booking, after solved any security issues during the payment online and tested the system in the booking office, new features must be added in the system to improve the booking management.
6.3) assumptions of the design process
In the design in the beds booking system, process fee payment is only can records the customer who paid the fee of the booking, and also customer need to according to the booking office staff to bank transfer the money to the booking office account, and booking office confirmed the payment is done by the customer, the payment status will be update to paid. However, the further design of the system abilities to online bed booking via the association's website, since there are no customer record in the current customer database, it is difficult to consider the online booking and payment this time. Nevertheless, after the system tested in the booking office in a period, customer records will be raise, and the further development is customer creates an online member account in the website, and they can beds booking online and process fee payment by Visa or PayPal.
6.4) weaknesses and suggested improvements
The beds booking system in the project is a big challenge, so when development a system there are many weaknesses and mistakes in the system, this major problem is not unfamiliar with hostel management process of the beds booking and due to some management issues need manual operate by the user. In order to develop a system, developer need very clear and understand the process flow of the current system, in this case of the hostel beds booking, understand the work flow of the booking process may make the system design and development better.
Finally, the improvements of the beds booking system, the work of current system analysis is very important, it is a technique to identify deficiencies in current environment; it's like a plan to making concerning the current system strategic and feasibility.
7) Referencing and Bibliographies
Ambler, S.W., 2003, Data Flow Diagrams (DFDs), Available at:
http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm (Accessed: 16 April 2010).
Chapple, M., Database Normalization Basics. Available at:
http://databases.about.com/od/specificproducts/a/normalization.htm (Accessed: 16 April 2010).
Goodland, M., Riha, K., 1999, SSADM - an Introduction. Available at:
http://www.dcs.bbk.ac.uk/~steve/1/ (Accessed: 15 April 2010).
Precision Quality Software, Context Diagrams: An Explanation. Available at:
http://www.pqsw.com/hjsasp/gn02.cfm?SI=43479230767&ID=921210469186 (Accessed 14 April 2010)
Shiflet, A.B., 2002, Entity-Relationship Model. Available at:
http://wofford-ecs.org/DataAndVisualization/ermodel/material.htm (Accessed 18 April 2010)
Sybase 2005, Database type properties. Available at:
http://192.87.31.188/docs/eassag/eassag148.htm (Accessed: 23 April 2010)
