導讀產品經理在產品功能設計，尤其是平臺類產品設計的過程中，必然涉及到數據模型以及數據操作相關的設計。在用戶場景和功能層面來看，是一個個根據用戶的使用場景設計的功....

產品經理在產品功能設計，尤其是平臺類產品設計的過程中，必然涉及到數據模型以及數據操作相關的設計。

在用戶場景和功能層面來看，是一個個根據用戶的使用場景設計的功能點。但是從數據層面來看，是根據用戶在該場景內對產品輸入的數據信息進行處理并輸出結果的一個過程。

和數據結構相對應，數據庫作為存儲數據的容器，所有與產品相關的功能數據、用戶信息、操作數據等都存儲在數據庫中。通過學習數據庫，可以從數據視角看產品，更多地從數據存儲、數據關聯等方面來對產品進行剖析。數據庫對于從事平臺產品設計，或者數據產品的小伙伴來說，尤其重要。

本文將與大家分享數據庫相關的基礎知識，希望可以共同學習，共同進步。

一、基礎名詞理解

• 數據：“數據是對客觀事物的符號表示，在計算機科學中指所有能輸入到計算機中，并被計算機程序處理的符號的總稱。”這是之前在數據結構篇中對數據的定義，那么結合數據庫來理解，數據是數據庫中存儲的基本對象。
• 數據庫：可長期存儲在計算機內，有組織、可共享的大量數據的集合，具有永久存儲型有組織和可共享三個基本特點。
• 數據管理：對數據進行分類、組織、編碼、存儲、檢索和維護，是數據處理的中心問題。

數據管理從人工管理階段，到文件系統階段到現在的數據庫系統階段，最本質的差別在于：數據庫管理做到了數據結構化。

舉個例子來說：將數據庫比喻成一個倉庫，那么數據就是這個倉庫中的貨物，管理員對這些貨物做分類整理、運輸等操作，就是數據管理。數據結構化就是講這些貨物分類分等地排列在貨架中，以便管理員能更好地進行管理。

二、數據模型

數據模型是對現實世界數據特征的抽象，是數據庫系統的核心和基礎，是數據結構化到一定程度的產物，是一種機構化數據的展現。

數據模型有概念模型，邏輯模型和物理模型三種：

1. 概念模型：又稱信息模型，是指按用戶的觀點來對數據進行建模，主要用于數據庫設計。
2. 邏輯模型：按計算機系統的觀點對數據和信息建模，主要用于DBMS（數據庫管理系統）的實現。
3. 物理模型：對數據最低層次的抽象，描述系統內部的表示和取存方法。

以上幾個模型的一般實現順序與流程為：

數據模型有三大組成要素：數據結構、數據操作、數據的完整性約束條件。

1. 數據結構：在之前的數據結構篇中有詳細的介紹（產品經理的技術修行筆記——數據結構篇）。
2. 數據操作：就是對數據庫中的各種對象可執行的操作的集合，比較常見的為數據庫的增刪改查。數據操作在平臺類產品中十分常見。比如：電商后臺管理系統中，針對一個商品的信息進行修改，上傳圖片、更新庫存，或者直接刪除新增商品，就是針對一個商品的數據操作。
3. 數據的完整性約束：指的是為了防止不符合規范的數據進入數據庫，在用戶對數據進行插入、修改、刪除等操作時，DBMS自動按照一定的約束條件對數據進行監測，使不符合規范的數據不能進入數據庫，以確保數據庫中存儲的數據正確、有效、相容。比如：我們定義學生年齡字段的數據類型為整型，那么就無法將帶有小數點的數字作為年齡插入之年齡字段中。

三、關系數據庫

以最常見的關系數據庫為例，對數據庫相關的概念，操作以及和產品設計相關的知識進行整理。

3.1 基本概念

• 實體：客觀存在并可互相區分的事物。
• 屬性：實體所具有的某一特征。
• 碼：唯一標識實體的屬性集。
• 關系：實體之間的關系，主要可分多1：1、1：N、M：N三種。

為了更清晰地對以上幾個名詞進行理解，還是以學生和班級為例：

在這個例子中，學生和班級就是兩個實體。學生的姓名、學號等就是學生的屬性，學號作為唯一標識學生的屬性，就是學生這個實體的碼。

那么學生與班級之間的聯系可以表示為N：1，因為一個學生只能在一個班級中，而一個班級中有多個學生。

一組關系組合在一起，就是關系模型。關系數據庫是一種基于關系模型的數據庫，是以顯示世界中各個實體之間的關系為基礎，來展現數據的數據庫。每個關系的數據結構都可以用一張規范話的二維表來表示。一個關系通常對應一張表，每一列為一個屬性。

3.2 關系數據庫的完整性

• 實體完整性：實體完整性要求每個表都有唯一標識符，每一個表中的主鍵字段不能為空或者重復的值——即若屬性A為基本關系R 的主屬性，那么A不能取空。
• 參照完整性：參照完整性要求關系中不允許引用不存在的實體，設定相應的更新刪除插入規則來更新參考表——即若屬性（或者屬性組）F還基本關系S的外碼，它與基本關系S 的主碼K對應，則對于R中每個元祖在F 上的至必須為1，空值為2，等于S中某個元祖的主碼值。

舉例理解一下，以課程表為例：

（1）課程表（課程ID、課程名、類型ID、學分… …）。

（2）課程類別表（類型ID、類型）。

這兩個表之間存在著屬性的引用——即“課程”表引用了“課程類別”表的主鍵“類型ID”。

按照參照完整性規則，“課程”表中每個元祖的“類型ID” 屬性只能取下面兩類值：

1. 空值：表示該課程還未確定類別。
2. 非空值：此時取值必須和“課程”表這某個元祖的“類型ID”值相同，表示這門課程歸屬該類別。

（3）用戶定義完整性：用戶自定義完整性是針對某一具體關系數據庫的約束條件，它反映某一具體應用所涉及的數據必須滿足的語義要求。

3.3 關系數據庫的標準語言

SQL ：即結構化查詢語言，是關系數據庫的標準語言。

特點表現為：

1. 綜合統一；
2. 高度費過程化；
3. 面向集合的操作方式；
4. 以一種語法結構提供多種使用方式；
5. 語言簡潔、易操作。

常見的操作語句有以下幾種：

（1）定義基本表

create table <表名>

<列名> <數據類型> [約束條件]

<列名> <數據類型> [約束條件]

………

（2）修改基本表

alter table <表名>

[add <新列名> <數據類型> [約束條件]]——增加新的列和條件

[drop [約束條件]]——刪除條件

[alter column <列名> <數據類型> ]——修改列定義

（3）刪除基本表：

drop table <表名>

（4）數據查詢

select [ALL|DISTINCT]<目標表達式>……——取消重復列

From <表名或視圖名>……

[where <條件表達式> ]

[group by <列名1> [HAVING <條件表達式>]]

[order by <列名2> [ASC|DESC]

四、總結

雖然對于客戶端產品經理來說，進行產品功能設計時并不需要去考慮數據庫的設計，一般會有架構師或者核心開發來規劃。但是需要明確的是：一個個產品功能最終是由數據通過產品設計的業務邏輯來展現出來的。

所以當技術提出，產品的需求影響了現有數據庫的設計，或者完成這個需求需要改變數據庫的結構時，產品經理需要從產品的現有功能和后期規劃中來考慮有關數據的這兩個問題：

1. 新增的功能需要現有數據庫所做的調整是什么，以及后期的規劃中是否會有類似的調整，是否需要統一設計；
2. 明確1的基礎上，思考這個修改對原有的老版本產品功能是否會有影響。

對于平臺類產品經理來說，對數據庫的學習應該需要更加深入。因為平臺在某種意義上來說，其實就是一個數據庫操作系統。以視頻類產品的資產管理后臺為例：所涉及到資產管理，推薦管理等功能，其實都是對于資產等實體進行查詢，修改等操作的過程。

以上是本次的數據庫的學習筆記，可能會有一些不合理的地方，希望共同學習共同進步。

參考教材：數據庫系統概論

作者：方小白，2年互聯網產品經驗，專注用戶增長與會員運營。

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

題圖來自Unsplash，基于CC0協議