Modello di relazione di partito. Come modellare le relazioni

Le relazioni sono ovunque:tra persone, tra organizzazioni, tra organizzazioni e persone. Pensa all'essere un dipendente di un'azienda, essere un membro di un team di progetto o essere una filiale di un'altra azienda. Esiste un modo semplice per modellare e gestire accuratamente tutte queste relazioni? Possiamo facilmente rispondere alla domanda "Chissà chi?"

Una rapida rassegna delle relazioni

Il modo esatto in cui è stato derivato questo modello di base è stato descritto nel mio articolo precedente, Disegni di distinte base flessibili e gestibili.

In questo modello e nella progettazione BOM convenzionale, il 1st interactor tende ad essere il Party nel Relationship – datore di lavoro anziché dipendente, team leader anziché membro del team, ecc.

Ecco come potrebbero apparire i dati (con il ruolo svolto da ciascuna parte tra parentesi):

Un modello più sofisticato

Immagina di voler modellare un team di sviluppo del progetto come il seguente:

Fonte:https://www.edrawsoft.com/template-matrix -org-chart.php

La maggior parte dei ruoli in questa gerarchia del team sono reali, ad es. l'analista dei requisiti riporta all'analista di sistema. Un altro modo di vedere è che l'analista di sistema gestisce l'analista dei requisiti.

Le relazioni tra i ruoli possono essere lette da sinistra a destra (LTR) o da destra a sinistra (RTL). Normalmente è meglio attenersi a una convenzione o all'altra, LTR o RTL, ma in pratica potresti scoprire che esistono delle eccezioni.

Si noti inoltre che questo diagramma mostra diversi modi di raggruppare i ruoli. Alcuni ruoli sono reali, come abbiamo discusso; altri sono logici, ad es. il gruppo tecnico, il gruppo di formazione, il core team e il team di supporto.

Possiamo dire che questo diagramma definisce la struttura del team utilizzando i ruoli necessari per completare il team di sviluppo del progetto. Questo è distinto da un'istanza reale della squadra, che sarebbe composta da nomi di persone reali contro ciascuno dei ruoli.

Quindi abbiamo bisogno di un modello di dati che sia flessibile e configurabile , come questo:

Le tabelle gialle contengono metadati e le tabelle blu contengono dati aziendali .

Impostazione dei metadati di base

Inizieremo compilando il party_type tavolo. Questa tabella distingue se una parte è una persona o un'organizzazione.

Prima di fare molto altro, dobbiamo anche definire i ruoli nel role_type tabella dei metadati:

Hai senza dubbio notato che ogni ruolo appartiene a una persona o a un'organizzazione. Per dare un'idea di ciò che è possibile, ho aggiunto alcune organizzazioni esterne con cui la nostra società per azioni fittizia, ABC Software Inc, ha rapporti.

Aggiunta di metadati sull'occupazione

Il prossimo compito è definire le coppie di ruoli valide tra il primo e il secondo interlocutore. A sua volta, questo definisce i tipi di relazioni che le parti possono avere. Iniziamo a compilare il role_type_relationship tabella di metadati con i ruoli dei dipendenti dell'azienda. Dopotutto, non possiamo creare team senza prima avere lavoratori:

Supponiamo che ABC Software Inc. assumerà due dipendenti, Jane Smith e Alex Jones, per i seguenti ruoli:

Facendo un passo indietro nel tempo, vedresti che questa relazione è iniziata prima che Jane Smith e Alex Jones fossero assunti; hanno dovuto fare domanda per un lavoro presso ABC Software Inc. La relazione sarebbe stata simile a questa:

Stai iniziando a vedere le possibilità che il modello di relazione tra le parti supporta?

Non abbiamo una tabella chiamata applicant e un'altra tabella chiamata employee , come si può trovare in altri modelli. Se ci pensi, condividerebbero molti degli stessi attributi:nome, indirizzo, data di nascita, ecc; dovresti copiare i valori da applicant a employee dopo l'assunzione di successo. Ma le persone coinvolte sono state trasformate da una cosa in un'altra? Ovviamente no! Sono sempre le stesse persone!

In realtà, è solo il rapporto che è cambiato tra ABC Software Inc. e Jane Smith o Alex Jones. E questo è esattamente ciò che modella il modello di relazione di partito.

Continuare:Metadati del team di progetto

Prima di poter creare una party_relationship tabella per definire il fatto che Jane Smith gestisce Alex Jones, dobbiamo definire la struttura del team di sviluppo del progetto. Questa è solo una questione di abbinamento dei ruoli genitore e figlio per formare una gerarchia valida:

Per tutti i ruoli di cui sopra, la relazione viene letta da sinistra a destra, ad es. il project manager gestisce il database engineer. In alternativa, puoi adottare il formato da destra a sinistra (l'ingegnere del database riporta al project manager) se questa è la tua convenzione preferita.

Infine, dobbiamo definire il rapporto tra i nostri due nuovi dipendenti:

Ovviamente puoi avere un numero qualsiasi di squadre nella forma di questa gerarchia. In un certo senso, quindi, party_relationship è un'istanza di role_type_relationship . Questo è simile al modo in cui un oggetto è un'istanza di una classe nella programmazione OO.

Compresi i metadati logici

Con riferimento al diagramma del team di sviluppo del progetto, possiamo anche definire le seguenti relazioni logiche tra ruoli :

Tieni presente che party_relationship non è mai un'istanza di un role_type_relationship . Allora a che serve definire relazioni logiche?

Bene, questo è probabilmente spiegato meglio a titolo di esempio. Immagina di voler inviare una lettera a tutti i dipendenti che sono logicamente membri del team di supporto. Per creare una mailing list, dovresti scrivere una query che restituisca tutti i ruoli di interazione del LOGICAL Support Team 2 uniti agli stessi ruoli di interazione REAL 2, uniti a party_relationship , unito al 2 interlocutore party . Ciò ti consentirebbe di ottenere i nomi e gli indirizzi di tutti gli interessati.

Un caso speciale

Potresti aver notato un paio di voci insolite nel role_type tabella di metadati, ovvero:

Questi sono due casi di un caso speciale, che si verifica quando una parte ha una relazione riflessiva con se stessa:

Ad esempio, per un analista di sistema autonomo, gli interagenti 1 e 2 in party_relationship fare riferimento alla stessa party riga, ovvero entrambe le colonne della chiave esterna contengono esattamente lo stesso party.ID valore.

L'importanza di avere un contesto

Immagina di avere un piccolo team di analisi formato sostanzialmente dal ramo tra il project manager e l'impiegato tecnico:

Ciascuna delle relazioni qui esiste anche nella struttura del team di sviluppo del progetto. Quindi, come possiamo differenziare un rapporto tra project manager → analista di sistema da un altro?

Usiamo il contesto opzionale chiave esterna tra role_type_relationship e role_type . Per il piccolo team di analisi, impostiamo il contesto su tutte le relazioni con il "piccolo team di analisi", l'elemento di primo livello. E facciamo lo stesso genere di cose per la struttura del team di sviluppo del progetto. Quando attraversiamo la struttura, lo facciamo solo per il tipo di squadra che ci interessa.

Pro e contro del modello di distinta base delle relazioni tra le parti

Se hai letto i miei altri articoli sull'argomento, probabilmente hai indovinato che sono un fan del modello di progettazione Bill of Materials. È semplice, ma molto potente. L'avvertenza è che deve essere utilizzata in modo appropriato e adattata in modo che la tua implementazione rimanga gestibile.

In questa implementazione delle relazioni tra parti del modello BOM, ci assicuriamo che le nostre relazioni rimangano accurate definendo innanzitutto le relazioni consentite tra gli interagenti che esistono nel nostro dominio. Ciò, ad esempio, impedirebbe all'Internal Revenue Service di essere "assunto" come web designer presso ABC Software Inc.

Quali possibilità emergono dalla definizione di relazioni in questo modo? Bene, la tua organizzazione potrebbe aver bisogno di sapere per quali altre organizzazioni hanno lavorato i tuoi attuali dipendenti e appaltatori. Questo aiuta a evitare possibili conflitti di interesse o addirittura frodi. Un esempio di questo è un'organizzazione di aggiudicazione. Ha bisogno di sapere in quali scuole i suoi valutatori hanno insegnato in precedenza per assicurarsi che non valutino le carte d'esame di quelle scuole. In un modello di relazione di partito, è facile interrogare e ottenere tali informazioni.

D'altra parte, la tua organizzazione potrebbe voler archiviare le stesse informazioni perché potrebbero presentare opportunità di business. Dipende solo dal tuo dominio.

In breve, le informazioni che puoi ottenere da dati ben strutturati sulle relazioni tra le parti possono essere inestimabili.