如何定义基于标签的组织结构？

Question

[原标题：有没有办法在基于标签的组织方法上强制建立关系结构？]

我有一些实体，它们有一系列属性。一些属性影响实体可以具有的其他属性，许多属性被组织成组，并且有时实体被要求具有来自某些组的一定数量的属性，或者可能具有来自某些组的一定范围的属性。

有没有办法对这些类型的标签到标签关系进行建模，例如需求、分组、排除等。使用数据库，或者这只能通过编程的“业务规则”来实现？理想情况下，我希望可能的标签及其关系易于配置，因此高度灵活。

我考虑的方法之一是拥有标签和可能的关系，然后你会得到一个应用标签-标签的关系类型的表，但这似乎是一种相当脆弱的方法。

那么，这是否可以以更严格的方式实现？如果可以，我将如何开始呢？

Answer 1

编辑：仅根据其他属性中的值应用的变量属性描述是非关系型非规范化设计。 RDBMS可能不是存储此类数据的最佳解决方案。对于需要这种灵活性的数据，RDF可能是一个很好的解决方案。

我之前的答案，与RDBMS解决方案有关，如下：

---

有些人使用实体 - 属性 - 值设计对灵活属性进行建模，但这往往是非结构化的，你最终会遇到数据完整性问题。仅当您需要几乎无限数量的实体子类型时才使用此选项。

其他人使用单表继承，其中放置所有子列使用的所有属性列-types到一个非常宽的表中，并在属性与子类型无关的行上保留NULL。但是这有限制，因为表格可能会变得太宽，而且你无法强制使用任何属性，因为它们必须都可以为空。

如果您的实体子类型数量相对较少，我建议为每组必需属性创建一个从属表。将依赖表的主键定义为父表的外键，以便获得一对一的关系。

CREATE TABLE Vehicles (
  vehicle_id INT PRIMARY KEY
  ...attributes common to all vehicles...
);

CREATE TABLE Automobiles (
  vehicle_id INT PRIMARY KEY,
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id) REFERENCES Vehicles(vehicle_id)
);

您还可以通过在父表的主键中编码子类型来提供更多的数据完整性。这是为了确保 Automobiles 中的一行无法在 Vehicles 中引用摩托车。

CREATE TABLE Vehicles (
  vehicle_id INT,
  vehicle_type VARCHAR(10),
  ...attributes common to all vehicles...
  PRIMARY KEY (vehicle_id, vehicle_type),
  FOREIGN KEY (vehicle_type) REFERENCES VehicleTypes (vehicle_type)
);

CREATE TABLE Automobiles (
  vehicle_id INT,
  vehicle_type VARCHAR(10) CHECK (vehicle_type = 'Automobile'),
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id, vehicle_type) 
    REFERENCES Vehicles(vehicle_id, vehicle_type)
);

当然，每次定义新的子类型时都需要创建一个新的依赖表，但是这种设计确实为您提供了更多的结构来强制执行数据完整性，NOT NULL属性等等。

您需要在应用程序逻辑中强制执行的唯一部分是确保在 Vehicles 中的每一行的 Automobiles 中创建一行 vehicle_type ='Automobile'。

Answer 2

使用数据库来执行规则或在其他地方使用源代码没有区别。代码就是数据。这就是深奥的 Lisp 答案。

您要问的真正问题是，这在关系数据库中还是在（我认为）Algol 系列语言中更容易。您没有指定 RDBMS，所以我将假设 ANSI。这使得这很难。

顺便说一句，这在 Prolog 中很容易。但这既不在这里也不在那里。

我想说对所有事情都使用检查约束。这种方法所需的思维转变是认识到您的 UI 将需要一种方法来定义这些标签关系。传统上，您会从 UI 向数据库发出 CRUD 语句。相反，您需要发出 ALTER TABLE 语句来 CRUD 检查约束。

这种方法有两个问题：

• 此类语句在大多数 RDBMS 中是不可参数化的。想想 SQL 注入。
• 实现方式在对完整 ANSI 检查约束的支持方面有所不同。如果不支持子查询，那就算了。

如果您能用特定的 RDBMS 来澄清您的问题，那么我们可以给您更好的答案。