MySQL⼀⼀数据库设计和建模⼯具PowerDesigner 概述
1 概述
1
关注我不迷路，每天分享⼀点点，每天进步⼀点点~
1.1 数据的组织形式
数据的组织形式
1.1
曾经的软件⼯程书中将软件等价于代码加上数据。由此可见代码和数据是构成软件的要素。我想⽤“静若处⼦，动若脱兔”来形容数据和代码会⽐较形象：数据是记录对象某时刻点的静态快照，例如⼀张表单；⽽实现业务的代码便是看不见的⼀只⼿，操作并改变着数据。
数据按存储形式可分为：⽂件型，如XML、JSON、Cookie等；数据库型，如SQL Server、Oracle、Sqlite等；内存型，如Session会话。
按组织形式可分为：层次模型，采⽤树形结构表⽰数据与数据间的联系，⼀个节点代表⼀条记录，根节点以外的其他节点有且仅有⼀个双亲节点；⽹状模型，采⽤⽹状结构表⽰数据与数据间的联系，允许⼀个以上的节点⽆双亲，⼀个节点可以有多个双亲；关系模型，⽤表结构表达实体集以及实体集之间的联系。关系模型与前两者最⼤的差别是⽤主码代替指针导航数据。
不难看出⽆论数据如何组织，不同的数据模型都关注两点：数据以及数据间的联系。
1.2 分析案例
分析案例
1.2
为有效保护耕地，成都市国⼟资源局决定建⽴成都市耕地保护基础数据库，建⽴农户、耕地档案以加强耕地与补贴基⾦发放管理。
需管理数据有农业家庭户、家庭户成员、耕地三类信息。农业家庭户信息包含户号、户类型、户主姓名、户主⾝份证号、户所属⾏政区划（即权属代码）。家庭户成员信息包括姓名、⾝份证号、性别、出⽣⽇期、年龄、是否为⼟地义务⼈。耕地信息包括地块编号（权属代码加4位⾃编码组成）、耕地类型、图幅编号、图斑编号、合同⾯积、实测⾯积、直补⾯积、登记年份。
每户家庭包含⼀位或多位家庭成员，某位家庭成员仅属于⼀户家庭。每户家庭拥有⼀块或多块耕地，某块耕地属于⼀户或多户家庭。
数据库设计
2 数据库设计
2
设计内容
2.1
2.1 设计内容
数据库设计属于系统总体设计和详细设计中的⼀项。
结合需求调研中⽤户提出的数据需求加以分析，在总体设计阶段的核⼼是形成概念模型，主要包括：现有数据梳理与分析、数据库逻辑结构、命名规则、E-R图。在详细设计阶段是对总体设计的具体细化，主要包括：数据库物理结构与存储⽅案、表描述和表的属性清单等。
步骤
2.2 步骤
2.2
在PowerDesigner中提供了多条设计路线、模型的相互转换（如图 2‑1所⽰）供设计⼈员⾃由发挥。常见的流程⼤概有如下两种：
步骤.jpg
图 2‑1 CDM、PDM、OOM的关系
l 设计CDM，再转换为PDM，最终⽣成OOM。
l 设计CDM，转换为PDM、OOM，再分别细化。
本⽂采⽤第⼀种流程进⾏数据库设计实践。
概念数据模型设计
3
3 概念数据模型设计
到实体
mysql连接工具3.1 到实体
3.1
⾸先将⽤户需求中描述的业务领域内的名词出来，如果系统中需要存储它们的信息或状态，可能就是我们要的业务实体对象。
根据1.2节描述，⼤致能确定系统⾄少有农业家庭户、家庭户成员、耕地三个实体。
表 3‑1 系统包含的实体
实体名含义
农业家庭户（Family）存放农业家庭户信息 ⽤于以户为单位查询户成员和耕地
家庭户成员（Members）存放家庭户成员信息
耕地（Land）存放耕地地块信息
理清联系
3.2 理清联系
3.2
到实体后，根据需求描述和业务理解，将实体之间的联系⽤菱形表⽰，菱形框内写明联系名，并⽤⽆向边将有关实体连接起来，同时在⽆向边旁标上联系的类型“⼀对⼀（1，1）、⼀对多（1，n）、多对多（m，n）”。
jpg
图 3‑1 实体间联系
形成E-R图
3.3 形成E-R图
3.3
绘出了实体和联系就搭好了E-R图的⾻架，下⾯将系统中关注实体的属性追加到各实体上。因为E-R图是概念设计阶段的产物，所以咱们⽆需过多关注数据库和编程实现的细节因素，以免丢失了重点。
例如属性中是否需要实体序号（即Id），复合属性（如地块编号）的拆分，派⽣属性的处理（如出⽣⽇期和性别可由⾝份证号得出，年龄可由出⽣⽇期得出），遵从范式等等都可以放在详细设计阶段。
概念设计阶段要做的就是到系统主要核⼼实体及其相互联系，并原原本本的将实体在系统中需要⽤到的属性标⽰出来。
jpg
图 3‑2 耕地保护系统E-R图
E-R图转换为CDM
3.4
3.4 E-R图转换为CDM
概念设计阶段，E-R图更多的作为⼀张重要的“草图”。概念设计中需要E-R图，但常采⽤概念数据模型来代替。我想可能是因为后者完全继承了E-R图所有的要素和精髓，⽽且能更简洁的描述属性、在详细设计和数据库⽣成中沿⽤上阶段成果。
综上所述，概念设计时可采⽤E-R图的思维⽅式直接绘制概念数据模型。E-R图和CDM有关概念对应关系如下：
表 3‑2 E-R图和CDM有关概念对应关系
E-R****图概念数据模型（CDM****）
实体实体（Entity）
联系联系（Relationship）
属性属性（Attributes）
--关联（Association）
特殊化继承（Inheriance）
--依赖（Link/Extended Dependency）
设计CDM时，需要注意它与E-R图在细节上的⼀些不同。其⼀，属性都有数据类型、长度、是否⾮空（Mandatory）设置；其⼆，实体最好都有主键（Primary Indentifier），否则转换为PDM时⽆法⾃动创建参照关系（外键）；其三，“⼀对多”联系中可能存在的依赖联系（标定联
系）。
为属性设置了数据类型，将能唯⼀标⽰实体的属性设为主键，最终形成CDM如下。户号、地块编号分别作为农业家庭户、耕地实体的主键。虽⾝份证号码可唯⼀辨识家庭成员，但考虑可能存在录⼊错误需更改，便单独创建了⾃增编号作为主键。
图 3‑3 耕地保护系统CDM
物理数据模型转换
4
4 物理数据模型转换
CDM⽣成PDM
4.1
4.1 CDM⽣成PDM
当选定了数据库时，可将已有CDM转换为与数据库对应的PDM，继⽽还可由PDM⽣成SQL脚本来建⽴数据库存储结构。
在详细设计阶段，需结合系统功能实现⽅式来考虑数据存储，数据库设计的重⼼转向数据模型的物理实现。如辅助⽀撑表的建⽴、派⽣属性的处理、索引的建⽴等等。
打开CDM模型，选择ToolsàGenerate Physical Data Model命令，选择⽬标DBMS点击确定即可⽣成PDM。转换中其对应关系如下：
表 4‑1 CDM与PDM中对象对应关系
CDM****中对象PDM****中对象
实体（Entity）表（Table）
联系（Relationship）参照关系、外键（Reference）
属性（Attributes）列（Column）
主标⽰符（Primary Identifier）主键（Primary Key）
⽣成PDM如下图，由于农业家庭户与耕地是“多对多”关系，所以系统⾃动⽣成⼀张新表来记录该关系。⽽农业家庭户与家庭成员是“⼀对
多”关系，系统⾃动在家庭成员表中追加户号外键。
jpg
图 4‑1 耕地保护系统PDM(1)
具体问题具体分析
4.2 具体问题具体分析
4.2
1)冗余字段的取舍
农业家庭户表的字段设置虽然符合系统呈现数据的需要，但如果户主发⽣变更，我们需要变更家庭成员表中新户主为⼟地义务⼈，同时修改农业家庭户表的户主信息。如果农业家庭户表中去掉户主姓名、⾝份证号字段，则按户查询时需通过户号关联家庭成员表，且是⼟地义务⼈的记录中提取户主姓名、⾝份证号。
考虑系统查询操作为主，编辑户主信息操作频率很低，农业家庭户表保留了户主姓名、⾝份证号字段。
2)派⽣属性（传递依赖）的处理
在家庭成员表中，性别、出⽣⽇期字段依赖⾝份证号码字段，年龄字段部分依赖于出⽣⽇期字段。是否去掉性别、出⽣⽇期、年龄字段，在系统代码实现中提供算法实时提取性别、出⽣⽇期和年龄？
稍作分析可知：性别和出⽣⽇期是不随时间改变的，在录⼊时就从⾝份证号码中提取出来，既是⾝份证号码格式检查的必然需要，也提⾼了系统读取记录时的效率。年龄是今时与出⽣⽇期间的差值，随时间⽽不同，显⽰时实时计算最合理，所以删除年龄字段。
3)复合属性的处理
在耕地表中，主键地块编号由权属编码和4位⾃编码组成。权属编码即⾏政区划代码，由区县、乡镇、村居委会、组构成18位代码。各组内从0001开始编4位顺序码，两者组合保证了地块号唯⼀。
系统中需实现按权属编码的分类汇总，如按组、按村居委会等等。通过地块编号字段的字符串前缀匹配运⾏即可实现（如LIKE
‘510108%’），即不再单独添加权属编码字段。
4)辅助⽀撑表的建⽴
从前⽂中可以看出耕地、农业家庭户均按权属编码分层管理，但现数据库设计中却未考虑权属编码的存放。在系统中它常以树状结构呈现、递归⽅式读取记录，所以在权属代码表中需设⽴⽗节点序号等字段。
除此之外，户类型、耕地类型、性别字段值为了物理存储⽅便，均采⽤⼀位数字表⽰。但在系统中呈现时需要翻译成对应的中⽂含义，如男⼥、家庭户、集体户等。由于性别、户类型枚举项固定不变，可以考虑硬编码到代码中作为枚举类型（Enum Type）；耕地类型枚举项可能存在变动，可以数据库中建表或在XML⽂件中管理。
5)其他
如果某家庭户所拥有地块减少，则需在户与耕地关系表中删除对应记录。为了保证操作可逆，系统常常设⽴Status字段作为逻辑删除标⽰。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。