sql >> Base de Datos >  >> RDS >> Database

Identificación de la estructura de la lista de materiales (BOM) en las bases de datos

El patrón de diseño de la lista de materiales (BOM) es engañosamente simple, pero increíblemente poderoso. Históricamente, se ha empleado para modelar estructuras de productos, pero el patrón se puede usar para hacer mucho más que simplemente definir una jerarquía. Este artículo presentará tres ejemplos muy diferentes para ayudarlo a reconocer el patrón en sus propios proyectos.

¿Qué es una lista de materiales o BOM?

Una lista de materiales tiene sus raíces en la fabricación. Es una lista de materias primas, subconjuntos, conjuntos intermedios, subcomponentes, piezas y las cantidades de cada uno necesarias para fabricar un producto final. Puede verlo como una descomposición jerárquica de un producto. Otros términos para lo mismo son estructura de producto, lista de materiales y lista asociada.

Para ilustrar una lista de materiales, observe el modelo conceptual a continuación. Comienza con el producto de nivel superior, Car . En términos generales, un Car tiene un Engine y un Body . En este ejemplo, hay diferentes tipos de motores:V6 y V8. Hay diferentes tipos de carrocerías:3 puertas, 5 puertas y familiar (también conocido como familiar o station wagon). El proceso de descomposición puede abarcar hasta el último tornillo y tuerca, o incluso una gota de pegamento, pero ya se hace una idea.

En el nivel más simple, está uniendo dos partes en forma de una jerarquía, una parte principal a una parte secundaria, desde la parte superior de la jerarquía hasta la parte inferior. El modelo de lista de materiales de fabricación más básico tiene este aspecto:




Esta es la estructura de lista de materiales clásica , donde una sola tabla [principal] tiene dos relaciones con una tabla de unión [secundaria].

Esta es la jerarquía de productos simple del ejemplo del automóvil:

Padre Niño Cantidad
Coche Cuerpo 1
Coche Motor 1
Motor V6 1
Motor V8 1


Las listas de materiales en la fabricación tienden a tener el mismo tipo de propiedades principales:

  • Los ensamblajes, subensamblajes y componentes individuales pueden reutilizarse . Por ejemplo, el mismo tipo de perno se puede usar en diferentes tipos de montaje.
  • A menudo es necesario que haya una cantidad específica de la jerarquía . Por ejemplo, es importante saber que un ensamblaje necesita 10 pernos, pero otro ensamblaje podría necesitar 15 pernos de la misma especificación.

Una vez que define un ensamblaje, su estructura se importa automáticamente a cualquier otro ensamblaje que lo utilice. Entonces, si ese ensamblaje cambiara, todas las demás listas de materiales que lo usan se actualizarán automáticamente. Las listas de materiales que describen subensamblajes como este se conocen como listas de materiales modulares. .

Para los fabricantes, una lista de materiales es una parte fundamental de la información del producto, un registro que enumera todo lo necesario para fabricar un producto. Se requieren técnicas de modelado avanzadas para manejar configurable productos, componentes variaciones o sustituir componentes Cambiar una pequeña parte de un producto puede tener múltiples impactos en las listas de materiales de otros productos. Sin tener esto en cuenta, la gestión de listas de materiales puede volverse bastante inmanejable.

Pero esta área especializada está más allá del alcance de este artículo. En su lugar, nos centraremos en ejemplos de dónde pueden aparecer estructuras BOM en el diseño de la base de datos. Una vez que pueda reconocer una lista de materiales, podrá hacer uso de este poderoso patrón de diseño.

Comenzaremos con un ejemplo común:la relación de muchos a muchos entre vuelos y aeropuertos.

¿Qué tiene que ver el patrón de lista de materiales con los vuelos?

Aquí está el modelo conceptual:

Imagínate en cualquier aeropuerto del mundo. Desde allí, podrás ver despegar aviones hacia otros destinos. También verás aterrizar aviones de otros destinos. Por lo tanto, existe una relación de muchos a muchos entre los aeropuertos de salida y de llegada.

Por lo general, resolvemos esta relación de muchos a muchos usando una tabla de unión:




El Flight la clase tendrá sus propios atributos, incluido flightNumber , scheduledDepartureTime y scheduledArrivalTime .

Mirando hacia atrás en nuestro modelo, podemos detectar un problema menor. Sabemos que no existen los DepartureAirport o un ArrivalAirport . Ambos son solo aeropuertos desde los que salen vuelos y a los que llegan vuelos.

Entonces fusionamos DepartureAirport y ArrivalAirport en un único airport tabla como esta:




Nuevamente, esto sigue la estructura clásica de BOM , donde una sola tabla [principal] tiene dos relaciones con una tabla de unión [secundaria].

Sin embargo, conceptualmente, hay una gran diferencia entre esto y una lista de materiales de fabricación. Esta lista de materiales no tiene una verdadera estructura jerárquica. Es completamente plano. ¿Por qué digo esto?

Se describe mejor a modo de ejemplo.

Primero, consideremos algunos datos de muestra para esta lista de materiales:

Salida Destino
Mánchester París
Mánchester Dubai
Dubai Chennai
Dubai Ciudad del Cabo


Ahora trabajaremos a través de un ejemplo. Imagina que necesitas volar de Manchester a Chennai. No hay vuelos directos. Pero puede volar desde Manchester a Dubai, la primera etapa de su viaje. Luego puede tomar otro vuelo de Dubái a Chennai, la segunda etapa de su viaje. Si bien las dos etapas forman su itinerario, ¡la segunda etapa de ninguna manera es una especie de subcomponente de la primera etapa! Por lo tanto, esta estructura es plana.

Pero tenga en cuenta la correspondencia de datos 1:1 entre los ejemplos de partes y vuelos:Coche → Manchester; Motor → Dubái; Chennai → V6.

En el ejemplo del automóvil, las partes forman una jerarquía estrechamente acoplada . En el ejemplo del aeropuerto, los vuelos se pueden atravesar para formar más conexiones débilmente acopladas entre vuelos. Para un pasajero que vuela de Manchester a Chennai, se debe crear un itinerario. Este es el resultado de una consulta, que tiene en cuenta lo que constituye una conexión, p. el tiempo mínimo y máximo entre vuelos; si se debe usar la misma aerolínea o si se permiten diferentes aerolíneas.

A continuación, veamos cómo se puede usar BOM para describir las relaciones en el modelado de datos.

Relaciones en la estructura de la lista de materiales

Con esto me refiero a las relaciones entre personas, entre organizaciones y entre organizaciones y personas. Estas son relaciones del mundo real, como alguien que es empleado de una empresa o miembro de un equipo, o de una empresa propietaria de otra empresa. El modelo conceptual se ve así:

Si tuviera que asignar esto directamente a un modelo físico, tendría tablas de unión para cada una de las relaciones de muchos a muchos. Esto puede complicarse un poco y no ayuda con la ejecución de consultas, por ejemplo, encontrar todas las relaciones de una Person tiene.

Así que probablemente sea mejor reconocer a esa Person y Organization son diferentes tipos de Party . Esto nos permite simplificar las tres relaciones de muchos a muchos en una sola:

Si sus requisitos son simples, esto puede ser suficiente. Pero en el mundo real, las cosas no suelen ser tan simples. Por ejemplo, un empleado puede dejar una empresa para viajar por el mundo por un tiempo. Cuando regresa de sus viajes, busca trabajo y es recontratado por la empresa que dejó. (¡Sucede!) El empleado, por lo tanto, tiene dos instancias separadas de una relación con este empleador, cada una con diferentes fechas de vigencia y posiblemente con una identificación de empleado diferente.

Así que la relación en sí misma requiere atributos. Esto significa otra entidad, Relationship , es necesario que los contenga:




Nuevamente, esto sigue la estructura clásica de BOM , donde una sola tabla [principal] tiene dos relaciones con una tabla de unión [secundaria].

Por convención, en este modelo el 1 interactor tiende a ser el Party en la Relationship como el empleador en lugar del empleado, o el líder del equipo en lugar del miembro del equipo.

Este patrón de lista de materiales de relación con las partes se puede utilizar para enumerar todos los empleados (2 interactor ) en una organización (1 interactor ) en el contractual nivel si quieres. Esta es una jerarquía plana de un solo nivel. También se puede usar simultáneamente para definir toda la estructura de informes de gestión (o jerarquía) en la misma organización, que puede tener cualquier número de niveles. Por ejemplo:un empleado puede trabajar bajo un contrato durante varios años, pero puede encontrarse trabajando para diferentes gerentes durante ese período (1 interactuador =responsable de; 2 interactuador =informa a). Incluso puede trabajar simultáneamente para más de un gerente.

Así es como se verían los datos (con sus respectivos roles entre paréntesis):

1 interactuador 2 interactuadores
Widget Co. Inc. (empleador) Gerente 1 (empleado)
Widget Co. Inc. (empleador) Gerente 2 (empleado)
Widget Co. Inc. (empleador) Empleado 1 (empleado)
Widget Co. Inc. (empleador) Empleado 2 (empleado)
Widget Co. Inc. (empleador) Empleado 3 (empleado)
Widget Co. Inc. (empleador) Empleado 4 (empleado)
Gerente 1 (responsable de) Empleado 1 (informa a)
Gerente 1 (responsable de) Empleado 2 (informa a)
Gerente 2 (responsable de) Empleado 3 (informa a)
Gerente 2 (responsable de) Empleado 4 (informa a)

Conozca la lista de materiales

Mientras que la lista de materiales estructura tiene sus raíces en la fabricación, se puede utilizar para diferentes propósitos , que puede variar desde algo estrictamente jerárquico y estrechamente acoplado hasta algo bastante plano y menos acoplado.

Mi esperanza es que estos ejemplos lo ayuden a reconocer el patrón BOM si existe en sus proyectos. Una vez que reconozca el patrón, comprenderá cómo debe implementarse. No tiene que reinventar la rueda cada vez, solo necesita adaptarla a sus requisitos específicos.