怎么简单地理解数据库的概念？ - 知乎229被浏览<strong class="NumberBoard-itemValue" title="1分享邀请回答1076 条评论分享收藏感谢收起8添加评论分享收藏感谢收起数据库中的基本概念
时间： 18:18:03
&&&& 阅读：308
&&&& 评论：
&&&& 收藏：0
标签：在同一个数据集合中，不同的选择条件对应了不同的输出结果，数据库就是这样一种按数据结构来组织、存储和管理数据的仓库。程序或用户可以通过它来进行数据的访问与修改，它是数据存储的灵魂。
数据管理经历了人工管理、文件系统到数据库系统3个阶段。数据库是具有逻辑关系和确定意义的数据结合，它能克服传统文件组织所产生的一系列问题，数据冗余小，由于关系型数据库管理系统对于信息查询具有很大的灵活性，并且设计简单，所以已经被广泛使用在了实际的系统开发中。
关系数据库系统与文件数据库系统区别
关系数据库（relational database）是一个被组织成一组正式描述的表格的数据项的集合，这些表格中的数据能以不同的方式被存取或重新召集而不需要重新组织数据库表格，它对应于一个关系模型中的所有关系的集合。例如，教师、学生、课程这些关系以及关系间的联系就组成了一个教务系统。文件数据库系统是对文件的操作，包括存储、查询等。
关系数据库系统与文件数据库系统的区别如下：
（1）关系数据库系统的主要特征是数据的结构化，而文件数据库系统是数据的非结构化
（2）关系数据库中，用户看到的逻辑结构是二维表，而文件数据库系统中，基本元素是文件。
（3）文件数据库系统可以实现多媒体文件管理，支持C/S工作模式
SQL语言的功能有哪些
SQL是结构化查询语言（ Structured Query Language）的缩写，其功能包括数据查询、数据操作、数据定义和数据控制4个部分。
数据查询是数据库中最常见的操作，select语句得到所需的信息。SQL语言的数据操作结构（Data Manipulation Language，DML）主要包括插入数据、修改数据及删除数据3种语句。SQL语言使用数据定义语言（Data Definition Language，DDL）实现数据定义功能，可对数据库用户、基本表、视图、索引进行定义与撤销。数据控制语句（Data Control Language，DCL）用于对数据库进行统一的控制管理，保证数据在多用户共享的情况下能够安全。
基本的SQL语句有 select、insert、update、delete、create、drop、grant、revoke等
例如，设教务管理系统中有3个基本表：
学生信息表 S(SNO,SNAME,AGE,SEX)，其属性分别表示学号、姓名、年龄和性别
选课信息表 SC(SNO, CNO, SCGRADE)，其属性分别表示学号、课程号和成绩
课程信息表 C(CNO,CNAME,CTEACHER)，其属性分别表示课程号、课程名称和任课老师姓名。
（1） 把SC表中每门课程的平均成绩插入到另外一个已经存在的表 SC_C( CNO,CNAME,AVG_GRADE)中牟其中 AVG_GRADE表示的是每门课程的平均成绩。
insert into SC_C( CNO, CNAME,AVG_GRADE)
select SC.CNO, C.NAME, AVG(SCGRADE) FROM SC, C where SC.CNO = C.CNO
（2）从SC表中把何昊老师的女学生选课记录删除
delete from SC,S,C where SC.SNO=S.SNO AND SC.CNO = C.CNO
AND S.SEX = ‘女’ AND C.CTEACHEAR = ‘何昊’
（3）规定女同学选修何昊老师的课程成绩都应该在80分以上（包含80分）
alter table SC,S,C
add constrant GRADE CHECK( GRADE&80 )
where SC.CNO = C.CNO and SC.SNO = S.SNO AND C.CTEACHER = ‘何昊‘
（4）找出没有选修过‘何昊’老师讲授课程的所有学生姓名
SELECT SNAME FROM S
WHERE NOT EXISTS( SELECT * FROM SC,C WHERE SC.CNO= C.CNO AND CNAME = ‘何昊‘ AND SC.SNO = S.SNO )
（5）列出有两门以上（含两门）不及格课程（成绩小于60）的学生姓名及其平均成绩
SELECT S.SNO,S.SNAME,AVG_SCGRADE = AVG(SC.SCGRADE)
FROM S,SC,( SELECT SNO FROM SC WHERE SCGRADE&60 GROUP BY SNO HACING COUNT(DISTINCT CNO)&=2)A WHERE S.SNO = A.SNO AND SC.SNO = A.SNO GROUP BY S.SNO,S.SNAME
内连接与外连接有什么区别
内连接也称为自然连接，只有两个表相匹配的行才能在结果集中出现。返回的结果集是两个表中所有相匹配的数据，而舍弃不匹配的数据。由于内连接是从结果表中删除与其他连接表中没有匹配行的所有行，所以内连接可能会造成信息的丢失
内连接是保证两个表中所有的行都要满足连接条件，而外连接则不然。与内连接不同，外连接不仅包含符合连接条件的行，而且还包括左表（左外连接时）、右表（右外连接时）或两个边接表（全外连接）中的所有数据行。也就是说，只限制其中一个表的行，而不限制另一个表的行。
SQL的外连接共有3种类型：左外连接，关键字为LEFT OUTER JOIN；右外连接，关键字为RIGHT OUTER JOIN；全外连接，关键字为FULL OUTER JOIN。外连接的用法和内连接一样，只是将INNER JOIN关键字替换为相应的外连接关键字即可。
什么是事务
事务是数据库中一个单独的执行单元（unit），它通常由高级数据库操作语言（如SQL）或编程语言（如C++、Java等）书写的用户程序的执行所引起。当在数据库中更改数据成功时，在事务中更改的数据便会提交，不再改变。否则，事务就取消或者回滚，更改无效。（p243）
事务必须满足4个属性，即原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability），即ACID 4种属性。
（1）原子性。事务是一个不可分割的整体，为了保证事务的总体目标，事务必须具有原子性，即当数据修改时，要么全执行，要么全都不执行。。。原子性要求事务必须被完整执行
（2）一致性。一个事务执行之前和执行之后数据库数据必须保持一致性状态。数据库的一致性状态应该满足模式所指定的约束，那么在完整执行该事务后数据库仍然处于一致性状态。为了维护所有数据的完整性，在关系型数据库中，所有的规则必须应用到事务的修改上。数据库的一致性状态由用户来赋值，由并发控制机制实现。例如，银行转账，转账前后两个账户金额之和应保持不变。由并发操作带来的数据不一致性包括丢失数据修改、读“脏”数据、不可重复读和产生幽灵数据。
（3）隔离性。 隔离性也被称为独立性，当两个或多个事务并发执行时，为了保证数据的安全性，将一个事务内部的操作与事务的操作隔离起来，不被其他正在进行的事务看到。
（4）持久性。持久性也被称为永久性，事务完成以后，DBMS保证它对数据库中的数据的修改是永久性的，当系统或截止发生故障时，该修改也永久保持。持久性一般通过数据库备份与恢复来保证。
一般情况下，通过执行COMMIT或ROLLBACK语句来终止事务，当执行COMMIT语句时，自从事务启动以来对数据库所做的一切更改就成为永久性的了，即被写入到磁盘；而当执行ROLLBACK语句时，自事务启动以来对数据库所做的一切更改都会被撤销，并且数据库中的内容返回到事务开始之前所处的状态。无论什么情况，在事务完成时，都能保证回到一致状态。
什么是存储过程？它与函数有什么区别于联系
SQL语句执行的时候要先编译，然后再被执行。在大型数据库系统中，为了提高效率，将为了完成特定功能的SQL语句集进行编译优化后，存储在数据库服务器中，用户通过指定存储过程的名字来调用执行。
存储过程不等于函数，两者虽然本质上没有区别，但具体而言有一下几个方面的区别：
（1）存储过程一般是作为一个独立的部分来执行的，而函数可以作为查询语句的一个部分来调用。由于函数可以返回一个对象，因此它可以在查询语句中位于from关键字的后面。
（2）一般而言，存储过程实现的功能较复杂，而函数实现的功能针对性比较强
（3）函数需要用括号包住输入的参数，且只能返回一个值或表对象，存储过程可以返回多个参数
（4）函数可以嵌入在SQL总使用，可以在select中调用，存储过程不行。
（5）函数不能直接操作实体表，只能操作内建表
（6）存储过程再创建时即在服务器上进行了编译，执行速度更快。
什么是主键？什么是外键
主键也称为主码，是数据库中的一个或多个字段，是表中记录的唯一标示符。主键不能为空。一个表中只能有一个主键，主键列不一定只有一列，可以是多列。 主键可以唯一地标识一行。
主键需遵循以下原则：
（1）主键对用户而言没有意义
（2）主键不能为空
（3）主键保持不变。因为主键的用途是唯一地标示一行数据
（4）主键不应包含动态变化的时间戳
（5）主键原则上应当由计算机自动生成，而非用户指定。
外键也称为外码，标示的是两个关系之间的联系。当公共关键字在一个关系中为主键时，这个公共关键字被称为另外一个关系的外键。
一个表可以有多个外键，也可以为空
什么是死锁
在OS中有若干程序并发执行，它们不断地申请、释放资源，在此过程中，由于争夺资源而处于无限期的等待状态，造成程序无法继续执行，若无外力作用，它们都将无法推进下去，这时称系统处于死锁状态或系统产生了死锁。此时便只能通过外力来打破这种状态。
产生死锁的原因有以下3点。
（1）系统资源不足，在系统中常有多个进程共享资源的情况，如打印机，这些资源在同一时刻只能被一个进程使用。
（2）进程运行的推进顺序不对，进程在运行中具有异步性，当进程推进顺序不当时，便产生死锁。
（3）资源分配不当，如果系统资源充足，进程的资源请求都能得到满足，死锁的可能性会被大大降低，而进程推进顺序与速度不同，也可能会产生死锁。
产生死锁的4个必要条件：
（1）互斥，每个资源每次只能被一个进程使用
（2）请求与保持等待，一个进程因请求资源而被阻塞时，对已获得的资源保持不放
（3）不可剥夺，进程已获得的资源，在未使用完之前，不能强制剥夺
（4）环路等待，若干进程之间形成首尾相接的等待资源关系。
So，为了预防死锁，就要打破产生死锁的4个条件中的一个或多个，因此需要最大限度地增加系统资源，合理地安排进程的顺序并确定合理的分配资源的算法。
避免死锁是在资源的动态灯泡过程中，采取有效的方法防止系统进入不安全状态，达到预防死锁的目的，其中最具代表性的方法就是银行家算法。
什么是共享锁？什么是互斥锁
在数据库中，锁主要是对数据进行读/写的一种保护机制，从数据库系统的角度来看，一般可以将锁分为共享锁和互斥锁。
共享锁简称S锁，也叫读锁。用于不更改或不更新数据的操作（只读），如select语句。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加互斥锁。共享锁可阻止其他并发运行的程序获取重叠的独占锁定，但是允许该程序获取重叠的共享锁定。其他用户可以获取共享锁锁定的资源，但是不能进行修改该共享锁。在执行select命令时，sql server通常会对对象进行共享锁定。
共享锁又称为读锁。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。
互斥锁简称X锁，也叫排它锁，用于数据修改操作，如insert、update或delete。确保不会同时对同一资源进行多重更新。为了保证数据操作的完整性，引入了互斥锁。用互斥锁来保证在任意时刻，只能有一个线程访问对象。若事务T对数据D加X锁，则其他任何事务都不能再对D加任何类型的锁，直至T释放D上的X锁；一般要求在修改数据前要向该数据加互斥锁，所以互斥锁又称为写锁。
对于锁的使用，有一定的限制，需要遵守两个事项：
A、先锁后操作
B、事务结束之后必须解锁
一二三四范式有何区别
正确地进行表的设计称为“数据库规范化”，它的目的就是减少数据库中的数据冗余，从而增加数据的一致性。
范式是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。常见的范式有1NF、2NF、3NF、BCNF、以及4NF。
1NF，第一范式。第一范式是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多的关系。第一范式的模式要求属性值不可再分裂成更小部分，即属性项不能是属性组合或有组属性组成。
简而言之，第一范式就是无重复的列
CHECK约束是指限制表中某一列或某些列中可接受的数据值或数据格式，它用于限制列的取值范围，使用形式为：CHECK（约束表达式）。如果是对单列定义CHECK约束，那么该列只允许特定的值；如果是对一个表定义CHECK约束，那么此约束会在特定的列中对值进行限制。例如，对于一个员工信息表，给员工的年龄属性添加了一个约束，即年龄必须大于0且小于等于120，那么用户在输入年龄的时候，就必须遵守该约束，输入负数或者121就无法输入
视图是由从数据库的基本表中选取出来的数据组成的逻辑窗口，不同于基本表。它是一个虚表，在数据库中，存放的只是视图的定义而已，不存放视图包含的数据项，这些项目仍然存放在原来的基本表结构中。
视图的作用：
（1）可以简化数据查询语句
（2）可以使用户能从多角度看待同一数据
（3）通过引入视图，可以提高数据的安全性
（4）视图提供了一定程度的逻辑独立性。
标签：原文地址：http://blog.csdn.net/omenglishuixiang1234/article/details/
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！当前位置： →
→ 数据库设计 概念结构设计以权限系统为例
数据库设计 概念结构设计以权限系统为例
& 作者及来源： QA龙 - 博客园 &
&收藏到→_→：
摘要: 数据库设计 概念结构设计（以权限系统为例）
"数据库设计 概念结构设计以权限系统为例"：：
转载来自http://yiyihuazi.blog.163.com/blog/static//小小宇梦&&&&& 转载请注明出处尊重别人也是尊重自己
一、数据模型
以下概念在一些教科书中都会有讲到，比如：《与》。这里作了一下总结。
模型，是对现实世界的抽象，数据模型，就是描述（静态特征）、数据操作（动态特征）、数据完整性（动静交互的约束）的概念的集合。而数据模型也是（dbms）的核心和基础，各种dbms的实现都是基于数据模型的。
数据模型可分为两种：概念数据模型、结构数据模型。
（1）概念数据模型，是面向现象世界的数据模型，它独立于和dbms；
常用的概念模型有：e-r模型、模型等。但dbms发展至今，主流的仍然是关系型 ，所以目前对于概念模型的设计依旧是使用e-r模型为主。
也许哪天型 成为主流，那我们的概念模型设计就也可以采用的 了。其实er模型就是模型的雏形，模型一定程度上是从er模型演变过来的。
（2）结构数据模型，是面向 的数据模型，又可分为逻辑数据模型（）、物理数据模型（物理结构）；
逻辑数据模型：这是用户在dbms中看到的模型。dbms的逻辑模型先后经历了层状模型（树状模型）、网状模型、关系模型，以及现在发展中的模型，之所以关系型经久不衰，就是因为它简单的：表，无论是设计、维护都比较容易，尽管在处理效率上略次于前两者。模型虽然结构清晰、设计方便，但查询功能太弱，因此在dbms中暂还没有取代关系模型的地位；
物理数据模型：是指数据在存储介质上的组织结构，它与相应的dbms及os相关，通常不需要手动去管理，而是通过用户在dbms中指定存储的方式，由dbms自动完成在相应os上的存储结构。
上面数据模型的三种分类，也正是数据从现实世界到计算机世界的具体表示所要经历的 ，无论dbms的发展如何，这个 是不会改变的。
相应的， 设计可分为以下三步：
（1）概念结构设计：利用概念模型对现实世界进行抽象；
（2）设计：将概念模型转化为逻辑模型，也就是将对现实世界的抽象转化为计算机上dbms的；
（3）物理结构设计：定制逻辑模型中实现的在物理介质的存储结构；
至于 设计在整个工程中所处的位置，详见《工程 - 5、 设计与开发》。
二、概念结构设计
概念结构设计的 ，就是建立e-r模型的 。
2.1、e-r图
e-r图的组件有很多，但概括起来说，可分为以下四种：
矩形：表示实体
菱形：表示实体间的关系
椭圆：表示实体的属性
线段：用于将实体、关系相连接
对于双矩形、双菱形、双椭圆、双线段等等一些组件，可以不用去管，通常用以上四种组件就可以表达清楚实体及实体间的关系。
2.2、建立e-r模型
以下 为建立e-r模型的一般步骤，这里以权限管理模块为例：
2.2.1、标识实体
&这是权限管理中常用的基于角色的访问控制（
rbac），通常有用户、角色这两个实体。
2.2.2、标识关系
&用户与角色间为多对多的互相拥有关系。
2.2.3、标识实体、关系的属性
&不仅仅是实体有属性，关系同样也有属性，这些属性在实体间建立关系时才会存在。
有时属性太多，无法在图上一一列出，可以用表格，在后面的步骤中这个表格同样会用到，如下：
2.2.4、确定属性域
属性域就是属性的取值范围。
这时，可以用表格将属性的数据类型、数据长度、取值范围及是否可为空、简单/复合、单值/多值、是否为派生属性等域信息定义出来。
这个 ，事实上包含了设计中的数据类型、null、check、default等信息。
数据类型及长度
是否可为空
1字节的短整形或布尔型
1字节的短整形
20字节的字符型或长整形
2.2.5、确定键
键就是可用于标识实体的属性，有：主键、唯一键、外键。
2.2.6、实体的特化/泛化
也就是此文来自: 马开东博客
转载请注明出处 网址：
模型中父类和子类的概念，这是个可选的步骤。
举个例子，用户中大部分人都是普通员工，但有一小部分是从事销售的，销售有个负责区域的属性，如果将这个属性放在用户实体中，如下：
这时我们会发现，除了销售外，其他非销售这个属性全都不存在，这就是特化的 。可以另建一个销售的实体来泛化用户实体，如下：
&这样就完成了对用户实体的泛化，泛化的 也就是抽出实体间公共属性的 ，但通常，除非特化的部分太多，才会考虑将一个实体抽象成两个
1对1关系的实体，所有这个步骤是可选的。
2.2.7、检查模型
（1）检查冗余
首先检查实体：1对1关系的实体中有没有非外键的重复属性，或者就是同一个实体；
其次检查关系：有没有通过其他关系也可以得到的重复属性；
当然有时，需要考虑时间维度，因为有些属性是有时效性的，也就是虽然是同一个属性，但不同的时间表示的却是不同的内容，这一点在后面的设计中会提到，这并不是真正的冗余。
（2）检查业务
检查当前的e-r模型是否满足当前此文来自: 马开东博客
转载请注明出处 网址：
业务的场景。可以从某个实体开始，沿着当前e-r模型的各个节点去模拟业务场景。尤其需要和《需求规格说明书》去做校验。
到这里，也就完成了e-r模型建立的全 ，有时，对于比较复杂的e-r模型，一张图可能显得太过局促，可以建立全局、局部e-r模型图，以便于查看和分析
设计是将概念模型转换成逻辑模型的 ，也就是将e-r图中的实体、关系、属性转化为dbms所支持的的 ，关系型 的为：表。
这个 可以使用一些case，比如：rose、er-win、power designer等。
一、创建表
1.1、实体的描述
在创建实体表的时候，按照e-r模型中实体及实体的属性，一个实体建立一个表，属性作为表的字段。可以参考以下的属性分类，进行详细、必要的实体属性描述。
（1）标识属性
标识实体的属性，如用户实体用户名，如果找不到就自行编号，这是实体完整性所必须的；
（2）一般属性
实体自身的基本属性，如用户实体的密码、联系方式等；
在定义一般属性时，需要注意属性自身的分类，不同的属性分类，结合，可能会产生不一样的表结构设计：
简单属性：由单个元素构成的属性，比如：邮编；
复合属性：由多个元素构成的属性，比如：姓名（first_name、middle_name、last_name）、地址（江苏省南京市玄武区北京东路63#）。
根据业务需要，可以把复合属性拆成多个简单属性，比如：ip（192.168.0.1），就可以用1个bigint、一个处理过的int、或4个tinyint来表示；
单值属性：一行纪录只有一个值的属性，比如：用户实体的身份证号码；
多值属性：一行纪录有多个值的属性，比如：公司实体的电话（567890），每个公司都可能有多个电话，这时，可以将电话属性抽象成一个实体，按照下面1:n的关系来描述，即将公司编号（标识属性）当成电话实体的一般属性；
派生属性：从某个或某几个属性可以派生出来的属性，比如：用户实体的年龄可以从出生日期属性中派生出来，通常派生属性不是必须的。但有时也可以一用，比如：地址字段比较长，如果想要对其进行检索，建立索引的话太宠大，这时可以派生search_code属性，比如：用地址的汉字首字母、五笔码等；
（3）分类属性
实体的分类，可以理解成特殊的一般属性，如用户实体性别属性，可分为男、女；
（4）瞬态属性
实体在某个瞬间或某个时间段内的属性值，也可以理解成特殊的一般属性。
瞬态属性与事实的关系非常诡异，关于事实的概念在下面会讲到。
a)、在事实中一定要注意瞬态属性的记载，比如：商品的单价，在商品销售纪录中需要记载，因为单价是会变的，应该记载售出时的单价；
b)、有的时候，需要单独的事实来记载实体瞬态属性的变化 ，比如：1号单价
为1元、2 号变为1.5元、3号变为1.2元（也许一天内就会有多次变化），而不是到当
天的商品销售事实表中去翻查当天的销售单价；
c)、有的时候事实此文来自: 马开东博客
转载请注明出处 网址：
发生了，会带来实体的瞬态的变化，比如：商品销售事实会影响，商品的最后售出时间、最新累计销售量等属性；
（5）行集属性
行集，顾名思义，就是多行。通常，行集属性用于表达多对多关系的属性，如用户和角色关系，有一个权限属性列表；
（6）关联属性
同样，关联属性也用于描述多对多的关系，但这里的关系通常没有属性，关联属性用来描述实体与实体间发生关系的状态，这样在对实体进行删除的时候，就可以避免到事实表中去检查实体有无被使用。因为被使用的实体是不能被物理删除的，会破坏实体的参照完整性（可通过外键实现参照完整性）。
通常，不对中已与其他实体发生关系的实体的某行进行物理地删除，只是进行逻辑删除：改变其分类属性，如：是否已删除(is_deleted)、状态(status)；
如果用户新建的实体与已被逻辑删除的实体重名时，可以给出页面提示，是否&激活&已存在的实体，当然，也可以不作提示直接新建，通常情况下，影响不大。
1.2、关系的描述
关系不同于实体（一个实体一个表），通常，只有多对多的关系才需要建立一个表。对于关系的多样性，如何对关系进行设计：
（1）1:1的关系(一对一)
1对1的关系最为复杂，通常不需要建立关系表，那么实体间的关系如何建立？
首先，看一下什么是强实体、弱实体？
强实体：不依赖其他实体主键的实体；
弱实体：依赖其他一个或多个实体主键的实体；
以用户与汽车实体为例：
a)，那么用户是弱实体，汽车是强实体，此时将汽车的标识属性作为用户的一般属性存放；
b)，这时用户、汽车都为弱实体，那么，此时可以考虑将两个实体合并为一个实体，因为双方必须为1:1的关系，不可能出现1:0的关系，当然并不一定非要合并实体，详见《 设计（4）_设计_常用技巧》中，关于使用实体还是使用属性的分析；
c) 如果每个用户不一定配车，而汽车也一定配给某用户，这时父子关系的建立是随意的，无论是用户引用汽车编号、还是汽车引用用户编号，作为自己的一般属性都是可以的。
（2）1:n的关系（一对多）
在n方的实体中用一般属性来刻画1方的实体的标识属性，比如：一个用户可以在银行开多个账户，账户实体中就包含着用户的身份证号（用户的标识属性）；
（3）m:n的关系（多对多）
这时需要建立一个关系表，比如：用户与角色，无法将关系属性作为某个实体的属性存放。上面的行集属性、关联属性就是对实体多对多关系的描述。
1.3、数据完整性
数据完整性通过约束来实现，在前面的e-r模型中已进行了的初步定义，这里是把键和域的定义落实到表中。通常约束在创建实体、关系表的时候一并建立。
数据完整性可分为以下几种：
（1）实体完整性
主键约束用于实现实体完整性，它用于标识一个实体（标识属性），不可以为null，对于可为null的唯一属性，可定义成唯一键；
（2）参照完整性
外键约束用于实现参照完整性，以保持主从表之间的。当然，也可以通过关联属性或等方式来实现参照完整性；
（3）用户定义完整性
有时，也叫做。因为用户定义完整性基本是源于的，通常包括：unique约束、check约束、null约束。
在ansi-sql中，主键、外键、唯一健、check、null被定义为5个基本的约束，但有的dbms中（比如 ，在sysconstraints中可查看到），将默认值定义为约束，null却不作为约束，当然这也没什么好去争议，只是dbms的实现方式而已。
在这些约束当中，有些是列级的约束，即只能对单列定义，比如：null约束、check约束，有些既可以是列级约束也可以是表级约束，即可以对单列定义，也可以对多列定义，比如：主键、外键、唯一键约束
回头看一下数据模型的三要素：、数据操作、数据完整性，不难发现，数据操作尚未得到体现，而事实就是实体或关系属性的变化、以及中以实体和关系为基础展开的业务 的纪录。也就是数据操作的纪录。
对于事实的发现，可以参考概要设计阶段的。
事实分可简单分为日志和业务事实，像记叙文一样，事实至少要包括六要素：时间、地点、人物、事情的起因、经过、结果，表示什么时间、什么人、在哪里，干了什么事。
是指自身运行状况的纪录，与业务不相干（做法类似的日志），所以，有时日志的事实是可选的。但如果记录这样的事实，对于做用户行为分析、以及自我的改进是很有意义的。
（1）正常：日常事务的纪录，比如登入、退出；
（2）警告：非正常操作的记录，比如非正常退出、数据越界操作；
（3）错误：记录错误事件的发生（程序名、错误内容），有时，错误级别很高的时候，比如，程序直接崩溃，这时错误日志往往只能到程序后台去查看了；
（2）业务事实
是指业务数据的纪录，对业务事实的发现，可采用如下步骤：
（1）对业务类型进行分类：大类（比如：到银行存款）、小类（比如：开户、发卡）；
（2）对业务类型下的业务操作进行分类，行成业务事实（比如：开户纪录）；
（3）对业务事实的信息进行汇总，以作业务统计和决策分析，这里严格来讲已经不是真正的事实了，而是一种统计 。
二、检查表结构
2.1、规范性检查
规范性检查，通过范式来进行，范式很多，有1，2，3，4，5，bc范式等，通常只需要检查1，2，3范式即可。
第一范式：是对属性（表中字段）单值的约束，要求一个属性不可对应多个值，也就是上面提到的单值属性，如果遇到多值属性，则需要将其抽象成一个实体，上面已经讲过；
第二范式：是对纪录（表中行）唯一性的约束，要求能够唯一标识一行纪录，无论是通过单列，还是多列来建立主键或唯一键，很多时候找不到能唯一标识实体的属性，那么就会建一个xxx_id的列来实现；
第三范式：是对表中数据冗余的约束，要求单表中不存在派生属性，多个表中不存在相同非主键属性值，也就是说其他表中用于关联当前实体的主键属性列不算是冗余。
3范式，归纳下来就是：属性单值、纪录唯一、数据无冗余，完全符合3范式的设计通常不存在，尤其是数据冗余，有时根据业务或性能的需要，会故意做一些冗余，只要注意保持冗余数据与源也是可以的，把握好度即可。
另外，满足第2范式的要求是必须满足第1范式，依次类推。
再补充以前老师的一句话： 设计要做到不重、不漏。我的理解是：不重是指避免数据冗余，不漏是指要以e-r模型为基础，否则凭空想象需要哪几个表，难免会有疏漏，甚至错误。
2.2、可用性检查
可用性检查，就是看表结构能否满足业务场景及（约束）。那么如何检查呢？
这项检查工作是个跨度比较大的 ，参考《工程 - 5、 设计与开发》会发现， 设计不是一蹴而就的，而是在需求分析阶段建立e-r模型，在概要设计、详细设计阶段逐步细化、落实的一个 ，随着项目推进而去不断地完善并实现，这就是最好的可用性检查。
最后，概念结构设计、设计的结果都并不是唯一的。只要简单（实体个体不多、关系清晰、属性不冗余）、符合业务需要，都是合理的设计。
下面列出了在项目开发 中，经常遇到的 设计模块。
一、常用实体1.1、全局实体（1）独立参数记录中独立存在的参数，通常使用整形和字符型即可兼顾所有常用类型的参数。
结构如下：
参数编号&参数名称/代码&参数值整形&参数值字符型1&首页标语&0&我爱北京天安门2&无操作自动退出时长&10&n/a&&&&&&&
注：n/a意为不可用（not available），如果觉得不习惯可用null，在《 设计（4）_设计_常用技巧》会讲到关于null值与默认值的问题。
（2）序号申请用于实体编号、事实编号等的唯一序号申请，对于oltp中，事务并发量较大的时候，使用这种方式来申请事实编号，可能会带来blocking，可以使用 的标识列、或oracle的sequence以标识事实，来代替手动序号申请。
有效日期字段用于第二天序号重新置为1的情况，在申请序号时，需要加一个有效日期与当前日期比较的逻辑。
结构如下：
序号&序号代码&下一序号值&有效日期1&next_user_id&3&n/a2&next_fact_id&888&&&&&&&&
（3）消息中各种提示、错误等的定义，比如：弹出的提示或错误框里的文本。
0、30是 中对语言的编号，0为英语，30为，是否记日志是指此文来自: 马开东博客
转载请注明出处 网址：
：当前消息是否存储为日志，即上一节里事实分中的日志；错误级别在一般的中通常不需要，可以省略。
结构如下：
消息编号&语言编号&消息文本&是否记日志&错误级别1&0&username or pass
error&1&32&30&用户名或密码错误&1&3&&&&&&&&
（4）字典有时，还会出现与业务无关的一些公共实体，比如：国家、民族、省、市、某某类型等，通常由于太多，不方便写在程序里，所以放到表中，在查询时根据id关联下即可。
对于大型平台，这部分公共信息通常为多个子所用，会将它们单独存放，比如：登录、权限相关的实体，一起放在一台上，作为公共或身份认证。这种情况，不一定是关系型，比如：windows的目录服务就是树状的；物理存储也不一定在磁盘上，比如：memcache、都是将数据存放在内存中。
1.2、权限实体目前的权限控制多采用基于角色的访问控制（rbac），有时也会结合物理位置，如：mac地址、ip等。
（1）子一个大型的平台，通过一个入口进去后可能有多个子，那么每个子就应该独立管理起来。
结构如下：
编号&版本&图标&背景图片&菜单风格&是否放栏&&1&1.0.0.1&/&/&/&/&winxp&0&&2&2.3.0.1&/&/&/&/&vista&1&&&&&&&&&&&&&&&
（2）菜单以下菜单属性只是ui方面的，还要有菜单对应的页面：c/s方式的dll、formname，b/s方式的url都要设计进来。最后菜单属于某个子。
结构如下：
菜单编号&菜单名称&热键&加速键&是否分组&是否分隔&是否栏显示&按钮图标&按钮提示&微帮助&子&&1&查询&f8&q&0&1&1&/&/&查询&查询 &1&&2&删除&f9&d&1&0&0&/&/&删除&删除数据&1&&&&&&&&&&&&&&&&&&&&
（3）页面元素页面元素，即页面每个控件来定义，在控制权限时，简单的做法就是根据角色权限配置把页面上的控件隐藏掉。最后控件属于某个菜单页面。
结构如下：
控件编号&控件名称&事件&菜单编号&&1&edt_text&chk_username.do&10&&2&btn_user&sav_userinfo.dll&10&&&&&&&&&&&
（4）数据内容数据权限的控制比较麻烦，通常数据集以表格的形式来展示，表格也是个页面控件（这里是一个特化/泛化的设计，在页面元素实体中也存在数据集展示的控件，单独将数据集相关的属性抽了出来作为一个实体），通过定义这个控件所展示的数据列清单，及行的范围来控制数据权限。
中文列表示表格的列名、英文名表示所查询的 中的表字段，行表示用于控制范围的字段：user_id表示只显示当前用户编号的数据（我们知道在事实中会记载操作员编号），空表示显示所有数据，即所有用户看到的数据是一样的。
结构如下：
数据集编号&控件编号&中文列&英文列&行&&1&20&列1,列2,列3&col1,col2,col3&user_id&&2&21&列1,列2,列3&col1,col2,col3&&&&&&&&&&&&&&
（5）用户这里的用户包括业务用户、管理员。业务用户：使用中的业务功能；管理员：对进行管理，不一定使用中的业务功能；
对于业务用户和管理员，根据的可以作为一个实体，也可以进行特化/泛化作为两个实体来处理。如果作为一个实体对于实现单点登录更为方便些。如果作为两个实体则通常需要两个登录入口。下面是作为一个实体的情况。
结构如下：
用户编号&用户名称&用户密码&创建时间&上次登录时间&登录次数&&abc&张六子&密文& 00:11:22& 11:22:33&2&&admin&王二小&密文& 22:33:44& 22:33:44&10&&&&&&&&&&&&&&&
如果中有用户账户存在的话，应该独立管理，而不应该和用户实体混为一谈。这里可能会遇到用户名/密码的问题，用户登录究竟是以用户编号/用户密码，还是用账户编号/账户密码，这两种其实都有，比如：目前的网上银行，有的银行使用前者，有的银行使用后者。用户编号/用户密码：用户的身份证号+用户密码来登录；账户编号/账户密码：当前账户的卡号+账户密码来登录；
需要注意的是，在 中的密码一定要存储为密文，通常使用不可逆加密算法，在验证密码的时候，使用同样的算法将明文加密成密文，与 中的密文进行比较即可，但这种 不太安全，有可能会出现在密文传输 中被捕获，进而出现模拟用户发包以通过验证的情况，所以银行方面通常会使用不对称加密算法，使用公钥和私钥以保证安全，这里不再赘述。
结构如下：
角色编号&角色名称&&1&财务&&2&销售&3&管理员&&&&&&&
（7）权限权限实体是可选的，可以直接把权限列表配置给角色，这里把权限定义好，然后指派给角色。
权限里只配置控件编号，子、菜单、数据集编号可以关联获得。
结构如下：
权限编号&控件编号&&1&1&&2&2&&3&100&3&101&&&&&&
（8）角色权限在权限配置的时候可以配置多个小的权限，一个角色可以拥有多个权限，角色的总权限为所有权限的并集。
结构如下：
角色编号&权限编号&&1&1&&1&2&2&2&&&&&&&
（9）用户角色一个用户可以拥有多个角色，用户的总权限为所有角色权限的并集。
结构如下：
用户编号&角色编号&&abc&1&&abc&2&&admin&3&&&&&&&
有的中还会有这样的功能：用户组（给用户组分配权限，新加入组的用户直接拥有组的权限）、新建的用户从已存在的用户复制角色权限，这里不一一列举，其实权限有时真没必要做那么复杂，配置起来会很麻烦的。
二、树型结构计算机世界里有很多种：链表、树、图等等，每种都有其优点，有时同样需要在 中实现这样的结构。比如：树形结构的可扩展性。
下面以windows的开始菜单为例，看下树形结构的设计。（1）整形使用整形编号，标识父子关系。想要得到某节点的所有父节点，或所有子节点，使用 实现递归即可，比如：自定义函数，或者使用cte。
结构如下：
菜单编号&菜单名称&父亲&节点深度&&1&开始&0&1&&2&程序&1&2&&3&设置&1&2&&4&控制面板&3&3&&&&&&&&&&&
（2）字符型使用字符串编号，标识父子关系。想要遍历父子节点，根据前缀全用模糊查询即可，缺点在于：变动某个中间节点的位置时，需要变更节点自身及其所有子节点的编号，维护起来不太方便。
结构如下：
菜单编号&菜单名称&节点深度&&001&开始&1&&00101&程序&2&&00102&设置&2&&0010201&控制面板&3&&&&&&&&&
三、（1）语言首先对语言进行编号，作为列表，在用户登录入口供用户选择。
结构如下：
语言编号&语言名称&&0&english &&28&繁體中文&&30&&&&&&&&
（2）名字空间域对中所有名称存放多个语言的版本，比如：菜单名。
结构如下：
名字_语言_编号&名字编号&语言编号&名字1&1&0&query2&1&30&查询&&&&&&&
（3）实体表在实体表中仅使用（2）中的名字编号，没有名称，结合用户登入时的语言编号以得到相应语言的名字。
结构如下：
菜单编号&热键&加速键&是否分组&是否分隔&是否栏显示&&1&f8&q&0&1&1&&2&f9&d&1&0&0&&&&&&&&&&&&&
四、不改变现有的结构扩展（1）扩展现有表的字段通常情况下，可以用特化/泛化来扩展实体表的属性。以用户实体为例。
原结构如下：用户编号&用户名称&&abc&张三&&efg&李四&&&&&&&
现需要在这些用户中标识一部分销售，也就是在概念结构设计中的例子。
扩展的结构如下：
用户编号&负责区域&&abc&southeast&&&&&&&
那是不是随着中的开展，逐渐地去建立很多的扩展表呢？也可以用一个表，这样建：
用户编号&属性&属性值&&abc&性别&男&&abc&负责区域&southeast&efg&性别&男&efg&负责区域&all&&&&&&&&
但如果实体的数据量很大时，这样的方式进行行列转换的成本还是比较大的。所以甚用。
（2）扩展新的实体扩展新的实体，通常无法做到完全通用，只能针对某一固定行业，在按照属性分类定义了基本的表结构后，进行扩展，比如：
这里统一存放所有实体的名字空间，每一棵树代表一个实体。树编号&节点编号&名称&父亲&&1&1&属性1&0&&1&2&属性2&1&&1&3&属性3&1&&&&&&&&&&&100&1000&属性1&0&&100&1001&属性2&100&&100&1002&属性3&100&&&&&&&&&&&
每一类型的实体对应着自己的属性表：实体编号&节点编号&列1&列2&列3&&1&1&1&a&abc&&1&2&2&b&efg&&1&3&3&c&hij&&&&&&&&&&&&&100&1000&4&x&abcd&&100&1001&5&y&efgh&&100&1002&6&z&hijk&&&&&&&&&&&&&
这样的属性表有很多张，对应着各种可能出现的实体类型，这样在进行每种类型的实体扩展时，只需要在表中配置数据，就可以实现实体的扩展，当然，前提是要对行业有相当的理解。
总结一下这些年在项目中一些设计技巧，有些在前面的章节已经提到过。
一、属性定义
1.1、数据类型
（1）整型还是字符型
在可以为整型的情况下尽量使用整型，通常情况下整型占的空间小，可以提高i/o及缓存命中率。
）定长还是变长字符型
定长的好处（也就是变长的坏处）：
a)定长字段不需要额外维护和计算行偏移量，当然这个成本不是很大，可以忽略；
b)如果用变长的话，很有可能会由于更新行数据而带来页拆分，这个成本是很大的；
变长的好处：
节省存储空间，可以提高i/o及缓存命中率；
那究竟使用定长还是变长呢？规则就是：同一属性列的数据长度有明显差异、且更新不太频繁的情况，使用变长字符，否则建议使用定长字符，比如：订单号、mac地址，这类长度固定的属性应该毫不犹豫地使用定长。
（3）数据类型的长度
业务的发展总是会出乎人为意料的，所以不要太小气，在长度不是太大的情况下，大胆去放大数据类型的长度，比如：把smallint（占2字节）改为int（占4字节）。
（4）数据类型
避免出现：同一个字段，在a表中为整型，在b表中为字符型，保证数据类型的一致。
建议将所有列都设为not null，原因如下：
（1）记录中存在允许为null的列时，每次都在读取该行时都需要去检查null列是否有值；
（2）索引中不会记录null值，因为这个值根本不存在，所有无论单表还是多表的查询中，is null/is not null无法使用索引，关于索引的使用可参见《
查询优化（3）_索引的设计与使用》；
（3）null值无法进行比较运算（比如：单表查询时id=1/id&&1都得不到id为null的行，多表关联时null与null也是无法对等的）、数学运算、连接运算等，当然可以通过设置一些选项来改变null的运算行为；
（4）null值除了增加程序处理的逻辑外，还有可能在聚合运算中导致bug，比如：count()和avg()，count(col1)如果col1存在null值，则得到的是非null值的行数，avg()也一样，用count(*)或count(col2)，假设col2不可为空，可以得到真实的行数；
那么对于属性列不确定的时候怎么办呢？答案就是：使用默认值，比如整型为0，字符使用
n/a或n/v，时间使用 00:00:00，这样以避免null值的使用。
另外，对于布尔型的0、1尽量保持逻辑一致，如：0为false，1为true。
dbms中之所以引入null，只是为了完善数学模型，即3值逻辑，这个有点像cross join。
1.3、fk（外键）
为保证实体完整性，也就是第2范式，表中主键或唯一键是一定要有的，否则就可能出现重复纪录。那么外键呢？
通常矛盾在于：参照完整性及实现参照完整性的性能问题。
（1）用外键实现参照完整性，保证；
（2）海量数据的情况下，参照完整性检查的成本很大；
究竟怎么使用外键呢？对于海量数据的情况，为保证dml的效率，不建议使用外键，参照完整性可以使用after或关联属性来实现；反之就是在不影响性能、或对性能要求不高的情况下使用外键。
1.4、check
check约束用于检查域完整性，不建议使用，检查工作完全可以放到界面上去做，比如：java里的，多么强大。
目前，能够想到的不得不用check约束的地方就是分区视图，但分区视图是 没有分区表的时候，一个替代品，所以有了分区表就再也没有使用check约束的理由了。
二、实体、关系表
（1）简单属性还是复合属性
举个例子：银行卡号一个长串，第一反应，它应该是一个字符串，但其实，银行卡号通常只有后四位才是唯一标识，前面都是银行编号+开户行等信息，那么这样完全可以把银行卡号作为多个整型值来存储。这要取决于；
再比如前面提到过的姓名，如果需要国际化时，姓名就要考虑firstname、middlename、lastname字段，而不能像中国人一样直接就是一个name字段；
（2）是否真的是多值属性
前面提到过多值属性需要单独抽象成实体，但有时，需要辨别是否真的是多值属性，比如：用户实体的地址、机器实体的所有元器件列表、 实体的所有章节，它们都是单值的复合属性；
（3）备注或者描述
数据表设计应该越简洁越好，像备注或者描述（remark/description）这样的字段，如果可有可无时，最好省掉：一是没有人真正地去维护它，二是占存储空间；
（4）实体还是属性
举个例子：《 设计（2）_设计》中1:1关系里的用户与汽车。
a)中对于汽车的属性不作限制，只需要知道汽车编号即可，e-r模型如下图：
&此时可以将用户与汽车实体合并为一个用户实体，
模型如下图：
b) 如果中对于汽车的属性需要作出描述，比如：产地等，e-r模型如下图：
&那么此时就不能实体进行合并，应该独立描述用户、汽车实体。
（1）字典的使用
实体表中的状态、类型等属性，如果不是太多，不需要做成字典表。另外、经常变化的元数据不宜作为字典，因为字典这些信息通常会加载在cache中，如果经常变，那就意味着需要经常去更新cache。
（2）中有哪些用户
通常需要存在四种用户：管理员（全部读写权限）、业务操作用户（部分读写权限）、 查询用户（只读权限）、测试用户（部分读写权限），测试用户通常供开发使用，往往在上线后，需要在线修改一些问题，测试用户产生的数据，不计入业务数据范围；
（3）大写还是小写
默认oracle把所有 对象大写，如果想指定成小写或大小写混写，需要用""，但这样带来的问题就是在引用这个对象时也要加上""，很不方便，所以索性全用大写，这对于异构 的互相访问很有帮助，比如：从oracle访问 ；
另外，在作字符等值比较时，最好使用upper/lower函数将两端的字符全转换成大写/小写再作比较；
在后面会分别给出 和oracle 的命名和开发规范，
（4）实体行如何删除
不允许对已发生事实、或建立关系的实体行进行物理删除，会破坏实体的参照完整性，即使是没有发生事实、或建立关系的实体行，通常也不进行物理删除，只是逻辑删除；
（5）兼容b/s和c/s开发方式
设计实体时要考虑到b/s和c/s开发方式的元素，比如：c/s方式中的dll、formname、根据b/s的使用一些新型的数据类型，比如：xml类型；
（6）数据权限
除了管理员有所有数据权限外，数据权限原则上是谁产生的数据谁有权限；
（7）如何进行数据同步
数据同步有推、拉两种方式。
推的方式：在数据发生变化后，立即发出通知给需要更新的点；
拉的方式：由定时任务，定时去数据源作增量检查，这种方式就需要在表中建立一个标识增量变化的属性，比如：时间戳；
（8）不能为了技术而技术
举个例子：用户申请编号时，发起申请编号的事务，事务完成时显示：您申请到的编号为xxx。
但如果并发量较大，即便是采用 自身的序号生成方式（identity或sequence），仍然会存在等待，那么，就可以考虑从客户端生成此次事务的唯一编号，到 层没有申请编号的排队 ，直接写入；
（9）实体还是关系
举个例子：《 设计（3）_设计_常用模块》中权限实体里的角色、权限、控件。
a)如果不使用权限实体，此时权限通过关系来描述，e-r模型如下图：
b)如果使用权限实体，此时权限以实体来描述，e-r模型如下图：
这两种方式都是可以的，但需要注意的是：一要避免由于实体或关系带来的数据多次存储，浪费存储空间；二要保证；
再重复一次：概念结构设计、设计的结果都不是唯一的。
（1）发现及记载事实
在《 设计（2）_设计》中提到过事实的发现，通常，业务相关的事实，通过查看《需求规格说明书》、与用户直接交谈、自身的行业经验、问卷调查等方式可以获得；
但业务中用不到或者说暂时用不到的事实，是否就不作记载呢？比如：日志等等，建议在不影响性能及 的情况下，记载尽量多的事实，日后，它对于做决策分析等这类事情时，会很有帮助；
（2）事实与
搜索此文相关文章： 设计 概念结构设计以权限为例此文来自: 马开东博客
网址: 站长QQ
数据库设计 概念结构设计以权限系统为例_博客园相关文章
博客园_总排行榜
博客园_最新
博客园_月排行榜
博客园_周排行榜
博客园_日排行榜