數據流圖 和 數據字典

1、數據流圖和數據字典是用來幹啥的？

一、數據流圖（Data Flow Diagram, DFD）

​ 從"數據（Data）"一詞中咱們能夠看出它是用來描述數據的，也就是說它的對象（或者說核心）應該是數據，要描述「（數據）是什麼？」；從"流（Flow）"一詞中咱們又能夠提煉出它的角度是（數據的）傳遞過程與加工，即「（數據）由有哪些屬性構成？從哪兒來？到哪兒去？要幹啥？」；最後着眼"圖（Diagram）"能夠得出這是以圖形爲基礎的模型，也就是用不一樣的圖形區分不一樣的類別。

​ 因此總結起來，一句話歸納：數據流圖（DFD）是從數據（Data）的傳遞和加工（Flow）角度，以圖形（Diagram）的方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換（Flow）過程。

​ 來，咱們先看一個簡單的實例（如今不知道怎麼作很正常，一下子詳細解釋）。

二、數據字典（Data Dictionary）

​ 你們試想一下，咱們如今已經擁有了一張"數據流圖（DFD）"，那麼光有這麼一張圖能夠嗎？好比說，你知道\(Entity\_001\)具體是啥嘛？不知道叭，這時確定有吐槽「那就把名稱加上唄」，但\(Entity\_001\)僅僅只是一個名稱嘛，既然是一個實體那是否是就還有屬性呢？這時將這些屬性一一標記上去這張圖會是什麼樣，顯然就很是的凌亂。因此咱們就用一個代號來表示一個對象（包括實體、數據流、加工、存儲），在圖以外引入新概念——數據字典（DD）來對這些代號進行解釋。下面就來簡單看一下數據字典是什麼。

​ 不用多說確定是一個描述"數據（Data）"的東西，那怎麼描述的呢？答案就是用"字典（Dictionary）"。字典是啥，只知道《辭海》、《康熙》或者《牛津》？umm……我能夠說這差很少，字典就是一種映射關係，咱們小時候「做弊」用的「暗號」就是一個不成文的字典，譬如\(X\)同窗規定撳動一次就選\(A\)、撳動兩次就選\(B\)……，那麼咱們就能夠獲得以下的字典：

明文（也能夠是id號）	密文（也能夠是對對應id號的解釋）
1	\(A\)
2	\(B\)
……	……
26	\(Z\)

因此字典的本質也就是一張表，又因爲是對數據流圖的描述，那很天然地就包括以下幾個方面：（Ⅰ）數據項；（Ⅱ）數據結構；（Ⅲ）數據流；（Ⅳ）數據存儲；（Ⅴ）處理過程；這裏先各出一個實例（用上面的數據流圖爲例，構造一個合理的、簡化的數據字典）：

（ⅰ）數據項：

\(ID\)	\(Name\)	含義
\(studentID\)	學生的\(ID\)號	對學生實體集有惟一標識的標識符
\(studentName\)	學生的姓名	每個學生實體在社會中的代號

（ⅱ）數據結構：

\(ID\)	\(Name\)	組成（實體的屬性）
\(Entity\_001\)	學生實體	\(ID\)號、姓名

（ⅲ）數據流：

\(ID\)	\(Name\)
\(DataFlow\_001\)	排課信息
\(DataFlow\_002\)	學生信息
\(DataFlow\_003\)	課程信息
\(DataFlow\_004\)	學生選課信息

（ⅳ）數據存儲：

\(ID\)	\(Name\)
\(DataStorage\_001\)	學生天然狀況（學生信息表）
\(DataStorage\_002\)	課程信息表
\(DataStorage\_003\)	學生的選課表

（ⅴ）處理及加工：

\(ID\)	\(Name\)	處理
\(DataProcess\_001\)	學生選課	記錄學生的\(ID\)、被選課程的\(ID\)

2、詳細介紹數據流圖和數據字典

一、數據流圖

（Ⅰ）數據流圖的基本圖形和符號

​ 咱們先從最簡單的圖形分類入手，這裏給出經常使用的四種基本圖形及其含義【在圖形中標註編號（\(ID\)）或者名稱（\(name\)），或者二者都標上，這樣看圖的時候既更直觀還容易查找\(ID\)索引】：

圖形（符號）	類別名稱	含義說明
或者	數據的加工和處理 （\(Data Process， DP\)）	必須有輸入流和輸出流，缺一不可
	數據的源點或匯點， 也就是外部實體（\(Entity\)）	數據加工的一端，要麼提供數據， 要麼聚集數據造成新的外部實體
	數據存儲文件 （\(DataStorage\)）	數據加工的一端， 能夠提供數據或者存儲數據
	數據流 （\(DataFlow\)）	一邊爲實體或者數據存儲文件， 另外一邊爲數據的加工和處理， 其名稱清晰表達傳遞的主要數據

​ 在加工的時候不可避免會出現多種數據進出的狀況，那麼數據流圖是怎樣表示的呢？在作表以前咱們先畫出數據加工和數據流的圖【\(（\theta_1，\theta_2） \in \theta=\{+， *， \bigoplus\}\)】：

\(\theta\)所表明的符號爲	含義（令true = 1）
*	交集，同時成立（能夠省略）：\(\sum_{i=1}^{N}{DF_{（input,i）}}=N\)、\(\sum_{j=1}^{M}{DF_{（output,j）}}=M\)
+	並集，至少有一個成立：\(\sum_{i=1}^{N}{DF_{（input,i）}}\ge 1\)、\(\sum_{j=1}^{M}{DF_{（output,j）}}\ge 1\)
\(\bigoplus\)	其中之一：\(\sum_{i=1}^{N}{DF_{（input,i）}}=1\)、\(\sum_{j=1}^{M}{DF_{（output,j）}}=1\)

（Ⅱ）數據流圖設計的原則

（1）、任意流不能重名 由於流的名字即爲他們的\(ID\)號，常識告訴咱們不存在兩個徹底同樣的物體，爲了區分必須避免重名；

（2）、數據守恆原則 對於任意一個數據處理來講，其所有的輸出數據流中的數據一定能從其輸入數據流中的數據直接得到。這一原則也說明了數據流是必須與數據處理有關的，應該也只能依附與數據流。咱們能夠用能量守恆來理解這一原則，將數據存儲和外部實體比做物體、數據比做能量，數據處理即爲物體之間的相互做用，只有在物體進行相互做用的時候纔會存在能量的流動（傳遞），因此同理可得只有在數據處理的推進下，數據才得以傳遞，從而造成數據流。

①、外部實體與外部實體之間不存在數據流；

②、外部實體與數據存儲之間不存在數據流；

③、數據存儲與數據存儲之間不存在數據流；

④、數據流必須通過（其中一端爲）數據處理（加工）；

（3）、守恆加工原則 （前兩條都是針對加工而言）

①、對於任意一個加工，至少有一個數據輸入流和一個數據輸出流；

②、由任意流不能重名能夠推出：對於任意一個加工，輸入數據流與輸出數據流必須不一樣名，即便輸入的數據與輸出的數據結構如出一轍，可是這樣的狀況常見於向數據存儲文件寫入數據的時候：因爲數據守恆原則，數據流必須通過數據加工，可是這樣的數據加工並不會改變數據流中的數據。因此人們規定：對流進或者流出數據存儲文件的數據流不須要標註名字，由於文件自己就足以說明數據流。因此，若是一種數據流須要被屢次引用時能夠創建一個臨時的數據存儲（對應的就是內存數據庫），這樣就沒有必要爲同一種數據流進行標號。另外，當輸入輸出流如出一轍的狀況發生在非數據存儲文件操做時，就要考慮其加工或者數據源存在的合理性和必要性了，由於這至關於沒有對數據進行處理，屬於冗餘操做；

③、數據源包含數據存儲文件、最終新造成的外部實體和數據存儲文件必須與數據源同級，也就是說數據流的終點必定是在外部而且指向外部實體或者數據存儲文件。由於只要有外部數據流參與，那麼有入必有出，這個出就是指向新造成外部實體或數據文件的輸出數據流；好比下圖中的數據文件：\(Student\_Course\)。

④、與③相對應的，若是新造成的外部實體或者數據存儲文件在圖的內部，就代表它不是數據流的終點而是一個結點，那麼必須具有一條輸入流和一條輸出流；好比說在②中說起的臨時數據存儲文件。

⑤、與③和④相反的，若是在內部的數據存儲文件不是新造成的，也就是說它們是該數據庫管理系統直接向操做系統中發送請求並載入內存的數據存儲文件，那麼這些文件能夠只含有輸入或者輸出流；好比說，如圖③所示，顯然\(Course\)、\(Student\)都不是新造成的數據存儲文件，因此它們雖然在頂層數據流圖的內部，可是隻有一條數據流（輸出）。

⑥、每個（或一組）輸入流與特定的一個（或一組）造成對應，這樣一對數據輸入輸出流在同層級圖中的同深度處以及彼此的後繼（更深層的）輸入輸出流對應該是相互獨立的，去掉其中任意一對或多對以後數據流圖仍然保持守恆加工原則；如圖：

（ⅰ）\(DF-A\)系列與\(DF-B\)系列相互獨立；

（ⅱ）\(DF-A1\)系列之間（\(DF-A1\_1\)與\(DF-A1\_2\)）相互獨立；

（ⅲ）彼此的後繼之間（\(DF-A1\_1\)與\(DF-A1\_2-A2\)系列、\(DF-A1\_2\)與\(DF-A1\_1-A2\)系列、\(DF-A1\_1-A2\)系列與\(DF-A1\_2-A2\)系列）相互獨立。

⑦、很容易被忽視的一點：數據存儲不可能憑空出如今數據庫管理系統中，必須經過操做系統從磁盤中讀取相應的文件載入內存，當對數據存儲文件操做完成以後，再寫入磁盤。可是正是由於全部的數據流圖都有這一類數據流，因此經常被做爲枝節被省略，這致使在研究細節的時候發現不少數據流圖都沒有遵照守恆加工原則；因此完整的數據流圖應該是這樣（用虛線表示省略的）：

這個時候咱們就能夠理解爲：從操做系統中讀取的文件與外部實體給予的信息進行組合（數據加工），最後造成了新的文件並寫入磁盤中。

（4）、父圖與子圖應該統一輸入輸出流： 父圖能夠看作是一個總體，也就是一個黑盒子，其中包含了不少個子圖，那麼子圖的輸入輸出流固然就源自黑盒子（父圖）；好比學生選課後出了成績：

一共分了兩個區域（上下），上部分爲總體的局部數據流圖，數據處理由一個父圖構成；下部分即爲父圖中更加細節的子圖數據流圖。這個時候咱們能夠看到父圖由外部數據流（\(CourseSchedulingInfo\)、\(ScoreInfo\)、\(CourseInfo\)、\(StudentInfo\)）的參與產生了一個新的數據存儲（\(Student\_Course\)），必須將其提出放在父圖的外部，若是不這樣作的話就會違反守恆加工原則。由父圖子圖流一致原則咱們能夠得出另外一重要的原則：加工細節隱蔽原則，就是說沒有必要一味地對父圖進行拆分，能夠適當地只保留父圖不去關心子圖的內在聯繫（類比總體法）。

（5）、簡化加工之間的關係 加工間的數據流越少，各個加工就越相對獨立、耦合度就越低，若是數據流不少的話，雖然能夠實現較爲複雜的功能可是也增長了運維成本，甚至可能形成動一發而牽全身的混亂局面。這就要求咱們作到先抓住主要矛盾，暫時忽略枝節。

（6）、均勻分解父圖 儘可能不要出現對數據處理分解的兩極化，好比一個分了七八層而另外一個只分了兩三層，這樣會形成輕重不一的局面存在考慮不周的潛在隱患。

（7）、是數據流而不是控制流 數據流是控制流上的操做表示，只有在控制流上進行的數據流分析纔有價值。也就是說數據流圖只須要表達出數據的結構、來源、流向、加工，並不關心數據流在融入控制層以後進行的邏輯處理與程序跳轉的結果（程序元素邏輯執行的前後順序）。

在這些原則中最重要的當屬：保持父圖與子圖平衡，保持數據平衡，加工細節隱蔽。

二、數據字典

（Ⅰ）數據字典的用途與組成

​ 根據以前的分析，咱們能夠得出：數據字典的就是對數據流圖中出現的全部被命名的圖形元素在數據字典中做爲一個詞條加以定義，使每一個圖形元素的名稱都有一個確切的解釋。

​ 最初只給了二級表頭，如今給出更加精細的三級表頭，畫一個思惟導圖會更加清晰。

具體實例請看傳送門：數據字典舉例。（想要\(PDF\)版的能夠私聊哦）

（Ⅱ）數據結構的描述

​ 在數據字典中最特殊的當屬數據結構了，由於數據結構是描述其餘字典條目的基礎，因此準確來講，數據字典中應該是包含下面4種條目：

①、數據項條目：數據類型、取值範圍……等；

②、數據流條目：定義、給出組成數據流的數據項（利用數據結構描述）；

③、文件條目：定義、給出組成文件的數據項（利用數據結構描述）；

④、加工條目：加工條目必須具有原子性，給出說明（激發條件、邏輯、處理順序……等）；

咱們言歸正傳，數據結構的描述一般採用以下表中的符號：

符號	含義	說明
=	被定義爲（賦值）	\(x=a\)，\(x\)由且僅由\(a\)構成
+	與	\(x=a+b\)，\(x\)由\(a\)和\(b\)構成
[…|…]或者[…, …]	或	\(x=[a，b]\)，\(x\)由\(a\)或者\(b\)構成
\(m\){…}\(n\)、{…}\(_{N}^{M}\)	重複（\(m,n\)的默認值爲0和\(+\infty\)）	\(x=3\{a\}六、\{a\}_3^6\)，\(a\)能夠重複3~5次
（…）	可選（非必須項）	\(x=（a）\)，\(a\)能夠出如今\(x\)中
"…"	基本數據元素	\(x="a"\)，\(x\)取值爲\(a\)的數據元素
··	鏈接	\(x=a··f\)，\(x\)由\(a\sim f\)組成

好比咱們要表示學生這個實體集（或者學生表）時，就能夠這樣：

\(StudentEntity=studentID+studentName+studentIDCard+studentSex+\{studentInterest\}+（studentInfo）\),

再好比咱們新建一個能夠實現查詢的任務，包括查詢學生信息、課程信息以及學生選課信息，這是當數據庫管理員（或者教務系統管理員）向教務管理系統發出查詢請求（數據流）的時候就能夠這樣表示：

\(selectRequestInfo=[selectStudentInfo\ |\ selectCourseInfo\ |\ selectStudent\_CourseInfo]+\{IllegalRequest\}\)，

3、數據流圖 & 數據字典 綜合應用問題

一、需求

​ 某教務管理系統的主要功能爲：師生教學管理和信息查詢。對於新招的師生，系統按照既定的法則自動生成師生的編號，並和他們的基本信息一塊兒分別寫入學生文件和教師文件，一樣適用於新開設的課程。

（Ⅰ）師生教學管理功能：新增師生和課程、註銷師生和課程、學生選課出成績

（1）、新增師生和課程 新招師生和課程的時候須要分別編制《入校學生單》、《新招教師單》以及《新開設課程單》以便直接對新增對象進行管理與研究，而後將信息分別寫入《學生表》、《教師表》和《課程表》。

①、《入校學生單》：\(ID\)號、姓名、身份證、出生年月日、性別、入校時間；

②、《新招教師單》：\(ID\)號、姓名、身份證、出生年月日、性別、新招時間；

③、《新開設課程單》：\(ID\)號、課程名、課時、上課信息（日期時間教室列表）、新開設時間；

（2）、註銷師生和課程 學生畢業、老師退休以及課程結課的時候須要分別編制《學生畢業單》、《老師退休單》、《課程結課單》，而後分別修改《學生表》、《教師表》、《課程表》中的註銷時間以及是否註銷（默認值爲\(NO\)，現改成\(YES\)）。

①、《學生畢業單》：\(ID\)號、畢業時間、是否畢業（只能填寫\(YES\)，用於覆蓋《學生表》）；

②、《老師退休單》：\(ID\)號、退休時間、是否退休（只能填寫\(YES\)，用於覆蓋《教師表》）；

③、《課程結課單》：\(ID\)號、結課時間、是否結課（只能填寫\(YES\)，用於覆蓋《課程表》）；

（3）、學生選課出成績 學生選課時須要編制《學生選課申請單》和《學生最新選課單》。

①、《學生選課申請提交單》：學生的\(ID\)號、課程的\(ID\)號、選課權重

②、《學生最新選課單》：學生的\(ID\)號、課程的\(ID\)號、選課權重；

假設選課權重在同一學號記錄中不能重複，且爲[1, 6]之間的整數，當學生提交《學生選課申請單》時系統給出選項，學生自行選擇，即限定每一個學生的選課門數最多爲6門。此外系統應該有三層過濾網（這三層過濾能夠放置在一個加工中——加工細節隱蔽原則）：

（ⅰ）系統首先經過聚合運算檢查在《學生最新選課單》中該學生的選課門數是否爲6，若不是則容許將該學生《學生選課申請提交單》的選課信息添加至《學生最新選課單》；如果則拒絕添加。

（ⅱ）若是選課門數小於6則進行衝突檢查，查找《學生選課表》中該學號對應的選課課程號集合，再在《課程表》中查找"上課信息"這一字段，而後與該學生新選課程的上課信息進行比對。若這時沒有衝突才能將《學生選課申請提交單》的選課信息寫入《學生最新選課單》；如有衝突則拒絕寫入。

（ⅲ）排處第一層衝突以後，系統應該檢查該學生全部新選課程的"上課信息"進行比對，並按照選課權重選取權重最大的課程，其餘與之相沖突的選課記錄將被刪去。

通過系統的三層排除衝突以後的《學生最新選課單》方能寫入《學生選課表》。以後學生考試填寫試卷，教師批閱提供分數信息，將分數信息與選課信息合併存入《學生選課表》。

（Ⅱ）信息查詢功能：查詢教師學生和課程的基本信息、學生成績

（1）、查詢教師的基本信息 能夠查詢到教師的基本信息；

（2）、查詢學生的基本信息 能夠查詢到學生的基本信息；

（3）、查詢課程的基本信息 能夠查詢到課程的基本信息；

（4）、查詢學生成績的基本信息 能夠查詢到學生選課的信息以及學生在此課程中的分數狀況；

二、數據流圖

（Ⅰ）頂層圖：

（Ⅱ）第0層圖：

（Ⅲ）加工的分解：

（ⅰ）對處理學生選課以及成績信息的分解：

三、數據字典

\(Excel\)查看傳送門：數據字典-教務管理系統部分功能

\(Excel\)下載傳送門：數據字典-教務管理系統部分功能。

4、數據字典的補充

​ 數據字典不僅僅是用於解釋數據流圖，還能在數據存儲文件設計的時候提供援助。當現實世界中的主體有不斷變化的屬性時（屬性的數量和屬性的取值），尤爲是變化得很是頻繁的時候，就會引入數據字典輔助數據表設計。

​ 這裏簡單地介紹一下由\(rongwenbin\)先生總結的兩種用於輔助設計數據庫表的數據字典，原文傳送門：數據字典。爲了更好理解我將先生用到的實例換作咱們常見的教務管理系統，其主要功能爲管理並查詢學生、教師、課程……等實體集的基本信息。

​ 在構建數據庫管理系統以前，我先將兩種數據字典擺出來：

（Ⅰ）將主體的屬性編碼（設置每個屬性\(ID\)號），並將這些\(ID\)號放入獨立的數據庫表中做爲主鍵，其對應的值就是屬性的取值；（這對應於數據庫表規範化中的模式分解）

（Ⅱ）將結構（模式）相同的數據庫表整合在一塊兒，用統一的編碼規範設置\(ID\)號並將其做爲主鍵，對應的值爲屬性的名稱以及屬性的取值；（這對應於數據庫表規範化中的模式合併）

​ 咱們來看這樣一個需求：假設咱們已經設計出了該教務管理系統的邏輯模型初稿，其中有一個模式爲「學生（學號，姓名，系別名稱）」。在這一模式中體現出了「學生」實體和「學生屬於系別」聯繫，雖然一舉兩得提升了查詢的效率，可是這裏很明顯存在一個問題：系別的名稱若是更改，則學生表中的"系別名稱"屬性的取值都要作出相應的調整，這系別名稱還好，若是是國籍呢，好比前蘇聯到俄羅斯，這就要涉及到上億份數據。怎樣解決這一問題呢？先生指出咱們能夠參考（Ⅰ）數據字典，新建一張《系別表》，其中存放"系別\(ID\)"和"系別名稱"，這樣在學生表中直接引入外鍵"系別\(ID\)"便可，這是更改系別名稱就只用在《系別表》中更改"系別名稱"而"系別\(ID\)"不用改，保證了《學生表》的穩定性。上述文字轉換爲數據表的動態變換就是：

更改以前的數據庫表《學生表》及實例：

學號	姓名	系別名稱
180502304	BN2U	地理信息系統

更改以後的數據庫表《學生表》及實例：

學號	姓名	系別\(ID\)
180502304	BN2U	001

新建的《系別表》及實例：

系別\(ID\)	系別名稱
001	地理信息系統

根據上級的命令更改數據，將「地理信息系統」改成「地理信息科學」這樣的話就會有：

更改以後的數據庫表《學生表》及實例：

學號	姓名	系別\(ID\)
180502304	BN2U	001

新建的《系別表》及實例：

系別\(ID\)	系別名稱
001	地理信息科學

顯然《學生表》沒有任何改動。

​ 這樣很\(nice\)可是有沒有想過若是一個主體中的屬性不是兩三個，而是幾十個甚至上百個，那麼每一次查詢都涉及到上百個奪標鏈接操做，這時的查詢效率簡直不敢恭維。因而先生又提出了第二種方案：（Ⅱ）數據字典，將屬性數據表進行合併，可是並非將全部的數據表進行合併，而是針對模式（結構）同樣的一組表。這樣就能將查詢所涉及到的表大幅度的減小，從而提升了查詢的效率。下面咱們來看一個案例，解釋（Ⅰ）的缺點和（Ⅱ）。

​ 咱們如今有一個需求：假設咱們更新了模式，最後變爲「學生（學號，姓名，證件類型，證件號，國籍，民族，系別名稱，政治面貌）」，根據（Ⅰ）的分解，咱們能夠將模式繼續升級爲「學生（學號，姓名，證件類型\(ID\)，國籍\(ID\)，民族\(ID\)，系別\(ID\)，政治面貌\(ID\)）」、「證件類型（證件類型\(ID\)，證件類型，證件號）」、「國籍（國籍\(ID\)，國籍）」、「民族（民族\(ID\)，民族名稱）」、「系別（系別\(ID\)，系別名稱）」、「政治面貌（政治面貌\(ID\)，政治面貌名稱）」，就這樣一直被分解，若是隻是5個左右的表那查詢起來也不是很費勁，可是一個學生顯然不可能只有這樣幾個屬性，因此若是繼續分解下去就會帶來過於沉重的查詢計算量。

​ 既然咱們的目的是爲了提升查詢效率，那個合併數據表顯然是一個不錯的選擇，可是咱們知道一個數據表的模式是定死了的，而且屬性的取值是必須規定在同一個域，因此只有表結構相同、對應屬性的取值範圍相同的表纔可以合併。咱們將目光轉移至分解以後的屬性表，發現除了《證件類型》這張表以外都很類似，模式都是「屬性的名稱（ID，屬性的值）」，那咱們就能夠合併了。回過頭看《證件類型》這張表，不難發現"證件號"能夠做爲主碼，從而代替"證件類型\(ID\)"，這樣《證件類型》表的模式爲「證件類型（證件號，證件類型）」。這時咱們整合這些屬性表，獲得一個新的表模式「屬性（屬性\(ID\)號，屬性分類\(ID\)號，屬性取值）」，構造一個實例：

《系統屬性代碼表》

屬性\(ID\)號	屬性分類	屬性取值
001	身份證	xxxxxx20010202xxxx
002	身份證	xxxxxx20000302xxxx
003	暫居證	yyyyyy
004	國籍	中國
005	國籍	薩摩亞
006	國籍	美國
007	系別	地理信息科學
008	政治面貌	團員
009	政治面貌	黨員
……	……	……

《學生表》

學生\(ID\)	學生姓名
180502304	BN2U
180502305	\(\pi\)
180502302	\(e\)

《屬性表》

學生\(ID\)	屬性\(ID\)
180502304	001
180502304	004
180502304	007
180502304	008
180502302	002
180502302	004
……	……

這樣在查詢任意一個學生的時候最多也就是3張表的查詢，一張差姓名、另外兩張查找其餘屬性\(ID\)以及對應的內容，這樣查詢效率是否是就大大提高了呢？可是細心的同窗會發現這樣作的後果就是形成了最開始的問題：對數據庫進行更改很麻煩。因此這裏我想作的一點補充就是：這兩種數據字典的思想要相結合，咱們能夠在需求分析階段調查不易改變的屬性名稱，將這些屬性名稱利用（Ⅱ）數據字典整合成爲一張表；相應地將容易改變的屬性名稱利用（Ⅰ）數據字典構造一張新的屬性表。就拿上面這個例子來講，對於「國籍」、「證件類型」、「民族」、「政治面貌」對於咱們來講在至關長的一段時期內屬性的名稱是不會變化的（可能咱們會變成黨員，可是團員仍是叫作團員），而「系別」可能就會有所調整，因此咱們能夠構建這樣4張表：「學生（學號，姓名）」、「系別（系別\(ID\)，系別名稱）」、「系統屬性代碼（屬性\(ID\)號，屬性分類，屬性取值）」、「屬性表（學生\(ID\) ，\(ID\)屬性\(ID\)）」，其中表示系的時候在《系統屬性代碼表》中體現：

《系統屬性代碼表》

屬性\(ID\)號	屬性分類	屬性取值
001	系	001
002	系	004
003	國籍	中國

《系別表》

系別\(ID\)	系別名稱
001	食品科學與工程
004	地理信息科學

數據流圖 && 數據字典就到這了，不知道大家有沒有弄懂？（反正我是明白了【狗頭保命】）