ArcGIS地理數據庫Geodatabase

本文轉載自查看原文 2020-11-12 09:47 761

一直以來對ArcGIS中的數據庫用的比較少，但是其實這是個很方便的東西，特別是在組織一些包含空間關系的各種實體對象的時候，可以很方便地進行查詢與顯示，感覺在房產管理等應用中非常有用

通過一個案例稍微記錄一下感覺這個組織模式還挺有意思的

GDB

地理數據庫是用於保存數據集集合的“容器”。有以下三種類型：

文件地理數據庫 - 在文件系統中以文件夾形式存儲。每個數據集都以文件形式保存，該文件大小最多可擴展至 1 TB。建議使用文件地理數據庫而不是個人地理數據庫。

個人地理數據庫 - 所有的數據集都存儲於 Microsoft Access 數據文件內，該數據文件的大小最大為 2 GB。

企業級地理數據庫 - 也稱為多用戶地理數據庫，在大小和用戶數量方面沒有限制。這種類型的數據庫使用 Oracle、Microsoft SQL Server、IBM DB2、IBM Informix 或 PostgreSQL 存儲於關系數據庫中。

多數情況下，Esri 推薦使用文件地理數據庫以實現數據庫大小的可擴展性，這樣可大幅度提高性能並可跨平台使用。

文件地理數據庫非常適合處理用於 GIS 投影的基於文件的數據集，非常適合個人使用以及在小型工作組中使用。它具有很高的性能，在不需要使用 DBMS 的情況下能夠進行很好的擴展以存儲大量數據。另外，還可跨多個操作系統對其進行移植。

目前，支持 geodatabase 的含有空間類型的 DBMS，如下所示：

使用 ST_Geometry 或 Oracle Spatial 類型（可選）的 Oracle
使用 Spatial Extender 幾何對象的 IBM DB2
使用 Spatial DataBlade 幾何對象的 Informix
使用 ST_Geometry 或 PostGIS 幾何的 PostgreSQL
使用 Microsoft 空間類型、幾何和地理的 Microsoft SQL Server

有關各 DBMS 中的地理數據庫所使用的存儲模式的詳細信息，請參閱地理數據庫怎樣存儲在 DBMS 中？

E-R 圖

https://www.cnblogs.com/arxive/p/9669041.html

https://zhuanlan.zhihu.com/p/29029129

https://www.visual-paradigm.com/cn/guide/data-modeling/what-is-entity-relationship-diagram 我覺得這個軟件的網頁文檔里面的說明是相當清楚的這節內容基本來源於此

數據庫是軟件系統中不可或缺的一個組成部分，若能在數據庫工程中好好利用 ER 圖，便能生成高質量的數據庫設計，用於數據庫創建，管理和維護

實體關系圖也被稱為 ERD、ER 圖、實體聯系模型、實體聯系模式圖或 ER 模型，是一種用於數據庫設計的結構圖。一幅 ERD 包含不同的符號和連接符，用於顯示兩個重要的資訊：

系統范圍內的主要實體，以及這些實體之間的相互關系。這也就是為什么它被稱為“實體”“關系”圖（ERD）

當我們談論 ERD 中的實體時，我們經常提到諸如人員/角色（例如學生），有形商業對象（例如產品），無形商業對象（例如日志）等業務對象。“關系”則是這些實體在系統內的相互關聯。

ERD 符號指南

ER 圖包含實體，屬性和關系。

實體

ERD 實體是一個系統內可定義的事物或概念，如人/角色（例如學生），對象（例如發票），概念（例如簡介）或事件（例如交易）（注：在 ERD 中，術語“實體”通常用來代替“表”，但它們是一樣的）。

考慮實體時，嘗試把它們想成名詞。在 ER 模型中，實體顯示為圓角矩形，其名稱位於上方，其屬性列在實體形狀的主體中。

ER的實體還會細分為弱實體和復合實體：

弱實體：一個實體必須依賴於另一個實體存在，那么前者是弱實體，后者是強實體，弱實體必須依賴強實體存在，例如學生實體和成績單實體，成績單依賴於學生實體而存在，因此學生是強實體，而成績單是弱實體。

弱實體和強實體的聯系必然只有1：N或者1：1，這是由於弱實體完全依賴於強實體，強實體不存在，那么弱實體就不存在，因此弱實體（雙線矩形）與聯系之間的聯系也是用的雙線菱形。

復合實體：復合實體也稱聯合實體或橋接實體，常常用於實現兩個或多個實體間的M：N聯系，用長方體內加一個菱形來表示。

用戶和商品兩個實體是M：N的關系，中間又訂單這個實體聯系，因此訂單這個實體是一個復合實體，同時如果用戶實體不存在，就沒有訂單實體的存在，因此對於用戶實體來講訂單是弱實體，同理商品實體如果不存在，同樣不存在訂單實體，因此對商品實體而言訂單是弱實體，具體如圖：

https://zh.wikipedia.org/wiki/ER%E6%A8%A1%E5%9E%8B

實體屬性

也稱為列 (Column)，意思是持有它的實體的屬性或特性。

一個屬性有一個描述屬性的名稱和一個描述屬性種類的類型，例如代表字符串的 varchar，整數的 int。當為物理數據庫開發繪制 ERD 時，得使用目標 RDBMS 支持的類型，以確保設計和物理數據庫的一致性。

下面的 ER 圖示例顯示了一個包含屬性的實體。

主鍵 (Primary Key)

主鍵又稱 PK，是一種特殊的實體屬性，用於界定數據庫表中的記錄的獨特性。一個表不能有兩筆（或更多）擁有相同的主鍵屬性值的記錄，像是身份證明內的 ID 便是典型的例子，兩個人即使性名相同，ID 是不會一樣，若身份證明是個表，那ID 便是主鍵了。

外鍵 (Foreign Key)

外鍵又稱外來鍵和外部鍵，是對主鍵的引用，用於識別實體之間的關系。請注意，有別於主鍵，外鍵不必是唯一的，多個記錄可以共享相同的值。下面的 ER Diagram 示例顯示了一個包含一些列的實體，其中一個外鍵用於引用另一個實體。

關系

兩個實體之間的關系表示這兩個實體以某種方式相互關聯。例如，學生可能參加課程。實體“學生”因此與“課程”相關，而這關系則在 ER 圖中以連接線表達着。

基數 (Cardinality)

基數定義了一個實與另一個實體的關系里面，某方可能出現次數。例如，一個團隊有許多球員，若把這關系呈現於 ERD 時，團隊和球員之間是一對多的關系。

在 ER 圖中，基數表示為連接線端的烏鴉腳。三種常見的主要關系是一對一，一對多和多對多。

一對一

一對多

一對多關系是指兩個實體 X 和 Y 之間的關系，其中 X 的一個實例可以鏈接到Y的許多實例，而 Y 的一個實例僅鏈接到 X 的一個實例。

多對多

多對多關系是指兩個實體 X 和 Y 之間的關系，其中 X 可以被鏈接到 Y 的許多實例，反之亦然。

請注意，多對多關系在物理 ERD 中被分成一對一對多的關系。

概念，邏輯和物理數據模型

ER 模型通常被繪制成最多三個抽象層次上：

雖然 ER 模型的三個層次都包含有屬性和關系的實體，但它們的創建目的和目標受眾都不同。

一般而言，業務分析人員使用概念和邏輯模型來展示系統中存在的業務對象 (Business Object)，而數據庫設計人員或數據庫工程師會為概念和邏輯ER模型加入更詳細的資訊，進而生成反映物理模型結構的物理數據模型，好為創建數據庫作準備。下表列出了三種數據模型之間的差異。

概念模型 vs 邏輯模型 vs 數據模型：

ERD功能	概念	邏輯	物理
實體(名稱)	是	是	是
關系	是	是	是
列		是	是
列的類型		隨意	是
主鍵			是
外鍵			是

概念數據模型

概念性 ERD 表達了系統中該存在的業務對象以及它們之間的關系。建立概念模型，是為了通過識別所涉及的業務對象來呈現系統的宏觀圖像。概念數據模型定義了哪些實體存在，而非哪些表。例如，邏輯或物理數據模型中可能存在“多對多”表，但在概念數據模型下，它們只會表示為無基數的關系。

概念數據模型示例

注意：概念性 ERD 支持使用泛化 (Generalization) 來表達兩個實體之間的“一種”關系，例如三角形是一種形狀，這個用法就像UML中的泛化一樣。請注意只有概念 ERD 支持泛化。

邏輯數據模型

邏輯 ERD 是概念 ERD 的詳細版本，通過明確定義每個實體中的列並引入操作和事務實體 (Transactional Entities)來讓概念模型豐富起來。雖然邏輯數據模型仍流於高層次的設計(非為特定數據庫系統而繪畫)，但如果會影響數據庫的設計，在繪制邏輯數據模型時仍然可酌情調整。

邏輯數據模型示例

用戶下的訂單有多個商品，一個商品又可以出現在多個用戶訂單中，多對多！

物理數據模型

物理 ERD 是數據庫的實際設計藍圖。物理數據模型通過為每列指定類型 (Type)，長度 (Length)，可為空 (Nullable) 等來詳細闡述邏輯數據模型。由於物理 ERD 表達了如何在特定的 DBMS中構造和關聯數據，因此在設計時要考慮到實際的數據庫系統的需要和局限，倒如確保 DBMS 支持某列類型，並在命名實體和列中避用某些保留字 (Reserved Words)。

物理數據模型示例

通過一對"一對多"的關系來表示多對多，名字不能有空格，這個關系真的很清楚啊

如何繪制 ER 圖？

如果您發現繪制 ER 圖很難，請不要擔心，在本節中我們將給你一些 ERD 提示。嘗試按照以下步驟以了解如何有效地繪制 ER 圖吧。

確保你清楚知道繪制 ERD 的目的。您是否試圖呈現涉及業務對象定義的整體系統架構？或者你正在開發一個准備用於數據庫創建的 ER 模型？您必須明了開發 ER 圖的目的，方可使用合適的模型層次（概念/邏輯和物理）來迎合您所需
確保你清楚模型的范圍。了解建模范圍可以防止在設計中包含冗余實體和關系。
畫出范圍內的主要實體。
通過添加列來定義實體的屬性。
仔細檢查 ERD 並檢查實體和列是否足以存儲系統的數據。如果不是，請考慮添加其他實體和列。通常，您可以在此步驟中確定一些事務 (Transactional)，操作 (Operational) 和事件 (Event) 實體。
考慮所有實體之間的關系，將它們聯系起來，並寫上正確的基數（例如客戶和訂單之間的一對多關系）。如果有任何實體沒有被連接上，請不要擔心，雖然這不常見，但它是合法的。
使用數據庫規范化技術 (Database Normalization)重構實體，以減少冗余數據和提高數據完整性。例如，“制造商”的資訊可能最初存儲在“產品”實體下，透過規范化過程，您可能會發“制造商”的記錄不斷重復，您便可將其拆分為單獨的“制造商”實體，並使用外鍵將“產品”和“制造商”連接起來。（如果有些數據總是重復那么可以考慮新建實體了）