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