Practice the truth About database design experience __ Database

If the database design is likened to Sherlock Holmes, according to a variety of conditions, restrictions, rules, the ladder of Cocoon, looking for the mutual links, step-by-step in-depth case of the middle, the final settlement of the case. But the first need to solve the case, then for the database design to use a long time a series of design database structure of the mature method (such as: standardization) can be used to solve the necessary method of good foundation. In fact, almost all of these methods are classic design methods, so it's not too hard to follow these methods when designing a database. As we know, we can directly turn you into a SQL Server table by designing your methods directly.

But unless you're just trying to catch an obvious thief, you need all sorts of conditions, rules, restrictions, connections that must be taken into account. As we need to consider the distribution, redundancy, clustering, 24/7 support, access process, triggers, constraints, and integrity issues in a database solution, we need to introduce the technology of database structure. This technique does not provide a way to physically implement a database, but it can be used to choose the best approach.

In modern times, the whole database system can be decomposed into different components according to different service requirements, instead of using a technique to complete the whole task. They can be divided into:

OLTP (online transaction processing) The--OLTP database stores the data needed for the current business operation, its primary purpose is to make the current public data complete and reasonable, and to do so requires two principles: 1. Each current block of data can only be stored in one editable location, The changes here will reflect all the places where this data is used. 2. Provide transaction support to make multiple changes to the database in effect. If one of the changes in the transaction fails, all other changes are not allowed to take effect, the transaction aborts, and all operations are rolled back.

Business data Store (operational data store,ods)--for the summary of daily reports. This data often takes a few completely different places and makes a certain amount of summary to save the time of the query. Its purpose is to provide users with operational data and to track recent trends in order to make decisions.

Data Warehouse (Warehouse)----------------------------------------------------------------- Without impacting the ability of users to create and store data in an OLTP system.

Data Mart-a dedicated, prioritized data store for a Mart, for a specific occasion, where the content is stored as a subset of the Data warehouse. Data marts are typically processed using technologies that are OLAP. It is usually built for a specific requirement of a company, or for a specific business of an organization, and typically has two special database structures: Star mode and snowflake pattern.

For the above four types, the final database overall structure depends entirely on the size of the problem that the database will address.

In most computer systems today, databases are the core. Even if not a database-core system, there is a need for data storage. Software, in the final analysis, is also the processing of data.

In the Internet, in banks, government agencies, companies, schools, supermarkets, pharmacies and other places, there are many database instances. This kind of database design process can generally be decomposed into the following steps:

It's important to define goals-not to be laughed off by the obvious, because many projects are caused by developers not knowing what the user is actually going to do or what they need, and risking or not being able to listen well to the user's correct or full opinions. At this stage, we define functionality, performance, customer base, and write requirements reports for the system that is ultimately created.

Logical design--to achieve the ultimate goal, through the analysis of the user's business, the implementation of the logical design

Physical design-take advantage of the results of logical design and transform it into a true implementation. This phase involves how the database system is physically implemented and we need to use those hardware and software.

Physical implementation-The project implementation phase involves actual physical data, database server development, and code to write access data.

Review-The process of assessing whether or not to reach the final goal. Most projects overlook this stage because it takes too long and raises little interest: testing, documenting, and accomplishing things that you don't want to do, but that you have to do. At this stage, there should be a way to take advantage of user feedback and maintain a plan to change all issues.

In the process of user usage, users are very rarely interested in the raw data or the actual interface used to access the data, as long as they are able to browse and process the data they need. Project design analysts, probably because of such reasons, tend to make some systems very awkward to use, consider the reasons for the poor.

The following are some of the conceptual design experiences I get from school, from my colleagues, from books, from the actual design:

1, define the target stage: Information collection, collection of information in the database project.

A, here you should try to avoid designing structures from the start. Even if you have database design experience, do not define tables and fields here and so on, you should process them step-by-step. Do not delve into a specific section before listening to users explaining their ideas and needs and summarizing the tasks that should be done by the project. We often implement a structure and a solution to a task that is not good for the customer or for us until we know enough about it.

b, in the analysis process, as soon as possible to write the required data into a document is a good habit. For example: In the company, because an employee is sick or another job, in order to not have a great impact on the development speed, the successor needs to go all out to understand the full content of the project, the only way to help them is the entire information document. So you know how important it is to write a document, and you don't want to leave any project content in your head. Note When recording user needs:

Maintain a set of shared system design and specification documentation. The document should consist primarily of: design meeting records, documentation of oral change requirements, and all final instructions, such as functions, techniques, testing, etc.

In addition to the documentation for the specification, a common repository is developed and maintained for all information.

Take some time to hold meetings and try not to post your personal opinion when the customer is telling. Let the customer speak out and listen to every suggestion, request, or idea that the customer has.

Pay attention to the information that you have added without the user's permission.

The scope of project use should be established early and always kept in mind. Doing so avoids the development of a project that is too big or misses something useful. Write a description of the project's operating scope (task description or Task object) to describe the project's parameters. The specification should be continuously negotiated, contrasted and perfected during the design and implementation of the project until it is finally completed. If the object and the final goal of the project are not confirmed at this stage, or if no content is recorded, there is a good chance of conflict with the user when the idea is inconsistent with the customer. Therefore, make sure that the customer is clear about the system you are about to implement and describe it in a clear and understandable language, describing everything in detail as much as possible.

C, during the entire database design, the customer will usually make some changes to the field name, field definition, business rules, user interface and color, so you should be prepared. No matter what the customer request, should give support, this project will ultimately be controlled by the user, so you have to make the system flexible enough to apply changes in a variety of uses, whether secondary or primary, but the idea of these customers is based on the customer's decision to make at the design stage.

Because at any point in time, customers can say to you, "How come there is a missing", "I did not say so" and so on. If you're talking, there's a lot of trouble when you don't have a document in your hands to hold your own. Therefore, if you make a decision that is different from what the customer says, you should use the documentation to prove the correctness of your decision.

D, database prototype as the company and customers when signing contracts with each other to communicate information used in the picture. Each negotiation has to rely on the development of the prototype, it can be a good reflection of the developers eventually developed products. Database designers can use it as a working model, design documents to avoid the lack of information required by users.

E, talk to customers should pay attention to, do not first speak, threatening customers, and before they tell you what they want to do before the event to discuss your views, regardless of the user's expectations are likely to cause the project failure. Friendly negotiation with our clients is a solid foundation for us to get the design information. If the foundation is not reliable, the final product will not succeed. In presenting to the customer:

1. Who uses the data.

2, how to use these data.

3, the customer needs those reports.

4. Previous methods of data processing.

5, by those rules control the use of data.

All these questions need to be understood clearly.

2. Logic design Phase

A, I think in the logic design phase, should be prohibited to talk about performance issues, should aim at the conceptual model. As a general recommendation, designers should try to standardize as high a level as possible. If a performance problem is found in the system test, the system can be normalized in reverse. But we should never abandon the normalized structure in order to adjust the performance of the application. So, advocates wait until the physical modeling stage or at least compelling reasons to reverse normalization.

b, at the end of the logical design, when the next step begins, consider the following questions:

1, the use of data

Processing of reports, use and ownership of data, interface with external systems, data transformation plans

2, the capacity of the determination

Table and Database growth

3. Project plan

4, the Final Document review

Read through all the documents and revise and calibrate them. Make the customer sign the contract.

C, as a designer, you should also make the necessary forecasts and documentation for the customer's potential future needs. This allows for more time to operate when the customer's future business arrives.

Concluding remarks

Of course, with the development of database technology, a variety of technologies, new methods will continue to appear. This requires us to explore in the numerous complex, to explore.