您的位置:首頁>正文

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

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

在用戶場景和功能層面來看,

是一個個根據使用者的使用場景設計的功能點。 但是從資料層面來看, 是根據使用者在該場景內對產品輸入的資料資訊進行處理並輸出結果的一個過程。

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

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

一、基礎名詞理解

資料:“資料是對客觀事物的符號表示, 在電腦科學中指所有能輸入到電腦中,
並被電腦程式處理的符號的總稱。 ”這是之前在資料結構篇中對資料的定義, 那麼結合資料庫來理解, 資料是資料庫中存儲的基本物件。 資料庫:可長期存儲在電腦內, 有組織、可共用的大量資料的集合, 具有永久存儲型有組織和可共用三個基本特點。 資料管理:對資料進行分類、組織、編碼、存儲、檢索和維護, 是資料處理的中心問題。

資料管理從人工管理階段, 到檔案系統階段到現在的資料庫系統階段, 最本質的差別在於:資料庫管理做到了資料結構化。

舉個例子來說:將資料庫比喻成一個倉庫, 那麼資料就是這個倉庫中的貨物, 管理員對這些貨物做分類整理、運輸等操作, 就是資料管理。 資料結構化就是講這些貨物分類分等地排列在貨架中,

以便管理員能更好地進行管理。

二、資料模型

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

資料模型有概念模型, 邏輯模型和物理模型三種:

概念模型:又稱資訊模型, 是指按使用者的觀點來對資料進行建模, 主要用於資料庫設計。 邏輯模型:按電腦系統的觀點對資料和資訊建模, 主要用於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 <列名1> [HAVING <條件運算式>]]

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

四、總結

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

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

新增的功能需要現有資料庫所做的調整是什麼,以及後期的規劃中是否會有類似的調整,是否需要統一設計;明確1的基礎上,思考這個修改對原有的老版本產品功能是否會有影響。

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

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

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

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

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

題圖來自Unsplash,基於CC0協議

而一個班級中有多個學生。

一組關係組合在一起,就是關係模型。關聯式資料庫是一種基於關係模型的資料庫,是以顯示世界中各個實體之間的關係為基礎,來展現資料的資料庫。每個關係的資料結構都可以用一張規範話的二維表來表示。一個關係通常對應一張表,每一列為一個屬性。

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 <列名1> [HAVING <條件運算式>]]

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

四、總結

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

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

新增的功能需要現有資料庫所做的調整是什麼,以及後期的規劃中是否會有類似的調整,是否需要統一設計;明確1的基礎上,思考這個修改對原有的老版本產品功能是否會有影響。

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

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

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

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

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

題圖來自Unsplash,基於CC0協議

同類文章
Next Article
喜欢就按个赞吧!!!
点击关闭提示