银行数据库设计

1、银行数据库设计银行数据库设计银行数据库的数据需求初始的用户需求规格说明可以基于数据库用户的交流以及设计者自己对银行业务的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是银行企业的主要特征：1.银行有多个支行。每个支行位于某个城市，由唯一的名字标识。银行监控每个支行的资产2.银行客户通过其customer_id值标识，银行存储了每位客户的姓名及其居住的城市和街道。客户可以有账户，并且可以贷款。一个客户可能和某个银行员工发生联系，该员工作为此客户的贷款负责人或私人助理3.银行员工功过其employee_id值来标识。银行的管理机构存储每个员工的姓名、 号码、亲属姓名及其经理的em

2、ployee_id号码。银行还需要知道员工开始工作的日期，由此日期可以推知员工的雇佣期4.银行提供两类账户支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外，每个储蓄存款账户有其利率，而每个支票账户有其透支额5.每笔贷款由某个支行发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款，但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载

3、其日期和金额真实的银行中，还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似，并且为了保持示例的简洁性，在我们的模型中不考虑对存款和取款的记录。银行数据库设计建模 数据库建模如下： 一组实体的集合 一组实体集间联系的集合 实体：是现实世界中可区别于其他对象的“事物”或“对象”。 例如：企业中的每个人都是一个实体，一个人的person_id性质可以唯一地标识这个人；贷款也可以被看作实体，通过贷款号唯一地标识某个贷款实体。 每个实体有一组性质（或属性） 例如：people have names and addresses 实体集：是相同类型

4、即具有相同性质（或属性）的实体集合。 例如：某个银行的所有客户的集合可被定义为实体集customer。类似地，实体集loan表示某个银行所发放的所有贷款的集合。 实体集不必互不相交。例如，可以定义银行所有员工的实体集employee和所有客户的实体集customer。而一个person实体可以是employee实体，可以是customer实体，可以既是employee实体又是customer实体，也可以都不是。银行数据库设计实体集 customer and loancustomer_id customer_ customer_ customer_ loan_ amount name stree

5、t city number银行数据库设计联系集 联系：是指多个实体间的相互关联。例如：可以定义客户Hayes和贷款号L-15相关联的联系Hayesloan L-15customer entityrelationship setloan entity 联系集联系集是n (n 2) 个实体集上的数学关系，其元素如下：(e1, e2, en) | e1 E1, e2 E2, , en En这里 (e1, e2, , en) 是一个联系。 例如： (Hayes, L-15) borrower银行数据库设计联系集 borrower银行数据库设计联系集 (续) 一个联系集也可以具有描述性属性。 实体集cu

6、stomer和account之间的联系集depositor。我们可以将属性access_date与该联系关联起来，以表示客户访问一个账户的最近日期。银行数据库设计属性 一个实体集可能有多个属性，每个实体可以用一组(属性，数据值)对来表示。 域域 每个属性都有一个可取值的集合 属性类型：简单 属性和复合属性单值 属性和多值 属性 例如：多值属性： phone_numbers派生 属性 可以从别的相关属性或实体派生出来 例如： age, 派生于 date_of_birth例如： customer = (customer_id, customer_name, customer_street, cus

7、tomer_city )loan = (loan_number, amount )银行数据库设计复合属性银行数据库设计映射基数约束 指明一个实体通过一个联系集能同时与多少个实体相关联。 映射基数在描述二元联系集时非常有用。 对于实体集A和B之间的二元联系集R来说，映射的基数必然是以下情况之一： One to one One to many Many to one Many to many 银行数据库设计映射基数One to oneOne to many注：A和B中的某些实体可能没有与另一个实体集中的任何实体相 关联。银行数据库设计映射基数 Many to oneMany to many注：某个

8、联系集的映射基数是依赖于该联系集所建模的对象在现 实世界中的实际情况。银行数据库设计码 超码超码：是一个或多个属性的集合，这些属性的组合可以使我们在一个实体集中唯一地标识一个实体。 我们通常只对这样的一些超码感兴趣，它们的任意子集都不能成为超码，这样的最小子集称为候选码。 Customer_id is candidate key of customer account_number is candidate key of account 尽管可能存在多个候选码，只选择其中之一作为主码。 码(主码、候选码或超码)是实体集的性质，而不是单个实体的性质。实体集中的任意两个实体都不允许同时在码属性上具

9、有相同的值。码的制定代表了被建模的现实企业中的约束。 主码的选择应该是那些从不或极少变化的属性。 例如：一个人的地址不应作为主码的一部分；(美)社会保障号可以作为主码。银行数据库设计联系集的码所有参与的实体集的主码的组合构成一个联系集的超码。(customer_id, account_number) is the super key of depositor注：给定的联系集中的一个联系实例必须是由其参与实体能唯一标识的，而不必使用描述属性。 假设我们要记录一个客户访问一个账户的所有日期。单值的属性access_date只能保存一个访问日期。我们不能通过同一用户和帐号之间联系的多个实例来表示多个

10、访问日期，因为这些联系实例无法仅使用参与的实体来唯一的标识。正确的处理方法是创建一个多值的属性access_date，它可以保存所有的访问日期。联系集的主码结构依赖于联系集的映射基数。例如，实体集customer和account，以及具有属性access_date的联系集depositor。 如果联系集是多对多的，那么depositor的主码由customer和account的主码共同组成。 如果一个客户只能有一个帐号，即depositor联系是从customer到account多对一的，则depositor的主码就是customer的主码。 如果联系是从account到customer多对一

11、的，则每个帐号最多只能属于一个客户，所以depositor的主码就是account的主码。 一对一的联系中，可以使用两个主码中的任意一个来作为联系的主码。银行数据库设计E-R 图n矩形表示实体集；双矩形表示弱实体集n菱形表示联系集n线段将属性连接到实体集或将实体集连接到联系集n椭圆表示属性l双椭圆表示多值属性l虚椭圆表示派生属性n双线表示一个实体集全部参与到联系集中n下划线表示主码属性银行数据库设计带有复合、多值和派生属性的E-R图银行数据库设计具有描述性属性的联系集银行数据库设计角色 参与一个联系集的实体集可以相同 标签 “manager” 和 “worker” 称为角色； 表示实体在联系中

12、的作用 角色在E-R图中用连接菱形和矩形的线段上的标签指明 角色标签是可选的，用于解释联系的语义银行数据库设计One-To-Many 联系 One-to-many 联系borrower ： a loan is associated with at most one customer via borrower, a customer is associated with several (including 0) loans via borrower银行数据库设计Many-To-One 联系 Many-to-one 联系borrower ：a loan is associated with se

13、veral (including 0) customers via borrower, a customer is associated with at most one loan via borrower银行数据库设计Many-To-Many 联系 A customer is associated with several (possibly 0) loans via borrower A loan is associated with several (possibly 0) customers via borrower银行数据库设计参与n全部参与 (双线): every entity i

14、n the entity set participates in at least one relationship in the relationship setl例如： participation of loan in borrower is total4 every loan must have a customer associated to it via borrowern部分参与： some entities may not participate in any relationship in the relationship setl例如： participation of cu

15、stomer in borrower is partial银行数据库设计三元联系E-R图银行数据库设计实体-联系设计问题实体集和联系集的概念并不精确，而且定义一组实体及它们的相互联系实体集和联系集的概念并不精确，而且定义一组实体及它们的相互联系可能有多种不同的方式。可能有多种不同的方式。 用实体集还是用属性用实体集还是用属性 用实体集还是用联系集用实体集还是用联系集 用二元联系集与用二元联系集与n元联系集元联系集 联系属性的布局联系属性的布局银行数据库设计实体集 Vs. 属性 具有属性employee_id、employee_name和telephone_number的实体集employee。

16、 如果 可以作为一个单独的实体，它具有属性telephone_number和location 实体集employee，具有属性employee_id和employee_name。 实体集telephone，具有属性telephone_number和location。 联系集emp_telephone，表示员工及 间的联系。 两种定义主要差别 将 处理成为一个telephone_number属性暗示对每个员工，正好有一个 号码与之相联系；而将 看成一个telephone实体，就允许每个员工可以有多个 号码与之相联系。也就是说，将 作为一个实体来建模可以保存关于 的额外信息，如它的位置，或类型（移

17、动的，视频的或普通的旧 ），或哪些人共用。因此把 视为一个实体比把它视为一个属性的方式更具有通用性；而且当这种通用性很重要的时候，这种定义方式就更为适合。银行数据库设计实体集 Vs. 属性 什么作为属性？什么作为实体集？ 区分它们主要依赖于被建模的实际企业的结构，以及被讨论的属性的相关语义。 常见错误 用一个实体集的主码作为另一个实体集属性，而不是使用联系。 例如，即使每笔贷款只有一个客户，将cumstomer_id作为loan的属性也是不正确的。用borrower联系代表贷款和客户之间的关联才是正确的方法，这样可以明确地表示出两者之间的关系，而不是将这种关系隐含在属性中。 将相关实体集的主码

18、属性作为联系集的属性。 例如，loan_number和customer_id不应该在borrower联系中作为属性出现。这样做是不对的，因为在联系集的表示中已经隐含了这些主码属性。银行数据库设计实体集 Vs. 联系集 银行贷款的建模 一种方法假设银行贷款通过一个实体来建模。 另一种方法，不将贷款做为一个实体，而将其作为客户和银行支行之间的一个联系，这一联系具有描述属性loan_number和amount。每笔贷款都是用客户和银行支行间的一个联系来表示。 如果每笔贷款正好为一个客户所有，并且正好同一个支行相联系，那么我们可以发现用联系来表示贷款是能满足设计要求的。 但是，采用这样的设计，不能很方

19、便地表示几个客户共有一笔贷款的情况。为此，必须为共有贷款的每个持有人分别定义一个联系，并不得不在每个这样的联系中复制描述性属性loan_number和amount的值。当然，每个这样的联系必须有相同的loan_number和amount值。 数据复制的问题 在确定用实体集还是联系集时可采用的一个原则是，当描述发生在实体间的行为时采用联系集。银行数据库设计二元 Vs. 多元联系集 数据库中的联系通常都是用二元的。一些看来非二元的联系实际上可以用多个二元关系更好地表示。 例如，我们可以创建一个三元联系parent，将一个孩子与其父母相关联。这一联系也可以用两个二元联系分别来表示，即mother和f

20、ather，分别与他们的孩子相关联。使用mother和father两个联系使我们可以记录孩子的母亲，即使我们不知道父亲的身份；而对于这种情况三元联系parent中必须有一个Null值。所以在这个例子中用二元联系更好。 上面的方法并不总是令人满意的。 考虑联系集works_on，它与employee、branch和job有关。 不能直接将works_on分离为employee和branch之间的联系与employee和job之间的联系这两个二元联系。 否则，我们可以记录Jones既是经理又是审计员，且Jones既在Perryridge又在Downtown工作；然而我们无法记录Jones是在Per

21、ryridge工作的经理和在Downtown工作的审计员，而不是在Perryridge工作的审计员或在Downtown工作的经理。银行数据库设计联系属性的布局 一个联系的映射基数比率会影响联系属性的布局。 一对一或一对多联系集的属性可以放到一个参与该联系的实体集中，而不是放到联系集中。 例如，指定depositor是一个一对多的联系集，也就是一个客户可以有多个账户，但每个账户只能属于一个客户。在这种情况下，指明客户最后一次访问账户的日期的属性access_date可以放在account实体集中。既然每个account实体最多和一个customer实例参与到联系中，因而将属性access_dat

22、e放在account实体集中和将属性access_date放在depositor联系集中具有相同的含义。 一对多联系集的属性仅仅可以重放置到参与联系的“多”的那一边的实体集中。 一对一的联系集，联系的属性可以放到任一参与联系的实体中。银行数据库设计联系属性的布局 设计时将描述属性作为联系集的属性还是实体集的属性这一决定应该反映出被建模企业的本来特点。 设计者可以选择保留access_date作为depositor的属性，以显式地表明访问发生在实体集customer和实体集account的交互点上。 属性位置的选择在多对多联系集中体现得更清楚。 假设depositor为一个多对多的联系集，表明一

23、个客户可有一个或多个账户，而一个帐户可以为一个或多个客户所拥有。 要表达某个客户最近一次访问某个账户的日期，access_date则必须作为联系集depositor的属性，而不是任何一个参与此联系集的实体集的属性。 如果将access_date作为account的属性，对一个共有的账户，就不能确定是哪个客户进行了最近一次访问。 当一个属性是由参与的实体集联合确定而不是由单独的某个实体集确定时，该属性就必须放到多对多联系集中。银行数据库设计弱实体集一个实体集可能没有足够的属性以形成主码，这样的实体集就称作弱实体集。与此相对，有主码的实体集称作强实体集。实体集payment：该实体集具有属性pay

24、ment_number、payment_date和payment_amount。还款号通常是从1开始的连续数字，分别针对每一笔贷款生成。虽然各个payment实体互不相同，但不同贷款的还款却可能具有相同的还款号。因此，实体集payment没有主码，是一个弱实体集。弱实体集必须与另一个称为标识实体集或属主实体集的实体集关联才有意义。每个弱实体集必须和一个标识实体关联，也就是说，弱实体集就称为存在依赖于标识实体集。我们称标识实体集拥有它所标识的弱实体集。将弱实体集与其标识实体集相关联的联系称为标识性联系。标识性联系是从弱实体集到标识实体集的多对一联系。payment的标识实体集是loan，将pay

25、ment实体和它们对应的loan实体关联在一起的loan_payment是标识性联系。虽然弱实体集没有主码，仍需要某种方法来区分那些依赖于某个强实体集的弱实体集中的实体。弱实体集的分辨符是使得我们能进行这种区分的属性集合。弱实体集payment的分辨符是属性payment_number，因为对每笔贷款来说，还款号唯一标识了偿还该贷款的一笔款项。弱实体集的主码由标识实体集的主码和弱实体集的分辨符共同组成。例如弱实体集payment的主码是loan_number, payment_number，其中loan_number是标识实体集loan的主码，而payment_number区分同一个贷款的不同

26、payment实体。银行数据库设计弱实体集银行数据库设计特殊化和一般化 特殊化从单一的实体集出发，通过创建不同的低层实体集来强调同一实体集中不同实体间的差异。 低层实体集可以有特殊的属性或参与到特殊的联系中，这些属性或联系并非适用于高层实体集中的所有实体。 设计者采用特殊化的原因正是为了表达这样的与众不同的特征。 如果customer和employee既没有特有的属性（即与person实体所拥有的那些属性不同的属性），又没有参与特殊的联系（即person实体没有参与的联系），就没有必要对person实体集进行特殊化。 一般化的进行基于这样的认识：一些实体集具有共同的特征（即可以用相同的属性对它

27、们进行描述，且它们都参与到相同的联系集中）。一般化是在这些实体集的共同性的基础上将它们综合成了一个高层实体集。 一般化用于强调低层实体集间的相似性并隐藏它们的差异；同时由于去除了共同属性的重复出现，可以达到简洁的表示效果。.银行数据库设计特殊化和一般化银行数据库设计聚集n 考虑employee、branch和job之间的三元联系works_on。n 假设想记录一位员工在某一部门作为经理的工作情况。n 存在的问题：冗余信息。n联系集works_on和manages可以合并到一个联系集中。然而，我们不应该将它们合并到一起，因为一些employee、branch、job组合可能没有经理银行数据库设计

28、聚集n 聚集是一种抽象，通过这种抽象，联系被当作高层实体来看待。n将联系集works_on看成一个称作works_on的高层实体集，并且可以像对待别的实体集那样对待这样的实体集，从而可以在works_on和manager之间创建一个二元联系manages来表示谁管理什么任务。银行数据库设计银行数据库的数据需求初始的用户需求规格说明可以基于数据库用户的交流以及设计者自己对银行业务的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是银行企业的主要特征：1.银行有多个支行。每个支行位于某个城市，由唯一的名字标识。银行监控每个支行的资产2.银行客户通过其customer_id值标识，银

29、行存储了每位客户的姓名及其居住的城市和街道。客户可以有账户，并且可以贷款。一个客户可能和某个银行员工发生联系，该员工作为此客户的贷款负责人或私人助理3.银行员工功过其employee_id值来标识。银行的管理机构存储每个员工的姓名、 号码、亲属姓名及其经理的employee_id号码。银行还需要知道员工开始工作的日期，由此日期可以推知员工的雇佣期4.银行提供两类账户支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外，每个储蓄存款账户有其利率，而每个支票账户

30、有其透支额5.每笔贷款由某个支行发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款，但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额真实的银行中，还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似，并且为了保持示例的简洁性，在我们的模型中不考虑对存款和取款的记录。银行数据库设计银行数据库中的实体集 实体集branch，具有属性branch_name、branch_city和assets； 实体集c

31、ustomer，具有属性customer_id、customer_name、customer_street和customer_city；此外还可以考虑加上属性banker_name； 实体集employee，具有属性employee_id、employee_name、telephone_number、salary和manager；此外还包括多值属性dependent_name，属性start_date及其派生属性employment_length； 两个账户实体集savings_account和checking_account，它们共同的属性是account_number和balance；此外

32、，savings_account还具有属性interest_rate，checking_account还具有属性overdraft_amount； 实体集loan，具有属性loan_number、amount和originating_branch； 弱实体集loan_payment，具有属性payment_number、payment_date和payment_amount。银行数据库设计银行数据库中的联系集 定义如下联系集，在此过程中要对前面关于实体集属性的决策进一步精化 borrower，是customer和loan间的一个多对多联系集； loan_branch，指明产生贷款的银行支行的多

33、对一联系集。注意这个联系代替了loan实体集的originating_branch属性； loan_payment，从loan到payment的一对多联系集，表明一笔款项是为某笔贷款而付的； depositor，具有联系属性access_date，是customer和account间的多对多联系集，表明某个客户拥有某个账户； cust_banker，具有联系属性type的一个多对一联系集，表明一个客户可以从一个银行员工处获得建议，而一个银行员工可以为一个或多个客户提供建议。注意这个联系集代替了customer实体集的banker_name属性； works_for，具有manager角色和具有

34、worker角色的employee实体之间的联系集；其映射基数表明了一个员工仅为一个经理工作，而一个经理监督一个或多个员工。注意我们用这一联系集代替了employee实体集的manager属性。银行数据库设计银行数据库中的E-R图银行数据库设计转换为关系模式 符合E-R数据库模式的数据库可以表示为一些关系模式的集合。数据库的每个实体集和联系集都有唯一的关系模式与之对应，关系模式名即为相应的实体集或联系集的名称。 E-R模型和关系数据库模型都是现实世界抽象的逻辑表示。由于两种模型都采用类似的设计原则，我们可以将E-R设计转换为关系设计。银行数据库设计实体集 TO 模式强实体集： 模式具有与该强实

35、体集相同的属性。弱实体集： 模式具有的属性为：标识实体集的主码+该弱实体集属性 payment = (loan_number, payment_number, payment_date, payment_amount)银行数据库设计联系集 TO 模式 对于多对多的二元联系，主码应该是参与实体集的主码属性的并集。 对于一对一的二元联系集，任何一个参与实体集的主码都可以作为联系的主码。可以任意选择一个与该联系集相关联的实体集，将它的主码属性作为联系的主码。 对于多对一的二元联系集，主码应该是联系集中“多”那一边的实体集的主码。 对于n元联系集，如果连接到它的边中没有箭头，则主码是所有参与实体集的主

36、码属性的并集。 对于n元联系集，如果连接到它的一条边中有一个箭头，则除去“箭头”那一边的实体集的主码属性，其他参与实体集的主码属性的并集为联系的主码。 注：还要在该模式R上建立外码约束。银行数据库设计模式冗余n对于多对一或一对多的联系集，如果多的一方是全部参与的，则可以通过在多的一方添加额外的属性（一的一方的主码）来表示。n例如：不需要为account和branch创建联系集account-branch，而可以通过在account中添加branch_name来表示二者联系。银行数据库设计模式冗余 一对一的联系集，任意一方都可作为多的一方处理。 即，额外的属性可以添加到任何一个实体 如果多的一方

37、部分参与联系，可能导致空值。 account = (account_number, balance, branch_name) branch = (branch_name, branch_city, assets) 弱实体集与其标识实体集的联系集转换的模式是冗余的。 例如：payment和loan的联系集loan_payment银行数据库设计复合属性与多值属性 通过为每个子属性创建一个单独的属性来处理复合属性，并不是为复合属性自身创建单独的一个属性。 例如：address是实体集customer的一个复合属性，并且address由street和city组成。从customer产生的模式将包括属

38、性address_street和address_city，而不是为address建立单独的属性或模式。 多值属性较为复杂，必须为其创建新的关系模式。 对一个多值属性M，为其创建关系模式R，该模式具有对应M的属性A，以及对应属性M所在的实体集或联系集的主码的那些属性。 例如实体集employee，该实体集具有一个多值属性dependent_name。employee的主码是employee_id。我们为该属性创建一个关系模式： dependent_name(employee_id, d_name) 一个雇员的每个亲属都可以表示为该模式上的关系中的唯一一个元组。这样，假设有一个employee_id为12-234的雇员，他的亲属有John何Mary，就对应着关系dependent_name中的两个元组： (123-45-6789 , Jack) and (123-45-6789 , Jane) 这种关系模式的主码由模式中的所有属性构成；另外，需要在该关系模式上建立外码约束银行数据库设计特殊化的表示 方法 1： 为高层实体集创建模式 为每个低层实体集创建模式，属性包括高层属性的主码和其局部属性集 schema attributes person name, street, city customer name, credit_rating employee name,