正文
導讀:今天有小夥伴在群問有沒有數據倉庫建設規範,參與過兩個數據倉庫的規劃,寫過一些規範文檔,今天分享給大家,大家可以借鑑,完成自己的規範!
以下為完整的內容,供大家參考。
1 概述
本文檔制定了XX數據倉庫中資料庫對象的命名規範(用戶、表、視圖、存儲過程、函數、表分區、主鍵、索引、序列等)、資料庫編程規範,JAVA編程規範為系統設計和開發工作提供統一的命名標準,提高系統的規整性和代碼的可讀性,減輕維護工作量,提高工作效率。
2 資料庫對象命名規範2.1 層次劃分
序號
模型層次
用途
1
ODS
存放來自各個系統的原始數據;
2
DW
根據業務分析需求,對主題域內的數據進行輕度匯總;
3
DM
建立跨域的業務主題模型;
4
DIM
統一服務於數據中心的參數表;
5
APP
應用層,用於生成報表
6
XX
XX
數據層級按照自己數據倉庫規劃的命名即可~
2.2 表、視圖、存儲過程、函數命名規範<對象類型><_模型層次><_主題><_對象描述>[_匯總類型][_存儲類型]
說明:<> 尖括號中的內容為必須項,適用於所有用戶層對象,[] 方括號中的內容為可選項,會因用戶層及對象的不同而不同
命名約束:資料庫對象命名可能受最大長度限制,因此在實際命名中如果按照規範約定的命名方式存在超長的現象,需要開發人員靈活控制。
2.2.1 對象類型<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型]。
適用範圍:所有用戶層對象。
對象類型
對象
說明
TB
TABLE
表
VW
VIEW
視圖
……
……
……
2.2.2 模型層次
<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型]
說明:對象屬性一般為對象歸屬用戶的簡寫。
適用範圍:所有用戶層對象。可以參照自己的對象屬性命名規範,對此不要求統一。
模型層次
說明
ODS
獲取層,存放從各個源系統接收的原始數據;
DW
根據業務分析需求,對數據進行匯總,
應用分析原則優先訪問DW層,其次DWD層,不允許訪問ODS層;
DM
建立跨域的業務主題模型;
DIM
維表
APP
報表層,根據DM模型數據生成報表。
2.2.3 主題域
<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型][_][序號或描述]
說明:主題域是對數據進行大類劃分,不同用戶下的分類有所不同。適用所有業務層;每個新增的業務主題均需到該規範備案登記。
主題域
命名
簡稱
描述
客戶域
Customer
XX
泛客戶
…
…
…
…
2.2.4 對象描述
<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型]
如果是通用命名規則:<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型],這裡的對象描述是多業務的合成體,這時不加業務。
匯總類型
<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型]
適用範圍:除字典表、日誌表之外的對象。
2.2.5 存儲類型<對象類型><_模型層次><_主題域><_對象描述>[_匯總類型][_存儲類型]
適用範圍:所有用戶層除日誌、字典表、維表之外的對象。
對象描述
存儲類型
說明
目標程序
無
臨時表
TMP
程序中臨時使用的中間表,用於存放程序運行中使用的臨時數據,程序運行結束後表由程序自行清空,只保留結構。
配置表
CFG
月表以統計周期欄位做月分區。除該欄位外,其餘欄位與日表必須相同。數據保留周期為業務需要的周期。所有的月報表、月KPI數據必須從月表出,禁止從日表出。
2.2.5.3 周表周表數據保留周期為業務需要的周期。
2.3 其他對象命名規範對象
命名規則
說明
表分區
根據實際情況自行確定
建議等
主鍵
PK<_表名><_列名>
索引
IDX<_表名><_列名>
…
…
…
2.4 常用欄位命名規範
欄位名
數據類型
欄位說明
備註
常用欄位1
常用類型1
欄位說明1
備註1
欄位命名需做到見名知其意,避免用中文拼音,或者拼音+英語的方式。
可以參考企業現有業務資料庫的數據字典命名。
2.5 常用單位規範約定數據倉庫中欄位的默認單位,比如車速默認單位是KM/h。
2.6 資料庫對象命名注意事項2.7 數據倉庫建表注意事項表名,列名等需要添加注釋,否則不予上線。
XX……。
3 主機目錄及文件命名規範3.1 用戶命名規範主機用戶名命名規範:
序號
主機用戶名
帳號類型
用途
1
hadoop
應用程式帳號
hadoop集群管理用戶
2
…
ftp帳號
…
3.2 目錄規劃<根目錄>/<二級目錄>/[三級目錄/]<業務域>[/自定義]
目錄規劃不做強制性的要求,但是要做到層次清晰、命名規範,見名知意。
l 根目錄
取值為:根據物理存儲掛載情況而定;
l 二級目錄
取值為:主機如果沒有文件系統掛載點,則二級目錄為用戶家目錄,否則取值用戶名;
l 三級目錄
取值為:用戶自行定義,如果存儲在用戶家目錄下則需要三級目錄;
l 業務域
取值為:抽取的文件按業務類型進行分類存儲。
l 自定義
取值為:可選項,如果文件存儲有其它要求,可根據實際情況靈活調整,如需要分省存放等。
3.3 文件命名規範<文件類型>_<主題域>_<數據周期>_<接口文件序號>.dat
主題域取值情況咱定為各項目名稱:
取值為:周期日數據8位長度,YYYYMMDD,月數據6位長度YYYYMM;
取值為:接口文件序號長度為3,默認從000開始;
3.4 文件格式規範文件欄位儘量不採用定長分隔,採用「|」等特殊字符作為分隔符,另外在抽取文件時需要確定欄位內容中不會出現分隔符字符,以免錯列;
文件編碼採用UTF-8。
4 數據保存周期規範周期類型
模型層次
保留周期(HIVE)
備註
日
ODS
365
……
對象變量命名規則如下:
命名規則:<對象類型><_><變量描述>
.
5.1.2 參數和對象命名注意事項所有名稱採用英文單數名詞或動詞,避免出現複數。
固定長度的字符串類型採用char,長度不固定的字符串採用varchar,一定要避免長度不固定的情況下採用char。
如無特殊需求,避免使用大欄位(blob, clob, long, text, image 等)。
命名使用英文單詞,避免使用拼音,特別不應該使用拼音簡寫。命名不允許使用中文或者特殊字符。
命名中若使用特殊約定或縮寫,則必須要注釋說明。
使用有意義、易於記憶、描述性強、簡短及唯一的英文單詞。自已特有的命名風格,要自始自終保持一至,不可來回變化。
對於變量命名,禁止取單個字符(如i、j… ),建議除了要有具體含義外,還能表明變量
除非必要,不允許使用數字或較奇怪的字符來定義標識符。
5.2 書寫規範5.2.1 代碼大小寫規範5.2.2 代碼縮進規範程序塊採用縮進風格書寫,保證代碼清晰易讀,風格一致。縮進格數統一為 4 格。
必須使用空格,禁止使用TAB鍵。
同一條語句佔用多於一行時,每行的第一個關鍵字應當右對齊。
對於Insert … values 和update 語句,一行寫一個欄位,這段後面緊跟注釋(注釋語句左對齊),vales 和insert 左對齊,左括號和右括號與insert、values 左對齊
insert...select語句中,應使每行的欄位順序對應,以每行不超過80字符為準,以增強可讀性。
5.2.3 空格及換行關鍵字之後要留空格。
創建表、存儲過程、函數時,表名、存儲過程名和函數名之後不要留空格。
不允許把多個語句寫在一行中,即一行只寫一條語句。
相對獨立的程序塊之間、變量說明之後必須加空行。
超過80字符的語句要分行書寫,長表達式應在低優先級操作符處換行,操作符或關鍵字放在新行之首。劃分出的新行應適當地縮進,使排版整齊,語句可讀。
if後的條件要用括號括起來,括號內每行最多兩個條件。
不同類型的操作符混合使用時,建議使用括號進行隔離,以使代碼清晰。
減少控制語句的檢查次數,如在else(if…else)控制語句中,對符合條件頻率高的儘量放到前面。
儘量避免使用嵌套的if語句,在這種情況應使用多個if語句來判斷其可能。
5.2.4 其它避免使用select * 語句。
insert 語句必須給出欄位列表,否則對後續表的擴展回帶來維護上的麻煩。
當一個SQL 語句中涉及到多個表時,必須使用別名來限定欄位名,這使其它人閱讀起來更方便,避免了含議模糊的引用,其中能夠別名中清晰地判斷出表名。
確保變量和參數在類型和長度與表數據列類型和長度相匹配。
5.3 注釋規範一般情況下,源程序有效注釋量不低於30%以上。說明:注釋的原則是有助於程序閱讀理解,便於後期維護,在該加的地方都加了,注釋不宜太多但也不能太少,注釋語言須準確、易懂、簡潔。
所有變量定義需要加注釋,說明該變量的用途和含義。
注釋內容要清晰明了,含義準確,防止注釋二義性。
禁止在注釋中使用縮寫,特別是非常用的縮寫。
注釋與所描述代碼進行同樣的縮排。
對程序分支必須書寫注釋。
保證代碼和注釋的一致性。修改代碼同時修改相應的注釋,不再有用的注釋要同步刪除。
注釋應與其描述的代碼相似,對代碼注釋應放在其上方或右方(單條語句的注釋)相應的位置,不可放在下面。
注釋上面的代碼應空行隔開。
統一文件頭的注釋。
在代碼的功能、意圖層次上進行注釋,提供有用、額外的信息。
函數應對返回代碼詳細描述。
儘量使用」#」進行注釋。
避免在一行代碼或表達式的中間插入注釋。
所有硬編碼必須加注釋,如 id='0' 則需要優先注釋 '0'的含義, 或者在注釋中說明對應的字典表。
5.4 語法規範所有DDL和DML語句儘量遵循標準SQL,以SQL99為基準。
說明:採用標準SQL編寫,方便移植時各種資料庫之間做對應修改。
正例:
delete from table1;
反例:
delete table1;
數據類型採用基本數據類型,儘量不要使用某資料庫特有的類型。
說明:採用基本數據類型,各種資料庫均支持,減少不同版本的維護。設計數據類型和長度時要考慮應用編程開發的方便以及後續可維護性。
l對於特別複雜的sql(特別是多層嵌套,帶字句或相關的查詢),應先考慮是否設計不當引起,對複雜的sql可以通過程序實現,原則上遵循一句話只做一件事情,避免多重嵌套SQL的使用。必要時採用中間表。
對於超過2個以上的大表關聯,必須進行執行計劃驗證,並在設計中有所體現。
不要將空的變量值直接與比較運算符比較。如果變量可能為空,應該使用is null或is not null來進行比較。
每個程序過程生成的目標數據表不允許出現空值。
儘可能地使用相關表欄位的類型定義,如%type,%rowtype等。
對資料庫腳本代碼中所定義的變量要進行初始化。\
……
5.5 程序結構5.5.1 程序結構模板定義一個模板供大家參考!
5.5.2 程序代碼5.5.2.1 程序代碼規範程序代碼段左側要留有1個縮進(4個空格)。
除特殊程序(如空調度、日誌程序等)外,程序開始、程序結束、程序出錯時都要記錄日誌,日誌記錄使用公用的函數或存儲過程,具體使用方法參見後面日誌內容。
關鍵字要換行輸寫,不同行關鍵字要右對齊。
對於內容超過一行的代碼,換行時要有一個縮進,並注意對齊以保證美觀。
每個欄位後面都要有欄位說明(欄位描述、值內容、單位等),欄位說明要對齊。
欄位說明內容可以換行,但同樣要與上行欄位說明內容對齊。
對於比較簡單的SQL語句,也可根據實際情況寫在一行或幾行中,但多行的要注意縮進,並且要注意美觀性。
對於insert欄位數量比較多的語句,對應的select中的欄位儘可能定義別名,別名要與insert中欄位名相同,這樣很容易找到欄位的對應關係。
對於多層嵌套,一定要注意各層嵌套的縮進層次,才能保證代碼良好的可讀性,否則代碼將非常難讀。
關鍵字、保留字之間必須留有空格。
……
5.5.2.2 程序代碼示例XXXX
程序日誌分為兩種:
5.5.3.2 日誌記錄
考慮如何記錄程序日誌,制定日誌規範!
分區表的分區增加、分區刪除操作,統一由分區控制程序完成,應用數據處理程序中不允許包含增加、刪除分區的操作;分區表清空分區的操作,應在應用數據處理程序中進行,這樣可以避免因為程序多次運行導致的數據重複。
保留多個周期數據的表必須建立分區,分區鍵可以根據業務需要和數據大小分為日、月、年,這樣即可以避免因為表越來越大導致程序運行速度越來越慢,又解決分區太多浪費空間。全量替換的數據表(如維表、臨時表)可以不建立分區。
日分區表禁止保留月底最後一天數據,如果要用到月底最後一天數據,需要單獨建立月表保存。
6 JAVA編碼規範6.1 避免引發錯誤的編寫規範
使用字符串的equals方法比較判斷時,如有常量字符串,一定要養成常量在前,變量在後的編寫習慣。
養成這種編碼習慣能夠有效減少當比較的變量是null時發生空指針的錯誤
在finally中執行關閉操作,能夠確保出現異常時資料庫連接、IO讀寫句柄被正常關閉。
……
6.2 編程注意事項說明明確方法功能,精確(不是近似)地實現方法的設計。一個方法僅完成一件功能,即時簡單功能也應該編寫方法實現。
異常捕獲後,如果不對改異常進行處理,則應該記錄日誌或使用。
如果是自己拋出的異常,則必須要填寫詳細的異常描述信息,這樣才能方便。
判斷時要注意運算符的優先級,並用括號明確表達式的操作順序,避免使用默認的優先級。
不要在循環體內定義變量。
……
6.3 程序排版及注釋規範6.3.1 程序排版程序塊要採用縮進風格編寫,縮進的空格數為4個。
……
6.3.2 程序注釋7 shell編碼規範7.1 shell編程案例制定程序案例,供大家參考
8 完整的規範文檔結構End
Real -Time Is The Future . 關注我們不迷路,我們下期見啦 ~
01. 文末掃碼後臺回復「經典」,即可領取大數據數倉經典書籍。
02. 文末掃碼後臺回復「中臺」,即可領取大廠中臺架構高清ppt。
03.文末掃碼後臺回復關鍵詞:畫像源碼、畫像ppt、用戶畫像,都可獲取寶貴幹貨資源與資料
04.更多福利:
Q: 關於數據倉庫,你還想了解什麼?
歡迎關注我們一起進步
覺得不錯,請把這篇文章分享給你的朋友哦
投稿請聯繫小助手:iom1128『紫霞仙子』
!關注不迷路~ 各種福利、資源定期分享!