模式
什么是模式？
模式是定义数据集组织结构的设计或结构：哪些列被分组到表中，这些表如何相互关联，以及定义这些列的规则和数据类型。
模式是一个含义过多的术语；它是一个抽象的词，积累了许多不同的定义，因此可能会让人感到困惑。根据上下文，模式可能意味着
最后，模式有时意味着特定于您正在使用的数据库平台的内容，例如在 Oracle 中，模式指的是同一用户创建的数据库中的所有对象。
作为整体结构的模式：设计和实现
一旦您从高层次的角度弄清楚了数据是如何组合在一起的（即您的概念性 数据模型），下一步就是创建反映该数据模型的模式，将其从抽象概念带到您的组织可以使用并填充信息的数据库。
广义而言，此过程由两个主要步骤组成
- 设计：规划数据库的结构，在此过程中创建实体关系图 (ERD)。
- 实施：使用该 ERD 生成 SQL 命令，这些命令在数据库中运行时，将创建您所需的模式。
您的模式设计过程的外观取决于您处理的是 事务性数据库还是分析性数据库，以及您是从头开始还是已经开始收集数据。无论您在哪个时间点设计模式，您都必须深入思考组织的需求以及您预计会提出的数据问题。
写入时模式与读取时模式
大多数传统的 关系数据库 使用写入时模式系统，其中数据在写入数据库之前经过验证并格式化为模式。由于正在写入的数据必须符合您已建立的任何特定数据完整性规则（例如，要求字段中的所有值都是唯一的，不接受字段中的空值，或以某种方式格式化日期），因此将此新数据添加到数据库可能会很慢。但是，读取时间很快，因为数据已经过验证。
在读取时模式系统中，数据（如 数据湖 中）仅在读取或从数据库中提取后才进行验证。读取时模式系统往往更灵活，因为您可以存储非结构化数据，而无需担心它是否符合严格的数据模型。在这种情况下，写入数据更快（因为数据在加载时不需要验证），但查询需要更多时间来执行。
您选择写入时模式还是读取时模式策略将取决于您组织的需求和特定用例。如果拥有结构化且一致的数据集对您的组织很重要，那么写入时模式系统可能是您的最佳选择。相比之下，如果您经常需要提取各种各样的数据，但并不总是确切知道数据是什么样的，您可能需要使用读取时模式系统。
逻辑模式和物理模式
无论您使用的是写入时模式还是读取时模式系统，您还需要考虑数据库结构及其实现——即您的逻辑模式和物理模式。逻辑模式定义数据的结构，而该结构的实际实现（例如，您如何以及在何处存储构成数据库的文件和代码）属于物理模式。
逻辑模式
逻辑模式是通过图解表及其字段如何相互关联来创建的。在创建逻辑模式时，您将建立表、关系、字段和视图，回答如下问题：
- 我们正在收集哪些数据，或者我们想要收集哪些数据？
- 您的数据库（或其中的单个模式）需要哪些表？
- 这些表如何相互关联？
- 每个表需要哪些字段？
- 这些字段的数据类型是什么？
- 哪些字段是必需的？
作为图表的模式：映射实体和关系
在回答这些问题和其他问题时，您可能会草拟一个 实体关系图 (ERD)，该图定义了每个表、其字段、它们的完整性约束以及这些表之间的关系，包括建立这些连接的 主键 和 外键，以及表之间的关系是一对一、一对多还是多对一。可视化您的表以及它们如何相互关联还可以揭示任何主要的遗漏或冲突。是的，有时您会看到这些图表本身被称为模式。
下图显示了一个模式的实体关系图，其中包含两个表：PRODUCTS 和 MANUFACTURER。“(PK)”和“(FK)”表示法告诉我们哪些字段是主键和外键，连接这些表的线表示一对多关系，即一个制造商可以链接到多个产品。
您可以在纸上或使用设计软件绘制模式图，该软件可以将您的图表直接转换为实现数据库所需的 SQL 命令。此时，您的模式是平台无关的；绘制这些规则和关系不会将您绑定到任何单个数据库软件。
物理模式
确定数据库的逻辑配置后，您将创建一个 物理模式 以将其实现到特定的 RDBMS 中，定义数据库文件将驻留在何处以及它们在磁盘上的存储分配。
作为众多表集合之一的模式
如果您的数据库仅有少量用户并且包含每个人都需要访问的数据，则单个表集合可能就足够了，但您可能会发现，在数据库中依赖单个模式无法满足您的组织的需求。如果您正在处理大量表（想想几十个、数百个或数千个），将这些表分组到单独的模式中将有助于从组织的角度出发，使您可以将类似的信息存储在一起，同时在必要时保留跨模式查询的能力。
在数据库中保留多个模式从安全角度来看也可能很有用，例如将保存敏感信息的表分隔到只有需要访问的人员才能访问的模式中，通常与 视图 结合使用。
事务性数据库与分析性数据库的模式设计
在考虑 事务性数据库（也称为操作数据库）的模式时，您的数据将需要进行一定程度的规范化并遵守数据完整性标准，因为这些小型事务和 OLTP 的效率和性能至关重要。
为 分析性数据库 设计模式看起来会有所不同。首先，您可能已经收集了原始数据，可能来自多个来源，现在需要施加一些结构才能对其进行分析。在这种情况下，冗余是可以接受的，因为分析性数据库更强调可探索性，而较少强调性能。在这里，您的模式也可以定义得更宽松，因为不需要固定的模式（如 规范化）。分析性数据库的模式设计更多地是关于了解来自各种来源的数据位于何处，并了解您需要连接哪些表来回答您的问题。
星型模式
您将看到的应用于分析性数据库的一种常见结构是 星型模式，它将数据分为事实表（即定量数据），这些事实表与描述这些事实的多个 维度 表相关。在星型模式的简单实现中，多个维度表都围绕着单个事实表并与之相关，在图表形式中看起来像一颗星，事实表位于其中心，如下所示
星型模式中的表通常是非规范化的，这可以为分析查询带来更好的性能。
创建数据库模式
大多数数据库平台（如 Redshift 和 PostgreSQL）使用“模式”来表示数据集的配置以及该数据集内表和其他命名对象的非嵌套分组，尽管 Oracle 将模式定义为单个数据库用户创建和拥有的所有对象。
要在 RDBMS 中创建模式，请使用查询 CREATE SCHEMA，如下例所示，我们在其中创建一个模式，其中包含两个由 customer_id 字段链接的表
CREATE SCHEMA new_schema;
CREATE TABLE new_schema.orders (
order_id
product_id
customer_id
subtotal
order_date
)
CREATE TABLE new_schema.customers (
customer_id
customer_name
customer_address
customer_email
);
这是一个非常简单的模式；我们没有指定数据类型或表字段上的任何其他约束。如果我们想在 customers 表中要求 customer_id 字段并指示其数据类型为整数，我们将像这样格式化该字段
customer_id INT NOT NULL
请注意，在 MySQL 中，CREATE SCHEMA 与 CREATE DATABASE 同义。
