对于现在主要的系统来说,一般而言都是管理数据型系统,因此一个系统数据库设计的好坏直接关系到了系统,因此特在此对数据库的设计做一个简单的回顾,希望各位新手,老手们多多指教。好了,废话就不多说了,直接切入主题吧:)
我们知道,数据库的数据模式包含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:一般化: 为高层实体创建表,并为每个低层实体创建一个表。或者直接免去高层实体表。但是,如果一个实体不属于低层的任何一个,则第二种表示无法表达。