??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲avav天堂av在线不卡,77777亚洲午夜久久多喷,亚洲av无码专区国产不乱码http://m.tkk7.com/ashutc/archive/2011/05/10/349926.html西瓜西瓜Tue, 10 May 2011 09:12:00 GMThttp://m.tkk7.com/ashutc/archive/2011/05/10/349926.htmlhttp://m.tkk7.com/ashutc/comments/349926.htmlhttp://m.tkk7.com/ashutc/archive/2011/05/10/349926.html#Feedback0http://m.tkk7.com/ashutc/comments/commentRss/349926.htmlhttp://m.tkk7.com/ashutc/services/trackbacks/349926.html

(1)不应针对整个pȝq行数据库设计,而应该根据系l架构中的组件划分,针对每个lg所处理的业务进行组件单元的数据库设计;不同lg间所对应? 数据库表之间的关联应可能减,如果不同lg间的表需要外键关联也量不要创徏外键兌Q而只是记录关联表的一个主键,保lg对应的表之间的独立性, 为系l或表结构的重构提供可能性?

(2)采用领域模型驱动的方式和自顶向下的思\q行数据库设计,首先分析pȝ业务Q根据职责定义对象。对象要W合装的特性,保与职责相关的数据 被定义在一个对象之内,q些数据能够完整描q该职责Q不会出现职责描q缺失。ƈ且一个对象有且只有一职责,如果一个对象要负责两个或两个以上的? 责,应进行分拆?

(3)Ҏ建立的领域模型进行数据库表的映射Q此时应参考数据库设计W二范式Q一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属 性,也可以是多个属性的集合Q不论那U方式,都应保关键字能够保证唯一性。在定关键字时Q应保证关键字不会参与业务且不会出现更新异常Q这Ӟ最优解 x案ؓ采用一个自增数值型属性或一个随机字W串作ؓ表的关键字?

(4)׃W一Ҏq的领域模型驱动的方式设计数据库表结构,领域模型中的每一个对象只有一职责,所以对象中的数据项不存在传递依赖,所以,q种思\的数据库表结构设计从一开始即满W三范式Q一个表应满第二范式,且属性间不存在传递依赖?

(5)同样Q由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关p,所以在领域模型中的对象存在d象和从对象之分,从对象是?QN或NQN的角度进一步主对象的业务逻辑Q所以从对象及对象关pLؓ的表及表兌关系不存在删除和插入异常?

(6)在映后得出的数据库表结构中Q应再根据第四范式进行进一步修改,保不存在多g赖。这Ӟ应根据反向工E的思\反馈l领域模型。如果表l? 构中存在多g赖,则证明领域模型中的对象具有至两个以上的职责Q应ҎW一条进行设计修正。第四范式:一个表如果满BCNFQ不应存在多g赖?

(7)在经q分析后认所有的表都满二、三、四范式的情况下Q表和表之间的关联尽量采用弱兌以便于对表字D和表结构的调整和重构。ƈ且,我认? 数据库中的表是用来持久化一个对象实例在特定旉及特定条件下的状态的Q只是一个存储介质,所以,表和表之间也不应用强兌来表qC务(数据间的一? 性)Q这一职责应由pȝ的逻辑层来保证Q这U方式也保了系l对于不正确数据Q脏数据Q的兼容性。当Ӟ从整个系l的角度来说我们q是要尽最大努力确保系 l不会生脏数据Q单从另一个角度来_脏数据的产生在一定程度上也是不可避免的,我们也要保证pȝ对这U情늚定w性。这是一个折中的Ҏ?

(8)应针Ҏ有表的主键和外键建立索引Q有针对性的Q针对一些大数据量和常用索方式)建立l合属性的索引Q提高检索效率。虽然徏立烦引会消耗部 分系l资源,但比较v在检索时搜烦整张表中的数据尤其时表中的数据量较大时所带来的性能影响Q以及无索引时的排序操作所带来的性能影响Q这U方式仍然是? 得提倡的?

(9)量采用存储过E,目前已经有很多技术可以替代存储过E的功能?#8220;对象/关系映射”{,数据一致性的保证攑֜数据库中Q无论对于版本控 制、开发和部v、以及数据库的迁U都会带来很大的影响。但不可否认Q存储过E具有性能上的优势Q所以,当系l可使用的硬件不会得到提升而性能又是非常重要 的质量属性时Q可l过q考虑选用存储q程?

(10)当处理表间的兌U束所付出的代P常常是用性上的代P过了保证不会出C攏V删除、更改异常所付出的代Pq且数据冗余也不是主? 的问题时Q表设计可以不符合四个范式。四个范式确保了不会出现异常Q但也可能由此导致过于纯z的设计Q得表l构难于使用Q所以在设计旉要进行综合判 断,但首先确保符合四个范式,然后再进行精化修正是刚刚q入数据库设计领域时可以采用的最好办法?

(11)设计出的表要h较好的用性,主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧?

(12)设计出的表要可能减数据冗余,保数据的准性,有效的控制冗余有助于提高数据库的性能?















西瓜 2011-05-10 17:12 发表评论
]]>
数据库设计范?/title><link>http://m.tkk7.com/ashutc/archive/2011/05/10/349910.html</link><dc:creator>西瓜</dc:creator><author>西瓜</author><pubDate>Tue, 10 May 2011 05:13:00 GMT</pubDate><guid>http://m.tkk7.com/ashutc/archive/2011/05/10/349910.html</guid><wfw:comment>http://m.tkk7.com/ashutc/comments/349910.html</wfw:comment><comments>http://m.tkk7.com/ashutc/archive/2011/05/10/349910.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://m.tkk7.com/ashutc/comments/commentRss/349910.html</wfw:commentRss><trackback:ping>http://m.tkk7.com/ashutc/services/trackbacks/349910.html</trackback:ping><description><![CDATA[<span style="color: red;">设计范式</span>Q?span style="font-family: Verdana;"><span style="color: #800080;">范式</span>, 数据库设计范?数据库的设计范式Q是W合某一U别的关系模式的集合。构造数据库必须遵@一定的规则。在关系数据库中Q这U规则就是范式。关pL据库? 的关pdL一定的要求Q即满不同的范式。目前关pL据库有六U范式:W一范式Q?NFQ、第二范式(2NFQ、第三范式(3NFQ、第四范? Q?NFQ、第五范式(5NFQ和W六范式Q?NFQ。满x低要求的范式是第一范式Q?NFQ。在W一范式的基上进一步满x多要求的UCؓW二范式 Q?NFQ,其余范式以次cL。一般说来,数据库只需满W三范式Q?NFQ就行了。下面我们D例介l第一范式Q?NFQ、第二范式(2NFQ和W三范式 Q?NFQ? <p class="cnt"><span style="font-family: Verdana;">       在创Z个数据库的过E中Q范化是其转化Z些表的过E,q种Ҏ可以使从数据库得到的l果更加明确。这样可能数据库生重复数据,从而导致创建多? 的表。范化是在识别数据库中的数据元素、关p,以及定义所需的表和各表中的项目这些初始工作之后的一个细化的q程?/span></p> <p class="cnt"><span style="font-family: Verdana;">       下面是范化的一个例? Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25 </span></p> <p class="cnt"><span style="font-family: Verdana;">       如果上面q个表用于保存物品的hQ而你惌删除其中的一个顾客,q时你就必须同时删除一个h根{范化就是要解决q个问题Q你可以这个表化ؓ两个表,一 个用于存储每个顾客和他所买物品的信息Q另一个用于存储每件品和其h格的信息Q这样对其中一个表做添加或删除操作׃会媄响另一个表?br /> <br /> <strong><span style="text-decoration: underline;">关系数据库的几种设计范式介绍</span></strong></span></p> <p><span style="font-family: Verdana;"> </span></p> <p class="cnt"><br /> <strong>1 W一范式Q?NFQ?/strong></p> <p class="cnt">       在Q何一个关pL据库中,W一范式Q?NFQ是对关pL式的基本要求Q不满W一范式Q?NFQ的数据库就不是关系数据库?/p> <p class="cnt">       所谓第一范式Q?NFQ是指数据库表的每一列都是不可分割的基本数据,同一列中不能有多个|卛_体中的某个属性不能有多个值或者不能有重复的属性。如 果出现重复的属性,可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间ؓ一对多关系。在W一范式Q?NFQ中表的每一行只包含一 个实例的信息。例如,对于?-2 中的员工信息表,不能员工信息都攑֜一列中昄Q也不能其中的两列或多列在一列中昄Q员工信息表的每一行只表示一个员工的信息Q一个员工的信息在表 中只出现一ơ。简而言之,W一范式是无重复的列?/p> <p class="cnt"><strong>2 W二范式Q?NFQ?/strong></p> <p class="cnt">       W二范式Q?NFQ是在第一范式Q?NFQ的基础上徏立v来的Q即满W二范式Q?NFQ必d满W一范式Q?NFQ。第二范式(2NFQ要求数据库? 中的每个实例或行必须可以被惟一地区分。ؓ实现区分通常需要ؓ表加上一个列Q以存储各个实例的惟一标识。如?-2 员工信息表中加上了员工编Pemp_idQ列Q因为每个员工的员工~号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称Z关键字或主键、主 码?/p> <p class="cnt">       W二范式Q?NFQ要求实体的属性完全依赖于d键字。所谓完全依赖是指不能存在仅依赖d键字一部分的属性,如果存在Q那么这个属性和d键字的这一? 分应该分d来Ş成一个新的实体,新实体与原实体之间是一对多的关pRؓ实现区分通常需要ؓ表加上一个列Q以存储各个实例的惟一标识。简而言之,W二范式 是非主属性非部分依赖于主关键字?/p> <p class="cnt"><strong>3 W三范式Q?NFQ?/strong></p> <p class="cnt">       满W三范式Q?NFQ必d满W二范式Q?NFQ。简而言之,W三范式Q?NFQ要求一个数据库表中不包含已在其它表中已包含的非d键字信息。例 如,存在一个部门信息表Q其中每个部门有部门~号Qdept_idQ、部门名U、部门简介等信息。那么在?-2的员工信息表中列出部门编号后׃能再? 部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NFQ也应该构徏它,否则׃有大量的数据冗余。简 而言之,W三范式是属性不依赖于其它非d性?</p> <p class="cnt"><span style="font-family: Verdana;"><strong><span style="text-decoration: underline;">数据库设计三大范式应用实例剖?/span></strong> </span></p> <p class="cnt">       数据库的设计范式是数据库设计所需要满的规范Q满些规范的数据库是z的、结构明晰的Q同Ӟ不会发生插入QinsertQ、删除(deleteQ? 和更斎ͼupdateQ操作异常。反之则是ؕ七八p,不仅l数据库的编Eh员制造麻烦,而且面目可憎Q可能存储了大量不需要的冗余信息?<br /> <br /> 设计范式是不是很难懂呢?非也Q大学教材上l我们一堆数学公式我们当然看不懂Q也C住。所以我们很多h根本不按照范式来设计数据库?<br /> <br /> 实质上,设计范式用很形象、很z的话语p说清楚,道明白。本文将对范式进行通俗地说明,q以W者曾l设计的一个简单论坛的数据库ؓ例来讲解怎样这些范式应用于实际工程?<br /> <br /> <strong>   范式说明 </strong><br /> <br /> W一范式Q?NFQ:数据库表中的字段都是单一属性的Q不可再分。这个单一属性由基本cd构成Q包括整型、实数、字W型、逻辑型、日期型{?<br /> <br /> 例如Q如下的数据库表是符合第一范式的: <br /> <br /> </p> <table style="height: 43px;" align="center" border="1" cellpadding="2" cellspacing="0"> <tbody> <tr> <td height="18">字段1 </td> <td>字段2 </td> <td>字段3 </td> <td>字段4 </td> </tr> <tr> <td height="23">   </td> <td>   </td> <td>   </td> <td>   </td> </tr> </tbody> </table> <br /> 而这L数据库表是不W合W一范式的: <br /> <br /> <table style="height: 25px;" align="center" border="1" cellpadding="2" cellspacing="0"> <tbody> <tr> <td>字段1 </td> <td>字段2 </td> <td colspan="2">字段3 </td> <td>字段4 </td> </tr> <tr> <td>   </td> <td>   </td> <td>字段3.1 </td> <td>字段3.2 </td> <td>   </td> </tr> </tbody> </table> <p class="main"><br /> 很显Ӟ在当前的M关系数据库管理系l(DBMSQ中Q傻瓜也不可能做ZW合W一范式的数据库Q因些DBMS不允怽把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的?<br /> <br /> <strong>W二范式Q?NFQ:</strong>数据库表中不存在非关键字D对M候选关键字D늚部分函数依赖Q部分函C赖指的是存在l合关键字中的某些字D决定非关键字段的情况)Q也x有非关键字段都完全依赖于L一l候选关键字?<br /> <br /> 假定选课关系表ؓSelectCourse(学号, 姓名, q龄, 评名称, 成W, 学分)Q关键字为组合关键字(学号, 评名称)Q因为存在如下决定关p: <br /> <br /> (学号, 评名称) → (姓名, q龄, 成W, 学分) <br /> <br /> q个数据库表不满第二范式,因ؓ存在如下军_关系Q?<br /> <br /> (评名称) → (学分) <br /> <br /> (学号) → (姓名, q龄) <br /> <br /> 卛_在组合关键字中的字段军_非关键字的情c?<br /> <br /> ׃不符?NFQ这个选课关系表会存在如下问题Q?<br /> <br /> (1) 数据冗余Q?<br /> <br /> 同一门课E由n个学生选修Q?学分"重复n-1ơ;同一个学生选修了m门课E,姓名和年龄就重复了m-1ơ?<br /> <br /> (2) 更新异常Q?<br /> <br /> 若调整了某门评的学分,数据表中所有行?学分"值都要更斎ͼ否则会出现同一门课E学分不同的情况?<br /> <br /> (3) 插入异常Q?<br /> <br /> 假设要开设一门新的课E,暂时q没有h选修。这P׃q没?学号"关键字,评名称和学分也无法记录入数据库?<br /> <br /> (4) 删除异常Q?<br /> <br /> 假设一批学生已l完成课E的选修Q这些选修记录应该从数据库表中删除。但是,与此同时Q课E名U和学分信息也被删除了。很昄Q这也会D插入异常?<br /> <br /> 把选课关系表SelectCourse改ؓ如下三个表: <br /> <br /> 学生QStudent(学号, 姓名, q龄)Q?<br /> <br /> 评QCourse(评名称, 学分)Q?<br /> <br /> 选课关系QSelectCourse(学号, 评名称, 成W)?<br /> <br /> q样的数据库表是W合W二范式的, 消除了数据冗余、更新异常、插入异常和删除异常?<br /> <br /> 另外Q所有单关键字的数据库表都符合第二范式,因ؓ不可能存在组合关键字?<br /> <br /> <strong>W三范式Q?NFQ:</strong>在第二范式的基础上,数据表中如果不存在非关键字段对Q一候选关键字D늚传递函C赖则W合W三范式。所谓传递函C赖,指的是如果存?A → B → C"的决定关p,则C传递函C赖于A。因此,满W三范式的数据库表应该不存在如下依赖关系Q?<br /> <br /> 关键字段 → 非关键字Dx → 非关键字Dy <br /> <br /> 假定学生关系表ؓStudent(学号, 姓名, q龄, 所在学? 学院地点, 学院电话)Q关键字为单一关键?学号"Q因为存在如下决定关p: <br /> <br /> (学号) → (姓名, q龄, 所在学? 学院地点, 学院电话) <br /> <br /> q个数据库是W合2NF的,但是不符?NFQ因为存在如下决定关p: <br /> <br /> (学号) → (所在学? → (学院地点, 学院电话) <br /> <br /> 卛_在非关键字段"学院地点"?学院电话"对关键字D?学号"的传递函C赖?<br /> <br /> 它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知?<br /> <br /> 把学生关p表分ؓ如下两个表: <br /> <br /> 学生Q?学号, 姓名, q龄, 所在学?Q?<br /> <br /> 学院Q?学院, 地点, 电话)?<br /> <br /> q样的数据库表是W合W三范式的,消除了数据冗余、更新异常、插入异常和删除异常?<br /> <br /> <strong>鲍依?U得范式QBCNFQ:</strong>在第三范式的基础上,数据库表中如果不存在M字段对Q一候选关键字D늚传递函C赖则W合W三范式?<br /> <br /> 假设仓库理关系表ؓStorehouseManage(仓库ID, 存储物品ID, 理员ID, 数量)Q且有一个管理员只在一个仓库工作;一个仓库可以存储多U物品。这个数据库表中存在如下军_关系Q?<br /> <br /> (仓库ID, 存储物品ID) →(理员ID, 数量) <br /> <br /> (理员ID, 存储物品ID) → (仓库ID, 数量) <br /> <br /> 所以,(仓库ID, 存储物品ID)?理员ID, 存储物品ID)都是StorehouseManage的候选关键字Q表中的唯一非关键字Dؓ数量Q它是符合第三范式的。但是,׃存在如下军_关系Q?<br /> <br /> (仓库ID) → (理员ID) <br /> <br /> (理员ID) → (仓库ID) <br /> <br /> 卛_在关键字D决定关键字D늚情况Q所以其不符合BCNF范式。它会出现如下异常情况: <br /> <br /> (1) 删除异常Q?<br /> <br /> 当仓库被清空后,所?存储物品ID"?数量"信息被删除的同时Q?仓库ID"?理员ID"信息也被删除了?<br /> <br /> (2) 插入异常Q?<br /> <br /> 当仓库没有存储Q何物品时Q无法给仓库分配理员?<br /> <br /> (3) 更新异常Q?<br /> <br /> 如果仓库换了理员,则表中所有行的管理员ID都要修改?<br /> <br /> 把仓库管理关p表分解Z个关p表Q?<br /> <br /> 仓库理QStorehouseManage(仓库ID, 理员ID)Q?<br /> <br /> 仓库QStorehouse(仓库ID, 存储物品ID, 数量)?<br /> <br /> q样的数据库表是W合BCNF范式的,消除了删除异常、插入异常和更新异常?</p> <p class="cnt"><strong>   范式应用 </strong><br /> <br /> 我们来逐步搞定一个论坛的数据库,有如下信息: <br /> <br /> Q?Q?用户Q用户名QemailQ主,电话Q联pd址 <br /> <br /> Q?Q?帖子Q发帖标题,发帖内容Q回复标题,回复内容 <br /> <br /> W一ơ我们将数据库设计ؓ仅仅存在表:</p> <p class="cnt"> </p> <table style="height: 25px;" align="center" border="1" cellpadding="2" cellspacing="0"> <tbody> <tr> <td>用户?</td> <td>email </td> <td>主页 </td> <td>电话 </td> <td>联系地址 </td> <td>发帖标题 </td> <td>发帖内容 </td> <td>回复标题 </td> <td>回复内容 </td> </tr> </tbody> </table> <br /> q个数据库表W合W一范式Q但是没有Q何一l候选关键字能决定数据库表的整行Q唯一的关键字D는户名也不能完全决定整个元l。我们需要增?发帖ID"?回复ID"字段Q即表修改为: <br /> <br /> <table style="height: 25px;" align="center" border="1" cellpadding="2" cellspacing="0"> <tbody> <tr> <td>用户?</td> <td>email </td> <td>主页 </td> <td>电话 </td> <td>联系地址 </td> <td>发帖ID </td> <td>发帖标题 </td> <td>发帖内容 </td> <td>回复ID </td> <td>回复标题 </td> <td>回复内容 </td> </tr> </tbody> </table> <br /> q样数据表中的关键字(用户名,发帖IDQ回复ID)能决定整行: <br /> <br /> (用户?发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容) <br /> <br /> 但是Q这L设计不符合第二范式,因ؓ存在如下军_关系Q?<br /> <br /> (用户? → (email,主页,电话,联系地址) <br /> <br /> (发帖ID) → (发帖标题,发帖内容) <br /> <br /> (回复ID) → (回复标题,回复内容) <br /> <br /> 即非关键字段部分函数依赖于候选关键字D,很明显,q个设计会导致大量的数据冗余和操作异常?<br /> <br /> 我们数据库表分解ؓQ带下划U的为关键字Q: <br /> <br /> Q?Q?用户信息Q用户名QemailQ主,电话Q联pd址 <br /> <br /> Q?Q?帖子信息Q发帖IDQ标题,内容 <br /> <br /> Q?Q?回复信息Q回复IDQ标题,内容 <br /> <br /> Q?Q?发脓Q用户名Q发帖ID <br /> <br /> Q?Q?回复Q发帖IDQ回复ID <br /> <br /> q样的设计是满W???范式和BCNF范式要求的,但是q样的设计是不是最好的呢? <br /> <br /> 不一定?<br /> <br /> 观察可知Q第4?发帖"中的"用户??发帖ID"之间?QN的关p,因此我们可以?发帖"合ƈ到第2的"帖子信息"中;W??回复"中的" 发帖ID"?回复ID"之间也是1QN的关p,因此我们可以?回复"合ƈ到第3的"回复信息"中。这样可以一定量地减数据冗余,新的设计为: <br /> <br /> Q?Q?用户信息Q用户名QemailQ主,电话Q联pd址 <br /> <br /> Q?Q?帖子信息Q用户名Q发帖IDQ标题,内容 <br /> <br /> Q?Q?回复信息Q发帖IDQ回复IDQ标题,内容 <br /> <br /> 数据库表1昄满所有范式的要求Q?<br /> <br /> 数据库表2中存在非关键字段"标题"?内容"对关键字D?发帖ID"的部分函C赖,即不满W二范式的要求,但是q一设计q不会导致数据冗余和操作异常Q?<br /> <br /> 数据库表3中也存在非关键字D?标题"?内容"对关键字D?回复ID"的部分函C赖,也不满W二范式的要求,但是与数据库?怼Q这一设计也不会导致数据冗余和操作异常?<br /> <br /> 由此可以看出Qƈ不一定要满范式的要求,对于1QN关系Q当1的一边合q到N的那边后QN的那边就不再满W二范式了,但是q种设计反而比较好Q?<br /> <br /> 对于MQN的关p,不能M一ҎN一边合q到另一边去Q这样会D不符合范式要求,同时D操作异常和数据冗余?<br /> 对于1Q?的关p,我们可以左边的1或者右边的1合ƈ到另一边去Q设计导致不W合范式要求Q但是ƈ不会D操作异常和数据冗余?<br /> <br /> <strong>   l论 </strong><br /> <br /> 满范式要求的数据库设计是结构清晰的Q同时可避免数据冗余和操作异常。这q意味着不符合范式要求的设计一定是错误的,在数据库表中存在1Q??QN关系q种较特D的情况下,合ƈD的不W合范式要求反而是合理的?<br /> <br /> 在我们设计数据库的时候,一定要时刻考虑范式的要求?/span><br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <img src ="http://m.tkk7.com/ashutc/aggbug/349910.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://m.tkk7.com/ashutc/" target="_blank">西瓜</a> 2011-05-10 13:13 <a href="http://m.tkk7.com/ashutc/archive/2011/05/10/349910.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>数据库设?/title><link>http://m.tkk7.com/ashutc/archive/2011/05/09/349855.html</link><dc:creator>西瓜</dc:creator><author>西瓜</author><pubDate>Mon, 09 May 2011 09:13:00 GMT</pubDate><guid>http://m.tkk7.com/ashutc/archive/2011/05/09/349855.html</guid><wfw:comment>http://m.tkk7.com/ashutc/comments/349855.html</wfw:comment><comments>http://m.tkk7.com/ashutc/archive/2011/05/09/349855.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://m.tkk7.com/ashutc/comments/commentRss/349855.html</wfw:commentRss><trackback:ping>http://m.tkk7.com/ashutc/services/trackbacks/349855.html</trackback:ping><description><![CDATA[<br /> <br /> <ol class="article"> <li>原始单据与实体之间的关系</li> <p class="contentNew">可以是一对一、一对多、多对多的关pR在一般情况下Q它们是一对一的关p:即一张原始单据对应且? 对应一个实体。在Ҏ情况下,它们可能是一对多或多对一的关p,即一张原始单证对应多个实体,或多张原始单证对应一个实体。这里的实体可以理解为基本表? 明确q种对应关系后,Ҏ们设计录入界面大有好处?/p> <p class="contentNew">比如Q一份员工历资料,在h力资源信息系l中Q就对应三个基本表:员工基本情况表、社会关p表、工作简历表。这是“一张原始单证对应多个实?#8221;的典型例子?/p> <li>主键与外?/li> <p class="contentNew">一般而言Q一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实? 可以定义主键Q也可以不定义主键(因ؓ它无子孙Q? 但必要有外键(因ؓ它有父亲Q? 主键与外键的设计Q在全局数据库的设计中,占有重要C。当全局数据库的设计完成以后Q有个美国数据库设计专家_“键,到处都是键,除了键之外,什么也 没有”Q这是他的数据库设计经验之谈,也反映了他对信息pȝ核心Q数据模型)的高度抽象思想。因为:主键是实体的高度抽象Q主键与外键的配对,表示实体 之间的连接?/p> <li>基本表的性质</li> <p class="contentNew">基本表与中间表、时表不同Q因为它h如下四个Ҏ:</p> <ul class="article"> <li>原子性。基本表中的字段是不可再分解的?/li> <li>原始性。基本表中的记录是原始数据(基础数据Q的记录?/li> <li>演绎性。由基本表与代码表中的数据,可以z出所有的输出数据?/li> <li>E_性。基本表的结构是相对E_的,表中的记录是要长期保存的?/li> </ul> <p class="contentNew">理解基本表的性质后,在设计数据库Ӟp基本表与中间表、时表区分开来?/p> <li>范式标准</li> <p class="contentNew">基本表及其字D之间的关系, 应尽量满第三范式。但是,满W三范式的数据库设计Q往往不是最好的设计。ؓ了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余Q达CI间换时间的目的?/p> <p class="contentNew">比如有一张存攑֕品的基本表,如表1所C?#8220;金额”q个字段的存在,表明该表的设计不满W三范式Q因?#8220;金额”可以?#8220;单h”乘以“数量”得到Q说?#8220;金额”是冗余字Dc但是,增加“金额”q个冗余字段Q可以提高查询统计的速度Q这是以空间换旉的作法?/p> <p class="contentNew">在Rose 2002中,规定列有两种cdQ数据列和计列?#8220;金额”q样的列被称?#8220;计算?#8221;Q?#8220;单h”?#8220;数量”q样的列被称?#8220;数据?#8221;?/p> <table style="line-height: 150%;" align="center" border="1" cellspacing="0" width="600"> <tbody> <tr> <td>商品名称</td> <td>商品型号</td> <td>单h</td> <td>数量</td> <td>金额</td> </tr> <tr> <td>电视?/td> <td>29?/td> <td>2,500</td> <td>40</td> <td>100,000</td> </tr> </tbody> </table> <p align="center">? 商品表的表结?/p> <li>通俗地理解三个范?/li> <p class="contentNew">通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中Qؓ了更好地应用三个范式Q就必须通俗地理解三个范式(通俗地理解是够用的理解,q不是最U学最准确的理解)Q?/p> <ul class="article"> <li>W一范式Q?NF是对属性的原子性约束,要求属性具有原子性,不可再分解;</li> <li>W二范式Q?NF是对记录的惟一性约束,要求记录有惟一标识Q即实体的惟一性;</li> <li>W三范式Q?NF是对字段冗余性的U束Q即M字段不能由其他字D|生出来,它要求字D|有冗余?/li> </ul> <p class="contentNew">没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时Z提高q行效率Q就必须降低范式标准Q适当保留冗余数据。具体做法是Q在概念数据模型设计旉守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字D,允许冗余?/p> <li>要善于识别与正确处理多对多的关系</li> <p class="contentNew">若两个实体之间存在多对多的关p,则应消除q种关系。消除的办法是,在两者之间增加第三个实体。这 P原来一个多对多的关p,现在变ؓ两个一对多的关pR要原来两个实体的属性合理地分配C个实体中厅R这里的W三个实体,实质上是一个较复杂的关p, 它对应一张基本表。一般来Ԍ数据库设计工具不能识别多对多的关p,但能处理多对多的关系?/p> <p class="contentNew">比如?#8220;图书馆信息系l?#8221;中,“图书”是一个实体,“读?#8221;也是一个实体。这两个实体之间的关p, 是一个典型的多对多关p:一本图书在不同旉可以被多个读者借阅Q一个读者又可以借多本图书。ؓ此,要在二者之间增加第三个实体Q该实体取名?#8220;借还 ?#8221;Q它的属性ؓQ借还旉、借还标志Q?表示借书Q?表示q书Q,另外Q它q应该有两个外键Q?#8220;图书”的主键,“读?#8221;的主键)Q它能?#8220;图书”? “读?#8221;q接?/p> <li>主键PK的取值方?/li> <p class="contentNew">PK是供E序员用的表间q接工具Q可以是一无物理意义的数字? q序自动加1来实现。也可以是有物理意义的字D名或字D名的组合。不q前者比后者好。当PK是字D名的组合时Q徏议字D늚个数不要太多Q多了不但烦引占用空间大Q而且速度也慢?/p> <li>正确认识数据冗余</li> <p class="contentNew">主键与外键在多表中的重复出现Q不属于数据冗余Q这个概念必L楚,事实上有许多不清楚。非键字D늚重复出现Q才是数据冗余!而且是一U低U冗余,即重复性的冗余。高U冗余不是字D늚重复出现Q而是字段的派生出现?/p> <p class="contentNew">比如商品中的“单h、数量、金?#8221;三个字段Q?#8220;金额”是?#8220;单h”乘以“数量”z出来的,它就 是冗余,而且是一U高U冗余。冗余的目的是ؓ了提高处理速度。只有低U冗余才会增加数据的不一致性,因ؓ同一数据Q可能从不同旉、地炏V角色上多次? 入。因此,我们提倡高U冗余(z性冗余)Q反对低U冗余(重复性冗余)?/p> <li>E-R图没有标准答?/li> <p class="contentNew">信息pȝ的E-R图没有标准答案,因ؓ它的设计与画法不是惟一的,只要它覆盖了pȝ需求的业务范围 和功能内容,是可行的。反之要修改E-R图。尽它没有惟一的标准答案,q不意味着可以随意设计。好的E—R囄标准是:l构清晰、关联简z、实体个? 适中、属性分配合理、没有低U冗余?/p> <li>视图技术在数据库设计中很有?/li> <p class="contentNew">与基本表、代码表、中间表不同Q视图是一U虚表,它依赖数据源的实表而存在。视图是供程序员使用? 据库的一个窗口,是基表数据综合的一UŞ? 是数据处理的一U方法,是用h据保密的一U手Dcؓ了进行复杂处理、提高运速度和节省存储空? 视图的定义深度一般不得超q三层?若三层视图仍不够? 则应在视图上定义临时? 在时表上再定义视图。这样反复交q定? 视图的深度就不受限制了?/p> <p class="contentNew">对于某些与国家政沅R经、技术、军事和安全利益有关的信息系l,视图的作用更加重要。这些系l的 基本表完成物理设计之后,立即在基本表上徏立第一层视图,q层视图的个数和l构Q与基本表的个数和结构是完全相同。ƈ且规定,所有的E序员,一律只准在? 图上操作。只有数据库理员,带着多个人员共同掌握?#8220;安全钥匙”Q才能直接在基本表上操作。请读者想惻Iq是Z么?</p> <li>中间表、报表和临时?/li> <p class="contentNew">中间表是存放l计数据的表Q它是ؓ数据仓库、输出报表或查询l果而设计的Q有时它没有主键与外键(数据仓库除外Q。时表是程序员个h设计的,存放临时记录Qؓ个h所用。基表和中间表由DBAl护Q时表q序员自己用程序自动维护?/p> <li>完整性约束表现在三个斚w</li> <p class="contentNew">域的完整性:用Check来实现约束,在数据库设计工具中,对字D늚取D围进行定义时Q有一个Check按钮Q通过它定义字D늚值城?/p> <p class="contentNew">参照完整性:用PK、FK、表U触发器来实现?/p> <p class="contentNew">用户定义完整性:它是一些业务规则,用存储过E和触发器来实现?/p> <li>防止数据库设计打补丁的方法是“三少原则”</li> <ul class="article"> <li>一个数据库中表的个数越越好。只有表的个数少了,才能说明pȝ的E--R囑ְ而精Q去掉了重复的多余的实体QŞ成了对客观世界的高度抽象Q进行了pȝ的数据集成,防止了打补丁式的设计Q?/li> <li>一个表中组合主键的字段个数少好。因Z键的作用Q一是徏主键索引Q二是做为子表的外键Q所以组合主键的字段个数了Q不仅节省了q行旉Q而且节省了烦引存储空_</li> <li>一个表中的字段个数少好。只有字D늚个数了Q才能说明在pȝ中不存在数据重复Q且很少有数据冗余,更重要的是督? 读者学?#8220;列变?#8221;Q这样就防止了将子表中的字段拉入C表中去,在主表中留下许多IZ的字Dc所?#8220;列变?#8221;Q就是将主表中的一部分内容拉出去,另外? 独徏一个子表。这个方法很单,有的人就是不习惯、不采纳、不执行?/li> </ul> <p class="contentNew">数据库设计的实用原则是:在数据冗余和处理速度之间扑ֈ合适的q炏V?#8220;三少”是一个整体概念,l? 合观点,不能孤立某一个原则。该原则是相对的Q不是绝对的?#8220;三多”原则肯定是错误的。试惻I若覆盖系l同L功能Q一百个实体Q共一千个属性) 的E-R图,肯定比二百个实体Q共二千个属性) 的E--R图,要好得多?/p> <p class="contentNew">提?#8220;三少”原则Q是叫读者学会利用数据库设计技术进行系l的数据集成。数据集成的步骤是将文gp? l集成ؓ应用数据库,应用数据库集成Z题数据库Q将主题数据库集成ؓ全局l合数据库。集成的E度高Q数据共享性就强Q信息孤岛现象就少Q整个企 业信息系l的全局E—R图中实体的个数、主键的个数、属性的个数׃少?/p> <p class="contentNew">提?#8220;三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改Q企业数据库变成了随意设计数据库表?#8220;垃圾?#8221;Q或数据库表?#8220;大杂?#8221;Q最后造成数据库中的基本表、代码表、中间表、时表杂ؕ无章Q不计其敎ͼD企事业单位的信息pȝ无法l护而瘫痪?/p> <p class="contentNew">“三多”原则M人都可以做到Q该原则?#8220;打补丁方?#8221;设计数据库的歪理学说?#8220;三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术Q不是Q何h都能做到的,因ؓ该原则是杜绝?#8220;打补丁方?#8221;设计数据库的理论依据?/p> <li>提高数据库运行效率的办法</li> <p class="contentNew">在给定的pȝg和系lY件条件下Q提高数据库pȝ的运行效率的办法是:</p> <ul class="article"> <li>在数据库物理设计Ӟ降低范式Q增加冗余,用触发? 多用存储q程?/li> <li>当计非常复杂、而且记录条数非常巨大Ӟ例如一千万条)Q复杂计要先在数据库外面,以文件系l方式用C++语言计算处理完成之后Q最后才入库q加到表中去。这是电信计费系l设计的l验?/li> <li>发现某个表的记录太多Q例如超q一千万条,则要对该表进行水q_剌Ӏ水q_割的做法是,以该表主键PK的某个gؓ界线Q将该表的记录水q_割ؓ两个表。若发现某个表的字段太多Q例如超q八十个Q则垂直分割该表Q将原来的一个表分解Z个表?/li> <li>Ҏ据库理pȝDBMSq行pȝ优化Q即优化各种pȝ参数Q如~冲Z数?/li> <li>在用面向数据的SQL语言q行E序设计Ӟ量采取优化法?/li> </ul> <p class="contentNew">MQ要提高数据库的q行效率Q必M数据库系l优化、数据库设计U优化、程序实现优化Q这三个层次上同时下功夫?/p> </ol> <p class="contentNew">上述十四个技巧,是许多h在大量的数据库分析与设计实践中,逐步ȝ出来的。对于这些经验的q用Q读者不能生帮硬套,死记背Q而要消化理解Q实事求是,灉|掌握。ƈ逐步做到Q在应用中发展,在发展中应用?</p> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /> <img src ="http://m.tkk7.com/ashutc/aggbug/349855.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://m.tkk7.com/ashutc/" target="_blank">西瓜</a> 2011-05-09 17:13 <a href="http://m.tkk7.com/ashutc/archive/2011/05/09/349855.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <p>лǵվܻԴȤ</p> <a href="http://m.tkk7.com/" title="亚洲av成人片在线观看">亚洲av成人片在线观看</a> <div class="friend-links"> </div> </div> </footer> վ֩ģ壺 <a href="http://7uj3.com" target="_blank">שש</a>| <a href="http://cztbm.com" target="_blank">Ƶ߹ۿ</a>| <a href="http://51708695.com" target="_blank">޾Ʒ鶹ר</a>| <a href="http://dazhe777.com" target="_blank">ۺС˵þ</a>| <a href="http://172pk.com" target="_blank">H߹ۿ</a>| <a href="http://51nianyefan.com" target="_blank">þþƷƵѲ</a>| <a href="http://cztshw.com" target="_blank">57paoƵѲ</a>| <a href="http://thinkchating.com" target="_blank">AV뾫Ʒ</a>| <a href="http://zdmaid.com" target="_blank">ƷƵ</a>| <a href="http://aidannis.com" target="_blank">޹þþþƷС˵</a>| <a href="http://beijinzhongliuyiyuan.com" target="_blank">ŷޡŹһ</a>| <a href="http://977446.com" target="_blank">޴߹ۿ</a>| <a href="http://lfhuanxin.com" target="_blank">߹ۿѹۿַ</a>| <a href="http://by6635.com" target="_blank">ŮƵƵƵҳ</a>| <a href="http://3688008.com" target="_blank">պƷһ</a>| <a href="http://hbjpxnyqckj.com" target="_blank">޾Ʒ㶮վ</a>| <a href="http://lzqzvip.com" target="_blank">ŮƷƵ</a>| <a href="http://srztw.com" target="_blank">Ļ</a>| <a href="http://zengzeyu.com" target="_blank">ҹ޲</a>| <a href="http://mabaolu.com" target="_blank">޾Ʒ͵</a>| <a href="http://wankufan.com" target="_blank">AVƬ߹ۿ</a>| <a href="http://26672814.com" target="_blank">ޢva</a>| <a href="http://zzo8.com" target="_blank">ձ岻Ļ</a>| <a href="http://868664.com" target="_blank">߹ۿվ</a>| <a href="http://zgbeian.com" target="_blank">ղϵ</a>| <a href="http://masfd.com" target="_blank">ˬˬƬav </a>| <a href="http://www-993789.com" target="_blank">91Ƶ</a>| <a href="http://lswqn.com" target="_blank">Ʒۺһ</a>| <a href="http://littlevv.com" target="_blank">avһ</a>| <a href="http://littlevv.com" target="_blank">޳a߹ۿ</a>| <a href="http://139699.com" target="_blank">ձҹѸƵ</a>| <a href="http://5g5t.com" target="_blank">Ļav벻 </a>| <a href="http://xiaoduanfa.com" target="_blank">ĻһëƬ</a>| <a href="http://amgzh.com" target="_blank">޹Ʒպ߹ۿ </a>| <a href="http://664403.com" target="_blank">һ˿wwwѸĻ</a>| <a href="http://www-8908.com" target="_blank">ˬָ߳ëƬ </a>| <a href="http://htsp777.com" target="_blank">ձһ</a>| <a href="http://m8va.com" target="_blank">þþƷѹۿ</a>| <a href="http://hhrrrr.com" target="_blank">޿ƬƵ </a>| <a href="http://slmlxg.com" target="_blank">޳avƬ</a>| <a href="http://xyflash.com" target="_blank">޾ƷóƬAV߲</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>