银行数据库设计

银行数据库设计7.2--53银行数据库的数据需求初始的用户需求规格说明可以基于数据库用户的交流以及设计者自己对银行业务的分析。这个设计阶段中的需求描述是制定数据库的概念结构的基础。以下是银行企业的主要特征：1.银行有多个支行。每个支行位于某个城市，由唯一的名字标识。银行监控每个支行的资产2.银行客户通过其customer_id值标识，银行存储了每位客户的姓名及其居住的城市和街道。客户可以有账户，并且可以贷款。一个客户可能和某个银行员工发生联系，该员工作为此客户的贷款负责人或私人助理3.银行员工功过其employee_id值来标识。银行的管理机构存储每个员工的姓名、电话号码、亲属姓名及其经理的employee_id号码。银行还需要知道员工开始工作的日期，由此日期可以推知员工的雇佣期4.银行提供两类账户——支票账户和储蓄存款账户。账户可以由两个或两个以上客户共有，一个客户也可以有两个或两个以上的账户。每个账户被赋予唯一的账户号。银行记录每个账户的余额以及每个账户拥有者访问该账户的最近日期。另外，每个储蓄存款账户有其利率，而每个支票账户有其透支额5.每笔贷款由某个支行发放，能被一个或多个客户所共有。一笔贷款用一个唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次还款情况。虽然贷款的还款号并不能唯一地标识银行所有贷款中的某个特定的还款，但可以唯一地标识对某贷款的所还款项。对每次的还款需要记载其日期和金额真实的银行中，还应像记载对贷款的所还款项那样来记载每个储蓄存款账户或支票账户中取出或存入的金额。由于这些记载的建模过程类似，并且为了保持示例的简洁性，在我们的模型中不考虑对存款和取款的记录。7.3--53建模数据库建模如下：一组实体的集合一组实体集间联系的集合实体：是现实世界中可区别于其他对象的“事物”或“对象”。例如：企业中的每个人都是一个实体，一个人的person_id性质可以唯一地标识这个人；贷款也可以被看作实体，通过贷款号唯一地标识某个贷款实体。每个实体有一组性质（或属性）例如：peoplehavenamesandaddresses实体集：是相同类型——即具有相同性质（或属性）——的实体集合。例如：某个银行的所有客户的集合可被定义为实体集customer。类似地，实体集loan表示某个银行所发放的所有贷款的集合。实体集不必互不相交。例如，可以定义银行所有员工的实体集employee和所有客户的实体集customer。而一个person实体可以是employee实体，可以是customer实体，可以既是employee实体又是customer实体，也可以都不是。7.4--53实体集customerandloancustomer_idcustomer_customer_customer_loan_amountnamestreetcitynumber7.5--53联系集联系：是指多个实体间的相互关联。例如：可以定义客户Hayes和贷款号L-15相关联的联系HayesloanL-15customerentityrelationshipsetloanentity联系集是n(n2)个实体集上的数学关系，其元素如下：{(e1,e2,…en)|e1E1,e2E2,…,enEn}这里(e1,e2,…,en)是一个联系。例如：(Hayes,L-15)borrower7.6--53联系集borrower7.7--53联系集(续)一个联系集也可以具有描述性属性。实体集customer和account之间的联系集depositor。我们可以将属性access_date与该联系关联起来，以表示客户访问一个账户的最近日期。7.8--53属性一个实体集可能有多个属性，每个实体可以用一组(属性，数据值)对来表示。域–每个属性都有一个可取值的集合属性类型：简单属性和复合属性单值属性和多值属性例如：多值属性：phone_numbers派生属性可以从别的相关属性或实体派生出来例如：age,派生于date_of_birth例如：customer=(customer_id,customer_name,customer_street,customer_city)loan=(loan_number,amount)7.9--53复合属性7.10--53映射基数约束指明一个实体通过一个联系集能同时与多少个实体相关联。映射基数在描述二元联系集时非常有用。对于实体集A和B之间的二元联系集R来说，映射的基数必然是以下情况之一：OnetooneOnetomanyManytooneManytomany7.11--53映射基数OnetooneOnetomany注：A和B中的某些实体可能没有与另一个实体集中的任何实体相关联。7.12--53映射基数ManytooneManytomany注：某个联系集的映射基数是依赖于该联系集所建模的对象在现实世界中的实际情况。7.13--53码超码：是一个或多个属性的集合，这些属性的组合可以使我们在一个实体集中唯一地标识一个实体。我们通常只对这样的一些超码感兴趣，它们的任意子集都不能成为超码，这样的最小子集称为候选码。Customer_idiscandidatekeyofcustomeraccount_numberiscandidatekeyofaccount尽管可能存在多个候选码，只选择其中之一作为主码。码(主码、候选码或超码)是实体集的性质，而不是单个实体的性质。实体集中的任意两个实体都不允许同时在码属性上具有相同的值。码的制定代表了被建模的现实企业中的约束。主码的选择应该是那些从不或极少变化的属性。例如：一个人的地址不应作为主码的一部分；(美)社会保障号可以作为主码。7.14--53联系集的码所有参与的实体集的主码的组合构成一个联系集的超码。(customer_id,account_number)isthesuperkeyofdepositor注：给定的联系集中的一个联系实例必须是由其参与实体能唯一标识的，而不必使用描述属性。假设我们要记录一个客户访问一个账户的所有日期。单值的属性access_date只能保存一个访问日期。我们不能通过同一用户和帐号之间联系的多个实例来表示多个访问日期，因为这些联系实例无法仅使用参与的实体来唯一的标识。正确的处理方法是创建一个多值的属性access_date，它可以保存所有的访问日期。联系集的主码结构依赖于联系集的映射基数。例如，实体集customer和account，以及具有属性access_date的联系集depositor。如果联系集是多对多的，那么depositor的主码由customer和account的主码共同组成。如果一个客户只能有一个帐号，即depositor联系是从customer到account多对一的，则depositor的主码就是customer的主码。如果联系是从account到customer多对一的，则每个帐号最多只能属于一个客户，所以depositor的主码就是account的主码。一对一的联系中，可以使用两个主码中的任意一个来作为联系的主码。7.15--53E-R图矩形表示实体集；双矩形表示弱实体集菱形表示联系集线段将属性连接到实体集或将实体集连接到联系集椭圆表示属性双椭圆表示多值属性虚椭圆表示派生属性双线表示一个实体集全部参与到联系集中下划线表示主码属性7.16--53带有复合、多值和派生属性的E-R图7.17--53具有描述性属性的联系集7.18--53角色参与一个联系集的实体集可以相同标签“manager”和“worker”称为角色；表示实体在联系中的作用角色在E-R图中用连接菱形和矩形的线段上的标签指明角色标签是可选的，用于解释联系的语义7.19--53One-To-Many联系One-to-many联系borrower：aloanisassociatedwithatmostonecustomerviaborrower,acustomerisassociatedwithseveral(including0)loansviaborrower7.20--53Many-To-One联系Many-to-one联系borrower：aloanisassociatedwithseveral(including0)customersviaborrower,acustomerisassociatedwithatmostoneloanviaborrower7.21--53Many-To-Many联系Acustomerisassociatedwithseveral(possibly0)loansviaborrowerAloanisassociatedwithseveral(possibly0)customersviaborrower7.22--53参与全部参与(双线):everyentityintheentitysetparticipatesinatleastonerelationshipintherelationshipset例如：participationofloaninborroweristotaleveryloanmusthaveacustomerassociatedtoitviaborrower部分参与：someentitiesmaynotparticipateinanyrelationshipintherelationshipset例如：participationofcustomerinborrowerispartial7.23--53三元联系E-R图7.24--53实体-联系设计问题实体集和联系集的概念并不精确，而且定义一组实体及它们的相互联系可能有多种不同的方式。用实体集还是用属性用实体集还是用联系集用二元联系集与n元联系集联系属性的布局7.25--53实体集Vs.属性具有属性employee_id、employee_name和telephone_number的实体集employee。如果电话可以作为一个单独的实体，它具有属性telephone_number和location实体集employee，具有属性employee_id和employee_name。实体集telephone，具有属性telephone_number和location。联系集emp_telephone，表示员工及电话间的联系。两种定义主要差别将电话处理成为一个telephone_number属性暗示对每个员工，正好有一个电话号码与之相联系；而将电话看成一个telephone实体，就允许每个员工可以有多个电话号码与之相联系。也就是说，将电话作为一个实体来建模可以保存关于电话的额外信息，如它的位置，或类型（移动的，视频的或普通的旧电话），或哪些人共用。因此把电话视为一个实体比把它视为一个属性的方式更具有通用性；而且当这种通用性很重要的时候，这种定义方式就更为适合。7.26--53实体集Vs.属性什么作为属性？什么作为实体集？区分它们主要依赖于被建模的实际企业的结构，以及被讨论的属性的相关语义。常见错误用一个实体集的主码作为另一个实体集属性，而不是使用联系。–例如，即使每笔贷款只有一个客户，将cumstomer_id作为loan的属性也是不正确的。用borrower联系代表贷款和客户之间的关联才是正确的方法，这样可以明确地表示出两者之间的关系，而不是将这种关系隐含在属性中。将相关实体集的主码属性作为联系集的属性。–例如，loan_number和customer_id不应该在borrower联系中作为属性出现。这样做是不对的，因为在联系集的表示中已经隐含了这些主码属性。7.27--53实体集Vs.联系集银行贷款的建模一种方法假设银行贷款通过一个实体来建模。另一种方法，不将贷款做为一个实体，而将其作为