如何在基于标签的组织中定义结构?

时间:2008-11-13 18:47:57

标签: database-design data-structures tags entity-relationship entity-attribute-value

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

我有一些实体,他们有一系列属性。一些属性影响实体可以具有的其他属性,许多属性被组织成组,偶尔实体被要求具有来自特定组的特定数量的属性,或者可能来自某些组的一系列属性。

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

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

那么,这是否可能以更严格的方式进行,如果是这样,我怎么会开始这么做呢?

2 个答案:

答案 0 :(得分:4)

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

我之前的答案,与RDBMS解决方案有关,如下:


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

其他人使用Single Table Inheritance,其中将所有子类型使用的所有属性列放入一个非常宽的表中,并在属性与子类型无关的行上保留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属性等等。

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

答案 1 :(得分:2)

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

你问的真正问题是在关系数据库中还是在(我假设)Algol家族语言中这是否更容易。你没有指定RDBMS,所以我将假设ANSI。这使得这很难。

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

我会说对一切都使用检查约束。这种方法所需的心理转变是要意识到您的UI需要一种方法来定义这些标记关系。传统上,您可以从UI向DB发出CRUD语句。相反,您需要向CRUD检查约束发出ALTER TABLE语句。

这种方法存在两个问题:

  • 在大多数RDBMS中,此类语句不可参数化。想想SQL注入。
  • 实现对完整ANSI检查约束的支持各不相同。如果不支持子查询,请忘记它。

如果你能用特定的RDBMS澄清你的问题,那么我们可以给你一个更好的答案。