Как составить ведомость материалов, которая имеет несколько вариантов

Question

Я застрял, пытаясь разработать Билль о материалах в доступе.У меня есть вызов таблицы IM_Item_Registry, где у меня есть Item_Code и логическое значение для, если это компонент.Я застрял в том, что прошлые грехи компании сделали несколько номеров деталей для одного и того же ингредиента от разных поставщиков.Продукт может использовать ингредиент 1 в начале цикла и ингредиент 2 в конце цикла, в зависимости от инвентаря, и он может переключаться с работы на работу (отсутствие дисциплины и случайные покупки в зависимости от цены).Это создает головную боль для меня, потому что они обычно имеют разные включения.Как мне добавить гибкость в использовании обоих?или было бы проще сделать несколько версий, а затем выбрать их по расписанию?

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

РЕДАКТИРОВАТЬ (28.03.2009) это для компании, занимающейся литьем под давлением.

IM_Item_Registry (Поля: Item_Code, Category (Сырье, изготовлено, поставляется заказчиком), компонент сборки), Описание, Компонент (логическое значение), активный (логическое значение), Единица измерения.

для этого спецификационного номера 100011 создает компонент, позволяющий назвать это дескриптором. В счете 100011 используется необработанная смола 700049 в98% -ное включение и необработанный цвет 600020 при 2% -ном включении. Однако у нас может не хватить необработанного цвета 600020, и нам придется его исчерпать из 600051, который изменит 700049 до 98,5%, потому что 600051 требует 1,5% включения для достижения того же цвета.

Я хотел бы создать таблицу, которая будет вызывать общий термин, скажем, 600020 и 60005.1 - добавка желтого цвета.затем создайте «призрачный» номер для вызова либо 600020, либо 600051 и укажите оба рецепта рецептуры.При запуске производства они сканировали, какой цвет они фактически использовали для создания производственной спецификации, и записывали, какой цвет использовался и в каком количестве.Есть ли способ сделать это при структурировании базы данных доступа?

Я предполагаю, что мне понадобится как таблица item_registry, таблица BoM (поля: BOM #, ParentID, Ghost_ID), а затем таблица компонентов (поля: Ghost_ID, item_code, коэффициент включения).

Answer 1

Нормализация базы данных является руководящим принципом для разработки эффективных, полезных таблиц и отношений в реляционной базе данных.Формы доступа, подчиненные формы, отчеты и т. Д. Требуют, чтобы должным образом нормализованные таблицы работали, как предполагалось.Существуют различные уровни нормализации, но общая идея состоит в том, чтобы избежать дублирования данных между строками и столбцами данных.Наличие дублирующихся данных требует больших затрат памяти и гарантирует, что действия с базой данных не создадут противоречивые состояния (противоречивые значения данных).Хорошо нормализованные таблицы позволяют определять полезные ограничения между столбцами данных и / или строками, чтобы обеспечить достоверность данных.

Таблица [BoM], предложенная в вопросе, не нормализована.Но прежде чем мы перейдем к этому, ParentID не был определен, и неясно, что он представляет.Вместо этого, чтобы показать, почему он не нормализован, позвольте мне добавить столбец [Product] в таблицу [BoM].Тогда, если у такого дескриптора есть два альтернативных списка компонентов (призраки?), Таблица будет выглядеть так:

BOMID, Product, GhostID
-----  -------  -------
1      Handle   1
1      Handle   2

Видите дублирование?И теперь, если продукт переименован, например, в «Бронзовый дескриптор», необходимо обновить обе строки для одного концептуального элемента.Это также вводит возможность наличия противоречивых данных, таких как

BOMID, Product,       GhostID
-----  -------        -------
1      Handle         1
1      Bronze Handle  2

---

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

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

Table: [IM_Item_Registry]
Item_Code (PK)

Table: [BOM]
BOMID (PK)
ProductID (FK)

Table: [BOM_Option]
OptionID (PK)
BOMID (FK)
Primary (boolean) - flags the primary/usual list of components
Description

Table: [Option_Items]
OptionID (FK; part of composite PK)
Item_Code (FK; part of composite PK)
Inclusion_Rate 

Столбец [BOM].[ProductID] ссылается на другую таблицу с подробной информацией о продукте, которая должна определяться отдельно от ведомостиМатериал.Если эта база данных действительно упрощенная, то это может быть просто строковое поле [Product], содержащее имя, но я предполагаю, что есть более полезные детали для хранения.Возможно, это то, на что намекает ParentID?(Я предлагаю выбирать не столь абстрактные имена, как «родитель» и «призрак», поэтому я выбрал слово «опция».)

Действительно, поскольку [BOM_Option] следует ограничить одним параметромСпецификация будет выполнять надлежащую нормализацию для создания другой таблицы, такой как

Table: [BOM_Primary]
[BOMID] (FK and PK) - Primary key so only one primary option can be defined at once
[OptionID] (FK)