MySQL（高级特性篇）11章——数据库的设计规范

一、为什么需要数据库设计

1. 设计数据表时需考虑的问题：
   1. 数据需求：明确用户需要的数据以及需要在数据表中保存的数据
   2. 数据正确性：在插入、删除、更新数据时，确定进行怎样的约束检查来保证数据的正确性
   3. 数据冗余：思考如何降低数据表的数据冗余度，防止数据表因用户量增长而迅速扩张
   4. 数据库维护便利性：考虑如何让负责数据库维护的人员更方便地使用数据库
2. 数据库设计的多样性：由于使用数据库的应用场景各不相同，针对不同情况设计出来的数据表也千差万别
3. 糟糕数据库设计的问题：
   1. 数据冗余：导致数据冗余、信息重复，造成存储空间浪费
   2. 操作异常：引发数据更新、插入、删除的异常
   3. 信息表示问题：无法正确表示信息，甚至丢失有效信息
   4. 程序性能：使程序性能变差
4. 良好数据库设计的优点
   1. 节省空间：节省数据的存储空间
   2. 保证完整性：能够保证数据的完整性
   3. 方便开发：方便进行数据库应用系统的开发
5. 总结：开始设置数据库时就需要重视数据表的设计，为建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则

二、范式

（1）范式简介

1. 数据库设计的重要性
   1. 设计需考虑多方面：设计数据表时，要考虑用户数据需求、数据正确性保证、降低数据冗余、方便数据库维护人员使用等问题
   2. 设计因场景而异：不同的数据库应用场景，设计出的数据表差别很大
   3. 糟糕设计的后果：可能导致数据冗余、操作异常、信息表示错误、程序性能差等问题
   4. 良好设计的优点：节省存储空间、保证数据完整性、方便数据库应用系统开发
2. 范式的概念
   1. 定义：在关系型数据库中，数据表设计的基本原则和规则被称为范式
   2. 作用：想要设计出好用的关系型数据库，就得符合范式要求
   3. 简称：范式英文名是 Normal Form，简称 NF

（2）范式都包括哪些

1. 常见范式及级别排序：关系型数据库有六种常见范式，按从低到高的级别依次是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯 - 科德范式（BCNF）、第四范式（4NF）、第五范式（5NF，又称完美范式）
2. 范式与冗余度的关系：范式设计越高阶，数据库冗余度就越低，并且高阶范式必然符合低阶范式的要求
3. 各范式的递进关系：满足最低要求的是第一范式（1NF），在 1NF 基础上满足更多规范要求的是第二范式（2NF），后续范式依此类推
4. 实际应用中的范式遵循：在 MySQL 等关系型数据库设计中，通常最高遵循到 BCNF，普遍遵循 3NF。但这不是绝对的，有时为了提高某些查询性能，会采用反规范化，即破坏范式规则

（3）键和相关属性的概念

1. 键与属性的基本定义
   1. 超键：在 MySQL 数据库里，能唯一确定一条记录（元组）的属性集合就是超键。比如在一个记录用户信息的表中，“身份证号” 能唯一标识一个用户，那 “身份证号” 就是一个超键；若 “手机号” 也能唯一标识用户，那 “手机号” 也是超键；甚至 “身份证号，姓名” 组合起来也能唯一标识，这也是超键
   2. 候选键：候选键是没有多余属性的超键。例如在上述用户信息表中，如果 “身份证号” 和 “手机号” 都能单独唯一标识用户，且没有多余属性，那 “身份证号” 和 “手机号” 就是候选键
   3. 主键：从候选键里由用户挑选出来的一个，用来唯一标识表中记录。如在用户信息表中，我们选 “身份证号” 作为主键。
   4. 外键：若表 A 中的某个属性集不是表 A 的主键，但却是表 B 的主键，那这个属性集就是表 A 的外键。比如有订单表和用户表，用户表中 “用户 ID” 是主键，订单表中也有 “用户 ID”，但它不是订单表主键，此时订单表中的 “用户 ID” 就是外键，用于关联两个表的数据
   5. 主属性：包含在任何一个候选键中的属性。在用户信息表中，若 “身份证号” 和 “手机号” 是候选键，那 “身份证号” 和 “手机号” 就是主属性
   6. 非主属性：不包含在任何候选键中的属性。在用户信息表中，若 “地址” 不在任何候选键里，那 “地址” 就是非主属性
2. 举例说明
   1. 球员表：表结构为 球员编号 | 姓名 | 身份证号 | 年龄 | 球队编号
   2. 超键：像（球员编号）、（球员编号，姓名）、（身份证号，年龄）等只要包含球员编号或者身份证号的任意组合都是超键
   3. 候选键：（球员编号）和（身份证号）是最小的超键，所以是候选键
   4. 主键：从候选键中选择（球员编号）作为主键
   5. 外键：球队编号是外键，因为它不是球员表主键，却是球队表主键
   6. 主属性和非主属性：主属性是（球员编号）、（身份证号）；非主属性是（姓名）、（年龄）、（球队编号）
   7. ​​​​​​​球队表：表结构为球队编号 | 主教练 | 球队所在地 ，球队编号是主键，用于和球员表关联

（4）第一范式（1st NF）

1. 定义：在 MySQL 数据库设计中，第一范式要求数据表中每个字段的值具有原子性，即每个字段的值是不可再拆分的最小数据单元。例如在设计 “地址” 字段时，不能把它拆分成 “省份”“城市”“街道” 等子字段（字段 X 不能拆分成字段 X - 1 和字段 X - 2 ）
2. 特性：实际上，任何的数据库管理系统（DBMS），包括 MySQL，都会默认满足第一范式的要求，不会自动将字段进行拆分
3. 举例1：
4. 举例2：
5. 举例3：

（5）第二范式（2nd NF）

1. 前提条件：在 MySQL 数据库设计里，满足第二范式的前提是先满足第一范式
2. 唯一性要求：数据表中的每一条数据记录都必须能够被唯一标识。比如在订单表中，若以 “订单编号” 作为主键，那每一个订单编号都对应唯一的一条订单记录
3. 完全依赖要求：在满足第二范式的数据库设计里，要获取非主属性的值，得依靠完整的主键（或候选键）来精准定位到对应的记录
4. 举例1：
5. 举例2：为了避免出现上述的情况，我们可以把球员比赛表设计为下面的三张表：

   表名	字段
   球员player表	球员编号、姓名和年龄等信息
   比赛game表	比赛编号、比赛时间和比赛场地等信息
   球员比赛关系player_game表	球员编号、比赛编号和的风等属性

   这样的话，每张数据表都符合第二范式，也就避免了异常情况的发生                                      

6. 1NF告诉我们字段属性是需要原子性的，而2NF告诉我们一张表就是一个独立的对象，一张表只表达一个意思
7. 举例3：
8. 第二范式（2NF）基于满足第一范式，有两个关键要点：

（6）第三范式（3rd NF）

1. 前提条件：满足第二范式是满足第三范式的基础
2. 核心要求：
   1. 数据表中的每个非主键字段（非主属性）都要和主键（或候选键）直接相关
   2. 所有非主键字段之间不能存在依赖关系，也就是非主属性不能依赖于其他非主属性。不能出现非主属性 A 依赖非主属性 B，而 B 又依赖主键 C 这种 “A→B→C” 的决定关系。简单来说，非主键属性之间必须相互独立
3. 拓展说明：这里提及的主键在实际应用中可拓展理解为候选键，同样适用于上述规则
4. 举例1：
5. 举例2：
6. 总结：

（7）小结

1. 第一范式（1NF）：确保数据表的每一列都是不可再分的最小数据单元，具有原子性，不能是集合、数组、记录等非原子数据项
2. 第二范式（2NF）：在满足 1NF 的基础上，确保非主键列完全依赖于整个主键，而非部分主键
3. 第二范式（2NF）：在满足 2NF 的基础上，确保每列都直接依赖于主键，不存在非主键列之间的间接依赖
4. 范式的优缺点：
   1. 优点：数据标准化有助于消除数据库中的数据冗余，其中 3NF 通常在性能、扩展性和数据完整性方面达到较好平衡
   2. 缺点：范式等级越高，数据表越多、越精细，数据冗余度越低。这可能导致查询时需要关联多张表，增加查询代价，还可能使部分索引策略失效，降低查询效率
   3. 实际应用策略：范式仅为设计标准，实际设计数据表时不一定要严格遵循。开发中，为提升性能和读取效率，可能违反范式化原则，通过增加少量数据冗余或重复数据，减少关联查询和 JOIN 表的次数，实现以空间换时间。因此，需理论结合实际，灵活运用范式。范式本身无绝对优劣，只有适用场景不同，实际设计可将范式和反范式混合使用

三、反范式化

（1）概述

1. 业务优先原则：在数据表设计中，不能单纯依照规范要求。部分看似冗余的数据对业务意义重大，此时应优先满足业务需求，再尽力降低数据冗余
2. 数据量大、高访问下的设计考量：当数据库数据量庞大，系统的 UV（独立访客数）和 PV（页面浏览量）访问频次高时，完全遵循 MySQL 三大范式设计数据表，会在读取数据时产生大量关联查询，影响数据库读性能。这种情况下，反范式优化是一种可考虑的思路，即通过在数据表中添加冗余字段来提升数据库读性能
3. 规范化与性能权衡：
   1. 性能优先：为达成某些商业目标，数据库性能比数据规范化更为重要
   2. 综合考量：在进行数据规范化设计时，要全面兼顾数据库性能
   3. 优化手段：（1）添加额外字段：在表中添加额外字段，可大幅减少搜索信息的时间（2）插入计算列：在表中插入计算列，便于进行数据查询

（2）应用举例

1. 举例1：
2. 举例2：
3. 举例3：
4. 举例4：

（3）反范式的新问题

1. 空间占用问题：反范式通过增加冗余数据以空间换时间提升查询效率，这会使数据库存储空间需求增大
2. 数据一致性问题：由于存在冗余字段，当一个表中的字段修改时，其他表中对应的冗余字段也需同步修改，否则会出现数据不一致的情况
3. 系统资源消耗问题：若使用存储过程进行数据的更新、删除等操作，在更新操作频繁时，会大量消耗系统资源
4. 小数据量场景劣势：数据量较小时，连接查询速度快。此时采用反范式难以显著提升查询速度，无法体现性能优势，还会增加数据冗余，造成存储空间的浪费，让数据库设计与维护更复杂

（4）反范式的适用场景

当冗余信息有价值或者能大幅度提高查询效率的时候，才会采取反范式的优化

3.4.1增加冗余字段的建议

考虑增加冗余字段时，需满足两个条件：

1. 该冗余字段无需经常修改
2. 该冗余字段在查询时必不可少

3.4.2历史快照、历史数据的需要

1. 历史快照与历史数据需求：在实际场景里，冗余信息十分必要。例如订单中的收货人姓名、电话、地址等信息属于历史快照，需保存。即便用户会修改自身信息，保存这些冗余数据仍意义重大
2. 反范式优化在数据仓库的应用：反范式优化常用于数据仓库设计。数据仓库多存储历史数据，对增删改实时性要求不高，但对历史数据分析需求强烈。适当增加数据冗余度，更便于数据分析
3. 数据仓库和数据库使用区别：

   对比项	数据库	数据仓库
   设计目的	捕获数据	分析数据
   数据实时性	对数据增删改实时性要求强，存储在线用户数据	一般存储历史数据
   冗余处理	尽量避免冗余，为提高查询效率可允许一定冗余度	适当允许较高冗余度以方便分析

四、BCNF（巴斯范式）

1. 定义与本质：
   1. 人们在第三范式（3NF）基础上改进提出巴斯范式（BCNF），也叫巴斯 - 科德范式（Boyce - Codd Normal Form）
   2. BCNF 没有引入新的设计规范，只是强化了 3NF 的设计要求，让数据库冗余度更低，因此也被称为修正的第三范式或扩充的第三范式，但不叫第四范式
2. 自然达到 BCNF 的条件：若一个关系满足第三范式，且它只有一个候选键，或者每个候选键都只包含单个属性，那么该关系自然满足 BCNF
3. 设计标准建议：一般情况下，数据库设计满足 3NF 或 BCNF 即可
4. 案例：
5. 数据表范式符合情况：
   1. 第一范式（1NF）：数据表的每个属性都具有原子性，满足 1NF 的要求
   2. 第二范式（2NF）：数据表中的非主属性 “数量” 完全依赖于候选键，如（仓库名，物品名）能决定 “数量”，（管理员，物品名）也能决定 “数量”，所以符合 2NF 的要求
   3. 第三范式（3NF）：数据表中的非主属性不存在对候选键的传递依赖，因此符合 3NF 的要求
6. 存在的问题：
   1. 插入异常：当要增加一个新仓库但还未存放物品时，由于数据表实体完整性要求主键不能有空值，会导致无法插入数据
   2. 更新异常：若仓库更换管理员，可能需要修改数据表中的多条记录
   3. 删除异常：若仓库里的商品全部卖空，仓库名称和相应的管理员名称也会被删除
7. 结论：即使数据表符合 3NF 的要求，仍可能出现插入、更新和删除数据的异常情况
8. 问题解决：
   1. 数据表符合 3NF 仍存在插入、更新和删除异常，原因是主属性 “仓库名” 对候选键（管理员，物品名）存在部分依赖。为解决此问题，引入 BCNF，它在 3NF 基础上消除主属性对候选键的部分或传递依赖关系
   2. 解决方案：

五、第四范式

1. 多值依赖的概念：
   1. 多值依赖定义：多值依赖体现属性间的一对多关系，记作 K →→ A
   2. 函数依赖与多值依赖对比：函数依赖本质是单值依赖，无法表达属性值间的一对多关系，而多值依赖可以
   3. 平凡的多值依赖：当全集 U = K + A 时，一个 K 能对应多个 A（即 K →→ A），此时全量数据就是一组一对多关系
   4. 非平凡的多值依赖：当全集 U = K + A + B 时，一个 K 既能对应多个 A，也能对应多个 B，且 A 与 B 相互独立（即 K →→ A，K →→ B）。此时全量数据有多组一对多关系，其中 “一” 的部分是相同属性集合，“多” 的部分是相互独立的属性集合
2. 举例1：
3. 举例2：

六、第五范式、域键范式

1. 除了第四范式外，还有更高级的第五范式（又称完美范式）和域键范式（DKNF）
2. 在满足第四范式（4NF）的基础上，消除不是由候选键所蕴含的连接依赖。如果关系模式R中的每一个连接依赖均由R的候选键所隐含，则称此关系模式符合第五范式
3. 函数依赖是多值依赖的一种特殊的情况，而多值依赖实际上是连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖可以由语义直接导出，而是在关系连接运算时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题
4. 第五范式处理的是无损连接问题，这个范式基本没有实际意义，因为无损连接很少出现，而且难以察觉。而域键范式试图定义一个终极范式，该范式考虑所有的依赖和约束类型，但是实用价值也是最小的，只存在理论研究中

七、实战案例

（1）迭代1次：考虑1NF

1. 第一范式要求数据表的所有字段为基本数据字段，不可再拆分，确保每列中的每个字段仅包含一种数据
2. 这张表里，我们把“property”这一字段，拆分成“specification（规格）”和“unit（单位）”，这2个字段如下：

（2）迭代2次：考虑2NF

1. 第二范式要求：在满足第一范式的基础上，数据表中每条记录需可唯一标识，所有字段必须完全依赖主键，不能只依赖主键的一部分
2. 应用步骤：
   1. 步骤一，确定主键：通过观察表中字段，发现 “listnumber (单号)” 和 “barcode (条码)” 组合能唯一标识每条记录，将其确定为主键
   2. 步骤二，拆分字段：确定主键后，判断字段对主键的依赖情况，把只依赖主键一部分的字段拆分出去形成新表。例如，进货单明细表中的 “goodsname (名称)”“specification (规格)”“unit (单位)” 只依赖 “barcode (条码)”，不完全依赖主键，将这 3 个字段和 “barcode (条码)” 拆分出来，形成新的数据表 “商品信息表”；“supplierid（供应商编号）”“suppliername（供应商名称）”“stock（仓库）” 只依赖 “listnumber（单号）”，不完全依赖主键，把这 3 个字段和 “listnumber（单号）” 拆分出来，形成新的数据表 “进货单头表”，剩余字段组成 “进货单明细表”
   3. 步骤三，为新表设置主键：在 “商品信息表” 中，“barcode” 可能重复，无法唯一标识记录，需添加主键，如自增字段 “itemnumber”。之后，将进货单明细表中的 “barcode” 替换为 “itemnumber”，得到新表

（3）迭代3次：考虑3NF

进货单头表还有数据冗余的可能。因为“supplername "依赖"supplierid"那么，这个时候，就可以按照第三范式的原则进行拆分了。进一步拆分一下进货单头表，把它拆解成供货商表和进货单头表

（4） 反范式化：业务优先的原则

1. 冗余字段问题与理论优化：进货单明细表中，“quantity（数量）”“importprice（进货价格）”“importvalue（进货金额）” 存在计算关系，按第三范式要求可删除其一以消除冗余
2. 业务优先原则：实际工作中应遵循业务优先原则，技术服务于业务，不能仅依据理论设计，要结合实际情况决定
3. 保留冗余字段的必要性：“importvalue” 看似冗余且不会致数据不一致，但取消该字段会影响业务。因供货商促销时进货单可能只有金额无价格，“importprice” 需由 “importvalue” 和 “quantity” 计算得出，四舍五入产生的误差日积月累会使查询结果偏差大，影响系统可靠性
4. 误差示例：如进货金额 25.5 元、数量 34，算出进货价格 0.74 元，再用此价格算进货金额为 25.16 元，相差 0.34 元

八、ER模型

数据库设计的整体性需求：数据库设计关联性强，需要提前了解数据库全貌，包括所需数据表、表中字段、表间关系及连接字段等，以便进行整体梳理和设计

ER 模型的定义：ER 模型即实体关系模型，是用于描述现实中事物、事物属性及事物间关系的数据模型

ER 模型的作用：在基于数据库的信息系统设计阶段，常使用 ER 模型描述信息需求和特性，有助于理清业务逻辑，设计出优秀的数据库

（1）ER模型包括哪些要素

1. 实体：
   1. 可看作数据对象，对应现实中真实个体，在 ER 模型中用矩形表示
   2. 分为强实体（不依赖其他实体）和弱实体（依赖其他实体）
2. 属性：
   1. 指实体的特性，如超市的地址、联系电话、员工数等，在 ER 模型中用椭圆形表示
   2. 不可再分，不能包含其他属性
3. 关系：指实体之间的联系，如超市与顾客的买卖联系，在 ER 模型中用菱形表示
4. 区分原则：从系统整体看，可独立存在的是实体，不可再分的是属性

（2）关系的类型

1. 一对一关系：
   1. 定义：实体间是一一对应的关系
   2. 示例：个人与身份证信息，一个人对应一个身份证信息，一个身份证信息也只属于一个人
2. 一对多关系：
   1. 定义：一边实体通过关系可对应多个另一边实体，另一边实体通过该关系只能对应唯一的一边实体
   2. 示例：班级与学生，一个班级可有多个学生，每个学生只对应一个班级
3. 多对多关系：
   1. 定义：关系两边的实体都能通过关系对应多个对方的实体
   2. 示例：供货商与超市，一个供货商可为多个超市供货，一个超市可从多个供货商采购；选课表中科目与学生，每个科目有多个学生选，每个学生可选择多个科目

（3）建模分析

1. ER 模型虽看似复杂，但对把控项目整体至关重要。开发小应用时，简单设计表或许可行；而设计有一定规模的应用，在项目初始阶段建立完整的 ER 模型极为关键。开发应用项目的实质就是建模

2. 此处设计的案例是电商业务，由于电商业务太过庞大且复杂，所以做了业务简化，比如针对SKU(StockKeepingUnit，库存量单位）和SPU(Standard Product Unit，标准化产品单元)的含义上，直接使用了SKU，并没有提及SPU的概念。本次电商业务设计总共有8个实体，如下所示

3. 其中，用户和商品分类是强实体，因为它们不需要依赖其他任何实体。而其他同于弱实体，因为它们虽然都可以独立存在，但是它们都依赖用户这个实体，因此都是弱实体。知道了这些要素就可以给电商业务创建ER模型了，如图：

（4）ER模型的细化

1. 通过 ER 模型可整体理解电商业务，此前展示的 ER 模型呈现了电商业务框架，涵盖订单、地址、用户等八个实体及其关系，但未对应具体表和表间关联。添加用椭圆表示的属性后，ER 模型将更加完整

2. 因此需要进一步去设计一下这个ER模型的各个局部，也就是细化下电商的具体业务流程，然后把它们综合到一起，形成一个完整的ER模型。这样可以理清数据库的设计思路。接下来再分析一下各个实体都有哪些属性，如下所示

3. 这样细分之后就可以重新设计电商业务了，ER 模型如图：

（5）ER模型图转换成数据表

1. 通过绘制 ER 模型已经理清了业务逻辑，现在就要进行非常重要的一步了：把绘制好的 ER模型，转换成具体的数据表，下面介绍下转换的原则：
   1. 一个实体通常转换成一个数据表
   2. 一个多对多的关系，通常也转换成一个数据表
   3. 一个1对1的关系，或者1对多的关系，往往通过表的外键来表达，而不是设计一个新的数据表
   4. 属性转换成表的字段
2. 其实，任何一个基于数据库的应用项目，都可以通过这种先建立ER 模型 ，再转换成数据表的方式，完成数据库的设计工作。创建ER模型不是目的，目的是把业务逻辑梳理清楚，设计出优秀的数据库。不是为了建模而建模，要利用创建ER模型的过程来整理思路，这样创建ER模型才有意义

九、数据表的设计原则

1. 数据表个数越少越好：RDBMS 核心是实体和联系的定义，数据表少意味着实体和联系设计简洁，便于理解与操作
2. 数据表中字段个数越少越好：字段多会增加数据冗余可能性，应保证字段相互独立，避免由其他字段计算得出取值。实际需在数据冗余和检索效率间平衡
3. 数据表中联合主键字段个数越少越好：设置主键为确定唯一性，需联合主键时，字段越多，索引空间占用越大，会增加理解难度、运行时间和索引空间
4. 使用主键和外键越多越好：数据库设计是定义表和字段关系，关系多则实体冗余度低、利用度高，可保证数据表独立性并提升关联使用率
5. 原则核心：简单可复用。简单体现在用更少的表、字段、联合主键字段设计；可复用通过主键、外键增强数据表复用率，键设计越多利用率越高

十、数据库对象编写建议

（1）关于库

（2）关于表、列

（3）关于索引

（4）SQL编写

十一、PowerDesigner的使用 

PowerDesigner 是开发人员常用的数据库建模工具，用户能借助它便捷制作数据流程图、概念数据模型、物理数据模型，涵盖数据库模型设计全过程，是 Sybase 公司提供的完整集成化企业级建模解决方案

（1）开始界面

1. 当前使用的PowerDesigner版本是16.5的。打开软件即是此页面，可选择Create Model,也可以选择Do Not Show page Again,自行在打开软件后创建也可以！完全看个人的喜好
2. “Create Model”的作用类似于普通的一个文件，该文件可以单独存放也可以归类存放
3. “Create Project”的作用类似于文件夹，负责把有关联关系的文件集中归类存放

（2）概念数据模型

常用的模型有4种，分别是 概念模型(CDM Conceptual Data Model) ， 物理模型（PDM,Physical Data Model） ， 面向对象的模型（OOM Objcet Oriented Model） 和 业务模型（BPM Business Process Model） ，我们先创建概念数据模型

点击上面的ok，即可出现下图左边的概念模型1，可以自定义概念模型的名字，在概念模型中使用最多的 就是如图所示的Entity(实体),Relationship(关系)

11.2.1Entity实体

选中右边框中Entity这个功能，即可出现下面这个方框，需要注意的是书写name的时候，code自行补 全，name可以是英文的也可以是中文的，但是code必须是英文的

11.2.2填充实体字段

General中的name和code填好后，就可以点击Attributes（属性）来设置name（名字），code(在数据库中 的字段名)，Data Type(数据类型) ，length(数据类型的长度)

1. Name: 实体名字一般为中文，如论坛用户
2. Code: 实体代号，一般用英文，如XXXUser
3. Comment:注释，对此实体详细说明
4. Code属性：代号，一般用英文UID DataType
5. Domain域，表示属性取值范围如可以创建10个字符的地址域
6. M:Mandatory强制属性，表示该属性必填。不能为空
7. P:Primary Identifer是否是主标识符，表示实体唯一标识符
8. D:Displayed显示出来，默认全部勾选

11.2.3设置主标识符

若不想让系统自动生成标识符，可手动设置：切换至 Identifiers 选项卡，添加一行 Identifier，点击左上角“属性”按钮，在弹出的标识属性设置对话框中点击“添加行”按钮，选择该标识所用属性，如可将学号设为学生实体的标识

11.2.4放大模型

创建好的概念数据模型字体较小，读者可按住 Ctrl 键并滑动鼠标可滑动按钮来放大或缩小字体。同时，主标识符会显示 * 号标志，name、Data type 和 length 等可见属性也会呈现出来

11.2.5实体关系

1. 同理可创建班级实体，需注意点击右边功能按钮后，点击鼠标指针状态按钮或右击鼠标，避免误操作。之后使用 “Relationship（关系）” 按钮连接学生和班级实体，二者会形成一对多（班级对学生）或多对一（学生对班级）的关系
2. 需要注意的是点击Relationship这个按钮，就把班级和学生联系起来了，就是一条线，然后双击这条线进行编辑，在General这块起name和code
3. 上面的name和code起好后就可以在Cardinalities这块查看班级和学生的关系，可以看到班级的一端是一 条线，学生的一端是三条，代表班级对学生是一对多的关系即one对many的关系，点击应用，然后确定 即可
4. 一对多和多对一练习完还有多对多的练习，如下图操作所示，老师实体和上面介绍的一样，自己将 name，data type等等修改成自己需要的即可，满足项目开发需求即可
5. 多对多需要注意的是自己可以手动点击按钮将关系调整称为多对多的关系many对many的关系，然后点 击应用和确定即可
6. 综上即可完成最简单的学生，班级，教师这种概念数据模型的设计，需要考虑数据的类型和主标识码， 是否为空。关系是一对一还是一对多还是多对多的关系，自己需要先规划好再设计，然后就ok了

（3）物理数据模型

1. 上面是概念数据模型，下面介绍一下物理数据模型，以后 经常使用 的就是物理数据模型。打开 PowerDesigner，然后点击File-->New Model然后选择如下图所示的物理数据模型，物理数据模型的名字 自己起，然后选择自己所使用的数据库即可
2. 创建好主页面如图所示，但是右边的按钮和概念模型略有差别，物理模型最常用的三个是 table(表) ， view(视图) ， reference(关系) ；
3. 鼠标先点击右边table这个按钮然后在新建的物理模型点一下，即可新建一个表，然后双击新建如下图所 示，在General的name和code填上自己需要的，点击应用即可），如下图：
4. 然后点击Columns,如下图设置，非常简单，需要注意的就是P（primary主键） , F （foreign key外键） , M（mandatory强制性的，代表不可为空） 这三个
5. 在此设置学号的自增（MYSQL里面的自增是这个AUTO_INCREMENT），班级编号同理，不多赘述！
6. 在下面的这个点上对号即可，就设置好了自增
7. 全部完成后如下图所示：
8. 班级物理模型同理如下图所示创建即可
9. 完成后如下图所示
10. 上面的设置好如上图所示，然后下面是关键的地方，点击右边按钮Reference这个按钮，因为是班级对学 生是一对多的，所以鼠标从学生拉到班级如下图所示，学生表将发生变化，学生表里面增加了一行，这 行是班级表的主键作为学生表的外键，将班级表和学生表联系起来。（仔细观察即可看到区别。）
11. 做完上面的操作，就可以双击中间的一条线，显示如下图，修改name和code即可
12. 但是需要注意的是，修改完毕后显示的结果却如下图所示，并没有办法直接像概念模型那样，修改过后 显示在中间的那条线上面，自己明白即可
13. 学习了多对一或者一对多的关系，接下来学习多对对的关系，同理自己建好老师表，这里不在叙述，记 得老师编号自增，建好如下图所示
14. 下面是多对多关系的关键，由于物理模型多对多的关系需要一个中间表来连接，如下图，只设置一个字 段，主键，自增
15. 点击应用，然后设置Columns，只添加一个字段
16. 这是设置字段递增，前面已经叙述过好几次
17. 设置好后如下图所示，需要注意的是有箭头的一方是一，无箭头的一方是多，即一对多的多对一的关系 需要搞清楚，学生也可以有很多老师，老师也可以有很多学生，所以学生和老师都可以是主体
18. 可以看到添加关系以后学生和教师的关系表前后发生的变化

（4）概念模型转为物理模型

1. 如下图所示先打开概念模型图，然后点击Tool,如下图所示
2. 点开的页面如下所示，name和code已经从概念模型1改成物理模型1了
3. 完成后如下图所示，将自行打开修改的物理模型，需要注意的是这些表的数据类型已经自行改变了，而 且中间表出现两个主键，即双主键

（5）物理模型转为概念模型

1. 上面介绍了概念模型转物理模型，下面介绍一下物理模型转概念模型（如下图点击操作即可）
2. 然后出现如下图所示界面，然后将物理修改为概念 ，点击应用确认即可
3. 点击确认后将自行打开如下图所示的页面，自己观察有何变化，如果转换为oracle的，数据类型会发生变 化，比如Varchar2等等） 

（6）物理模型导出SQL语句

1. 下面介绍一下物理模型导出SQL语句（点击Database按钮的Generate Database或者按ctrl+G）
2. 打开之后如图所示，修改好存在sql语句的位置和生成文件的名称即可
3. 在Selection中选择需要导出的表，然后点击应用和确认即可
4. 完成以后出现如下图所示，可以点击Edit或者close按钮
5. 自此，就完成了导出sql语句，就可以到自己指定的位置查看导出的sql语句了；PowerDesigner在以后在 项目开发过程中用来做需求分析和数据库的设计非常的方便和快捷