• 银行按分支机构组织，每个分支机构位于特定城市，以唯一名称标识。
• 客户关联特定银行职员，该职员可作为其私人银行家。
• 银行职员（银行家）通过employee-id唯一标识，银行需存储其姓名、电话号码及地址。
• 部分职员担任经理角色，每位经理管理多名职员，每位职员仅向一位经理汇报；每个分支机构仅有一位经理，每位职员仅能管理一个分支机构及该机构内的职员。
• 银行提供储蓄账户和活期账户两种类型，两类账户均可由多名客户持有（如联名账户），一位客户可拥有多个账户。
• 此外，每个储蓄账户设有利率，每个活期账户需记录透支额度。

咱们结合上面的业务规范，来逐一检查你的实体、关系和基数设计是否匹配：

实体部分 #

首先，核心实体必须包含：分支机构、银行职员、客户，以及对应两种账户的储蓄账户和活期账户（或者用一个统一的账户实体加类型属性，不过业务明确区分两种账户的专属属性，拆成两个实体更清晰）。如果你的ER图里缺了这些实体中的任何一个，那就是设计遗漏啦。

关系与基数细节核对 #

1. 分支机构和经理（职员）的关系
   业务明确要求「每个分支机构仅有一位经理，每位职员仅能管理一个分支机构」，所以这里的关系应该是1对1：一个分支机构对应唯一一位经理，一位经理只能管理一个分支机构。另外，经理和普通职员的层级关系是1对多：一位经理可以管多名职员，每位职员只向一位经理汇报，这个层级关系可不能漏哦。

2. 客户和银行职员的关系
   业务说客户关联特定职员作为私人银行家，这里的基数应该是1对多：一位职员可以作为多个客户的私人银行家，而一位客户通常对应一位专属的私人银行家（如果业务没说允许多个，按常规场景是1对多）。

3. 客户和账户的关系
   重点来了！业务提到「两类账户均可由多名客户持有（联名账户），一位客户可拥有多个账户」，这明显是多对多的关系——一个账户可以被多个客户共同持有，一个客户也能开多个账户。如果你的ER图里把这个设计成了一对多，那可就没法支持联名账户的场景了，得用中间关联表来实现多对多哦。

4. 账户类型的处理
   储蓄账户有专属的「利率」属性，活期账户有专属的「透支额度」属性。如果你用了统一的「账户」实体，那要么给实体加类型属性，同时允许利率/透支额度为空（对应不同类型）；要么用子类继承的方式，把储蓄账户和活期账户作为账户的子实体，这样更符合规范。如果拆成两个独立实体，那各自都要和客户建立多对多关系。

常见的错误点提醒 #

• 要是没体现经理管理普通职员的1对多层级关系，那就不符合业务里的汇报机制要求；
• 分支机构和经理的关系如果不是1对1，也违背了「每个分支仅一位经理、一位经理仅管一个分支」的规则；
• 客户和账户的关系如果不是多对多，就没法实现联名账户的业务场景。

内容的提问来源于stack exchange，提问作者Matt.C