Mô hình Mối quan hệ Đảng. Làm thế nào để mô hình hóa các mối quan hệ

Mối quan hệ có ở khắp mọi nơi:giữa con người với nhau, giữa các tổ chức, giữa tổ chức và con người. Hãy nghĩ về việc trở thành nhân viên của một công ty, trở thành thành viên của nhóm dự án hoặc trở thành công ty con của một công ty khác. Có cách nào đơn giản để lập mô hình và quản lý chính xác tất cả các mối quan hệ này không? Chúng ta có thể dễ dàng trả lời câu hỏi 'Ai biết ai không?'

Đánh giá nhanh về các mối quan hệ

Cách mô tả chính xác mô hình cơ bản này đã được mô tả trong bài viết trước của tôi, Mẫu thiết kế hóa đơn nguyên vật liệu (BOM) linh hoạt và có thể quản lý được.

Trong mô hình này và trong thiết kế BOM thông thường, 1st interactor có xu hướng trở thành Party trong Relationship - người sử dụng lao động hơn là nhân viên, trưởng nhóm hơn là thành viên trong nhóm, v.v.

Dưới đây là dữ liệu có thể trông như thế nào (với vai trò của mỗi bên trong dấu ngoặc đơn):

Một mô hình phức tạp hơn

Hãy tưởng tượng rằng bạn muốn lập mô hình một nhóm phát triển dự án như sau:

Nguồn:https://www.edrawsoft.com/template-matrix -org-chart.php

Hầu hết các vai trò trong hệ thống phân cấp nhóm này là có thật - ví dụ:nhà phân tích yêu cầu báo cáo cho nhà phân tích hệ thống. Một cách nhìn khác là người phân tích hệ thống quản lý người phân tích yêu cầu.

Mối quan hệ giữa các vai trò có thể được đọc từ trái sang phải (LTR) hoặc từ phải sang trái (RTL). Thông thường tốt nhất bạn nên tuân theo quy ước này hay quy ước kia - LTR hoặc RTL - nhưng trên thực tế, bạn có thể thấy rằng có những ngoại lệ cho điều này.

Ngoài ra, hãy lưu ý rằng biểu đồ này cho thấy các cách khác nhau để nhóm các vai trò. Một số vai trò là có thật, như chúng ta đã thảo luận; những người khác là logic - ví dụ:nhóm kỹ thuật, nhóm đào tạo, nhóm nòng cốt và nhóm hỗ trợ.

Có thể nói rằng sơ đồ này xác định cấu trúc nhóm sử dụng các vai trò cần thiết để hoàn thành nhóm phát triển dự án. Điều này khác với một phiên bản thực tế của nhóm, nhóm này sẽ được tạo thành từ tên của những người thực dựa trên từng vai trò.

Vì vậy, chúng tôi cần một mô hình dữ liệu linh hoạt và có thể định cấu hình , chẳng hạn như cái này:

Các bảng màu vàng chứa siêu dữ liệu và các bảng màu xanh lam chứa dữ liệu kinh doanh .

Thiết lập siêu dữ liệu nền tảng

Chúng tôi sẽ bắt đầu bằng cách điền party_type bàn. Bảng này phân biệt một bên là một cá nhân hay một tổ chức.

Trước khi làm nhiều việc khác, chúng ta cũng cần xác định vai trò trong role_type bảng siêu dữ liệu:

Bạn không nghi ngờ gì khi lưu ý rằng mỗi vai trò thuộc về một người hoặc một tổ chức. Để đưa ra ý tưởng về những gì có thể xảy ra, tôi đã thêm một số tổ chức bên ngoài mà công ty trách nhiệm hữu hạn giả tưởng của chúng tôi, ABC Software Inc, có mối quan hệ.

Thêm siêu dữ liệu việc làm

Nhiệm vụ tiếp theo là xác định cặp vai trò hợp lệ giữa người tương tác thứ nhất và thứ hai. Đổi lại, điều này xác định các loại mối quan hệ mà các bên có thể có. Hãy bắt đầu điền role_type_relationship bảng siêu dữ liệu với các vai trò nhân viên của công ty. Xét cho cùng, chúng tôi không thể tạo nhóm mà không có công nhân trước:

Giả sử rằng ABC Software Inc. sẽ thuê hai nhân viên, Jane Smith và Alex Jones, cho các vai trò sau:

Quay ngược thời gian một bước, bạn sẽ thấy rằng mối quan hệ này bắt đầu trước khi Jane Smith và Alex Jones được thuê; họ phải nộp đơn xin việc tại ABC Software Inc. Mối quan hệ sẽ như thế này:

Bạn có bắt đầu thấy các khả năng mà mô hình mối quan hệ bên hỗ trợ?

Chúng tôi không có bảng được gọi là applicant và một bảng khác có tên employee , như có thể được tìm thấy trong các mô hình khác. Nếu bạn nghĩ về nó, họ sẽ chia sẻ nhiều thuộc tính giống nhau - tên, địa chỉ, ngày sinh, v.v.; bạn sẽ phải sao chép các giá trị từ applicant tới employee khi thuê thành công. Nhưng những người liên quan có bị biến đổi từ thứ này thành thứ khác không? Dĩ nhiên là không! Họ vẫn là những người như cũ!

Trên thực tế, đó chỉ là mối quan hệ được thay đổi giữa ABC Software Inc. và Jane Smith hoặc Alex Jones. Và đây chính xác là những gì mô hình mối quan hệ bên lập mô hình.

Tiếp tục Bật:Siêu dữ liệu Nhóm Dự án

Trước khi chúng tôi có thể tạo party_relationship để xác định thực tế là Jane Smith quản lý Alex Jones, chúng ta phải xác định cấu trúc của nhóm phát triển dự án. Đây chỉ là một câu hỏi về việc ghép nối các vai trò cha mẹ và con cái để tạo thành một hệ thống phân cấp hợp lệ:

Đối với tất cả các vai trò trên, mối quan hệ được đọc từ trái sang phải - ví dụ:người quản lý dự án quản lý kỹ sư cơ sở dữ liệu. Ngoài ra, bạn có thể áp dụng định dạng từ phải sang trái (kỹ sư cơ sở dữ liệu báo cáo cho người quản lý dự án) nếu đó là quy ước ưa thích của bạn.

Cuối cùng, chúng ta phải xác định mối quan hệ giữa hai nhân viên mới của mình:

Tất nhiên, bạn có thể có bất kỳ số lượng đội nào theo hình dạng của hệ thống phân cấp này. Do đó, theo một nghĩa nào đó, party_relationship là một ví dụ của role_type_relationship . Điều này tương tự như cách một đối tượng là một thể hiện của một lớp trong lập trình OO.

Bao gồm siêu dữ liệu lôgic

Với việc tham khảo sơ đồ nhóm phát triển dự án, chúng ta cũng có thể xác định mối quan hệ logic giữa các vai trò sau đây :

Lưu ý rằng party_relationship không bao giờ là một ví dụ của role_type_relationship . Vậy mục đích của việc xác định các mối quan hệ logic là gì?

Chà, điều này có lẽ được giải thích tốt nhất bằng một ví dụ. Hãy tưởng tượng rằng bạn muốn gửi một lá thư cho tất cả nhân viên, những người là thành viên hợp lý của nhóm hỗ trợ. Để tạo danh sách gửi thư, bạn sẽ viết một truy vấn trả về tất cả các vai trò tương tác của Nhóm hỗ trợ LOGICAL 2 đã tham gia vào cùng các vai trò tương tác REAL 2, được tham gia vào party_relationship , đã tham gia 2 người tương tác party . Điều này sẽ cho phép bạn có được tên và địa chỉ của tất cả những người có liên quan.

Một trường hợp đặc biệt

Bạn có thể nhận thấy một vài mục nhập bất thường trong role_type bảng siêu dữ liệu, cụ thể là:

Đây là hai trường hợp của trường hợp đặc biệt, xảy ra khi một bên có mối quan hệ phản xạ với chính mình:

Ví dụ:đối với một nhà phân tích hệ thống tự kinh doanh, bộ tương tác 1 và 2 trong party_relationship tham khảo lại cùng một party row - tức là cả hai cột khóa ngoại đều chứa chính xác party.ID giá trị.

Tầm quan trọng của việc có ngữ cảnh

Hãy tưởng tượng chúng ta có một nhóm phân tích nhỏ về cơ bản được thành lập từ chi nhánh giữa người quản lý dự án và thư ký kỹ thuật:

Mỗi mối quan hệ ở đây cũng tồn tại trong cấu trúc nhóm phát triển dự án. Vì vậy, làm cách nào để chúng ta phân biệt một người quản lý dự án → mối quan hệ của nhà phân tích hệ thống với một người khác?

Chúng tôi sử dụng ngữ cảnh tùy chọn khóa ngoại giữa role_type_relationship và role_type . Đối với nhóm phân tích nhỏ, chúng tôi đặt bối cảnh cho tất cả các mối quan hệ thành “nhóm phân tích nhỏ”, yếu tố cấp cao nhất. Và chúng tôi cũng làm điều tương tự đối với cấu trúc nhóm phát triển dự án. Khi xem xét cấu trúc, chúng tôi chỉ làm như vậy đối với loại nhóm mà chúng tôi quan tâm.

Ưu điểm và nhược điểm của mẫu BOM quan hệ bên

Nếu bạn đã đọc các bài viết khác của tôi về chủ đề này, bạn có thể đoán rằng tôi là một fan hâm mộ của mẫu thiết kế Bill of Materials. Nó đơn giản, nhưng rất mạnh mẽ. Lưu ý là nó phải được sử dụng một cách thích hợp và nó phải được điều chỉnh để việc triển khai của bạn vẫn có thể quản lý được.

Trong việc triển khai mối quan hệ bên này của mẫu BOM, chúng tôi đảm bảo rằng các mối quan hệ của chúng tôi vẫn chính xác bằng cách xác định trước tiên các mối quan hệ được phép giữa các bên tương tác tồn tại trong miền của chúng tôi. Ví dụ, điều này sẽ ngăn Sở Thuế vụ được “tuyển dụng” làm nhà thiết kế web tại ABC Software Inc.

Những khả năng nào phát sinh từ việc xác định các mối quan hệ theo cách này? Tổ chức của bạn có thể cần biết những nhân viên và nhà thầu hiện tại của bạn đã làm việc cho những tổ chức nào. Điều này giúp tránh xung đột lợi ích có thể xảy ra hoặc thậm chí gian lận. Một ví dụ về điều này là một tổ chức trao giải. Nó cần biết những người đánh giá của nó đã dạy ở những trường nào trước đây để đảm bảo rằng họ không đánh giá các bài kiểm tra từ những trường đó. Trong mô hình mối quan hệ bên, thật dễ dàng truy vấn và lấy thông tin đó.

Mặt khác, tổ chức của bạn có thể muốn lưu trữ cùng một thông tin vì nó có thể mang lại cơ hội kinh doanh. Nó chỉ phụ thuộc vào miền của bạn.

Nói tóm lại, thông tin chi tiết bạn có thể nhận được từ dữ liệu mối quan hệ bên được cấu trúc tốt có thể là vô giá.