[Import] v. Analysis of Common Database models (I) persons and organizations

Original 10: fat Liu (reprinted please indicate the author and source, thank you)

5. Common Database Model Analysis has an interesting proportion in our database model design field-"", I call it the "-rule ". What does it mean? This "5" indicates that about 50% of the functional designs are cross-industry and universal, whether you are engaged in commercial circulation projects, E-government projects, or online auction systems, although each project belongs to a different industry, 50% of the design ideas are the same. This is the "General Model Design" described in this chapter (chapter 5 ". In other words, the model design concept described in this chapter can be used in any project; "3" indicates that 30% of the design ideas are the same among different companies in an industry. This is the next chapter (chapter 6) the "industry model design" to be explained; "2" indicates that the remaining 20% is the unique business needs of a specific company. I will not introduce this part of this serialization. (1) Most enterprise systems of persons and organizations record information about persons and organizations, such as company employees, suppliers, sales customers, online customers, membership card customers, subsidiaries, internal organizations, and other information. When most systems design databases for this information, they create their own independent tables without extracting the common information, resulting in data redundancy. For example, in order to open up the sales market, Company A usually gives membership card customers certain preferential conditions, so it is obviously not possible to exclude the situation where the cardholder is A company employee or the cardholder is A supplier of the company. Assume that company B is both A supplier of Company A and A member card customer of Company A. If the database table is designed in an independent way, Company B's information is as follows, for example, the company name, contact person, contact phone number, contact address, and other information must be recorded repeatedly in Company A's "member card customer" table and "supplier" table. If Company B's information, such as the contact number and address, is changed, Company A must modify the records in the membership card customer table and supplier table at the same time, otherwise, the business personnel will find that the information of the same company (Company B) is registered differently in two places in the system. Which of the following statements is true? Business personnel will doubt the accuracy of software data, and then doubt the entire system. Similarly, in some large enterprises, internal departments and subsidiaries sometimes conduct business exchanges according to the sales method. "Production Workshop" is a supplier of "product marketing department", and "Production Workshop" is also a sales customer of "raw material purchasing department. Some large enterprise groups will also establish internal banks, and internal departments and subsidiaries will use internal transfer cheques to complete internal exchanges and settlement, various departments and subsidiaries adopt relatively independent cost accounting methods. In this way, if each department or subsidiary creates an independent "Organization" table, the information of the same organization is stored in multiple tables, in this way, data duplication occurs. If the same data is repeatedly stored in multiple tables, once a department changes due to business development, this will cause a lot of trouble for system users-not only increase the workload of data modification, but also need to carefully check the modifications made in multiple places, to ensure that the information of the same department is consistent in all parts of the software. To sum up, in order to solve the problem of unnecessary repeated data storage in the system, the database design model in this regard uses the "primary Expansion Model" we mentioned earlier ".

Source: http://blog.csdn.net/liu7537/archive/2006/05/09/713973.aspx