中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文基于RBAC權限管理模塊為例子，以產品經理的視角，一步步完成數據庫邏輯設計實踐，希望能給大家帶來一點啟發！

我畢業后進入了一家B端公司做產品，在臨近轉正的時候，要考核的一點是SQL查詢語言的運用能力，因為工作中需要經常查詢數據來輔助分析，而以往呆過的公司都不需要產品經理很懂數據庫，只要會基本的SQL查詢即可，就一直沒有進一步了解它。

但現在隨著公司對產品經理的要求越來越高，尤其是B端產品經理，懂基本的數據庫設計是個很好的加分項。最近看到招聘網站上一家知名的B端公司jd里，對產品經理崗位的其中一條要求是：“了解主流數據庫的原理，具備較強的數據庫設計能力”。這種能力我們可以理解為基礎的數據庫邏輯設計能力。

而數據庫分為關系型數據庫和非關系型數據庫，本文主要討論的是關系型數據庫。

• 關系型數據庫是依據關系模型來創建的數據庫，所謂關系模型就是“一對一、一對多、多對多”等關系模型，比如一個學號對應一個學生，一個班級對應多個學生，多個老師對應多個學生。一個關系型數據庫是由二維表及其之間的聯系組成的一個數據組織。
• 非關系型數據庫是一種相對松散且可以不按照嚴格的結構規范進行存儲的數據庫。最常見的是鍵值對模型：存儲的數據是一個個“鍵值對”，比如age:18，那么age這個鍵里面存的值就是18。

拿知識星球來說，用戶發了一條動態，數據庫會建立一個索引，并將此動態存入數據區中。如果用戶刪掉此動態，數據庫首先會刪掉索引區的索引，數據區中的動態根據數據庫的存儲性能和容量可能會保留一段時間，保留的那段時間的狀態是假刪除，也叫邏輯刪除。如果用戶再新發布一條新的動態，新的索引和動態會直接覆蓋上一條假刪除的數據，此時就是真刪除了，也叫物理刪除。

為了防止覆蓋數據后變真刪除，還能這么設計：即把用戶假刪除的數據打上標記，存在另一個數據庫表中，當要恢復數據的時候再修改標記。

基本原理弄清楚了，接下來就要思考，怎么去設計了。

1. 什么是數據庫設計？

簡單來說，數據庫設計是根據業務系統的具體需要，結合我們所選用的數據庫管理系統，為這個業務系統構造出最優的數據存儲模型。并建立好數據庫中的表結構以及表與表之間的關聯聯系的過程。使之能有效的對應系統中的數據進行存儲，并可以高效的對已經存儲的數據進行訪問。

2. 為什么要進行數據庫設計？

數據庫相當于一個大樓的地基，如果地基打好了，大樓就會穩固，否則就很容易轟然倒塌。

那么好的數據庫設計和糟糕的數據庫設計有什么特點呢？

3. 數據庫設計的步驟是什么？

（1）需求分析

第一步要進行需求分析，梳理出系統中所要存儲的數據屬性、存儲特點和生命周期。

比如有的數據有時效性，有的數據無時效性。有實效性的數據可以采取過期清理的方式來進行存儲，比如小米云服務里的用戶主動刪除的照片、視頻、便簽等數據會進入回收站保留一定期限，到期后回收站自動清空。

還有的數據增長很快數據量也很大，但不是核心數據，那就可以采用分庫分表的方式進行存儲，也叫數據庫表的水平拆分。

比如我前公司的一個大客戶給他們的用戶發了大量的郵件，系統會不斷的返回相關的狀態信息數據，這些數據都在一張表里，當這些數據達到百萬甚至千萬級別時，用戶查詢數據的效率和速度都會降低，在界面上的體現是會發現搜索或跳轉頁面的時候特別卡，這個時候對數據庫進行分庫分表就是個不錯的方案。

舉一個我以前做的RBAC權限管理功能為例子，這個功能包括組織架構模塊、角色模塊、菜單權限模塊、人員管理模塊這四個核心模塊，復雜一點的還會有其他模塊，在這里不做說明。

我們設計好原型圖之后，可以梳理出各個模塊實體的主鍵、外鍵以及其他的屬性。其中主鍵是唯一標識一條記錄的，比如每個學生的學號是唯一的，學號就是一個主鍵。外鍵是用來和其他表建立聯系用的，A表的外鍵往往是B表的主鍵。

組織架構模塊：

• 包含的屬性：組織id（一般不在前端展示）、組織機構類型、機構名稱、單位類型、聯系人、郵箱、電話等等
• 可選唯一標識的屬性（又稱主鍵）：組織id或機構名稱
• 存儲特點：永久存儲

角色模塊：

• 包含的屬性：角色id、角色分類、角色名稱、角色描述、角色排序id、創建人、創建時間等等
• 可選唯一標識的屬性：角色id或角色名稱
• 存儲特點：永久存儲

菜單權限模塊：

• 包含的屬性：菜單id、菜單排序id、菜單名稱、菜單路徑url等等
• 可選唯一標識的屬性：菜單id或菜單名稱
• 存儲特點：永久存儲

人員管理模塊：

• 包含的屬性：用戶id、姓名、單位職務、級別、手機號、登錄名等等
• 可選唯一標識的屬性：人員id
• 存儲特點：永久存儲

（2）邏輯設計

第二步是邏輯設計，也是產品經理要重點學習的。

我們將上述模塊的需求轉化為數據庫的邏輯模型，一般用ER圖表示。

簡易版可以在紙上畫出來，作為初稿：

輸出的圖例規范如下：

矩形表示實體集，菱形表示聯系集，橢圓表示實體的屬性，線段表示兩者之間的連接。

運用數據庫范式設計具體的表：

數據庫的范式有很多種，包括第一范式、第二范式、第三范式等等，這些設計范式的晦澀的術語定義不會出現在本文中。直接用相關的案例將它們描述出來，相信能夠被更多人看懂。

第一范式：

采用這種范式設計出來的是一張二維表，且這種二維表的字段是不可以繼續再分的，比如“聯系方式”字段下面不能再拆分為“郵箱”和“電話”兩個字段。這也是最簡單且最容易遵守的一種范式。舉個例子，下面的表格就是符合第一范式的。

第二范式：

這種范式是在第一范式的基礎上定義的，下面的表中結合了組織架構和人員管理兩張表的屬性。

所以符合第二范式的表如下：

【人員管理表】

【組織架構表】

【關聯表】

第三范式：

這種范式是在第二范式的基礎上定義的，下面這張表包含了組織架構、人員管理和角色管理這三張表的屬性。

大家可以看到，一個組織架構下面會有很多用戶，一個用戶也會有很多角色。所以按照第三范式設計的表如下：

【人員管理表】

【組織架構表】

【角色表】

【關聯表】

小結：第一范式和第二范式的區別在于有沒有分出兩張表，第二范式是說一張表中包含了多種不同的實體屬性，那么必須要分成多張表， 第三范式是要求已經分成了多張表，那么一張表中只能有另一張表中的主鍵，而不能有其他的任何信息（其他的信息一律用主鍵在另一表中查詢）。

其實除了以上三個范式，還有第四、第五、BC以及反范式化設計，這里不做擴展，有興趣的可以自行查詢了解。

綜上，結合范式和ER圖輸出的表結構如下：

為了方便理解，表中的屬性字段命名我寫成了中文，實際上在數據庫里都是英文，比如用戶id可以命名為UserId,命名的工作在物理設計中進行，一般是架構師去處理。

（3）物理設計

第三步是物理設計，一般是架構師做的事，產品經理簡單了解下即可，同樣也不做擴展說明。

• 選擇合適的數據庫管理系統
• 定義數據庫、表及字段的命名規范
• 根據所選的數據庫管理系統選擇合適的字段類型。

結尾

了解了以上的知識并不能使你精通數據庫，尤其是像這種底層的東西，僅靠一篇文章是很難完全掌握的。比如在業務需求、性能和數據冗余之間達到一個平衡就需要深厚的數據庫功底。

但通過本文可以了解最基礎的數據庫邏輯設計應該怎么做，會對業務系統的技術實現有更深刻的認識，若有SQL基礎則能更容易理解。

本文由 @葩說產品 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議