7-关系数据库设计与范式理论.pptVIP

关系数据库设计 主要内容 什么样的关系数据库设计是好的？ 函数依赖 范式判断 模式分解及相关算法 问题的提出 问题 针对一个具体问题，如何构造合适的（更好的）数据模式？ 思路 讨论一个关系中属性间的依赖情况 讨论如何根据属性间依赖关系来判定关系是否有某些不合适的性质 掌握 基于函数依赖概念的关系数据库设计的规范方法 银行数据库模式 branch = (branch_name, branch_city, assets) customer = (customer_id, customer_name, customer_street, customer_city) loan = (loan_number, amount) loan_branch = (loan_number, branch_name) account = (account_number, balance) account_branch = (account_number, branch_name) employee = (employee_id. employee_name, telephone_number, start_date) dependent_name = (employee_id, dname) borrower = (customer_id, loan_number) depositor = (customer_id, account_number) cust_banker = (customer_id, employee_id, type) works_for = (worker_employee_id, manager_employee_id) payment = (loan_number, payment_number, payment_date, payment_amount) savings_account = (account_number, interest_rate) checking_account = (account_number, overdraft_amount) 更大的模式—实例分析1 方案1：borrower = (customer_id, loan_number) loan = (loan_number, amount) 方案2：bor_loan = (customer_id, loan_number, amount) 显然，方案2对应的表不必连接运算，但可能出现信息冗余 更大的模式—实例分析2 方案1：loan_branch = (loan_number, branch_name) loan = (loan_number, amount) 方案2：loan_amt_br = (loan_number, amount, branch_name) 显然，方案2对应的表不必连接运算，且没有信息冗余 更大的模式—分析 试图将太多的属性放在一个表里，可能会导致异常： 数据冗余：同样的信息在多条元组中重复出现 插入异常：插入元组时可能由于部分属性的值未知而导致插入失败 删除异常：部分元组的删除可能其他信息的丢失 更新异常：存在数据冗余时，更新某元组而不是所有可能的元组，可能导致数据不一致 更小的模式—实例分析1 假设已知模式 bor_loan = (customer_id, loan_number, amount)， 如何将模式分解成： borrower = (customer_id, loan_number) loan = (loan_number, amount) 更小的模式—实例分析2 并不是所有的分解都是有益的 如将 employee 表分解 该分解是有损的，即无法通过自然连接重建原模式 更小的模式—实例分析3 模式S-C-M（S学号，C班级，M班主任） 第一范式 First Normal Form （1NF） 定义：关系R中每个属性域都是原子的，则R ?1NF 非1NF的例子 employee表中的children属性域是若干名字的集合 employeeID由6位字符串组成，其中前两个字母表示所属部门，后面四位数字表示部门内编号（数据库应用程序中，字符串通常被认为是原子的，应尽量避免利用应用程序对数据进行解析） 模式中使用非原子属性会导致设计中存储冗余数据 如：为每一个客户存储一个 accounts集合，为每一个account存储一个owners集合 我们假设所有关系满足1NF 范式理论 目的：通过属性间的依赖关系，分析关系模式设计是否“好” 规范化：将一个低一级范式的关系模式分解为若干个高一级范式的关系模式的过程 基本思