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

一、为什么需要数据库筹划

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

二、范式

（1）范式简介

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

（2）范式都包罗哪些

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

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

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

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

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

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

• 前提条件：在 MySQL 数据库筹划里，满意第二范式的前提是先满意第一范式
  
• 唯一性要求：数据表中的每一条数据记录都必须能够被唯一标识。比如在订单表中，若以 “订单编号” 作为主键，那每一个订单编号都对应唯一的一条订单记录
  
• 完全依靠要求：在满意第二范式的数据库筹划里，要获取非主属性的值，得依靠完备的主键（或候选键）来精准定位到对应的记录
  
• 举例1：
  
  
  
• 举例2：
  
  
  为了制止出现上述的环境，我们可以把球员比赛表筹划为下面的三张表：   表名字段球员player表球员编号、姓名和年龄等信息比赛game表比赛编号、比赛时间和比赛场地等信息球员比赛关系player_game表球员编号、比赛编号和的风等属性 如许的话，每张数据表都符合第二范式，也就制止了异常环境的发生                                      
  
• 1NF告诉我们字段属性是需要原子性的，而2NF告诉我们一张表就是一个独立的对象，一张表只表达一个意思
  
• 举例3：
  
  
  
• 第二范式（2NF）基于满意第一范式，有两个关键要点：
  
  
  

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

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

（7）小结

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

三、反范式化

（1）概述

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

（2）应用举例

• 举例1：
  
  
  
• 举例2：
  
  
  
• 举例3：
  
  
  
  
• 举例4：
  
  
  

（3）反范式的新问题

• 空间占用问题：反范式通过增加冗余数据以空间换时间提升查询效率，这会使数据库存储空间需求增大
  
• 数据同等性问题：由于存在冗余字段，当一个表中的字段修改时，其他表中对应的冗余字段也需同步修改，否则会出现数据不同等的环境
  
• 系统资源消耗问题：若利用存储过程举行数据的更新、删除等操作，在更新操作频仍时，会大量消耗系统资源
  
• 小数据量场景劣势：数据量较小时，毗连查询速率快。此时接纳反范式难以明显提升查询速率，无法体现性能上风，还会增加数据冗余，造成存储空间的浪费，让数据库筹划与维护更复杂
  

（4）反范式的适用场景

当冗余信息有代价大概能大幅度进步查询效率的时候，才会采取反范式的优化
3.4.1增加冗余字段的建议

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

• 该冗余字段无需常常修改
  
• 该冗余字段在查询时必不可少
  

3.4.2汗青快照、汗青数据的需要

• 汗青快照与汗青数据需求：在现实场景里，冗余信息十分必要。例如订单中的收货人姓名、电话、地点等信息属于汗青快照，需保存。即便用户会修改自身信息，保存这些冗余数据仍意义庞大
  
• 反范式优化在数据仓库的应用：反范式优化常用于数据仓库筹划。数据仓库多存储汗青数据，对增删改及时性要求不高，但对汗青数据分析需求剧烈。适当增加数据冗余度，更便于数据分析
  
• 数据仓库和数据库利用区别：   对比项数据库数据仓库筹划目标捕获数据分析数据数据及时性对数据增删改及时性要求强，存储在线用户数据一样平常存储汗青数据冗余处置处罚尽量制止冗余，为进步查询效率可允许一定冗余度适当允许较高冗余度以方便分析
  

四、BCNF（巴斯范式）

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

五、第四范式

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

六、第五范式、域键范式

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

七、实战案例

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

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

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

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

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

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

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

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

八、ER模型

数据库筹划的整体性需求：数据库筹划关联性强，需要提前相识数据库全貌，包罗所需数据表、表中字段、表间关系及毗连字段等，以便举行整体梳理和筹划
ER 模型的定义：ER 模型即实体关系模型，是用于描述现实中事物、事物属性及事物间关系的数据模型
ER 模型的作用：在基于数据库的信息系统筹划阶段，常利用 ER 模型描述信息需求和特性，有助于理清业务逻辑，筹划出良好的数据库
（1）ER模型包罗哪些要素

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

（2）关系的类型

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

（3）建模分析

• ER 模型虽看似复杂，但对把控项目整体至关重要。开发小应用时，简单筹划表大概可行；而筹划有一定规模的应用，在项目初始阶段创建完备的 ER 模型极为关键。开发应用项目标实质就是建模
  
• 此处筹划的案例是电商业务，由于电商业务太过庞大且复杂，所以做了业务简化，比如针对SKU(StockKeepingUnit，库存量单位）和SPU(Standard Product Unit，尺度化产物单元)的含义上，直接利用了SKU，并没有提及SPU的概念。本次电商业务筹划统共有8个实体，如下所示
  
  
  
• 此中，用户和商品分类是强实体，因为它们不需要依靠其他任何实体。而其他同于弱实体，因为它们固然都可以独立存在，但是它们都依靠用户这个实体，因此都是弱实体。知道了这些要素就可以给电商业务创建ER模型了，如图：
  
  
  
  

（4）ER模型的细化

• 通过 ER 模型可整体明白电商业务，此前展示的 ER 模型呈现了电商业务框架，涵盖订单、地点、用户等八个实体及其关系，但未对应具体表和表间关联。添加用椭圆表现的属性后，ER 模型将更加完备
  
• 因此需要进一步去筹划一下这个ER模型的各个局部，也就是细化下电商的具体业务流程，然后把它们综合到一起，形成一个完备的ER模型。如允许以理清数据库的筹划思绪。接下来再分析一下各个实体都有哪些属性，如下所示
  
  
  
• 如许细分之后就可以重新筹划电商业务了，ER 模型如图：
  
  
  

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

• 通过绘制 ER 模型已司理清了业务逻辑，如今就要举行非常重要的一步了：把绘制好的 ER模型，转换成具体的数据表，下面先容下转换的原则：
  
  
  • 一个实体通常转换成一个数据表
    
  • 一个多对多的关系，通常也转换成一个数据表
    
  • 一个1对1的关系，大概1对多的关系，每每通过表的外键来表达，而不是筹划一个新的数据表
    
  • 属性转换成表的字段
    
  
  
• 其实，任何一个基于数据库的应用项目，都可以通过这种先创建ER 模型 ，再转换成数据表的方式，完成数据库的筹划工作。创建ER模型不是目标，目标是把业务逻辑梳理清楚，筹划出良好的数据库。不是为了建模而建模，要利用创建ER模型的过程来整理思绪，如许创建ER模型才故意义
  
  
  

九、数据表的筹划原则

• 数据表个数越少越好：RDBMS 核心是实体和接洽的定义，数据表少意味着实体和接洽筹划简洁，便于明白与操作
  
  
  
• 数据表中字段个数越少越好：字段多会增加数据冗余可能性，应保证字段相互独立，制止由其他字段盘算得出取值。现实需在数据冗余和检索效率间均衡
  
• 数据表中团结主键字段个数越少越好：设置主键为确定唯一性，需团结主键时，字段越多，索引空间占用越大，会增加明白难度、运行时间和索引空间
  
• 利用主键和外键越多越好：数据库筹划是定义表和字段关系，关系多则实体冗余度低、利用度高，可保证数据表独立性并提升关联利用率
  
  
  
• 原则核心：简单可复用。简单体如今用更少的表、字段、团结主键字段筹划；可复用通过主键、外键增强数据表复用率，键筹划越多利用率越高
  

十、数据库对象编写建议

（1）关于库

（2）关于表、列

（3）关于索引

（4）SQL编写

十一、PowerDesigner的利用 

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

• 当前利用的PowerDesigner版本是16.5的。打开软件便是此页面，可选择Create Model,也可以选择Do Not Show page Again,自行在打开软件后创建也可以！完全看个人的喜好
  
  
  
• “Create Model”的作用类似于普通的一个文件，该文件可以单独存放也可以归类存放
  
• “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(数据类型的长度)

• Name: 实体名字一样平常为中文，如论坛用户
  
• Code: 实体代号，一样平常用英文，如XXXUser
  
• Comment:解释，对此实体具体说明
  
• Code属性：代号，一样平常用英文UID DataType
  
• Domain域，表现属性取值范围如可以创建10个字符的地点域
  
• M:Mandatory强制属性，表现该属性必填。不能为空
  
• Primary Identifer是否是主标识符，表现实体唯一标识符
  
• Displayed显示出来，默认全部勾选
  

 

 
11.2.3设置主标识符

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

11.2.4放大模型

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

11.2.5实体关系

• 同理可创建班级实体，需留意点击右边功能按钮后，点击鼠标指针状态按钮或右击鼠标，制止误操作。之后利用 “Relationship（关系）” 按钮毗连弟子和班级实体，二者会形成一对多（班级对弟子）或多对一（弟子对班级）的关系
  
  
  
• 需要留意的是点击Relationship这个按钮，就把班级和弟子接洽起来了，就是一条线，然后双击这条线举行编辑，在General这块起name和code
  
  
  
• 上面的name和code起好后就可以在Cardinalities这块查察班级和弟子的关系，可以看到班级的一端是一 条线，弟子的一端是三条，代表班级对弟子是一对多的关系即one对many的关系，点击应用，然后确定 即可
  
  
  
• 一对多和多对一训练完还有多对多的训练，如下图操作所示，老师实体和上面先容的一样，自己将 name，data type等等修改成自己需要的即可，满意项目开发需求即可
  
• 多对多需要留意的是自己可以手动点击按钮将关系调解称为多对多的关系many对many的关系，然后点 击应用和确定即可
  
  
  
  
• 综上即可完成最简单的弟子，班级，教师这种概念数据模型的筹划，需要考虑数据的类型和主标识码， 是否为空。关系是一对一照旧一对多照旧多对多的关系，自己需要先规划好再筹划，然后就ok了
  
  
  

（3）物理数据模型

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

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

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

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

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

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

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。