房屋租赁管理系统建模——利用PowerDesigner进行数据库建模设计及SQL脚本生成

在建模之前，首先要明白概念数据模型、逻辑数据模型、物理数据模型。

概念数据模型 Conceptual Data Model (CDM)	从用户角度所建模的系统数据对象及其关系，它帮助用户分析信息系统的数据结构关系。
逻辑数据模型 Logic Data Mode(LDM)	从系统分析员角度所建模的系统数据对象逻辑结构关系，它帮助开发人员分析信息系统的逻辑数据结构。
物理数据模型 Physical Data Model (PDM)	从系统设计人员角度所建模的系统数据物理存储及结构关系，它针对设计者具体定义信息系统的数据库表结构。

不同模型中对应的元素有不同的名称

CDM/LDM到PDM的转换其实就是E-R模型到关系模型的转换。

了解E-R模型（“实体-联系模型”）

E-R模型的3中基本元素：实体，属性，联系。

实体：用于描述事物的数据对象，如客户、交易、产品、订单等

属性：是指描述实体特征的数据项。比如一个学生

标识符：指标识不同实体实例的属性；标识符与主键的区别是标识符是一个逻辑概念，主键是物理概念

联系：指实体之间的联系，如“学生”与“成绩”的联系，关联的实体数目称为联系度数

一个给定实体有多少实例与另一实体实例存在的数量对应关系。通常采用术语基数（Cardinality）来表示，教师与学生的基数分别为M和N。

实体-联系符号表示

实体继承联系

在实体继承联系中，一端是具有公共属性的实体，称为父实体；另一端是与父实体具有相似属性，同时也具有特殊性的一个或多个实体，称为子实体。

分为互斥性继承联系和非互斥性继承联系或者完整继承和非完整继承，与此同时也要注意符号表示

强弱实体联系

弱实体是指那些对于另外实体有依赖关系的实体，即一个实体的存在必须以另一实体的存在为前提。而被依赖的实体称为强实体，比如学校是强实体，学生是弱实体，而这种强弱又是相对的，对于成绩表，学生又是强实体，成绩表是弱实体。

弱实体分为标识符（ID）依赖弱实体和非标识符（非ID）依赖弱实体两类，弱实体的标识符中含有所依赖实体的标识符，则该弱实体称为标识符（ID）依赖弱实体。

规范化设计

为避免数据插入删除操作中出现数据不一致的问题，在设计时就要进行规范化处理

要处理的一种类型就是函数依赖

• 完全函数依赖

• 部分函数依赖

• 属性传递依赖

• 多值函数依赖

为便于理解，这里不进行学术性定义，而是通过简单的例子帮助理解：

对于关系 R （ X , Y , N, O, P ），其中（ X ， Y ）为复合主键，若其它属性 N,O,P 都完整依赖于该复合主键，则称关系 R 为完全函数依赖。反之，其它属性 N,O,P 仅依赖于 X ，或仅依赖于 Y ，则称 R 为部分函数依赖。

对于关系 R （ X , N, O, P ），其中 X 为主键，若属性 N 依赖于 X ，而 X 不依赖于 N（无环） ，属性 O 依赖于 N 。则属性 O 函数传递依赖于 X。

对于教学关系 R （课程 , 教师 , 课程参考书）， 一门课程可以有多个任课教师，也可以有多本参考书；每个任课教师可以任意选择他的参考书 。该关系存在多值函数依赖。

关系规范化范式

第1范式（1NF）：如果关系表中的属性不可再细分，该关系满足第1范式。反之，该表不是关系表

第2范式（2NF）：满足第1范式，并消除了关系中的属性部分函数依赖（做到完全依赖），该关系满足第2范式。

第3范式（3NF）：满足第2范式，并切断了关系中的属性传递函数依赖，该关系满足第3范式。

巴斯-科德范式（BCNF）：所有函数依赖的决定因子都是候选键，该关系满足BCNF范式。

第4范式（4NF）：满足BCNF范式，并消除了多值函数依赖，该关系满足第4范式。

优点：关系的规范化程度越高，关系数据库存储的冗余数据就越少，可消除的数据访问异常就越多。

缺点：规范化程度越高，分解出来的关系表就越多，但实现数据查询访问时，需关联多表，其效率降低。

问题描述

分析房屋租赁管理系统数据需求，设计该系统数据库，并在数据库服务器中实现该数据库。

1）针对房屋租赁管理系统数据需求，使用Power Designer建模工具，设计房屋租赁管理系统概念数据模型。

2）在概念数据模型基础上，采用关系数据库设计方式，将房屋租赁管理系统概念数据模型转换为系统逻辑数据模型设计，并进行规范化完善设计（拆分），至少满足3NF规范。

3）针对数据库实现，将房屋租赁管理系统逻辑数据模型转换为系统物理数据模型设计，并进行有关索引设计、视图设计。

4）将房屋租赁管理系统物理数据模型转换为SQL脚本程序。

5）在数据库服务器中，执行该SQL脚本程序，实现房屋租赁管理系统数据库对象创建实现。

概念数据模型设计

1.抽取与标识实体：房主，房源，租赁者，合同

2.分析与标识实体联系。给出实体之间的联系连接线以及联系的名称。

3.定义实体属性与标识符。确定属性（包括名称，数据类型，约束）以及标识符

4.检查与完善数据模型。在之前的基础上加入三方合同，业务员，以及看房信息。

属性中的Mandatory是是否强制，也就是NULL or NOT NULL,P一列是主键，Dispaly勾选上就好

房主

房源

租赁者

三方合同

业务员

看房信息

建立实体联系

在面板中选择relationship，建立实体间的联系

以房主和房源为例，连接之后进行命名以及实体-联系类型，房主与房源是一对多的关系，且房主与房源依赖存在，所以勾选Mandatory选项。

类似的建立其他实体间的联系，最终的结果如下

之后可以选择工具中的生成逻辑数据模型，在配置时去掉Check model的勾选，否则房主与租赁者的身份证号等相同名称不被允许。

逻辑数据模型设计

要求至少满足3NF范式，进行简单的概括：第一范式不能有重复列或者可细分属性列，第二范式要求关系表中所有数据都要和该关系表的主键有完全函数依赖，第三范式要求属性没有函数传递依赖。由于我们设计的还算不错，因此满足3NF范式。

接下来生成物理数据模型，选择工具中的生成逻辑数据模型。

物理数据模型设计

在此基础上进行索引视图设计，对“房源”关系表的“租金列”设计索引，以便针对“租金”查询时，可以使数据库有较高的查询进度。这样，租赁者可以在合适的价格区间进行房屋信息的查看，并且所耗费的查询时间较少。

进行视图设计时，选中面板里的view

配置时选中SQL Query，我们使用QL语句创建视图

select H.houseid,H.addres,H.area,O.owner_id,O.owner_phone
FROM houses as H,owner as O
WHERE H.owner_id = O.owner_id

得到这样一个视图

最后在工具菜单栏的“Tools->Check Model”菜单命令对该PDM设计进行
检查。

SQL脚本生成

点击菜单栏数据库

点击生成数据库，完成脚本的生成。

 执行SQL脚本

找到文件并用文本编辑器打开

使用pgAdmin4数据库管理工具，连接PostgreSQL数据库服务器，在服务器中创建房屋租赁数据库，调入创建数据库对象的SQL脚本文件

先把开始的drop全部去掉

由于模型转换过程可能修改了属性code，根据错误提示修改之后就能成功创建。