"Introduction to Database Design Classics" Reading notes--Chapter One: the past and present of database modeling

"The beginning of the database design classic", is now learning this book, although the previous read a similar book, may be due to previous experience, some of the book said something only digested part, now relive side understood more. So read the first time read do not understand it does not matter, after a a year to read again, or will read not understand, haha.

That's the book.

Chapter One the past and present of database modeling

What is the difference between a database model and a database?

The database will serve a type of application. Different types of database models support different types of applications.

Online transaction processing (online Transaction PROCESSING,OLTP) databases are typically specialized, highly concurrent (shareable) architectures that require fast access to very small amounts of data.

File system

Hierarchical Database Model

Network Database model

relational Database model

Object Database model: Compared to relational database models, the object database model solves complex problems that are more difficult to understand, such as eliminating the need for types and many-to-many relationship substitution tables. Another advantage of the object database model is the inherent ability to manage and cater to very complex application and database models. This is because of the fundamental principle of object methodology: Very complex elements can be decomposed into the most basic parts, allowing explicit access to and execution of these basic parts. It is important to discuss the object database model when describing the relational database model in the book, because many modern applications are written using an object-based SDK (such as Java). One of the most important key points between object programming applications and relational data is the performance of the mapping process between two structured types (objects and relationships).

When retrieving multiple data items, the performance of the object database model is relatively poor. On the other side, relational data is best suited to retrieving data sets, but it can also effectively access unique data items.

Type of database:

Transaction: Minor changes to the database (small transaction)

DSS (decision support SYSTEM,DSS): Data Warehouse databases are generally inflexible because they can be extremely large

Mixed: For small and medium companies it is more appropriate to choose, because there is only one instead of two databases, fewer machines, fewer software licenses, fewer people

For a database model, you must design it before you build, and then start populating it with data and associating it with the application.

The design of the database is important because all applications written according to the database model design are completely related to the structure of the underlying database. If you must modify the database model in a later stage, you may have to modify all content that is based on the database model, or you may need to rewrite it completely.

A well-structured database model with a good structure is a simple, easy-to-read, and easy-to-understand database model.

Data integrity-Integrity is a set of rules in a database model that ensures that data in a database is not lost.

The fewer queries that support scheduled queries and Ad-hoc or unplanned queries--ad-hoc, the better. In some environments, such as in very high-concurrency OLTP databases, you may have to completely prohibit ad-hoc queries or move to a more appropriate data warehouse platform.

There are a few small points:

Ad-hoc queries can cause serious performance problems. Customer-facing applications that require millisecond response time do not get along well with Ad-hoc queries.

Support business goals-highly normalized table structures do not necessarily represent business structures directly, and non-normalized, data Warehouse, fact-latitude structures may be more appropriate for operational operations.

Provide the appropriate performance for any necessary modification operations

Each table in the database model should be more appropriate to represent a topic or topic-don't design the database model too much, don't create too many tables. The OLTP database may become large because of more detail and more tables, and the data warehouse may crash if you divide the data into too many tables.

Future growth must always be a matter of serious consideration-some databases may grow at an immeasurable rate.

Methods of database Design

How do I start designing a database model?

Demand Analysis-Collects the following information: The nature of the data, the required characteristics, and any particular needs, such as the expected output response.

Conceptual design--start using graphical tools to draw beautiful graphics: Entity Relationship diagram (ERD). This step involves creating a table, a field in a table, and a relationship between tables. This step also includes normalization.

Logical design-Create a Database language command to generate a table definition.

Physical design--Adjust database language commands to modify the database model against the underlying physical properties of the table.

Adjustment phase-This step includes several items, such as proper indexing, further normalization, even anti-normalization, security features, and other content not included in the previous steps.

These individual steps are interchangeable, repeatable, iterative, and truly capable of doing anything.

The only common fact that should be adhered to is that you should draw the ERD well before building the metadata table and build the table, and visually design it before you actually implement it.

"Introduction to Database Design Classics" Reading notes--Chapter One: the past and present of database modeling