Hubungan ada di mana-mana:antara orang, antara organisasi, antara organisasi dan orang. Pikirkan tentang menjadi karyawan sebuah perusahaan, menjadi anggota tim proyek, atau menjadi anak perusahaan dari perusahaan lain. Apakah ada cara langsung untuk memodelkan dan mengelola semua hubungan ini secara akurat? Bisakah kita dengan mudah menjawab pertanyaan 'Siapa yang tahu siapa?'
Tinjauan Singkat Hubungan
Persisnya bagaimana model dasar ini diturunkan dijelaskan dalam artikel saya sebelumnya, Desain Bill of Materials (BOM) yang Fleksibel dan Dapat Dikelola.
Dalam model ini dan dalam desain BOM konvensional, 1st interactor cenderung menjadi Party di Relationship – majikan daripada karyawan, pemimpin tim daripada anggota tim, dll.
Berikut tampilan datanya (dengan peran yang dimainkan masing-masing pihak dalam tanda kurung):
| 1 interaksi | 2 interaksi |
|---|---|
| Widget Co. Inc. (majikan) | Manajer 1 (karyawan) |
| Widget Co. Inc. (majikan) | Manajer 2 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 1 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 2 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 3 (karyawan) |
| Widget Co. Inc. (majikan) | Karyawan 4 (karyawan) |
| Manajer 1 (bertanggung jawab atas) | Karyawan 1 (melapor ke) |
| Manajer 1 (bertanggung jawab atas) | Karyawan 2 (melaporkan ke) |
| Manajer 2 (bertanggung jawab) | Karyawan 3 (melapor ke) |
| Manajer 2 (bertanggung jawab) | Karyawan 4 (melapor ke) |
Model yang Lebih Canggih
Bayangkan Anda ingin membuat model tim pengembangan proyek seperti berikut:
Sumber:https://www.edrawsoft.com/template-matrix -org-chart.php
Sebagian besar peran dalam hierarki tim ini nyata – mis. analis kebutuhan melapor ke analis sistem. Cara lain untuk melihatnya adalah bahwa analis sistem mengelola analis kebutuhan.
Hubungan antar role dapat dibaca dari kiri ke kanan (LTR) atau dari kanan ke kiri (RTL). Biasanya yang terbaik adalah tetap berpegang pada satu konvensi atau yang lain – LTR atau RTL – tetapi dalam praktiknya Anda mungkin menemukan bahwa ada pengecualian untuk ini.
Juga, perhatikan bahwa diagram ini menunjukkan cara yang berbeda untuk mengelompokkan peran. Beberapa peran nyata, seperti yang telah kita bahas; yang lain logis – mis. kelompok teknis, kelompok pelatihan, tim inti, dan tim pendukung.
Kita dapat mengatakan bahwa diagram ini mendefinisikan struktur tim menggunakan peran yang dibutuhkan untuk menyelesaikan tim pengembangan proyek. Ini berbeda dari contoh tim yang sebenarnya, yang akan terdiri dari nama-nama orang sungguhan untuk setiap peran.
Jadi kita membutuhkan model data yang fleksibel dan dapat dikonfigurasi , seperti ini:
Tabel kuning berisi metadata , dan tabel biru berisi data bisnis .
Menyetel Metadata Dasar
Kita akan mulai dengan mengisi party_type meja. Tabel ini membedakan apakah suatu pihak adalah orang atau organisasi.
Sebelum kita melakukan banyak hal lain, kita juga perlu mendefinisikan peran di role_type tabel metadata:
| Nama Cantik | Jenis Pesta |
|---|---|
| HM Pendapatan dan Bea Cukai (HMRC) | Organisasi |
| Layanan Pendapatan Internal (IRS) | Organisasi |
| Layanan Paspor | Organisasi |
| Sama | Organisasi |
| Perseroan Terbatas | Organisasi |
| Perusahaan Terbatas Publik | Organisasi |
| Pemohon | Orang |
| Mandiri | Orang |
| Teknik CTO | Orang |
| Manajer Proyek | Orang |
| Spesialis Proyek | Orang |
| Analis Sistem | Orang |
| Analis Persyaratan | Orang |
| Petugas Teknis | Orang |
| Administrator Sistem | Orang |
| Insinyur Perangkat Keras Senior | Orang |
| Insinyur Perangkat Keras | Orang |
| Insinyur Perangkat Lunak Senior | Orang |
| Insinyur Perangkat Lunak | Orang |
| Insinyur Basis Data | Orang |
| Dukungan Teknis | Orang |
| Manajer QA | Orang |
| Desainer Web | Orang |
| Insinyur QA Perangkat Lunak | Orang |
| Kantor Proyek | Orang |
| Insinyur Keamanan Informasi | Orang |
| Teknis | Organisasi |
| Pelatihan | Organisasi |
| Tim Inti | Organisasi |
| Tim Dukungan | Organisasi |
Anda pasti telah mencatat bahwa setiap peran adalah milik seseorang atau organisasi. Untuk memberikan gambaran tentang apa yang mungkin, saya telah menambahkan beberapa organisasi eksternal yang memiliki hubungan dengan perusahaan terbatas fiktif kami, ABC Software Inc.
Menambahkan Metadata Ketenagakerjaan
Tugas berikutnya adalah menentukan pasangan peran yang valid antara interaksi pertama dan kedua. Pada gilirannya, ini menentukan jenis hubungan yang dapat dimiliki oleh para pihak. Mari mulai mengisi role_type_relationship tabel metadata dengan peran karyawan perusahaan. Lagi pula, kami tidak dapat membuat tim tanpa terlebih dahulu memiliki pekerja:
| Jenis Peran Pertama | Jenis Peran Kedua | Arah Deskripsi | Deskripsi | Jenis Hubungan |
|---|---|---|---|---|
| Perseroan Terbatas | Teknik CTO | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Manajer Proyek | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Spesialis Proyek | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Analis Sistem | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Analis Persyaratan | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Petugas Teknis | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Administrator Sistem | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Perangkat Keras Senior | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Perangkat Keras | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Perangkat Lunak Senior | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Perangkat Lunak | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Basis Data | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Dukungan Teknis | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Manajer QA | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Desainer Web | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur QA Perangkat Lunak | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Kantor Proyek | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Insinyur Keamanan Informasi | LTR | mempekerjakan | NYATA |
| Perseroan Terbatas | Pemohon | LTR | memilih | NYATA |
Misalkan ABC Software Inc. akan mempekerjakan dua karyawan, Jane Smith dan Alex Jones, untuk peran berikut:
| Hubungan Pesta | Hubungan Jenis Peran | |||
|---|---|---|---|---|
| Interactor Pertama (Organisasi) | Interaktor Kedua (Orang) | Interactor Pertama (Peran) | Interactor ke-2 (Peran) | Deskripsi |
| ABC Software Inc. | Jane Smith | Perseroan Terbatas | Teknik CTO | mempekerjakan |
| ABC Software Inc. | Alex Jones | Perseroan Terbatas | Manajer Proyek | mempekerjakan |
Mengambil langkah mundur dalam waktu, Anda akan melihat bahwa hubungan ini dimulai sebelum Jane Smith dan Alex Jones dipekerjakan; mereka harus melamar pekerjaan di ABC Software Inc. Hubungannya akan terlihat seperti ini:
| Hubungan Pesta | Hubungan Jenis Peran | |||
|---|---|---|---|---|
| Interactor Pertama (Organisasi) | Interaktor Kedua (Orang) | Interactor Pertama (Peran) | Interactor ke-2 (Peran) | Deskripsi |
| ABC Software Inc. | Jane Smith | Perseroan Terbatas | Pemohon | memilih |
| ABC Software Inc. | Alex Jones | Perseroan Terbatas | Pemohon | memilih |
Apakah Anda mulai melihat kemungkinan bahwa pola hubungan pesta mendukung?
Kami tidak memiliki tabel bernama applicant dan tabel lain bernama employee , seperti yang dapat ditemukan dalam model lain. Jika Anda memikirkannya, mereka akan memiliki banyak atribut yang sama – nama, alamat, tanggal lahir, dll; anda harus menyalin nilai dari applicant kepada employee setelah berhasil disewa. Tetapi apakah orang-orang yang terlibat telah diubah dari satu hal menjadi hal lain? Tentu saja tidak! Mereka masih orang yang sama!
Faktanya, hanya hubungan yang berubah antara ABC Software Inc. dan Jane Smith atau Alex Jones. Dan inilah tepatnya model pola hubungan pesta.
Melanjutkan:Metadata Tim Proyek
Sebelum kita dapat membuat party_relationship tabel untuk menentukan fakta bahwa Jane Smith mengelola Alex Jones, kita harus mendefinisikan struktur tim pengembangan proyek. Ini hanyalah pertanyaan tentang memasangkan peran orang tua dan anak untuk membentuk hierarki yang valid:
| Jenis Peran Pertama | Jenis Peran Kedua | Arah Deskripsi | Deskripsi | Jenis Hubungan |
|---|---|---|---|---|
| Tim Pengembangan Proyek | Teknik CTO | RTL | prospek | NYATA |
| Teknik CTO | Manajer Proyek | LTR | mengelola | NYATA |
| Manajer Proyek | Analis Sistem | LTR | mengelola | NYATA |
| Manajer Proyek | Administrator Sistem | LTR | mengelola | NYATA |
| Manajer Proyek | Spesialis Proyek | LTR | mengelola | NYATA |
| Manajer Proyek | Insinyur Perangkat Lunak Senior | LTR | mengelola | NYATA |
| Manajer Proyek | Dukungan Teknis | LTR | mengelola | NYATA |
| Manajer Proyek | Desainer Web | LTR | mengelola | NYATA |
| Manajer Proyek | Insinyur QA Perangkat Lunak | LTR | mengelola | NYATA |
| Manajer Proyek | Kantor Proyek | LTR | mengelola | NYATA |
| Manajer Proyek | Insinyur Keamanan Informasi | LTR | mengelola | NYATA |
| Manajer Proyek | Insinyur Basis Data | LTR | mengelola | NYATA |
| Manajer Proyek | Dukungan Teknis | LTR | mengelola | NYATA |
| Manajer Proyek | Manajer QA | LTR | mengelola | NYATA |
| Analis Sistem | Analis Persyaratan | LTR | mengelola | NYATA |
| Analis Persyaratan | Petugas Teknis | LTR | mengelola | NYATA |
| Administrator Sistem | Insinyur Perangkat Keras Senior | LTR | mengelola | NYATA |
| Insinyur Perangkat Keras Senior | Insinyur Perangkat Keras | LTR | mengelola | NYATA |
| Insinyur Perangkat Lunak Senior | Insinyur Perangkat Lunak | LTR | mengelola | NYATA |
Untuk semua peran di atas, hubungan dibaca dari kiri ke kanan – mis. manajer proyek mengelola insinyur database. Atau, Anda dapat menggunakan format kanan-ke-kiri (perekayasa basis data melapor ke manajer proyek) jika itu adalah konvensi pilihan Anda.
Terakhir, kita harus mendefinisikan hubungan antara dua karyawan baru kita:
| Hubungan Pesta | Hubungan Jenis Peran | |||
|---|---|---|---|---|
| Interactor Pertama (Organisasi) | Interaktor Kedua (Orang) | Interactor Pertama (Peran) | Interactor ke-2 (Peran) | Deskripsi |
| Jane Smith | Alex Jones | Teknik CTO | Manajer Proyek | mengelola |
Tentu saja Anda dapat memiliki sejumlah tim dalam bentuk hierarki ini. Oleh karena itu, dalam arti tertentu, party_relationship adalah contoh dari role_type_relationship . Ini mirip dengan cara objek adalah turunan dari kelas dalam pemrograman OO.
Termasuk Metadata Logis
Dengan mengacu pada diagram tim pengembangan proyek, kita juga dapat mendefinisikan hubungan logis antar peran berikut ini :
| Jenis Peran Pertama | Jenis Peran Kedua | Arah Deskripsi | Deskripsi | Jenis Hubungan |
|---|---|---|---|---|
| Tim Inti | Spesialis Proyek | RTL | adalah anggota | LOGIS |
| Tim Inti | Analis Sistem | RTL | adalah anggota | LOGIS |
| Tim Inti | Analis Persyaratan | RTL | adalah anggota | LOGIS |
| Tim Inti | Petugas Teknis | RTL | adalah anggota | LOGIS |
| Tim Inti | Administrator Sistem | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Perangkat Keras Senior | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Perangkat Keras | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Perangkat Lunak Senior | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Perangkat Lunak | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Basis Data | RTL | adalah anggota | LOGIS |
| Tim Inti | Dukungan Teknis | RTL | adalah anggota | LOGIS |
| Tim Inti | Manajer QA | RTL | adalah anggota | LOGIS |
| Tim Inti | Desainer Web | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur QA Perangkat Lunak | RTL | adalah anggota | LOGIS |
| Tim Inti | Kantor Proyek | RTL | adalah anggota | LOGIS |
| Tim Inti | Insinyur Keamanan Informasi | RTL | adalah anggota | LOGIS |
| Tim Dukungan | Desainer Web | RTL | adalah anggota | LOGIS |
| Tim Dukungan | Insinyur QA Perangkat Lunak | RTL | adalah anggota | LOGIS |
| Tim Dukungan | Kantor Proyek | RTL | adalah anggota | LOGIS |
| Tim Dukungan | Insinyur Keamanan Informasi | RTL | adalah anggota | LOGIS |
Perhatikan bahwa party_relationship tidak pernah menjadi contoh dari role_type_relationship . Jadi apa gunanya mendefinisikan hubungan logis?
Yah, ini mungkin paling baik dijelaskan melalui sebuah contoh. Bayangkan Anda ingin mengirim surat kepada semua karyawan yang secara logis adalah anggota tim pendukung. Untuk membuat milis, Anda akan menulis kueri yang mengembalikan semua peran interaksi Tim Dukungan LOGIS 2 yang digabungkan ke peran interaksi REAL 2 yang sama, bergabung ke party_relationship , bergabung dengan 2 party . Ini akan memungkinkan Anda untuk mendapatkan nama dan alamat semua pihak terkait.
Kasus Khusus
Anda mungkin telah melihat beberapa entri yang tidak biasa di role_type tabel metadata, yaitu:
| Jenis Peran | Jenis Pesta |
|---|---|
| Self | Orang |
| Sama | Organisasi |
Ini adalah dua contoh kasus khusus, yang terjadi ketika suatu pihak memiliki hubungan refleksif dengan dirinya sendiri:
| Jenis Peran Pertama | Jenis Peran Kedua | Arah Deskripsi | Deskripsi | Jenis Hubungan |
|---|---|---|---|---|
| Mandiri | Analis Sistem | LTR | dipekerjakan | NYATA |
Misalnya, untuk analis sistem wiraswasta, interaksi 1 dan 2 di party_relationship merujuk kembali ke party yang sama baris – yaitu kedua kolom kunci asing berisi party.ID yang sama persis nilai.
Pentingnya Memiliki Konteks
Bayangkan kita memiliki tim analitik kecil yang pada dasarnya dibentuk dari cabang antara manajer proyek dan petugas teknis:
| Jenis Peran Pertama | Jenis Peran Kedua | Arah Deskripsi | Deskripsi | Jenis Hubungan |
|---|---|---|---|---|
| Tim Analisis Kecil | Manajer Proyek | RTL | prospek | NYATA |
| Manajer Proyek | Analis Sistem | LTR | mengelola | NYATA |
| Analis Sistem | Analis Persyaratan | LTR | mengelola | NYATA |
| Analis Persyaratan | Petugas Teknis | LTR | mengelola | NYATA |
Setiap hubungan di sini juga ada dalam struktur tim pengembangan proyek. Jadi, bagaimana kita membedakan satu manajer proyek → hubungan analis sistem dari yang lain?
Kami menggunakan konteks opsional kunci asing antara role_type_relationship dan role_type . Untuk tim analitik kecil, kami menetapkan konteks pada semua hubungan ke "tim analitik kecil", elemen tingkat atas. Dan kami melakukan hal yang sama untuk struktur tim pengembangan proyek. Saat melintasi struktur, kami melakukannya hanya untuk jenis tim yang kami minati.
Pro dan Kontra Pola BOM Hubungan Partai
Jika Anda telah membaca artikel saya yang lain tentang masalah ini, Anda mungkin menebak bahwa saya adalah penggemar pola desain Bill of Materials. Ini sederhana, tetapi sangat kuat. Peringatannya adalah bahwa itu harus digunakan dengan tepat dan harus disesuaikan agar implementasi Anda tetap dapat dikelola.
Dalam implementasi pola BOM hubungan partai ini, kami memastikan bahwa hubungan kami tetap akurat dengan terlebih dahulu menentukan hubungan yang diizinkan antara para interaktor yang ada di domain kami. Ini akan, misalnya, mencegah Internal Revenue Service dari "dipekerjakan" sebagai desainer web di ABC Software Inc.
Kemungkinan apa yang muncul dari mendefinisikan hubungan dengan cara ini? Nah, organisasi Anda mungkin perlu mengetahui untuk apa karyawan dan kontraktor Anda bekerja di organisasi lain. Ini membantu menghindari kemungkinan konflik kepentingan atau bahkan penipuan. Contohnya adalah organisasi pemberi penghargaan. Perlu diketahui di sekolah mana asesor sebelumnya mengajar untuk memastikan bahwa mereka tidak menilai kertas ujian dari sekolah tersebut. Dalam model hubungan pesta, mudah untuk menanyakan dan mendapatkan informasi tersebut.
Di sisi lain, organisasi Anda mungkin ingin menyimpan informasi yang sama karena dapat menghadirkan peluang bisnis. Itu hanya tergantung pada domain Anda.
Singkatnya, wawasan yang bisa Anda dapatkan dari data hubungan pihak yang terstruktur dengan baik bisa sangat berharga.
