对于现在主要的系统来说，一般而言都是管理数据型系统，因此一个系统数据库设计的好坏直接关系到了系统，因此特在此对数据库的设计做一个简单的回顾，希望各位新手，老手们多多指教。好了，废话就不多说了，直接切入主题吧：）
我们知道，数据库的数据模式包含2种模式
1：概念模式（ER图表示）
2：逻辑模式（关系表）
因此，在做好了系统的需求以后，就应该开始着手数据库的设计了。
首先，根据根据需求文档寻找名词，评定系统中的逻辑实体，提取出数据库设计中的实体。
其次，根据所提取的逻辑实体画出数据库设计中的ER图。
再次，把ER图转换成你的DataBaseS????.
第一点我就不说了，偶目前的水平还未达到收集需求的层次。：）
概念模型（领域建模）E-R图
1：实体：实体是现实世界中可区别于其他对象的“事件”或者“物体”。例如：企业中的每个人都是一个实体。每个实体还具有一组性质，其中一部分的性质可以唯一标识实体。
实体可是实实在在存在的，或者是抽象的概念。
2，属性：实体的性质。其中特殊的属性有：复合属性和多值属性。
复合属性：可划分的属性。比如：人的地址这一属性，还可划分成街道，门牌号等属性。
多值属性：多个值的属性。比如: 人的亲戚，可以有好几个。
派生属性：通过别的属性推倒出来的。比如：根据当前的日期和人的出生日期，可以推算他的年龄
3：联系：指的是多个实体之间的相互关联。其中，联系也可以具有属性。
实体Or属性的选择：
1: 属性不能再具有需要描述的性质。
1: 属性不能具有与其他实体的联系。
比如：在部门表中，人是作为属性还是字段。如果将人作为属性字段，则如果还需要人的地址和电话属性的话，将其作为属性就是不好的，应该另作为一个实体来存储。
实体Or联系的选择：
1：是否反映了真实的业务逻辑。
2：是否会增加系统的空间开销（）
3：是否容易会导致系统数据的不一致性。
比如，顾客----（贷款）----银行 如果此时一个顾客贷多笔款，多个顾客贷一笔款，则作为联系的贷款会出现重复或者容易导致数据的不一致性。
顾客----（借）---贷款---（属于）银行 其中，（）里面的表示联系。
将ER图转换成表：
1：用表表示强实体集，每个属性分别作为一个字段。
2：用表表示弱实体集，注意，弱实体集的属性还要多一个字段：与它关联的那个强实体集的主码。
3：用表表示联系集，把参与联系的每个实体集的主码作为联系集表的主码。注意实体之间如果是多对1的关系的话，且A，B2个实体之间存在依赖，A依赖于B ，则可将A与AB之间的联系集合成一张表。
因为这样不会导致空值出现的状况。
4：复合属性，有几个属性，表追加几列。
5：多值属性：创建新表，并把多值属性的那个实体的主码表作为此新表的追加列。
6：一般化： 为高层实体创建表，并为每个低层实体创建一个表。或者直接免去高层实体表。但是，如果一个实体不属于低层的任何一个，则第二种表示无法表达。