1.概述
关注我不迷路,每天分享一点点,每天进步一点点~
1.1数据的组织形式
曾经的软件工程书中将软件等价于代码加上数据。由此可见代码和数据是构成软件的要素。我想用“静若处子,动若脱兔”来形容数据和代码会比较形象:数据是记录对象某时刻点的静态快照,例如一张表单;而实现业务的代码便是看不见的一只手,操作并改变着数据。
数据按存储形式可分为:文件型,如XML、JSON、Cookie等;数据库型,如SQL Server、Oracle、Sqlite等;内存型,如Session会话。
按组织形式可分为:层次模型,采用树形结构表示数据与数据间的联系,一个节点代表一条记录,根节点以外的其他节点有且仅有一个双亲节点;网状模型,采用网状结构表示数据与数据间的联系,允许一个以上的节点无双亲,一个节点可以有多个双亲;关系模型,用表结构表达实体集以及实体集之间的联系。关系模型与前两者最大的差别是用主码代替指针导航数据。
不难看出无论数据如何组织,不同的数据模型都关注两点:数据以及数据间的联系。
1.2分析案例
为有效保护耕地,成都市国土资源局决定建立成都市耕地保护基础数据库,建立农户、耕地档案以加强耕地与补贴基金发放管理。
需管理数据有农业家庭户、家庭户成员、耕地三类信息。农业家庭户信息包含户号、户类型、户主姓名、户主身份证号、户所属行政区划(即权属代码)。家庭户成员信息包括姓名、身份证号、性别、出生日期、年龄、是否为土地义务人。耕地信息包括地块编号(权属代码加4位自编码组成)、耕地类型、图幅编号、图斑编号、合同面积、实测面积、直补面积、登记年份。
每户家庭包含一位或多位家庭成员,某位家庭成员仅属于一户家庭。每户家庭拥有一块或多块耕地,某块耕地属于一户或多户家庭。
2数据库设计
2.1设计内容
数据库设计属于系统总体设计和详细设计中的一项。
结合需求调研中用户提出的数据需求加以分析,在总体设计阶段的核心是形成概念模型,主要包括:现有数据梳理与分析、数据库逻辑结构、命名规则、E-R图。在详细设计阶段是对总体设计的具体细化,主要包括:数据库物理结构与存储方案、表描述和表的属性清单等。
2.2步骤
在PowerDesigner中提供了多条设计路线、模型的相互转换(如图 2‑1所示)供设计人员自由发挥。常见的流程大概有如下两种:
图 2‑1 CDM、PDM、OOM的关系
l 设计CDM,再转换为PDM,最终生成OOM。
l 设计CDM,转换为PDM、OOM,再分别细化。
本文采用第一种流程进行数据库设计实践。
3概念数据模型设计
3.1找到实体
首先将用户需求中描述的业务领域内的名词找出来,如果系统中需要存储它们的信息或状态,可能就是我们要找的业务实体对象。
根据1.2节描述,大致能确定系统至少有农业家庭户、家庭户成员、耕地三个实体。
表 3‑1 系统包含的实体
实体名 | 含义 |
---|---|
农业家庭户(Family) | 存放农业家庭户信息 用于以户为单位查询户成员和耕地 |
家庭户成员(Members) | 存放家庭户成员信息 |
耕地(Land) | 存放耕地地块信息 |
3.2理清联系
找到实体后,根据需求描述和业务理解,将实体之间的联系用菱形表示,菱形框内写明联系名,并用无向边将有关实体连接起来,同时在无向边旁标上联系的类型“一对一(1,1)、一对多(1,n)、多对多(m,n)”。
图 3‑1 实体间联系
3.3形成E-R图
绘出了实体和联系就搭好了E-R图的骨架,下面将系统中关注实体的属性追加到各实体上。因为E-R图是概念设计阶段的产物,所以咱们无需过多关注数据库和编程实现的细节因素,以免丢失了重点。
例如属性中是否需要实体序号(即Id),复合属性(如地块编号)的拆分,派生属性的处理(如出生日期和性别可由身份证号得出,年龄可由出生日期得出),遵从范式等等都可以放在详细设计阶段。
概念设计阶段要做的就是找到系统主要核心实体及其相互联系,并原原本本的将实体在系统中需要用到的属性标示出来。
图 3‑2 耕地保护系统E-R图
3.4E-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.1CDM生成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如下图,由于农业家庭户与耕地是“多对多”关系,所以系统自动生成一张新表来记录该关系。而农业家庭户与家庭成员是“一对多”关系,系统自动在家庭成员表中追加户号外键。
图 4‑1 耕地保护系统PDM(1)
4.2具体问题具体分析
1)冗余字段的取舍
农业家庭户表的字段设置虽然符合系统呈现数据的需要,但如果户主发生变更,我们需要变更家庭成员表中新户主为土地义务人,同时修改农业家庭户表的户主信息。如果农业家庭户表中去掉户主姓名、身份证号字段,则按户查询时需通过户号关联家庭成员表,且是土地义务人的记录中提取户主姓名、身份证号。
考虑系统查询操作为主,编辑户主信息操作频率很低,农业家庭户表保留了户主姓名、身份证号字段。
2)派生属性(传递依赖)的处理
在家庭成员表中,性别、出生日期字段依赖身份证号码字段,年龄字段部分依赖于出生日期字段。是否去掉性别、出生日期、年龄字段,在系统代码实现中提供算法实时提取性别、出生日期和年龄?
稍作分析可知:性别和出生日期是不随时间改变的,在录入时就从身份证号码中提取出来,既是身份证号码格式检查的必然需要,也提高了系统读取记录时的效率。年龄是今时与出生日期间的差值,随时间而不同,显示时实时计算最合理,所以删除年龄字段。
3)复合属性的处理
在耕地表中,主键地块编号由权属编码和4位自编码组成。权属编码即行政区划代码,由区县、乡镇、村居委会、组构成18位代码。各组内从0001开始编4位顺序码,两者组合保证了地块号唯一。
系统中需实现按权属编码的分类汇总,如按组、按村居委会等等。通过地块编号字段的字符串前缀匹配运行即可实现(如LIKE ‘510108%’),即不再单独添加权属编码字段。
4)辅助支撑表的建立
从前文中可以看出耕地、农业家庭户均按权属编码分层管理,但现数据库设计中却未考虑权属编码的存放。在系统中它常以树状结构呈现、递归方式读取记录,所以在权属代码表中需设立父节点序号等字段。
除此之外,户类型、耕地类型、性别字段值为了物理存储方便,均采用一位数字表示。但在系统中呈现时需要翻译成对应的中文含义,如男女、家庭户、集体户等。由于性别、户类型枚举项固定不变,可以考虑硬编码到代码中作为枚举类型(Enum Type);耕地类型枚举项可能存在变动,可以数据库中建表或在XML文件中管理。
5)其他
如果某家庭户所拥有地块减少,则需在户与耕地关系表中删除对应记录。为了保证操作可逆,系统常常设立Status字段作为逻辑删除标示。
图 4‑2 耕地保护系统PDM(2)
4.3生成SQL建库脚本
打开PDM模型,选择DatabaseàGenerate Database命令,可生成SQL脚本或直接连接DBMS建库。
5面向对象模型生成
面向对象模型(OOM)是与编程语言密切相关的UML描述模型。它可由CDM、PDM生成类图,再由OOM生成目标语言代码。
该部分内容不在数据库设计讨论范畴,在此不再赘述。
6小结
6.1CDM、PDM、类图有关概念对应关系
表 6‑1 CDM、PDM、类图有关概念对应关系
CDM中对象 | PDM中对象 | 类图中对象 |
---|---|---|
实体(Entity) | 表(Table) | 类 |
联系(Relationship) | 外键(Reference) | 类类型字段(变量) |
属性(Attributes) | 列(Column) | 字段(变量) |
主标示符(Primary Identifier) | 主键(Primary Key) | 字段(变量) |
关联(Association) | 外键、关联表 | 类类型字段(变量) |
继承(Inheriance) | -- | 继承 |
方法、接口、多态描述了对象的行为,是系统运行的规则;属性描述了对象某时点的状态,是静态的快照。由于内存有限、系统也不可能永不停止,所以将对象的状态值放在数据库中存储,系统运行需要时再映射还原成对象。
6.2生成数据库设计文档
PowerDesigner提供了根据CDM、PDM等模型生成数据库设计文档的功能,减少了文档编写的工作量,生成文档内容主要包括模型图、所有列表项等等。选择ReportàGenerate Report命令,可通过向导或已有模板生成文档。
6.3遵从范式
数据库设计是否需要严格遵从范式,需要达到第几范式?这个问题一直困扰着我。最终我得到的答案是合适就好,个人认为第三范式可以作为数据库设计的一般参照标准。
7参考文献
看了这么多,休息一会吧。我这里整理了sql的几版zl,come on!!!
[1] 陈平、褚华,软件设计师教程,第2版,清华大学出版社
[2] 赵韶平、徐茂生等,PowerDesigner系统分析与建模,第2版,清华大学出版社
[3]图中年龄属性用虚线边框,只为突出它是非必须的属性。后文详论。
[4]特殊的实体,标示系统某事件引起的实体间联系。如家访对于教师和学生、租借对于顾客、商店和影片。
[5] 对象变量,如object、用户自定义class。两个类的联系在Hibernate中由对应的hbm.xml定义。
[6]包含值类型(int、float、char、enum、struct等)、引用类型(string)。