Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Xác định cấu trúc Hóa đơn nguyên vật liệu (BOM) trong Cơ sở dữ liệu

Mẫu thiết kế bill of material (BOM) được đánh giá là đơn giản nhưng vô cùng mạnh mẽ. Trong lịch sử, nó được sử dụng để lập mô hình cấu trúc sản phẩm, nhưng mô hình này có thể được sử dụng để làm nhiều việc hơn là chỉ đơn giản là xác định hệ thống phân cấp. Bài viết này sẽ giới thiệu ba ví dụ rất khác nhau để giúp bạn nhận ra mô hình trong các dự án của riêng mình.

Hóa đơn nguyên vật liệu hay BOM là gì?

A hóa đơn nguyên vật liệu có nguồn gốc từ sản xuất. Nó là danh sách các nguyên vật liệu thô, cụm phụ, cụm trung gian, thành phần phụ, bộ phận và số lượng của từng nguyên liệu cần thiết để sản xuất một sản phẩm cuối cùng. Bạn có thể xem nó như một sự phân rã theo thứ bậc của một sản phẩm. Các thuật ngữ khác cho điều tương tự là cấu trúc sản phẩm, hóa đơn nguyên vật liệu và danh sách liên quan.

Để minh họa một BOM, hãy xem mô hình khái niệm bên dưới. Nó bắt đầu với sản phẩm cấp cao nhất, Car . Nói rộng ra, một CarEngineBody . Trong ví dụ này, có các loại động cơ khác nhau:V6 và V8. Có các loại thân:3 cửa, 5 cửa và điền trang (còn được gọi là toa xe hoặc toa xe ga). Quá trình phân hủy có thể diễn ra đến tận cái đai ốc và chốt cuối cùng - hoặc thậm chí là bôi keo - nhưng bạn sẽ có được bức tranh.

Ở cấp độ đơn giản nhất, bạn đang kết hợp hai phần với nhau dưới dạng phân cấp - một phần mẹ đến một phần con - từ trên cùng của hệ thống phân cấp phải xuống dưới cùng. Mô hình BOM sản xuất cơ bản nhất trông giống như sau:




Đây là cấu trúc BOM cổ điển , trong đó một bảng [cha] duy nhất có hai mối quan hệ với một bảng nối [con].

Dưới đây là phân cấp sản phẩm đơn giản từ ví dụ Xe hơi:

Parent Con Số lượng
Car Phần thân 1
Xe ô tô Động cơ 1
Động cơ V6 1
Động cơ V8 1


Các BOM trong lĩnh vực sản xuất có xu hướng có cùng một loại đặc tính chính:

  • Các cụm, cụm con và các thành phần riêng lẻ có thể được sử dụng lại . Ví dụ, cùng một loại bu lông có thể được sử dụng trong các kiểu lắp ráp khác nhau.
  • Thường cần phải có số lượng cụ thể theo thứ bậc . Ví dụ:điều quan trọng là phải biết rằng một tổ hợp cần 10 bu lông, nhưng một tổ hợp khác có thể cần 15 bu lông có cùng thông số kỹ thuật.

Sau khi bạn xác định một lắp ráp, cấu trúc của nó sẽ tự động được nhập vào bất kỳ hệ thống lắp ráp nào khác sử dụng nó. Vì vậy, nếu tổ hợp đó thay đổi, thì tất cả các BOM khác sử dụng nó sẽ tự động được cập nhật. Các BOM mô tả các cụm con như thế này được gọi là BOM mô-đun .

Đối với các nhà sản xuất, BOM là một thông tin quan trọng về sản phẩm, một hồ sơ liệt kê mọi thứ cần thiết để sản xuất một sản phẩm. Các kỹ thuật mô hình hóa nâng cao được yêu cầu để xử lý có thể định cấu hình sản phẩm, biến thể thành phần hoặc thay thế các thành phần. Việc thay đổi một phần nhỏ của sản phẩm có thể có nhiều tác động đến các BOM sản phẩm khác. Nếu không tính đến những điều này, việc quản lý BOM có thể trở nên khó quản lý.

Nhưng lĩnh vực chuyên môn này nằm ngoài phạm vi của bài báo này. Thay vào đó, chúng tôi sẽ tập trung vào các ví dụ về nơi cấu trúc BOM có thể xuất hiện trong thiết kế cơ sở dữ liệu. Khi bạn có thể nhận ra BOM, bạn sẽ có thể sử dụng mẫu thiết kế mạnh mẽ này.

Chúng ta sẽ bắt đầu với một ví dụ phổ biến:mối quan hệ nhiều-nhiều giữa các chuyến bay và sân bay.

Mẫu Hóa đơn Nguyên vật liệu có Liên quan gì đến Chuyến bay?

Đây là mô hình khái niệm:

Hãy tưởng tượng bạn đang ở bất kỳ sân bay nào trên thế giới. Từ đó, bạn sẽ có thể nhìn thấy máy bay cất cánh đến các điểm đến khác. Bạn cũng sẽ thấy máy bay hạ cánh từ các điểm đến khác. Vì vậy, có rất nhiều mối quan hệ giữa sân bay khởi hành và sân bay đến.

Thông thường, chúng tôi giải quyết mối quan hệ nhiều-nhiều này bằng cách sử dụng bảng nối:




Flight lớp sẽ có các thuộc tính riêng, bao gồm flightNumber , scheduledDepartureTimescheduledArrivalTime .

Nhìn lại mô hình của chúng tôi, chúng tôi có thể phát hiện ra một vấn đề nhỏ. Chúng tôi biết rằng không có thứ gọi là DepartureAirport hoặc ArrivalAirport . Cả hai đều chỉ là các sân bay mà các chuyến bay khởi hành và các chuyến bay đến.

Vì vậy, chúng tôi hợp nhất DepartureAirportArrivalAirport vào một airport bảng như thế này:




Một lần nữa, điều này tuân theo cấu trúc BOM cổ điển , trong đó một bảng [cha] duy nhất có hai mối quan hệ với một bảng nối [con].

Mặc dù vậy, về mặt khái niệm, có sự khác biệt lớn giữa điều này và BOM sản xuất. BOM này không có cấu trúc phân cấp thực sự. Nó hoàn toàn bằng phẳng. Tại sao tôi nói điều này?

Nó được mô tả tốt nhất bằng một ví dụ.

Trước tiên, hãy xem xét một số dữ liệu mẫu cho BOM này:

Khởi hành Điểm đến
Manchester Paris
Manchester Dubai
Dubai Chennai
Dubai Thành phố Cape


Bây giờ chúng ta sẽ làm việc thông qua một ví dụ. Hãy tưởng tượng bạn cần bay từ Manchester đến Chennai. Không có chuyến bay trực tiếp. Nhưng bạn có thể bay từ Manchester đến Dubai, chặng đầu tiên của hành trình. Sau đó, bạn có thể đáp một chuyến bay khác từ Dubai đến Chennai, chặng thứ hai trong hành trình của bạn. Trong khi hai chặng tạo nên hành trình của bạn, thì chặng thứ hai không phải là một thành phần phụ của chặng đầu tiên! Do đó, cấu trúc này là phẳng.

Nhưng lưu ý sự tương ứng của dữ liệu 1:1 giữa các bộ phận và các ví dụ về chuyến bay:Car → Manchester; Động cơ → Dubai; Chennai → V6.

Trong ví dụ về ô tô, các bộ phận tạo thành hệ thống phân cấp kết hợp chặt chẽ . Trong ví dụ về sân bay, các chuyến bay có thể được chuyển qua để tạo thêm kết nối lỏng lẻo giữa các chuyến bay. Đối với hành khách bay từ Manchester đến Chennai, cần phải tạo một hành trình. Đây là kết quả của một truy vấn, có tính đến những gì tạo thành kết nối - ví dụ:thời gian tối thiểu và tối đa giữa các chuyến bay; liệu phải sử dụng cùng một hãng hàng không hoặc nếu các hãng hàng không khác nhau được phép.

Tiếp theo, hãy xem cách BOM có thể được sử dụng để mô tả các mối quan hệ trong mô hình dữ liệu.

Các mối quan hệ trong cấu trúc BOM

Ý tôi là mối quan hệ giữa con người, giữa các tổ chức và giữa tổ chức với con người. Đây là những mối quan hệ trong thế giới thực, chẳng hạn như một người là nhân viên của một công ty hoặc thành viên của một nhóm, hoặc của một công ty sở hữu một công ty khác. Mô hình khái niệm trông như thế này:

Nếu bạn ánh xạ điều này trực tiếp đến một mô hình vật lý, bạn sẽ có các bảng nối cho từng mối quan hệ nhiều-nhiều. Điều này có thể hơi lộn xộn và nó không giúp ích gì cho việc chạy các truy vấn - ví dụ:tìm tất cả các mối quan hệ với một Person có.

Vì vậy, có lẽ tốt hơn nên nhận ra PersonOrganization là các loại Party . Điều này cho phép chúng tôi đơn giản hóa ba mối quan hệ nhiều-nhiều thành một mối quan hệ duy nhất:

Nếu yêu cầu của bạn là đơn giản, điều này có thể đủ. Nhưng trong thế giới thực, mọi thứ không đơn giản như vậy. Ví dụ, một nhân viên có thể rời công ty để đi du lịch vòng quanh thế giới trong một thời gian. Khi anh ấy trở về sau chuyến du lịch của mình, anh ấy tìm việc làm và được thuê lại bởi công ty mà anh ấy đã rời đi. (Điều đó xảy ra!) Do đó, nhân viên có hai trường hợp riêng biệt về mối quan hệ với người sử dụng lao động này, mỗi trường hợp có ngày hiệu lực khác nhau và có thể có ID nhân viên khác.

Vì vậy, bản thân mối quan hệ yêu cầu các thuộc tính. Điều này có nghĩa là một thực thể khác, Relationship , bắt buộc phải chứa chúng:




Một lần nữa, điều này tuân theo cấu trúc BOM cổ điển , trong đó một bảng [cha] duy nhất có hai mối quan hệ với một bảng nối [con].

Theo quy ước, trong mô hình này, 1 người tương tác có xu hướng trở thành Party trong Relationship chẳng hạn như người sử dụng lao động thay vì nhân viên, hoặc trưởng nhóm hơn là thành viên trong nhóm.

Mẫu BOM mối quan hệ bên này có thể được sử dụng để liệt kê tất cả các nhân viên (2 interactor ) trong một tổ chức (1 interactor ) theo hợp đồng mức độ nếu bạn muốn. Đây là một hệ thống phân cấp đơn, phẳng. Nó cũng có thể được sử dụng đồng thời để xác định toàn bộ cấu trúc báo cáo quản lý (hoặc thứ bậc) trong cùng một tổ chức, có thể có bất kỳ số cấp nào. Ví dụ:một nhân viên có thể làm việc theo một hợp đồng trong một số năm nhưng có thể thấy mình làm việc cho những người quản lý khác nhau trong khoảng thời gian đó (1 người tương tác =chịu trách nhiệm; 2 người tương tác =báo cáo cho). Anh ta thậm chí có thể làm việc đồng thời cho nhiều người quản lý.

Dưới đây là dữ liệu có thể trông như thế nào (với các vai trò tương ứng của chúng trong ngoặc đơn):

1 người tương tác 2 người tương tác
Widget Co. Inc. (nhà tuyển dụng) Người quản lý 1 (nhân viên)
Widget Co. Inc. (nhà tuyển dụng) Người quản lý 2 (nhân viên)
Widget Co. Inc. (nhà tuyển dụng) Nhân viên 1 (nhân viên)
Widget Co. Inc. (nhà tuyển dụng) Nhân viên 2 (nhân viên)
Widget Co. Inc. (nhà tuyển dụng) Nhân viên 3 (nhân viên)
Widget Co. Inc. (nhà tuyển dụng) Nhân viên 4 (nhân viên)
Người quản lý 1 (chịu trách nhiệm) Nhân viên 1 (báo cáo)
Người quản lý 1 (chịu trách nhiệm) Nhân viên 2 (báo cáo)
Người quản lý 2 (chịu trách nhiệm) Nhân viên 3 (báo cáo)
Người quản lý 2 (chịu trách nhiệm) Nhân viên 4 (báo cáo)

Tìm hiểu về BOM

Trong khi hóa đơn vật liệu cấu trúc có nguồn gốc từ sản xuất, nó có thể được sử dụng cho các mục đích khác nhau , có thể bao gồm từ thứ gì đó có thứ bậc nghiêm ngặt và được kết hợp chặt chẽ với thứ gì đó khá phẳng và được liên kết lỏng lẻo hơn.

Tôi hy vọng rằng những ví dụ này sẽ giúp bạn nhận ra mô hình BOM nếu nó tồn tại trong các dự án của bạn. Một khi bạn nhận ra mô hình, bạn sẽ hiểu nó nên được triển khai như thế nào. Bạn không phải phát minh lại bánh xe mỗi lần - bạn chỉ cần điều chỉnh nó theo yêu cầu cụ thể của mình.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Mô hình dữ liệu cho ứng dụng đặt lịch hẹn khám bệnh

  2. Cách xử lý số chia cho số 0 trong SQL

  3. Thực hiện kiểm toán thay đổi dữ liệu bằng bảng tạm thời

  4. Ghi nhật ký tối thiểu với CHÈN… CHỌN vào Bảng đống

  5. Phân tích cú pháp các giá trị mặc định của tham số bằng PowerShell - Phần 2