2010-11-25 125 views

回答

44

在概念數據模型中,您只關心高級設計 - 應該存在哪些表以及它們之間的關係。在這個階段,您可以識別模型中的實體以及它們之間的關係。

當您明確定義每個表中的列時,邏輯模型出現在概念建模之後。在編寫邏輯模型時,您可能還會考慮您正在設計的實際數據庫系統,但只有在它影響設計時(例如,如果沒有觸發器,您可能需要刪除某些冗餘列等)。

還有其闡述了邏輯模型和每列有它的類型/長度等

Here是描述每三個水平的良好的畫面分配的物理模型。

+5

如果您確定要在關係數據庫上構建系統,那麼此答案纔是正確的。如果您正在使用非關係數據庫(例如Graphical Database等NoSQL)或根本沒有數據庫,則概念數據建模也非常有用! (例如,你自己的代碼,或者在代碼中找出正確的類和對象,或者在建模域或業務時根本沒有代碼) – 2012-02-01 04:15:11

+0

@veljkoz:我在某處研究過概念與邏輯層次相同。這裏是參考請清除我的疑問.http://jcsites.juniata.edu/faculty/rhodes/dbms/dbarch.htm – Sudhir 2014-02-08 06:07:17

+0

@Sudhir他們都在討論相同的設計水平,但具有不同的細節水平,所以是的,你可以用相同的名字叫他們(儘管我個人寧願選擇'邏輯'而不是'概念'作爲封裝名稱)。這是理論,所以你可能會發現其他的變化。 – veljkoz 2014-02-10 15:46:05

8

不幸的是,這些術語有很多可能的定義。根據ANSI-SPARC「三模式」模型,概念模式或概念模型由數據庫中的一組對象(表,視圖等)組成,而外部模式則是用戶看到的對象。

在數據管理的專業和尤其是在數據建模者/建築師,術語概念模型經常用於指語義模型而術語邏輯模型被用於表示一個初步的或虛擬數據庫設計。這可能是您在工作場所最有可能遇到的用法。

然而,在學術用途和描述DBMS體系結構時,邏輯級意味着與物理層(文件,索引,存儲)不同的數據庫對象(表,視圖,表,鍵,約束等)。爲了進一步混淆事物,在工作場所,術語「物理模型」通常用於表示在實際數據庫中實施或計劃實施的設計。這可能包括「物理」和「邏輯」級別的結構(例如表和索引)。

當你遇到任何這些條款時,你真的需要澄清正在描述的內容,除非上下文顯而易見。

有關這些差異的討論,請參閱Simsion和Witt的Data Modeling Essentials。

1

我需要產生一個邏輯模型和一個概念模型。這裏的所有解釋都非常模糊。上面提到的鏈接只是顯示了不同之處,即概念模型是沒有字段的邏輯模型。好吧,我沒有提到數據庫的名稱。這似乎是完全多餘的。

我真的不知道'語義'是什麼意思。有人可以解釋我會以不同的方式使用'英語'來做什麼,並且可能會發佈一個更好的示例鏈接,而不是一張顯示一張圖片具有字段而另一張沒有字段的圖片。這些流行語都很好,但它很模糊,實際上並沒有用處。除了採用我的邏輯模型(這基本上是我的物理模型顛倒了數據庫的設計,點擊了上述工具中的一個按鈕,並且圖像看起來有點不同,然後取下數據類型),我還能做其他任何事情嗎?

從我可以看到實際(和不流行語)

物理模型:實際表。邏輯模型:點擊我的工具的小按鈕(使用Oracles SQL Developer Data Modeller,我沒有erwin許可證和2010 visio不再將工程師從DB中撤銷) ,然後屏幕上的圖像稍微改變。數據類型消失了,約束的名字消失了,然後表格的顏色變成了紫色(所以現在我稱之爲實體)。

好的。那麼我的概念模型會是什麼樣子:與我的邏輯模型完全相同的東西減去字段。我認爲除此之外還有更多。背誦其數據的「語義」表示聽起來真的很好,並且看起來很不錯,但對於以前沒有做過這些的人來說,這是沒有意義的。

-1

邏輯數據模型

邏輯數據模型描述爲儘可能詳細的數據,而不考慮他們將如何物理數據庫實現。邏輯數據模型的功能包括: ·包括它們之間的所有實體和關係。 ·指定每個實體的所有屬性。 ·指定了每個實體的主鍵。 ·指定了外鍵(標識不同實體之間關係的鍵)。 ·正常化發生在此級別。 概念數據模型

概念數據模型標識不同實體之間的最高級別關係。概念數據模型的特徵包括: ·包含重要的實體及其間的關係。 ·沒有指定屬性。 ·沒有指定主鍵。

2

邏輯數據庫模型

邏輯數據庫建模需要編制的業務需求和代表需求的一種模式。它主要與收集業務需求有關,而不是數據庫設計。需要收集的信息涉及組織單位,業務實體和業務流程。

一旦信息被編譯,報告和圖表製成,包括這些:

ERD-實體關係圖顯示了不同類別的數據之間的關係,顯示了不同類別的一個數據庫的開發所需的數據的。 業務流程圖 - 它顯示了公司內部的個人活動。它展示了數據如何根據可以設計哪個應用程序接口在組織內移動。 用戶反饋文檔。

邏輯數據庫模型基本上確定是否收集了業務的所有需求。它由開發人員,管理人員以及最終用戶進行審查,以確定在物理建模開始之前是否需要收集更多信息。

物理數據庫模型 物理數據庫建模涉及基於邏輯數據庫建模期間收集的要求設計實際數據庫。收集的所有信息都轉換爲關係模型和商業模型。在物理建模過程中,對象被定義爲一個稱爲模式級的級別。模式被視爲一組在數據庫中彼此相關的對象。 根據邏輯建模期間提供的信息製作表格和列。主鍵,唯一鍵和外鍵是爲了提供約束而定義的。索引和快照已定義。可以總結數據,並在創建表格後爲用戶提供替代視角。

物理數據庫建模取決於組織中已經使用的軟件。它是軟件特定的。物理建模包括:

服務器模型圖 - 它包括表和列以及數據庫中存在的不同關係。 數據庫設計文檔。 用戶的反饋文檔。

摘要:

1.Logical數據庫建模,主要用於收集有關企業需求的信息,不涉及設計數據庫;而物理數據庫建模則主要用於數據庫的實際設計。 2.邏輯數據庫建模不包括索引和約束;應用程序的邏輯數據庫模型可用於各種數據庫軟件和實現;而物理數據庫建模是特定於軟件和硬件的,並且具有索引和約束。 3.邏輯數據庫建模包括; ERD,業務流程圖和用戶反饋文檔;而物理數據庫建模包括;服務器模型圖,數據庫設計文檔和用戶反饋文檔。

瞭解更多:邏輯和物理數據庫模型之間的區別| |之間的區別邏輯與物理數據庫模型http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg

0

這裏的大多數答案都嚴格與不同抽象層次的數據模型的符號和語法有關。關鍵的區別並沒有被任何人提及。概念模型表面概念。概念以不同的方式與其他概念相關聯,即實體與邏輯抽象級別的另一個實體相關聯。概念更接近類型。通常在概念級別,您顯示事物類型(這並不意味着您必須在命名約定中使用術語「類型」)以及這些類型之間的關係。因此,多對多關係的存在不是規則,而是類型元素之間關係的結果。在邏輯模型中實體表示現實世界中該事物的一個實例。在概念模型中,不期望描述實體的實例及其關係,而是描述該實體的「類型」或「類」。 示例: - 車輛在車輛中使用車輪和車輪。在概念層面,這是一個多對多的關係 - 一個特定的車輛(例如一輛車),一個特定的註冊號碼有5個車輪和每個特定的車輪,每個車輪都有一個序列號僅與該特定車輛有關。在邏輯層面上,這是一種一對多的關係。

概念性涵蓋「類型/類」。邏輯涵蓋「實例」。

我會添加另一個關於數據庫的評論。我同意上面評論過的一位同事,概念模型和邏輯模型對數據庫一無所知。概念模型和邏輯模型使用ER或UML等符號從數據角度描述真實世界。數據庫廠商巧妙地設計了他們的產品,以遵循用於邏輯建模世界的相同理念,並創建了關係數據庫,使每個人的生活變得更加簡單。您可以使用概念和邏輯模型在所有級別描述組織的數據格局,而不使用關係數據庫。

嗯,我想這是我的2美分...

0

概念模式 - 涵蓋實體和關係。應該先創建。與其他一些答案相反;表格在這裏沒有定義。例如,「多對多」表不包含在概念數據模型中,但被定義爲實體之間的「多對多」關係。

邏輯架構 - 涵蓋表,屬性,密鑰,強制角色約束和參照完整性,不考慮物理實現。像索引這樣的東西沒有定義,屬性類型應該保持邏輯,例如文本而不是varchar2。應該基於概念模式來創建。

相關問題