Разработка базы данных материалов, инвентаря и конфигурации продукта: как отслеживать изменения - PullRequest
Новая
       39

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

0 голосов
/ 11 ноября 2019

Я буду использовать следующее соглашение для объяснения проблемы:

  • Компонент: деталь самого низкого уровня, которая может использоваться в сборке (например, электрический конденсатор).
  • Сборка: Набор компонентов и / или других сборок.
  • Продукт: экземпляр типа конструкции. «Sellable» и «buyable».

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

Тип продукта может использовать одни и те же компоненты / сборки в разных местах, которые необходимобыть отслеженным. (например, компонент с SN0001 находился в позиции «X» продукта «Y» с ноября 2010 года по ноябрь 2012 года и теперь находится в позиции «Z» продукта «K»)

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

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

Чтобы подвести итог проблемы, необходимо выполнить следующие требования:

  1. Существует "основной" тип продукта, который состоит из компонентов, сборок. , сборочные узлы, сборочные узлы и т. д., заканчивающиеся набором компонентов.
  2. Тип "основного" продукта "экземпляров" n раз (тип продукта был построен n единиц).
  3. Сборки / компоненты также могут быть продуктом.
  4. Каждый компонент / сборка имеет свой серийный номер.
  5. Компоненты / сборки должны находиться в «основном» продукте и другихтакие места, как «склад» или «мастерская».
  6. Ремонт компонента / сборки должен отслеживаться путем описания отремонтированного компонента / сборки и выполненной операции. (например, обмен сборками)
  7. Ремонт компонентов / сборок можно выполнить в «основном» продукте и / или во внешних установках (например, сборка X # SN0010 была отремонтирована путем замены конденсаторов с номером партии#YYY для других с номером партии # ZZZ платы с SN # XYZ)
  8. Изменения, выполняемые в изделиях / сборках, необходимо отслеживать по времени и положению.

Требования к используемому программному обеспечению - это, в основном, Access 2016 из-за его корпоративного инструмента, который есть у каждого в своем ноутбуке.

Так что я пробую некоторые проекты, вдохновленные сообщениями вроде: https://dba.stackexchange.com/questions/231701/databse-design-for-a-part-subassembly-list

В результате сначала в топологии БД с 5 таблицами: 

TABLE: Assemblies
    - Description: Specify the type of assembly and also its position. Also
      includes its parent assembly.
    - Elements:
        - AssemblyNameID: Primary Key. Unque ID for an assembly. (short text)
        - parentAssemblyNameID: A list of "AssemblyNameID" to perform the
          recursive tree of the assemblies/component.
    - Example:

AssemblyNameID                            | parentAssemblyNameID
-------------------------------------------------------------------
AS#VIDEO_RACK_UNIT                        |  
AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_MASTER  | AS#VIDEO_RACK_UNIT
AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_SLAVE   | AS_VIDEO_RACK_UNIT
AS#VIDEO_RECORDER                         |
AS#VIDEO_RECORDER#PCB_POWER_SUPPLY        | AS#VIDEO_RECORDER
PCB_POWER_SUPPLY                          | AS#VIDEO_RECORDER#PCB_POWER_SUPPLY


TABLE: Component: 
    - Description: A type of component/product (example: rackUnit,
      videoRecorder, capacitors). Types of components that can be replaceable  
    - Elements:
        - partName: Primary Key. Unique ID for a type of part
    - Example:

partNameID
--------------------
RECORDER_STUDIO
VIDEO_RACK_UNIT
VIDEO_RECORDER
PCB_POWER_SUPPLY
CAPACITORS

TABLE: partInstancesList
    - Description: a product of a type of part.
    - Elements:
        - partSerialNumber: PrimaryKey. This is a product that can be located
          in a position an could be fixed.
        - partName: ForeignKey: The type of part that the product is.
    - Example:

partSerialNumber    | partName
---------------------------
RECORDER_STUDIO#BCN | RECORDER_STUDIO
RECORDER_STUDIO#MAD | RECORDER_STUDIO
VIDEO_RACK_UNIT#001 | VIDEO_RACK_UNIT
VIDEO_RACK_UNIT#002 | VIDEO_RACK_UNIT
VIDEO_RECORDER#001  | VIDEO_RECORDER
VIDEO_RECORDER#002  | VIDEO_RECORDER
VIDEO_RECORDER#003  | VIDEO_RECORDER
VIDEO_RECORDER#004  | VIDEO_RECORDER
PCB_PSUPPLY#001     | PCB_POWER_SUPPLY
PCB_PSUPPLY#001     | PCB_POWER_SUPPLY
PCB_PSUPPLY#001     | PCB_POWER_SUPPLY
PCB_PSUPPLY#001     | PCB_POWER_SUPPLY
CAPS_LOTNUMBER#222  | CAPACITORS


TABLE: Master products
    - Description: Keeps information about the units build and delivered.
    - Elements: 
        - partSN: Serial number of the type of product
        - productType: ForeignKey to describe the relationship between an
          instance of a product and its family.
    - Example:

partSN              | productType
---------------------------
RECORDER_STUDIO#BCN | RECORDER_STUDIO
RECORDER_STUDIO#MAD | RECORDER_STUDIO

TABLE: AssemblyVsPart
    - Description: A table where is recorded when a "partSerialNumber" is
      mounted/unmounted in a position of an assembly. The position is referred
      to the location in an assembly and the "master" product (in this case is
      the "RECORDER_STUDIO#xxx".
    - Elements: 
        - id: Primary Key. Useful to store an unique event happened in a
          product and a master product.
        - assemblyName: ForeignKey: Contains the kind of assembly where the
          event happens.
        - partIdNumber: ForeignKey: List of serialized number parts from table
          "partInstancesList"
        - eventDate: Date when the event happens
        - eventType: what kind of event occurs (mount, unmount, repair...)
        - masterProduct: Instance of the product affected (in this case is
          RECORDER_STUDIO#xxx)
    - Example:

id | assemblyName       | partIDNumber       | eventDate | eventType | masterProduct
-------------------------------------------------------------------------
1  | AS#VIDEO_RACK_UNIT | VIDEO_RACK_UNIT#001 | 1/1/2002 | MOUNT     | RECORDER_STUDIO#BCN
2  |                    | VIDEO_RECORDER#002  | 5/10/2010| REPAIR
3  |AS#VIDEO_RACK_UNIT  | VIDEO_RECORDER#002  | 7/10/2010| MOUNT     | RECORDER_STUDIO#BCN

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

  • Первоначальный продукт находился в другой таблице, но вскоре я понял, что он должен быть в таблице сборки.
  • Я не знаю, как управлять изменениями на верхнем уровне, которые не могли бы повлиять на дочерние сборки.
  • Мне подходят таблица partSerialNumber и таблица partType.
  • Я не могу объявить, что сборка может быть составлена ​​n-раз одним и тем же узлом в таблице сборки parent-child. Пример: 
TABLE: Assemblies
AssemblyNameID (PK)                       | parentAssemblyNameID
-------------------------------------------------------------------
AS#VIDEO_RACK_UNIT                        |  
AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_MASTER  | AS#VIDEO_RACK_UNIT
AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_SLAVE   | AS_VIDEO_RACK_UNIT
AS#VIDEO_RECORDER                         | AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_MASTER
AS#VIDEO_RECORDER                         | AS#VIDEO_RACK_UNIT#VIDEO_RECORDER_SLAVE
AS#VIDEO_RECORDER#PCB_POWER_SUPPLY        | AS#VIDEO_RECORDER
PCB_POWER_SUPPLY                          | AS#VIDEO_RECORDER#PCB_POWER_SUPPLY

Это вызывает очевидную ошибку в БД, потому что я пытаюсь продублировать первичный ключ, но также верно, что VIDEO_RECORDER_SLAVE и VIDEO_RECORDER_MASTER имеют подузлы VIDEO_RECORDER.

Таким образом, результат этой итерации был следующим:

TABLE: assemblyTreeDescriptor
    - Description: Describes the products used in an assembly
    - Items:
        - AssemblyType: foreignKey: Kind of assembly
        - partType: ForeignKey: A part from part family product.
    - Example:

assemblyType       | partType
---------------------------------
AS#VIDEO_RECORDER  | PCB_POWER_SUPPLY
AS#VIDEO_RECORDER  | PCB_CONTROL
AS#PCB_POWER_SUPPLY| CAPACITORS
AS#PCB_POWER_SUPPLY| DCDC

TABLE: assemblyInstances:
    - Description: Establish a relationship between a type of assembly and its
      location in the master product.
    - Items:
        - AssemblyLocation: (PK) Location in the master product
        - assemblyID: (FK): type of assembly
    - Example:

assemblyLocation             | assemblyType
--------------------------------
AS#VIDEO_RECORDER_POS_MASTER | AS#VIDEO_RECORDER
AS#VIDEO_RECORDER_POS_SLAVE  | AS#VIDEO_RECORDER
AS#VIDEO_RECORDER#PSUPPLY    | AS#PCB_POWER_SUPPLY

TABLE: assemblies:
    - Description: Establish the parent/child relationships between assemblies
      (like the previous one but describing generic items trying to avoid
      refer it to a specific location in the master product.)

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

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

Заранее спасибо за любое предложение.

С уважением

...