一直以来对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)重构实体，以减少冗余数据和提高数据完整性。例如，“制造商”的資訊可能最初存储在“产品”实体下，透過规范化过程，您可能会发“制造商”的记录不断重复，您便可将其拆分为单独的“制造商”实体，并使用外键將“产品”和“制造商”連接起來。（如果有些数据总是重复 那么可以考虑新建实体了）
数据模型的例子
ERD 示例 - 贷款系统
E-R图的绘制类型
使用ERD和数据流图（DFD）
在系统分析和设计中，可以绘制数据流图（DFD） 来展现系统流程中的信息流。在数据流图中，有一个名为数据储存 (Data Store)的符号，它代表一个提供系统所需信息的数据库表。
数据流图（DFD）有效地表达了信息如何在系统内流动。使用 DFD，您可以识别由特定系统/过程范围内的特定实体或子过程提供和输出的信息，以及完成该过程所需的信息的种类和形式。
由于物理 ER 图提供了实际数据库的蓝图，因此这种 ERD 中的实体与 DFD 中的数据存储一致。您可以 ERD 作为 DFD 的补充，以表达信息的结构；或以 DFD 补充 ERD，以显示系统在运行时如何运用数据。
使用ERD和BPMN业务流程图（BPD）
在业务流程映射中 (Business Process Mapping)，可以绘制 BPMN 业务流程图 （BPD） 以展示业务工作流程。在业务流程图中，有一个称为数据对象（Data Object）的符号，表示在流程输入/输出的数据。
由于概念和逻辑数据模型提供了系统内业务对象的高级视图，因此此类 ERD 中的实体与 BPD 中的数据对象一致。您可绘制 ERD 作为 BPD 的补充，以表示业务工作流程所需的数据对象的结构；或以 BPD 補充 ERD，以显示在整个业务流程中如何運用数据。
https://www.visual-paradigm.com/cn/tutorials/ 推一个这个软件教程 感觉对软件开发会很有用
ArcGIS Desktop创建gdb
GDB的属性域能够限制数据的范围与类型 这样能减少错误
gdb中可以新建、导入、导出：
数据库表直观表示：
属性域操作
描述了字段的合法值规则，分为 范围和编码值
子类型
是要素类中具有相同属性的要素的子集，可用于进行数据分类，必须与长整型或者短整型的字段关联
创建地理数据库标记
关系类
注释类
几何网络
拓扑
版本
参考：
https://desktop.arcgis.com/zh-cn/arcmap/10.4/manage-data/geodatabases/types-of-geodatabases.htm
https://wenku.baidu.com/view/3d0cb04cfad6195f302ba64e.html