数据库系统设计_银行业务管理系统

根据下面的需求描述,使用Sybase Power Designer设计相应的数据库概念模型,并转换成Oracle或MS SQL Server上的物理数据库结构。

[背景需求]

某银行准备开发一个银行业务管理系统,通过调查,得到以下的主要需求:

银行有多个支行。各个支行位于某个城市,每个支行有唯一的名字。银行要监控每个支行的资产。 银行的客户通过其身份证号来标识。银行存储每个客户的姓名及其居住的街道和城市。客户可以有帐户,并且可以贷款。客户可能和某个银行员工发生联系,该员工是此客户的贷款负责人或银行帐户负责人。 银行员工也通过身份证号来标识。员工分为部门经理普通员工,每个部门经理都负责领导其所在部门的员工,并且每个员工只允许在一个部门内工作。每个支行的管理机构存储每个员工的姓名电话号码家庭地址及其经理的身份证号。银行还需知道每个员工开始工作的日期,由此日期可以推知员工的雇佣期。 银行提供两类帐户——储蓄帐户支票帐户。帐户可以由2个或2个以上客户所共有,一个客户也可有两个或两个以上的帐户。每个帐户被赋以唯一的帐户号。银行记录每个帐户的余额开户的支行以及每个帐户所有者访问该帐户的最近日期。另外,每个储蓄帐户有其利率,且每个支票帐户有其透支额。 每笔贷款由某个分支机构发放,能被一个或多个客户所共有。每笔贷款用唯一的贷款号标识。银行需要知道每笔贷款所贷金额以及逐次支付的情况(银行将贷款分几次付给客户)。虽然贷款号不能唯一标识银行所有为贷款所付的款项,但可以唯一标识为某贷款所付的款项。对每次的付款需要记录日期金额

[需求分析]

1、实体的确定:

a.从背景需求中首先可以大致确定几大实体,包括:支行、客户、员工、账户、贷款。因为这些对象都有明显的若干属性,故可以将它们设计为实体。

b.接着让我们分析某些不太确定的对象。

首先是经理,我们的问题是是否将经理设置为单独的实体,从给出的需求来看,经理是员工的一种,但是没有特殊的属性来标识,且每个员工需要一个经理的身份证号,由此看来,我们不需要将经理设置为单独的实体,只需要给“员工”实体一个一对多、指向自己的“经理”联系即可,这样在生成物理模型的时候自动将经理的身份证号添加到“员工”属性中(当然经理的此属性是自己的身份证号)。

接着是“储蓄账户”和“支票账户”,从需求描述来看,这两个对象都有各自的属性:利率和透支额。且它们是“账户”的子集,所以,自然将这两个对象设置为实体,并且继承“账户”。

最后是逐次支付情况,贷款的支付不是一次性的,而“贷款”的主键贷款号无法标识逐次支付情况,如果将每次支付的日期和金额设计为“贷款”的属性,那么相对“贷款”的其他属性来说会产生冗余,造成空间的浪费,故我们将“支付情况”设计为一个单独的实体。由于“支付情况”这个实体对“贷款”产生依赖,所以必须将“支付情况”设计成若实体。

2、联系的确定:

a.根据需求,首先确定几个明显的联系:

l 支行:账户  (1 :N)————开户

l 支行:贷款  (1 :N)————发放

l 贷款:客户  (1 :N)————拥有

l 员工:员工  (1 :N)————经理

b.两个扩展的联系:

l 存储账户/支票账户:账户   ————继承

l 贷款:支付情况  (1 :N)————逐次支付(依赖)

c. 有属性的联系:

假设一个员工只能在一个支行工作,则员工的开始工作日期是在和支行发生联系的时候产生的,故将其设置为联系的属性:

l 支行:员工  (1 :N,开始工作日期)————工作

同样,员工可能是某客户的账户负责人或贷款负责人,故在员工和客户发生联系的时候必须标明负责人的类型:

l 客户:员工  (M :N,负责人类型)  ————负责

账户中需要标明账户所有者最近访问的日期,该日期是账户所有者(即客户)和账户发生访问联系的时候产生的,故将其设计为联系的属性:

l 客户:账户  (M :N,最近访问日期)————拥有

[概念模型设计&物理模型生成]

1、根据需求分析设计概念模型CDM(基于PowerDesign):

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzgsxx.html