数据和商业智能术语表

A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
V
W
X

架构

什么是模式?

模式 是定义数据集组织的设计或结构:哪些列被分组到表中,这些表如何相互关联,以及定义这些列的规则和数据类型。

模式是一个多义词;它是一个抽象的词汇,已经积累了很多不同的定义,因此可能很难理解。根据上下文,模式可以表示

  1. 您数据库的整体结构、规范或“蓝图”
  2. 一个展示您数据库中表之间如何相互关联的图表
  3. 您数据库中的单个表集合(众多集合之一)

最后,模式有时意味着您所使用的数据库平台特定的含义,例如在Oracle中,模式指的是由同一用户在数据库中创建的所有对象。

作为整体结构的模式:设计和实现

一旦您从高层次上确定了您的数据如何组合(即,您的概念性 数据模型),下一步就是创建一个反映该数据模型的模式,将抽象变为组织可使用并填充信息的数据库。

从广义上讲,这个过程由两个主要步骤组成

  1. 设计:绘制数据库的结构,在这个过程中创建一个实体关系图(ERD)。
  2. 实现:使用该ERD生成SQL命令,当在您的数据库中运行时,将创建您所需的模式。

您的模式设计过程看起来像什么取决于您是否处理 事务性或分析数据库,以及您是从头开始还是已经开始收集数据。无论您在设计模式时处于哪个阶段,您都必须深入思考您组织的需要和您预期要问的数据问题。

写入模式与读取模式

大多数传统的关系型数据库采用写入模式,即数据在写入数据库之前需要经过验证和格式化为模式。由于写入的数据必须符合您所建立的特定数据完整性规则(例如,要求字段中的所有值都是唯一的,字段中不接受空值,或以特定方式格式化日期),因此将新数据添加到数据库中可能会很慢。然而,读取速度很快,因为这些数据已经过验证。

在读取模式系统中,数据(如在数据湖中)仅在读取或从该数据库中提取后才会进行验证。读取模式系统通常更灵活,因为您可以在不担心其是否符合严格的数据模型的情况下存储非结构化数据。在这种情况下,写入数据更快(因为数据在加载时不需进行验证),但查询执行时间会更长。

您选择写入模式或读取模式策略将取决于您的组织需求和特定用例。如果您组织对精心结构化和一致的数据集非常重要,写入模式系统可能是您的最佳选择。相比之下,如果您经常需要拉取各种数据,而不总是知道这些数据的具体样子,您可能想使用读取模式系统。

逻辑模式和物理模式

无论您是在处理写入模式或读取模式系统,您还需要考虑数据库结构及其实现——即您的逻辑模式和物理模式。逻辑模式定义了您数据的结构,而该结构的实际实现(如您存储组成数据库的文件和代码的方式)属于物理模式。

逻辑模式

逻辑模式是通过绘制表及其字段之间的关系创建的。在创建逻辑模式时,您将建立表、关系、字段和视图,回答以下问题:

  • 我们正在收集什么数据,或者我们希望收集什么数据?
  • 您的数据库(或其中单个模式)需要哪些表?
  • 这些表是如何相互关联的?
  • 每个表需要哪些字段?
  • 每个字段的类型是什么?
  • 哪些字段是必需的?

模式作为图:映射实体和关系

在回答这些问题和其他问题时,您可能会绘制一个定义每个表、其字段、其完整性约束以及这些表之间关系的实体关系图(ERD),包括建立这些连接的主键外键以及这些表之间的关系是一对一、一对多还是多对一。可视化您的表及其相互关系也可以揭示任何重大遗漏或冲突。是的,有时这些图本身也被称为模式。

下面的图像显示了包含两个表(PRODUCTSMANUFACTURER)的模式的实体关系图。"(PK)"和"(FK)"注释告诉我们哪些字段是主键和外键,并且连接这些表的线条表明这是一种一对多关系,即一个制造商可以链接到许多产品。

<em>Fig. 2</em>. An entity relationship diagram of a schema with two tables.
图2。包含两个表的模式的实体关系图。

您可以在纸上或使用能够直接将您的图转换为实现数据库所需的SQL命令的设计软件中规划您的模式。此时,您的模式是平台无关的;规划这些规则和关系并不将您绑定到任何单一的数据库软件。

物理模式

一旦您确定了数据库的逻辑配置,您将创建一个物理模式以将其实现到特定的关系数据库管理系统(RDBMS)中,并定义您的数据库文件将存储的位置以及它们在磁盘上的存储分配。

模式作为众多表中的一个集合

如果您的数据库只看到少数用户并且包含所有人需要访问的数据,单个表的集合可能就足够了。但是,如果您在许多表中处理数据(想想几十、几百或几千),将那些表分组到单独的模式中将有助于组织,这样您就可以将类似的信息存储在一起,同时仍然能够在必要时跨模式查询。

在安全方面,将多个模式存储在数据库中也可能是有帮助的,例如,将包含敏感信息的表分离到一个只有需要的人才能访问的模式中,通常与视图结合使用。

事务数据库与分析数据库的方案设计

当考虑事务数据库(也称为操作数据库)的方案时,您的数据需要在某种程度上进行归一化,并遵守数据完整性标准,因为对于那些小事务和OLTP来说,效率和性能至关重要。

分析数据库设计方案将有所不同。首先,您可能已经收集了原始数据,可能来自多个来源,现在需要施加一些结构以进行分析。在这种情况下,冗余是可以接受的,因为分析数据库更重视可探索性而不是性能。在这里,您的方案也可以更加宽松地定义,因为没有固定模式(如归一化)是必需的。分析数据库的方案设计更多的是了解您各种来源的数据存储在哪里,以及您需要将哪些表连接起来以回答您的问题。

星型模式

在分析数据库中经常应用的一种常见结构是星型模式,它将数据分为事实表(即定量数据)和多个描述这些事实的维度表。在星型模式的一个简单实现中,几个维度表都围绕着并与一个单独的事实表相关联,形成一个星形图,其中事实表位于中心,如下所示

<em>Fig. 2</em>. An entity relationship diagram of a simple star schema.
图2. 一个简单星型模式的实体关系图。

星型模式中的表通常是反归一化的,这有助于提高分析查询的性能。

创建数据库方案

大多数数据库平台(如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 SCHEMACREATE DATABASE是同义的。

相关术语

更多阅读