"Getting Started with Database design Classics" Reading notes--Chapter III: Database modeling in the workplace

Normalization is used to granularity and organize the data that is used in the database.

The process of normalization and application paradigm will be described in detail in the 4th chapter. At this stage you only need to know that normalization is the method or formula used to divide data into separate tables--based on a set of rules.

Do not trust the view for anything other than a security goal.

The concept of a table

In the data model theory, a table is a bucket that is continuously stored in the data. The idea of a relational database model and normalization is that the data in a particular table is directly associated with all other items in the same table.

All records in the same table have the same field structure.

Tables, fields, records, tuples

fields, columns, and properties are terms used to describe the fields in a table.

Data type

The data type can be divided into 3 types:

• Simple data types-these are data types that apply a pattern or a value limit on a single value.
• Complex data types-any data type that includes connection objects and relational databases, including items such as binary objects and collection arrays.
• Specialized data types-there are more advanced relational databases that can store the inherent structured data, such as XML documents, spatial coordinate data, and multimedia data.

About Normalization

Normalization usually tries to divide the information into smaller, more manageable parts, but preferably not too small. Most of the obvious redundancy can usually be removed. Commercially, the primary goal is to save space and organize data for availability and manageability. Very busy applications and end-user requirements may force a violation of standardized rules in many ways to meet performance needs. Paradigms above the third paradigm are often ignored and sometimes even the third paradigm is ignored.

Normalization is the process of self-increment. In other words, each paradigm layer is added to the paradigm that has been applied. For example, the second paradigm could only be applied to tables in the first paradigm, and the third paradigm could not be applied to tables in the fourth paradigm, since the table in the fourth paradigm is, by definition, the accumulation of tables already in the third paradigm.

Advantages of Normalization

• Reduce the physical need to store data
• Data is better organized.
• Normalization allows you to modify a small amount of data (that is, a record) in a table at once.

Potential for standardized hazards

The positive effects of some of the specifics of normalization can have negative side effects and are sometimes counterproductive, depending on the database's application focus. Performance is always another problem: excessive granularity caused by excessive application normalization. Excessive demand for concurrent OLTP databases can be negatively impacted by excessive granularity. Be aware of the following points:

• The physical space involved is increasing
• Excessive minimization of redundancy implies fine-grained granularity and excessive tables. Too many tables can cause a particularly large SQL connection query. The more tables The SQL connection queries, the slower the query executes. Performance is thoroughly impacted, making the application completely useless.
• Using excessive amounts of redundancy to minimize better organization of data can actually lead to more complexity. The deeper the normalization level, the more mathematical the model becomes.

Expressing relationships with ERD

There can be various types of relationships between tables and tables, and it is best to describe the relationships between different types of tables through the display of entity diagrams (entities Relationship Diagram, ERD).

Bird foot Structure

The bird foot structure (crow ' s foot) is used to describe the "many" sides of a one-to-many relationship or many-to-many relationships. It should be understood that many toes refer to more than one and therefore are multiple.

One

A one-to-one relationship is less useful, except in exceptional cases where the price of the storage space is very cheap. The one-on relationship is a typical case of the fourth paradigm shift.

One-to-many

A one-to-many relationship is particularly common between tables in a relational database model.

Many-to-many

A many-to-many relationship means that for each record in a table, there are many possible corresponding records in the other table, and vice versa. The classic example of a many-to-many relationship is that multiple students enroll in multiple courses at the university. The implication is that each student is enrolled in multiple courses, and no way courses have multiple student registrations.

Many-to-many relationships can be solved with an intermediate correlation table, with two to many.

0 or one or more

The relationship between tables can be 0 or one or more. 0 refers to the record does not need to exist in the target table, with zero one refers to it can exist, no zero of the first refers to it must exist, and more refers to multiple.

Even if publishers do not currently publish any books, they can be called publishers.

Identifying and non-identifying relationships

Figure 3-20 shows the identity relationship, the non-identity relationship, and the dependent table.

• Identity relationship--the child table is identified by the parent table part and depends partly on the parent table. The primary key of the parent table is included in the primary key of the child table.
• Non-identity relationship--the child table does not depend on the parent table, so the child table is the primary key of the parent table as a foreign key, not as part of the primary key of the child table.
• dependent entities or tables--coauthor tables depend on the author and publication tables. A dependent table exists for a table that has an identity relationship to the parent table.
• Non-dependent entities or tables-this is the opposite of a dependent table.

Keys are used to identify and ultimately retrieve records from the database at a later date.

"Getting Started with Database design Classics" Reading notes--Chapter III: Database modeling in the workplace