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

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

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

Как можно реализовать схему БД с модификациями изделия?

База проектируется на Access 2013

Ну вот например.
Мы жестянкой занимаемся, изготавливаем в том числе воздуховоды для вентиляции.

Изделие - воздуховод

Модификации - с фланцами/без фланцев, окрашенный/не окрашенный, оцинкованный/нержавеющий.

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

Воздуховод из оцинкованного металла, с фланцами, без окраски.

Воздуховод из черного металла, с фланцами, с окраской

Воздуховод из черного металла, без фланцев, с окраской

и т.п.

И что под каждый вариант отдельное изделие монстрячить?

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

...И все таки не так просто.
Модификация ведь от изделия зависит, а изделия разные могут быть.
И у каждого своя модификация.

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

Переделал с учетом замечаний:

Кот МатроскинНапример, можно сделать дочернюю к изделиям таблицу "модификации", и в связующую
"Изделия2Комплектующие" добавить ID модификации - в какую модификацию оно входит. Если ID модификации null - входит во все.
Хотя я бы все-таки хранил каждую модификацию как отдельное изделие (введя в таблицу "изделия" некую типизацию) - будет проще учитывать, что же мы все-таки изготавливали.

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

Так?

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

Единицы измерения это Measure