什么是模式？
一个**模式**是定义数据集组织的设计或结构：它规定了哪些列被分组到表中，这些表如何相互关联，以及定义这些列的规则和数据类型。
“模式”是一个被过度使用的术语；它是一个抽象词，累积了许多不同的定义，因此可能令人难以辨别。根据上下文，模式可能指
最后，“模式”有时指您正在使用的特定数据库平台中的概念，例如在Oracle中，“模式”指的是由同一用户创建的数据库中的所有对象。
模式作为整体结构：设计与实现
一旦您从高层次上弄清了数据如何协同工作（即您的概念性数据模型），下一步就是创建一个反映该数据模型的模式，将其从抽象概念转化为您的组织可以使用的、填充信息的数据库。
概括来说，此过程由两个主要步骤组成
- 设计：规划数据库结构，在此过程中创建实体关系图（ERD）。
- 实现：使用该ERD生成SQL命令，在数据库中运行这些命令即可创建所需的模式。
您的模式设计过程取决于您是处理事务型数据库还是分析型数据库，以及您是从头开始还是已经开始收集数据。无论在哪个阶段设计模式，您都必须深入思考组织的需求以及您预期会向数据提出的问题。
写入时模式 vs. 读取时模式
大多数传统关系型数据库使用**写入时模式**系统，即数据在写入数据库之前会经过验证并格式化为模式。由于要写入的数据必须符合您建立的任何特定数据完整性规则（例如要求字段中所有值唯一、不接受字段中的空值或以特定方式格式化日期），因此将新数据添加到数据库可能会很慢。然而，读取时间很快，因为数据已经过验证。
在**读取时模式**系统中，数据（例如在数据湖中）仅在读取或从该数据库中拉取后才进行验证。读取时模式系统通常更灵活，因为您可以存储非结构化数据而无需担心它符合严格的数据模型。在这种情况下，写入数据更快（因为数据在加载时无需验证），但查询执行需要更多时间。
选择写入时模式还是读取时模式策略将取决于您的组织需求和具体用例。如果拥有精心结构化且一致的数据集对您的组织很重要，那么写入时模式系统可能是您的最佳选择。相比之下，如果您需要定期引入各种数据，而又不总是确切知道这些数据是什么样子，您可能需要使用写入时模式系统。
逻辑模式和物理模式
无论您使用写入时模式还是读取时模式系统，您都需要考虑数据库结构及其实现——即您的逻辑模式和物理模式。逻辑模式定义数据的结构，而该结构的实际实现（例如您如何以及在哪里存储构成数据库的文件和代码）则属于物理模式。
逻辑模式
**逻辑模式**通过图示表及其字段如何相互关联来创建。在创建逻辑模式时，您将建立表、关系、字段和视图，回答诸如以下问题：
- 我们正在收集或想要收集哪些数据？
- 您的数据库（或其中的单个模式）需要哪些表？
- 这些表之间如何关联？
- 每个表需要哪些字段？
- 这些字段的每种数据类型是什么？
- 哪些字段是必填的？
模式作为图表：映射实体和关系
在回答这些及其他问题时，您很可能会勾勒出实体关系图 (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 同义。
