Example of agileeas. NET platform development-pharmacy system-Database Design

 

Opening

 

In the previous article, we analyzed functional and non-functional requirements. In this article, we will look at how to design the database. Of course, the database design is also skillful, however, many people often design databases.

We know that if our database design fully complies with the third paradigm required by the database, it may be inconvenient for us to use this database design through the ORM framework, because ORM is associated with multiple tables

The processing or support on is not good, so we often allow redundant fields in the table during database design, in this way, we can easily read data during the query process without associating the query,

Of course, there are also good solutions to deal with this demand, such as through views.

Next let's take a look. If you design the database of the pharmacy system, we will attach the download of the database design document.

Outline

 

 

1. design the database of the function module.

2. Analyze the rationality of the design.

 

Design the database design for each function module

 

 

In this section, we will design a database based on the requirements document of the previous article to analyze the database design of each module. We will take a holistic approach, the common infrastructure that we use in each module

Whether independent maintenance and management are required.

Next we will analyze the separate tables we need to design:

Next we will analyze the design of the database tables for each module:

1. Basic data

Drug dictionary:

Of course, some of the above fields are not fully reflected. Some specific supplementary designs can be improved based on this.

Supplier:

Supplier information is mainly used to provide assistance for drug procurement and drug withdrawal. With supplier information, funds can be directly allocated in the future. Of course, it is possible to pay the supplier money based on the consumption, his Hospital System

This mechanism is generally available.

Maintenance of the drug type to facilitate later extension and editing. It is generally not recommended to directly Delete the drug type, which may cause data loss and failure. We recommend that you enable the disabled field.

2. drug warehouse receiving

To import a drug to the database, you must reference the drug information in the drug dictionary table, store the supplier information, and reference the drug type.

3. drug warehouse delivery (for customers to issue medicines)

The drug warehouse here refers to the customer sending the drug in the drug store system, which needs to save the customer's name, date of sending the drug, quantity, and so on, so as to help the later customers to return the drug.

4. Inventory Management

Inventory management refers to the inflow or outflow of drug data from all modules.

5. drug withdrawal from the supplier

The supplier withdraws medicines, mainly from the drug store to the supplier, and records the details of the drug records returned from the drug store.

6. Customer withdrawal

Customer withdrawal. The customer name, quantity, date, and other information must be included to facilitate future statistical queries and detailed records.

7. Drug Price Adjustment

Detailed records, price adjustment reasons, quantity of drugs for price adjustment, price adjustment date, new and old prices, and other information.

8. Report Drug loss

Record the quantity, cause, date, and so on.

9. Drug inventory check

The inventory table records the inventory information, the inventory information, the actual inventory information, the date of the inventory, the status of the inventory record, and whether the operation has been adjusted.

The main modules involved in the drug store system have been covered. You can see a lot of redundant information from the above design, such as the content about the drug information, there are a lot of redundant content. Mainly for convenience

The reading of basic information prevents too many associated queries. Of course, the view can also be used, but it will be inconvenient to use in encoding. Of course, redundant fields may cause too large physical storage in the database. Of course, if

If we say that our data is of a large magnitude, we may need to consider this requirement during design. When our data volume is not large, we may be more efficient.

 

Design Analysis

 

 

Through the above database design document, we found the following points. We saved the following fields of medicines in each table:

Whether we should directly store the primary key information in the drug dictionary, and then directly reference the primary key in the drug dictionary as the foreign key in other tables, this may be a benefit, if we maintain a drug word later

After the ceremony, after the information changes, all the drug information will be synchronized, but there is also a bad thing. Maybe we sometimes need to keep the original drug dictionary information, when used to track historical records, problems may occur. And. Dimension

Protection. We must associate the drug dictionary table. Of course, creating a view can solve this problem.

In addition, when designing a database, we must design a field that is not easily deleted when it is like basic data. The pseudo-deletion is better. For example, we add the following fields.

Of course, not deleting will cause too much redundant data, but after deletion, it will cause some data information errors or invalid references. How can we do this, the above table stores related drug information from the side

It can also avoid the issue that cannot be referenced when the basic data is deleted.

There are still many other techniques in the database design process, which take the two factors of vertical change, we will maintain the association between the two changing factors through an association table. There are still many specific applications,

Of course, my level is also limited, and it may not be very reasonable. You are welcome to make a brick. If some content is incorrect or incorrect, please correct it.

 

Summary

 

 

This article mainly provides the database design of the pharmacy system. Of course, my database design may not be suitable for actual use. If you have better design ideas, please note that I will not

Improvement.

 

 

Pharmacy system-database design document

 

 

 

 

More communication

 

 

Official blog: http://www.smarteas.net/

Http://www.agilelab.cn/

if you have any questions about using the agileeas. NET development platform, use the following contact methods or communication methods.

1. Telephone-Email:

He gozhou: hegezhou_hot@163.com Mobile: 18691480181 blog: http://www.cnblogs.com/hegezhou_hot/

2. QQ chat group:

308961614 Network Name: h.o. T