AgileEAS.NET平台开发实例-药店系统-数据库设计

2011-04-02 900

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 开篇上篇，我们分析了，功能需求和非功能性的需求，本篇我们就来看下，如何设计数据库，当然数据库的设计也是有一些技巧性而已，不过大家经常做数据库设计的朋友都知道，如果我们的数据库设计完全符合数据库要求的第三范式的话，那么我们可能在通过ORM框架来使用这个数据库设计的时候，会有不方便的地方，因为ORM在多表关联上的处理或者说是支持的并不好，所以我们常常在数据库设计的时候，会允许在表中存在冗余字段，这样我们能够在查询的过程中可以很方便的读取数据，而不用关联查询，当然也有不错的方案去处理这方面的需求，比如通过视图等。

开篇

上篇，我们分析了，功能需求和非功能性的需求，本篇我们就来看下，如何设计数据库，当然数据库的设计也是有一些技巧性而已，不过大家经常做数据库设计的朋友都

知道，如果我们的数据库设计完全符合数据库要求的第三范式的话，那么我们可能在通过ORM框架来使用这个数据库设计的时候，会有不方便的地方，因为ORM在多表关联

上的处理或者说是支持的并不好，所以我们常常在数据库设计的时候，会允许在表中存在冗余字段，这样我们能够在查询的过程中可以很方便的读取数据，而不用关联查询，

当然也有不错的方案去处理这方面的需求，比如通过视图等。

下面我们就来看看，如果设计药店系统的数据库，后面我们会附上数据库设计文档的下载。

大纲

1、设计功能模块的数据库设计。

2、分析设计的合理性。

设计每个功能模块的数据库设计

         我们本节将会根据上篇的需求文档来进行数据库的设计，来分析每个模块的数据库设计，我们采取的方式还是从整体上去考虑，我们在每个模块都要使用的公共的基础设

计等是否需要单独维护和管理等。

         下面我们来分析下我们需要设计出的单独的表：



          下面我们来分析下每个模块的数据库表的设计：

      1、基础数据

           药品字典：



           当然上面的有些字段并没有完全的体现出来，具体的一些补充设计，大家可以基于这个基础之上进行完善和改进。

           供应商：



            供应商信息主要是为了药品的采购和退药提供帮助，有了供应商信息后，后期可以直接进行拨款操作，当然这是根据这种按消耗付给供应商钱成为可能，HIS医院系统

一般都会有这样的机制。



              药品类型的维护，方便后期进行扩展和编辑等，一般不推荐直接删除药品类型，会造成数据的丢失和失效性，建议可设计启用禁用字段。

        2、药品入库



              药品入库一方面是需要引用药品字典表中的药品信息，还要保存供应商信息，同时还要引用药品类型。

        3、药品出库(顾客发药)



               这里的药品出库，就是药店系统中的顾客发药，里面需要保存顾客的姓名，发药日期，数量，等等，这样可以为后期的顾客退药提供帮助。

         4、库存管理



                 库存管理，是所有模块的药品数据流的流入或流出。

         5、供应商退药



                  供应商退药，主要是药店退药到供应商，记录药店退供应商的药品记录明细。

          6、顾客退药



                   顾客退药。必须包含退药的顾客姓名和数量，日期等信息，方便后期的统计查询等，并详细记录明细信息。

           7、药品调价



                    详细记录，调价原因，调价的药品数量，调价日期，新旧价格等信息。

           8、药品报损



                  记录报损的数量，原因，日期等。

          9、药品盘点



               盘点表记录盘点的信息，账目库存与实际库存信息，记录盘点的日期，盘点记录的状态，是否进行过调整操作等。

               药店系统目前涉及到的主要模块都已经涵盖，大家可以从上面的设计中看到很多的冗余信息，比如关于药品信息的内容，有很多的内容都冗余。主要是为了方便

基础信息的读取，防止过多的关联查询，当然通过视图也可以解决，但是还是会在编码中使用起来会有一定的不方便，当然，冗余字段会造成数据库物理存储太大，当然如果

说我们的数据的数量级很大的话，可能我们需要在设计的时候，考虑这个方面的要求，当我们的数据量不是太大的时候，可能我们更讲究效率优先。

设计分析

           通过上面的数据库设计文档，我们发现了以下的几点，我们在每个表里面都保存了药品的如下几个字段的信息：



           我们是否应该直接保存药品字典中的主键信息，然后其他表里面直接引用药品字典中的主键作为外键即可，那么可能有这样的一个好处，如果我们后期维护一个药品字

典后，信息变更后，所有的药品信息，都会跟着同步，但是也有一个不好处，也许我们有时候需要保留原有的药品字典信息时，用于跟踪历史记录时，就会出问题。而且。维

护时。我们必须要关联药品字典表，当然建立视图可以解决。

            并且我们在设计数据库时，对于像基础数据这些信息时，一定要设计为不要轻易删除的字段，伪删除比较好，例如我们添加如下字段。



        当然不删除会造成冗余数据太多，但是删除后会造成部分数据的信息错误，或者说无效的引用，那么我们如何来做，上面我们在每个表中都保存相关的药品信息，从侧面

也能避免删除基础数据时造成的无法找到引用的问题等。

         数据库设计的过程中还有很多的其他的技巧，把二个都纵向变化的因素，我们会单独通过一个关联表来维护这二个都变化的因素之间的关联关系。具体的应用还有很多，

当然我的水平也是有限，不一定是很有道理，欢迎大家拍砖，如果部分内容有错误或者不正确，还请大家指正。