『壹』 如何使用數據字典
為了對數據流程圖中的各個元素作出詳細的說明，有必要建立數據字典 (Data dictionary) 。數據字典的內容主要是對數據流程圖中的數據項、數據結構、數據流、處理邏輯、數據存儲和外部實體等六個方面進行具體的定義。數據流程圖配以數據字典，就可以從圖形和文字兩個方面對系統的邏輯模型進行完整的描述。
一、數據項的定義
數據項又稱數據元素，是數據的最小單位。分析數據特性應從靜態和動態兩個方面去進行。在數據字典中，僅定義數據的靜態特性，具體包括： (1) 數據項的名稱、編號、別名和簡述； (2) 數據項的長度； (3) 數據項的取值范圍；
例：數據項定義
數據項編號： I02 －01
數據項名稱：材料編號
別名：材料編碼
簡述：某種材料的代碼
類型及寬度：字元型， 4 位
取值范圍：「0001 」－「 9999 」
二、數據結構的定義
數據結構描述某些數據項之間的關系。一個數據結構可以由若干個數據項組成；也可以由若干個數據結構組成，還可以由若干個數據項和數據結構組成。例如表 5.l 所示訂貨單就是由三個數據結構組成的數據結構，表中用 DS 表示數據結構，用 I 表示數據項。
數據字典中對數據結構的定義包括以下內容： (1) 數據結構的名稱和編號； (2) 簡述；(3) 數據結構的組成。如果是一個簡單的數據結構，只要列出它所包含的數據項。如果是一個嵌套的數據結構 ( 即數據結構中包含數據結構 ) ，則需列出它所包含的數據結構、的名稱，因為這些被包含的數據結構在數據字典的其他部分已有定義。
例：數據結構定義
數據結構編號： DS03 － 08
數據結構名稱：用戶訂貨單
簡述：用戶所填用戶情況及訂貨要求等信息
數據結構組成： DS03 － 02 + DS03 － 03 + DS03 －04
三、數據流的定義
數據流由一個或一組固定的數據項組成。定義數據流時，不僅要說明數據流的名稱、組成等，還應指明它的來源、去向和數據流量等。
例：數據流定義
數據流編號： FD3 － 08
數據流名稱：領料單
簡述：車間開出的領料單
數據流來源：車間
數據流去向：發料處理模塊
數據流組成：材料編號 + 材料名稱 + 領用數量+ 日期 + 領用單位
數據流量： 10 份／時
高峰流量： 20 份／時 ( 上午9 ： 00 －11 ： 00)
四、處理邏輯的定義
處理邏輯的定義僅對數據流程圖中最底層的處理邏輯加以說明。編寫數據字典是系統開發的一項重要的基礎工作。一旦建立，並按編號排序之後，就是一本可供查閱的關於數據的字典，從系統分析一直到系統設計和實施都要使用它。在數據字典的建立、修正和補充過程中，始終要注意保證數據的一致性和完整性。
數據字典可以用人工建立卡片的辦法來管理，也可存儲在計算機中用一個數據字典軟體來管理。
『貳』 全面教你如何建立數據分析的思維框架
全面教你如何建立數據分析的思維框架
目前，還有一些人不會建立數據分析的思維框架，那麼今天課課家，就一步一步的教大家怎麼建立，大神路過還請繞道，當然還可以交流一下。有需要的小夥伴，可以參考一下。
曾經有人問過我，什麼是數據分析思維?如果分析思維是一種結構化的體現，那麼數據分析思維在它的基礎上再加一個准則：
不是我覺得，而是數據證明。
這是一道分水嶺，「我覺得」是一種直覺化經驗化的思維，工作不可能處處依賴自己的直覺，公司發展更不可能依賴於此。數據證明則是數據分析的最直接體現，它依託於數據導向型的思維，而不是技巧，前者是指導，後者只是應用。
作為個人，應該如何建立數據分析思維呢?
一、建立你的指標體系
在我們談論指標之前，先將時間倒推幾十年，現代管理學之父彼得·德魯克說過一句很經典的話：
如果你不能衡量它，那麼你就不能有效增長它。
所謂衡量，就是需要統一標准來定義和評價業務。這個標准就是指標。假設隔壁老王開了一家水果鋪子，你問他每天生意怎麼樣，他可以回答賣的不錯，很好，最近不景氣。這些都是很虛的詞，因為他認為賣的不錯也許是賣了50個，而你認為的賣的不錯，是賣了100。
這就是「我覺得」造成的認知陷阱。將案例放到公司時，會遇到更多的問題：若有一位運營和你說，產品表現不錯，因為每天都有很多人評價和稱贊，還給你看了幾個截圖。而另外一位運營說，產品有些問題，推的活動商品賣的不好，你應該相信誰呢?
其實誰都很難相信，這些眾口異詞的判斷都是因為缺乏數據分析思維造成的。
老王想要描述生意，他應該使用銷量，這就是他的指標，互聯網想要描述產品，也應該使用活躍率、使用率、轉化率等指標。
如果你不能用指標描述業務，那麼你就不能有效增長它。
了解和使用指標是數據分析思維的第一步，接下來你需要建立指標體系，孤立的指標發揮不出數據的價值。和分析思維一樣，指標也能結構化，也應該用結構化。
我們看一下互聯網的產品，一個用戶從開始使用到離開，都會經歷這些環節步驟。電商app還是內容平台，都是雷同的。想一想，你會需要用到哪些指標?
而下面這張圖，解釋了什麼是指標化，這就是有無數據分析思維的差異，也是典型的數據化運營，有空可以再深入講這塊。
標體系沒有放之四海而皆準的模板，不同業務形態有不同的指標體系。移動APP和網站不一樣，SaaS和電子商務不一樣，低頻消費和高頻消費不一樣。好比一款婚慶相關的APP，不需要考慮復購率指標;互聯網金融，必須要風控指標;電子商務，賣家和買家的指標各不一樣。
這些需要不同行業經驗和業務知識去學習掌握，那有沒有通用的技巧和注意事項呢?
二、明確好指標與壞指標
不是所有的指標都是好的。這是初出茅廬者常犯的錯誤。我們繼續回到老王的水果鋪子，來思考一下，銷量這個指標究竟是不是好的?
最近物價上漲，老王順應調高了水果價格，又不敢漲的提高，雖然水果銷量沒有大變化，但老王發現一個月下來沒賺多少，私房錢都不夠存。
老王這個月的各類水果銷量有2000，但最後還是虧本了，仔細研究後發現，雖然銷量高，但是水果庫存也高，每個月都有幾百單位的水果滯銷最後過期虧本。
這兩個例子都能說明只看銷量是一件多不靠譜的事情。銷量是一個衡量指標，但不是好指標。老王這種個體經營戶，應該以水果鋪子的利潤為核心要素。
好指標應該是核心驅動指標。雖然指標很重要，但是有些指標需要更重要。就像銷量和利潤，用戶數和活躍用戶數，後者都比前者重要。
核心指標不只是寫在周報的數字，而是整個運營團隊、產品團隊乃至研發團隊都統一努力的目標。
核心驅動指標和公司發展關聯，是公司在一個階段內的重點方向。記住是一個階段，不同時期的核心驅動指標不一樣。不同業務的核心驅動指標也不一樣。
互聯網公司常見的核心指標是用戶數和活躍率，用戶數代表市場的體量和佔有，活躍率代表產品的健康度，但這是發展階段的核心指標。在產品1.0期間，我們應把注意力放到打磨產品上，在大推廣前提高產品質量，這時留存率是一個核心指標。而在有一定用戶基數的產品後期，商業化比活躍重要，我們會關注錢相關的指標，比如廣告點擊率、利潤率等。
核心驅動指標一般是公司整體的目標，若從個人的崗位職責看，也可以找到自己的核心指標。比如內容運營可以關注閱讀數和閱讀時長。
核心驅動指標一定能給公司和個人帶來最大優勢和利益，記得二八法則么?20%的指標一定能帶來80%的效果，這20%的指標就是核心。
另外一方面，好的指標還有一個特性，它應該是比率或者比例。
拿活躍用戶數說明就懂了，我們活躍用戶有10萬，這能說明什麼呢?這說明不了什麼。如果產品本身有千萬級別的注冊用戶，那麼10萬用戶說明非常不健康，產品在衰退期。如果產品只擁有四五十萬用戶，那麼說明產品的粘性很高。
正因為單純的活躍用戶數沒有多大意義，所以運營和產品會更關注活躍率。這個指標就是一個比率，將活躍用戶數除以總用戶數所得。所以在設立指標時，我們都盡量想它能不能是比率。
認識和看待事物
這類常見的提問方式包括了一個知名人物或歷史事件如何評價？如何看待一個產品？你對某個事物是如何理解的？如何看待或分析一種行為或熱點等？
對於看待或分析事物類的思維，則是我們前面一篇思維的邏輯裡面講到的很多內容，即事物本身應該結合外部環境+時間線+事物核心維度進行全面的分析，事物的外在交互關系，事物的內部結構和銜接，事物本身動態展現的行為特徵等。這些首先分析清楚，即對事物本身有一個全面和客觀的認識。
這類思維的一個核心即辯證思維，在這里我不太喜歡用批評性思維這個詞，辯證思i維更加體現了這類思維的重點是全面，客觀，以數據說話同時減少主觀偏頗看法。對於這類問題你不一定要去表面自己的主觀感受，而更加重要的是把事實和道理講清楚，有理有據。
在真正分析清楚後，後續才過渡到這類問題的演進，即如何評估或評價一個事物，其前提仍然是分析清楚客觀數據，但是數據本身不是評價或評估指標，因此一談到評估自然會想到需要建立或參考一個評估體系。一個歷史帝王有政治，經濟，外交，軍事和民生各種評價體系。對一輛車可能有動力，舒適性，油耗，操控等各種評價體系。一個產品本身有功能滿足度，易用性，性能，價格等各種評價體系等。對於任何評估，則首先是找到現成可用的科學評價體系，然後將對事物分析後的數據映射到具體的評價體繫上，即任何評估指標值的得出一定有事物本身內在數據和運作機制進行支撐的。
這些都想清楚後，即這類思維的重點是事物的分解和集成分析，事物的行為或活動分析，事物相關的內外環境因素分析，事物本身的關鍵屬性維度分析和評估體系確定，事物各關鍵指標特性間的相互制約和促進力分析（類似系統思維中的正負循環）等。
壞指標有哪些呢?
其一是虛榮指標，它沒有任何的實際意義。
產品在應用商店有幾十萬的曝光量，有意義嗎?沒有，我需要的是實際下載。下載了意義大嗎?也不大，我希望用戶注冊成功。曝光量和下載量都是虛榮指標，只是虛榮程度不一樣。
新媒體都追求微信公眾號閱讀數，如果靠閱讀數做廣告，那麼閱讀數有意義，如果靠圖文賣商品，那麼更應該關注轉化率和商品銷量，畢竟一個誇張的標題就能帶來很高的閱讀量，此時的閱讀量是虛榮指標。可惜很多老闆還是孜孜不倦的追求10W+，哪怕刷量。
虛榮指標是沒有意義的指標，往往它會很好看，能夠粉飾運營和產品的工作績效，但我們要避免使用。
第二個壞指標是後驗性指標，它往往只能反應已經發生的事情。
比如我有一個流失用戶的定義：三個月沒有打開APP就算做流失。那麼運營每天統計的流失用戶數，都是很久沒有打開過的，以時效性看，已經發生很久了，也很難通過措施挽回。我知道曾經因為某個不好的運營手段傷害了用戶，可是還有用嗎?
活動運營的ROI(投資回報率)也是後驗性指標，一個活動付出成本後才能知道其收益。可是成本已經支出，活動的好與壞也註定了。活動周期長，還能有調整餘地。活動短期的話，這指標只能用作復盤，但不能驅動業務。
第三個壞指標是復雜性指標，它將數據分析陷於一堆指標造成的陷阱中。
指標能細分和拆解，比如活躍率可以細分成日活躍率、周活躍率、月活躍率、老用戶活躍率等。數據分析應該根據具體的情況選擇指標，如果是天氣類工具，可以選擇日活躍率，如果是社交APP，可以選擇周活躍率，更低頻的產品則是月活躍率。
每個產品都有適合它的幾個指標，不要一股腦的裝一堆指標上去，當你准備了二三十個指標用於分析，會發現無從下手。
三、建立正確的指標結構
既然指標太多太復雜不好，那麼應該如何正確的選擇指標呢?
和分析思維的金字塔結構一樣，指標也有固有結構，呈現樹狀。指標結構的構建核心是以業務流程為思路，以結構為導向。
假設你是內容運營，需要對現有的業務做一個分析，提高內容相關數據，你會怎麼做呢?
我們把金字塔思維轉換一下，就成了數據分析方法了。
從內容運營的流程開始，它是：內容收集—內容編輯發布—用戶瀏覽—用戶點擊—用戶閱讀—用戶評論或轉發—繼續下一篇瀏覽。
這是一個標準的流程，每個流程都有指標可以建立。內容收集可以建立熱點指數，看哪一篇內容比較火。用戶瀏覽用戶點擊則是標準的PV和UV統計，用戶閱讀是閱讀時長。
從流程的角度搭建指標框架，可以全面的囊括用戶相關數據，無有遺漏。
這套框架列舉的指標，依舊要遵循指標原則：需要有核心驅動指標。移除虛榮指標，適當的進行刪減，不要為添加指標而添加指標。
四、了解維度分析法
當你有了指標，可以著手進行分析，數據分析大體可以分三類：
利用維度分析數據
使用統計學知識如數據分布假設檢驗
使用機器學習
我們先了解一下維度分析法。
維度是描述對象的參數，在具體分析中，我們可以把它認為是分析事物的角度。銷量是一種角度、活躍率是一種角度，時間也是一種角度，所以它們都能算維度。
當我們有了維度後，就能夠通過不同的維度組合，形成數據模型。數據模型不是一個高深的概念，它就是一個數據立方體。
上圖就是三個維度組成的數據模型/數據立方體。分別是產品類型、時間、地區。我們既能獲得電子產品在上海地區的2010二季度的銷量，也能知道書籍在江蘇地區的2010一季度銷量。
數據模型將復雜的數據以結構化的形式有序的組織起來。我們之前談到的指標，都可以作為維度使用。下面是範例：
將用戶類型、活躍度、時間三個維度組合，觀察不同用戶群體在產品上的使用情況，是否A群體使用的時長更明顯?
將商品類型、訂單金額、地區三個維度組合，觀察不同地區的不同商品是否存在銷量差異?
數據模型可以從不同的角度和層面來觀察數據，這樣提高了分析的靈活性，滿足不同的分析需求、這個過程叫做OLAP(聯機分析處理)。當然它涉及到更復雜的數據建模和數據倉庫等，我們不用詳細知道。
數據模型還有幾種常見的技巧、叫做鑽取、上卷、切片。
選取就是將維度繼續細分。比如浙江省細分成杭州市、溫州市、寧波市等，2010年一季度變成1月、2月、3月。上卷則是鑽取的相反概念，將維度聚合，比如浙江、上海、江蘇聚合成浙江滬維度。切片是選中特定的維度，比如只選上海維度、或者只選2010年一季度維度。因為數據立方體是多維的，但我們觀察和比較數據只能在二維、即表格中進行。
上圖的樹狀結構代表鑽取(source和time的細分)，然後通過對Route的air切片獲得具體數據。
聰明的你可能已經想到，我們常用的數據透視表就是一種維度分析，將需要分析的維度放到行列組合進行求和、計數、平均值等計算。放一張曾經用到的案例圖片：用城市維度和工作年限維度，計算平均工資。
除了Excel、BI、R、Python都能用維度分析法。BI是相對最簡便的。
談到維度法，想要強調的是分析的核心思維之一：對比，不同維度的對比，這大概是對新人快速提高的最佳捷徑之一。比如過去和現在的時間趨勢對比，比如不同地區維度的對比，比如產品類型的區別對比，比如不同用戶的群體對比。單一的數據沒有分析意義，只有多個數據組合才能發揮出數據的最大價值。
我想要分析公司的利潤，利潤 = 銷售額 – 成本。那麼找出銷售額涉及的指標/維度，比如產品類型、地區、用戶群體等，通過不斷的組合和拆解，找出有問題或者表現良好的原因。成本也是同理。
這就是正確的數據分析思維。總結一下吧：我們通過業務建立和篩選出指標，將指標作為維度，利用維度進行分析。
很多人會問，指標和維度有什麼區別?
維度是說明和觀察事物的角度，指標是衡量數據的標准。維度是一個更大的范圍，不只是數據，比如時間維度和城市維度，我們就無法用指標表示，而指標(留存率、跳出率、瀏覽時間等)卻可以成為維度。通俗理解：維度>指標。
到這里，大家已經有一個數據分析的思維框架了。之所以是框架，因為還缺少具體的技巧，比如如何驗證某一個維度是影響數據的關鍵，比如如何用機器學習提高業務，這些涉及到數據和統計學知識，以後再講解。
這里我想強調，數據分析並不是一個結果，只是過程。還記得「如果你不能衡量它，那麼你就不能有效增長它」這句話嗎?數據分析的最終目的就是增長業務。如果數據分析需要績效指標，一定不會是分析的對錯，而是最終數據提升的結果。
數據分析是需要反饋的，當我分析出某項要素左右業務結果，那麼就去驗證它。告訴運營和產品人員，看看改進後的數據怎麼樣，一切以結果為准。如果結果並沒有改善，那麼就應該反思分析過程了。
這也是數據分析的要素，結果作導向。分析若只是當一份報告呈現上去，後續沒有任何跟進、改進的措施，那麼數據分析等與零。
業務指導數據，數據驅動業務。這才是不二法門。
『叄』 資料庫數據字典怎麼寫
數據字典是什麼
進行資料庫設計的時候，對資料庫元素進行的解釋說明就是數據字典。舉個例子吧，假設有下面這個設計出來的資料庫表：
player(fname, lname, account, pwd, email)
對應的數據字典就是：
player：玩家信息表
fname：玩家名
lname：玩家姓
account：賬戶名
pwd：密碼
email：聯系電郵
這里只是一個針對某一表的數據字典，還有針對表與表之間關系的數據字典、表內欄位屬性的數據字典等等。越是大型的資料庫設計，越是需要數據字典來輔助進行設計說明，幫助設計人員之間的溝通野豎與交流。
SQL資料庫數據字典怎麼生成的？
數據字典是關於數據的信息的 *** ，也就是對數據流圖中包含的所有元素的定義的 *** 。
資料庫數據字典是一組表和視圖結構。它們存放在SYSTEM表空間中。
資料庫數據字典不僅是每個資料庫的中心。而且對每個用戶也是非常重要的信息。用戶可以用SQL語句訪問資料庫數據字典。
生成資料庫參考代碼如下：
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:
-- Create date: <2014-09-19>
-- Description:
-- =============================================
CREATE PROCEDURE [dbo].[CreateDatabaseDictionarie]
AS
BEGIN
DECLARE @TableName nvarchar(35),@htmls varchar(8000)
DECLARE @欄位名稱 VARCHAR(200)
DECLARE @類型 VARCHAR(200)
DECLARE @長度 VARCHAR(200)
DECLARE @數值精度 VARCHAR(200)
DECLARE @小數位數 VARCHAR(200)
DECLARE @默認值 VARCHAR(200)
DECLARE @允許為空 VARCHAR(200)
DECLARE @外鍵 VARCHAR(200)
DECLARE @主鍵 VARCHAR(200)
DECLARE @描述 VARCHAR(200)
SET NOCOUNT ON;
DECLARE Tbls CURSOR
FOR
Select distinct Table_name
FROM INFORMATION_SCHEMA.COLUMNS
order by Table_name
OPEN Tbls
PRINT ''
PRINT ''
PRINT ' '
PRINT ' ......
數據字典的組成
數據字典的組成：1、數據項2、數據結構3、數據流4、數據存儲5、處理過程數據字典數據字典是資料庫的重要組成部分。它存放有資料庫所用的有棚脊畢關信息，對用戶來說是一組只讀的表。數據字典內容包括：1、資料庫中所有模式對象的信息，如表、視圖、簇、及索引等。2、分配多少空間，當前使用了多少空間等。3、列的預設值。4、約束信息的完整性。5、用戶的名字。6、用戶及角色被授予的許可權。7、用戶訪問或使用的審計信息。8、其它產生的資料庫信息。資料庫數據字典是一組表和視圖結構。它們存放在SYSTEM表空間中。資料庫數據字典不僅是每個資料庫的中心。而且對每個用戶也是非常重要的信息。用戶可以用SQL語句訪問資料庫數據字典。關於數據的信息 *** ,是一種用戶可以訪問的記錄資料庫和應用程序元數據的目錄,是對資料庫內表信息的物理與邏輯的說明
數據字典與資料庫設計之間有什麼關系？
正文
1 引言
1．1編寫目的
說明編寫這份資料庫設計說明鏈芹書的目的，指出預期的讀者。
1．2背景
說明：
a．說明待開發的資料庫的名稱和使用此資料庫的軟體系統的名稱；
b．列出該軟體系統開發項目的任務提出者、用戶以及將安裝該軟體和這個資料庫的計算站（中心）。
1．3定義
列出本文件中用到的專門術語的定義、外文首字母組詞的原片語。
1．4參考資料
列出有關的參考資料：
a．本項目的經核準的計劃任務書或合同、上級機關批文；
b．屬於本項目的其他已發表的文件；
c．本文件中各處引用到的文件資料，包括所要用到的軟體開發標准。
列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。
2 外部設計
2．1標識符和狀態
聯系用途，詳細說明用於唯一地標識該資料庫的代碼、名稱或標識符，附加的描述性信息亦要給出。如果該資料庫屬於尚在實驗中、尚在測試中或是暫時使用的，則要說明這一特點及其有效時間范圍。
2．2使用它的程序
列出將要使用或訪問此資料庫的所有應用程序，對於這些應用程序的每一個，給出它的名稱和版本號。
2．3約定
陳述一個程序員或一個系統分析員為了能使用此資料庫而需要了解的建立標號、標識的約定，例如 用於標識資料庫的不同版本的約定和用於標識庫內各個文卷、、記錄、數據項的命名約定等。
2．4專門指導
向准備從事此資料庫的生成、從事此資料庫的測試、維護人員提供專門的指導，例如將被送入數據 庫的數據的格式和標准、送入資料庫的操作規程和步驟，用於產生、修改、更新或使用這些數據文卷的操 作指導。 如果這些指導的內容篇幅很長，列出可參閱的文件資料的名稱和章條。
2．5支持軟體
簡單介紹同此資料庫直接有關的支持軟體，如資料庫管理系統、存儲定位程序和用於裝入、生成、修 改、更新資料庫的程序等。說明這些軟體的名稱、版本號和主要功能特性，如所用數據模型的類型、允許 的數據容量等。列出這些支持軟體的技術文件的標題、編號及來源。
3 結構設計
3．1概念結構設計
說明本資料庫將反映的現實世界中的實體、屬性和它們之間的關系等的原始數據形式，包括各數據項、記錄、系、文卷的標識符、定義、類型、度量單位和值域，建立本資料庫的每一幅用戶視圖。
3．2邏輯結構設計
說明把上述原始數據進行分解、合並後重新組織起來的資料庫全局邏輯結構，包括所確定的關鍵字和屬性、重新確定的記錄結構和文卷結構、所建立的各個文卷之間的相互關系，形成本資料庫的資料庫管理員視圖。
3．3物理結構設計
建立系統程序員視圖，包括：
a．數據在內存中的安排，包括對索引區、緩沖區的設計；
b．所使用的外存設備及外存空間的組織，包括索引區、數據塊的組織與劃分；
c．訪問數據的方式方法。
4 運用設計
4．1數據字典設計
對資料庫設計中涉及到的各種項目，如數據項、記錄、系、文卷、模式、子模式等一般要建立起數據字典，以說明它們的標識符、同義名及有關信息。在本節中要說明對此數據字典設計的基本考慮。
4．2安全保密設計
說明在資料庫的設計中，將如何通過區分不同的訪問者、不同的訪問類型和不同的數據對象，進行分別對待而獲得的資料庫安全保密的設計考慮。...
mysql資料庫數據字典表怎麼寫
你導出 rmation_schema 資料庫里的所有表就OK了 新特性啊,以前只有ORACLE才有的
數據字典包括哪些內容
你好！
我用的是考研參考書，上面的答案是：
數據字典是資料庫中描述信息和控制信息的 *** ，他是資料庫設計和管理的有力工具。數據字典包含（1.數據項，2數據流，3.數據結構.4.數據存儲.5.處理過程）五個部分。同時也是詳細數據收集和數據分析的結果。
SQL怎麼創建數據字典表，最好舉個例子！
我的理解數據字典表就是普通的表，例如性別的數據字典表
而這個字典表即可以包含， xmdm（代碼），xmmc（名稱），xm *** （說明） 三列，可根據使用情況增加或減少列，裡面的數據，即包含了 男，女，未知，三個選擇 這男，女等就是字典
是可以列舉完全的。
資料庫中的字典是什麼意思?
數據字典即為資料庫說明。包含完整的表結構介紹。
數據字典是特殊的資料庫資料庫類型是按什麼
資料庫設計方法、規范與技巧
一、資料庫設計過程
資料庫技術是信息資源管理最有效的手段。資料庫設計是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。
資料庫設計中需求分析階段綜合各個用戶的應用需求（現實世界的需求），在概念設計階段形成獨立於機器特點、獨立於各個DBMS產品的概念模式（信息世界模型），用E-R圖來描述。在邏輯設計階段將E-R圖轉換成具體的資料庫產品支持的數據模型如關系模型，形成資料庫邏輯模式。然後根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖（VIEW）形成數據的外模式。在物理設計階段根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成資料庫內模式。
1. 需求分析階段
需求收集和分析，結果得到數據字典描述的數據需求（和數據流圖描述的處理需求）。
需求分析的重點是調查、收集與分析用戶在數據管理中的信息要求、處理要求、安全性與完整性要求。
需求分析的方法：調查組織機構情況、調查各部門的業務活動情況、協助用戶明確對新系統的各種要求、確定新系統的邊界。
常用的調查方法有： 跟班作業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄。
分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。自頂向下的結構化分析方法（Structured Analysis，簡稱SA方法）從最上層的系統組織機構入手，採用逐層分解的方式分析系統，並把每一層用數據流圖和數據字典描述。
數據流圖表達了數據和處理過程的關系。系統中的數據則藉助數據字典（Data Dictionary，簡稱DD）來描述。
數據字典是各類數據描述的 *** ，它是關於資料庫中數據的描述，即元數據，而不是數據本身。數據字典通常包括數據項、數據結構、數據流、數據存儲和處理過程五個部分(至少應該包含每個欄位的數據類型和在每個表內的主外鍵)。
數據項描述＝｛數據項名，數據項含義說明，別名，數據類型，長度，
取值范圍，取值含義，與其他數據項的邏輯關系｝
數據結構描述＝｛數據結構名，含義說明，組成:｛數據項或數據結構｝｝
數據流描述＝｛數據流名，說明，數據流來源，數據流去向，
組成:｛數據結構｝，平均流量，高峰期流量｝
數據存儲描述＝｛數據存儲名，說明，編號，流入的數據流，流出的數據流，
組成:｛數據結構｝，數據量，存取方式｝
處理過程描述＝｛處理過程名，說明，輸入:｛數據流｝，輸出:｛數據流｝,
處理:｛簡要說明｝｝
2. 概念結構設計階段
通過對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體DBMS的概念模型，可以用E-R圖表示。
概念模型用於信息世界的建模。概念模型不依賴於某一個DBMS支持的數據模型。概念模型可以轉換為計算機上某一DBMS支持的特定數據模型。
概念模型特點：
(1) 具有較強的語義表達能力，能夠方便、直接地表達應用中的各種語義知識。
(2) 應該簡單、清晰、易於用戶理解，是用戶與資料庫設計人員之間進行交流的語言。
概念模型設計的一種常用方法為IDEF1X方法，它就是把實體-聯系方法應用到語義數據模型中的一種語義模型化技術，用於建立系統信息模型。
使用IDEF1X方法創建E-R模型的步驟如下所示:
2.1 第零步——初始化工程
這個階段的任務是從目的描述和范圍描述開始，確定建模目標，開發建模計劃，組織建模......
『肆』 怎麼生成數據字典
數據字典是關於數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。
資料庫數據字典是一組表和視圖結構。它們存放在SYSTEM表空間中。
資料庫數據字典不僅是每個資料庫的中心。而且對每個用戶也是非常重要的信息。用戶可以用SQL語句訪問資料庫數據字典。
生成資料庫參考代碼如下：
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: <Carbe>
-- Create date: <2014-09-19>
-- Description: <生成資料庫字典>
-- =============================================
CREATE PROCEDURE [dbo].[CreateDatabaseDictionarie]
AS
BEGIN
DECLARE @TableName nvarchar(35),@htmls varchar(8000)
DECLARE @欄位名稱 VARCHAR(200)
DECLARE @類型 VARCHAR(200)
DECLARE @長度 VARCHAR(200)
DECLARE @數值精度 VARCHAR(200)
DECLARE @小數位數 VARCHAR(200)
DECLARE @默認值 VARCHAR(200)
DECLARE @允許為空 VARCHAR(200)
DECLARE @外鍵 VARCHAR(200)
DECLARE @主鍵 VARCHAR(200)
DECLARE @描述 VARCHAR(200)
SET NOCOUNT ON;
DECLARE Tbls CURSOR
FOR
Select distinct Table_name
FROM INFORMATION_SCHEMA.COLUMNS
order by Table_name
OPEN Tbls
PRINT '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">'
PRINT '<html xmlns="http://www.w3.org/1999/xhtml">'
PRINT ' <head>'
PRINT ' <title>KC管理系統-資料庫字典</title>'
PRINT ' <style type="text/css">'
PRINT ' body{margin:0; font:11pt "arial", "微軟雅黑"; cursor:default;}'
PRINT ' .tableBox{margin:10px auto; padding:0px; width:1000px; height:auto; background:#FBF5E3; border:1px solid #45360A}'
PRINT ' .tableBox h3 {font-size:12pt; height:30px; line-height:30px; background:#45360A; padding:0px 0px 0px 15px; color:#FFF; margin:0px; text-align:left }'
PRINT ' .tableBox table {width:1000px; padding:0px }'
PRINT ' .tableBox th {height:25px; border-top:1px solid #FFF; border-left:1px solid #FFF; background:#F7EBC8; border-right:1px solid #E0C889; border-bottom:1px solid #E0C889 }'
PRINT ' .tableBox td {height:25px; padding-left:10px; border-top:1px solid #FFF; border-left:1px solid #FFF; border-right:1px solid #E0C889; border-bottom:1px solid #E0C889 }'
PRINT ' </style>'
PRINT ' </head>'
PRINT ' <body>'
FETCH NEXT FROM Tbls INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
Select @htmls = ' <h3>' + @TableName + ' : '+ CAST(Value as varchar(1000)) + '</h3>'
FROM sys.extended_properties AS A
WHERE A.major_id = OBJECT_ID(@TableName)
and name = 'MS_Description' and minor_id = 0
PRINT ' <div class="tableBox">'
PRINT @htmls
PRINT ' <table cellspacing="0">'
PRINT ' <tr>'
PRINT ' <th>欄位名稱</th>'
PRINT ' <th>類型</th>'
PRINT ' <th>長度</th>'
PRINT ' <th>數值精度</th>'
PRINT ' <th>小數位數</th>'
PRINT ' <th>默認值</th>'
PRINT ' <th>允許為空</th>'
PRINT ' <th>外鍵</th>'
PRINT ' <th>主鍵</th>'
PRINT ' <th>描述</th>'
PRINT ' </tr>'
DECLARE TRows CURSOR
FOR
SELECT
' <td>' + CAST(clmns.name AS VARCHAR(35)) + '</td>',
' <td>' + CAST(udt.name AS CHAR(15)) + '</td>' ,
' <td>' + CAST(CAST(CASE WHEN typ.name IN (N'nchar', N'nvarchar') AND clmns.max_length <> -1 THEN clmns.max_length/2 ELSE clmns.max_length END AS INT) AS VARCHAR(20)) + '</td>',
' <td>' + CAST(CAST(clmns.precision AS INT) AS VARCHAR(20)) + '</td>',
' <td>' + CAST(CAST(clmns.scale AS INT) AS VARCHAR(20)) + '</td>',
' <td>' + isnull(CAST(cnstr.definition AS VARCHAR(20)),'') + '</td>',
' <td>' + CAST(clmns.is_nullable AS VARCHAR(20)) + '</td>' ,
' <td>' + CAST(clmns.is_computed AS VARCHAR(20)) + '</td>' ,
' <td>' + CAST(clmns.is_identity AS VARCHAR(20)) + '</td>' ,
' <td>' + ISNULL(CAST(exprop.value AS VARCHAR(500)),'') + '</td>'
FROM sys.tables AS tbl
INNER JOIN sys.all_columns AS clmns ON clmns.object_id=tbl.object_id
LEFT OUTER JOIN sys.indexes AS idx ON idx.object_id = clmns.object_id AND 1 =idx.is_primary_key
LEFT OUTER JOIN sys.index_columns AS idxcol ON idxcol.index_id = idx.index_id AND idxcol.column_id = clmns.column_id AND idxcol.object_id = clmns.object_id AND 0 = idxcol.is_included_column
LEFT OUTER JOIN sys.types AS udt ON udt.user_type_id = clmns.user_type_id
LEFT OUTER JOIN sys.types AS typ ON typ.user_type_id = clmns.system_type_id AND typ.user_type_id = typ.system_type_id
LEFT JOIN sys.default_constraints AS cnstr ON cnstr.object_id=clmns.default_object_id
LEFT OUTER JOIN sys.extended_properties exprop ON exprop.major_id = clmns.object_id AND exprop.minor_id = clmns.column_id AND exprop.name = 'MS_Description'
WHERE (tbl.name = @TableName and exprop.class = 1) --I don't wand to include comments on indexes
ORDER BY clmns.column_id ASC
OPEN TRows
FETCH NEXT FROM TRows INTO @欄位名稱,@類型,@長度,@數值精度,@小數位數,@默認值,@允許為空,@外鍵,@主鍵,@描述
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT ' <tr>'
PRINT @欄位名稱
PRINT @類型
PRINT @長度
PRINT @數值精度
PRINT @小數位數
PRINT @默認值
PRINT @允許為空
PRINT @外鍵
PRINT @主鍵
PRINT @描述
PRINT ' </tr>'
FETCH NEXT FROM TRows INTO @欄位名稱,@類型,@長度,@數值精度,@小數位數,@默認值,@允許為空,@外鍵,@主鍵,@描述
END
CLOSE TRows
DEALLOCATE TRows
PRINT ' </table>'
PRINT ' </div>'
FETCH NEXT FROM Tbls INTO @TableName
END
PRINT ' </body>'
PRINT '</html>'
CLOSE Tbls
DEALLOCATE Tbls
END