引言
数据库的设计范式是数据库设计所需要满的规范Q满些规范的数据库是z的、结构明晰的Q同Ӟ不会发生插入QinsertQ、删?
QdeleteQ和更新QupdateQ操作异常。反之则是ؕ七八p,不仅l数据库的编Eh员制造麻烦,而且面目可憎Q可能存储了大量不需要的冗余信息?br />
设计范式是不是很难懂呢?非也Q大学教材上l我们一堆数学公式我们当然看不懂Q也C住。所以我们很多h根本不按照范式来设计数据库?br />
实质上,设计范式用很形象、很z的话语p说清楚,道明白。本文将对范式进行通俗地说明,q以W者曾l设计的一个简单论坛的数据库ؓ例来讲解怎样这
些范式应用于实际工程?br />
范式说明
W一范式Q?NFQ:数据库表中的字段都是单一属性的Q不可再分。这个单一属?
由基本类型构成,包括整型、实数、字W型、逻辑型、日期型{?br />
例如Q如下的数据库表是符合第一范式的:
字段1 | 字段2 | 字段3 | 字段4 |
字段1 | 字段2 | 字段3 | 字段4 | |
字段3.1 | 字段3.2 |
很显Ӟ在当前的M关系数据库管理系
l(DBMSQ中Q傻瓜也不可能做ZW合W一范式的数据库Q因些DBMS不允怽把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS?
设计ZW合W一范式的数据库都是不可能的?br />
W二范式Q?NFQ:数据库表中不存在非关键字D对M候选关键字D늚部分函数依赖Q部
分函C赖指的是存在l合关键字中的某些字D决定非关键字段的情况)Q也x有非关键字段都完全依赖于L一l候选关键字?/p>
假设仓库理关系表ؓ
StorehouseManage(仓库ID, 存储物品ID, 理员ID,
数量)Q且有一个管理员只在一个仓库工作;一个仓库可以存储多U物品。这个数据库表中存在如下军_关系Q?br />
(仓库ID,
存储物品ID) →(理员ID, 数量)
(理员ID, 存储物品ID) → (仓库ID, 数量)
所以,
(仓库ID, 存储物品ID)?理员ID,
存储物品ID)都是StorehouseManage的候选关键字Q表中的唯一非关键字Dؓ数量Q它是符合第三范式的。但是,׃存在如下军_关系Q?br />
(仓库ID) → (理员ID)
(理员ID) → (仓库ID)
卛_在关键字D决定关键字D늚情况Q所?
其不W合BCNF范式。它会出现如下异常情况:
(1) 删除异常Q?br />
当仓库被清空后,所?存储物品ID"??
?信息被删除的同时Q?仓库ID"?理员ID"信息也被删除了?br />
(2) 插入异常Q?br />
当仓库没有存储Q何物
品时Q无法给仓库分配理员?br />
(3) 更新异常Q?br />
如果仓库换了理员,则表中所有行的管理员ID都要修改?br />
把仓库管理关p表分解Z个关p表Q?br />
仓库理QStorehouseManage(仓库ID, 理员ID)Q?br />
仓库QStorehouse(仓库ID, 存储物品ID, 数量)?br />
q样的数据库表是W合BCNF范式的,消除了删除异常、插入异
常和更新异常?/p>
范式应用
我们来逐步搞定一个论
坛的数据库,有如下信息:
Q?Q?用户Q用户名QemailQ主,电话Q联pd址
Q?Q?
帖子Q发帖标题,发帖内容Q回复标题,回复内容
W一ơ我们将数据库设计ؓ仅仅存在表:
用户?/td> | 主页 | 电话 | 联系地址 | 发帖标题 | 发帖内容 | 回复标题 | 回复内容 |
用户?/td> | 主页 | 电话 | 联系地址 | 发帖ID | 发帖标题 | 发帖内容 | 回复ID | 回复标题 | 回复内容 |
一?nbsp;联系
联系QRelationshipQ是指实体集q间或实体集内部实例之间的连接?br />
实体之间可以通过联系来相互关联。与实体和实体集对应Q联pM可以分ؓ联系和联p集Q联p集是实体集之间的联p,联系是实体之间的联系Q联pLh方向性的。联pd联系集在含义明确的情况之下均可称pR?br />
按照实体cd中实例之间的数量对应关系Q通常可将联系分ؓ4c,即一对一QONE TO ONEQ联pR一对多QONE TO MANYQ联pR多对一QMANY TO ONEQ联pd多对多联p(MANY TO MANYQ?/p>
二?nbsp;建立联系
在CDM工具选项板中除了公共的工具外Q还包括如下图所C的其它对象产生工具?br />
在图形窗口中创徏两个实体后,单击“实体间徏立联p?#8221;工具Q单M个实体,在按下鼠标左键的同时把光标拖臛_一个实体上qN标左键,q样在两个实体间创Z联系Q右键单d形窗口,释放Relationship工具。如下图所C?br />
三?nbsp;四种基本的联p?br />
即一对一QONE TO ONEQ联pR一对多QONE TO MANYQ联pR多对一QMANY TO ONEQ联pd多对多联p(MANY TO MANYQ。如图所C?br />
四?nbsp;其他几类Ҏ联系
除了4U基本的联系之外Q实体集与实体集之间q存在标定联p(Identify RelationshipQ、非标定联系QNon-Identify RelationShipQ和递归联系QRecursive RelationshipQ?br />
标定联系Q?/strong>
每个实体cd都有自己的标识符Q如果两个实体集之间发生联系Q其中一个实体类型的标识W进入另一个实体类型ƈ与该实体cd中的标识W共同组成其标识W时Q这U联pdUCؓ标定联系Q也叫依赖联pR反之称为非标定联系Q也叫非依赖联系?br />
注意Q?br />
在非标定联系中,一个实体集中的部分实例依赖于另一个实例集中的实例Q在q种依赖联系中,每个实体必须臛_有一个标识符。而在标定联系中,一个实体集中的全部实例完全依赖于另个实体集中的实例Q在q种依赖联系中一个实体必至有一个标识符Q而另一个实体却可以没有自己的标识符。没有标识符的实体用它所依赖的实体的标识W作q标识W?/span>
换句话来理解Q在标定联系中,一个实体(选课Q依?一个实体(学生Q,那么Q学生)实体必须臛_有一个标识符Q而(选课Q实体可以没有自q标识W,没有标标识符的实体可以用实体Q学生)的标识符作ؓ自己的标识符?br />
递归联系Q?/strong> 七?nbsp;定义联系的强制?/strong>
递归联系是实体集内部实例之间的一U联p,通常形象地称反联pR同一实体cd中不同实体集之间的联pMUCؓ递归联系?br />
例如Q在“职工”实体集中存在很多的职工,q些职工之间必须存在一U领g被领导的关系。又?#8220;学生”实体信中的实体包?#8220;班长”子实体集?#8220;普通学?#8221;子实体集Q这两个子实体集之间的联pd是一U递归联系。创建递归联系Ӟ只需要单?#8220;实体间徏立联p?#8221;工具从实体的一部分拖至该实体的别一个部分即可。如?br />
五?nbsp;定义联系的特?/strong>
在两个实体间建立了联pdQ双击联pȝQ打开联系Ҏ窗口,如图所C?br />
六?nbsp;定义联系的角色名
在联pȝ两个方向上各自包含有一个分l框Q其中的参数只对q个方向起作用,Role Name色名Q描q该方向联系的作用,一般用一个动词或动宾l表?br />
如:“学生 to 评 ” l框中应该填?#8220;拥有”Q而在“评To 学生”l框中填?#8220;属于”。(在此只是举例说明Q可能有些用词不太合理)?/p>
Mandatory 表洋q个方向联系的强制关pR选中q个复选框Q则在联pȝ上生一个联pȝ垂直的竖Uѝ不选择q个复选框则表Cp这个方向上是可选的Q在联系U上产生一个小圆圈?br />
八?nbsp;有关联系的基?/strong>
联系h方向性,每个方向上都有一个基数?br />
举例Q?br />
“p?#8221;?#8220;学生”两个实体之间的联pL一对多联系Q换句话?#8220;学生”?#8220;p?#8221;之间的联pL多对一联系。而且一个学生必d于一个系Qƈ且只能属于一个系Q不能属于零个系Q所以从“学生”实体?#8220;p?#8221;实体的基Cؓ“1,1”Q从联系的另一方向考虑Q一个系可以拥有多个学生Q也可以没有M学生Q即零个学生Q所以该方向联系的基数就?#8220;0,n”,如图所C?br />
待箋?/p>
]]>
3Q选择"Attributes"选项卡,再点?#8220;Add Attributes”工具Q弹出如图所C窗口,选择某个属性作为标识符p了?br />
待箋?br />
参数 | 说明 |
Minimum | 属性可接受的最数 |
Maximum | 属性可接受的最大数 |
Default | 属性不赋值时Q系l提供的默认?/td> |
Unit | 单位Q如公里、吨、元 |
Format | 属性的数据昄格式 |
Lowercase | 属性的赋值全部变为小写字?/td> |
Uppercase | 属性的赋值全部变为大写字?/td> |
Cannot modify | 该属性一旦赋g能再修改 |
List Of Values | 属性赋值列表,除列表中的|不能有其他的?/td> |
Label | 属性列表值的标签 |
2Q在上图所C窗口中Q点L入属性按钮,弹出属性对话框Q如下图所C?br />
注意Q这里涉及到域的概念Q即一U标准的数据l构Q它可应用至数据Ҏ实体的属性上。在以下的教E中另立章节详l说明?br />
待箋?br />