多对多关系至少需要3个表,我们把一个表叫做主表,一个叫做关系表,另外一个叫做字典表或者副表(字典表是纪录比较少,而且基本稳定的,例如:版块名称;副表是内容比较多,内容变化的,例如)。
按照数据库的增删查改 *** 作,多对多关系的查找都可以用inner join或者
select from 主表 where id in (select 主表id from 关系表)
1,角色任命型
特点:关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键,有一个表是字典类型的表。
界面特点:显示主表,用checkbox或多选select设置多选关系。
例如:任命版主(用户表-关系表-版块名称表),角色权限控制等,用户是5个版块版主,只要关系表5行纪录就可以确立,关系表的两个外键具有联合主键性质。
增加关系:如果没有组合纪录,insert之。
删除关系:如果有组合纪录,删除之。
2,集合分组型
特点:同角色任命型类似,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。区别是主副表都不是字典表,可能都很大不固定。
界面特点:显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。
例如:歌曲专集(专集表-关系表-歌曲表)。手机分组(分组表-关系表-手机表)。用户圈子(圈子表-关系表-用户表)。文章标签(文章表-关系表-标签表)
增加关系:同版主任命型。
删除关系:同版主任命型。
3,明细帐型
特点:关系表可以有重复纪录,关系表一般有时间字段,有主键,可能还有文字型的字段用来说明每次发生关系的原因(消费)。
界面特点:显示关系表,用radio或下拉设置单选关系。
例如:现金消费明细帐或订单(用户表-订单表-消费原因表),用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。
增加关系:不管有没有组合纪录,insert之,纪录时间。
删除关系:根据关系表PK删除。
4,评论回复型
特点:同明细帐型关系表一般有时间字段,有主键,区别是重点在文字型的字段用来说明每次发生关系的内容(评论回复)。
界面特点:回复文本框。
例如:论坛回复(用户表-回复表-帖子表),用户可能多次在不同帖子上评论回复费。
增加关系:不管有没有组合纪录,insert之,纪录时间和文字。
删除关系:根据关系表(回复表)PK删除。
5,站内短信型
特点:主副表是同一个,关系表一般有时间字段,有主键,重点在关系表文字型的字段用来说明每次发生关系的内容(消息)或者其他标记位来表示文字已读状态时间等。
界面特点:回复文本框。
例如:站内短信(用户表-短信表-用户表),用户可能给用户群发或者单发,有标记位来表示文字已读状态时间等。
增加关系:不管有没有组合纪录,insert之,纪录时间和文字。
删除关系:根据关系表(回复表)PK删除。
6,用户好友型
特点:主副表是同一个,同集合分组型,关系表两外键组合无重复纪录,关系表一般不需要时间字段和主键。
界面特点:同集合分组型,显示主表,用搜索代替简单的checkbox或多选select,或者一条一条的添加。
例如:下载站点的文件,(文件表-关系表-文件表)可以被软件工具打开,软件工具本身也是一种文件,可以被下载。用户的好友,也是用户(用户表-好友关系表-用户表)
增加关系:同版主任命型。
删除关系:同版主任命型
随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧
一 成立数据小组
大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成
数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库(如果存在旧系统)的分析及数据转换 数据库设计的审核 控制及必要调整
二 设计原则
规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询
控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计
库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复
并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询
必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息
数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求
头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改(可由管理软件自动完成) 并通知相关的开发人员 以便进行相应的程序修改
三 设计技巧
分类拆分数据量大的表 对于经常使用的表(如某些参数表或代码对照表) 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率
索引设计 对于大的数据库表 合理的索引能够提高整个数据库的 *** 作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的 *** 作效率
数据 *** 作的优化 在大型数据库中 如何提高数据 *** 作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔 *** 作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统 *** 作的核心 有可能在 *** 作时被其他进程锁定 因而使整个事务 *** 作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O *** 作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O *** 作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表 *** 作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop *** 作再进行重建
数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整
必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率
避免长事务 对单个大表的删除或插入 *** 作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序 *** 作共同构成的长事务(如银行交易系统的日终交易) 可以由一系列 *** 作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务
适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能
lishixinzhi/Article/program/SQL/201311/16498
1、概念设计:
对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等),通过对其中住处的分类、聚集和概括,建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
所建立的模型应避开数据库在计算机上的具体实现细节,用一种抽象的形式表示出来。以扩充的实体—(E-R模型)联系模型方法为例,第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等,从而给出各部门内所用信息的局部描述。第二步再将前面得到的多个用户的局部视图集成为一个全局视图,即用户要描述的现实世界的概念数据模型。
2、逻辑设计:
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式,即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时,可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。
3、物理设计:
根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施,对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。
4、三者关系:
由上到下,先要概念设计,接着逻辑设计,再是物理设计,一级一级设计。三者一环扣住一环,缺一不可,概念设计是前提,逻辑设计是纽扣,将概念设计和物理设计紧密联系起来,物理设计的结果就是传说中的“物理数据库”也就是最后的结果。三者密不可分,缺一不可。
扩展资料
数据库设计的基本步骤:
1、需求分析阶段:准确了解与分析用户需求(包括数据与处理),是整个设计过程的基础,是最困难、最耗费时间的一步。
2、概念结构设计阶段:是整个数据库设计的关键,通过对用户的需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型。从实际到理论。
3、逻辑结构设计阶段:将概念结构转换为某个DBMS所支持的数据模型,对其进行优化。优化理论。
4、数据库物理设计阶段:为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。选择理论落脚点。
5、数据库实施阶段:运用DBMS提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果,建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。理论应用于实践。
6、数据库运行和维护阶段:数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。理论指导实践,反过来实践修正理论。
主要特点:
1、 实现数据共享:数据库服务器数据共享包含所有用户可同时存取数据库中的数据,也包括用户可以用各种方式通过接口使用数据库,并提供数据共享。
2、 减少数据的冗余度:同文件系统相比,由于数据库实现了数据共享,从而避免了用户各自建立应用文件。减少了大量重复数据,减少了数据冗余,维护了数据的一致性。
3、数据的独立性:数据的独立性包括逻辑独立性(数据库中数据库的 逻辑结构和 应用程序相互独立)和物理独立性(数据物理结构的变化不影响数据的逻辑结构)。
4、数据实现集中控制:文件管理方式中,数据处于一种分散的状态,不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理,并通过 数据模型表示各种数据的组织以及数据间的联系。
5、数据一致性 和可维护性,以确保数据的安全性和可靠性主要包括:安全性控制:以防止数据丢失、错误更新和越权使用;完整性控制:保证数据的正确性、有效性和相容性;并发控制:使在同一时间 周期内,允许对数据实现多路存取,又能防止用户之间的不正常交互作用。
6、故障恢复:由 数据库管理系统提供一套方法,可及时发现故障和修复故障,从而防止数据被破坏。 数据库系统能尽快恢复数据库系统运行时出现的故障,可能是物理上或是逻辑上的错误。比如对系统的误 *** 作造成的数据错误等。
IT行业,数据库确实是一门相当重要的课程。但是在大学里面,对待数据库原理及应用这么课程以及其课程设计的重视程度就相差很大了,各个学校要求也不一样。如果是要学好,那确实要下工夫;如果只是完成课程设计,交差了事,其实相当简单。
既然是课程设计,也算是个小小的项目,既然是项目,也就离不开需求分析、数据库设计、部署实现等环节。当然,这个小小的项目只需要前面的部分:需求和数据库设计,数据库设计是重点。
需求分析就不用多说,和所有其他项目一样,无非就是用户需求,功能需求,系统需求等,找任何一本关于需求分析的书都是可以,除了那些个空话之外,更多的是要根据设计需要进行分析。
数据库设计就比较复杂一点,首先得把数据库原理搞清楚,比如:符合什么样的范式,怎么画ER图,如何理解用例图。在设计数据库之前,有一系列的分析要做:面向对象分析,用例分析,类和对象分析等等。分析到位是数据库设计成功的重要保障。分析完成之后才是设计,比如:逻辑结构设计,关系模式设计,存取方法设计,存储结构设计,数据完整性设计,参考完整性设计,Check约束,Default约束,触发器设计,视图设计,存储过程设计,权限设计等。这些都完成了,最后一步才是写SQL代码实现这些设计,创建数据库及相关的数据表,关联,视图,触发器,存储过程等一些列的看得见的数据库参数。
上面说的比较理论,也比较笼统。我想我可以用一个简单例子告诉你我要表达的意思。例子很简单,其中很多地方都不是太好,不过或许可以给你一个直观的思路。
数据库应用课程设计报告书
网上超市管理系统
成 绩:
学 号:
姓 名:
指导教师:
20 年 月 日
目录
任务书 (3)
1 需求调查、分析 (4)
11 企业介绍 (4)
12 需求调查及分析 (5)
2 面向对象分析和设计 (7)
21 用例分析 (7)
22类和对象设计 (12)
3 逻辑结构设计 (15)
31 类和对象向关系模式转换 (15)
32 关系模式优化 (16)
4 数据库物理结构设计 (16)
41 存取方法设计 (16)
42 存储结构设计 (17)
5 数据库完整性设计 (17)
51 主键及唯一性索引 (17)
52 参照完整性设计 (18)
53 Check约束 (18)
54 Default约束 (18)
55 触发器设计 (19)
6 数据库视图设计 (19)
7 数据库存储过程设计 (20)
8 权限设计 (20)
9 总结 (21)
参考资料 (21)
网上超市管理系统
摘要:
网上超市管理系统,是以网上管理方式为实例而设计的一种实用型管理系统。本系统最大的特点是通用性、简单 *** 作性,适用于超市的管理。随着商品的增多,商品管理人员的负担越来越重,为了让所有商品管理人员能从繁重的工作中解脱出来,实现无纸化办公;也为了使工作更有条理,更方便,更有效率,更为了超市在经营中提高利润而开发出这套网上超市管理系统。
1 需求调查、分析
11 企业介绍
在Internet飞速发展的今天,互联网成为人们快速获取、发布和传递信息的重要渠道,它在人们政治、经济、生活等各个方面发挥着重要的作用。在政府的大力提倡和支持下,我国电子商务已走上了健康发展的轨道。各行业纷纷建立自己的网站,开展网上产品信息发布,进行网上洽谈、签约,开展网络营销。将超市办成网上超市已经是大势所趋,甚至一些小型的超市也可以开展网上交易。总之,电子商务以互联网为媒介,以信息传播速度快、受众广泛、低成本动作的优势决定着其必然成为未来营销的主导,我国企业要充分重视由此带来的机遇和挑战,才能在激烈的国际竞争中立于不败之地。
在超市经营中,随着超市规模的不断扩大,人们对超市服务的要求不断提高,使用一款适合的网上超市管理系统将更加迫切。利用网上超市,人们可以在家里逛超市,只需要办理会员卡,就可以为本地顾客送货上门。不仅如此,把超市办成网上经营和管理将大大提高效率和收益。因此,开发一个网上超市管理系统是非常有必要和好处的。
12 需求调查及分析
121顾客需求
为方便用户购买商品,网上超市客户系统应该提供如下所示几种功能:
(1)商品分类:网上超市与传统超市相比的一个优势是,当用户明确自己要买哪类商品时,用户可以使用商品分类功能快速找到需要的商品。
(2)商品预览:以列表的方式显示商品信息,这样可以在页面显示大量的商品信息,同时可以提供更多的商品浏览方式,如分类浏览、热门商品等。
(3)商品显示:当用户找到感兴趣的商品后需要显示商品的详细信息,包括商品简介、出产商、价格等。
(4)购物帮助:当用户在购物中遇到什么问题时,可以查看购物帮助获得相关信息。管理员会根据顾客反映的情况及时更改或增添购物帮助的内容。
(5)购物车:当用户找到需要的商品时,可以先将商品加入购物车,然后继续允许找其他的商品,购物车中存储当前用户打算购买的所有商品。
(6)商品订单:当用户在网上超市中找到了所有需要的商品后,决定购买,可以下订单。管理员会定期处理用户下达的订单,并根据用户订单的信息向用户送货。
(7)用户注册:提供用户注册功能以及相关的用户信息修改、密码维护等。
122销售管理员需求
网上超市的销售部分的管理员功能是维护销售的正常工作,它需要提供如下功能:
(1)商品管理:商品是网上超市的内容所在,管理员需要能够维护超市中的商品信息。同时与商品相关的商品类型等信息也需要管理员维护。
(2)会员管理:由于有注册用户,所以管理员需要对拥护账号进行管理,如删除一些无效账号等。
(3)订单处理:在用户下达订单后,管理员需要对用户订单进行处理,为用户准备订购的商品,并组织送货、收取货等。
(4)购物帮助管理:管理员要根据用户反映的情况及时修改购物帮助的内容,使用户得到即时的帮助。
123采购、仓存管理员需求
网上超市的系统中将采购员和仓存管理员统一为采购、仓存管理员,其主要需求如下:
(1)录入商品信息:商品是网上超市的内容所在,当有新进的货物时,采购管理员需要维护超市中的商品信息。
(2)维护供应商信息:采购管理员在进行采购工作时,就需要对供应商信息的查询。
(3)维护仓库信息:有多上仓库,什么商品存放在哪个仓库,这些都需要采购仓存管理员来维护。
124系统管理员需求
网上超市的系统管理员功能是维护系统的正常工作,它需要提供如下功能:
(1)对系统中用户的管理:系统中顾客,销售管理员,采购、仓存管理员都是系统的用户,这些用户就需要系统管理员进行统一管理。
(2)会员管理:由于有注册用户,所以管理员需要对拥护账号进行管理,如删除一些无效账号等。但这样的一个功能可以授权于销售管理员去处理。
125数据库需求分析
用户的需求具体体现在各种信息的提供、保存、更新和查询。这就要求数据库结构能够充分地满足各种信息的输入和输出。收集基本数据、数据结构和数据处理流程,为下一步的具体设计做好充分的准备。
网上超市管理系统要处理的数据流程图:
2 面向对象分析和设计
21 用例分析
22 类和对象设计
3 逻辑结构设计
31 类和对象向关系模式转换
顾客信息(姓名、顾客编号、性别、出生年月、家庭地址、邮政编码、是否居住本地区、联系电话、身份z号、备注信息)
供应商信息(供应商编号、公司名称、联系人姓名、联系地址、所在城市、邮政编码、电话号码、传真号码、备注信息)
购物车(商品编号、顾客编号、商品名称、商品规格、时间、备注信息)
商品信息(商品编号、商品名称、单价、商品规格、商品产地、保质期、类别、备注信息)
订单信息(订单编号、商品编号、顾客编号、商品名称、商品规格、数量、顾客姓名、时间、备注信息)
员工信息(姓名、职工号、部门编号、性别、出生年月、家庭地址、邮政编码、联系电话、身份z号、备注信息)
进货信息(进货信息编号、供应商编号、公司名称、联系人姓名、商品编号、商品名称、商品规格、商品产地、商品数量、商品单价、进货日期、备注信息)
部门信息(部门编号、部门名称、负责人姓名)
销售信息(销售信息编号、顾客编号、顾客姓名、商品编号、商品名称、商品规格、商品产地、商品数量、商品单价、销售日期、折扣、备注信息)
仓库信息(仓库编号、仓库名称、存放商品类别、容量、负责人编号,负责人姓名)
留言信息(留言编号、留言标题、留言内容、留言日期、顾客编号、回复人编号、回复日期)
积分信息(积分编号、顾客编号、顾客姓名、积分)
商品入库(仓库编号、仓库名称、商品编号、商品名称、库存量、入库时间)
32 关系模式优化
顾客信息(姓名、顾客编号、性别、出生年月、家庭地址、邮政编码、是否居住本地区、联系电话、身份z号、备注信息)
供应商信息(供应商编号、公司名称、联系人姓名、联系地址、所在城市、邮政编码、电话号码、传真号码、备注信息)
购物车(商品编号、顾客编号、时间、备注信息)
商品信息(商品编号、商品名称、单价、商品规格、商品产地、保质期、类别、备注信息)
订单信息(订单编号、商品编号、顾客编号、数量、时间、备注信息)
员工信息(姓名、职工号、部门编号、性别、出生年月、家庭地址、邮政编码、联系电话、身份z号、备注信息)
进货信息(进货信息编号、供应商编号、商品编号、商品名称、商品规格、商品数量、商品单价、进货日期、备注信息)
部门信息(部门编号、部门名称、负责人姓名)
销售信息(销售信息编号、顾客编号、商品编号、商品数量、商品单价、销售日期、折扣、备注信息)
仓库信息(仓库编号、仓库名称、存放商品类别、容量、负责人编号)
留言信息(留言编号、留言标题、留言内容、留言日期、顾客编号、回复人编号、回复日期)
积分信息(积分编号、顾客编号、积分)
商品库存(仓库编号、商品编号、库存量、入库时间)
4 数据库物理结构设计
41 存取方法设计
42 存储结构设计
为了提高查询时间和空间的利用率,对网上超市管理系统的数据库作如下设计:
首先将网上超市管理系统日志文件存放在磁带上,因为数据库的数据备份和日志文件等只在故障恢复的时候才要使用,而且数据量很大。第二,把所有的基本表(如:顾客信息表)存放在一块磁盘上,而所有的索引则存放在另一块磁盘上。这样分开存放的目的在于查询时多个磁盘驱动器并行工作,提高了物理I/O读写效率,也加快了存取速度。
5 数据库完整性设计
51 主键及唯一性索引
52 参照完整性设计
1、由于员工信息表中的部门编号必须在部门信息中存在,而部门编号又是部门信息表中的主键,所以员工信息表中将属性部门编号设计为外键。
2、订单信息表中属性商品编号对应于商品信息表中的商品编号,因此将其设计为外键。
订单信息表中字段顾客编号对应于顾客信息表中的顾客编号,而顾客编号又是顾客信息的主键,所以将顾客编号作为订单信息表的外键。
3、进货信息表中属性商品编号对应于商品信息表中的商品编号,因此将其设计为外键。
进货信息表中字段供应商编号对应于供应商信息表中的供应商编号,而供应商编号又是供应商信息表的主键,所以将供应商编号作为进货信息表的外键。
4、销售信息表中字段顾客编号对应于顾客信息表中的顾客编号,而顾客编号又是顾客信息表的主键,所以将顾客编号作为销售信息表的外键。此外,销售信息表中的商品编号必须在商品信息表中存在,所以将商品编号也设计为改表的外键。
5、留言信息表中顾客编号需要在顾客信息表中存在记录,把顾客编号作为该表的外键。留言信息表中的属性回复人编号必须是员工信息表在存在的记录,所以把回复人编号也设为留言信息表的外键。
6、积分表中的属性顾客编号对应于顾客信息表中的顾客编号,而顾客编号是主键,所以将其设计为积分表的外键。
53 Check约束
1、对积分表中的积分字段设计check约束:积分必须是大于或者等于0的。
2、订单信息表、进货信息表和销售信息表对数量、商品数量设计check约束:即这些属性值必须取大于或者等于0的值。
54 Default约束
1、积分表中的积分字段设计default约束:积分默认值为0。
2、订单信息表中属性值数量默认为1单位。
55 触发器设计
1、 当采购完成后,即在进货信息表中添加信息时,建立该表上的插入触发器。该触发器的功能是当进货信息表中插入信息时,将进货的商品信息自动添加到商品信息表中以及在商品库存表在自动增加库存量。在这些动作完成之后,将进货信息表中添加的该信息删除。
2、 在订单信息表上建立插入触发器。如果订单中要添加的商品信息在商品信息表中不存在,则不予以添加。当订单信息成功提交,即订单信息表在成功插入新记录时,首先根据该顾客的积分情况自动生成折扣,然后自动将订单信息表中的记录添加到销售信息表中,并且将积分信息表中的记录更新或添加。在这些动作完成之后,再将订单信息表在的该记录删除。
3、 在商品库存量不足的时候需要系统提示工作人员及时的进行采购,所以在商品库存表上建立一个触发器就可以完成以上功能。当商品库存量到达一定的底线时,自动给采购、库存管理员留言,即在留言信息表中添加信息。这样可以对商品库存情况动态掌握。
6 数据库视图设计
1、为了方便查看部门信息,建立部门信息视图。显示部门信息表中的全部内容。
2、商品查询在网上超市管理系统中查看的非常频繁,需要建立商品信息视图。显示商品信息表中的全部信息。
3、建立顾客信息视图,显示顾客信息表中的全部内容。
4、在采购的时候,采购人员需要对供应商的信息进行查询,因此需要建供应商信息视图,显示该表中的全部内容。
5、当顾客在网上逛过超市后会将自己喜欢的商品先放入购物车中备选,这时就需要对购物车进行查询。所以有必要建立购物车信息视图。除了显示购物车表中的全部信息外,还需要连接查询并显示商品信息表中的商品名称和商品规格以及其他的商品信息。
6、顾客确定要购买商品的时候,需要提交订单信息,而在提交之前必须对其进行查询,所以需要建立订单信息视图。显示订单信息,以及连接查询并显示商品信息表中的商品名称和商品规格以及其他的商品信息。
7、对于网上超市的各部门的负责人来说,经常需要对员工的信息查看,故建立员工信息视图。除显示员工信息表中全部信息外,还要通过连接查询并显示部门名称。
8、采购人员在采购前后都需要对进货信息进行查询,这就需要建立进货信息视图。除显示进货信息表中全部信息外,还要通过连接查询并显示供应商的公司名称、联系人姓名、联系电话和商品名称、商品规格、商品产地、数量及单价。
9、每隔一段时间,都要查看一下收益如何,即查询销售情况。因此需要建立一个销售信息视图。显示销售信息表中的全部信息和通过连接查询并显示商品名称、商品规格、商品产地、数量及单价。除此之外,还要计算并显示销售总额。
10、建立仓库信息视图,显示仓库信息表中的所有信息即可。
11、建立留言信息视图。显示留言信息表中的全部信息以及通过连接查询并显示顾客姓名和回复人的姓名。
12、对积分的查询也是顾客经常查询的项目。所以非常有必要建立积分信息视图。显示积分信息表在的所有信息和连接查询并显示顾客姓名。
13、不管是在销售还是在采购的时候,都要对商品的库存量进行查询。因此要建立商品库存信息视图。显示库存信息以及通过连接查询并显示仓库名称和商品名称、商品规格等其他商品信息。
7 数据库存储过程设计
1、 顾客是网上超市管理系统的最主要的用户,也需要经常的添加和删除,故建立顾客删除存储过程。在删除某个顾客信息的时候,如果他的购物车中还有记录,则将其删除;若他提交了订单信息,也要把订单信息中的记录删除;最后还要把留言信息表和积分表中与该顾客相关的信息一并删除。
2、 建立删除员工的存储过程。如果该员工是某个部门的负责人,则一般情况下不予以删除,如果要删除,则必须对部门信息表中的负责人进行更新。若该员工是留言信息表中的回复人,则要对留言信息表在回复人编号进行修改或者删除。
3、 建立删除商品的存储过程。如果某个商品已经过了保质期或者已经被淘汰了,则要对这样的商品进行删除。首先要在商品信息表中把这些商品删除,在商品库存表将其删除,其次若果有顾客将该商品选入了购物车,甚至提交了订单,则要对顾客予以说明并将其从购物车表和订单信息表中删除。
8 权限设计
9 总结
理论联系实际才能做好一件事,学习一门课程同样是这样。通过一周的数据库课程设计实习,我受益匪浅,从中学到了许多新知识,这些知识是在课堂中不能学到或者说很难学到的。并且对数据库应用这一门课程有了更深一步的理解。在做课程设计中,我们可以把课堂上所学的理论知识和实践联系起来,在所要开发的系统中渐渐学会了融会贯通。同样通过对SQL的应用,也使我们熟练和巩固了对SQL的理解。这样我们对开发系统的整个过程也有了一个系统的了解。
这次课程设计,我选择的课题是《教务管理系统》,在教务管理系统的开发中采用了完整的数据库设计的全过程,从需求分析到概念结构设计,到逻辑结构设计,再到物理结构设计,最后到数据库的实施和维护,每一步都认真的分析和实施。当然,在本次课程设计的成果中还存在许多的不足之处,这就需要我们学习更多的知识,进行更深研究。
在这次实习中,我们完全投入到了开发系统的世界里。结束后明白了理论和实践要想充分地结合,需要非常扎实的基本功。这就说明学好基础知识是理论付诸实践的前提。在开发教务管理系统中我学到了很多,希望在以后能充分利用实习的机会充实自己,用所学的理论知识充分去实践,在实践中又要努力去巩固理论知识。只有这样,才能把一门课程甚至一门学科学精、学透
参考资料:
1 萨师煊,王珊数据库系统概论高等教育出版社第三版2000
2 龚波等译 SQL SERVER 2000教程北京希望电子出版社
3 史嘉权,史红星,李博等数据库系统概论习题、实验与考试辅导清华大学出版社2006
4 赵乃真等信息系统设计与应用清华大学出版社2005
注:由于这里不好排版,文章中的表格和没有显示出来,我打包成附件了,可以下载查看。
第13章 数据库应用系统设计概述
131 数据库设计概述
1311 数据库系统设计内容
数据库设计包含两方面的内容。
1 结构特性设计
结构特性设计通常是指数据库模式或数据库结构设计,它应该具有最小冗余的、能满足不同用户数据需求的、能实现数据共享的系统。数据库结构特性是静态的,应留有扩充余地,使系统容易改变。
2 行为特性设计
行为特性设计是指应用程序、事物处理的设计。
1312 数据库设计特点
数据库设计是一项综合性技术。“三分技术,七分管理,十二分基础数据”是数据库建设的基本规律。数据库设计的特点是:
硬件、软件和管理界面相结合。
结构设计和行为设计相结合。
132 数据库设计步骤
见图。
133 数据库结构设计
1331 需求分析
需求分析的目标是准确了解系统的应用环境,了解并分析用户对数据及数据处理的需求。
1 收集需求信息
一般来讲,用户对数据库的要求如下:
(1)信息需求
(2)处理需求
(3)安全性与完整性要求
2 分析整理
分析的过程是对所收集到的数据进行抽象的过程。下面是“高校收费管理系统”的用户需求分析:
每年新生入学时学费基本信息的输入
每年老生离校时学生基本信息的删除
查询、打印学生的交费情况
查询、打印降级生的交费情况
进入学费管理系统的安全性条件设计
3 数据流图
数据库设计中采用数据流图(DFD:Data Flow Diagram)来描述系统的功能。DFD一般由下面图素构成。
:数据及其流动方向,直线上方标明数据流名称
:数据处理,圆圈内标明处理名称
:数据流的终点和源点,方框内标明相应的名称
:文件和数据存储,在其内标明相应名称
例如:高校收费管理系统
4.数据字典
数据字典(DD:Data Dictionary)用于记载系统中的各种数据、数据元素以及它们的名字、性质、意义及各类约束条件,记录系统中用到的常量、变量、数组及其他数据单位,是系统开发与维护中不可缺少的重要文件。数据字典是关于数据库中数据的一种描述,而不是数据本身。数据字典是在需求分析阶段建立,在数据库设计过程中不断修改、充实、完善的。
数据字典产生于数据流图,是对数据流图中的四个成分(数据流、数据项、文件和处理)描述的结果。其中:
数据流描述:定义数据流的组成,一般包含若干数据项,通常在数据流图的下方通过“说明”定义。
文件描述:定义文件的组成以及文件的组织方式,如学生交费数据可用下面方法描述:
交费数据=学号+姓名+收费标准+应交学费+待交学费+本次交款
数据项描述:定义数据项,一般包括名称、类型长度、允许范围等。如学生交费数据文件中的数据项。
数据项名称 类型 长度(字节) 范围
学号 字符 8 H、G和数字
姓名 字符 8 任何字母
收费标准 正整数 5 0-99999
应交学费 正整数 5 0-99999
待交学费 正整数 5 0-99999
本次交款 正整数 5 0-99999
数据处理的描述:说明数据处理的逻辑关系,即输入与输出之间的逻辑关系。同时,也要说明数据处理的触发条件、错误处理等问题。
1332 概念结构设计
概念结构的目标是将需求分析得到的用户需求抽象为数据库的概念结构,即概念模式。概念结构设计形成一个独立于具体DBMS的概念模型。描述概念模式的是E―R图。
1 局部E-R模型设计
局部E―R模型设计是从数据流图出发确定实体和属性,并根据数据流图中表示的对数据的处理、确定实体之间的联系。
2 总体E-R模型设计
将各个局部E―R图加以综合,使同一个实体只出现一次,便可产生总体E―R图。
1333 逻辑结构设计
数据库的逻辑结构设计的目标就是将概念结构转换成特定的DBMS所支持的数据模型,并对其优化的过程。逻辑设计阶段一般分三个过程进行:
将概念结构转换为一般的关系、网状、层次模型;
将由概念结构转换来的模型向所选用DBMS支持的数据模型转换;
对数据模型进行优化
1334 物理设计
数据库的物理设计目标是在选定的DBMS上建立起逻辑设计结构确立的数据库的结构。这项工作一般由系统程序员完成。数据库的物理设计通常分为两步进行。
1 确定数据库的物理结构
在关系数据库中,确定数据库的物理结构主要指确定数据存放位置和存储结构,包括确定关系、索引、日志、备份等数据的存储分配合存储结构,确定系统配置等工作。
2 对所确定的物理结构进行评价
134 应用程序设计
数据库的应用程序设计和一般的应用程序设计方法基本相同。
应用程序的设计方法可以采用一般的程序设计方法。
135 运行和维护
1351 数据载入数据库
1352 数据库系统试运行
在试运行阶段应当注意:
1 数据的加载过程应先输入小部分数据进行试运行
2 应注意数据库的转储和恢复工作
1353 数据库系统的运行和维护
在数据库系统正式运行阶段,对数据库的经常性维护工作是由DBA来实施的,他的工作主要包括:
1 数据库的转储和恢复
2 数据库的安全性和完整性控制
3 数据库性能的监督、分析和改造
4 数据库的重组与重构
(1)数据库的重组
(2)数据库的重构
136 小结
本章通过高校收费管理系统数据库的构建与设计过程的详细描述,学习了数据库设计的基本方法,数据库设计的基本流程,E-R图的建立和到关系模式的转换,学习了软件工程的基本思想,为后续课程数据库开发技术打好基础。
以上就是关于请问数据库在创建表的时候如何设计表关系,一对一,一对多,多对多 请高手举例说明。谢谢!!!全部的内容,包括:请问数据库在创建表的时候如何设计表关系,一对一,一对多,多对多 请高手举例说明。谢谢!!!、大型数据库的设计原则与开发技巧、什么是数据库的概念设计、逻辑设计、物理设计,以及三者的关系等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)