Доброго времени суток, уважаемые знатоки!

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

Прикрепляю два варианта схемы данных.
Общее описание: Главная таблица - "Инструмент", там хранятся маркировки всех инструментов. Все инструменты делятся на типы (таблица "Тип_инструмента"), каждому типу инструмента соответствует свой набор свойств (таблица "Список_свойств" и таблица "Соответствие_св-ва_типу", которая описывает какой набор свойств соответствует определенному типу инструмента).
Далее идет различие.
1 вариант. В таблице "Хранилище_значений_св-в" я храню значения всех свойств, соответствующих каждому инструменту, причем в текстовом формате, так как некоторые свойства описываются целым числом, некоторые числом с плавающей точкой, а некоторые набором текстовых значений.
Минусы при такой схеме в том, что я храню все свойства в текстовом формате и значения свойств в поле "Значение" таблицы "Хранилище_значений_св-в" будут много раз повторяться, так как значения некоторых свойств у разных инструментов часто одинаковые.

2 вариант. Я создаю дополнительную таблицу "Список_значений_св-в", в которой буду хранить все возможные значения всех свойств, тоже в текстовом формате, и свяжу ее с таблицей "Хранилище_значений_св-в" через id (см схему данных). Причем там будут записаны как наборы текстовых значений, так и числа с плавающей точкой и целые числа (собственно, как и в первом варианте).
Плюсом такой схемы будет отсутствие повторений в значениях свойств.
Но минус обоих схем в том, что я храню в одном столбце и текстовые свойства и числовые.

В общем, как-то так. Какой из этих вариантов лучше? Или может предложите какой-то третий? Мне больше в голову ничего не идет.

На всякий случай выложу файлы с примерами этих схем.

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

Не могли бы вы набросать схему, как вы видите решение моей задачи? Просто я очень много времени потратил на продумывание данной схемы (да, стоит сказать, что я новичек в базах данных). Это далеко не первый мой вариант. Сначала все было линейно, но была огромная куча таблиц (для каждого типа инструмента своя таблица, а типов около 30), там пошла путаница со связями (я не всю схему данных привел. Там еще есть сборные инструменты, состоящие из других инструментов). В конечном итоге пришел к такой схеме. Как избавиться от кольца тоже не очень представляю. Ведь значение свойства однозначно связано как с инструментом, так и с самим свойством. Я не могу записать значение не указав какой инструмент и какое свойство. Набор свойств в свою очередь определяется типом инструмента, ну и у каждый инструмент принадлежит к какому-то из типов. В моем понимании, все должно выглядеть примерно так. Буду очень признателен, если подскажите более правильную схему )

AkinaПочитайте, что такое EAV и как реализуется. И обратите внимание на фразу о шаблонах.

Почитал что такое EAV. Собственно, убираю одну таблицу и все, вроде, так как надо получается. Таблица "Инструмент" хранит сущности, таблица "Список_свойств" содержит атрибуты, таблица "Хранилище_значений_св-в" содержит значения.

Только вот эти ваши слова я не очень понял
Akina А схема шаблонов набора свойств вообще никак не связана со схемой хранения сведений об их значениях для экземпляров инструментов - т.е. должны получиться две формально независимые схемы.
Это таблицы-словари со стандартным набором значений как-то отделить надо от общей схемы? Я нигде подобных примеров не видел. Не могли бы вы пояснить?

Ну и привожу 2 обновленных варианта схемы. Какой лучше? ) На самом деле, есть третий, где не 1, а 3 таблицы, которые хранят значения свойств. Каждая из таблиц хранит свой тип данных (int, float, string). Только я сомневаюсь, что потяну дальнейшую работу с такой схемой, т.к. запросы обещают быть сложными (таблицы как-то перемножать нужно будет)

вот, собственно, схема. Не прикрепилась сразу почему-то )

AkinaSergey8969привожу 2 обновленных варианта схемы. Какой лучше?Выделение отдельной таблицы для хранения значений мне кажется избыточным. Вариант 1 имхо более "вменяем".

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

AkinaОбе схемы плохи.
В любом случае - схема должна получиться линейной, в ней неоткуда взяться кольцам.

Является ли это аксиомой или кольца все же встречаются в исключительных случаях?

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

я не сразу понял что вы имели ввиду под таблицей шаблонов наборов свойств.

Значит я создаю таблицу, в которой храню "шаблоны наборов свойств", то есть связь между типом инструмента и свойствами, соответствующими этому типу. Получается таблица "соответствие_св-в_типу", которую я убрал из первоначальной схемы. Ну и дабы обеспечить целостность данных я привязываю данную таблицу к таблице с наборами типов инструмента и к таблице с набором свойств. В этоге получается такая же схема, как была изначально. Где в моих рассуждениях ошибка? Я не очень понимаю как мне сделать эту таблицу отдельной, при этом обеспечив целостность данных.

AkinaНЕТ!!! как ты, блин, умудряешься буквально за пару часов забыть всё, что прочитал ранее?

:) я не забываю то, что прочитал ранее, но понимаю все, что вы говорите исходя из своих скудных знаний, на свой манер, так сказать) очевидно, что я не все понял, что вы мне говорили, так как мало с чем имел дело. Я говорил, что новичок в вопросе. Я не программист по образованию) Для меня полученная от вас информация противоречива, потому как с одной стороны вы говорите, что кольцо в схеме данных - это плохо, хотя оговорились, что иногда так может быть, с другой стороны таблица, хранящая "шаблоны наборов свойств" нужна, причем отдельная. На сколько я понял, эта таблица вида Id, Id_св-во, Id_тип_данных. И как ее тут связать с соответствующими таблицами, не образовывая кольцо я не совсем понимаю, уж не серчайте ))

Собственно, в чем я ошибаюсь? ) Таблица шаблонов наборов свойств правильная? Id, Id_св-во, Id_тип_данных? Способ привязки не тот? ) Либо она вообще ни с чем не должна быть связана, а к ней нужно обращаться за списком свойств при добавлении нового инструмента? Ну тогда никакой целостности данных.

Чем вообще так губительно кольцо в схеме данных? Данные как-то наслаиваться могут?

AkinaА при чём тут целостность? Где ты её видишь вообще? А если видишь - каким макаром она может быть нарушена?

Если я запишу в таблицу шаблонов несуществующий id_свойство или id_тип_инструмента, то Access позволит мне это сделать. Плюс если я захочу удалить какое-нибудь свойство из таблицы свойств - в таблице шаблонов оно останется. Это я имел ввиду.

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

Akina,

Позвольте поинтересоваться, нет ли ошибок в оставшейся части моей схемы данных?

Описание.
Синей рамкой выделена часть схемы данных, которую мы уже обсудили.
В таблице "Склад" хранится информация о кол-ве инструмента на складе, в цехе и на списание. Таблица "Журнал_выдачи" сохраняет данные о выдаче и получении инструмента: когда, кому, сколько. Таблицы "Рабочий" и "Тип_операции" - словари.
В таблице "Сборка" хранится информация какой инструмент с каким собирается, в случае если он сборный. Таблица "Инструмент_1" - это на самом деле та же таблица "Инструмент". Access почему-то не дает сделать 2 связи между одними и теми же таблицами, при попытке это сделать он создает виртуальную копию одной из таблиц. Копия существует только на схеме.

Кто-нибудь гляньте пожалуйста схему базы склада инструмента, скажите нет ли серьезных ошибок, работоспособна ли в таком виде?

Еще раз описание схемы полностью.
Главная таблица - "Инструмент", там хранятся маркировки всех инструментов. Все инструменты делятся на типы (таблица "Тип_инструмента"), каждому типу инструмента соответствует свой набор свойств (таблица "Список_свойств" и таблица "Соответствие_св-ва_типу", которая описывает какой набор свойств соответствует определенному типу инструмента - таблица шаблонов наборов свойств). В таблице "Хранилище_значений_св-в" содержатся значения всех свойств, соответствующих каждому инструменту.
В таблице "Склад" хранится информация о кол-ве инструмента на складе, в цехе и на списание. Таблица "Журнал_выдачи" сохраняет данные о выдаче и получении инструмента: когда, кому, сколько. Таблицы "Рабочий" и "Тип_операции" - словари.
В таблице "Сборка" хранится информация какой инструмент с каким собирается, в случае если он сборный. Таблица "Инструмент_1" - это на самом деле та же таблица "Инструмент". Access почему-то не дает сделать 2 связи между одними и теми же таблицами, при попытке это сделать он создает виртуальную копию одной из таблиц. Копия существует только на схеме. (это вообще нормально?)

Ладно, всем спасибо за ответы. Думаю, у меня все получится с такой схемой. Пока проблем нет