數據倉庫建設規範(文檔版)

2021-02-13 數據倉庫與Python大數據

正文

導讀:今天有小夥伴在群問有沒有數據倉庫建設規範,參與過兩個數據倉庫的規劃,寫過一些規範文檔,今天分享給大家,大家可以借鑑,完成自己的規範!

以下為完整的內容,供大家參考。

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


2.2.5.1    日表日表以統計周期欄位做日分區。數據保留周期為業務需要的周期,月底最後一天的數據不保存,如有需要則沉澱到月表中。2.2.5.2    月表

月表以統計周期欄位做月分區。除該欄位外,其餘欄位與日表必須相同。數據保留周期為業務需要的周期。所有的月報表、月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   資料庫編程規範5.1  參數和變量命名規範5.1.1 對象變量

對象變量命名規則如下:

命名規則:<對象類型><_><變量描述>

.

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 程序日誌5.5.3.1    日誌分類

程序日誌分為兩種:

5.5.3.2    日誌記錄

考慮如何記錄程序日誌,制定日誌規範!

5.6  分區管理規範

分區表的分區增加、分區刪除操作,統一由分區控制程序完成,應用數據處理程序中不允許包含增加、刪除分區的操作;分區表清空分區的操作,應在應用數據處理程序中進行,這樣可以避免因為程序多次運行導致的數據重複。

保留多個周期數據的表必須建立分區,分區鍵可以根據業務需要和數據大小分為日、月、年,這樣即可以避免因為表越來越大導致程序運行速度越來越慢,又解決分區太多浪費空間。全量替換的數據表(如維表、臨時表)可以不建立分區。

日分區表禁止保留月底最後一天數據,如果要用到月底最後一天數據,需要單獨建立月表保存。

 

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.更多福利:

關鍵詞
領取資源
ck安裝clickhouse安裝pdf文檔0808
大廠實時數倉PPT合集畫像源碼用戶畫像項目源碼推薦系統推薦系統教程視頻OneData阿里OneData體系PPT

Q: 關於數據倉庫,你還想了解什麼?

歡迎關注我們一起進步

覺得不錯,請把這篇文章分享給你的朋友哦

投稿請聯繫小助手:iom1128『紫霞仙子』

關注不迷路~ 各種福利、資源定期分享

相關焦點

  • 如何設計一個規範的數據倉庫
    一.什麼是數據倉庫數據倉庫的特徵在於面向主題、集成性、穩定性和時變性,用於支持管理決策。數據倉庫的存在的意義在於對企業的所有數據進行匯總,為企業各個部門提供統一的、規範的數據出口。數據倉庫在構建過程中通常都需要進行分層處理。業務不同,分層的技術處理手段也不同。
  • 關於數據倉庫建設,了解這7點就夠了
    編輯導讀:在數據分析中,實時數據倉庫很重要,它決定了報表和BI到底能不能實時展現數據。但很多人可能都對它不夠了解,本文作者結合自己的工作實踐,從7個方面分享了數據倉庫建設的相關步驟和需要注意的問題,一起來看看~之前發了一篇數據倉庫的文章,發現大家對數據倉庫還是非常感興趣的。
  • 網站數據分析:數據倉庫相關的問題(三)
    其實歸納起來就兩類:一是用傳統RDBMS為主導的資料庫管理數據,oracle、mysql等都是基於傳統的關係型資料庫,優勢就是有更嚴謹的數據結構,關係型資料庫對數據的管理更加規範,數據處理過程中可能出現的非人為誤差極小,而且標準的SQL接口使數據獲取的成本較低,數據的查詢和獲取更加靈活和高效;但劣勢也很明顯,對海量數據的處理和存儲的能力不足,當數據量達到一定程度的時候就會出現明顯的瓶頸
  • 建設數據倉庫的八個步驟
    建設數據倉庫    建立數據倉庫是一個解決企業問題的過程,業務人員往往不懂如何建立和使用數據倉庫因此數據倉庫的項目小組應該由業務人員和信息部門的人員共同組成,雙方需要相互溝通,協作開發數據倉庫。    開發數據倉庫的過程包括以下幾個步驟。
  • 傳統行業如何建立數據倉庫?
    在理解建立商業智能系統目標的基礎上,建立有效的企業管理模式,制定出詳細的企業數據倉庫業務管理規範,設計出常用的ETL數據採集規範和工作流程,從而明確商業智能系統的實施範圍和目標。對於數據建模工程師來說,對業務的深刻理解是首要任務,因為數據倉庫建模分為概念模型設計、邏輯模型設計和物理模型設計3個階段,一般按照自頂向下的順序依次對模型進行設計。概念模型主要是模型設計人員對業務規則的理解,是最高層次的數據模型,幾乎涵蓋了業務所有的核心概念和重要的主題,為以後邏輯模型的建設打下了基礎。
  • 數據倉庫模型設計與工具
    一、基本概念維度建模,是數據倉庫大師Ralph Kimball提出的,是數據倉庫工程領域最流行的數倉建模經典。二、建模方法 —— 經典數據倉庫模型數據倉庫建模方法論可分為:維度建模、範式建模、Data Vault模型、Anchor模型。
  • 建築設計防火規範2018版_2020年建築設計防火規範2018版資料下載...
    目錄前 言 1總 則 2術語、符號 2.1 術語2.2 符號 3廠房和倉庫 3.1 火災危險性分類3.2 廠房和倉庫的耐火等級3.3 廠房和倉庫的層數、面積和平面布置3.4 廠房的防火間距3.5 倉庫的防火間距3.6 廠房和倉庫的防爆3.7 廠房的安全疏散3.8 倉庫的安全疏散 4甲、乙、丙類液體、氣體儲罐(區)和可燃材料堆場 4.1 一般規定4.2 甲、乙、丙類液體儲罐(區)的防火間距4.3 可燃
  • 大數據篇:一文讀懂@數據倉庫
    數據中臺把數據統一之後,會形成標準數據,再進行存儲,形成大數據資產層,進而為客戶提供高效服務。數據中臺,包括平臺、工具、數據、組織、流程、規範等一切與企業數據資產如何用起來所相關的。隨時間變化即反映歷史變化操作型資料庫主要關心當前某一個時間段內的數據,而數據倉庫中的數據通常包含歷史信息,系統記錄了企業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息,通過這些信息,可以對企業的發展歷程和未來趨勢做出定量分析和預測。企業數據倉庫的建設,是以現有企業業務系統和大量業務數據的積累為基礎。
  • 數據倉庫的定義及特點
    數據倉庫的定義及特點 數據倉庫的定義及特點 2012-09-29 10:13:00  來源:CIO時代網    對於數據倉庫的概念我們可以從兩個層次予以理解,首先,數據倉庫用於支持決策,面向分析型數據處理,它不同於企業現有的操作型資料庫;其次,數據倉庫是對多個異構的數據源有效集成,集成後按照主題進行了重組,並包含歷史數據,而且存放在數據倉庫中的數據一般不再修改
  • 倉庫管理基礎知識:倉庫單據的作用、種類、格式規範、整理與保存
    大家好,我是許栩,歡迎來到我的專欄《倉儲基礎知識:倉庫管理的必備技能》。本篇是專欄的第六篇文章,倉庫管理基礎知識:倉庫單據的作用、種類、格式規範、整理與保存。(本專欄總目錄請見上圖。)什麼是倉庫單據?倉庫單據是指對物料的名稱、規格型號、單位和數量的現狀或變動情況所做的記錄。在本專欄第三篇《倉庫管理的5個基本原則》中,我提到了倉庫天規?我將「憑單出入庫」原則作為倉庫管理的第一原則,並將之稱為倉庫天規。憑單出入庫,所憑的「單」,指的就是倉庫的單據。
  • 理解數據管理文檔對數據真實可靠性的重要性,如何進行良好的臨床數據文檔管理
    同時闡述了如何進行良好的臨床數據文檔管理,只有在切實地理解臨床數據管理的全過程的基礎上,進行嚴格而有效的文檔管理和定期的質量控制才是高質量數據管理文檔的保證。[ 關鍵詞 ] 臨床試驗主文檔;數據管理;文檔管理;數據真實可靠性臨床試驗質量管理規範(GCP)規定所有的臨床試驗的信息應該被記錄、處理和保存,並能被準確地核查、報告和解釋。
  • Hive數據倉庫實戰
    Hive作為大數據平臺Hadoop之上的主流應用,公司一般都是用它作為公司的數據倉庫,分布式機器學習的訓練數據和數據處理也經常用它來處理,下面介紹下它的常用功能。Hive原理和功能介紹Hive是建立在 Hadoop 上的數據倉庫基礎構架。
  • 博泰文檔:中國檔案外包服務的先行者
    2014年4月,北京工商批准的首家以「文檔數據外包」註冊的企業拿到了新的營業執照,從此前的「北京東方博泰檔案文件管理諮詢有限公司」正式更名為「北京東方博泰文檔數據外包服務有限公司」這意味著「文檔數據外包」作為一個行業被正式認可。
  • 內附PPT|性能遠超MySQL 阿里云云原生數據倉庫AnalyticDB基礎版
    spm=a2c6h.12873639.0.0.45e3bd6essBOnC&file=18b2313f8df2002993baedfabc2fe026.pdf日前,阿里雲正式發布雲原生數據倉庫AnalyticDB基礎版,極大降低了用戶構建數據倉庫的門檻,每月可低至860元。
  • 數據倉庫與數據集市 - 大數據_CIO時代網 - CIO時代—新技術、新...
    數據倉庫應該一次增加一個主題,並且當需要容易地訪問多個主題時,應該創建以數據倉庫為來源的數據集市。    Ralph Kimball說「數據倉庫僅僅是構成它的數據集市的聯合」。他認為「可以通過一系列維數相同的數據集市遞增地構建數據倉庫」,通過使用「一致的」維,能夠共同看到不同數據集市中的信息,這表示它們擁有公共定義的元素。
  • 馬蜂窩數據中臺起步建設:數倉的架構、模型與應用
    作為中臺的另一大核心部分,馬蜂窩數據倉庫主要承擔數據統一化建設的工作,包括統一數據模型,統一指標體系等。下面介紹馬蜂窩在數據倉庫建設方面的具體實踐。3、設計流程馬蜂窩數倉模型設計的整體流程涉及需求調研、模型設計、開發測試、模型上線四個主要環節,且規範設計了每個階段的輸出與輸入文檔。
  • 構建實時數據倉庫,雲原生數據倉庫AnalyticDB for MySQL技術解密
    阿里雲分析型資料庫重磅推出基礎版,極大降低了用戶構建數據倉庫門檻。高度兼容MySQL,極低的使用成本和極高的性能,使中小企業也可以輕鬆的搭建一套實時數據倉庫,實現企業數據價值在線化。AnalyticDB for MySQL的產品系列包括基礎版(單機版)和集群版,基礎版為單個節點提供服務,極簡的架構大大的降低了基礎版的成本。存儲計算分離架構、行列混存技術、輕量的索引構建方式和分布式混合計算引擎又保證了基礎版強大的分析性能。年成本不到一萬就可以構建一套實時數據倉庫,無需成立專門的大數據團隊,為企業節省百萬成本。
  • 劉靜芳:建設銀行數據治理實踐和政務數據標準化探索
    2003年建設企業級數據倉庫,開始把「對數據內容的管控、對數據隱藏含義的解讀」從IT系統的部署過程中分離出來,成為獨立環節;2011年建設新一代核心系統,開始認識並確認數據可復用、可單獨管理、是一種新的生產要素。也就是說,建設銀行對數據治理問題的理解和認識也是一個不斷深化的過程。
  • 博泰文檔:揭開中國企業檔案外包時代序幕
    「博泰文檔希望利用最好的硬體條件、嚴密的業務流程以及專業化的管理來很好地填補當前國內市場的需求。」張屹表示。「紙質文檔」保存不簡單紙質商業文檔數據往往是企業或者機構中最為核心的商業業務數據,很多企業認為自己保存才是最安全的,但是隨著文檔量增加,商業文檔的儲存空間、管理架構搭建等將耗費企業大量的財力與人力,文檔數據外包的需求逐步顯現。
  • 基於 Markdown 的中文文檔排版規範
    0 前言 相信閱讀本文的讀者一定有被 Markdown 靈活的寫作風格搞懵過,不知道怎麼寫更優雅、更規範,那麼本文就是來幫您梳理 Markdown 寫作過程中常見的一些問題,然後給出一個建議的應用規範。通過閱讀本文,相信你一定可以基於 Markdown 寫出更加優雅的中文文檔。