數據庫設計_ERMaster安裝使用_PowerDesigner數據設計工具

本文轉載自查看原文 2019-06-19 11:26 1139 java框架一

數據庫設計

1. 說在前面

項目開發的流程包括哪些環節

需求調研【需求調研報告】-- 公司決策層

(1) 根據市場公司需求分析公司是否需要開發軟件來輔助日常工作

(2) 公司高層市場考察，市場分析，決定做什么軟件。

(3) 不懂技術的人想象軟件應該有什么功能，長什么樣子

需求文檔【功能列表】+原型 --- 公司產品經理（產品專員）。

(1) 根據領導的需求設計出產品的原型（圖紙）

① 有具體的功能，功能之間可以跳轉（靜態跳轉）

(2) 編寫需求文檔

① 對項目的詳細介紹，每個功能能夠完成具體哪些點，描述一清二楚

美工通過原型設計UI。--> HTML網頁

(1) 設計師，美工

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

后台開發，設計數據庫（創建數據庫結構）---技術經理+（若干開發人員3-5）

(1) 負責項目的架構技術選型等等，技術的全局把控- 技術經理

(2) 數據的設計

① 項目經理根據需求文檔原型設計-居多

② 每個開發者根據自己的模塊自己設計（分開設計，最后匯總）

(3) 項目模塊代碼的編寫

(4) 后台開發，公共代碼編寫

(5) 功能編碼

測試

(1) 黑盒測試-

① 程序內部不可見-以特定的程序或者工具來測試軟件

(2) 白盒測試

① 單元測試，程序軟件直接通過代碼測試

上線運行
后期的不斷開發維護升級
項目淘汰

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. 小結（重點）

數據庫設計就是建立項目的表結構
基於數據的復雜性，一般數據庫數據庫是先畫ER圖的。
數據庫設計的步驟是：標識表，標識字段，標識表與表之間關系

標識表，先標識實體表，在標識業務表

實體表（名詞，沒有行為）

業務表（包括業務動作，一般就是一個中間表）

標識字段，必須要求理解三大范式

為什么需要三大范式，避免數據的冗余，導致數據的異常。

數據庫設計總體上要符合三大范式，但是基於業務需求和性能要求，有時候可以有少許的冗余

數據設計冗余，設計者必須要說明原因(項目需求需要)

標識表與表之間的關系

有哪些表與表之間關系，一對多，多對一，一對一，多對多
表與表之間的關系是由需求決定，討論表之間的關系前，必須要先確定需求
關系數據庫是不能直接支持多對多的業務關系的，如果出現多對多必須要拆分一個中間表，原因是數據庫里面的字段不能存儲一個集合數據。

5. ERMaster的使用

ERMaster 是集成到Eclipse開發工具的一個插件。

5.1. ERMaster安裝

復制到dropins文件夾，解壓到當前文件夾

　　2.打開eclipse。在新建的other里面有ermaster選項，表示成功

5.1. DDL導出

在工作區，右擊

5.1. 導出文檔

右擊工作區，導出HTML

6. 綜合案例-學生成績管理系統

需求：設計一個學生成績管理系統

首先有學生，學生必須包括登錄、禁用功能
基於安全性的考慮，學生的身份信息要單獨存儲。
一個學生有多門成績
一個學生可以有多個老師，一個老師也可以教多個學生

第一步：標識表，標識實體表。學生、學生身份、成績、老師

第二步：標識字段

第三步：標識表與表之間的關系

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.權限管理