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 first 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.1 database structure changes can be large or small
It is common to fine-tune database fields, such as adding a field or modifying a field. Of course, this is also annoying when it often happens, so we may add some reserved fields to the database. When I used to refer to the database design of my predecessors, I often found some "reserved fields", so I also imitated them myself. Later I found it useless. For example, when you need to add a reserved field, I will find a reserved field of the reserved type and change the name of the original field from "Reserved 1" to a suitable name; when you need to add a numeric field, find a numeric reserved field and change the original field name from "Reserved X" to "XXX ". What is the difference between this approach and adding a field? It is better to cancel the reserved field, and then add the field as needed. Changes to database fields are minor changes. Although changes to the data operation layer, business layer, and performance Layer Code may also require "Upgrading" old data, these changes are all "minor actions ", not so terrible. The most terrible thing is the change in the data table or table relationship. For example, the original table design is unreasonable, you need to split a table into two or more tables. If the requirement changes, you need to add more tables. The original table relationship does not need to be modified, these changes will cause a wide range of modifications to the program. Because the database structure changes can be large or small, we may adopt a "will" strategy when encountering relevant problems. It is only necessary to repair and supplement the database, and we do not dare to fundamentally modify the database, as a result, the snowball rolls bigger and bigger, and one day you will find that the database structure cannot meet your needs, but the construction period is under great pressure. At this time, you can only wish you good luck!
7.2 what is the source of database structure change?
The reasons for database changes may be: 1) the customer's requirements have not changed, but our demand analysis in the early stage is not in place, or we did not pay attention to the database design in the early stage, this leads to unreasonable database design. 2) The customer's business changes, so that the database also needs to be adjusted. In either case, it is actually a business concept-driven database design! See the figure shown above:
Figure 7.1 business concept-driven Database Design
This figure is a diagram of the "bottom-up" design philosophy described above. Now we can re-understand it: 1) There are three work products in the "Demand Analysis" activity: business Concept diagram, business flowchart, and use cases/user stories. 2) The "business concept diagram" is the "input" of the "Design Database" activity, that is, the "business concept diagram" is an important basis for database design.
What is "business concept? Next we will use examples to understand "business concept model-driven database design ".
7.3 case: Student Course Selection System-business concept model-driven Database Design
Case study: Business modeling of the Course Selection System for students
Some requirements of a student's course selection system are as follows:
1) Basic student information: Student ID, name, age, school, school address, and contact number.
2) Basic course information: name, credits, and category (required, restricted, optional ).
3) students can read multiple courses and each course has corresponding scores.
Do you think you can design a Database Based on the above information? It is recommended that you first consider the Database Design Based on the above information, and then continue to read the article after completion, so the effect is better.
In actual work, due to the high schedule pressure, we may not just take a moment to think about these requirements, but simply the database design. This poses a considerable risk that the database design may not meet the requirements of the "three major Paradigms" and lead to some problems, such as: 1) the split table is not split, the table relationship is not suitable; 2) the field design is not suitable; 3) data redundancy, inconsistency, and so on. If we can perform business modeling first, we can avoid these problems.
Is a modeling analysis of the business concepts required above:
Figure 7.2 business conceptual modeling of the Course Selection System
I usually use a UML class diagram to organize the business concept model. The basic syntax of this diagram is as follows: 1) The rectangles in the diagram are classes. This diagram has four classes: students, schools, courses, and scores; 2) there is a solid line between the students and the school, indicating that they are "related"; 3) the relationship between the student and the school is "* to 1", indicating that multiple students correspond to one school; 4) the relationship between the student and the course is "* to *", indicates that multiple students correspond to multiple courses; 5) the score class has a dotted line connecting students to the real line between the students and the courses. This score class is called an association class, this may be difficult to understand. It indicates the constraints on the relationship between students and courses. You can understand this "score" as follows: The score of each student in each course.
There are two types of business modeling: business structure modeling and business behavior modeling. In fact, the above case is "business structure modeling", which mainly analyzes the data structure; "business behavior modeling" mainly analyzes processes and processes, in Figure 7.1, one of the work products of "requirement analysis" is "Business Flow Chart", which is a product of behavior modeling. Later articles will share more information about behavior modeling.
Based on this business concept modeling, we can design the following databases, which will be illustrated through three diagrams.
Figure 7.3 The Database Design of the Course Selection System 1 is a small business modeling diagram in the upper-right corner. For your convenience, Figure 7.3 shows the database design corresponding to the "Student Class" and "school class.
Figure 7.4 Database Design of the Course Selection System 2 This figure shows the database design corresponding to "course class" and "score class". Please focus on the database design of "score class.
Is a summary of the above two figures:
Figure 7.5 Database Design of the Course Selection System 3
There are a total of four data tables in this database design. Think about how business conceptual modeling drives the database design in contrast to Figure 7.2. If we ignore the "business concept modeling" step, our database design may be: 1) The student table, school table, and curriculum cannot be split; 2) no partition table can be split and designed.
If you have used a E-R graph or a database with Power Design software, you will find that the content of the above article is exactly the same! Analysis of business concepts with class diagram, indeed and E-R diagram is very similar, the truth is also common, but there are still some differences: 1) E-R diagram is generally directly oriented to the database design, the relationship between objects is generally one-to-one, one-to-many, while the relationship between many-to-many is indirectly implemented through two-to-many; 2) a class diagram can also represent the relationship above, however, class diagrams can express richer content, such as inheritance (generalization), inclusion (aggregation, combination), dependency, and association class. That is to say, using a class chart to analyze the business concept model can achieve a wider and deeper effect. Of course, this is my personal experience and is for reference only.
If you have been using E-R charts well, there is no need to convert them into class charts for analysis. Whether it is a class diagram, E-R diagram, or other diagrams or tools, we aim to better understand the needs, sort out the business and sort out the appropriate business concept model, lay a solid foundation for database design.
I wanted to write an article, but the longer I did not know it, I was reluctant to cut down the content. So I divided it into the next two articles. The next article will share with you: 7.4 business modeling and database design of the attendance system
7.5 business modeling is upgraded to the next level to create a more flexible database design
7.6 database design summary
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, welcome to consider my upcoming event in Shenzhen: Agile encounter UML details please click this link: 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
