数据库设计_ERMaster安装使用_PowerDesigner数据设计工具

数据库设计

1. 说在前面

项目开发的流程包括哪些环节

1. 需求调研【需求调研报告】-- 公司决策层

(1) 根据市场公司需求分析公司是否须要开发软件来辅助平常工做

(2) 公司高层市场考察，市场分析，决定作什么软件。

(3) 不懂技术的人想象软件应该有什么功能，长什么样子

1. 需求文档【功能列表】+原型  --- 公司产品经理（产品专员）。

(1) 根据领导的需求设计出产品的原型（图纸）

① 有具体的功能，功能之间能够跳转（静态跳转）

(2) 编写需求文档

① 对项目的详细介绍，每一个功能可以完成具体哪些点，描述一清二楚

1. 美工经过原型设计UI。--> HTML网页

(1) 设计师，美工

(2) 目前纯粹的后台管理系统有成熟模板或者框架可选（BootStrap）

1. 后台开发，设计数据库（建立数据库结构）---技术经理+（若干开发人员3-5）

(1) 负责项目的架构技术选型等等，技术的全局把控- 技术经理

(2) 数据的设计

① 项目经理根据需求文档原型设计-居多

② 每一个开发者根据本身的模块本身设计（分开设计，最后汇总）

(3) 项目模块代码的编写

(4) 后台开发，公共代码编写

(5) 功能编码

1. 测试

(1) 黑盒测试-

① 程序内部不可见-以特定的程序或者工具来测试软件

(2) 白盒测试

① 单元测试，程序软件直接经过代码测试

1. 上线运行
2. 后期的不断开发维护升级
3. 项目淘汰

 

2. 数据库设计的概述

2.1. 数据库设计是什么

所谓的数据库设计就是根据需求文档的描述将需求转成数据库的存储结构的过程.

 

在数据库设计的流程上,咱们一般根据需求,画出数据的ER图.而后在经过ER图生成数据库的建库脚本. （Entity Relational）

 

ER图，所谓的ER图就是数据库关系图

 

为何咱们使用ER图来实现数据库设计的设计呢?

 

1.可见便可得.使用ER图能够经过图形的方式展现表与表直接的关系

2.能够根据设置的数据库,方便生成不一样的数据库的SQL建库脚本

3.能够快速的生成数据库文档

 

 

小结：所谓的数据库设计，就是经过ER图，根据需求给数据库建表表结构！！！

 

2.2. 为何须要数据库设计

软件开发都是分别从页面设计和数据库设计开始的.

建立项目的数据库是项目开发必须的阶段.

 

 

3. 数据库设计基础理论（重点）

3.1. 数据库设计的步骤

 

数据库设计的步骤是根据需求的描述:

第一步：标识表

第二步：标识表的字段

第三步：标识表与表之间的关系

 

3.2. 标识表注意事项

所谓的标识表，就是根据需求将表建立！！

 

咱们在标识表的时候,能够将表分为实体表和业务表.

所谓的实体表:就是记录需求中描述为一个对象（名词）的表.如:用户,商品,订单,管理员,角色等

所谓的业务表:就是记录在需求中描述为一个业务行为（动词）的表:收藏,关注,等 （大部分是中间表）

 

虽然没有强制的规定先标识实体表仍是业务表,但咱们一般在标识表时会先标识实体表,再标识业务表.

 

由于业务表通常是用于标识实体表与另外一个实体的多对多的关系的.

 

3.3. 标识字段注意事项

 

 

标识字段,在数据库设计中,尽可能符合数据库设计的三大范式原则.

 

--三大范式，就是用于数据库设计，标识字段的时候使用的！！！。

 

数据库表设计三大范式最终解决的是数据冗余问题

 

3.4. 三大范式

为了创建冗余较小、结构合理的数据库，设计数据库时必须遵循必定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须知足必定的范式。          

在实际开发中最为常见的设计范式有三个

3.4.1.  第一范式(确保每列保持原子性)

第一范式是最基本的范式。若是数据库表中的全部字段值都是不可分解的原子值，就说明该数据库表知足了第一范式。

第一范式的合理遵循须要根据系统的实际需求来定。好比某些数据库系统中须要用到“地址”这个属性，原本直接将“地址”属性设计成一个数据库表的字段就行。可是若是系统常常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性从新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操做的时候将很是方便。这样设计才算知足了数据库的第一范式，以下表所示。

 

 

上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就很是方便，也提升了数据库的性能。

                

1. 第二范式(确保表中的每列都和主键相关)

非主键列必须依赖主键列存在

第二范式在第一范式的基础之上更进一层。第二范式须要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不能够把多种数据保存在同一张数据库表中。

好比要设计一个订单信息表，由于订单中可能会有多种商品，因此要将订单编号和商品编号做为数据库表的联合主键，以下表所示。

 订单信息表

 

 

 

这样就产生一个问题：这个表中是以订单编号和商品编号做为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。因此在这里违反了第二范式的设计原则。

而若是把这个订单信息表进行拆分，把商品信息分离到另外一个表中，把订单项目表也分离到另外一个表中，就很是完美了。以下所示。

 

这样设计，在很大程度上减少了数据库的冗余。若是要获取订单的商品信息，使用商品编号到商品信息表中查询便可。

 第三范式(确保每列都和主键列直接相关,而不是间接相关-在2NF基础上消除传递依赖)

第三范式须要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。好比在设计一个订单数据表的时候，能够将客户编号做为一个外键和订单表创建相应的关系。而不能够在订单表中添加关于客户其它信息（好比姓名、所属公司等）的字段。以下面这两个表所示的设计就是一个知足第三范式的数据库表。

这样在查询订单信息的时候，就可使用客户编号来引用客户信息表中的记录，也没必要在订单信息表中屡次输入客户信息的内容，减少了数据冗余。

 

三大范式只是通常设计数据库的基本理念，能够创建冗余较小、结构合理的数据库。若是有特殊状况，固然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构（范式）。因此不能一味的去追求范式创建数据库。

1.1. 实际开发部符合三范式的场景

 示例-性能的要求出现的冗余数据

咱们不少系统都要记录日志.而日志里面,必需要包括用户的信息.若是严格按照三大方式.日志的用户信息必须是从用户表中得到，日志天天都会出现巨量的数据。若是关联用户表查询，整理日志时会致使用户表的访问大大被拖慢。

 

因此，咱们会将用户的信息直接写在日志表里面。在日志表中写用户的的信息,明显违反了第二范式，基于查询的性能的须要，通常日志表的用户信息是冗余。

. 示例-业务逻辑的要求出现的冗余数据

咱们在订单中有一个商品的价格、商品名字。而这个商品的价格直接就是订单的字段.并非商品表里面商品的价格.明显违反了第三范式.

 

但业务上,因为订单的商品的价格不能随着着商家修改了商品价格而修改.因此像这种需求下,必需要给订单表一个冗余的商品价格字段。

1.1. 标识表与表之间的关系

表与表之间的关系包括有

. 一对一

一对多/多对一

 多对多

 遵循范式设计

 以实际需求为主的设计

数据库表与表的关系，就是也需求描述的从属关系。

 

问题：表与表之间的关系，是谁决定的？

答：需求决定的！！！

 

 

 

1. 小结（重点）

1. 数据库设计就是创建项目的表结构
2. 基于数据的复杂性，通常数据库数据库是先画ER图的。
3. 数据库设计的步骤是：标识表，标识字段，标识表与表之间关系

 

标识表，先标识实体表，在标识业务表

 

实体表（名词，没有行为）

业务表（包括业务动做，通常就是一个中间表）

 

标识字段，必需要求理解三大范式

为何须要三大范式，避免数据的冗余，致使数据的异常。

 

数据库设计整体上要符合三大范式，可是基于业务需求和性能要求，有时候能够有少量的冗余

 

数据设计冗余，设计者必需要说明缘由(项目需求须要)

 

标识表与表之间的关系

1. 有哪些表与表之间关系，一对多，多对一，一对一，多对多
2. 表与表之间的关系是由需求决定，讨论表之间的关系前，必需要先肯定需求
3. 关系数据库是不能直接支持多对多的业务关系的，若是出现多对多必需要拆分一个中间表，缘由是数据库里面的字段不能存储一个集合数据。

 

 

5. ERMaster的使用

ERMaster 是集成到Eclipse开发工具的一个插件。

5.1. ERMaster安装

1. 复制到dropins文件夹，解压到当前文件夹

　　2.打开eclipse。在新建的other里面有ermaster选项，表示成功

5.1. DDL导出

在工做区，右击

 

5.1. 导出文档

右击工做区，导出HTML

 

6. 综合案例-学生成绩管理系统

需求：设计一个学生成绩管理系统

1. 首先有学生，学生必须包括登陆、禁用功能
2. 基于安全性的考虑，学生的身份信息要单独存储。
3. 一个学生有多门成绩
4. 一个学生能够有多个老师，一个老师也能够教多个学生

 

 

第一步：标识表，标识实体表。学生、学生身份、成绩、老师

第二步：标识字段

第三步：标识表与表之间的关系

 

6.1. ER设计图

6.2. SQL语句

导出sql语句把逻辑名称做为注释

 

sql

SET SESSION FOREIGN_KEY_CHECKS=0;


/* Drop Tables */


DROP TABLE IF EXISTS student_teacher;

DROP TABLE IF EXISTS tb_info;

DROP TABLE IF EXISTS tb_score;

DROP TABLE IF EXISTS tb_student;

DROP TABLE IF EXISTS tb_teacher;

/* Create Tables */


-- student_teacher

CREATE TABLE student_teacher

(

stu_id int NOT NULL COMMENT '学生id',

teacher_id int NOT NULL COMMENT '主键'

) COMMENT = 'student_teacher';

 

-- 学生身份信息

CREATE TABLE tb_info

(

stu_idcard varchar(50) COMMENT '身份证',

stu_address varchar(100) COMMENT '地址',

stu_phone varchar(50) COMMENT '电话',

stu_email varchar(50) COMMENT '邮箱',

stu_id int NOT NULL COMMENT '学生id'

) COMMENT = '学生身份信息';

 

 

-- 学生成绩表

CREATE TABLE tb_score

(

sc_id int NOT NULL AUTO_INCREMENT COMMENT '主键',

sc_suject varchar(50) COMMENT '科目',

sc_score float COMMENT '成绩',

stu_id int NOT NULL COMMENT '学生id',

PRIMARY KEY (sc_id)

) COMMENT = '学生成绩表';

 

 

-- 学生信息报

CREATE TABLE tb_student

(

stu_id int NOT NULL AUTO_INCREMENT COMMENT '学生id',

stu_name varchar(50) COMMENT '学生姓名',

stu_account varchar(50) COMMENT '学生帐号',

stu_pwd varchar(50) COMMENT '学生密码',

stu_salt varchar(100) COMMENT '密码加密字段（盐）',

stu_status int DEFAULT 1 COMMENT '学生状态 1 正常 0 锁定',

PRIMARY KEY (stu_id)

) COMMENT = '学生信息报';

 

 

-- 老师表

CREATE TABLE tb_teacher

(

teacher_id int NOT NULL AUTO_INCREMENT COMMENT '主键',

teacher_name varchar(50) COMMENT '姓名',

teacher_account varchar(50) COMMENT '帐号',

teacher_pwd varchar(50) COMMENT '密码',

teacher_phone varchar(50) COMMENT '老师电话',

PRIMARY KEY (teacher_id)

) COMMENT = '老师表';

 
 

/* Create Foreign Keys */

 

ALTER TABLE student_teacher

ADD FOREIGN KEY (stu_id)

REFERENCES tb_student (stu_id)

ON UPDATE RESTRICT

ON DELETE RESTRICT

;



ALTER TABLE tb_info

ADD FOREIGN KEY (stu_id)

REFERENCES tb_student (stu_id)

ON UPDATE RESTRICT

ON DELETE RESTRICT

;

 

 

ALTER TABLE tb_score

ADD FOREIGN KEY (stu_id)

REFERENCES tb_student (stu_id)

ON UPDATE RESTRICT

ON DELETE RESTRICT

;

 

 

ALTER TABLE student_teacher

ADD FOREIGN KEY (teacher_id)

REFERENCES tb_teacher (teacher_id)

ON UPDATE RESTRICT

ON DELETE RESTRICT

;

 

 

 

7. 综合案例-CRM系统（做业）

Customer Relational Manager System (客户关系管理系统)

7.1. 客户调研

客户人员是一个不懂软件设计的人,它但愿有一个能够作管理系统来管理他的员工.

描述以下:

系统的需求调研 1.每一个销售人员只能查看本身的客户. （销售不能互相看客户） 2.客户是公司，有多个联系人  （客户主体公司） 3.销售能够指定客户给另外一个销售人员跟进 （销售人员能够转移客户给另外销售） 4.销售人员离职时,能够禁用不让登陆 5.管理员能够修改销售人员的密码 （后台管理人员能够管理全部信息） 6.销售人员能够设置重点跟进客户,而且能够说明重点跟进客户的缘由. 7.销售人员能够屡次跟进同一个客户（骚扰）

 

7.2. 系统功能列表（需求文档的核心部分）

功能列表给到客户人员。给到开发人员，跟进需求文档设计数据库。

前端功能（销售人员的功能）	1.客户管理
	2.联系人管理
	3.转移客户
	4.跟进客户
	5.标记重点客户
后台管理（管理员管理 RBAC）	1.客户管理 (全局)
	2.联系人管理（全局）
	3.管理员管理
	4.角色管理
	5.权限管理

 

 

7.3. 数据库设计

根据功能列表与客户调研报告（需求文档），设计数据数据库。

 

第一步：RBAC系统的设计

 

Role Based Access Control (基于角色的权限控制系统)；就是根据不一样的用户，根据用于所属的角色不一样而登陆的界面就不一样。

 

 

 

需求：一个管理员只有一个角色（单角色的设计），一个角色能够有多个管理员

      一个就是能够有多个权限，一个权限也能够有在多个角色角色。

 

第二步：业务系统的设计（CRM）

 

需求：

1. 一个销售（用户），只能查看本身的客户
2. 客户是公司，有多个联系人  （客户主体公司）
3. 销售人员能够设置重点跟进客户,而且能够说明重点跟进客户的缘由.
4. 销售人员离职时,能够禁用不让登陆
5. 销售人员能够屡次跟进同一个客户（骚扰）
6. 销售能够指定客户给另外一个销售人员跟进

8. PowerDesigner数据设计工具

PowerDesigner是一个专业的数据库设计软件。如今市场主流的数据库设计工具！！

 

8.1. 使用步骤

8.1.1. 第一步：建立一个物理ER图

 

--不要建立逻辑ER图，逻辑ER图只能看，不能生成数据脚本。

 

8.1.2. 第二步：工具栏说明

8.1.3. 第三步：取消Name To Code

 

8.1.4. 第三步：CRM系统的设计

问题：设计表的时候，发现没有ID自增加选项

答：是由于默认没有指定Mysql数据库。因此须要设计为MySQL数据库。

--修改后，发现多个一个Identity选项

设计图以下：