Abstract:
The database is the foundation of the system. If you need to change the fields of the database frequently, or even modify the table and table relationship, I believe that no one will be able to cope with it several times! Because of the changes in the database structure, not only the changes in the database itself, but also the code at the entity, data operation, logic, and performance layers must be modified. What's more troublesome is that if a large amount of old data already exists in the database, the old data will not automatically adapt to the new database structure, you need to "Upgrade" the old data. This article will share with you how to build the foundation of the system-design the database! The article is too long and divided into the next two articles. This is the next article.
Outline:
1. What is an excellent design?
2. Excellent Design can save project workload
3. Excellent Design starts with analysis requirements
4. The software system is not of the bucket type.
5. The principle of Software Design"
6. Planning System skeleton-Architecture Design
7. Build the foundation of the system-Database Design
8. Details determine success or failure-Detailed Design
9. What a good user feels is really good-user experience design
10. continuously improve the design level
This article is one of the series of articles. If you have not read the previous articles, it is recommended that you read the previous articles first and then read this article, so that the effect is better.
7. Build the foundation of the system-Database Design
7.4 business modeling and database design of the attendance system
The case study of the Course Selection System for students is relatively simple, mainly to help everyone understand "business concept model-driven database design". Next, we will continue to share with you the example of "Attendance System". My main purposes are: 1) Modeling the behavior of the attendance system; 2) through another example, I will try again to understand how to use a class chart to analyze the business concept model. 3) based on the business concept model and considering our actual situation, we need to design a database that is "old-fashioned; 4) dig deep into the business concept model and design a database with a "high-end atmosphere. This section will share with you 1st, 2, and 3.
For requirements of this attendance system, please refer to the previous article. If you forget it, you must check it again! You can see that the previous article did not describe the approval process for leave (Going Out) in detail. Let's take a look at this process through a diagram below, this figure is one of the results of business behavior modeling.
Figure 7.6 Activity diagram of the approval process
After understanding this process, we will have a clearer understanding of the business conceptual model. The following two business modeling diagrams are directly described:
Figure 7.7 business concept modeling of the attendance system 1
Figure 7.8 business concept modeling of the attendance system 2
The above two figures are combined to form a complete business modeling. Because a picture is too large, it may not be displayed, or it may not be easy to see, it is split into two images.
Based on the above business modeling, how can we design databases? If you copy the student attendance system practice, a class must correspond to at least one data table. This design seems a little troublesome, and it may be quite troublesome to write code later. What are the main requirements of this system? This system is mainly centered on the approval process of leave (out-of-office). In fact, it is a simple workflow. We need to solve the issue of submitting an application and multiple levels of approval. In real projects, there is a lot of progress pressure and various constraints. Therefore, a design that can solve the main contradiction is a good design, therefore, I have such an old design that can meet the needs and make it easy to implement. Take a look at the two figures below and extract some of the database designs.
Figure 7.9 Database Design of the attendance system 1
Figure 7.10 Attendance System Database Design 2
This design is quite old-fashioned and should have been split into multiple tables to get one table: 1) when you submit a leave application, the leave application form contains one more record, all the fields related to this record approval are empty. 2) when you go to an approval stage, you only need to update the corresponding fields for this application record.
The code of this program is also relatively simple to write. For example, the presentation layer does not need to design different interfaces for different process links. You can simply do this through one interface, of course, you need to write a bunch of If Else or Switch Case. The code of the presentation layer is as follows:
7.11 Train of Thought on the presentation layer code of the attendance system
When an employee asks for leave, he can only see the content of Part 1, which is hidden in Part 2, 3, and 4. When the department manager approves the application, the content of Part 1 is read-only and the content of Part 2 can be edited, 3. Four parts are hidden, and the deputy general manager and the General Manager perform similar processing during their approval.
The database design should not only be taken into account from the database perspective, but also balance the workload of the project as a whole. In general, it can solve the main contradiction in the demand and reduce the development workload, it is the design that the project team can do. Such database design and software design are good designs.
The business modeling and database design of the attendance system also demonstrate the Best Practices: 1) business structure modeling and behavior modeling are necessary. Business modeling can be further explored, do not compress your time because the project progress is tight. The return of the time investment here is great. 2) Business modeling gives us a deeper understanding of the demand, let our database design and software design "go in and out and stick to it"; 3) when we encounter progress pressure and various restrictions, you don't have to design your database and code based on this business model. You can take a step back and use an old database design and program design to solve the problem. 4) you can also adopt more aggressive design strategies, which will be shared in the next section.
7.5 business modeling is upgraded to the next level to create a more flexible database design
This section will share with you the 4th goals mentioned above: digging deep into the business concept model and creating a "high-end atmosphere" database design. But this goal is too "great". Here we can only share some of the initial content for you, and I will share more content in the future.
We have more thoughts: What should we do if the approval process for leave (Going Out) changes, for example, the approval process is added? According to the previous "old soil" design, it is troublesome. We need to add the "Leave Application Form" field, and the code at the presentation layer also needs to be modified, so more If Else is needed. Of course, we may also have a better solution, that is, to think that this is a demand change and say to the customer: no money no talk (there is no money to discuss ). As long as our business analysis is in place in the early stage, we can draw all the flowcharts and business concept diagrams, and confirm with the customer, the customer will not be able to settle the bills, and the approval process will be added, this is obviously a demand change. It requires a lot of work and a little money! But why can't we make the program more flexible? Why can't I create a "full-active" workflow? In this way, our software will be more competitive and help us make more money.
The workflows mentioned in the previous article are divided into three layers: 1) Dead workflows: hard code, database design, and any changes to the process or form, you may need to modify the code and database design. 2) half-dead workflows: some are written to death, while some are flexible and can adapt to changes in some needs. 3) Fully-active workflows: code and database design are flexible and can basically adapt to changes in processes and forms, without the need to modify the code or database design. You only need to configure it. What kind of hierarchy does the old design belong? I am so embarrassed to say that this is a "dead Workflow" with the worst flexibility! If the process is slightly changed, it needs to be modified everywhere, including modifying the database design and code.
Next, let's try "Live Workflow". We need to further analyze the business model, find out the rules of the process, and design the database and software based on the rules!
Figure 7.12 in-depth mining of the Business conceptual model of the attendance system
The content in the red dotted box is a rule, and other parts can be seen as an "instance" of this rule ". This figure reveals this rule: 1) from the beginning of the application, the subsequent approval is actually a "Approval chain"; 2) the "application" corresponds to a "first approval ", "First approval" is followed by "next approval"; 3) for a "approval", if it is not "first approval", it corresponds to a "last approval ". If the database and program can be designed for such a rule, the system will be able to adapt as long as the rule is met, so that the approval process will not be afraid of changes!
Figure 7.12 may be a little difficult. If you do not have the experience in analyzing business applications using class diagrams, it will be even harder to understand this diagram, but this is just the beginning of the challenge! When we need to build a more flexible system, we are faced with two major challenges: 1) Exploring the needs to discover the essential capabilities of the needs and building a deeper business model; 2) According to 1st) point business model, design the corresponding database design and software design. These two challenges are both very difficult. Figure 7.12 is only the start of further exploration of the business model. It is very difficult to create a "Live Workflow". In the future, we will have the opportunity to share more articles.
7.6 database design summary
The quality of database design determines the foundation of the system. Both the design of "Old Earth" and the design of "high-end atmosphere" serve the project's objectives. In general, we should meet the following basic requirements: 1) Pay attention to database design in terms of consciousness, and the time investment in database design is great value; 2) good business modeling (including structural modeling and behavior modeling) is the basis for sound database design, and can allow you to "break in and out" in the future; 3) to build a database based on the business concept model, you can use a database design method similar to the Student Course Selection System (the business entity class corresponds to the data table one by one ), you can also use the "old soil" Design Method of the attendance system (merge business entity classes into a table ). When conditions are ripe, we can consider further improving our business mining capabilities and elastic design capabilities, so that our software can be sold better and we can earn higher salaries!
This is one of the series of articles. It is not easy to be a software designer. Please pay attention to the subsequent articles!
Activity information:
There are many UML diagrams in the series "how software design is made", and the articles have always emphasized demand-driven design. If you are interested in these topics, you are welcome to consider an upcoming event in Shenzhen: Agile encounter UML
Click this link for details: http://blog.csdn.net/fireball1975/article/details/19550771
This activity has been released in the CSDN community, see: http://huiyi.csdn.net/module/meeting/meeting/info/706/community
Author: Zhang chuanbo
Innovation workshop entrepreneurship class (agile course) Instructor
Senior Consultant of software R & D Management
Cmme Chief Expert
Fireball-UML war demand analysis author
Founder of www.umlonline.org
