Какой тип модели данных моделирует параметры и результаты?

Question

Следующая таблица...:

CREATE TABLE v (
    height int,
    width int,
    depth int,
    volume int,
    PRIMARY KEY (height, width, depth);
)

... может использоваться для хранения входов и выходов функции 3 переменных с именем volume: volume(height, width, depth) = height * width * depth,

Какую модель данных я здесь использую? Это Entity-Attribute-Value?

Answer 1

Вы, кажется, математически ориентированы. Когда Кодд (Дата) представил реляционную модель, он (они) изменил существующий математический язык в новое поле.

В вашем случае: значение может быть функцией трех параметров: val = f(h,w,d), Но для "отношений" (таблиц базы данных) все немного по-другому: функция определяется только в том случае, если {h,w,d} действительно существует в таблице. В математике функция определена во всей области R3. В реляционной алгебре ключ таблицы ({h,w,d}) определяется в более ограниченном домене (или произведении набора доменов). Большая часть мира СУБД /SQL связана с этими ограничениями. (ограничения, ограничения домена, что угодно) Ограничение UNIQUE, пожалуй, самое фундаментальное ограничение: оно гарантирует, что существует не более одного кортежа с определенным {h,w,d}. Как следствие, есть только одно значение функции. Сотрудники СУБД называют неключевые поля отношения "функционально зависимыми" от FK ({h,w,d}}: учитывая набор ключей, может быть не более одной строки, соответствующей ему (и не более одной "значение функции")

EAV - это просто класс моделей данных, чтобы "имитировать", что объект имеет переменное количество атрибутов, без изменения определений используемых таблиц. Но на уровне таблицы это просто означает добавление дополнительной таблицы (фактически двух) с атрибутами и значениями. Моделирование данных - это только скрытая топология.

Answer 2

Нет, это не модель EAV. Вы просто моделируете размеры прямоугольного тела и также сохраняете объем. В реальном мире вы, вероятно, включили бы единицы измерения и некоторые проверочные ограничения.

CREATE TABLE v (
    height_cm int not null check (height_cm > 0),
    width_cm int not null check (width_cm > 0),
    depth_cm int not null check (depth_cm > 0),
    volume_cm3 int not null check (volume_cm3 = height_cm * width_cm * depth_cm),
    PRIMARY KEY (height_cm, width_cm, depth_cm)
);

(Однажды я работал рядом с парнем, который должен был решать проблемы с реляционным уродством db/XML/XSLT, который был разработан плохо сформированным комитетом. Среди прочего, он рассчитывал стоимость доставки, основываясь частично на том, сколько контейнеров поместится в железнодорожный вагон. Пользователи быстро обнаружили, что могут сэкономить на доставке, просто указав отрицательное число в одном измерении каждой упаковки.)

Если вы уроните столбец "volume_cm3", таблица явно в 5NF. (Никаких неключевых атрибутов вообще.) Но если вы включите столбец "volume_cm3" и его ограничения, в какой нормальной форме это будет? Все еще в 5NF?

Answer 3

Таблица V, которую вы показываете, является просто таблицей. Он имеет ключ из трех частей и один столбец данных, полностью зависящий от ключа. Объем определяется по формуле, использующей три показателя (и, возможно, некоторые другие), которые находятся в ключе. Функциональная зависимость Volume - это ключ из трех частей. Это не пара значений атрибутов. Это также не нарушает никакой нормальной формы. Это просто производная таблица с ключом из трех частей и одним столбцом данных. Можно задуматься над этим вопросом.