网站首页 爱站云资源网 值得一看 正文
某种“数据库技术”课程的作业吧
把表的结构提供给你,其它的最好看看书自己做吧
车主(车主ID,...)
汽车(汽车ID,...,所属车主ID)
事故(事故ID,...,所属汽车ID)
所有的主ID应该有索引,车主姓名和车牌号也可以有索引
视图:车主与汽车的连立,车主、汽车与事故的连立
E-R图就是三大区域,中间有两个1:n连接
这是3NF范式(主外码连接无冗余)
access数据库设计实例
1,范式
7大范式:1NF,2NF,3NF,BCNF,4NF,5NF,6NF
什么叫normalization?Denormalization?
Normalization是数据库规范化,denormalization是数据库逆规范化。
在设计和操作维护数据库时,关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构,不仅便于对数据库进行相应的存取操作,而且可以极大地简化应用程序的其他内容(查询、窗体、报表、代码等)。正确进行表设计的正式名称就是"数据库规范化"。目的:减少数据库中数据冗余,增进数据的一致性。
范式概念:
1)1NF:目标就是表中每列都不可分割;
2)2NF:目标就是表中的每行都是有标识的。前提是满足了1NF.当关键字为单field时,一定满足2NF。当关键字为组合field时(即超过一个field),不能存在组合关键字中有某个字段能够决定非关键字段的某部分。非主field非部分依赖于主field,即非关键字段必须完全依赖于一组组合关键字,而不是组合关键字的某一部分。
3)3NF:目标是一个table里面所有的列不依赖于另外一个table里面非关键的列。前提是满足了2NF,不存在某个非关键字段决定另外一个非关键字段。即:不存在传递依赖(关键字x->非关键属性y->非关键属性z)
4)BCNF:前提是满足了2NF,不存在某个非关键字段决定另外一个非关键字段。也不存在某个关键字段决定另外一个关键字段。即:在3NF基础上,加上约束:不存在某个关键字段决定另外一个关键字段。
1第一范式(1NF)
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于图3-2中的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而言之,第一范式就是无重复的列。
2第二范式(2NF)
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。如图3-2员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是非主属性非部分依赖于主关键字。
3第三范式(3NF)
满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。
例子:
第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。
例如,如下的数据库表是符合第一范式的:字段1字段2字段3字段4
而这样的数据库表是不符合第一范式的:字段1字段2字段3字段4字段31字段32
很显然,在当前的任何关系数据库管理系统(S)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些S不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的S中设计出不符合第一范式的数据库都是不可能的。
第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为Ss(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:
(学号,课程名称)→(姓名,年龄,成绩,学分)
这个数据库表不满足第二范式,因为存在如下决定关系:
(课程名称)→(学分)
(学号)→(姓名,年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF,这个选课关系表会存在如下问题:1)数据冗余:同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了门课程,姓名和年龄就重复了-1次。2)更新异常:若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。3)插入异常:假设要开设一门新的课程,暂时还没有人选修。由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。4)删除异常:假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
把选课关系表Ss改为如下三个表:
学生:Sn(学号,姓名,年龄);
课程:s(课程名称,学分);
选课关系:Ss(学号,课程名称,成绩)。
这样的数据库表是符合第二范式的,消除了数据冗余、更新异常、插入异常和删除异常。
另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。
第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A→→"的决定关系,则传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:关键字段→非关键字段x→非关键字段y
假定学生关系表为Sn(学号,姓名,年龄,所在[]学院[],学院地点,学院电话),关键字为单一关键字"学号",因为存在如下决定关系:
(学号)→(姓名,年龄,所在[]学院[],学院[]地点,[]学院[]电话)
这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
(学号)→(所在[]学院[])→([]学院[]地点,[]学院[]电话)
即存在非关键字段"[]学院[]地点"、"[]学院[]电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。
把学生关系表分为如下两个表:
学生:(学号,姓名,年龄,所在[]学院[]);
[]学院[]:([]学院[],地点,电话)。
这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BCNF.
假设仓库管理关系表为Ssanag(仓库,存储物品,管理员,数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
(仓库,存储物品)→(管理员,数量)
(管理员,存储物品)→(仓库,数量)
所以,(仓库,存储物品)和(管理员,存储物品)都是Ssanag的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
(仓库)→(管理员)
(管理员)→(仓库)
即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:1)删除异常:当仓库被清空后,所有"存储物品"和"数量"信息被删除的同时,"仓库"和"管理员"信息也被删除了。2)插入异常:当仓库没有存储任何物品时,无法给仓库分配管理员。3)更新异常:如果仓库换了管理员,则表中所有行的管理员都要修改。
把仓库管理关系表分解为二个关系表:
仓库管理:Ssanag(仓库,管理员);
仓库:Ss(仓库,存储物品,数量)。
这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。
简言之数据库五大范式:
第一范式:对于表中的每一行,必须且仅仅有唯一的行值.在一行中的每一列仅有唯一的值并且具有原子性.
(第一范式是通过把重复的组放到每个独立的表中,把这些表通过一对多关联联系起来这种方式来消除重复组的)
第二范式:第二范式要求非主键列是主键的子集,非主键列活动必须完全依赖整个主键。主键必须有唯一性的元素,一个主键可以由一个或更多的组成唯一值的列组成。一旦创建,主键无法改变,外键关联一个表的主键。主外键关联意味着一对多的关系.(第二范式处理冗余数据的删除问题。当某张表中的信息依赖于该表中其它的不是主键部分的列的时候,通常会违反第二范式)
第三范式:第三范式要求非主键列互不依赖.(第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键)
第四范式:第四范式禁止主键列和非主键列一对多关系不受约束
第五范式:第五范式将表分割成尽可能小的块,为了排除在表中所有的冗余。
空间数据库设计实例
'使用方法,在打开窗体时用opendb即可,关闭用closedb,数据库文件你修改dbname变量'表操作打开openrs1,"select*from..."关闭closers1我写了四个表操作变量,1234,你自己看着理解,你要会SQl语句,要不这也没有什么用。'数据库连接:放在一个模块里里面
PublicConstDBName="FoxData.mdb"
PublicConstDBpass=""
PublicconnAsNewADODB.Connection
PublicRs1AsNewADODB.Recordset
PublicRs2AsNewADODB.Recordset
PublicRs3AsNewADODB.Recordset
PublicRs4AsNewADODB.RecordsetPublicSubOpenDB()
DimDBpathAsString
DBpath=App.Path+"\"+DBName
conn.Open"provider=Microsoft.Jet.oledb.4.0;datasource="&DBpath&";JetOLEDB:DatabasePassword="&DBpass&";"
EndSub
'******************************************
'关闭数据库
PublicSubCloseDB()
OnErrorResumeNext
conn.Close
Setconn=Nothing
EndSubPublicSubOpenRs(ByValRsNumAsInteger,ByValRsSqlAsString)
SelectCaseRsNum
Case1:Rs1.OpenRsSql,conn,adOpenKeyset,adLockPessimistic
Case2:Rs2.OpenRsSql,conn,adOpenKeyset,adLockPessimistic
Case3:Rs3.OpenRsSql,conn,adOpenKeyset,adLockPessimistic
Case4:Rs4.OpenRsSql,conn,adOpenKeyset,adLockPessimistic
EndSelectEndSub
PublicSubCloseRs(ByValRsNumAsInteger)
SelectCaseRsNum
Case1:Rs1.Close:SetRs1=Nothing
Case2:Rs2.Close:SetRs2=Nothing
Case3:Rs3.Close:SetRs3=Nothing
Case4:Rs4.Close:SetRs4=Nothing
EndSelect
EndSub
数据库设计实例教程
数据库课程设计
题目:小型超市管理系统
1、项目计划
1.1系统开发目的
(1)大大提高超市的运作效率;
(3)使用本系统,可以迅速提升超市的管理水平,为降低经营成本,提高效益,增强超市扩张力,提供有效的技术保障。
1.2背景说明
21世纪,超市的竞争也进入到了一个全新的领域,竞争已不再是规模的竞争,而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势,多种业态:超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模,成为超市营业者努力追求的目标。
1.3项目确立
针对超市的特点,为了帮助超市解决现在面临的问题,提高小型超市的竞争力,我们将开发以下系统:前台POS销售系统、后台管理系统,其中这两个子系统又包含其它一些子功能。
1.4应用范围
本系统适应于各种小型的超市。
1.5定义
(1)商品条形码:每种商品具有唯一的条形码,对于某些价格一样的商品,可以使用自定义条形码。
(2)交易清单:包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。
(3)商品积压:在一定时期内,远无法完成销售计划的商品会造成积压。
(4)促销:在一定时期内,某些商品会按低于原价的促销价格销售。
库存告警提示:当商品的库存数量低于库存报警数量时发出提示。
(5)盘点:计算出库存、销售额、盈利等经营指标。
1.6参考资料
《数据库原理及设计》陶宏才编清华大学出版社
《SQLServer2000实用教程》范立南编清华大学出版社
《SQLServer2000编程员指南》李香敏编北京希望电子出版社
《轻松搞定SQLServer2000程序设计》RebeccaM.Riordan编
《软件工程规范》WattsS.Humphrey编清华大学出版社
《软件工程理论与实践》ShariLawrencePfleeger编清华大学出版社
《软件需求分析》SwapnAKishore编机械工业出版社
《软件工程思想》林锐编
2、逻辑分析与详细分析
2.1系统功能
(1)、零售前台(POS)管理系统,本系统必须具有以下功能:
商品录入:根据超巿业务特点制定相关功能,可以通过输入唯一编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。该扫描录入方法可以充分保证各种电脑操作水平层次的人员均能准确快速地进行商品扫描录入。
收银业务:通过扫描条形码或者直接输入商品名称(对于同类多件商品采用一次录入加数量的方式)自动计算本次交易的总金额。在顾客付款后,自动计算找零,同时打印交易清单(包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号)。如果顾客是本店会员并持有本人会员卡,则在交易前先扫描会员卡,并对所购物品全部实行95折优惠,并将所购物品的总金额累计到该会员的总消费金额中。会员卡的有效期限为一年,满一年未续卡者,该会员卡将被注销。
安全性:OS登陆、退出、换班与操作锁定等权限验证保护;断电自动保护最大限度防止意外及恶意非法操作。
独立作业:有的断网收银即在网络服务器断开或网络不通的情况下,收银机仍能正常作业
(2)、后台管理系统,本系统必须具备以下功能
进货管理:根据销售情况及库存情况,自动制定进货计划(亦可手工制定修改),可以避免盲目进货造成商品积压。按计划单有选择性地进行自动入库登记。综合查询打印计划进货与入库记录及金额。
销售管理:商品正常销售、促销与限量、限期及禁止销售控制。综合查询各种销售明细记录、各地收银员收银记录以及交结账情况等。按多种方式统计生成销售排行榜,灵活察看和打印商品销售日、月、年报表。
库存管理:综合查询库存明细记录。库存状态自动告警提示。如库存过剩、少货、缺货等。软件为您预警,避免库存商品积压损失和缺货。库存自动盘点计算。
人员管理:员工、会员、供货商、厂商等基本信息登记管理。员工操作权限管理。客户销售权限管理。
(3)系统结构
系统总体结构
模块子系统结构
功能描述:商品录入子系统要求能快速录入商品,因此必须支持条形码扫描。
功能描述:收银业务子系统能计算交易总额,打印交易清单,并根据会员卡打折。
功能描述:进货管理子系统可以根据库存自动指定进货计划,进货时自动等级,以及提供查询和打印计划进货与入库记录的功能。
功能描述:销售管理子系统可以控制某商品是否允许销售,查询每种商品的销售情况并产生年、月、日报表,同时可以生成销售排行榜。
功能描述:库存管理子系统提供查询库存明细记录的基本功能,并根据库存的状态报警,以及自动盘点计算。
功能描述:人员管理子系统提供基本信息登记管理,员工操作权限管理,客户销售权限管理的功能。
2.2、流程图
前台管理系统
顶层DFD图
第0层DFD图
第1层DFD图
2.3、户类型与职能
(1)、员工(营业员):
通过商品条形码扫描输入商品到购买清单
操作软件计算交易总金额
操作软件输出交易清单
对会员进行会员卡扫描以便打折
(2)、:超市经理
操作软件录入商品,供货商,厂商
操作软件制定进货计划
查询打印计划进货与入库记录
操作软件控制商品销售与否
查询打印销售情况
操作软件生成销售排行榜
查询库存明细记录
根据软件发出的库存告警进行入货
操作软件进行盘点计算
(3)、总经理:
基本信息登记管理
员工操作权限管理
客户销售权限管理
2.4、统开发步骤
确定参与者和相关的用况
为每个用况设计过程
建立顺序图,确定每个脚本中对象的协作
创建类,确定脚本中的对象
设计,编码,测试,集成类
为过程编写系统测试案例
运行测试案例,检验系统
2.5、系统环境需求
系统模式
本系统采用C/S模式作为开发模式
硬件环境
服务器端:
高性能的计算机一台,
普通的双绞线作为连接。
客户端:普通的计算机或者工作站,
普通的双绞线作为连接。
软件环境
服务器端:安装SQLServer2000的服务器版本,
安装windows2000服务器版本,
配置了诺顿等必须的防毒软件。
客户端:安装SQLServer2000的服务器版本,
安装了VB等可视化开发工具软件,
安装windows2000服务器版本。
2.6、系统安全问题
信息系统尽管功能强大,技术先进,但由于受到自身体系结构,设计思路以及运行机制等限制,也隐含许多不安全因素。常见因素有:数据的输入,输出,存取与备份,源程序以及应用软件,数据库,操作系统等漏洞或缺陷,硬件,通信部分的漏洞,企业内部人员的因素,病毒,“黑客”等因素。因此,为使本系统能够真正安全,可靠,稳定地工作,必须考虑如下问题:为保证安全,不致使系统遭到意外事故的损害,系统因该能防止火,盗或其他形式的人为破坏。
系统要能重建
系统应该是可审查的
系统应能进行有效控制,抗干扰能力强
系统使用者的使用权限是可识别的
3、基于UML的建模
3.1语义规则
用例模型(usecasesview)(用例视图)的基本组成部件是用例(usecase)、角色(actor)和系统(system)。用例用于描述系统的功能,也就是从外部用户的角度观察,系统应支持哪些功能,帮助分析人员理解系统的行为,它是对系统功能的宏观描述,一个完整的系统中通常包含若干个用例,每个用例具体说明应完成的功能,代表系统的所有基本功能(集)。角色是与系统进行交互的外部实体,它可以是系统用户,也可以是其它系统或硬件设备,总之,凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域(即用例的活动区域)则抽象表示系统能够实现的所有基本功能。在一个基本功能(集)已经实现的系统中,系统运转的大致过程是:外部角色先初始化用例,然后用例执行其所代表的功能,执行完后用例便给角色返回一些值,这个值可以是角色需要的来自系统中的任何东西。
UML:是一种标准的图形化建模语言,它是面向对象分析与设计的一种标准表示;它不是一种可视化的程序设计语言而是一种可视化的建模语言;不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准;不是过程也不是方法但允许任何一种过程和方法使用它。
用例(usecase):
参与者(actor):
3.2、UML模型
3.21、系统UML模型
3.22、子系统UML模型
(1)零售前台(POS)管理系统用例视图
(2)后台管理系统用例视图
3.3、系统实现图
4、超市销售系统概念设计文档
(1)、系统ER图
(2)、系统ER图说明
1)商店中的所有用户(员工)可以销售多种商品,每种商品可由不同用户(员工)销售;
2)每个顾客可以购买多种商品,不同商品可由不同顾客购买;
3)每个供货商可以供应多种不同商品,每种商品可由多个供应商供应。
(3)、视图设计
1)交易视图(v_Dealing)——用于查询交易情况的视图;
2)计划进货视图(v_PlanStock)——用于查询进货计划的视图;
3)销售视图(v_Sale)——用于查询销售明细记录的视图;
4)入库视图(v_Stock)——用于查询入库情况的视图。
5、逻辑设计文档
(1)、系统关系模型
a)商品信息表(商品编号,商品名称,价格,条形码,促销价格,促销起日期,促销止日期,允许打折,库存数量,库存报警数量,计划进货数,允许销售,厂商编号,供货商编号)
b)用户表(用户编号,用户名称,用户密码,用户类型)
c)会员表(会员编号,会员卡号,累积消费金额,注册日期)
d)销售表(销售编号,商品编号,销售数量,销售金额,销售日期)
e)交易表(交易编号,用户名称,交易金额,会员卡号,交易日期)
f)进货入库表(入库编号,入库商品编号,入库数量,单额,总额,入库日期,计划进货日期,入库状态)
g)供货商表(供货商编号,供货商名称,供货商地址,供货商电话)
h)厂商表(厂商编号,厂商名称,厂商地址,厂商电话)
(2)、系统数据库表结构
数据库表索引
表名中文名
MerchInfo商品信息表
User用户表
Menber会员表
Sale销售表
Dealing交易表
Stock进货入库表
Provide供货商表
Factory厂商表
商品信息表(MerchInfo)
字段名字段类型长度主/外键字段值约束对应中文名
MerchIDint4PNotnull商品编号
MerchNameVarchar50Notnull商品名称
MerchPriceMoney4Notnull价格
MerchNumInt4Notnull库存数量
CautionNumInt4Notnull库存报警数量
PlanNumInt4null计划进货数
BarCodeVarchar50Notnull条形码
SalesProPriceMoney4促销价格
SalesProDateSDatetime8促销起日期
SalesProDateEDatetime8促销止日期
AllowAbateInt4Notnull允许打折
AllowSaleInt4Notnull允许销售
FactoryIDVarchar10FNotnull厂商编号
ProvideIDVarchar10FNotnull供货商编号
用户表(User)
字段名字段类型长度主/外键字段值约束对应中文名
UserIDvarchar10PNotnull用户编号
UserNameVarchar25Notnull用户名称
UserPWVarchar50Notnull用户密码
UserStyleInt4Notnull用户类型
会员表(Menber)
字段名字段类型长度主/外键字段值约束对应中文名
MemberIDVarchar10PNotnull会员编号
MemberCardVarchar20Notnull会员卡号
TotalCostMoney4Notnull累积消费金额
RegDateDatetime8Notnull注册日期
销售表(Sale)
字段名字段类型长度主/外键字段值约束对应中文名
SaleIDVarchar10PNotnull销售编号
MerChIDVarchar10FNotnull商品编号
SaleDateDatetime8Notnull销售日期
SaleNumInt4Notnull销售数量
SalePriceMoney4Notnull销售单额
交易表(Dealing)
字段名字段类型长度主/外键字段值约束对应中文名
DealingIDVarchar10PNotnull交易编号
DealingPriceMoney4Notnull交易金额
DealingDateMoney4Notnull交易日期
MemberIDVarchar10会员卡号
UserNameVarchar10FNotnull用户名称
入库纪录表(Stock)
字段名字段类型长度主/外键字段值约束对应中文名
StockIDVarchar10PNotnull入库编号
MerchIDVarchar10FNotnull入库商品编号
MerchNumInt4Notnull入库数量
MerchPriceMoney4Notnull单额
TotalPriceMoney4Notnull总额
StockDateDatetime8Datetime入库日期
PlanDateDatetime8Datetime计划进货日期
StockStateInt4Notnull入库状态
供货商表(Provide)
字段名字段类型长度主/外键字段值约束对应中文名
ProvideIDvarchar10PNotnull供货商编号
ProvideNameVarchar50Notnull供货商名称
ProvideAddressVarchar250供货商地址
ProvidePhoneVarchar25供货商电话
厂商表(Provide)
字段名字段类型长度主/外键字段值约束对应中文名
FactoryIDvarchar10PNotnull厂商编号
FactoryNameVarchar50Notnull厂商名称
FactoryAddressVarchar250厂商地址
FactoryPhoneVarchar25厂商电话
6、物理设计文档
/*----------创建数据库----------*/
createdatabaseSuperMarketdb
onprimary
(
name=SuperMarketdb,
filename='C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
logon
(
name=SuperMarketlog,
filename='C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go
/*----------创建基本表----------*/
use[SuperMarketdb]
go
/*创建交易表*/
CREATETABLEDealing(
DealingIDintidentity(1,1)Primarykey,
DealingDatedatetimeNOTNULL,
DealingPricemoneyNOTNULL,
UserNamevarchar(25)NULL,
MemberCardvarchar(20)NULL
)
GO
/*创建厂商表*/
CREATETABLEFactory(
FactoryIDvarchar(10)Primarykey,
FactoryNamevarchar(50)NOTNULL,
FactoryAddressvarchar(250)NULL,
FactoryPhonevarchar(50)NULL
)
GO
/*创建会员表*/
CREATETABLEMember(
MemberIDvarchar(10)Primarykey,
MemberCardvarchar(20)NOTNULL,
TotalCostmoneyNOTNULL,
RegDatedatetimeNOTNULL
)
GO
/*创建商品信息表*/
CREATETABLEMerchInfo(
MerchIDintidentity(1,1)Primarykey,
MerchNamevarchar(50)UniqueNOTNULL,
MerchPricemoneyNOTNULL,
MerchNumintNOTNULL,
CautionNumintNOTNULL,
PlanNumintNOTNULL,
BarCodevarchar(20)UniqueNOTNULL,
SalesProPricemoneyNULL,
SalesProDateSdatetimeNULL,
SalesProDateEdatetimeNULL,
AllowAbateintNOTNULL,
AllowSaleintNOTNULL,
FactoryIDintNOTNULL,
ProvideIDintNOTNULL
)
GO
/*创建供应商表*/
CREATETABLEProvide(
ProvideIDvarchar(10)Primarykey,
ProvideNamevarchar(50)NOTNULL,
ProvideAddressvarchar(250)NULL,
ProvidePhonevarchar(25)NULL
)
GO
/*创建销售表*/
CREATETABLESale(
SaleIDintidentity(1,1)Primarykey,
MerChIDintNOTNULL,
SaleDatedatetimeNOTNULL,
SaleNumintNOTNULL,
SalePricemoneyNOTNULL
)
GO
/*创建入库表*/
CREATETABLEStock(
StockIDintidentity(1,1)Primarykey,
MerchIDintNOTNULL,
MerchNumintNOTNULL,
MerchPricemoneyNULL,
TotalPricemoneyNULL,
PlanDatedatetimeNULL,
StockDatedatetimeNULL,
StockStateintNOTNULL
)
GO
/*创建用户表*/
CREATETABLEUser(
UserIDvarchar(10)Primarykey,
UserNamevarchar(25)NOTNULL,
UserPWvarchar(50)NOTNULL,
UserStyleintNOTNULL,
)
GO
/*----------创建表间约束----------*/
/*商品信息表中厂商编号、供应商编号分别与厂商表、供应商表之间的外键约束*/
ALTERTABLEMerchInfoADD
CONSTRAINT[FK_MerchInfo_Factory]FOREIGNKEY
(
[FactoryID]
)REFERENCESFactory(
[FactoryID]
),
CONSTRAINT[FK_MerchInfo_Provide]FOREIGNKEY
(
[ProvideID]
)REFERENCESProvide(
[ProvideID]
)
GO
/*销售表中商品编号与商品信息表之间的外键约束*/
ALTERTABLESaleADD
CONSTRAINT[FK_Sale_MerchInfo]FOREIGNKEY
(
[MerChID]
)REFERENCESMerchInfo(
[MerchID]
)ONDELETECASCADE
GO
/*入库表中商品编号与商品信息表之间的外键约束*/
ALTERTABLEStockADD
CONSTRAINT[FK_Stock_MerchInfo]FOREIGNKEY
(
[MerchID]
)REFERENCESMerchInfo(
[MerchID]
)ONDELETECASCADE
GO
/*----------创建索引----------*/
/*在交易表上建立一个以交易编号、交易日期为索引项的非聚集索引*/
CREATEnonclusteredINDEXIX_DealingONDealing(DealingID,DealingDate)
GO
/*在商品信息表上建立一个以商品编号为索引项的非聚集索引*/
CREATEnonclusteredINDEXIX_MerchInfoONMerchInfo(MerchID)
GO
/*在销售表上建立一个以销售编号、销售日期为索引项的非聚集索引*/
CREATEnonclusteredINDEXIX_SaleONSale(SaleID,SaleDate)
GO
/*在入库表上建立一个以入库编号、入库日期、商品编号为索引项的非聚集索引*/
CREATEnonclusteredINDEXIX_StockONStock(StockID,StockDate,MerchID)
GO
/*----------创建视图----------*/
/*创建用于查询交易情况的视图*/
CREATEVIEWv_Dealing
AS
SELECTDealingDateas交易日期,
UserNameas员工名称,
MemberCardas会员卡号,
DealingPriceas交易金额
FROMDealing
GO
/*创建用于查询进货计划的视图*/
CREATEVIEWv_PlanStock
AS
SELECTStock.StockIDasSID,
MerchInfo.MerchNameas商品名称,
MerchInfo.BarCodeas条形码,
Factory.FactoryNameas厂商,
Provide.ProvideNameas供货商,
Stock.MerchNumas计划进货数量,
Stock.PlanDateas计划进货日期
FROMStock,MerchInfo,Provide,Factory
WhereStock.MerchID=MerchInfo.MerchID
andProvide.ProvideID=MerchInfo.ProvideID
andFactory.FactoryID=MerchInfo.FactoryID
andStock.StockState=0
GO
/*创建用于查询销售明细记录的视图*/
CREATEVIEWv_Sale
AS
SELECTMerchInfo.MerchNameas商品名称,
MerchInfo.BarCodeas条形码,
MerchInfo.MerchPriceas商品价格,
Sale.SalePriceas销售价格,
Sale.SaleNumas销售数量,
Sale.SaleDateas销售日期
FROMSaleINNERJOIN
MerchInfoONSale.MerChID=MerchInfo.MerchID
GO
/*创建用于查询入库情况的视图*/
CREATEVIEWv_Stock
AS
SELECTMerchInfo.MerchNameas商品名称,
MerchInfo.BarCodeas条形码,
Factory.FactoryNameas厂商,
Provide.ProvideNameas供货商,
Stock.MerchPriceas入库价格,
Stock.MerchNumas入库数量,
Stock.TotalPriceas入库总额,
Stock.StockDateas入库日期
FROMStock,MerchInfo,Provide,Factory
WhereStock.MerchID=MerchInfo.MerchID
andProvide.ProvideID=MerchInfo.ProvideID
andFactory.FactoryID=MerchInfo.FactoryID
andStock.StockState=1
GO
7、小结
和传统管理模式相比较,使用本系统,毫无疑问会大大提高超市的运作效率,辅助提高超市的决策水平,管理水平,为降低经营成本,提高效益,减少差错,节省人力,减少顾客购物时间,增加客流量,提高顾客满意度,增强超市扩张能力,提供有效的技术保障。
由于开发者能力有限,加上时间仓促,本系统难免会出现一些不足之处,例如:
本系统只适合小型超市使用,不能适合中大型超市使用;
超市管理系统涉及范围宽,要解决的问题多,功能复杂,实现困难,但由于限于时间,本系统只能做出其中的一部分功能;
对于以上出现的问题,我们深表歉意,如发现还有其它问题,希望老师批评指正。
数据库设计实例-教务管理系统
先设计数据库,有一张是教师表,一张是学员表,学员表里面放一些资料就行,然后设计程序,主页面是个登录界面,登录的时候要判断登录成员是学生还是教师,学生的话跳出界面A,教师身份的话跳出界面B,其实A和B可以是同一个界面,A界面只允许浏览,所以A界面就可以用到ListView或DataGridView控件绑定数据,只不过将此控件的可写设置为False,如果是B界面,将False设置为True,然后添加几个按钮,分别实现,更新,删除,添加的功能即可,这应该算是最简单的学生管理系统了,当然,可以根据自己需求来不断完善其他功能.
- 上一篇:数据库的建立,数据库的建立过程是怎样的
- 下一篇:搜狐邮箱登陆,搜狐邮箱登陆登录入口
猜你喜欢
你 发表评论:
欢迎- 搜索
- 文章归档
-
- 2021年4月 (28)
- 2021年3月 (102)
- 2020年10月 (2)
- 2020年9月 (3)
- 2020年8月 (6)
- 2020年7月 (33)
- 2020年6月 (42)
- 2020年5月 (41)
- 2020年4月 (46)
- 2020年3月 (51)
- 2020年2月 (81)
- 2020年1月 (69)
- 2019年12月 (100)
- 2019年11月 (98)
- 2019年10月 (82)
- 2019年9月 (113)
- 2019年8月 (55)
- 2019年7月 (52)
- 2019年6月 (5)
- 2019年5月 (39)
- 2019年4月 (36)
- 2019年3月 (103)
- 2019年2月 (49)
- 2019年1月 (107)
- 2018年12月 (39)
- 2018年11月 (8)
- 2018年10月 (57)
- 2018年9月 (10)
- 2018年8月 (27)
- 2018年7月 (13)
- 2018年6月 (61)
- 2018年5月 (21)
- 2018年4月 (46)
- 2018年3月 (7)
- 2018年2月 (12)
- 2018年1月 (40)
- 2017年12月 (50)
- 2017年11月 (39)
- 2017年10月 (36)
- 2017年9月 (34)
- 2017年8月 (30)
- 2017年7月 (143)
- 2017年6月 (41)
- 标签列表
本文暂时没有评论哦(●'◡'●)