可选数据库实体

回答您的简化问题:

对于您所描述的层次结构,如果我发现层次结构中的某些级别是可选的,我会质疑层次结构是否真的很好地映射到我的域。我会考虑用不同的方式绘制关系,或者重新定义模式中的实体。

我不认为能在这样的短空间内对一般问题给出更详细的答案,因为要找出一个域的最佳表示是a)困难的,b)非常具体的特定域。

使用外部连接。(右外接和左外接)。

他们是专门为这个做的。

<编辑>这是我的第一篇文章。根据评论,我将添加第二个帖子。

这是我的建筑第一关。这类事情通常需要与主题专家进行大量的反复讨论才能得到正确的答案。

“试验”指:
-采取行动,测量结果
-采取多个行动(子测试),测量每个行动的结果
-不做任何测试(但是你仍然可以有测量结果--?)

我将此配置为“父”测试表和子“子测试”表,其中测试可以有0个或更多相关子测试,并且每个子测试必须与一个且只有一个测试相关。(如果测试只有一个子测试,请将其输入到自己的表中,不要尝试跟踪测试表中的子测试。)

只有存在子测试时,才能存在测试。因此,测试是子测试表的子项;子测试可以有零个或多个测试,并且测试必须与一个且只有一个子测试相关。

只有在有试验的情况下才有措施。因此,重复上述步骤,并将措施作为审判的孩子。

是否可以有没有试验(或测试)的子测试?如果是这样,那就不要参加任何试验。

没有试验就有办法吗?如果没有,您不需要任何测试(或子测试)。如果是(?)如有必要,再次输入一些贴有适当标签的假人/标语牌子测试或试验。

同样,这是最基本的,需要更多的与驾驶要求的人面谈。

正如其他人所说,我们很难在不了解您的领域的情况下给出明确的答案。您试图将许多业务规则提取到几个段落中,但一些重要信息已丢失。具体地说,在不知道两个实体的属性的情况下,不可能确定它们是否真的是不同的。说了这么多,我们走吧。

一 TEST 是一个单一的过程。尽管包含“测试”一词,但lat不是 试验 但这是一套预先定义好的程序。我将把这个场景建模为一个实体 试验 有一个可选的父实体,我希望调用它 TEST_GROUP (原来如此)但最好使用域名, SUB_TEST .

一 TRIAL 似乎与 试验 ,因此将其建模为单独的实体。因此,当涉及到 MEASUREMENT :可以有一个实体具有两个可选的外键,也可以有 TEST_MEASUREMENT 和 TRIAL_MEASUREMENT . 选择哪条路取决于特性和使用情况。

以下是实体关系的初始阶段。当用户说“哦,不,那根本不是我的意思”时,这就是项目的重点。

create table sample (
    sample_id number not null
    , constraint samp_pk primary key (sample_id)
)
/
create table sub_test (
    sub_test_id number not null
    , sample_id number not null
    , constraint subt_pk primary key (sub_test_id)
    , constraint subt_samp_fk foreign key (sample_id)
        references sample (sample_id)
)
/
create table test (
    test_id number not null
    , sample_id number not null
    , sub_test_id number 
    , constraint tst_pk primary key (test_id)
    , constraint tst_samp_fk foreign key (sample_id)
        references sample (sample_id)
    , constraint tst_subt_fk foreign key (sub_test_id)
        references sub_test (sub_test_id)
)
/
create table trial (
    trial_id number not null
    , test_id number not null
    , constraint trl_pk primary key (trial_id)
    , constraint trl_tst_fk foreign key (test_id)
        references test (test_id)
)
/
create table measurement (
    measurement_id number not null
    , trial_id number 
    , test_id number 
    , constraint meas_pk primary key (measurement_id)
    , constraint meas_tst_fk foreign key (test_id)
        references test (test_id)
    , constraint meas_trl_fk foreign key (trial_id)
        references trial (trial_id)
    , constraint measurement_ck check (
            (test_id is not null and trial_id is null)
            or (test_id is null and trial_id is not null)
)
/

编辑

解决更一般的问题。

选项1(虚拟)

从未 使用虚拟记录。这就像使用一个魔法值而不是一个空值。解决方案比它解决的问题更糟糕。

选项2(汇总)

当父级和子级具有相同的属性时,这可以工作。但是,如果它们有不同的列,或者它们是不同的依赖项,那么这不是一个可行的解决方案。即使它们具有相同的数据结构,但不同的业务用途,也可能是一个问题。

选项3(pick-a-parent)

这将是我的首选解决方案。障碍是需要一个检查约束来确保填充了一个(并且只有一个)符合条件的外键。你还需要防止太多的父母/祖父母/曾祖父母混入其中。

我不完全确定我理解你问题的细节,但听起来你应该有以下几点:

表格测试 测试ID、请求、样本、测试

表子检验 子测试\u id,测试\u id(要测试的外键)

桌上试验 试用名、试用名、测量值、子测试名

因此,测试是子测试的集合(可能只有一个子测试),子测试是测试的集合(可能只有一个测试)

我不完全确定我了解你的领域,但你能做点什么吗?

Tests 有一个 parent_test_id 列,可以是 NULL (设置后,这是子测试)。

Trials 有一个 test_id 列。(因为你做了一件事,至少做了一次测量,所以所有的测试都至少进行了一次试验,对吗?)

Measurements 有一个 trial_id 列。

这似乎违背了您的前提,因为它规定所有测试都至少有一个测试,所以我可能误解了这些要求。你怎么能在没有测试的情况下进行测试?

无论如何,如果必要的话,你可以把 三价铝 和A 试验样品 在 测量 ,可能带有一个或另一个必须为空(并且必须设置另一个)的约束。

根据我第一篇文章的反馈,我将对这篇文章进行第二次尝试。要理解的关键是设计和体系结构可以是高度迭代的,而且我怀疑在没有大量反复的情况下,您是否能够得到理想的模型——这种情况在堆栈溢出时不会发挥得很好。很有可能你会把贴出来的想法(APC有一些好的想法),和你的同事一起把它们弹回来,然后想出一些有用的东西。

我这些天设计数据库的目标是尝试生成一个完全规范化的模型。一旦你得到了它,如果它看起来不合理或不实用,你可以为效率、便利性或其他任何东西去规范化——但关键是你去规范化了 之后 你找到了理想的模型。如果你停止正常化 之前 你得到了完全标准化,你没有非标准化,你只是得到了一个草率的模型。

以下是迄今为止我看到的实体:

为了清楚起见,我将在这里称为 考试 . 你定义一个考试及其所有内容(见下文),人们联系你的实验室,对他们的问题进行测试。

对于为客户执行的任何给定检查,您都会运行 测验 . 任何给定的测试可由(要求由?)使用。任何数量的考试。

通常,您会得到一组为多个考试一起完成的测试。如果存在适用于特定测试集的属性,则可能需要将每个测试集标识为其自己的实体。调用这些 测试组 . 但是,如果只使用这些测试,那么将一组特定的测试与一个或多个测试关联起来,将它们定义为它们自己的实体可能不会给您带来任何特别的好处。(这些是您的子测试。)

所以,一个考试“有”或“包含”一个或多个测试。或者,考试与一个或多个测试组相关。但是,尝试将考试与零个或多个测试组关联起来 和 零个或多个单独的测试将产生一个过于复杂的模型(更不用说物理实现),我真的希望避免这种情况。也许一个测试组可以包含一个测试,所以测试只引用测试组?也许一个考试只能与一个测试组相关——在这种情况下,这是一个“多对多”的表格,将考试与测试相关。这取决于与主题专家对需求的进一步讨论。

所以你有考试——考试定义,真的——以某种方式或其他方式与多个考试相关。接下来,您有一个考试的“付费实例”(客户x会进来支付您测试他的小工具)。把这个叫做 客户考试 ;它包含所有联系和账单信息,标识要运行的检查,因此与要为客户执行的测试相关。(可能还有一个客户实体……?)

试验 是为属于CustomerRAM的测试而执行的。它们与考试无关,它们是正在进行的试验的一个实例。(假设试验的“含义/定义”实际上是试验的一部分,似乎是安全的——例如,如果试验=枪准确,那么试验所需的工作=火炮50次并测量)。因此,对给定客户的测试执行测试时。他们表演过一次还是不止一次?(试射枪50次,还是每次都算是试射?如果他们打两轮50枪怎么办?)不管怎样,审判事件的属性都存储在这里——发生的时候,是谁做的,特殊的注释/情况,等等。

措施 是否由(或为)生产?试验。每项措施的含义/定义实际上是试验定义的一部分(试验定义的一部分);试验事件产生规定/预期措施的具体值。假设试验产生零(?)或者更多的度量,所以度量是它们自己的实体。

回顾这一点,似乎有某种形式的隐式双结构:一组表格定义可用的考试、测试、试验和测量(哪些可以检查,如何测试,我们应该测量什么),以及一组配套的表格来跟踪每个人的特定实例(谁想要,谁做了工作,他们什么时候做的,他们做的是什么,他们做的是什么)。在结果之前)

我必须克服这个问题。这里的关键是,和所有设计课程一样,在提出想法和提出问题时,他们是否产生了您自己的想法、问题或答案?