根据下面的需求描述，使用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)：