Version3.0数据库设计第二学期2ACCP第一学期SQL知识回顾•数据库基本概念•SQL查询语言基本知识•SQLServer2000的使用3ACCP第二学期SQL课程目标•理解数据库设计过程•T-SQL编程•理解事务的概念•视图•存储过程•触发器•游标•SQL安全模型Version3.0第一章数据库设计5目标理解与数据库设计有关的概念,如数据库建模实体关系模型理解用于设计数据库的E-R图及其实现理解数据规范化数据完整性了解数据字典、数据完整性和数据库服务器设计6数据库设计和建模必要性•好的数据库结构有利于:-节省数据的存储空间-能够保证数据的完整性-方便进行数据库应用系统的开发•设计不好的数据库结构将导致-数据冗余、存储空间浪费-内存空间浪费7设计数据库不管数据库的大小和复杂程度如何,可以用下列基本步骤来设计数据库:–收集信息–标识对象–设计数据模型–标识每个对象的信息类型–标识对象之间的关系8数据建模的概念将现实世界的数据转换成信息世界的数据的过程称为建模9数据建模步骤商业信息需求可操作的数据库外模式概念模式内模式商业视图系统视图10建立外模式外模式是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述是数据库用户的数据视图是与某一应用有关的数据的逻辑表现不依赖于数据库的逻辑结构,外模式是与用户有关的数据模型11建立概念模型1-2概念模式是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。概念模式是整个组织的数据视图,表示数据库中的全部数据内容,因此一个数据库只有一个概念模式。12建立概念模型2-2概念模式由若干个概念记录类型组成,它不仅要描述概念记录类型,还要描述记录之间的联系、所允许的操作、数据的完整性、安全性和其它数据控制方面的要求。概念模型不涉及到存储结构、访问技术等细节。设计概念模型的方法有多种,例如实体关系模型、对象模型等。13建立内模型内模式是数据物理结构和存储方式的描述,是数据在数据库内部的表示方法。一个数据库只有一个内模式。内模式定义了所有内部记录类型、索引和文件的组织形式,以及数据控制方面的细节。14使用DBMS设计数据库体系结构外部视图1外部视图n内部视图外模式/模式映象模式/内模式映象应用1应用k-1应用k数据库系统的三级模式结构概念视图外模式/模式映象DBMSos由数据库管理员建立和维护外模式概念模式内模式15概念模型设计-实体关系模型•实体关系模型:DB设计过程,并且表示DB的整个逻辑结构–实体:实体可以是具体的(例如一个人或一本书),也可以是抽象的(如一个节日或一个概念)–属性:实体是由一组属性来表示的。例如:Person(个人)实体的属性有Name(名称)、SSN、Age(年龄)、Street(街道)、City(城市)–关系:关系是两个或多个实体之间的联系16关系的类型XXXXYYYY一对一XXXXYYYY一对多XXXXYYY多对一XXXXYYYY多对多17E-R图的符号符号含义实体类型弱实体类型关系类型属性键属性多值属性复合属性派生属性18E-R图1-2StreetCustomerCust_NameCityDateAcct_TypeAcct_NumberAccountCustAcctDepositorStreetCustomerCust_NameCityDateCustAcctDepositorAcct_TypeAcct_NumberAccount一对多一对一19E-R图2-2StreetCustomerCust_NameCityDateCustAcctDepositorAcct_TypeAcct_NumberAccountAccountAcct_numberAcct_TypeLogTransactionDateAmountTrans_Number多对多有弱实体集的E-R图20什么是规范化我们的任务是研究模式设计,研究设计一个“好”的(没有“毛病”的)关系模式的办法。数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系。21三级范式1-3第一范式的定义:如果一个表中没有重复组(即行与列的交叉点上只有一个值,而不是一组值),且定义了关键字、所有非关键属性都依赖于关键字,则这个表属于第一范式(常记成1NF)。例如,图1中的表属于1NF,它的关键字是工程号,职工号。22三级范式2-3第二范式的定义:如果一个表属于1NF,且不包含部分依赖性,既没有任何属性只依赖于关键字的一部分,则这个表属于第二范式(常记成2NF)。将1NF转换成2NF的方法是分解。23三级范式3-3第三范式的定义:如果一个表属于2NF,且不包含传递依赖性,则这个表是第三范式(常记成3NF)。满足3NF的表中不包含传递依赖,即没有一个非关键属性依赖于另一个非关键属性,或者说没有一个非关键属性决定另一个非关键属性。24规范化实例1-5假设某建筑公司要设计一个数据库。公司的业务规则概括说明如下:•公司承担多个工程项目,每一项工程有:工程号、工程名称、施工人员等;•公司有多名职工,每一名职工有:职工号、姓名、性别、职务(工程师、技术员)等;•公司按照工时和小时工资率支付工资,小时工资率由职工的职务决定(例如,技术员的小时工资率与工程师不同)。•公司定期制定一个工资报表,如图-1所示。25规范化实例2-5工程号工程名称职工号姓名职务小时工资率工时实发工资A1花园大厦1001齐光明工程师6513845.001002李思岐技术员6016960.001004葛宇宏律师60191140.00小计2945.00A2立交桥1001齐光明工程师6515975.001003鞠明亮工人5517935.00小计1910.00A3临江饭店1002李思岐技术员60181080.001004葛宇洪技术员6014840.00小计1920.00图-1某公司的工资表26规范化实例3-5工程号工程名称职工号姓名职务小时工资率工时A1花园大厦1001齐光明工程师6513A1花园大厦1002李思岐技术员6016A1花园大厦1004葛宇宏律师6019A2立交桥1001齐光明工程师6513A2立交桥1003鞠明亮工人5517A3临江饭店1002李思岐技术员6018A3临江饭店1004葛宇洪技术员6014图-227规范化实例4-51.表中包含大量的冗余,可能会导致数据异常:a.更新异常例如,修改职工号=1001的职务,则必须修改所有职工号=1001的行。b.添加异常若要增加一个新的职工时,首先必须给这名职工分配一个工程。或者为了添加一名新职工的数据,先给这名职工分配一个虚拟的工程。(因为主关键字不能为空)c.删除异常例如,1001号职工要辞职,则必须删除所有职工号=1001的数据行。这样的删除操作,很可能丢失了其它有用的数据。28规范化实例5-52.采用这种方法设计表的结构,虽然很容易产生工资报表,但是每当一名职工分配一个工程时,都要重复输入大量的数据。这种重复的输入操作,很可能导致数据的不一致性。29用函数依赖图表示所有属性之间存在的函数依赖关系,如图3所示。1.图上方的箭头表示关键属性决定非关键属性。2.图下方的箭头表示属性之间的函数依赖性。函数依赖图工程号工程名称职工号姓名职务小时工资率工时图-3函数依赖图30再看这三个表的函数依赖图工程号工程名称职工号姓名职务小时工资率工程号职工号工时图-4三个表的函数依赖图31画出四个表的函数依赖图从函数依赖图可见,已经消除职工表中的传递依赖,这四个表都属于第三范式。在绝大多数情况下,一个数据库的所有表都满足3NF,就基本达到数据库设计的目标。工程号工程名称职工号姓名职务职务小时工资率工程号职工号工时32数据库设计中的其他因素•数据字典–数据元素定义可以独立于表定义,也可以是表定义的一部分•数据类型•强制完整性–数据的可靠性和准确性•数据库服务器设计33总结关系型数据库和SQLServer的基本原理与数据库设计有关的概念,如数据库建模数据规范化用于设计数据库的E-R图及其实现数据完整性数据字典、安全设计以及物理设计