关闭

关闭

关闭

封号提示

内容

首页 数据库设计 2 逻辑结构设计.doc

数据库设计 2 逻辑结构设计.doc

数据库设计 2 逻辑结构设计.doc

上传者: 张风若 2017-10-15 评分 0 0 0 0 0 0 暂无简介 简介 举报

简介:本文档为《数据库设计 2 逻辑结构设计doc》,可适用于影视/动漫领域,主题内容包含数据库设计逻辑结构设计数据库设计逻辑结构设计数据库设计()逻辑结构设计逻辑结构设计是将概念模型转换成逻辑模型的过程也就是将ER图中的实体、关系、属性符等。

数据库设计逻辑结构设计数据库设计逻辑结构设计数据库设计()逻辑结构设计逻辑结构设计是将概念模型转换成逻辑模型的过程也就是将ER图中的实体、关系、属性转化为DBMS所支持的数据结构的过程关系型数据库的数据结构为:表。这个过程可以使用一些CASE工具比如:ROSE、ERWIN、PowerDesigner等。一、创建表、实体的描述在创建实体表的时候按照ER模型中实体及实体的属性一个实体建立一个表属性作为表的字段。可以参考以下的属性分类进行详细、必要的实体属性描述。)标识属性标识实体的属性如用户实体用户名如果找不到就自行编号这是实体完整性所必须的一般属性)实体自身的基本属性如用户实体的密码、联系方式等在定义一般属性时需要注意属性自身的分类不同的属性分类结合业务规则可能会产生不一样的表结构设计:简单属性:由单个元素构成的属性比如:邮编复合属性:由多个元素构成的属性比如:姓名(FIRSTNAME、MIDDLENAME、LASTNAME)、地址(江苏省南京市玄武区北京东路#)。根据业务需要可以把复合属性拆成多个简单属性比如:IP)就可以用个bigint、一个处理过的int、或个tinyint来表示单值属性:一行纪录只有一个值的属性比如:用户实体的身份证号码多值属性:一行纪录有多个值的属性比如:公司实体的电话(、、)每个公司都可能有多个电话这时可以将电话属性抽象成一个实体按照下面:N的关系来描述即将公司编号(标识属性)当成电话实体的一般属性派生属性:从某个或某几个属性可以派生出来的属性比如:用户实体的年龄可以从出生日期属性中派生出来通常派生属性不是必须的。但有时也可以一用比如:地址字段比较长如果想要对其进行检索建立索引的话太宠大这时可以派生SEARCHCODE属性比如:用地址的汉字首字母、五笔码等)分类属性实体的分类可以理解成特殊的一般属性如用户实体性别属性可分为男、女)瞬态属性实体在某个瞬间或某个时间段内的属性值也可以理解成特殊的一般属性。瞬态属性与事实的关系非常诡异关于事实的概念在下面会讲到。A)、在事实中一定要注意瞬态属性的记载比如:商品的单价在商品销售纪录中需要记载因为单价是会变的应该记载售出时的单价B)、有的时候需要单独的事实来记载实体瞬态属性的变化过程比如:号单价为元、号变为元、号变为元(也许一天内就会有多次变化)而不是到当天的商品销售事实表中去翻查当天的销售单价C)、有的时候事实发生了会带来实体的瞬态的变化比如:商品销售事实会影响商品的最后售出时间、最新累计销售量等属性)行集属性行集顾名思义就是多行。通常行集属性用于表达多对多关系的属性如用户和角色关系有一个权限属性列表)关联属性同样关联属性也用于描述多对多的关系但这里的关系通常没有属性关联属性用来描述实体与实体间发生关系的状态这样在对实体进行删除的时候就可以避免到事实表中去检查实体有无被使用。因为被使用的实体是不能被物理删除的会破坏实体的参照完整性(可通过外键实现参照完整性)。通常不对系统中已与其他实体发生关系的实体的某行进行物理地删除只是进行逻辑删除:改变其分类属性如:是否已删除(ISDELETED)(STATUS)如果用户新建的实体与已被逻辑删除的实体重名时可以给出页面提示是否"激活"已存在的实体当然也可以不作提示直接新建通常情况下影响不大。、关系的描述关系不同于实体(一个实体一个表)通常只有多对多的关系才需要建立一个表。对于关系的多样性如何对关系进行逻辑结构设计::的关系一对一对的关系不需要建立关系表通常把强实体的标识属性当成弱实体的一般属性比如:一个用户在一个部门把部门编号当成用户实体的一般属性(当然可能有一个用户是多个部门的情况这里假设一个用户只属于一个部门)如果两个实体都是弱实体需要相互依赖那么这时应该考虑将两个实体合并为一个实体什么是强实体、弱实体强实体:不依赖其他实体主键的实体弱实体:依赖其他一个或多个实体主键的实体这里部门是强实体用户是弱实体。:N的关系(一对多)在N方的实体中用一般属性来刻画方的实体的标识属性比如:一个用户可以在银行开多个账户账户实体中就包含着用户的身份证号(用户的标识属性)M:N的关系(多对多)这时需要建立一个关系表比如:用户与角色无法将关系属性作为某个实体的属性存放。上面的行集属性、关联属性就是对实体多对多关系的描述。、数据完整性数据完整性通过约束来实现在前面的ER模型中已进行了的初步定义这里是把键和域的定义落实到表中。通常约束在创建实体、关系表的时候一并建立。数据完整性可分为以下几种:)实体完整性主键约束用于实现实体完整性它用于标识一个实体(标识属性)不可以为对于可为的唯一属性可定义成唯一键)参照完整性外键约束用于实现参照完整性以保持主从表之间的数据的一致性。当然也可以通过关联属性或触发器等方式来实现参照完整性)用户定义完整性有时也叫做业务规则。因为用户定义完整性基本是源于业务规则的通常包括:UNIQUE约束、CHECK约束、约束。在ANSISQL中主键、外键、唯一健、CHECK、被定义为个基本的约束但有的DBMS中(比如SQLSERVER在sysconstraints中可查看到)将默认值定义为约束却不作为约束当然这也没什么好去争议只是DBMS的实现方式而已。在这些约束当中有些是列级的约束即只能对单列定义比如:约束、CHECK约束有些既可以是列级约束也可以是表级约束即可以对单列定义也可以对多列定义比如:主键、外键、唯一键约束、事实回头看一下数据模型的三要素:数据结构、数据操作、数据完整性不难发现数据操作尚未得到体现而事实就是实体或关系属性的变化、以及系统中以实体和关系为基础展开的业务过程的纪录。也就是数据操作的纪录。对于事实的发现可以参考概要设计阶段的数据流图。事实分可简单分为系统日志和业务事实像记叙文一样事实至少要包括六要素:时间、地点、人物、事情的起因、经过、结果表示什么时间、什么人、在哪里干了什么事。)系统日志是指系统自身运行状况的纪录与业务不相干(做法类似操作系统的日志)所以有时系统日志的事实是可选的。但如果记录这样的事实对于做用户行为分析、以及系统自我的改进是很有意义的。)正常:系统日常事务的纪录比如登入、退出)警告:非正常操作的记录比如非正常退出、数据越界操作)错误:记录错误事件的发生(程序名、错误内容)有时错误级别很高的时候比如程序直接崩溃这时错误日志往往只能到应用程序后台去查看了)业务事实是指系统业务数据的纪录对业务事实的发现可采用如下步骤:)对业务类型进行分类:大类(比如:到银行存款)、小类(比如:开户、发卡))对业务类型下的业务操作进行分类行成业务事实(比如:开户纪录))对业务事实的信息进行汇总以作业务统计和决策分析这里严格来讲已经不是真正的事实了而是一种统计报表。二、检查表结构、规范性检查规范性检查通过范式来进行范式很多有BC范式等通常只需要检查范式即可。第一范式:是对属性(表中字段)单值的约束要求一个属性不可对应多个值也就是上面提到的单值属性如果遇到多值属性则需要将其抽象成一个实体上面已经讲过第二范式:是对纪录(表中行)唯一性的约束要求能够唯一标识一行纪录无论是通过单列还是多列来建立主键或唯一键很多时候找不到能唯一标识实体的属性那么就会建一个XXXID的列来实现第三范式:是对表中数据冗余的约束要求单表中不存在派生属性多个表中不存在相同非主键属性值也就是说其他表中用于关联当前实体的主键属性列不算是冗余。范式归纳下来就是:属性单值、纪录唯一、数据无冗余完全符合范式的数据结构设计通常不存在尤其是数据冗余有时根据业务或性能的需要会故意做一些冗余只要注意保持冗余数据与源数据的一致性也是可以的把握好度即可。另外满足第范式的要求是必须满足第范式依次类推。再补充以前老师的一句话:数据库设计要做到不重、不漏。我的理解是:R模型为基础否则凭空想象需要哪不重是指避免数据冗余不漏是指要以E几个表难免会有疏漏甚至错误。、可用性检查可用性检查就是看表结构能否满足业务场景及业务规则(约束)。那么如何检查呢这项检查工作是个跨度比较大的过程参考《软件工程、数据库设计与开发》会发现数据库设计不是一蹴而就的而是在需求分析阶段建立ER模型在概要设计、详细设计阶段逐步细化、落实数据结构的一个过程随着项目推进而去不断地完善并实现数据结构这就是最好的可用性检查。最后概念结构设计、逻辑结构设计的结果都并不是唯一的。只要简单(实体个体不多、关系清晰、属性不冗余)、符合业务需要都是合理的设计。发表于年月日::|||

用户评论(0)

0/200

精彩专题

上传我的资料

每篇奖励 +2积分

资料评价:

/7
0下载券 下载 加入VIP, 送下载券

意见
反馈

立即扫码关注

爱问共享资料微信公众号

返回
顶部