For a database administrator, the best thing he can do for his database is to make it start with a reasonable logical design. Unfortunately, the database design is often done in a rush so that it is wrong, or even reworked after the database is created. A knowledgeable and Intelligent Database Administrator knows that a good design of the database will greatly improve the performance of the database, rather than compromising the performance of the database. This idea is contrary to the popular idea. In fact, directly investing in physical design or deeper work will only cause trouble, not only in terms of performance, but also in terms of data integrity.
If a database runs fast but the collected data is incorrect, what are the advantages? In addition, in the early design phase of the database system, creating a reasonable logical design can make it take the test of physical design changes in the subsequent creation and maintenance stages. However, if you take a shortcut in the logical design phase, you may not only need to redesign the logical model, but may also need to reconstruct the following physical model. Indirect cost of the staff's work time, suspension period, etc.) may be surprising. Before developing and establishing a database, you need to understand the basic principles behind logical database design and standardization.
In the middle of 1970s, relational database models gradually surpassed other data models. The popularity of Oracle relational model technology standardized the design performance. The most popular one is the Entity relation graph Entity-relationshipdi.pdf, ERD), which was proposed by P. P. Chen in 1976. This is the semantic data model, because it tries to capture the meaning of business elements. Because the relational model itself is almost a syntax-based model, it is a model that mainly processes the structure, and the object relationship graph ERD) is usually used to supplement it. In fact, ERD modeling must be prior to link modeling. When an ERD ends, it is more or less directly mapped to the relational model, and then the relational model is mapped to its physical model.
An entity is a business element, such as an employee or a project. One relationship is the relationship between two entities, such as employees working on different projects. Attributes are the characteristics of an entity, such as the salary of an employee or the budget of a project. Attributes are considered to be a set of values or values in the definition field. Their values are the data they will use in the relational model later. They extract all or part of a thing. ERD has many painting methods, as long as you choose one and keep the meaning consistent throughout the use process.
Use a box to represent the objects that draw an advanced graph without attributes), and place the object names in the center of the box. The Object Name of a low-level graph is listed in the upper part of the box followed by the attribute name.
There is an arrow between the boxes, indicating the link type. There are three basic types of relationships: one-to-one, one-to-many, and multiple-to-many. A one-to-one relationship uses a single arrow at one end or both ends of an online bar based on the type of a one-to-one relationship. One-to-multiple dual arrow headers and multiple-to-multiple dual arrow headers. When each value of an object is related to one value of another object and only one value, there is a pure one-to-one relationship, and vice versa. This type of relationship is rare.
A more common one-to-one relationship is a child relationship, which is one of the foundations of object-oriented analysis and design. In an object-oriented system, this is regarded as a class and a subclass or, more simply, a class level ). In other words, attributes such as length and width are sent to a more specific entity square on the attribute rectangle in a more common entity ). Therefore, the direction of inheritance is from general to special. Child-type relationships are more common than pure-type one-to-one relationships, but these two are not commonly used. Generally, when a designer encounters a one-to-one relationship by accident, he must ask the following questions:
■ Can these two entities be combined?
■ Are they exactly the same for their own goals?
■ Do they have to be independent and different for some business reasons?
Generally, one-to-one entity can be merged. In the Oracle relational model, the most commonly used relationship is one-to-many relationship. In this case, as a designer, the best thing you can do for yourself is to free yourself from all the many-to-many relationships. They are not really removed, however, you can use two or more one-to-multiple relationships in their original locations to replace multiple-to-many relationships. This is because the relational model cannot directly implement multiple-to-multiple relationships. Think about how to store Foreign keys if there are many employees engaged in multiple projects? You cannot store multiple values in a column, which violates the relational requirement that data must be atomic. This means that no unit can hold more than one piece of information. The information Rule also shows that it is a special case of the first paradigm FirstNormalForm. Therefore, to ensure data atomicity, each many-to-many relationship is replaced by two or more one-to-many relationships.
What you want to do is to split multiple-to-multiple relationships. In a relational model, a new entity called a position is usually called a cross table, because it represents the intersection of each pair of actual values in the two tables related to it, or join table. A cross table is such an entity: it is not always the true abstraction of some business elements, however, it is the basic method to solve and implement the many-to-many relationship in the Oracle relationship model.
- Procedure
- Introduction to Oracle Database learning methods
- Summary of Oracle Database experience
- Introduction to Oracle entry-level experience
- Analysis of Oracle mandatory access and control functions