数据库规范化.doc_第1页
数据库规范化.doc_第2页
数据库规范化.doc_第3页
数据库规范化.doc_第4页
数据库规范化.doc_第5页
免费预览已结束,剩余17页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

一、基础概念要理解范式,首先必须对知道什么是关系数据库,如果你不知道,我可以简单的不能再简单的说一下:关系数据库就是用二维表来保存数据。然后你应该理解以下概念:实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,不如说“老师与学校的关系”。属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。元组:表中的一行就是一个元组。分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。全码:如果一个码包含了所有的属性,这个码就是全码。主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。第一范式是数据库规范化中所使用的一种正规形式。第一范式是为了要排除 重复组 的出现,所采用的方法是要求数据库的每个字段都只能存放单一值,而且每条记录都要能利用一个惟一的主键来加以识别。1不符合第一范式的情况重复组重复组通常会出现在会计帐上,每条记录可能有不定个数的值。举例来说:交易顾客日期数量PeteMonday19.00 -28.20PeteWednesday-84.00SarahFriday100.00 150.00-40.00数量 就是所谓的重复组了,而在这种情况下这份数据就不符合第一范式。想要消除重复组的话,只要把每笔记录都转化为单一记录即可:交易交易 ID顾客日期数量1PeteMonday19.002PeteMonday-28.203PeteWednesday-84.004SarahFriday100.005SarahFriday150.006SarahFriday-40.00缺乏惟一识别码一样是在交易这个例子中,同一天同一个人买了同样的数量,这样的交易做了两次:交易顾客日期数量PeteMonday19.00PeteMonday19.00如上所示,这两笔交易可以说是一模一样,也就是说如果只靠这些数据我们没有办法分辨这两笔记录。我们之所以说它不符合第一范式,是因为上面这样的表示法欠缺一个惟一识别码,可以是一个字段,也可以是一组字段,而且可以保证在这个数据中惟一识别码不会重复出现。要将它正规化到符合第一范式的原则只需要加入一个惟一识别码即可:交易交易 ID顾客日期数量1PeteMonday19.002PeteMonday19.00关系数据库里的第一范式大多数的 RDBMS (关系数据库) 允许用户在定义数据表的时候不去指定主键,不过这么一来这种数据表就不符合第一范式了。从某个角度看来,不允许重复组的出现是关系数据库表示信息的方法,RDBMS 里数据表每一笔记录的每一个字段都只能有一个值。举例来说,如果定义了一个叫做 Favorite Number 的整数字段,每一笔记录的 Favorite Number 这个字段都只会是一个整数 (或是无);这也就是说,如果设置了主键的话,理论上不可能会有任何关系数据库的数据表会违反第一范式的原则。不过就算是在这种情况下,还是可以设计出在骨子里违反第一范式的数据表。最简单的方法就是把多个有意义的值编码过后存进一个字段里,然后在数据表中用很多字段来表达同一个事实。单一字段中有多个有意义的值在单一字段中存放多个值是违反第一范式的做法,下面这个就是很好的例子,它把多个值用逗号分开来表示:挑食列表人不喜欢的食物JimLiver, Goats cheeseAliceBroccoliNormanPheasant, Liver, Peas以这样的设计看来,想要知道有什么人不喜欢某样特定的东西是很不容易的。不过可以把这个数据表转化成下面这种符合第一范式的类型:挑食列表人不喜欢的食物JimLiverJimGoats cheeseAliceBroccoliNormanPheasantNormanLiverNormanPeas用很多字段来表达同一个事实在同一个数据表里用多个字段来表达同一个事情也是违反第一范式的:个人数据人喜欢的颜色不喜欢的食物 (1)不喜欢的食物 (2)不喜欢的食物 (3)JimGreenLiverGoats cheeseAliceFuchsiaBroccoliNormanBluePheasantLiverPeasEmilyYellow就算我们能确定每个人不喜欢吃的食物最多不会超过三样,这还是一个很糟的设计。举例来说,我们想要知道所有不喜欢同一种食物的人的组合的话,这就不是件容易的事,因为食物有可能出现在任何一个字段,也就是说每一次的查询都要去检查 9 (3 x 3) 组不同的字段组合。第二范式(2NF,台湾译作第二正规化)是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的所有数据都要和该数据表的主键有相依关系;如果有哪些数据只和主键的一部份有关的话,就得把它们独立出来变成另一个数据表。如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式。一个数据表符合第二范式当且仅当它符合第一范式 所有非主键的字段都一定和主键有关 示例有一个数据表记录了设备元件的信息,如下所示:元件来源元件 ID(主键)供应商 ID(主键)供应商名称价格供应商住址652Stylized Parts59.99VA732Stylized Parts20.00VA651ACME Industries69.99CA这个数据表的每个值都是单一值,所以它符合第一范式。因为同一个元件有可能由不同的供应商提供,所以得把元件 ID 和供应商 ID 合在一起组成一个主键。主键和价格之间的关系很正确:同一个元件在不同供应商有可能会有不同的报价,所以价格确实和主键完全相关。另一方面,供应商的名称和住址就只和供应商 ID 有关,这不符合第二范式的原则。仔细看就会发现 Stylized Parts 这个名称和 VA 这个住址重复出现了两次;要是它改名了或是被其他公司并购了怎么办?这时候最好把这些数据存到第二个数据表中:供应商ID名称住址1ACME IndustriesCA2Stylized PartsVA这么一来,原本的 元件来源 数据表就得要做相对应的更动:元件来源元件 ID (主键)供应商 ID (主键)价格65259.9973220.0065169.99检查数据表里的每个字段,确认它们是不是都和主键完全相关,这样才能知道这个数据表是不是符合第二范式;如果不是的话,就把那些不完全相关的字段移到独立的数据表里。接下来的步骤是要确保所有不是键的字段都和彼此没有相依关系,这就叫做第三范式。第三范式(3NF,台湾译作第三正规化)是数据库规范化中所使用的一种正规形式,用来检验是否所有非键属性都只和候选键有相关性,也就是说所有非键属性互相之间应该是无关的。第三范式和第二范式不同的地方在于,在第三范式里,所有的非键属性都必须和每个候选键有直接相关。如果再对第三范式做进一步加强就成了BC范式,它所强调的重点就在于 数据间的关系是奠基在键上、以整个键为考量、而且除了键之外不考虑其他因素。正规定义令:R 表一个关系; F 表维持 R 所需的一组功能相依性; X 表 R 属性的子集合; A 表 R 的一个属性 如果对于 这种类型的功能相依性而言,下列叙述任一为真的话,则可以称 R 符合第三范式:;也就是说 A 是明显功能相依性 X 是超键 A 是 R 的键的一部份 任何一个具有部份相依性或是转移相依性的关系都违反了第三范式。示例以下面这个定义机械元件的关系为例:机械元件元件编号(主键)制造商名称制造商地址1000ToyotaPark Avenue1001MitsubishiLincoln Street1002ToyotaPark Avenue本例中制造商地址很明显地不该被列在这个关系里面,因为和元件本身比起来,制造商地址应该和制造商比较有关系;正确的做法应该是把独立成为一个新的数据表:制造商制造商名称(主键)制造商地址ToyotaPark AvenueMitsubishiLincoln Street然后把原本的数据表改成这样:机械元件元件编号(主键)制造商名称1000Toyota1001Mitsubishi1002Toyota先前那个数据表的问题在于每提到一次制造商名称就要多存一次它的地址,而这就不符合第三范式的原则。下面提供了另一个例子:订单 (Order)订单编号 (主键)(Order Number)客户名称 (Customer Name)单价(Unit Price)数量 (Quantity)小计 (Total)1000David$35.003$105.001001Jim$25.002$50.001002Bob$25.003$75.00在本例中,小计不应该放在这个数据表里面,只要把单价乘上数量就可以得到小计了;如果想要符合第三范式的话,就把小计拿掉吧 (不过在做查询的时候,本来用 SELECT Orders.Total FROM Orders 就要改成用 SELECT UnitPrice * Quantity FROM Orders 了)。订单 (Order)订单编号(主键)(Order Number) 客户名称 (Customer Name)单价 (Unit Price)数量 (Quantity)1000David$35.0031001Jim$25.0021002Bob$25.003主键(Unique Key)主键(Unique Key 或 Primary Key),又称主码。数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据库表只能有一个主键,且主键的取值不能缺失,即不能为空值(Null)。从技术的角度来看,Primary Key和Unique Key有很多相似之处。但还是有以下区别:一、作为Primary Key的域域组不能为null。而Unique Key可以。二、在一个表中只能有一个Primary Key,而多个Unique Key可以同时存在。更大的区别在逻辑设计上。Primary Key一般在逻辑设计中用作记录标识,这也是设置 Primary Key的本来用意。而Unique Key只是为了保证域域组的唯一性。外键(Foreign key),又称外码。在关系数据库中,每个数据表都是由关系来连系彼此的关系,父数据表(Parent Entity)的主键会放在另一个数据表当属性建立彼此的关系,而这个属性就是外键。例如:学生跟老师之间是教学的关系,学生数据表会有个属性叫指导老师(FK),而这个值就是对晕到老师数据表的老师代号(PK),学生的指导老师就是外键。候选键在关系模型中,候选键或候选码是某个关系变量的一组属性所组成的集合,它需要同时满足下列两个条件:这个属性集合始终能够确保在关系中能唯一标识元组 在这个属性集合中找不出合适的子集能够满足条件(1) 满足第一个条件的属性集合称为超键,因此我们也可以把候选键定义为“最小超键”,也就是不含有多余属性的超键。候选键的重要性是它们能够在关系中唯一标识出不同的元组,因此超键也是在设计数据库模式时需要指定的最重要的约束之一。由于在关系模型中,每个关系都是一个集合(没有重复的元素),所以每个关系都至少有一个候选键(因为所有属性组合必然是个超键)。但是在某些关系型数据库中表也能代表多重集,所以在每个关系中都显式地定义至少一个候选键是一条很重要的设计原则。数据库管理系统通常都需要将每个关系中的某个候选键定义为主键,亦即这个候选键是区分不同元组时首选的识别方式,例如外键通常就是引用主键而非其他候选键。数据类型名称类别大小(字节)数据的本质说明BitInteger1数据的大小容易让人误解。表中第一个bit数据类型取用一个字节,接下来的7个bit数据类型使用同一个字节。允许null则会多使用一个字节BigintInteger8当需要频繁使用越来越大的数值时,可以使用Bigint数据类型。该数据类型允许使用-263263-1内的数值,即正负460百万兆IntInteger4-2 147 483 6482 147 483 647的全部数值SmallIntInteger2-32 76832 767的全部数值TinyIntInteger10255的全部数值Decimal或NumericDecimal/Numeric变化的固定精度和小数位数,-1038-11038-1。这两个名称意思相同MoneyMoney8-263263,精确到所代表货币单位的万分之一。注意,货币单位可以是任意的,不限于美元SmallMoneyMoney4-214 748.3648214 748.3647货币单位FloatApproximate Numerics变化的接受一个参数(如Float(20)),以确定存储大小和精度。注意,该参数是以位为单位,而不是以字节为单位。范围为-1.79E+3081.79E+308DateTimeDate/Time8表示日期和时间的数据类型,从1753年1月1日到9999年12月31日,精确度是1/300sSmallDateTimeDate/Time4表示日期和时间的数据类型,从1900年1月1日到2079年6月6日,精确度是1minTimestamp/rowversionSpecialNumeric二进制数字8在给定的数据库中唯一的特殊值。当对数据库执行记录插入或更新时,由数据库自己自动地设置该值即使没有在UPDATE语句中提及timestamp列(实际上,不允许直接更新timestamp域)Unique IdentifierSpecialNumeric二进制数字16特殊的全局唯一标识符(GUID)。确保跨时间和空间上是唯一的CharCharacter变化的固定长度字符数据。如果值的长度比设定的长度短,则将添补空格直至达到设定的长度。数据是非Unicode字符数据。可指定的最大长度是8 000字符VarCharCharacter变化的可变长度的字符数据。不会向值中填入空格。数据是非Unicode字符数据。可指定的最大长度是8 000字符,不过,可以使用max关键字,表明该数据是非常大的字符数据(最大存储大小是231字节)TextCharacter变化的在SQL Server 2005中是一种遗留系统支持。使用varchar (max)替代NCharUnicode变化的固定长度Unicode字符数据。如果值的长度比设定的长度短,则将添补空格直至达到设定的长度。可指定的最大长度是4 000字符NVarCharUnicode变化的可变长度Unicode字符数据。不会向值中填入空格。可指定的最大长度是4 000字符,不过,可以使用max关键字,表明该数据是非常大的字符数据(最大存储大小是231字节)NtextUnicode变化的与Text数据类型类似,在SQL Server 2005中只是一种遗留系统支持。在这里,使用nvarchar(max)。可变长度的Unicode字符数据BinaryBinary变化的固定长度的二进制数据,最大长度是8KBVarBinaryBinary变化的可变长度的二进制数据,可指定的最大长度是8KB,不过,可以使用max关键字,表明该数据是一个大型数据对象LOB(最大存储大小是231字节)ImageBinary变化的在SQL Server 2005中是一种遗留系统支持。使用varbinary(max)替代Sql_variantOther特殊的与VB和C+中的Variant有些类似。本质上,是能够容纳大多数其他SQL Server数据类型的容器。这意味着,当一个列或函数需要能够处理多种数据类型时,可以使用Sql_variant。与VB不同,使用这种数据类型时,必须明确地将其转换为更确定的数据类型XMLCharacter变化的用于存储XML数据的字符数据类型。用于基于XML模式验证数据,以及特殊的面向XML的函数聚合函数若要汇总一定范围的数值,请使用以下函数: 函数名语法说明SUM SUM(aggregate)返回表达式中所有值的总和。SUM 只能与包含数值的字段一起使用。将忽略空值。AVERAGEAVERAGE(aggregate)返回表达式中所有非空值的平均值(算术平均值)。AVERAGE 只能与包含数值的字段一起使用。将忽略空值。MAX MAX(aggregate)返回表达式中的最大值。对于字符列,MAX 将按照排序顺序来查找最大值。将忽略空值。MIN MIN(aggregate)返回表达式中的最小值。对于字符列,MIN 将按照排序顺序来查找最小值。将忽略空值。COUNT COUNT(aggregate)返回组中非空项的数目。COUNT 始终返回 Int 数据类型值。COUNTDISTINCTCOUNTDISTINCT(aggregate)返回组中某项的非空非重复实例数STDev STDEV(aggregate)返回某项的非空值的标准偏差。STDevP STDEVP(aggregate)返回某项的非空值的总体标准偏差。VARVAR(aggregate) 返回某项的非空值的方差。VARP VARP(aggregate)返回某项的非空值的总体方差。 条件函数若要测试条件,请使用以下函数:函数名语法说明IFIF(condition,value_if_true,value_if_false)如果指定了计算结果为 TRUE 的条件,将返回一个值;如果指定了计算结果为 FALSE 的条件,则返回另一个值。条件必须是计算结果为 TRUE 或 FALSE 的值或表达式。如果条件为 True,则 Value_if_true 表示返回的值。如果条件为 False,则 Value_if_false 表示返回的值。ININ(item, set)确定某项是否是集的成员。Switch Switch(condition1, value1)对一系列表达式求值并返回与其中第一个为 True 的表达式相关联的表达式的值。Switch 可以有一个或多个条件/值对。数据类型转换若要将值从一种数据类型转换为另一种数据类型,请使用以下函数: 函数名语法说明INT DECIMAL INT(value)DECIMAL(value)将值转换为整数。将值转换为十进制数字。FLOAT FLOAT(value)将值转换为 float 数据类型。TEXTTEXT(value)将数值转换为文本。数据类型转换函数函数名语法说明CAST()CAST(AS length )CONVERT()CONVERT(length, ,style)1)data_type为SQL Server系统定义的数据类型,用户自定义的数据类型不能在此使用。2)length用于指定数据的长度,缺省值为30。3)把CHAR或VARCHAR类型转换为诸如INT或SAMLLINT这样的INTEGER类型、结果必须是带正号或负号的数值。4)TEXT类型到CHAR或VARCHAR类型转换最多为8000个字符,即CHAR或VARCHAR数据类型是最大长度。5)IMAGE类型存储的数据转换到BINARY或VARBINARY类型,最多为8000个字符。6)把整数值转换为MONEY或SMALLMONEY类型,按定义的国家的货币单位来处理,如人民币、美元、英镑等。7)BIT类型的转换把非零值转换为1,并仍以BIT类型存储。8)试图转换到不同长度的数据类型,会截短转换值并在转换值后显示“+”,以标识发生了这种截断。9)用CONVERT()函数的style 选项能以不同的格式显示日期和时间。style 是将DATATIME 和SMALLDATETIME 数据转换为字符串时所选用的由SQL Server 系统提供的转换样式编号,不同的样式编号有不同的输出格式。日期和时间函数若要显示日期或时间,请使用以下函数:函数名语法说明DATEDATE(year, month, day)返回给定年、月、日的上午 12:00:00 的日期时间值。DATEONLYDATEONLY(datetime)从日期时间值返回年、月和日。DATETIMEDATETIME(year, month, day, hour, minute, second)返回给定年、月、日、小时、分钟和秒的日期时间。YEAR YEAR(datetime)返回日期时间的年份值。QUARTER QUARTER(datetime)返回日期时间的日历季度 (1-4)。MONTH MONTH(datetime)返回日期时间中的月。DAY DAY(datetime)从日期时间中提取“日”。HOUR HOUR(datetime)从日期时间中提取小时。MINUTE MINUTE(datetime)从日期时间中提取分钟。SECOND SECOND(datetime)从日期时间中提取秒。DAYOFYEAR DAYOFYEAR(datetime)返回日期时间中一年中的第几天。1 月 1 日 = 1 到 12 月 31 日 = 366(假定是闰年)。WEEK WEEK(datetime) 返回日历年中该周的数值。DAYOFWEEK DAYOFWEEK(datetime)返回星期几,从星期一开始。星期一 = 1 到星期日 = 7。NOW NOW( )返回当前日期和时间。TODAY TODAY( )返回当前日期。DATEDIFF DATEDIFF(interval,datetime, datetime)返回开始日期时间和结束日期时间之间的差。DATEADD DATEADD(interval,units, datetime)返回将指定数目的时间间隔单位添加到原始日期时间后得到的日期时间。逻辑函数若要测试条件的逻辑,请使用以下函数:函数名语法说明ANDAND(logical, logical)如果所有参数都为 TRUE,则返回 TRUE;如果一个或多个参数为 FALSE,则返回 FALSE。语法:参数的计算结果必须是逻辑值(例如 TRUE 或 FALSE),或者参数必须是包含逻辑值的数组或引用。如果数组或引用参数包含文本或空单元,则忽略这些值。OR OR(logical, logical)如果任一参数为 TRUE,则返回 TRUE;如果所有参数均为 FALSE,则返回 FALSE。 语法:参数的计算结果必须是逻辑值(例如 TRUE 或 FALSE),或者是包含逻辑值的数组或引用。如果数组或引用包含文本或空单元,则忽略这些值。NOT NOT(logical)颠倒其参数的值。如果希望确保某子句不等于特定的值,请使用 NOT。 语法: 如果值为 False,NOT 将返回 True;如果值为 True,NOT 将返回 False。数学函数若要进行数值操作,请使用以下函数: 函数名语法说明MODMOD(number, divisor)返回数字除以除数之后的余数。除数不能为 0。TRUNC TRUNC(number, digits)按指定的位数截断数字。如果数字为正,则从小数点右侧截断数字。如果数字为负,则从小数点左侧截断数字。ROUND ROUND(number, digits)将数字舍入到指定的位数。如果位数大于 0(零),则将数字舍入到指定的小数位数。如果位数为 0,则数字舍入到最近的整数。如果数字小于 0,则数字舍入到小数点左侧。运算符算术运算符若要执行基本的数学运算(例如加法、减法或乘法)、组合数字以及生成数值结果,请使用以下运算符:运算符语法说明+ 加value + value用于将两个或多个项相加。- 减value- value用于从一个项减去另一个项。* 乘 value* value用于使项相乘。/ 除 value/divisor用于对项进行除运算。除数不能为 0。- 求反 -value更改值的符号。 求幂 valuepower用于对值进行幂运算(求幂)。比较运算符若要比较两个值并返回逻辑值 True 或 False,请使用以下运算符:运算符语法说明= 等于 value1= value2用于使两个值相等。如果 value1 等于 value2,则为 True。 不等于 value1 value2用于指示两个值不相等。如果 value1 不等于 value2,则为 True。 大于 value1 value2用于指示一个值大于另一个值。如果 value1 大于 value2,则为 True。 = 大于或等于 value1 = value2用于指示一个值大于或等于另一个值。如果 value1 大于或等于 value2,则为 True。 小于 value1 value2用于指示一个值小于另一个值。如果 value1 小于 value2,则为 True。 = 小于或等于 value1 = value2用于指示一个值小于或等于另一个值。如果 value1 小于或等于 value2,则为 True。文本函数若要在报表中进行文本操作,请使用以下函数: 函数语法说明Concat (&) string & string将两个字符串组合为一个字符串。第二个字符串追加到第一个字符串的末尾。 Find FIND(string, substring) 第一个字符串实例的位置。Left LEFT(string, length)返回字符串最左侧的一些字符。如果在函数内指定的长度参数值小于零,则这种行为未定义。Length LENGTH(string)返回字符串中的字符数。Lower LOWER(string)将字符串从大写字符转换为小写字符。LTrim LTRIM(string)返回删除了前导空格的字符串。 Replace REPLACE(find, replace, string)返回一个字符串,其中某个子字符串的所有实例均替换为另一个子字符串。Right RIGHT(string, length)返回字符串最右侧的一些字符。如果在函数内指定的长度参数值小于零,则这种行为未定义。RTrim RTRIM(string)返回删除了尾随空格的字符串。 Text 将数值转换为字符串。 TEXT(value)Substring SUBSTRING(string, start, length)返回字符串中的子字符串。如果在函数内指定的长度参数值小于零,则这种行为未定义。Upper UPPER(string)将字符串从小写字符转换为大写字符。字符串比较函数:函数语法说明CHARINDEX()CHARINDEX(,)返回字符串中某个指定的子串出现的开始位置。其中substring _expression 是所要查找的字符表达式,expression 可为字符串也可为列名表达式。如果没有发现子串,则返回0 值。此函数不能用于TEXT 和IMAGE 数据类型。PATINDEX()PATINDEX(,)返回字符串中某个指定的子串出现的开始位置。其中子串表达式前后必须有百分号“%”否则返回值为0。与CHARINDEX 函数不同的是,PATINDEX函数的子串中可以使用通配符,且此函数可用于CHAR、 VARCHAR 和TEXT 数据类型。信息函数若要返回有关用户的全局信息,请使用以下函数: 函数语法说明GetUserID GETUSERID()返回用户用来访问数据的 ID。SyntaxGetUserCulture GETUSERCULTURE()返回用户的语言或区域设置。SQL Server数据库设计表和字段1. 原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。 例1:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键一般而言,一个实体不能既无主键又无外键。在ER 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。 3. 基本表的性质基本表与中间表、临时表不同,因为它具有如下四个特性: (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。 (3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。 4. 范式标准基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。例2:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。在Rose 2002中,规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。表1 商品表的表结构商品名称 商品型号 单价 数量 金额电视机 29吋 2,500 40 100,000 5. 通俗地理解三个范式通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解):第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余.没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。 6. 要善于识别与正确处理多对多的关系若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处理多对多的关系。例3:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系,是一个典型的多对多关系:一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。为此,要在二者之间增加第三个实体,该实体取名为“借还书”,它的属性为:借还时间、借还标志(0表示借书,1表示还书),另外,它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。 7. 主键PK的取值方法 PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。 8. 正确认识数据冗余主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。例4:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性,因为同一数据,可能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。9. ER图没有标准答案信息系统的ER图没有标准答案,因为它的设计与画法不是惟一的,只要它覆盖了系统需求的业务范围和功能内容,就是可行的。反之要修改ER图。尽管它没有惟一的标准答案,并不意味着可以随意设计。好的ER图的标准是:结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。10. 视图技术在数据库设计中很有用与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口,是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统,视图的作用更加重要。这些系统的基本表完成物理设计之后,立即在基本表上建立第一层视图,这层视图的个数和结构,与基本表的个数和结构是完全相同。并且规定,所有的程序员,一律只准在视图上操作。只有数据库管理员,带着多个人员共同掌握的“安全钥匙”,才能直接在基本表上操作。请读者想想:这是为什么?11. 中间表、报表和临时表中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员自己用程序自动维护。12. 完整性约束表现在三个方面域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有一个Check按钮,通过它定义字段的值城。参照完整性:用PK、FK、表级触发器来实现。用户定义完整性:它是一些业务规则,用存储过程和触发器来实现。 13. 防止数据库设计打补丁的方法是“三少原则” (1) 一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的ER图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计; (2) 一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间; (3) 一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的ER图,肯定比二百个实体(共二千个属性) 的ER图,要好得多。提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局ER图中实体的个数、主键的个数、属性的个数就会越少。提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。 “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。14. 提高数据库运行效率的办法在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是: (1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。 (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用C+语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。 (3) 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。 (4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。 (5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。1逻辑数据库和表的设计数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论