Vehicle management system

Tip: After the article is written, the table of contents can be automatically generated. For how to generate it, please refer to the help document on the right


I. Introduction

The content of this topic is to develop a campus vehicle information management system for campus administrators and security departments. It needs to realize the addition, deletion, modification and checking of basic personnel and vehicle information, as well as the entry and query of vehicle access information, and the system design needs to fully consider the campus The connectivity of existing information systems.
The campus vehicle information management system is not a completely independent system. In fact, it is a content expansion of the campus information platform. From the current network survey, most campuses are equipped with campus information platforms, including at least teachers. Student registration information (ie, statistics on school personnel), entry statistics of student performance, and various other information. In the campuses of first- and second-tier cities, a system for registering information about entering and exiting personnel has been basically realized. This system is designed and developed on the basis of the above status inspection to realize the information management of vehicles entering and exiting the campus, and the system has Strong portability, in fact, any place with access detection function can use such an information recording system.
The system development process includes database design, user-side interface design, and java program design and realization of the core functions of the system. The design and realization of the database is the core part of this subject.


Tip: The following is the content of this article, the following cases are for reference

2. System requirement analysis and related technology introduction

2.1 Functional requirements analysis

The data that the database needs to store includes
1. Login user data: user name, password, name, department
2. Personnel data: ID number, name, gender, personnel category, campus card number
3. Vehicle data: license plate number, vehicle type, owner
4. Entry and exit records: time, type of entry and exit, place of entry and exit, license plate number, remarks

2.2 Feasibility analysis

The technical threshold of the information management system is low. After possessing a certain database design ability, algorithm design ability, interface design foundation and certain programming knowledge, an information management system with interface can be independently developed. In the information age, the use of information management systems to manage and maintain information data is a general trend. Various information checks and permission restrictions added by the system can greatly guarantee the security of data. The sharing of data recorded through the information management system is Conventional manual information recording methods are incomparable. The original intention of the development of this system is to record the information of all vehicles entering and exiting the campus, to provide a data reference for various campus safety incidents that may occur, and to ensure campus safety from the perspective of information recording and verification. Its scalability is extremely strong. From the perspective of applicable objects, all closed management areas can achieve system migration through targeted transformation of the original system (mainly database transformation and system bottom layer), and they also have access information records Function.

2.3 System operating environment

The development and operation environment of this system is Windows 10 operating system, which requires mouse and keyboard as input devices and monitor as output device.

2.4 Introduction to related technologies

Database technology: SQL Server2008 version + SSMS
software development technology: Eclipse (Java integrated development tool)
Interface design: Windows Builder (Java swing + AWT)

3. Overall system design

3.1 System functional structure design

This system is divided into an operator part and an administrator part. The operator part can enter vehicle access information; the functions of the administrator part can be summarized as data maintenance functions, including system user data maintenance, personnel information data maintenance, and vehicle information The maintenance of data and the maintenance of the entry and exit records. In addition, due to the difference between the operator and administrator system interfaces, a system login interface needs to be added, including login authentication and password modification functions.
The system function module division is shown in Figure 3-1.
Figure 3-1 System function structure diagram

3.2 System function flow design

3.2.1 System login function process design After the
system is running, the login interface is first entered, and the user's authority is obtained through login verification to determine the user's operation interface selection logic. In addition, this page provides an interface for password modification, in the user name text edit box The small square at the back can trigger the click event to jump to the password modification interface. The exceptions that need to be handled include: the text edit box is empty, the account does not exist, the password is incorrect, and the new password entered twice is inconsistent during the password modification process. The complete process of the system login function is shown in Figure 3-2.

Figure 3-2 System login function flowchart
3.2.2 The design of the entry and exit registration function process
takes into account that the traffic flow at the campus entrance and exit will be very large during the peak period, so the entry process is required to be simple, efficient, and use the least operation to obtain the most critical information. Therefore, the system is in the entry and exit registration function design part. There are only one or two click event buttons, one is the entry control button, the other is the refresh interface button (which can be used to reset the input content of the text box). The form data that needs to be filled in are the access type, access location, vehicle type, license plate number, and personnel certificate No. and remarks, the first three use the drop-down box selection mechanism to ensure the rationality of the input value, the latter three use text edit boxes (only the remark content can be empty); another function of this part is to display the entered information (in and out Record), this part of the function requires the reintegration of the display of information (need to display detailed personnel information, vehicle information), and high timeliness, mainly reflected in the screening and ordering of the displayed information content and the immediacy of information changes caused by information entry . The abnormal situation that this function needs to handle is also the situation where the form content is illegal. The complete flow of the access registration function is shown in Figure 3-3.
Figure 3-3 Flow chart of access registration function
3.2.3 Data maintenance function process design
The normal operation of the system is inseparable from the maintenance of data. The data maintenance of this system can be divided into user information maintenance, personnel information maintenance, vehicle information maintenance and access record maintenance from the interface module. In terms of function, it can be roughly divided into information addition, information deletion, information modification and information query. Among them, the information query function should provide multiple query methods as much as possible. The interactive process of the data maintenance function is shown in Figure 3-4.
Figure 3-4 Flow chart of access registration function

3.3 Database design

The campus vehicle information management system is not a completely independent system. From practical considerations, it should be an extension of the campus information platform. Therefore, when designing personnel information, the input of redundant information should be appropriately reduced, such as the grade of the student. Information such as, class, class teacher, etc. can all be inquired and obtained through the connection with other information systems, instead of requiring repeated entry in this system. (As for the situation where there is no personnel information database, then I just want to say that the importance of the personnel information database to the campus is much higher than this system, so please also your school leadership to move to the personnel information management system).
3.3.1 Conceptual structure design
(1) System user information
System users are users who log in to the system. The user’s basic information will be stored here, including the user’s number in the system (which will be used as a job number for login), The login password of the user, the user’s name and the user’s title, among which the attributes of the user’s number are set to increase as the main code (the initial value is 1, the increment is 1). In addition, at the beginning of the database creation, an administrator user (work ID 0, password 000) will be created as the only login user in the system. The system user entity is shown in Figure 3-5.
Figure 3-5 System user entity attribute diagram
(2) (Access) Personnel information
Personnel information is mainly composed of two parts, one part is the school personnel information entered by the administrator (usually the data content can be associated with the school’s existing personnel information system), the other part is operated by the slave Temporary personnel that are separated from the entry and exit information entered by the personnel, the information of these temporary personnel will be automatically saved and entered (the personnel at this time can be understood as the owner of the vehicle in and out). (Access) The personnel entity is shown in Figure 3-6.
Figure 3-6 Person entity attribute diagram
(3) (Access) Vehicle information is
similar to the information of personnel entering and exiting. The information of entering and leaving vehicles is also composed of two parts. The part entered by the administrator must be added based on the existing school personnel as the owner of the vehicle, and entered by the operator The part is also stripped from the information of entry and exit registration and added to the vehicle data with the category attribute of the temporary vehicle. These temporary personnel are automatically added, and the logic of the temporary vehicle will be described in the next system detailed design section. (Access) The vehicle entity is shown in Figure 3-7.
Figure 3-7 Vehicle entity attribute diagram
(4) Access record information
The entry and exit record information is the data generated by the event that a vehicle enters and exits. Considering the principle that time-type data should not be set as a unique code attribute in database design, the entry and exit records are treated as weak entity sets during design. It forms an identification connection with the identification entity (vehicle). The entry and exit record entity is shown in Figure 3-8.

Figure 3-8 Entity attribute diagram of access record
2) The overall ER diagram of the system
In the above entities, the personnel entity and the vehicle entity form a one-to-many relationship, and the vehicle and the entry and exit records constitute a one-to-many relationship (that is, the entry and exit records are generated by the entry and exit behavior of the vehicle), and the system user It is a separate entity, only used for system login. The overall ER diagram of the system is shown in Figure 3-9.
Figure 3-9 Overall ER diagram of the system
3.3.2 Logical structure design
The part that needs to be designed in the ER diagram is the identification and connection between the vehicle and the entry and exit records. My processing method is to use the main code license plate number in the vehicle as the external code in the entry and exit record table. Use the time in the entry and exit record as the partial code and the license plate number as the main code of the entry and exit record table. The relationship between the vehicle and the person's possession is reflected by adding the owner's information (using the person's main ID card number) to the vehicle as an external code.
(1) Users (system user table)
All fields of the system user table are required to be non-empty. The id field is set as the main code for self-increment, and the user department can restrict the corresponding value as needed. The system user table is shown in Table 3-1.

(2)
The id and type fields of the Personnel (personnel information table) are required to be non-empty, and the type field and sex field are restricted by the value set. The id field is set as the main code, and the schoolCard field is set as the default value restriction to 0. The personnel information table is shown in Table 3-2.

(3) Vehicle (vehicle information table)
All fields in the vehicle information table must be non-empty. The license field is set as the main code, and the owner field is set as the foreign code, which corresponds to the id of the personnel information table. The type field can add value constraints. Vehicle The information table is shown in Table 3-3.


4) AccessRecord (entry and exit record table)
except for the note field, the entry and exit record table is not empty, the time field and the license field are set as the main code, and the license field is the foreign code, corresponding to the license field in the vehicle information table, type and addr fields You can add value constraints.

4. Detailed system design

4.1 Detailed design of system login module

At the beginning of the design, the system login module has two options. The first one is to set the user access database permissions by setting database users and roles. From the perspective of database access permissions, the system login function is realized, and its specific implementation The method is to first connect to the database from the database administrator role, and then enter the administrator interface. All user additions, permission changes, password resets, and user deletions will be transformed into editing database roles. This approach can maximize Ensure that the data in the database is accessed correctly. Another way to achieve this is to implement the user authentication function in the Java interface logic, choose different interface logic for different users, and maintain user information by modifying a basic table that actually exists in the database. It is safe Inferior to the former, but the victory lies in the low implementation complexity, because regardless of whether the database role verification is used, the user’s identity needs to be checked during the design of the system interface. From this perspective, my system finally adopted The latter is not to set up multiple database roles, but to directly store user information in the basic table of the database, and implement user login verification through Java background logic.
The verification logic of the login interface uses the Id number entered in the input box to query user information, and then compare whether the passwords are consistent to achieve login verification. The jump logic of the interface is to make a logical selection by querying the department of the user corresponding to the Id to realize the page jump. After the jump, the original login interface is closed.

4.2 Detailed design of access registration module

This part of the function is the core function of the system, and its basic logic is relatively simple. The operator fills in the form, the system reads the form information, judges the form information and stores it in the database after integration, and triggers a page refresh. However, the process from reading the content of the form to storing the data in the database requires more complicated logic control. Therefore, a stored procedure is created in the database to execute a series of Insert statements to store the data in the form in the database in. In addition, you need to design a view for record display to preview the access records.
The detailed implementation logic of entry and exit registration is to first check the validity of the form input in the Java page control, and require that the license plate number and personnel information content cannot be empty (the personnel information can be filled in either the campus card number or the ID number). After the operator triggers the input button click event, the stored procedure Proc_add is called. The input parameters include access type, access address, vehicle type, license plate number, personnel information and remarks. In the storage process, three counting parameters @cn1, @cn2, @cn3 are also set, which respectively represent the number of times the personnel information appears in the ID field of the personnel information table, and the number of times the license plate number appears in the vehicle information and license plate number field. And the number of times that the personnel information appears in the campus card field of the personnel information table, because the ID number and the campus card number cannot be the same, so @cn1 and @cn3 cannot be 1 at the same time. According to the different results of the three parameters, different storage methods can be obtained. The judgment logic table is shown in Table 4-1.

In particular, the time field in the entry and exit records is the method of obtaining the current system time in the called database (@time=GETDATE()).
In addition to the content in the Access Record table, the content of the access record information should also include the vehicle type and owner information in the Vehicle table. The data display function can be realized by creating a database view. The specific display method is to use the Java GUI. The Table class displays the read data view.

4.3 Detailed design of data maintenance module

The overall design of the data maintenance part is more distinctive. All data operations are completed in one interface. There is no complicated window popping up the logic of repeated input, but it is more user-friendly, whether it is data addition, query, or modification and deletion. It can be completed on the current page. This approach makes data entry more efficient, and data query and modification functions can also be highly coupled, which greatly improves the efficiency of data maintenance. The disadvantage is that the interface button control logic is more complicated, and the development is more difficult. It may not be friendly to subsequent maintenance and updates, but the improvement of user experience is certain. (In order to facilitate comparison, in the user information management section, a program that clicks a button to trigger the execution of a new page is used for horizontal comparison).
4.3.1 Data addition
The implementation of the data addition part of the function is relatively simple. After the administrator fills in the information and clicks the add button, the system first checks the validity of the input and checks the information entered by the administrator, mainly including checking whether the input field is Empty and whether the record is added repeatedly (the uniqueness of the master code). In particular, for the campus card field in the personnel information, an insert statement trigger is set in the database, which can deal with the fact that the ID number of the added personnel is not repeated. If the card number already exists, the implementation method is to create a trigger. After detecting the execution of the Personnel table insert statement, the number of times the campus card number in the inserted record appears in the campus card number field of the Personnel table. If it is greater than 1, an exception will be thrown and the transaction will be executed. Roll back, otherwise do not perform any operation.
4.3.2 Data query
The implementation logic of the data query function is also relatively simple. After the administrator clicks the query button, the system reads the information in the form, and almost all query methods can be realized through fuzzy query (like'%'+text+'%'). What needs to be handled separately here is the query of the access record information, because it involves querying by date, it cannot use the fuzzy query method to obtain the query result. My method is to add three drop-down boxes in the form , Are used to set the year, month, and day. Here you need to solve the problem of inconsistency in the number of days in each month (the solution is to use the getActualMaximum (Calendar.DAY_OF_MONTH) method in Java.calendar to get the number of days in the current month (determined by the year and month drop-down box) And displayed in the drop-down box), so that you get the date field required for the query, and then call the created database stored procedure Proc_findByDate, the logic of the stored procedure is to use'where time between'. Another way to query incoming and outgoing records is to use attribute characteristics to query, which is similar to the fuzzy query method mentioned earlier.
4.3.3 Data modification The
data modification function is more tricky. The data modification logic starts when the administrator selects a row of data in the table at the bottom of the page. When the administrator triggers a click event, the selected record will be automatically filled and displayed in the top form Area, where the form content corresponding to the main code attribute will be set to a non-editable state, and other content can be modified. After the system detects that the form content is modified (the form content must be inconsistent with the data saved in the database, Triggered, in other words, you can see whether the current form data is consistent with the data in the database by whether the save button is lit or not), the save button on the page will enter the selectable state (the initial state is not selectable), and then the operator clicks the save button, The system will check whether the modified information is legal, and the data after passing the check will be updated to the database. Then the interface refreshes and returns to the initial query state of the page.
4.3.4 Deletion of data
To delete data, you also need to select the record first, which is similar to the data modification logic. After selecting a record, the delete button will light up. Click Delete at this time to delete the selected record and refresh the interface. In particular, for the deletion of personnel information and vehicle information, taking into account the data integrity of the database system, the triggers Per_del and Veh_del of the delete statement are added to the database, which in turn realizes the first detection of whether the person is a certain person when deleting a person. The owner of the vehicle, if it is, will delete it together with the vehicle. When deleting the vehicle, first check whether the vehicle has access records, and if so, it will delete all the access records of the vehicle. In addition, taking into account the transfer of access information, a record clear function is set up, which can clear all access records without deleting personnel information and vehicle information, and free up database space.
4.3.5 Others The
administrator interface framework uses CardPanel to trigger events from the buttons at the top of the interface, and displays the interface corresponding to the button (which can be understood as a Card) at the top.

Guess you like

Origin blog.csdn.net/weixin_44120833/article/details/111502748