ArcGIS地理数据库Geodatabase

一直以来对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)重构实体，以减少冗余数据和提高数据完整性。例如，“制造商”的資訊可能最初存储在“产品”实体下，透過规范化过程，您可能会发“制造商”的记录不断重复，您便可将其拆分为单独的“制造商”实体，并使用外键將“产品”和“制造商”連接起來。（如果有些数据总是重复那么可以考虑新建实体了）