Создание реляционной базы данных из N-мерной таблицы

Question

У меня есть множество функций, которые имеют много входных аргументов, но относительно немного уникальных выходов, и я пытаюсь подсчитать выходы, чтобы я мог смотреть на входы. Обычно у меня будет набор 2D-таблиц для данной функции, с некоторыми правилами, которые определяют, на какую таблицу смотреть. Так, например, если значение некоторой переменной меньше 1, я должен посмотреть на таблицу 1, но если переменная больше или равна 1, я должен посмотреть на таблицу 2, чтобы определить выход (но, более типично, таблицу использование будет зависеть от значения 5 или 6 переменных). Существует дополнительная проблема: таблица 2 и таблица 1 не обязательно имеют одинаковые строки &.

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

Я изучил принципы проектирования баз данных, но все вступительные материалы, которые я нашел, использовали гораздо более простые примеры, чем мои, и я не уверен, как продлить то, что я прочитал, чтобы удовлетворить мои потребности. Я понимаю, что если у меня есть N входных данных для моей функции, тогда мне понадобятся таблицы N + 1 для создания реляционной базы данных; поэтому я не уверен, что это сделает вещи более ясными или менее ясными. Я надеюсь, что это распространенная проблема для экспертов по базам данных и что у кого-то будет какой-то совет!

Edit:

Пример был предложен, поэтому я сделал один вверх, который похож на мою проблему. Предположим, я хочу выяснить, какая цена на одежду была на определенную дату. У меня есть три 2D таблицы, которые дают мне эту информацию:

Перед 1/1/2010:

+--------+----------+----------+----------+----------+ 
|  | Fabric A | Fabric B | Fabric C | Fabric D | 
+--------+----------+----------+----------+----------+ 
| Size S |  1 |  2 |  3 |  4 | 
| Size M |  5 |  6 |  7 |  8 | 
| Size L |  9 |  10 |  11 |  12 | 
+--------+----------+----------+----------+----------+ 

После 1/1/2010:

Если Конструктор P:

+--------+------------+------------+------------+ 
|  | Location X | Location Y | Location Z | 
+--------+------------+------------+------------+ 
| Size S |   1 |   2 |   3 | 
| Size M |   5 |   6 |   7 | 
| Size L |   9 |   10 |   11 | 
+--------+------------+------------+------------+ 

Если конструктор Q:

+--------+------------+------------+------------+ 
|  | Location X | Location Y | Location Z | 
+--------+------------+------------+------------+ 
| Size S |   2 |   2 |   3 | 
| Size M |   4 |   5 |   5 | 
| Size L |   6 |   7 |   8 | 
+--------+------------+------------+------------+ 

Итак, это три таблицы. Что я сделал создается табличное что-то вроде этого:

+------------+----------+------+--------+----------+-------+ 
| Date | Designer | Size | Fabric | Location | Price | 
+------------+----------+------+--------+----------+-------+ 
| 01/01/2010 | P  | L | A  | X  |  6 | 
| 01/01/2010 | P  | L | A  | Y  |  7 | 
| 01/01/2010 | P  | L | A  | Z  |  8 | 
| 01/01/2010 | P  | L | B  | X  |  6 | 
| 01/01/2010 | P  | L | B  | Y  |  7 | 
| 01/01/2010 | P  | L | B  | Z  |  8 | 
| 01/01/2010 | P  | L | C  | X  |  6 | 
| 01/01/2010 | P  | L | C  | Y  |  7 | 
| 01/01/2010 | P  | L | C  | Z  |  8 | 
| 01/01/2010 | P  | L | D  | X  |  6 | 
| 01/01/2010 | P  | L | D  | Y  |  7 | 
| 01/01/2010 | P  | L | D  | Z  |  8 | 
| 01/01/2010 | P  | M | A  | X  |  4 | 
| 01/01/2010 | P  | M | A  | Y  |  5 | 
| 01/01/2010 | P  | M | A  | Z  |  5 | 
| 01/01/2010 | P  | M | B  | X  |  4 | 
| 01/01/2010 | P  | M | B  | Y  |  5 | 
| 01/01/2010 | P  | M | B  | Z  |  5 | 
| 01/01/2010 | P  | M | C  | X  |  4 | 
| 01/01/2010 | P  | M | C  | Y  |  5 | 
| 01/01/2010 | P  | M | C  | Z  |  5 | 
| 01/01/2010 | P  | M | D  | X  |  4 | 
| 01/01/2010 | P  | M | D  | Y  |  5 | 
| 01/01/2010 | P  | M | D  | Z  |  5 | 
| 01/01/2010 | P  | S | A  | X  |  2 | 
| 01/01/2010 | P  | S | A  | Y  |  2 | 
| 01/01/2010 | P  | S | A  | Z  |  3 | 
| 01/01/2010 | P  | S | B  | X  |  2 | 
| 01/01/2010 | P  | S | B  | Y  |  2 | 
| 01/01/2010 | P  | S | B  | Z  |  3 | 
| 01/01/2010 | P  | S | C  | X  |  2 | 
| 01/01/2010 | P  | S | C  | Y  |  2 | 
| 01/01/2010 | P  | S | C  | Z  |  3 | 
| 01/01/2010 | P  | S | D  | X  |  2 | 
| 01/01/2010 | P  | S | D  | Y  |  2 | 
| 01/01/2010 | P  | S | D  | Z  |  3 | 
| 01/01/2010 | Q  | L | A  | X  |  9 | 
| 01/01/2010 | Q  | L | A  | Y  | 10 | 
| 01/01/2010 | Q  | L | A  | Z  | 11 | 
| 01/01/2010 | Q  | L | B  | X  |  9 | 
| 01/01/2010 | Q  | L | B  | Y  | 10 | 
| 01/01/2010 | Q  | L | B  | Z  | 11 | 
| 01/01/2010 | Q  | L | C  | X  |  9 | 
| 01/01/2010 | Q  | L | C  | Y  | 10 | 
| 01/01/2010 | Q  | L | C  | Z  | 11 | 
| 01/01/2010 | Q  | L | D  | X  |  9 | 
| 01/01/2010 | Q  | L | D  | Y  | 10 | 
| 01/01/2010 | Q  | L | D  | Z  | 11 | 
| 01/01/2010 | Q  | M | A  | X  |  5 | 
| 01/01/2010 | Q  | M | A  | Y  |  6 | 
| 01/01/2010 | Q  | M | A  | Z  |  7 | 
| 01/01/2010 | Q  | M | B  | X  |  5 | 
| 01/01/2010 | Q  | M | B  | Y  |  6 | 
| 01/01/2010 | Q  | M | B  | Z  |  7 | 
| 01/01/2010 | Q  | M | C  | X  |  5 | 
| 01/01/2010 | Q  | M | C  | Y  |  6 | 
| 01/01/2010 | Q  | M | C  | Z  |  7 | 
| 01/01/2010 | Q  | M | D  | X  |  5 | 
| 01/01/2010 | Q  | M | D  | Y  |  6 | 
| 01/01/2010 | Q  | M | D  | Z  |  7 | 
| 01/01/2010 | Q  | S | A  | X  |  1 | 
| 01/01/2010 | Q  | S | A  | Y  |  2 | 
| 01/01/2010 | Q  | S | A  | Z  |  3 | 
| 01/01/2010 | Q  | S | B  | X  |  1 | 
| 01/01/2010 | Q  | S | B  | Y  |  2 | 
| 01/01/2010 | Q  | S | B  | Z  |  3 | 
| 01/01/2010 | Q  | S | C  | X  |  1 | 
| 01/01/2010 | Q  | S | C  | Y  |  2 | 
| 01/01/2010 | Q  | S | C  | Z  |  3 | 
| 01/01/2010 | Q  | S | D  | X  |  1 | 
| 01/01/2010 | Q  | S | D  | Y  |  2 | 
| 01/01/2010 | Q  | S | D  | Z  |  3 | 
| 01/01/1900 | P  | L | A  | X  |  9 | 
| 01/01/1900 | P  | L | A  | Y  |  9 | 
| 01/01/1900 | P  | L | A  | Z  |  9 | 
| 01/01/1900 | P  | L | B  | X  | 10 | 
| 01/01/1900 | P  | L | B  | Y  | 10 | 
| 01/01/1900 | P  | L | B  | Z  | 10 | 
| 01/01/1900 | P  | L | C  | X  | 11 | 
| 01/01/1900 | P  | L | C  | Y  | 11 | 
| 01/01/1900 | P  | L | C  | Z  | 11 | 
| 01/01/1900 | P  | L | D  | X  | 12 | 
| 01/01/1900 | P  | L | D  | Y  | 12 | 
| 01/01/1900 | P  | L | D  | Z  | 12 | 
| 01/01/1900 | P  | M | A  | X  |  5 | 
| 01/01/1900 | P  | M | A  | Y  |  5 | 
| 01/01/1900 | P  | M | A  | Z  |  5 | 
| 01/01/1900 | P  | M | B  | X  |  6 | 
| 01/01/1900 | P  | M | B  | Y  |  6 | 
| 01/01/1900 | P  | M | B  | Z  |  6 | 
| 01/01/1900 | P  | M | C  | X  |  7 | 
| 01/01/1900 | P  | M | C  | Y  |  7 | 
| 01/01/1900 | P  | M | C  | Z  |  7 | 
| 01/01/1900 | P  | M | D  | X  |  8 | 
| 01/01/1900 | P  | M | D  | Y  |  8 | 
| 01/01/1900 | P  | M | D  | Z  |  8 | 
| 01/01/1900 | P  | S | A  | X  |  1 | 
| 01/01/1900 | P  | S | A  | Y  |  1 | 
| 01/01/1900 | P  | S | A  | Z  |  1 | 
| 01/01/1900 | P  | S | B  | X  |  2 | 
| 01/01/1900 | P  | S | B  | Y  |  2 | 
| 01/01/1900 | P  | S | B  | Z  |  2 | 
| 01/01/1900 | P  | S | C  | X  |  3 | 
| 01/01/1900 | P  | S | C  | Y  |  3 | 
| 01/01/1900 | P  | S | C  | Z  |  3 | 
| 01/01/1900 | P  | S | D  | X  |  4 | 
| 01/01/1900 | P  | S | D  | Y  |  4 | 
| 01/01/1900 | P  | S | D  | Z  |  4 | 
| 01/01/1900 | Q  | L | A  | X  |  9 | 
| 01/01/1900 | Q  | L | A  | Y  |  9 | 
| 01/01/1900 | Q  | L | A  | Z  |  9 | 
| 01/01/1900 | Q  | L | B  | X  | 10 | 
| 01/01/1900 | Q  | L | B  | Y  | 10 | 
| 01/01/1900 | Q  | L | B  | Z  | 10 | 
| 01/01/1900 | Q  | L | C  | X  | 11 | 
| 01/01/1900 | Q  | L | C  | Y  | 11 | 
| 01/01/1900 | Q  | L | C  | Z  | 11 | 
| 01/01/1900 | Q  | L | D  | X  | 12 | 
| 01/01/1900 | Q  | L | D  | Y  | 12 | 
| 01/01/1900 | Q  | L | D  | Z  | 12 | 
| 01/01/1900 | Q  | M | A  | X  |  5 | 
| 01/01/1900 | Q  | M | A  | Y  |  5 | 
| 01/01/1900 | Q  | M | A  | Z  |  5 | 
| 01/01/1900 | Q  | M | B  | X  |  6 | 
| 01/01/1900 | Q  | M | B  | Y  |  6 | 
| 01/01/1900 | Q  | M | B  | Z  |  6 | 
| 01/01/1900 | Q  | M | C  | X  |  7 | 
| 01/01/1900 | Q  | M | C  | Y  |  7 | 
| 01/01/1900 | Q  | M | C  | Z  |  7 | 
| 01/01/1900 | Q  | M | D  | X  |  8 | 
| 01/01/1900 | Q  | M | D  | Y  |  8 | 
| 01/01/1900 | Q  | M | D  | Z  |  8 | 
| 01/01/1900 | Q  | S | A  | X  |  1 | 
| 01/01/1900 | Q  | S | A  | Y  |  1 | 
| 01/01/1900 | Q  | S | A  | Z  |  1 | 
| 01/01/1900 | Q  | S | B  | X  |  2 | 
| 01/01/1900 | Q  | S | B  | Y  |  2 | 
| 01/01/1900 | Q  | S | B  | Z  |  2 | 
| 01/01/1900 | Q  | S | C  | X  |  3 | 
| 01/01/1900 | Q  | S | C  | Y  |  3 | 
| 01/01/1900 | Q  | S | C  | Z  |  3 | 
| 01/01/1900 | Q  | S | D  | X  |  4 | 
| 01/01/1900 | Q  | S | D  | Y  |  4 | 
| 01/01/1900 | Q  | S | D  | Z  |  4 | 
+------------+----------+------+--------+----------+-------+ 

Я не могу использовать маленькие таблицы для моих целей (я не думаю), но я могу легко использовать большой. Тем не менее, это вводит вторичное требование: теперь другие люди должны иметь возможность регулярно проверять, что большая таблица полностью содержит всю информацию из таблиц. Для кого-то не так сложно проверить, согласуется ли цена с большой таблицей с ценой из соответствующей маленькой таблицы, но по мере того, как мы добавляем больше таблиц и включаем больше параметров, становится очень сложно выявить другие проблемы (например, отсутствующая запись).Вопрос, на который нужно будет ответить, - «можно ли использовать большую таблицу для правильного поиска всех возможных цен на предмет одежды?».

Мое настоящее мышление заключается в том, что я хотел бы настроить небольшие таблицы, которые очень легко проверить, и, возможно, автоматизировать процесс генерации большой таблицы, чтобы доверие к процессу => доверие к большой таблице. Я также задаюсь вопросом, нужна ли мне большая таблица для того, чтобы сделать поиск, который я хочу сделать, или если есть умный способ пойти и получить результаты из маленьких таблиц напрямую (используя умный дизайн базы данных, возможно?).

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

Edit:

Спасибо за все комментарии до сих пор. К сожалению, я пытаюсь понять пару ответов, и кажется, что проблема все еще слишком расплывчата, чтобы правильно ответить. Я просто попытаюсь сформулировать свою проблему в контексте уже приведенного примера.

В моем примере одежды выше, я говорю, что цена предмета одежды, в общем, является функцией проданной даты, проданного места, дизайнера, размера, ткани. Я создал таблицу для выражения взаимосвязи между этими входами и ценой.

Однако многие из строк в этой таблице не используют все столбцы - для чего-либо, проданного до 1/1/2010, нет зависимости от дизайнера, например. Чтобы закодировать это в моей большой таблице, мне пришлось добавить много дополнительных строк, чтобы гарантировать, что для чего-либо, проданного до 1/1/2010, дает тот же ответ дизайнеру P как конструктор Q для любой другой комбинации входных данных. Это кажется неэффективным, но я не уверен, как (или) это можно было бы сформулировать лучше. Я попытался понять процесс нормализации, но я изо всех сил пытаюсь понять, как это будет работать для этого примера одежды. И в дальнейшем я не уверен, что нормализация сделает таблицу более понятной (так как это моя основная цель сейчас).

В качестве дополнительного ограничения для бизнеса я мог бы получить больше информации в любое время о ценах или новых методах ценообразования. Поэтому вполне возможно, что мне, возможно, придется добавить еще пару входных данных (столбцов) в мою большую таблицу и целую загрузку большего количества строк, чтобы понять, как цена теперь зависит от каждого входа, даже если это приведет только к одной или двум новым новым ценам точки. В моем примере у меня три таблицы, но на самом деле у меня будут сотни. Это очень много информации, и нет никакого способа обойти это, но я уверен, что есть способ сделать это, что не требует ни сотни небольших таблиц, ни много тысяч существенно избыточных строк в большой таблице. Я просто пытаюсь понять, как я сломаю его. Есть ли способ разбить его, что яснее человеческого глаза? Есть ли способ сформулировать его, что означает, что при появлении нового ввода мне не нужно добавлять 1000 лишних строк в таблицу? Является ли нормализация тем, что мне нужно делать?

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

Answer 1

TL; DR Ваши текстовые таблицы - это фотографии отношений & функции. Вам нужно забыть форматирование и «2D» и «плоский», а просто определить размеры, значения которых связаны между отношением приложения, которое представляет таблица. Если вы хотите отобразить отношение в определенном формате, это проблема пользовательского графического интерфейса.

Вам необходимо прочитать и узнать о реляционной модели, моделировании и нормализации информации.

---

Каноническая картина (но это просто картина) при использовании реляционных баз данных, чтобы поставить все размеры правоотношения приложения вдоль верхней части.

Цена цена на размер Размер с тканью Ткань после 1/1/2010 спроектированный P

+------+--------+-------+ 
| Size | Fabric | Price | 
+------+--------+-------+ 
| S |  A |  1 | 
| S |  B |  2 | 
... 
| L |  D | 12 | 
+------+--------+-------+ 

Но подождите! В приведенной выше таблице является частью некоторой таблицы, как:

Цена цена на размер Размер с тканью Ткань после После разработан Designer И После = 1/1/2010 И Designer = P

+------+--------+------+----------+----------+ 
| Size | Fabric | Price| Designer | After | 
+------+--------+------+----------+----------+ 
| S |  A | 1 |  P | 1/1/2010 | 
| S |  A | 1 |  P | 1/1/2010 | 
... 
| L |  D | 12 |  P | 1/1/2010 | 
+------+--------+------+----------+----------+ 

, которая является частью некоторой таблицы, как:

Цена цена на размер Размер с ткани Ткань после После разработан Designer

+------+--------+-------+----------+----------+ 
| Size | Fabric | Price | Designer | After | 
+------+--------+-------+----------+----------+ 
| S |  A |  1 |  P | 1/1/2010 | 
... 
| M |  D |  8 |  Q | 1/1/1900 | 
... 
+------+--------+-------+----------+----------+ 

С другой стороны, если ярлык этой таблицы всегда означает "Цена является цена на размер Размер с тканью Ткани И Цена цена после После спроектированного Designer »и некоторые другие вещи так, то мы должны были бы только первую таблицу и это одно:

Цена является цена после После разработан Designer

+-------+----------+----------+ 
| Price | Designer | After | 
+-------+----------+----------+ 
|  1 |  P | 1/1/2010 | 
... 
|  8 |  Q | 1/1/1900 | 
... 
+-------+----------+----------+ 

из-за того, чтобы быть в состоянии реконструировать больше один из более мелких.

Отношение содержит строки, которые составляют предикат aka параметризованное утверждение о деловой ситуации в истинное утверждение. join двух отношений содержит строки, которые превращают «И» их предикатов в истинное утверждение. (И union «ИЛИ» и т. Д.). Дизайн базы данных - это поиск необходимых и достаточных предикатов для описания любой ситуации в бизнесе. Мы описываем предикаты/таблицы, которые мы хотим видеть как запросы в терминах этих базовых предикатов/таблиц. Мы пытаемся упростить предикаты/таблицы. Мы стараемся минимизировать предикаты/таблицы, которые могут быть выражены в терминах других (полностью или частично). Мы можем форматировать по-разному на выходе. Мы также определяем ограничения, которые описывают допустимые состояния базы данных (что эквивалентно ситуации приложения, которые могут возникнуть), поэтому СУБД может отклонять недействительные попытки обновления.

При проектировании, когда мы имеем некоторых предикатов/таблицу, которые полностью описывают наш бизнес-ситуацию мы делаем предикаты/столы меньших и независимыми, где это возможно с помощью нормализации, которая основана на функциональных зависимости и присоединяются зависимости. Методы информационного моделирования обычно пытаются создать базовые предикаты/таблицы, которые уже по крайней мере несколько нормализованы.

Функциональные зависимости включают предикаты/таблицы, в которых столбцы являются функциями других столбцов. Присоединительные зависимости включают предикаты/таблицы, используя «И». (Каждая функциональная зависимость связана с зависимостью соединения). Нормализация включает замену предикатов/таблиц на более мелкие, чтобы избавиться от проблемных функциональных и зависимых связей.

Answer 2

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

Я считаю,

Если честно, я не уверен, что у вас есть соответствующий механизм, но вам кажется, что вы должны иметь возможность передавать продукт и дату в функцию, которая затем использует бизнес-правила для определения соответствующей цены и поэтому я думаю, что вам нужно что-то вроде механизма бизнес-правил.