当前位置:首页 » 数据仓库 » 数据库表设计实例
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

数据库表设计实例

发布时间: 2022-08-15 18:14:38

A. 谁有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范式的,消除了删除异常、插入异常和更新异常。
简言之数据库五大范式:
第一范式:对于表中的每一行,必须且仅仅有唯一的行值.在一行中的每一列仅有唯一的值并且具有原子性.
(第一范式是通过把重复的组放到每个独立的表中,把这些表通过一对多关联联系起来这种方式来消除重复组的)
第二范式:第二范式要求非主键列是主键的子集,非主键列活动必须完全依赖整个主键。主键必须有唯一性的元素,一个主键可以由一个或更多的组成唯一值的列组成。一旦创建,主键无法改变,外键关联一个表的主键。主外键关联意味着一对多的关系.(第二范式处理冗余数据的删除问题。当某张表中的信息依赖于该表中其它的不是主键部分的列的时候,通常会违反第二范式)
第三范式:第三范式要求非主键列互不依赖.(第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键)
第四范式:第四范式禁止主键列和非主键列一对多关系不受约束
第五范式:第五范式将表分割成尽可能小的块,为了排除在表中所有的冗余。

B. 查阅资料,寻找数据库设计的实例(附实例材料),分析其数据库设计的过程,判断是

查阅资料,寻找数据库设计的实例(附实例材料),分析其数据库设计的过程,判断是?
突破抢了亲啦咯

C. 数据库课程设计实例

数据库课程设计

题目:小型超市管理系统
1、项目计划
1.1系统开发目的
(1)大大提高超市的运作效率;
(2)通过全面的信息采集和处理,辅助提高超市的决策水平;
(3)使用本系统,可以迅速提升超市的管理水平,为降低经营成本, 提高效益,增强超市扩张力, 提供有效的技术保障。
1.2背景说明
21世纪,超市的竞争也进入到了一个全新的领域,竞争已不再是规模的竞争,而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势,多种业态:超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模,成为超市营业者努力追求的目标。
1.3项目确立
针对超市的特点,为了帮助超市解决现在面临的问题,提高小型超市的竞争力,我们将开发以下系统:前台POS销售系统、后台管理系统,其中这两个子系统又包含其它一些子功能。
1.4应用范围
本系统适应于各种小型的超市。
1.5 定义
(1)商品条形码:每种商品具有唯一的条形码,对于某些价格一样的商品,可以使用自定义条形码。
(2)交易清单:包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。
(3)商品积压:在一定时期内,远无法完成销售计划的商品会造成积压。
(4)促销:在一定时期内,某些商品会按低于原价的促销价格销售。
库存告警提示:当商品的库存数量低于库存报警数量时发出提示。
(5)盘点:计算出库存、销售额、盈利等经营指标。
1.6 参考资料
《数据库原理及设计》 陶宏才编 清华大学出版社
sql Server 2000 实用教程》范立南编 清华大学出版社
《SQL Server 2000 编程员指南》李香敏编 北京希望电子出版社
《轻松搞定 SQL Server 2000 程序设计》Rebecca M.Riordan编
《软件工程规范》Watts S.Humphrey编 清华大学出版社
《软件工程理论与实践》 Shari Lawrence Pfleeger编 清华大学出版社
《软件需求分析》 Swapna Kishore编 机械工业出版社
《软件工程思想》 林锐编

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模式作为开发模式
 硬件环境
服务器端:
高性能的计算机一台,
普通的双绞线作为连接。
客户端: 普通的计算机或者工作站,
普通的双绞线作为连接。
 软件环境
服务器端:安装SQL Server 2000的服务器版本,
安装windows 2000服务器版本,
配置了诺顿等必须的防毒软件。
客户端: 安装SQL Server2000的服务器版本,
安装了VB等可视化开发工具软件,
安装windows2000服务器版本。

2.6、系统安全问题
信息系统尽管功能强大,技术先进,但由于受到自身体系结构,设计思路以及运行机制等限制,也隐含许多不安全因素。常见因素有:数据的输入,输出,存取与备份,源程序以及应用软件,数据库,操作系统等漏洞或缺陷,硬件,通信部分的漏洞,企业内部人员的因素,病毒,“黑客”等因素。因此,为使本系统能够真正安全,可靠,稳定地工作,必须考虑如下问题:为保证安全,不致使系统遭到意外事故的损害,系统因该能防止火,盗或其他形式的人为破坏。
 系统要能重建
 系统应该是可审查的
 系统应能进行有效控制,抗干扰能力强
 系统使用者的使用权限是可识别的
3、基于UML的建模
3.1语义规则
用例模型(use cases view)(用例视图)的基本组成部件是用例(use case)、角色(actor)和系统(system)。用例用于描述系统的功能,也就是从外部用户的角度观察,系统应支持哪些功能,帮助分析人员理解系统的行为,它是对系统功能的宏观描述,一个完整的系统中通常包含若干个用例,每个用例具体说明应完成的功能,代表系统的所有基本功能(集)。角色是与系统进行交互的外部实体,它可以是系统用户,也可以是其它系统或硬件设备,总之,凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域(即用例的活动区域)则抽象表示系统能够实现的所有基本功能。在一个基本功能(集)已经实现的系统中,系统运转的大致过程是:外部角色先初始化用例,然后用例执行其所代表的功能,执行完后用例便给角色返回一些值,这个值可以是角色需要的来自系统中的任何东西。
UML:是一种标准的图形化建模语言,它是面向对象分析与设计的一种标准表示;它不是一种可视化的程序设计语言而是一种可视化的建模语言;不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准;不是过程也不是方法但允许任何一种过程和方法使用它。

用例(use case):

参与者(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)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
MerchID int 4 P Not null 商品编号
MerchName Varchar 50 Not null 商品名称
MerchPrice Money 4 Not null 价格
MerchNum Int 4 Not null 库存数量
CautionNum Int 4 Not null 库存报警数量
PlanNum Int 4 null 计划进货数
BarCode Varchar 50 Not null 条形码
SalesProPrice Money 4 促销价格
SalesProDateS Datetime 8 促销起日期
SalesProDateE Datetime 8 促销止日期
AllowAbate Int 4 Not null 允许打折
AllowSale Int 4 Not null 允许销售
FactoryID Varchar 10 F Not null 厂商编号
ProvideID Varchar 10 F Not null 供货商编号

用户表(User)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
UserID varchar 10 P Not null 用户编号
UserName Varchar 25 Not null 用户名称
UserPW Varchar 50 Not null 用户密码
UserStyle Int 4 Not null 用户类型

会员表(Menber)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
MemberID Varchar 10 P Not null 会员编号
MemberCard Varchar 20 Not null 会员卡号
TotalCost Money 4 Not null 累积消费金额
RegDate Datetime 8 Not null 注册日期

销售表(Sale)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
SaleID Varchar 10 P Not null 销售编号
MerChID Varchar 10 F Not null 商品编号
SaleDate Datetime 8 Not null 销售日期
SaleNum Int 4 Not null 销售数量
SalePrice Money 4 Not null 销售单额

交易表(Dealing)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
DealingID Varchar 10 P Not null 交易编号
DealingPrice Money 4 Not null 交易金额
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 会员卡号
UserName Varchar 10 F Not null 用户名称

入库纪录表(Stock)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
StockID Varchar 10 P Not null 入库编号
MerchID Varchar 10 F Not null 入库商品编号
MerchNum Int 4 Not null 入库数量
MerchPrice Money 4 Not null 单额
TotalPrice Money 4 Not null 总额
StockDate Datetime 8 Datetime 入库日期
PlanDate Datetime 8 Datetime 计划进货日期
StockState Int 4 Not null 入库状态

供货商表(Provide)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
ProvideID varchar 10 P Not null 供货商编号
ProvideName Varchar 50 Not null 供货商名称
ProvideAddress Varchar 250 供货商地址
ProvidePhone Varchar 25 供货商电话

厂商表(Provide)
字段名 字段类型 长度 主/外键 字段值约束 对应中文名
FactoryID varchar 10 P Not null 厂商编号
FactoryName Varchar 50 Not null 厂商名称
FactoryAddress Varchar 250 厂商地址
FactoryPhone Varchar 25 厂商电话
6、物理设计文档
/*----------创建数据库----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go

/*----------创建基本表----------*/
use [SuperMarketdb]
go
/*创建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*创建厂商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*创建会员表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*创建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*创建供应商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*创建销售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*创建入库表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*创建用户表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO

/*----------创建表间约束----------*/
/*商品信息表中厂商编号、供应商编号分别与厂商表、供应商表之间的外键约束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*销售表中商品编号与商品信息表之间的外键约束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入库表中商品编号与商品信息表之间的外键约束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO

/*----------创建索引----------*/
/*在交易表上建立一个以交易编号、交易日期为索引项的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一个以商品编号为索引项的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在销售表上建立一个以销售编号、销售日期为索引项的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入库表上建立一个以入库编号、入库日期、商品编号为索引项的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO

/*----------创建视图----------*/
/*创建用于查询交易情况的视图*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 员工名称,
MemberCard as 会员卡号,
DealingPrice as 交易金额
FROM Dealing
GO
/*创建用于查询进货计划的视图*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
Factory.FactoryName as 厂商,
Provide.ProvideName as 供货商,
Stock.MerchNum as 计划进货数量,
Stock.PlanDate as 计划进货日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*创建用于查询销售明细记录的视图*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
MerchInfo.MerchPrice as 商品价格,
Sale.SalePrice as 销售价格,
Sale.SaleNum as 销售数量,
Sale.SaleDate as 销售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*创建用于查询入库情况的视图*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
Factory.FactoryName as 厂商,
Provide.ProvideName as 供货商,
Stock.MerchPrice as 入库价格,
Stock.MerchNum as 入库数量,
Stock.TotalPrice as 入库总额,
Stock.StockDate as 入库日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO

7、小结
和传统管理模式相比较,使用本系统,毫无疑问会大大提高超市的运作效率,辅助提高超市的决策水平,管理水平,为降低经营成本, 提高效益,减少差错,节省人力,减少顾客购物时间,增加客流量,提高顾客满意度,增强超市扩张能力, 提供有效的技术保障。
由于开发者能力有限,加上时间仓促,本系统难免会出现一些不足之处,例如:
 本系统只适合小型超市使用,不能适合中大型超市使用;
 超市管理系统涉及范围宽,要解决的问题多,功能复杂,实现困难,但由于限于时间,本系统只能做出其中的一部分功能;
对于以上出现的问题,我们深表歉意,如发现还有其它问题,希望老师批评指正。
请采纳。

D. sql数据库XX系统的设计实例

我这里有个现成的,简单的图书管理系统数据库。
数据库名称:BookManager 图书信息表(BookInfo)
字段
名称
类型
是否为空(Y/N)
说明
BookID
编号
Int(4)
N
主键
BookName
书的名称
Varchar(50)
N

BookAuthor
作者
Varchar(50)
N

BookTypeID
图书的类型
Int(4)
N
外键
BookSpec
图书规格
Varchar(50)
Y

BookConcert
出版社
Varchar(50)
Y

BookPrice
价格
double
N

BookCount
数量
Int(10)
N

BookDates
入库时间
Datatime
N

BookState
图书状态
Varchar(20)
Y
是否已借出
BookRemark
备注
Varchar(100)
Y

fee
费用
Double
N
结帐付费
图书类型表(BookType)
字段
名称
类型
是否为空(Y/N)
说明
ID
编号
Int(4)
N
主键,自动增加
TypeName
图书类型
Varchar(50)
N

E. 数据库表的设计

用户表:{用户编号(PK),用户名,密码,用户类别, 所属专业号(FK)}
课程表:{课程编号(PK),课程名,用户编号(FK) ,学分}
院 系:{院系编号(PK),院名}
专 业:{专业号(PK),专业名称 ,专业简介 ,总学时,所属院号(FK)}
参考书:{索书号(PK),课程编号(FK),ISBN/ISSN,责任者,出版日期,校图书馆连接地址,电子书连接地址}
专业课程表{专业号,课程编号} 联合主键

F. 数据库设计实例

某种“数据库技术”课程的作业吧
把表的结构提供给你,其它的最好看看书自己做吧

车主(车主ID,...)
汽车(汽车ID,...,所属车主ID)
事故(事故ID,...,所属汽车ID)

所有的主ID应该有索引,车主姓名和车牌号也可以有索引
视图:车主与汽车的连立,车主、汽车与事故的连立

E-R图就是三大区域,中间有两个1:n连接

这是3NF范式(主外码连接无冗余)

G. 求sql数据库设计实例

推荐最好的软件分析设计网站:

“erp系统分析论坛”"(摆渡搜索)

涉及: ERP解决方案||需求分析||业务建模||系统分析||信息监理;有大量的免费ERP软件资料,还有交易区,提供资源买卖市场;

------ [总设计师] 咨询团 ------

H. 1. 根据现实生活中的例子,设计一个简单的数据库,要求有至少三个表,每个表的字段不少于三个,每个表的

要求
1.提交报告的创建表和插入表数据的SQL语句须在SQL Server 2000中进行测试验证。
2.每位同学独立完成,最后如果发现两位同学的报告存在25%以上雷同,则两人的期中考试成绩记为0分,请学习委员收设计报告的时候进行筛查。
3.最终上交设计报告要求用A4纸打印。
4.提交学委时间为11月5日,学委进行筛查后提交给我的最后时间为11月6日。