Report on the Train Ticketing System

Report on the Train Ticketing System Author: Zaobo He, Bing Jiang, Zhuojun Duan 1.Introduction... 2 1.1 Intentions... 2 1.2 Background... 2 2. Overview of the Tasks... 3 2.1 Modules of the system... 3 2.1.1 Query module... 3 2.2.2 Registration module... 3 2.2.3 Login module... 4 2.2.4 Ticket sales module... 4 2.2.5 Ticket return module... 4 2.2.6 Personal information module... 4 2.2.7 Reservation module... 5 3. Design of the Database... 5 3.1 The table of User... 5 3.2 Table of Train Schedule... 5 3.3 Table of ticketing record... 6 3.4 Table of Massage Boards... 6 3.5 Table of News... 7 4. Algorithm for implementing the system... 7 4.1 Query algorithm for the remaining tickets... 7 4.2 External Row Lock:... 8 4.3 B-Tree Index... 9 4.4 How to select the route... 9

1.Introduction 1.1 Intentions Advanced database technologies play a critical role in information management system. How to search, maintain and modify the large scale data set efficiently becomes a core problem. Especially, the coming of big data promotes amounts of novel database technologies coming out, which are related to index, concurrency and so on. Those data models or algorithms, however, are still purely theoretical so that some practical applications are necessary to verify those models of algorithms. Most importantly, it is well to propose some novel technologies in this process. In this project, based on the practical condition of train ticketing selling, we propose several new algorithms of the remaining tickets and build a complete train tickets selling system. Our contribution can be classified two parts as follows: Firstly, we apply the B-tree to index on station search. Practical train system consists of thousands of train routes schedule, where each route has many stations. On the other hand, some routes will intersect at some stations, so these stations can be used as transfer stops to form new routes facilitate the customs to choose other available routes if the direct one does not exist. So mounts of information stored in our database makes it take lots of time when doing search. In order to solve this, we construct index on the station information and combine the hash function and B-tree for searching. We also apply the hash function and B-tree to direct train schedule. Input S=String of starting stop Input D= String of destination stop; KeyS=Hash(InputS), KeyD=Hash(InputD) Construct index on the station name using B-tree with the keys computed by the hash function. Secondly, when doing search, there is no direct train schedule which can satisfy the customer, or the tickets has been sold out, our system will computer the shortest way using Dijkstra algorithm. 1.2 Background Current train ticketing system confront with kinds of complex problems, for the reason that it directly related to the normal operation of the train system which is one of the basic business for a country. Moreover, with the rapid development of economy, the requirements of travelling put huge pressure on the performance of train ticketing system. Thus, a novel train ticketing system based on advanced database technologies is highly needed. Management and customer service are two basic function modules of the train ticketing system. An efficient ticketing system

can lower the workload and enhance work efficiency. Meanwhile, find information rapidly and quickly is significant to customer. To conquer the above problems, we develop a train ticketing system based on novel indexing algorithms to make it possible to maintain, update, and search a huge dynamic data set. 2. Overview of the Tasks 2.1 Modules of the system Our train ticketing system plan to implement a new human-computer interactive system for the ordering the tickets by customs and the management of train companies, which should be open architectures, easy to extend and easy-maintenance in database and advanced platform. 2.1.1 Query module This part provides two ways for query, one is based on train schedule, another is based on station. In the first case, if the needed train route is found, the custom can order the ticket directly through clicking the button. In the second case, according to the information input by customers, such that departure time, starting and destination stations, the system will return all the train schedule which can satisfy the requirements of the custom directly, that is there is no transfer station in this route. At the same time, the number of remaining tickets, and the price will be returned. When no direct route from the starting point to the destination point, the system will find some path which combining some stations which can send the passenger to the destination. We use algorithm of Dijkstra to compute the shortest path, but our system not only return the shortest path for customs to choose but also some path which may be cheaper ways. Based on the information returned, the custom can decide whether buying or not, if buying, the number of remaining tickets minus one. The system will set a proper position for customer automatically. 2.1.2 Registration module Registration is one part that every information system needs. Till now, there are mainly two kinds of solutions being used widely: The user login ID and password are directly assigned by administrator, the only thing that can be revised is the password by user. The user should input the basic information, and the username will be recorded in the system after the information is validated by the system. We

use this way to registration. And both the username and the password can be changed by the user online. 2.1.3 Login module When user gets into our system, the index page is for user login. This page is mainly for user information validation, if user gets into other web pages of our system, he will also be redirected to the user login page. There is an entry for user registration if it is the first time for that user to use our system. The principle is registration first then login to use. 2.1.4 Ticket sales module The ticket sales module is the most critical and essential part of the whole system, other auxiliary modules are all serve for it in different ways. When getting into this module, users are asked to choose or input train number, departure time, originating station, destination station, class level, student or not and remaining ticket number correspondingly. Then, users can click price calculation button and order button to buy tickets. After payment, system will generate user receipt, in other words, ticket. This system simulated a real ticket as well as print button on it. When user clicks the print button, the ticket will be printed out in theory. This function needs to implement connection to printer, which is not realized in our system. 2.1.5 Ticket return module Some users need to return and refund tickets due to different kinds of reasons, like some user changes their mind and do not want their previously ordered ticket, therefore; the ticket return module is indispensable for the entire system. The current principle for ticket refund is eighty percent of the original receipt price before train departs. Our system sets the refund ration is also eighty percent of the original price on ticket. After user finishing his return successfully, our system will increase the available ticket number and delete the record of this order in database immediately and automatically. 2.1.6 Personal information module The function of personal information module is help the customers look up or modify their own information. After the users logging into the main interface, click the button Personal information, then the information of current customers will be showed.

2.1.7 Reservation module In order to relief the stress of buying tickets at the same time, our system allow user to order the tickets in advance. Same as buying module, customer must input the information about the travel. In addition, if the customer decides to reserve one ticket, he or she should input his or her personal information. Then the number of remaining tickets will minus 1. 3. Design of the Database Our system adopts database software Sql Server 2012. We devise 9 tables. 3.1 The table of User This table is used to record the basic information of the users, the structure is as follows: Table 1 The Table of user ID Int 4 key User name Char 10 User name Password Char 10 Password Contact information Varchar 50 Telephone number Company name Varchar 50 Company name Address Varchar 20 Address Identity card Char 20 Identity card number Ticket agency Int 4 Ticket agency User type Int 4 Ticket agency is 1,business users is 2 3.2 Table of Train Schedule This table is used to store the detail information of each section in train schedule. Table 2 Table of Train Schedule Sequence number Decimal 9 key Number of train Char 18 Number of train Departure time Datatime 8 Departure time Arrival time Datetime 8 Arrival time Starting time Char 50 Starting station Destination time Char 50 Arrival station

Distance Decimal 9 Distance between two stops 3.3 Table of ticketing record This table is used to store the tickets records and ordering information. Table 3 Table of ticketing record Sequence number Int 4 key Type Int 1 Buying tickets: 1, ordering tickets: Train number Char 10 Train number Departing station Char 10 Departing station Arrival station Char 10 Arrival station Seat type Char 10 Common:1, air-conditioned:2, 0 sleeper:3 Number of tickets Decimal 9 Number of tickets Price Decimal 9 Price User name Char 50 User name Contact information Decimal 20 Contact information Identity card Decimal 20 Identity card number Starting time Datetime 8 Starting time time Datetime 8 time Number of seat Int 4 Number of seat 3.4 Table of Massage Boards This table is used to store the information fed back by the customers. Table 4 Table of Massage Boards Sequence number Int 4 key Title Varchar 50 title Content Varchar 1000 content Writer Varchar 50 writer Time Datetime 8 time

3.5 Table of News This is used for the manager to publish the news about the train station. Table 5 Table of News Sequence number Int 4 key Title Varchar 100 title Time Datetime 8 time Content Varchar 5000 content 4. Algorithm for implementing the system 4.1 Query algorithm for the remaining tickets The remaining tickets sets are very large and complex so that querying tickets from these big data sets is nontrivial. Take China for example, there has about 5000 trains within a day and every train has 20 carriages, moreover, a carriage has about 100 seats. Therefore, the data scale is very large. Most complexly, one ticket is related to several continuous stations. These stations interact with each other. How to allocate the train seats optimally to employ the free seats becomes a critical problem. In this part, we present a dynamic allocation algorithm to free seats based on binary section values. Its basic idea can be described as follows. We use 1 to represent that one ticket is useful in this station interval, relatively, 0 represent that it is not useful. We first present the algorithm as follows and then do a detailed analysis. Input: Several M stations. Amount of free seats, denote the number with N Output: Allocation strategy to satisfy: 1) Lower storage cost; 2) Lower time cost; 3) Employ the free efficiently, do not waste. 1. Initially, section value 111 1 (the number is M-1) is related to the free seats; 2. Transmit the user s requirement to corresponding section value; 3. Traverse the section value table find the first value that satisfy users section value;

4. Produce a sold tickets record and put it to the sold tickets table. Produce 0-2 remaining section values. 5. Compute the remaining section values based Step 4. And then If these new section values does not exist in remaining table, then insert these new records into the section value table from small to large; else Ignore it or them. 6. Correlate the remaining tickets with corresponding section value 7. When a new user comes, repeat the above steps. For clearly, now we give an example. Assume we have 7 stations in the railway network so we have 6 sections assume which is A, B, C, D, E, F and G respectively. This train have 3000 seats, and 1 represents there have a free seat, 0 represents there does not have a free seat. In the initial time, the remaining tickets have just one binary section value 111111 which is related to the whole 3000 free seats. Now a user comes, who wants to from C to E with section value 001100. Search from the section value table with section value 111111 which satisfies users request, so we allocate a ticket to this user. This process produces two new section values which are 000011 and 110000. Now insert these two values to section value table and which are also correlated to seat No. 1. This status can be described as follows, The sold tickets table Section value: 001100 (C E) Fig. 1 sold tickets table The remaining tickets table Section value: 001100 (E G) related to No.1 seat Section value: 001100 (A C) related to No.1 seat Section value: 111111 (A G) related to No.2 seat No.3 seat No. 3000 seat Fig. 2 remaining tickets table Therefore, in this way, we can always allocate the seats optimally. And we just need to store the section value table in memory so this algorithm lower the storage cost. And our query also is based on the section value table so that our query is time consuming. 4.2 External Row Lock: Besides the basic row and page locks of database, we want to try some new technology. In the function module of buying tickets, to press the button price to

apply the train number and total tickets amount to the database. And the system would use the column remainder to judge how many tickets of the same train are being visited by customs. If then somebody else also wants to buy the tickets of the train and the column remainder is larger than the amount of the remainder tickets, the system would not access his order and would return the message No ticket left. Such lock is used to reduce the invalid visits to release the pressure to the database. It also can protect the database from the DDOS attack. 4.3 B-Tree Index To fasten the speed of select, B-tree is used to build the construction of train information by the train number. When customs want to choose which train to take, the system would be input the train number into. Because the amount of trains is not too large to be reload in memory, the B-tree would be faster than B+ tree. Each train number is unique and there is no conflict existing. 4.4 How to select the route Because the system would be only input the start station and the destination station, the route, which the passenger would take, is totally designed by the system. The whole train route map has been separated into 4 parts. Each end to the center (transport station: Beijing) is one route. And all the stations would be transformed into a tree. The transport station is the root and the son of each point is next station, which is also farther to Beijing than its father point. Then the system would travel from the start station to Beijing and from Beijing to the destination station. The system would create a temp table temp-route to record the route of all the stations.