產品經理的技術修行筆記——資料庫篇

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

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

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

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

一、基礎名詞理解

數據：「數據是對客觀事物的符號表示，在計算機科學中指所有能輸入到計算機中，並被計算機程序處理的符號的總稱。」這是之前在數據結構篇中對數據的定義，那麼結合資料庫來理解，數據是資料庫中存儲的基本對象。

資料庫：可長期存儲在計算機內，有組織、可共享的大量數據的集合，具有永久存儲型有組織和可共享三個基本特點。

數據管理：對數據進行分類、組織、編碼、存儲、檢索和維護，是數據處理的中心問題。

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

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

二、數據模型

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

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

概念模型：又稱信息模型，是指按用戶的觀點來對數據進行建模，主要用於資料庫設計。

邏輯模型：按計算機系統的觀點對數據和信息建模，主要用於DBMS（資料庫管理系統）的實現。

物理模型：對數據最低層次的抽象，描述系統內部的表示和取存方法。

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

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

數據結構：在之前的數據結構篇中有詳細的介紹（產品經理的技術修行筆記——數據結構篇）。

數據操作：就是對資料庫中的各種對象可執行的操作的集合，比較常見的為資料庫的增刪改查。數據操作在平台類產品中十分常見。比如：電商後台管理系統中，針對一個商品的信息進行修改，上傳圖片、更新庫存，或者直接刪除新增商品，就是針對一個商品的數據操作。

數據的完整性約束：指的是為了防止不符合規範的數據進入資料庫，在用戶對數據進行插入、修改、刪除等操作時，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」 屬性只能取下面兩類值：

空值：表示該課程還未確定類別。

非空值：此時取值必須和「課程」表這某個元祖的「類型ID」值相同，表示這門課程歸屬該類別。

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

3.3 關係資料庫的標準語言

SQL ：即結構化查詢語言，是關係資料庫的標準語言。

特點表現為：

綜合統一；

高度費過程化；

面向集合的操作方式；

以一種語法結構提供多種使用方式；

語言簡潔、易操作。

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

（1）定義基本表

create table

[約束條件]

[約束條件]

………

（2）修改基本表

alter table

[add [約束條件]]——增加新的列和條件

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

[alter column ]——修改列定義

（3）刪除基本表：

drop table

（4）數據查詢

select [ALL|DISTINCT]……——取消重複列

From ……

[where ]

[group by [HAVING ]]

[order by [ASC|DESC]

四、總結

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

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

新增的功能需要現有資料庫所做的調整是什麼，以及後期的規劃中是否會有類似的調整，是否需要統一設計；

明確1的基礎上，思考這個修改對原有的老版本產品功能是否會有影響。

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

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

參考教材：資料庫系統概論

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

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

題圖來自Unsplash，基於CC0協議

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！