Database Design Knowledge Point

1stExample: rows cannot be repeated, and Columns cannot be divided (the column value is unique)

2ndExample: Non-master dependency Non-primary key columns depend on primary key columns

3rdExample: Non-master independent Non-primary key columns are mutually independent.

 

Data Modeling steps

1. Analyze requirements and draw an example Diagram

2. Write case text, design the interface prototype, and simulate functional scenarios

3. Entity searching

4. Recognize Object Attributes

5. Identifies the relationship between entities (one-to-one, one-to-many, multiple-to-many)

6. Draw a conceptual data model (ErFigure)

7. Convert a conceptual data model to a physical data model (Table)

8. Modifying the physical data model based on the paradigm continues to repeat 5

 

Object Modeling

1. Analyze requirements and draw an example Diagram

2. Write case text, design the interface prototype, and simulate functional scenarios

3. Identify the business model (domain object)

4. Find key nouns and verbs to identify the attributes and responsibilities of a class.

5. Identify the relationship between business models (Association, dependency, combination, aggregation, generalization, implementation)

6. Converts a business model to a conceptual data model., 4, 5, 6

ErEntity and OO inDifferences between domain objects in:

1.      Domain ModelA higher abstraction level, closer to the real world and business, and closer to the database

2.      An object must correspond to a table, while domain ModeIt may be a virtual service that only exists at the business layer (such as the shopping cart) and does not need to be persisted to the database, or a domain model.Composed of multiple tables.

3.      When the business is complex, use domain modelThe Requirement Description is better, but the corresponding domain modelThe ing with the database table becomes very complex and the matching degree is very low.

4.      Data Modeling Based on databases is easy to use (that is, the data displayed on the Interface comes from a database table). However, correct design requires rich experience. Take ooModeling for the starting point, whether the business is complex or not, it is easy to abstract the approximate Domain ModelBut when the business is complicated, the domain modelIng with database tables becomes very difficult.

conclusion: In theory, we advocate oo and DDD , however, due to objective conditions (the entire domestic software environment, small and medium-sized companies are eager for quick success, but do not focus on scalability and maintainability, supervisors the design concept is outdated, project cycle cost restriction) subjective conditions ( Program understanding of OO ), therefore, in many cases, we still use dB modeling or DDD to follow the old path of DB . In any case, the idea of DDD has blossomed everywhere, and the general trend is gradually becoming oo , move closer to DDD . Therefore, in such a period of transition, neither dB as the center design nor completely oo , instead, we should combine 2 (similar to the socialist road with Chinese characteristics) to learn from each other.