Проектирование базы данных с именем файла, именем теста и его результатом при каждой сборке

Question

Мне нужно спроектировать базу данных, где я должен хранить Test Name для каждого Filename, и каждый Test Name может работать на нескольких Builds и может либо Pass, либо Fail. Между Filename & Test Name существует соотношение 1-1, что означает, что для 1 теста существует 1 файл. Но каждый тест может выполняться на многих сборках и иметь разные выходные данные.

Мой подход: Таблица 1: FileAndTestMap

+----------+----------+
| Testname | Filename |
+----------+----------+
| 1        | A.txt    |
+----------+----------+
| 2        | Er.txt   |
+----------+----------+

Таблица 2: Сборка

+------+--------------+
| S No | Build Number |
+------+--------------+
| 1    | Build_123    |
+------+--------------+
| 2    | Build_234    |
+------+--------------+

Таблица 3: Build_XXX (для каждой сборки)

+----------+----------+--------+
| TestName | Executed | Passed |
+----------+----------+--------+
| 1        | Y        | Y      |
+----------+----------+--------+
| 2        | N        | N      |
+----------+----------+--------+

Мне не нравится этот дизайн, и мне нужен лучший подход к нему. Любая помощь приветствуется.

Answer 1

Вы можете выбрать отображение базы данных на основе постоянства сущностей, т. Е. Может ли ваша сущность сохраняться независимо или нет.В вашем конкретном случае следующие являются автономными и зависимыми объектами:

1. Имя файла> Автономный.Файл может сохраняться даже тогда, когда не будет никакого теста или сборки.
2. Имя теста> Зависимый.Имя теста может существовать, только если файл существует, а сборка существует.И каждое имя теста принадлежит одному и только одному имени файла.
3. Build> частично зависит от файла.Вы можете создать, когда есть хотя бы файл

Итак, теперь вы можете начать с отображения базы данных следующим образом:

FileName

 +----------+----------
| Id       | Filename |
+----------+----------+
| 1        | A.txt    |
+----------+----------+
| 2        | Er.txt   |
+----------+----------+
// Id is primary key

//Если тест зависел только от файла, то здесь testId можно сделать внешним ключом напрямую, но тест зависит от сборки, и это один ко многим.(один тест может выполняться на нескольких сборках)

Тест

    +------+--------------+
    | Id   | Test Name    |
    +------+--------------+
    | 1    | Test 1       |
    +------+--------------+
    | 2    | Test 2       |
    +------+--------------+
//Id is primary key

Таблица сборки

    +------+--------------+
    | S No | Build Number |
    +------+--------------+
    | 1    | Build_123    |
    +------+--------------+
    | 2    | Build_234    |
    +------+--------------+
// Id is primary key

BuildTestMap

+------+--------------+ ------- + ------ + --------+---------
| Id   | BuildId      | TestId | FileId | Executed | Passed |
+------+--------------+ -------+ -------+ -------- + -------
| 1    | Build_123    |  1     |  2    |   y       |  n     |
+------+--------------+ -------+ ------+ ----------+ -------
| 2    | Build_234    |  1     |  2    |   y       |  y     |
+------+--------------+------- + ------+ ----------+ -------

//Notice here TestId is foreign key of Test table and FileId is foreign key of File table and BuildId is foreign key of Build table

Answer 2

Сделать номер сборки в качестве первичного ключа в таблице 2, а в таблице 3 использовать его в качестве внешнего ключа.

Схема таблицы 3:

SRNo (автоинкремент), номер сборки (ForeignKey из таблицы 2)), Имя теста (ForiegnKey из таблицы 1), выполнено, пройдено