資料庫設計 1. 說在前面 項目開發的流程包括哪些環節 (1) 根據市場公司需求分析公司是否需要開發軟體來輔助日常工作 (2) 公司高層市場考察,市場分析,決定做什麼軟體。 (3) 不懂技術的人想象軟體應該有什麼功能,長什麼樣子 (1) 根據領導的需求設計出產品的原型(圖紙) ① 有具體的功能,功能 ...
資料庫設計
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.許可權管理 |
7.3. 資料庫設計
根據功能列表與客戶調研報告(需求文檔),設計數據資料庫。
第一步:RBAC系統的設計
Role Based Access Control (基於角色的許可權控制系統);就是根據不同的用戶,根據用於所屬的角色不同而登錄的界面就不同。
需求:一個管理員只有一個角色(單角色的設計),一個角色可以有多個管理員
一個就是可以有多個許可權,一個許可權也可以有在多個角色角色。
第二步:業務系統的設計(CRM)
需求:
- 一個銷售(用戶),只能查看自己的客戶
- 客戶是公司,有多個聯繫人 (客戶主體公司)
- 銷售人員可以設置重點跟進客戶,並且可以說明重點跟進客戶的原因.
- 銷售人員離職時,可以禁用不讓登錄
- 銷售人員可以多次跟進同一個客戶(騷擾)
- 銷售可以指定客戶給另一個銷售人員跟進
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選項
設計圖如下: