VB+SQL Server2000中小型医院药品管理系统 第8页
根据对数据流图和数据字典的分析，确定该应用中的实体、属性和实体之间的联系，并画出系统总体的E-R图。概念设计可分为三步进行：首先设计局部E-R模式，然后把各局部E-R模式综合成一个全局模式，最后对全局ER模式进行优化，得到最终的模式，即概念模式。
实体和属性的定义。ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。若有联系，进一步确定是1:N，M:N，还是1:1等。还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系，等等。
利用ER方法进行数据库的概念设计，可分成三步进行：首先设计局部ER模式，然后把各局部ER模式综合成一个全局模式，最后对全局ER模式进行优化，得到最终的模式，即概念模式。
所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。
1) 局部ER模式的合并
合并的原则是：首先进行两两合并；先和合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。
2) 消除冲突
冲突分为三类：属性冲突、结构冲突、命名冲突。
设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一的概念模型。
3) 全局ER模式的优化
在得到全局ER模式后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式，除能准确、全面地反映用户功能需求外，还应满足下列条件：实体类型的个数要尽可能的少；实体类型所含属性个数尽可能少；实体类型间联系无冗余。
各个实体的E-R图如下所示：
图5.1 药品信息E-R图
图5.2 用户信息E-R图
图5.3客户信息E-R图
图5.4 供货商信息E-R图
图5.5 定货报表E-R图
图5.6出货报表E-R图
图5.7定货信息E-R图
图5.8出货信息E-R图
图5.9用户登录信息E-R图
所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。
系统的总体E-R图说明
1) 每个用户可以查看多个定货报表,一份定货报表可以被多个用户查看；
2) 每个用户可以查看多种药品信息,每一种药品信息可被多个用户查看；
3) 每个用户可以查看多个出货信息,每一种出货信息可被多个用户查看；
4) 每个客户可以购买多种药品,每一种药品可被多个客户购买；
5) 每个客户可以查看多个出货报表,而每个出货报表只能被买药品的客户所查看；
6) 每个供货商可以提供多种药品,每种药品可以被多个供货商所提供；
7) 每个供货商可以查看多个定货信息,但每个定货信息只能被一个供货商查看,即提供药品的供货商；
图5.10全局E-R图
数据库的逻辑设计的任务就是把概念结构设计阶段的基本E－R图转化为与选用具体机器上的DBMS产品所支持的数据模型相符合的逻辑结构，首先要实现的是E－R图关系模型的转化。而为此要解决的问题是如何将实体和实体之间的联系转化为关系模式，如何确定这些关系模式的属性和码。对于实体，将每个实体转换为一个关系，实体的属性即为关系的属性，实体的码即为关系的码。
对于实体间的联系，可以分成三种情况：
1.若实体间的联系是1：1，可以在两个实体转换成的两个关系中任意一个关系的属性中加入另一个关系的码。
2.若实体间的联系是1：n，则在n端实体转换成的关系中加入1端实体转换成的关系码。
3.若实体间的联系是n：m，则将联系转换为关系，关系的属性为诸个实体的码加上联系具有的属性，而关系的码则为诸实体的码的组合。
本系统中所涉及到的关系的主码与外码如下所示：
药品（药品编号、药品名称、药品单价、数量、规格、购置日期、生产厂家）
用户（用户编号、姓名、性别、出生日期、家庭住址、联系电话）
供货商（供货商编号、名称、地址、电话、邮编、）
客户（姓名、性别、年龄、出生日期、家庭住址、联系电话）
定货报表（药品编号、药品名称、数量、定货日期、生产厂商、规格）
出货报表（药品编号、药品名称、数量、出货日期、生产厂商、规格）
定货信息（药品编号、入库单价、药品名称、数量、定货日期、生产厂商、规格）
出货信息（药品编号、出库单价、药品名称、数量、出货日期、生产厂商、规格）
用户登陆（用户名,密码）
程序流程图也称程序框图，它的历史比较悠久，使软件开发者所熟悉和普遍采用的一种算法表达工具。
程序流程图的优缺点：
1)由于不支持逐步求精，它使程序员过早的考虑程序控制细节，而不考虑程序整体结构。
2)流程线转移不受限制，容易破坏程序的整体结构。
3)不适于表达数据结构和模块调用关系。
4)描述过于琐碎，不利于理解大型程序。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>