数据库表设计
好的数据结构会影响速度。好的数据库表设计会影响数据库操作效率。特别是数据多的时候，如果表的结构不好的话操作的时候条件（where后的内容）会变的非常复杂。
SQL是关系数据库中用到的一种语言。所以，为了简化SQL，表的关系（内部和外部）要尽量设计的合理。
下面有几个可以参照的步骤：
1）找出那个表要描述的东西；
2）列出你想通过这个表得到的相关信息的列表；
3）通过上面的信息列表，将信息划分成一块块小的部分，通过此小块来建表；
比如说：
现在需求是：
1）我需要一个表来管理我的朋友的个人信息；
2）我想要的是：通过名字查到某人的地址，生日和邮箱；
3）将上面的信息划分成一块块分别对应表里的一个字段，所以表可以如下：
姓名住址邮箱生日
但需求可能更细，比如说：生日我想精确到年，这样方便我查询每年里所有的朋友。这样就可以将生日再细分成年月日三个字段。甚至如果要细分的话，地址可以再分国国家，省，市等。当然，这就看你想通过表获得哪些数据，一切设计是为了方便数据库操作。在方便自己的前提下将数据表的字段设计成“原子化”（即不可再细分）。比如说，一个网上商店的数据表，什么路多少号对于它来说就是原子化的数据了，就不用再把什么街多少号分开做为两个字段来存储。但对于一个地产商来说，他希望可以通过街道名，号，等来查，所以地址分成几个字段会更好。
字段的原子化是指一个字段里不要包括多个同类型的值；如：
name interests
jim fishing,football
lilei walking,book
表的原子化是指一个表里不要包括几个储存同类型值的字段；如：
teacher student1 student2 student3
lucy hanmeimei poli lily
jack rose mary simon
这里的student1 student2 student3 就重复了。但上面这两种情况似乎只能选择其中一个,也就是说无法满足绝对的原子化,其实不然.我们可以把这些无法满足原子化的字段另外建一个表,让两个表关联起来.
更合理的表设计会给每条记录加上一个唯一的识别，就是加上主键。
1）将一个表字段设为主键要求在表创建的时候就进行设置。
2) 一个表里被设为主键的字段的值必须是唯一的，也就是说如果一个字段被设为主键，这个表所有的数据列表里这个字段的值不可能有重复的。
3) 被设为主键的字段不能插入空值。
4) 被设为主键的字段的值是不能更改的。
5) 如果字段被设为是自增长的,主键只能设置一个且它必须是主键。如果表中没有自增长的字段,则可以设多个字段为主键.
6) 主键最好是一个和表里数据无关的值。比如说另建一个字段：id;而不要设在：name 等这些字段上。
前面提到了两个表关联.两个表之间数据的关系有三种:
1)一对一;两个表里数据唯一对应;
2)一对多;表A在表B里对应多条数据,但表B里的一条数据绝对只对就A中的一条数据;
3)多对多;A里的一条数据对应B里的多条数据,B里一条数据也对应A中的多条数据.
一对一的表设计用的不多.可能用到的情况有:
a)对一个表中大多数时候不查的字段,放到另一个表中对应起来.这样可以提高大多数时候查询的效率;
b)若表中记录还有些字段的值未知,可以将这些字段分出来放.这样可以让主表中不存在NULL;
c)不想轻易就查出来的数据,比如一个人的工资详情,等.可以在主另一表中放着;
d)大文本,通过一个外键关联,这样可以提高查询效率;
一对多的情况可以如下:
有一个人员信息表info,里面包括一个外键:email;这个字段里存的是邮箱表emailBox里的主键:id;因为一个人可以对应多个邮箱,但一个邮箱只能属于一个人(他自己要共用木有办法)
多对多对优化表设计的用处最大,效果最显著;一个多对多的关系是由一个连接表有两个一对多的表关系组成的;查看下图:
另外,同一个表里的各字段之间不要有复杂的依赖关系.各字段只能和主键有依赖关系.如果非主键和非主键间有依赖关系,就要将它们从主表分离出去,放在另一个表中,并通过外键进行关联
ORI数据库表设计 用户信息 用户表USERINFO 字段类型描述是否允许空UID INT 用户编号,主键自增长否LOGINNAME VARCHAR(12) 登录用户名（长度限制4~12个字符）否 PASSWORD VARCHAR(16) 密码（长度限制8~16个字符）否 USERTYPE INT 用户类型（1个人用户，2企业用户）否 NICKNAME VARCHAR(16) 昵称否 个人用户HUMANUSERINFO 字段类型描述是否允许空HUID INT 主键，自增长否 UID INT USERINFO表外键否REALNAME VARCHAR(8) 用户真实姓名否 EMAIL VARCHAR(50) 邮箱否 TEL VARCHAR(20) 家庭电话是 MOBILE VARCHAR(11) 手机是 ADDRESS VARCHAR(100) 家庭地址是 POSTCODE VARCHAR(6) 邮编是HEADPORTRAITPATH VARCHAR(100) 头像路径是BIRTHDAY VARCHAR(10) 生日是 HOBBY VARCHAR(100) 兴趣爱好是 JOB VARCHAR(100) 工作是TOTALPRICE DOUBLE(10,2) 个人消费总金额是GOLD Int(20) 金币是IDENTITYCARD VARCHAR(18) 身份证是 企业用户ENTERPRISEUSERINFO 字段类型描述是否允许空EUID INT 主键，自增长否 UID INT USERINFO表外键否 NAME VARCHAR(100) 公司名称否 TEL VARCHAR(20) 电话否 EMAIL VARCHAR(50) 邮箱否 ADDRESS VARCHAR(100) 地址否FAX VARCHAR(20) 传真是HEADPORTRAITPATH VARCHAR(100) 头像路径是LICENSE VARCHAR(100) 营业执照复印件否
数据库设计词汇对照表 1. Access method（访问方法）：此步骤包括从文件中存储和检索记录。 2. Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。 3. Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。 4. Anomalies（异常）参见更新异常（update anomalies） 5. Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设计用户界面以及使用和处理数据库的应用程序。 6. Attribute（属性）（关系模型）：属性是关系中命名的列。 7. Attribute（属性）（ER模型）：实体或关系中的一个性质。 8. Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些与超类有关的属性的过程。 9. Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。 10. Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如，panch Has Staff。 11. Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。 12. Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。 13. Candidate key（候选键，ER关系模型）：仅包含唯一标识实体所必须得最小数量的属性/列的超键。 14. Cardinality（基数）：描述每个参与实体的可能的关系数目。 15. Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并成新数据库应用程序的一个需求集合 16. Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。 17. Client（客户端）：向一个或多个服务器请求服务的软件应用程序。 18. Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段，这些行在这个字段上有相同的值。 19. Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一个主索引或一个群集索引。 20. Column（列）：参加属性（attribute）。 21. Complex relationship（复杂关系）：度数大于2的关系。 22. Composite attribute（复合属性）：由多个简单组件组成的属性。 23. Composite key（复合键）：包含多个列的主健。
数据库表结构设计参考
表名外部单位表（DeptOut） 列名数据类型（精度范围）空/非空约束条件 外部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 交换类型变长字符串(50) N 交换、市机、直送、邮局单位邮编变长字符串(6) 单位标识(英文) 变长字符串(50) 排序号整型(4) 交换号变长字符串(50) 单位领导变长字符串(50) 单位电话变长字符串(50) 所属城市变长字符串(50) 单位地址变长字符串(255) 备注变长字符串(255) 补充说明该表记录数约3000条左右，一般不做修改。初始化记录。 表名外部单位子表（DeptOutSub） 列名数据类型（精度范围）空/非空约束条件 外部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 补充说明该表记录数一般很少 表名内部单位表（DeptIn） 列名数据类型（精度范围）空/非空约束条件 内部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 工作职责 排序号整型(4) 单位领导变长字符串(50) 单位电话（分机）变长字符串(50) 备注变长字符串(255)
补充说明该表记录数较小（100条以内），一般不做修改。维护一次后很少修改 表名内部单位子表（DeptInSub） 列名数据类型（精度范围）空/非空约束条件内部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 单位类型变长字符串(50) 领导、部门 排序号Int 补充说明该表记录数一般很少 表名省、直辖市表（Province） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 名称变长字符串(50) N 外键 投递号变长字符串(255) N 补充说明该表记录数固定 表名急件电话语音记录表（TelCall） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 发送部门变长字符串(50) N 接收部门变长字符串(50) N 拨打电话号码变长字符串(50) 拨打内容变长字符串(50) 呼叫次数Int 呼叫时间Datetime 补充说明该表对应功能不完善，最后考虑此表 表名摄像头图像记录表（ScreenShot） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 拍照时间Datetime N 取件人所属部门变长字符串(50) N 取件人用户名变长字符串(50) 取件人卡号变长字符串(50) 图片文件BLOB/Image
数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法，考虑到数据库及其应用系统开发的全过程，将数据库设计分为六个阶段。如下图。 ①需求分析 需求收集和分析，得到用数据字典描述的数据需求，用数据流图描述的处理需求。 ②概念结构设计 对需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型（用E-R图表示）。 ③逻辑结构设计 将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其 进行优化。 ④物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。 ⑤数据库实施
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻 辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明：设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式，如下图。 需求分析阶段：综合各个用户的应用需求；
概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式，即E-R图； 逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关 系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式； 物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。
关系型数据库理论可能是20世纪60年代和70年代存储系统先锋的救星，但是从那是开始它就成了许多数据开发人员的毒药，就是因为现代数据库系统发展得如此之好，以至于它将其关系型支柱对开发人员隐藏了。设计良好的关系型数据库很容易使用、很灵活，并且能够保护数据的有效性。而设计不良的数据相反仍然能够发挥相当的作用，但是最终可能会导致数据的无效、错误或者丢失。 开发人员有一些专用的规则，叫做范式（normal forms），他们根据这些规则来创建设计良好的数据库。在这里，我将通过创建一个用于保存书籍信息的简单数据库来探讨一下范式。 确定实体和元素 设计数据库的第一步是做你的家庭作业并确定你所需要的实体。实体是数据一种类型的概念集。通常只从一两个实体开始，再随着你数据的规范化而增加列表。对于我们的示例数据库，它看上去就好像我们只需要一个实体——书。 在确定了所需要实体的清单之后，你下一步就需要为每个实体创建数据元素（也就是说，你需要保存的信息）的清单。收集这样的信息有多种途径，但是最有效的可能就是依赖你的用户了。向你的用户询问他们日常工作的情况，要求查看当前完成他们工作所需要的各种表格和报告。例如，订单上可能会列出你创建销售应用程序所需要的许多数据元素。 我们的书籍实体没有书面表格和报告可用，但是下列元素清单将有助于我们开始设计这个数据库： {Title, Author, ISBN, Price, Publisher, Category} 很重要的一点是，要注意，把我们这里要用的实体移动到元素的过程并不能适用于所有状况。你所需要的实体不会总是像我们书籍示例那样清楚，所以你可能要从数据元素的一长串清单开始，在后面你会根据实体来划分元素。 正规化的头几步 一旦有了实体清单（表格）和数据元素（字段），你就准备好让关系型数据库理论运作了。这个理论的主要推动力是规范化——删除任何重复的组和冗余的数据，并把它们放到两个或者更多相关表里的过程。你并不是一定需要拥有一个以上的表格，但是你的数据简单到只需要一个表格的机会并不多。 你应该小心地检查数据（这些数据会出现在多条记录里）和依赖性错误的实体和元素清单，并把已损坏的字段移动到不同的表格里。例如，你可能列出同一个作者的多本书，并在数据库里重复了作者的名字。当你认为会一次又一次地看到相同的数据值时，你就应该考虑把这个字段移动到另一个表格里了。 要记住，在这一点上，你只是在操作潜在表格的列表，而不应该真正地创建这个表格：现在还是要用笔和纸来列表。 范式简介 数据库规范化的过程非常著名，所以有正式的规则来保证规范化数据库的建设。这些规则有七条，叫做范式，而在大多数情况下头四条就够用了： 第一范式（1NF）——这条规则有几个要求，包括：无多值项目（multivalued item）和重复组（repeating group）；每个字段都是原子型的（atomic），也就是说每个字段必须包含可能的最小数据元素；以及表格含有关键字（key）。 第二范式（2NF）——表格必须按照1NF来规范化。所有的字段必须引用（或者描述）主键值。如果主键基于一个以上的字段，那么每个nonkey字段必须取决于复杂键（complex key），而不仅仅是一个没有键的字段。不支持主键的nonkey字段应该被移动到另一个表格里去。 第三范式（3NF）——表格必须符合1NF和2NF的要求。所有的字段都必须相互独立。任何描述nonkey字段的字段都必须被移动到另一个表格里。
怎样设计一个优秀的数据库 一个成功的管理系统，是由：[50% 的业务+ 50% 的软件] 所组成，而50% 的成功软件又有[25% 的数据库+ 25% 的程序] 所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。 有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： ?第 1 部分- 设计数据库之前：这一部分罗列了12 个基本技巧，包括命名规范和明确业务需求等。 ?第 2 部分- 设计数据库表：总共24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 ?第 3 部分- 选择键：怎么选择键呢？这里有10 个技巧专门涉及系统生成的主键的正确用法，还有何时以及如何索引字段以获得最佳性能等。 ?第 4 部分- 保证数据完整性：讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 ?第 5 部分- 各种小技巧：不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。 第 1 部分- 设计数据库之前 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。 定义标准的对象命名规范 一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用_N 作为后缀；如果是字符类型则可以采用_C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多"money"字段，你不妨给每个列[字段]增加一个_M 后缀。还有，日期
数据库设计中英文术语表 正文 1.Access method（访问方法）：此步骤包括从文件中存储和检索记录。 2.Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。 3.Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。 4.Anomalies（异常）参见更新异常（update anomalies） 5.Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设 计用户界面以及使用和处理数据库的应用程序。 6.Attribute（属性）（关系模型）：属性是关系中命名的列。 7.Attribute（属性）（ER模型）：实体或关系中的一个性质。 8.Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些 与超类有关的属性的过程。 9.Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。 10.Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如， panch Has Staff。 11.Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标 识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可 以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。 12.Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。 13.Candidate key（候选键，ER关系模型）：仅包含唯一标识实体所必须得最小数量的 属性/列的超键。 14.Cardinality（基数）：描述每个参与实体的可能的关系数目。 15.Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并成 新数据库应用程序的一个需求集合 16.Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。 17.Client（客户端）：向一个或多个服务器请求服务的软件应用程序。 18.Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段， 这些行在这个字段上有相同的值。 19.Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一 个主索引或一个群集索引。 20.Column（列）：参加属性（attribute）。 https://www.doczj.com/doc/c210940391.html,plex relationship（复杂关系）：度数大于2的关系。 https://www.doczj.com/doc/c210940391.html,posite attribute（复合属性）：由多个简单组件组成的属性。 https://www.doczj.com/doc/c210940391.html,posite key（复合键）：包含多个列的主健。 24.Concurrency control（并发控制）：在多用户环境下同时执行多个十五并保证数据完 整性的一个DBMS服务。 25.Constraint（约束）：数据库不允许包含错误数据的一致性规则。 26.Data conversion and loading（数据转换和加载）：数据库应用生命周期重的一个阶段， 包括转换现有数据到新数据库中以及酱下耨应用程序转换到新的数据库上运行。 27.Data dictionary（数据字典）：参见系统目录（system catalog）。
入库资料表结构说明 一、考证资料库 测站标题表 测站标题表用来描述每个测站的基本信息。这些信息一般不随时间的变化而变化。在整个数据库的生命周期中，测站标题表的内容基本保持不变。但该表中的数据需要逐条的录入。 表标识: ST_STINF_B 表编号: 101 二、实时水雨情库 时段降水量表 时段降水量表用来记录时段降水量和日降水量以及积雪深度和密度。
该表中的数据可以使用相应的信息处理系统自动将报汛资料写入数据库中。 表标识: ST_RNFL_R 表编号: 201 河道水情表 河道水情表用来记录河道水文（水位）站测报的河道水情信息，如水位和流量等。该表中的数据可以使用相应的信息处理系统自动将报汛资料写入数据库中。 表标识: ST_RIVER_R 表编号: 203
闸坝水情表 闸坝水情表用来记录河道上闸坝站测报的水情信息。该表中的数据可以使用相应的信息处理系统自动将报汛资料写入数据库中。 表标识: ST_DAM_R 表编号: 204 湖库水情表 湖库水情表用来记录湖库站测报的水库水情信息。该表中的数据可以使用相应的信息处理系统自动将报汛资料写入数据库中。 表标识: ST_RSVR_R 表编号: 205
闸门启闭情况表 闸门启闭情况表用来存储闸坝和水库报汛中列报的闸门启闭情况以及相应的过闸流量等。该表中的数据可以使用相应的信息处理系统自动将报汛资料写入数据库中。 表标识: ST_GATE_R 表编号: 206 三、历史水雨情库 逐日降雨量表 表标识: ST_DAYP_H 表编号: 401
逐日水位表 表标识: ST_DAYZ_H 表编号: 402
数据库名/HotelManagerDB 客房表/Rooms SQL语句 房间类型 insertinto RoomType values('普通单人间','否','0','1'); insertinto RoomType values('普通双人间','否','0','2'); insertinto RoomType values('豪华单人间','否','0','3'); insertinto RoomType values('豪华双人间','否','0','4'); 楼层表 insertinto Floor values('一楼'); insertinto Floor values('二楼'); insertinto Floor values('三楼'); 房间状态 insertinto RoomState values('未入住'); insertinto RoomState values('已入住'); insertinto RoomState values('空闲'); insertinto RoomState values('仓库');
客房表 insertinto Rooms values('101','1','1','60','普通单人间,房间内物品完 好.','1'); insertinto Rooms values('102','2','1','100','普通双人间,房间内物品完 好.','1'); insertinto Rooms values('201','3','2','80','豪华单人间,房间内物品完 好.','1'); insertinto Rooms values('202','4','2','140','豪华双人间,房间内物品完 好.','1'); insertinto Rooms values('301','1','3','60','普通单人间,房间内物品完 好.','1'); insertinto Rooms values('302','2','3','100','普通双人间,房间内物品完好.','1'); 客户表/Customers 权限系统表的设计
OA办公管理系统数据库表设计9 --1.考勤表 create table Attendence ( Attribute_RecordId number not null primary key, user_no number(4) not null, WorkDate date null, CalendarDate date null, OnDutyTime date null, OffDutyTime date null, OnDutyTimeStatus number null, OffDutyTimeStatus number null, LateRemark varchar2(200) null, LeaveEarlyRemark varchar2(200) null, checkremark varchar2(100) null ); --2.邮件表
create table email ( Emai_id number not null primary key, user_no number(4) not null, ReceiveEmailPeopleId number null, EmailContent varchar2(100) null, SendEmailTime date null, emailremark varchar2(100) null ); --3.文件表 create table FILES ( FILE_ID number(6) not null primary key, user_no number(4) null, FILE_NAME varchar2(50) null, FILE_CONTENT varchar2(200) null, SENDER_ID number(6) null, SENDER_NAME varchar2(40) null, DA TETIME date null,
数据库设计中英文术语表 June 27, 2004, In Focus on 索引 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 正文 1.Access method（访问方法）：此步骤包括从文件中存储和检索记录。 2.Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。 3.Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。 4.Anomalies（异常）参见更新异常（update anomalies） 5.Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设 计用户界面以及使用和处理数据库的应用程序。 6.Attribute（属性）（关系模型）：属性是关系中命名的列。 7.Attribute（属性）（ER模型）：实体或关系中的一个性质。 8.Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些 与超类有关的属性的过程。 9.Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。 10.Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如， panch Has Staff。 11.Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标 识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。 12.Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。 13.Candidate key（候选键，ER关系模型）：仅包含唯一标识实体所必须得最小数量的 属性/列的超键。 14.Cardinality（基数）：描述每个参与实体的可能的关系数目。 15.Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并 成新数据库应用程序的一个需求集合 16.Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。 17.Client（客户端）：向一个或多个服务器请求服务的软件应用程序。 18.Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段， 这些行在这个字段上有相同的值。 19.Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一 个主索引或一个群集索引。 20.Column（列）：参加属性（attribute）。 https://www.doczj.com/doc/c210940391.html,plex relationship（复杂关系）：度数大于2的关系。 https://www.doczj.com/doc/c210940391.html,posite attribute（复合属性）：由多个简单组件组成的属性。 https://www.doczj.com/doc/c210940391.html,posite key（复合键）：包含多个列的主健。 24.Concurrency control（并发控制）：在多用户环境下同时执行多个十五并保证数据完 整性的一个DBMS服务。
创建三个数据库：平台（Platform ）,IM(IM),人力资源（HR ） 一． P latform 库 Platform 库中的表有：人员信息表，部门表，职位表，组件组表，组件表 组件权限要求： 1. 不同部门可见的组件（组）不同； 2. 相同部门的不同职位可见的组件（组）不同； 3. 人事部可见所有人的个人基本信息（可以修改），财务部可见所有人的基本信息基本表 （不能修改）： 组件流程： 1. 登陆时，（通过存储过程）获取人员信息表、部门表、职位表、组件组表、组件表，发 送给服务器，有服务器发给客户端，添加相应组件（组）（组件由管理员分配）； 2. 如果有人员信息更改，（通过触发器）改变数据库数据 基本表： 人员信息表属性：人员编号（主键），在职状态，部门编号，职位编号，员工姓名、年龄、家庭住址、部门、职位、学历、手机号、密码、邮箱、身份证号、生日、性别 部门表属性：部门号，部门名称，上级部门，合作部门 编号 字段名 类型 长 度 索引 可空 描述 1 EmpID Int 20 主键（自增） N 员工编号 2 Name nvarchar 20 N 名字 3 Sex nvarchar 10 Y 性别 4 Address nvarchar 50 Y 家庭住址 5 Birthday nvarchar 50 Y 生日 6 PhoneNumber varchar 30 Y 手机号 7 Password varchar 50 N 密码 8 Email varchar 50 Y 电子邮箱 9 LevelEdu nvarchar 20 Y 学历 10 IdCard varchar 50 Y 身份证号 11 DeptID Int 部门表外键 N 部门ID 12 PositionID Int 职位表外键 Y 职位ID 13 Iswork Int N 宝贝，，、。、。么么么么 0离职，1在职 编号 字段名 类型 长度 索引 可空 描述 1 DeptID int 主键(Pk)（自增） N 部门ID 2 DeptName nvarchar 20 N 部门名称 3 SuperiorDeptID int 本表外键 Y(UNIQUE) 上级部门ID
1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单据对应多个实体，或多张原始单据对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单据对应多个实体”的典型例子。 2. 主键与外键 一般而言，一个实体不能既无主键又无外键。在E－R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性： (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。 理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。 4. 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。 〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。 在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。 表1 商品表的表结构 商品名称商品型号单价数量金额 电视机 29吋 2,500 40 100,000 5. 通俗地理解三个范式 通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)： 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解； 第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。 没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范
数据库表结构设计 1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系:即一张原始单据对 应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实 体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计 录入界面大有好处。 〖例1〗:一份员工履历资料，在人力资源信息系统中，就对应三个基本表:员 工基本情况表、社会 关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的 实体, 可以定义主键， 也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个 美国数据库设计专家说:“键，到处都是键，除了键之外，什么也没有”，这 就是他的数据库设计经验 之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为:主键是 实体的高度抽象，主键与 外键的配对，表示实体之间的连接。
3. 基本表的性质 基本表与中间表、临时表不同，因为它具有如下四个特性: (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。 理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。 4. 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是 最好的设计。为了提高数据库的运行效率，常常需要降低范式标准:适当增加冗余，达到以空间换时间的目的。 〖例2〗:有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。 在ROSE 2002中，规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。 表1 商品表的表结构 商品名称商品型号单价数量金额 电视机 29吋 2,500 40 100,000 5. 通俗地理解三个范式
如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据 库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的 老师也比不过经验的教诲。所以我们最近找了些对数据库设计颇有造诣的专业人士给大家传授一些设 计数据库的技巧和经验。我们的编辑从收到的130 个反馈中精选了其中的60 个最佳技巧，并把这些 技巧编写成了本文，为了方便索引其内容划分为5 个部分： 第1 部分—设计数据库之前 这一部分罗列了12 个基本技巧，包括命名规范和明确业务需求等。 第2 部分—设计数据库表 总共24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第3 部分—选择键 怎么选择键呢？这里有10 个技巧专门涉及系统生成的主键的正确用法，还有何时以及如何索引字段 以获得最佳性能等。 第4 部分—保证数据完整性 讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 第5 部分—各种小技巧 不包括在以上4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。 第1 部分—设计数据库之前 1. 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库 项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实 现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究 可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。— Lamont Adams 我曾经接手过一个为地区运输公司开发的数据库项目，活不难，用的是Access 数据库。我设置 了一些项目设计参数，而且同客户一道对这些参数进行了评估，事先还查看了开发环境下所采取 的工作模式，等到最后部署应用的时候，只见终端上出了几个提示符然后立马在我面前翘辫子 了！抓耳挠腮的折腾了好几个小时，我才意识到，原来这家公司的网络上跑着两个数据库应用， 而对网络的访问需要明确和严格的用户帐号及其访问权限。明白了这一点，问题迎刃而解：只需 采用客户的系统即可。这个项目给我的教训就是：记住，假如你在诸如Access 或者
索引、规则、默认值和约束 在这个小组中，我负责建立图书数据库的索引、规则、默认值和约束。数据库的索引是一个表中所包含的值的列表，注明了表中包含各个值的行所在的存储位置。创建索引，我最大的感受是能节约大量时间，特别是当表中数据很大时。规则、约束、默认值则一起保证了数据的完整性。规则是数据库中队存储在表的列或用户定义数据类型中的值的规定和限制；约束定义了关于列中允许值的规则；默认值是用户输入记录时向没有指定具体数据的列中自动插入的数据。这些都是创建一个数据库必不可少的元素。 表的创建 在我们这个小组里，我负责关于表的创建部分，包括了字段名、数据类型和主键的设计。我做的数据库设计部分，首先必须弄清楚表中列的数据类型，是char、varchar、int、datetime、smallint型等等，还有是几个字符长度。还有的就是它的值是否可以为空的，这也是需要考虑的。在这个过程中我需要注意的是表的列名是不能重复的，它是具有唯一性的。设置主键相对而言就比较容易了，我最大的体会是对于表中每列的数据类型的分析必须谨慎细心，否则很容易出错。 E-R图 在我们组我负责画E-R图。它是这次项目设计的关键点，如果E-R图设计错误那么接下来的设计就无法进行，因此设计E-R图时需要特别的认真。E-R模型能够方便地模拟研究对象的静态过程。E-R ,即实体-联系方法，E-R图直观提供了表示实体型、属性和联系的方法。在画E-R图过程中，必须明确识别实体、属性和联系，用矩形、椭圆和菱形对应框出来。画这个图为后面的数据库设计打好基础，通过这次的数据库设计，我学到了不少知识，将理论运用与实际。 表关系图 在我们小组，我负责的是创建表关系图这部分。建表关系图相对来说也是比较容易的，只需要明确表之间的关系，有相同列内容的表用线连接起来。创建表关系图时，把老师上课讲的内容结合起来，就比较轻松了。通过这次小组设计，分工合作，我学到了很多书本上不能学到的东西，感觉对数据库的了解有所提高，毕竟自己亲自设计过一个数据库，不再是书本上的理论，空空而谈，自己觉得还是有收获的。 实验总结 在这次项目设计中，我们小组所选择的是设计一个图书管理系统，这对我们来说是一次尝试与创新的过程，也可以说是一个挑战的过程。虽然学了数据库这么久了，但是我们还是缺少经验。现在我们利用自己学到的知识设计并制作一个图书管理系统，这本身就是一个知识转化为生产力的过程，所以大家都很兴奋，都不同程度的投入了很高的热情与努力。 在具体的设计与实施中，我们看到并感受到了一个管理系统从无到有的过程，对具体的设计步骤、思路、方法、技巧都有了进一步的了解，并感受深刻。这次课程设计加深了我们对数据库系统设计相关知识以及SQL SERVER相关功能的理解。比如在建立基本的表、视图、索引、存储过程、触发器等，都比以前更加熟悉了，并在解决各种问题的过程中学到了很多新的知识。 在设计中我们基本能按照规范的方法和步骤进行，首先对现有的系统进行调查，并查阅有关资料，最后确定设计方案，然后设计并制作，实施过程中我们
数据库表设计 好的数据结构会影响速度。好的数据库表设计会影响数据库操作效率。特别是数据多的时候，如果表的结构不好的话操作的时候条件（where后的内容）会变的非常复杂。 SQL是关系数据库中用到的一种语言。所以，为了简化SQL，表的关系（内部和外部）要尽量设计的合理。 下面有几个可以参照的步骤： 1）找出那个表要描述的东西； 2）列出你想通过这个表得到的相关信息的列表； 3）通过上面的信息列表，将信息划分成一块块小的部分，通过此小块来建表； 比如说： 现在需求是： 1）我需要一个表来管理我的朋友的个人信息； 2）我想要的是：通过名字查到某人的地址，生日和邮箱； 3）将上面的信息划分成一块块分别对应表里的一个字段，所以表可以如下： 姓名住址邮箱生日 但需求可能更细，比如说：生日我想精确到年，这样方便我查询每年里所有的朋友。这样就可以将生日再细分成年月日三个字段。甚至如果要细分的话，地址可以再分国国家，省，市等。当然，这就看你想通过表获得哪些数据，一切设计是为了方便数据库操作。在方便自己的前提下将数据表的字段设计成“原子化”（即不可再细分）。比如说，一个网上商店的数据表，什么路多少号对于它来说就是原子化的数据了，就不用再把什么街多少号分开做为两个字段来存储。但对于一个地产商来说，他希望可以通过街道名，号，等来查，所以地址分成几个字段会更好。 字段的原子化是指一个字段里不要包括多个同类型的值；如： name interests jim fishing,football lilei walking,book 表的原子化是指一个表里不要包括几个储存同类型值的字段；如： teacher student1 student2 student3 lucy hanmeimei poli lily jack rose mary simon