數據庫(5)---數據庫系統的實現

【聲明】本文章來自穆晨 - 博客園,記錄于此方便后期的學習和查閱

一、前言

雖說數據庫系統的具體實現因業務環境,RDBMS等因素而異,但總體開發流程,以及開發過程中所涉及到的一些問題,也具有不少統一的套路、標準。

本文主要討論數據庫系統實現過程中的重點環節、基本開發流程、數據庫管理以及數據質量工程等話題。

二、參照完整性約束對更新刪除操作的影響

第3篇中已經討論過,關系設計的目的就是為了減少冗余,消除更新異常。但當時也留下一個問題:外碼冗余時,該如何解決呢?

關系數據庫理論將外碼冗余的問題交給了RDBMS,讓它來解決涉及外碼的更新異常。如下存在外碼的關系中:

關系EMPLOYEE中的Dept屬性是一個外碼,它對應DEPARTMENT關系的主碼。如果對該屬性進行更新或者刪除,那么這個外碼就找不到它對應的主碼,兩個關系的聯系就被破壞了。針對這個問題,RDBMS的解決方案有四個,下面以刪除異常為例進行說明:
  • 限制刪除:指如果某記錄主碼被另一個記錄外碼對應,則該記錄不允許被刪除。如上面示例DEPARTMENT關系中的記錄在刪除的時候有可能被RDBMS禁止。

  • 級聯刪除:指如果某個記錄的主碼被另一個記錄的外碼對應,那么這兩個記錄將一起被刪除。

  • 設置為空:指如果某個記錄的主碼被另一個記錄的外碼對應,那么在刪除這個記錄后,另外那個記錄的外碼字段設置為空。

  • 設置默認值:同“設置為空”,不過是將設置為空改為設置成一個默認值。

更新情況和刪除一樣,要注意的是所有處理都發生在對外碼映射中的非外碼關系進行操作時發生。這些處理主要是對外碼關系進行附加操作,如級聯刪除,置空,置默認值,或者報錯。

三、索引機制

索引(index)機制的本質是一種檢索加速機制,本文將從索引的邏輯意義上對它進行解析,至于其在各RDBMS里的物理實現細節則不做介紹。如下客戶關系表中:

由于CustID是按順序排列的,如果要檢索某CustID值對應的記錄,可使用多種查找算法提高檢索效率,如二分查找等。但關系中某一列排好序以后,其他列必然是亂序的,那如何解決?在RDBMS中,這種情況可以通過新建一個只包含兩列的附加表來實現:

索引表中,其中一列為索引字段,另一列則包含一個指針指向原紀錄。這樣在對索引列進行查詢的時候,RDBMS會先對索引表進行操作,完了再映射到原表并返回結果。

從本質上來說,這是一種犧牲空間換取時間的辦法,索引建立不單耗費存儲資源,而且會降低更新、刪除等操作的效率。因此不是說建的索引越多就越好,具體建立何種索引,建立多少索引,則要取決于計算資源,RDBMS,業務場景等因素。

四、觸發器機制

觸發器是一種規則,當關系中刪除、插入、修改一條記錄的時候執行。它的應用場景很多,如:每次向關系表中插入記錄后,更新記錄總數,如果超過了n,則不再插入數據。幾乎所有RDBMS都提供了該功能。

觸發器的代碼,不是標準SQL代碼,不必細究。觸發器實現代碼的語法規則取決于RDBMS,需要時再有針對性的參考手冊即可。

五、數據庫系統開發流程

數據庫系統(database system):指讓用戶和數據庫信息之間進行有效交互的計算機系統。其典型的框架如下圖所示:

數據庫系統的三大主要部分:數據庫、數據庫管理軟件(RDBMS)、前端應用程序(Web/APP等)。

數據庫是數據庫系統的核心,負責存放所有數據。而數據庫對外的所有交互,均通過RDBMS來進行。一般用戶通過前端應用程序使用RDBMS,而比較專業的用戶也可直接使用RDBMS操縱數據庫。

舉例來說,某人通過APP訂購商品,那么這個APP就是前端應用程序,而當她有一個具體行為,比如付款的時候,前段應用程序就會和RDBMS通信,讓RDBMS完成扣款,并返回操作執行結果。

數據庫系統的開發流程,總體可以劃分為以下幾個步驟:
1. 數據庫需求

需求搜集是所有環節中最重要的一步。通常,都會通過ER圖進行表示,并和各業務方討論搜集得到,最終整理成文檔。這些需求將指導后面的工作,如:需求建模、數據庫實現、以及前端應用程序開發等。

特別強調,數據庫系統開發需求階段,其過程是循環迭代式的,一開始的需求集并不大,但隨著項目的進展,需求會越來越多。但不論是以上哪個階段發生了需求變動,整個流程都需要重新走一遍,決不允許隱式變更需求。

2. 數據庫建模

數據庫建模階段,即邏輯模型建模,在本系列文章的第2篇已詳細講解,這里不再贅述。

3. 數據庫實現

這一步的本質就是在空的RDBMS里實現2中創建的關系模型,一般通過使用SQL或者RDBMS提供的前端工具實現。

4. 開發前端應用程序

前端應用開發,在需求搜集好之后就開始進行了,主要有網站、APP等前端形式,由于前端程序的實際實現涉及到和數據庫之間交互,因此這一步的最終完成在數據庫建模之后。

5. 數據庫部署

這一步就是部署數據庫系統的軟硬件環境。還包含將初始數據填入數據庫中。對于云數據倉庫,這一步就叫"數據上云"。

6. 數據庫使用
7. 數據庫管理和維護

嚴格來講,這部分不算開發流程,屬于數據庫系統開發完成后的工作。接下來本文將圍繞這個話題進行講解。

六、數據庫系統管理

數據庫系統發行后,控制權便從數據庫設計、實現、部署的團隊,移交給了數據庫管理員(database administrator, DBA),并由他們來對系統進行管理。

數據庫管理涵蓋了確保一個已經部署的數據庫系統正確運行的各種行為。主要包含以下范疇:

這部分工作的涉及面相當廣而深,應由專業的DBA團隊去完成。本文主要針對人群是數據科學家,因此僅對這些工作做一個簡明的介紹。

1. 數據庫系統監測與維護

DBA需要監測數據庫系統的運行情況,并針對發現的問題進行維護。比如發現存儲資源不夠用了,則要分配給數據庫系統更多存儲空間等。

DBA需要掌握數據庫中各關系的具體使用情況,從而進行優化。比如某兩個表被很多用戶頻繁使用,并只用來重復創建相同的報表。這時候DBA就可以考慮建議數據庫開發團隊反規范化設計的將這兩個表合并到一起。

2. 數據庫安全保障

安全保障工作,是數據庫系統管理工作中的首要任務,該任務需要DBA對數據的存取過程嚴加控制,包括:數據庫訪問人員的賬戶認證、權限劃分、敏感數據的加密等。

3. 數據庫備份與恢復

數據庫的數據,是存放在計算機的物理磁盤里,而計算機對數據的處理過程,都是先把數據從硬盤轉移到內存,處理完后再存放回去。

如果數據在內存中進行處理,還沒有將數據轉移回磁盤的時候,數據庫掛了的話就將導致數據丟失。因此RDBMS采用恢復日志(recovery log)機制,先記錄更新操作要做的事情,比如那個數據被更新,更新前后的值,更新請求的用戶等,然后再做具體的更新操作。在更新日志中可以設置"檢查點",之后DBA可使用它進行周期性副本備份。失效事件發生之后,DBA可以利用"檢查點"進行系統恢復:回滾(Roll Back)至指定檢查點狀態。

對于那種徹底性毀壞的情況,比如發生火災、地震等,可在多個不同物理站點上保留完全鏡像備份(complete mirrored backup)。這些副本需持續更新保證與數據庫系統一致。

4. 數據庫性能優化

性能優化包括:設置索引、逆規范化、SQL優化等,通常用QPS(query per second)等指標來衡量數據庫系統的優化效果。

這部分工作內容很多也比較雜,主要通過DBA管理RDBMS的查詢優化器來完成。但對于數據庫的開發員和使用者來說,也多多少少要知道一點,比如寫Hive語句時,需要靈活設置分區,避免數據傾斜等。

5. 數據庫標準制定

這部分工作包括數據庫中字段命名規范、SQL編碼規范的制定等。除了這些開發標準,還有使用標準,比如使用數據庫的人需要遵守哪些有益于數據庫系統健康的行為規范等。

七、數據質量體系

數據庫系統,以及數據倉庫系統,都需要始終重視數據質量問題。一句話概括:數據質量就是衡量數據能否真實、及時反映客觀世界的指標。

具體來說,數據質量包含以下幾大指標:
1. 準確性

準確性要求數據能夠正確描述客觀世界。比如某用戶姓名拼音mu chen,錯誤的錄入成了muc hen,就應該彈出警告語。

2. 唯一性

唯一性要求數據不能被重復錄入,或者不能有兩個幾乎相同的關系。比如張三李四在不同業務環境下分別建立了近乎相同的關系,這時應將這兩個關系合并。

3. 完整性

完整性要求進行數據搜集時,需求數據的被描述程度要高。比如一個用戶的購買記錄中,必然要有支付金額這個屬性。

4. 一致性

一致性要求不同關系、或者同一關系不同字段的數據意義不發生沖突。比如某關系中昨天存貨量字段+當天進貨量字段-當天銷售量字段等于當天存貨量,否則就可能是數據質量有問題。

5. 及時性

及時性要求數據庫系統中的數據"保鮮"。比如當天的購買記錄當天就要入庫。

6. 統一性

統一性要求數據格式統一。比如nike這個品牌,不能有的字段描述為"耐克",而有的字段又是"奈克"。

數據質量和數據具體意義有很大相關性,因此無法單憑數據庫理論來保證。且由于具體業務及真實世界的復雜性,數據質量問題必然會存在,不可能完全預防得了。因此很多RDBMS或第三方公司都提供了數據質量工程服務/軟件,用來識別和校正數據庫系統中的各種數據質量問題。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,818評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,185評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,656評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,647評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,446評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,951評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,041評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,189評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,718評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,602評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,800評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,316評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,045評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,419評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,671評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,420評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,755評論 2 371