建模具有古怪行爲的數據庫（ERD）

Question

我正在處理的其中一個數據庫有一些古怪的行爲，我想在實體關係圖中進行說明。

其中一種行爲是有「預訂」表和「發票」表。當「預訂」開具發票時，記錄將被插入「發票」表中，然後從「預訂」表中刪除。

但是，仍然保留有關預訂編號的參考。

我們如何建模？表格之間的大箭頭和旁邊的一些文字描述了會發生什麼？

否，更換數據庫架構在這一點上是不可能的時間

編輯：這是我想用圖表的類型： alt text http://img813.imageshack.us/img813/5601/erdartistperformssong.png Link

Answer 1

如果通過ERD，您的意思是原始的「陳」圖，其關係是用菱形書寫的文字，那麼您在預訂和發票之間有關係。這是一種特殊的關係，不是用一個簡單的外鍵來實現的;它通過複雜的移動和約束來實現。

如果ERD指的是ERwin繪製的圖表，那麼您沒有簡單的方法來完成此操作。它傾向於集中於繪製PK-FK關係。這些東西之間有一個非PK-FK關係。與文本的某種線是關於你所能做的一切。

箭頭BTW不合適，因爲ERD顯示數據庫的「狀態」。流動的數據不是ERD的一部分。你確實有關係，這不是一個典型的PK-FK關係。這是基於某些地方存在的行而非其他存在的行的非典型關係。

在UML中，您可以很容易地將這作爲關係中的「約束」。

Answer 2

聽起來像一個過程流，而不是一個實體關係。如果在條目被添加到發票時，並且該條目從預訂中刪除，則兩者之間從來沒有關係。你永遠不可能遍歷這種關係，因爲在兩個地方都沒有可以相互關聯的記錄。

ERD不完全描述數據庫。還有其他一些東西，如流程流程和用例，詳細介紹系統的其他方面。

這是UML軟件的一個類比。類圖不會顯示類與之交互的所有不同方式。一個類可能會在本地初始化並調用另一個類的函數，但由於沒有關聯這兩個類的組合或繼承，因此類圖不會顯示這種關係。只有當你用各種類型的圖表完整地記錄系統時，你才能看到它如何運作的所有方面。

Answer 3

我不知道這些人在說什麼。

1. 實體關係圖並未完全描述數據;當然，它只顯示實體和關係，它不顯示屬性。這就是爲什麼它被稱爲ERD而不是數據模型的原因。顯然，很多人在這裏無法區分。

2. 數據模型是爲了顯示儘可能多地。但它取決於（a）您使用的標準[如果有]和（b）標記。有些顯示比其他更多。 IDEF1X是唯一的關係建模標準（1993年的NIST 184）。它是最完整的，並且顯示其他符號沒有顯示的錯綜複雜。最近MS和其他人拿出了「簡化」的符號，當然，在「ERDs」中丟失了很多。

3. 這不是「流程」，它是在一個數據庫中的關係。

4. UML是用於建模數據完全不合適的，尤其是當有至少一個標準加上幾個不規範的，但常用的數據建模符號。在UML中沒有任何內容不能在IDEF1X中顯示。但這裏大多數開發商從來沒有聽說過它（開發商不應該被建模，除非他們已經獲得建模技能，但那是另一回事）..

5. 這是一個完全合法的;它可能不是衆所周知的，但它是合法的，並被命名。這是一個Supertype-Subtype關係，除了Cardinality是1 :: 0-n而不是1 :: 0-1。 IDEF1X符號（右）具有子類型符號。請注意，父代只有一個關係;每個孩子都有一個。當然，烏鴉腳顯示基數。這些關係可以獨家或非排他性;你是唯一的;那就是X通過半圈的意思。

   • ERwin是唯一實現IDEF1X的建模（非圖表）工具，因此具有IDEF1X表示法的完整補充。

   • 當然，標準的建模能力，都在心中，而不是工具。我使用簡單的繪圖工具繪製符合IDEF1X的數據模型。

6. 我發現，一些開發商在亞型符號卻步，所以我表現的簡化版本（左）在我的IDEF1X模型;它旨在表達排他性的意義，而保留父行末尾的單行表明它是一個子類型。

洛特：點擊這裏▶Link to Data Model◀洛特：點擊這裏

Link to IDEF1X Notation對於那些誰不熟悉關係建模標準。