【数据库建模】什么是数据库模式？

应用程序的数据库模式对其功能、性能和成功至关重要。事实上，这几乎决定了你完成的应用程序工作的各个方面。

因此，在构建任何类型的工具时，了解如何创建有效的模式都至关重要。

在本指南中，我们将介绍您需要了解的所有内容。我们将从基础知识开始，包括模式所包含的内容，然后再讨论在使用不同类型的数据库时需要了解的更具体的细节。

最后，我们将看看低代码开发是如何改变这里的平衡的。

首先，让我们看看一些定义。

什么是数据库模式？

数据库模式是数据组织和结构方式的蓝图。换句话说，这是一组可以存储什么数据的规则，以及存储方式和位置。请注意，这与数据库将存储的实际值不同。

创建模式意味着映射出数据库将存储的值、它们之间的关系以及管理它们的规则。

换句话说，模式是数据的空白画布。稍后，您可以开始用实际值填充此值。

目标是构建一个与您完成的应用程序需求紧密匹配的框架。然后，您可以将其用作业务流程层和用户界面的基础。

为什么需要数据库的模式？

在构建应用程序时，通常应该先开发一个健壮的数据库模式，然后再进行其他任何操作。

这样做的一个原因是确保您收集和存储的数据与应用程序正常运行所需的数据相匹配。例如，在格式、特异性和一致性方面。

还有一个问题是确保系统之间的互操作性。也就是说，如果您正在构建一个要与其他工具集成的应用程序，这将是数据库模式设计中的一个因素。

如果从一开始就知道这是一项要求，那么应该将这一事实构建到架构中，包括通过选择数据类型和格式。

最后，您的模式对于任何将在您的应用程序项目上工作的开发人员来说都是一种路线图。在构建流程、用户界面和自动化规则时，有一个清晰的应用程序数据蓝图至关重要。

你的模式应该包括什么？

但是数据库模式包含哪些特定信息？记住，这个想法是概述您将存储的数据、应用于不同值的规则以及不同变量之间的相互关系。

考虑到这一点，下面是有效数据库模式的更具体内容。

表

数据库是将数据组织到一个或多个表中的一种方式。它们由行和列组成。

注意，这在NoSQL数据库中的工作方式有点不同。稍后我们将进一步探讨这个问题。目前，我们假设您使用的是关系型DBMS，因为它们更常见。

创建模式时要做的第一件事是概述数据库表。

每个表应代表一个实体。列表示此实体可以具有的不同属性，而行表示单个实例。例如，假设您在公司目录应用程序中为所有员工设置了一个表。

这些列将由您希望存储的每个员工的所有信息组成，如他们的姓名、工作、地址和电话号码。然后，表中的行用于为团队的特定成员填充此信息。

表在数据库中也必须具有唯一的名称。这是一段元数据，允许我们在从应用程序的其他元素进行查询时引用每个特定的表。

在我们的公司目录应用程序中，我们可以将员工称为表employees或employee_details。

根据需要，您可以选择在模式中包含一个表。通常，这种模式将用于非常简单的应用程序。通常，您会有几个相关的表。

稍后再详细介绍。

字段和属性

我们知道，每个表的列表示实体可以具有的不同属性。这些也被称为字段。模式的一个关键部分是详细概述这些内容。在这里，您将充实您要存储的更具体的数据。

当然，这其中的第一个元素是定义需要针对每个实体存储的属性。你的应用程序要求是一个很好的起点。

换句话说，你的应用程序需要什么数据才能运行？用户和系统流程需要了解每个实体的哪些信息？

让我们以我们公司的目录应用程序为例。

至少，我们可能会决定需要两张桌子才能工作。我们将调用这些employee_details和user_details。正如您可能已经猜到的，这些将分别代表我们的员工和用户。

现在，我们可以充实并命名要存储在每个表中的属性。

因此，对于employee_details，我们的属性名称可能是：

• first_name,
• last_name,
• email_address,
• phone_number,
• department,
• job_role,
• date_of_birth,
• join_date,
• unique_id.

对于user_details，我们可以存储：

• name,
• email_address,
• access_level,
• unique_id,
• Any required authentication details.

 

这里需要记住的一点是，我们不能在一个表中有两个同名的属性。这将使查询值变得令人难以置信的混乱，因此您的数据库管理系统（DBMS）不允许这样做。

对于表中的每一行，我们还需要至少有一个属性是唯一的。这里的想法是一样的。我们需要一些区分行的方法，以便在查询中引用它们。

您可以使用从业务需求中派生的属性之一来完成此操作。然而，这会产生问题，因为它阻止我们为该列拥有多个具有相同值的行。

例如，你可以很容易地让两个约翰·史密斯在你的会计团队工作。

更好的选择是为每个表创建唯一的ID属性。这通常是系统生成的变量，用于引用特定行。对此有一些不同的标准，但它们都有相同的目标。

也就是说，为我们提供了一种完全独特的方式来引用表中的任何给定行。

数据类型

一旦我们知道了我们需要存储的属性以及我们想要调用它们，我们还需要定义它们将存储的值的类型。例如，它们存储的是数值还是基于文本的值？

这称为属性的类型。

不同的数据库标准和应用程序构建工具将提供略有不同的选项。通常，可以分配给每个属性的数据类型为：

• 字符串-基于文本的变量。
• 数字-整数或十进制数字。
• 日期/时间-时间数据。
• 数组-按设置顺序排列的值列表。
• 枚举器-定义的选项。
• 布尔值-真/假数据。
• 公式-基于应用于其他值的定义规则的输出。
• 唯一ID-用于在DBMS中创建唯一标识符的定义系统，例如UUID或GUID格式。

使用一些工具，如BudibaseDB，您将能够使用其他数据类型，如文件附件、关系或长格式文本字段。

因此，如果我们将此应用于为employee_details表标识的属性，我们将得到如下结果：

• first_name: string,
• last_name: string,
• email_address: string,
• phone_number: string,
• department: enumerator,
• job_role: string,
• date_of_birth: date,
• join_date: string,
• unique_id: unique ID.

规则

一旦我们为每个属性定义了数据类型，就应该开始考虑我们想要管理这些属性的任何规则了。

您可以实施的一些最重要的规则包括：

• 应如何格式化值。
• 默认值。
• 是否需要属性。
• 属性是否可以复制或必须是实例的唯一属性。

因此，例如，我们可以规定电话号码必须是特定数量的字符，以确保值的有效性。或者，我们可以将所有employee_details属性都设置为强制属性，但date_of_bornth除外，这样员工就可以对自己的年龄保密。

您还可以将规则应用于不同数据类型的特定格式。例如，某些数值可能需要为整数，而其他数值可能设置为固定的小数位数。

您还需要为任何日期属性指定格式，以确保整个数据库的一致性。

关系

数据库模式的一个关键部分是定义不同属性和值之间的关系。注意，并非所有数据库标准都提供不同数据之间的关系。

例如，关系是SQL数据库的核心功能，但其他工具不支持它们。其他人支持一种形式的关系数据，但对它的处理略有不同。同样，我们将在讨论NoSQL数据库时更详细地了解这一点。

目前，关系是如何定义不同实体之间交互的方式。换句话说，它们允许我们在不同表的行之间创建链接。

在两个表之间，我们可以实现三种不同的关系：

• 一对一关系-第一个表中的每一行都可以与第二个表中一行相关。
• 一对多关系-第一个表中的每一行都可以与第二个表中多行相关。
• 多对多关系-每个表中的几行可以相互关联。

其中每一项在不同的环境中都很有用。在我们的公司目录示例中，我们可能使用一对一关系，因此每个用户都链接到相应的employee_details条目。

如果我们有第三个表，例如department_details，我们可能会使用一对多关系，将每个部门连接到employee_details表中所有相应的团队成员。

View

视图是由存储的查询创建的数据库的定义子集。这是在模式中预定义的，因此用户和系统进程可以以与独立数据库基本相同的方式查询它。

这允许您限制不同用户或进程对基础数据库的暴露程度。

视图提供了许多好处，包括允许您：

• 限制对不同数据的访问。
• 创建虚拟表，简化或连接不同的实体。
• 返回聚合值，如总和、平均值和计数。
• 创建虚拟表以按不同属性进行排序或筛选，例如，各个年份的销售数据。

由于视图是由存储的查询创建的，因此可以将它们配置为只读或可更新。这是确保基础数据安全性和完整性的一种有用方法。

因此，我们可能有一个主数据库，存储我们所有的销售线索。然后，我们可以根据每个条目的员工数量，使用两个视图为企业和SMB创建虚拟表。

存储过程

对于某些数据库标准（包括SQL），模式还可以包括存储过程。这些是可以应用于应用程序其他地方的不同值的代码集。

这有点像使用一组SQL语句定义函数。关键的好处是您可以创建一次过程，并使用它反复执行相同的任务。这消除了在其他地方再次手动编码的需要。

您只需在查询中调用存储过程即可。

这也为整个应用程序提供了性能优势。

例如，我们的公司目录示例存储每个员工的出生日期。我们可能希望在数据库模式中创建一个存储过程，以基于此计算它们的当前年龄。

然后，我们可以在应用程序的界面上以各种方式使用它，而无需存储新属性或多次计算。

主键和外键

在关系数据库（如SQL）中，您将遇到术语主键和外键。这些属性用于定义实体之间的关系。这可以是现有属性，也可以是为此特定目的创建的属性。

通常这是行的唯一ID。有时，您可以使用不同的属性，以提高数据库用户的可读性。

主键是表中用于标识特定行的属性。为了避免混淆，这必须是唯一的值。它也不能为空。

外键是一个表用来引用另一个表中特定行的属性。该值与行自身表中的主键相同。这不一定是唯一的，例如在一对多或多对多关系的情况下。

外键也可以为空，其中特定行在其他表中没有任何关系。

每个表只能有一个主键属性，但可以有多个外键，以允许与多个表建立关系。

在我们的公司目录中，employee_details中的每一行都有一个主键，但它可能有两个不同的属性，用于存储department_details和user_details表中相关行的外键。

数据库模式的类型

现在我们知道了什么是数据库模式以及它包含的内容，我们可以开始考虑创建自己的模式。

第一部分是理解不同类型的模式，它们如何结合在一起，以及不同利益相关者如何使用它们。

我们可以将其分为三层：

• 概念的
• 逻辑的
• 概念的

它们的技术性或抽象性各不相同。每一项都对应用程序项目中的不同利益相关者有用。

让我们依次看看他们中的每一个。

概念架构

概念数据库模式是应用程序满足其核心需求所需数据的抽象概述。请注意，这主要集中于您的业务信息需求，而不是数据库的实际底层结构。

这通常是创建模式的第一阶段。它主要是为了非技术利益相关者的利益而创建的。

在这个级别上，我们可以简单地定义所需的实体、每个实体将包含的属性以及它们之间关系的概述。

在这个阶段，我们不需要关心我们将如何格式化和存储数据的细节，甚至不必担心我们将如何操作不同的变量。

例如，如果我们想创建一个电子商务商店，在概念层面，我们可能会决定需要四个不同的实体：

• 产品。
• 订单。
• 客户。
• 用户。

然后我们可以列出我们希望这些实体的每个实例都具有的基本属性。

我们甚至可以确定它们之间的基本联系方式。例如，每个用户链接到一个客户，每个客户可以创建多个订单，每个订单可以包含多个产品等。

逻辑架构

接下来，我们可以在此基础上创建逻辑模式。这为我们的概念模式提供了更精细的技术细节。例如，我们将使用特定的键来创建实体之间的关系。

此时，我们可以开始将所需的实体和属性转换为更具体的表和列。顾名思义，逻辑数据库模式还概述了将应用于值的任何逻辑约束。

例如，我们可以概述我们想要管理不同属性的任何规则，至少是抽象的。

这里的目标是创建一个技术概要，说明我们的数据库应该如何构造，而不考虑我们最终使用的特定DBMS。

物理架构

最后，物理模式是我们数据库的具体技术设计。其中很大一部分是将逻辑模式转换为更详细的模型，以满足所选DBMS的特定需求。

这包括创建和命名所有表、属性和键，以及验证规则、触发器、存储过程和完整性约束。我们还将实现在数据库模式的前几个级别中概述的关系。

物理模式还包括存储数据的方式和位置的技术细节，包括索引、路径和域。

创建物理模式通常与创建数据库本身同义。

也就是说，一旦这个过程完成，我们实际上就有了一个可以填充的完整数据库。

数据库模式设计和模型

正如我们所知，模式是数据库结构的概要。然而，有许多不同的方法来构造数据库。这就是所谓的数据库模式设计。

模式设计的选择很大程度上取决于应用程序的需求。

幸运的是，这里有一些我们可以依赖的常见模型。让我们来看看创建现代应用程序最重要的方法，以及用于可视化表示的模式图。

平的

平面模型是最基本的数据库模式，由一个表组成。本质上，这只不过是一个CSV文件或电子表格。有时，这是简单应用程序所需的全部内容，比如注册工具。

显然，这有一定的局限性。最值得注意的是，您不能用一个表来定义实体之间的关系。事实上，您实际上只有一个实体可以使用。

然而，平面数据库模式提供的简单程度也有一些关键好处。其中包括易用性、低成本和普遍缺乏复杂性。

平面模式通常用于简单的单功能内部工具。例如，在线回拨表单。

关系

关系数据库模式在现代应用程序中无处不在。正如我们已经看到的，在不同实体之间建立关系是许多应用程序项目功能的基础。

正如我们前面提到的，这意味着为不同的实体创建表，并使用主键和外键在它们之间创建不同类型的关系。

这会带来很大程度的复杂性，因为每个实体可能与其他几个表有不同的关系。

然而，关系数据库也提供了高度的灵活性。例如，对于每个表与其他表的关系，有一个很大的范围来建立自己的复杂设计。

关系模式还可以方便地查询复杂的相关数据。具体来说，可以查询相关表中的属性，而无需通过层次结构或基于目录的结构。

有无数种不同的方法可以使用关系模式组织实体。这使您能够灵活地创建适用于特定实体和业务需求的模式。

考虑到这一点，让我们来看看几个常见的变体。

明星

星形模式是关系模型的演变，它将实体划分为事实和相关维度。事实总是数字的，而维度是描述性的。

这个模型的名字来源于这样一个事实，即多个维度表从一个事实表分支出来，采用中心轮辐格式。

例如，我们可能有一个事实表来记录在线商店的销售额。然后，我们将使用从这个维度分支出来的维度表来记录更具体的属性项目、地点、销售人员、客户或其他重要实体。

销售表只需要包含售出的单位数，以及维度表中每一行的外键。

启动模型的简单性使其易于可视化和理解实体之间的关系。然而，它在灵活性方面是有限的，因为您无法创建更复杂的关系。

雪花

雪花模式本质上是星形模型上更复杂的变体。不同之处在于，在雪花数据库模式中，每个维度表还可以有其他维度从中分支出来。

因此，为了返回到前面的示例，我们可以添加从items表分支的其他维度。例如，保修信息、任何促销优惠的详细信息或其他相关产品的详细信息。

我们可以对任何维度进行同样的处理。

正如您可能已经猜到的那样，雪花模型之所以得名，是因为它的维度表分支类似雪花。

这提供了比星形模型更大的灵活性，同时保留了许多简单性。

不同数据库标准中的模式

前面我们说过，创建物理模式的一部分是将需求转换为符合DBMS惯例的具体结构。因此，了解常见数据库标准之间的差异很重要。

下面是一些模式如何在不同的DBMS中运行的示例。

SQL语言

在SQL数据库中，模式由无限数量的对象组成。这里的对象指的是表、视图、函数和索引。我们可以创建跨多个数据库使用的单一模式。

看看我们关于如何集成多个数据库的文章。

对象也可以在不同的模式之间传输。

我们可以使用CREATE schema命令在SQL中定义模式，为其命名，并在其中定义任何数据库对象。或者，SQL将database和schema视为同义词，因此我们也可以使用CREATE database。

还有许多其他参数与SQL模式相关。

其中包括：

• schema_title-模式的名称。
• 授权所有者-创建或当前拥有架构的用户。
• DEFAULT CHARACTER SET SET_name-指定模式中值使用的默认字符集。
• CREATE语句-任何必需的CREATE语句。
• GRANT语句-任何必需的GRANT语句。
• PATH schema_title-文件路径和名称（如果需要）。

注意，默认情况下，创建模式的用户将是其所有者。然后可以稍后将其传输给另一个用户。

Postgres

PostgresSQL是一个开源DBMS，旨在扩展SQL的功能，同时保持相同的基本查询语言。

然而，Postgres对待数据库模式有点不同。

Postgres模式是一个命名空间，包含数据库的所有存储对象。命名空间只是用于引用不同对象的名称的集合。这也有助于确保所有对象名称都是唯一的。

Postgres数据库可以有多个模式。但是，每个模式只能属于一个数据库。

在创建Postgres数据库时，默认情况下也会创建公共模式。此处可以找到任何未手动分配给架构的对象。

NoSQL

当涉及到NoSQL数据库时，事情就有点棘手了。事实上，关于这些是否需要模式存在争论。这是因为它们有所谓的动态模式。

也就是说，组织数据库的方式仍然有一个潜在的逻辑，但它更灵活。这意味着NoSQL数据库更容易修改，以响应业务需求或其包含的数据的变化。

然而，在开始创建应用程序之前，您仍然需要清楚地了解要存储的数据。

因此，您仍然需要彻底考虑应用程序满足其要求所需的不同实体和属性。使用NoSQL DBMS，我们不会在不同的表上存储不同实体的详细信息。

MongoDB是NoSQL DBMS的一个示例。

还有一种误解是NoSQL数据库无法处理关系。

这不是真的。他们只是对关系型DBMS做了一点不同。NoSQLDBMS允许您在单个对象中嵌套关系数据，而不是依赖于不同实体的多个表。

在许多情况下，这可以提高可伸缩性和查询速度，因为可以从一个实体而不是两个或更多实体中检索相同的信息。

数据库模式和低代码开发

正如我们在开始时所说的，创建数据库模式是构建应用程序的关键第一步。这会对应用程序的功能、性能、安全性和最终成功产生巨大影响。

但在低代码开发时代，数据库模式的作用是什么？

毕竟，低代码只是为了简化和加快开发过程。您还需要花费时间创建数据库架构吗？

当然，低代码会改变事情，但数据库模式仍然至关重要。

为了了解Budibase如何处理不同类型的数据，我们来看看它。

BudibaseDB数据库

BudibaseDB是我们的内置数据库。我们有偏见，但我们认为这是任何人为其应用程序项目建立数据库的最快方式。单击按钮即可添加表、创建属性和输入行。

我们的数据库支持广泛的直观数据类型，包括长格式文本、关系、公式和文件附件。

BudibaseDB还支持实体之间的关系，无需任何DBMS知识。分配一个显示列，并在几秒内创建复杂的关系。

我们的内置数据库还可以根据您的需要快速添加或更改属性和屏幕。构建一个初始数据库模式，并允许它随着应用程序需求的变化而变化。

通过CSV上传、自动生成的CRUD屏幕和自动更新的表单UI，Budibase是围绕完美数据库模式构建工具的快速、简单的方法。

连接到外部数据库

我们还为一系列外部数据库提供广泛的连接。您可以围绕SQL、Postgres、MongoDB、Airtable等构建Budibase应用程序。利用现有数据，或使用首选DBMS从头构建数据库架构。

Budibase为开发人员提供了为其特定应用程序创建完美数据层的能力。构建自己的深度数据库模式，或使用BudibaseDB在几秒内创建一个灵活、可扩展的数据库。

或者，使用我们的平台查询和管理现有数据集。

我们还为REST API和Google Sheets提供专用数据连接器。

看看我们的web应用程序项目数据源终极指南。

开始使用Budibase

我们的用户选择Budibase以实现快速、经济高效的构建和无与伦比的灵活性。在几分钟内构建数据层、创建专业UI并部署完成的应用程序。

使用BudibaseDB快速构建可适应的数据库模式或使用我们的一系列连接器查询永久数据库。

您可能还喜欢我们关于如何创建数据模型的指南。