Os relacionamentos estão em toda parte:entre pessoas, entre organizações, entre organizações e pessoas. Pense em ser um funcionário de uma empresa, ser membro de uma equipe de projeto ou ser uma subsidiária de outra empresa. Existe uma maneira direta de modelar e gerenciar com precisão todos esses relacionamentos? Podemos responder facilmente à pergunta "Quem sabe quem?"
Uma revisão rápida dos relacionamentos
Exatamente como esse modelo básico foi derivado foi descrito em meu artigo anterior, Projetos de lista de materiais flexíveis e gerenciáveis (BOM).
Neste modelo e no projeto BOM convencional, o
1st interactor tende a ser o Party no Relationship – empregador em vez de empregado, líder de equipe em vez de membro da equipe, etc. Aqui está a aparência dos dados (com o papel que cada parte desempenha entre parênteses):
| 1 interator | 2 interator |
|---|---|
| Widget Co. Inc. (empregador) | Gerente 1 (funcionário) |
| Widget Co. Inc. (empregador) | Gerente 2 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 1 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 2 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 3 (funcionário) |
| Widget Co. Inc. (empregador) | Funcionário 4 (funcionário) |
| Gerente 1 (responsável por) | Funcionário 1 (subordinado a) |
| Gerente 1 (responsável por) | Funcionário 2 (subordinado a) |
| Gerente 2 (responsável por) | Funcionário 3 (subordinado a) |
| Gerente 2 (responsável por) | Funcionário 4 (subordinado a) |
Um modelo mais sofisticado
Imagine que você deseja modelar uma equipe de desenvolvimento de projeto como o seguinte:
Fonte:https://www.edrawsoft.com/template-matrix -org-chart.php
A maioria dos papéis nessa hierarquia de equipe são reais – por exemplo, o analista de requisitos se reporta ao analista de sistema. Outra maneira de ver isso é que o analista de sistema gerencia o analista de requisitos.
As relações entre as funções podem ser lidas da esquerda para a direita (LTR) ou da direita para a esquerda (RTL). Normalmente, é melhor seguir uma convenção ou outra – LTR ou RTL – mas na prática você pode descobrir que há exceções a isso.
Além disso, observe que este diagrama mostra diferentes maneiras de agrupar funções. Alguns papéis são reais, como discutimos; outros são lógicos – por exemplo. o grupo técnico, o grupo de treinamento, a equipe central e a equipe de suporte.
Podemos dizer que este diagrama define a estrutura da equipe usando as funções necessárias para completar a equipe de desenvolvimento do projeto. Isso é diferente de uma instância real da equipe, que seria composta de nomes de pessoas reais em cada uma das funções.
Então, precisamos de um modelo de dados que seja flexível e configurável , como este:
As tabelas amarelas contêm metadados , e as tabelas azuis contêm dados de negócios .
Definindo metadados básicos
Começaremos preenchendo o
party_type tabela. Esta tabela diferencia se uma parte é uma pessoa ou uma organização. Antes de fazermos muito mais, também precisamos definir funções no
role_type tabela de metadados:| Belo nome | Tipo de festa |
|---|---|
| HM Revenue and Customs (HMRC) | Organização |
| Serviço de Receita Interna (IRS) | Organização |
| Serviço de passaporte | Organização |
| Igual | Organização |
| Empresa Limitada | Organização |
| Sociedade Limitada | Organização |
| Requerente | Pessoa |
| Próprio | Pessoa |
| CTO Engenharia | Pessoa |
| Gerente de Projeto | Pessoa |
| Especialista em Projetos | Pessoa |
| Analista de Sistemas | Pessoa |
| Analista de Requisitos | Pessoa |
| Escriturário Técnico | Pessoa |
| Administrador do sistema | Pessoa |
| Engenheiro de Hardware Sênior | Pessoa |
| Engenheiro de Hardware | Pessoa |
| Engenheiro de Software Sênior | Pessoa |
| Engenheiro de software | Pessoa |
| Engenheiro de banco de dados | Pessoa |
| Suporte técnico | Pessoa |
| Gerente de controle de qualidade | Pessoa |
| Web Designer | Pessoa |
| Engenheiro de controle de qualidade de software | Pessoa |
| Escritório de Projetos | Pessoa |
| Engenheiro de Segurança da Informação | Pessoa |
| Técnico | Organização |
| Treinamento | Organização |
| Equipe principal | Organização |
| Equipe de suporte | Organização |
Você sem dúvida notou que cada função pertence a uma pessoa ou a uma organização. Para dar uma ideia do que é possível, adicionei algumas organizações externas com as quais nossa empresa limitada fictícia, ABC Software Inc, tem relacionamento.
Adicionando metadados de emprego
A próxima tarefa é definir os pares de papéis válidos entre o primeiro e o segundo interagentes. Por sua vez, isso define os tipos de relacionamentos que as partes podem ter. Vamos começar a preencher o
role_type_relationship tabela de metadados com as funções dos funcionários da empresa. Afinal, não podemos criar equipes sem antes ter trabalhadores:| 1º tipo de função | 2º tipo de função | Descrição Direção | Descrição | Tipo de relacionamento |
|---|---|---|---|---|
| Empresa Limitada | CTO Engenharia | LTR | emprega | REAL |
| Empresa Limitada | Gerente de Projeto | LTR | emprega | REAL |
| Empresa Limitada | Especialista em Projetos | LTR | emprega | REAL |
| Empresa Limitada | Analista de Sistemas | LTR | emprega | REAL |
| Empresa Limitada | Analista de Requisitos | LTR | emprega | REAL |
| Empresa Limitada | Escriturário Técnico | LTR | emprega | REAL |
| Empresa Limitada | Administrador do sistema | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de Hardware Sênior | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de Hardware | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de software sênior | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de software | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de banco de dados | LTR | emprega | REAL |
| Empresa Limitada | Suporte técnico | LTR | emprega | REAL |
| Empresa Limitada | Gerente de controle de qualidade | LTR | emprega | REAL |
| Empresa Limitada | Web Designer | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de controle de qualidade de software | LTR | emprega | REAL |
| Empresa Limitada | Escritório de Projetos | LTR | emprega | REAL |
| Empresa Limitada | Engenheiro de Segurança da Informação | LTR | emprega | REAL |
| Empresa Limitada | Requerente | LTR | seleciona | REAL |
Suponha que a ABC Software Inc. vá contratar dois funcionários, Jane Smith e Alex Jones, para as seguintes funções:
| Relação da Parte | Relação de tipo de função | |||
|---|---|---|---|---|
| 1º Interator (Organização) | 2º Interator (Pessoa) | 1º Interator (Função) | 2º Interator (Função) | Descrição |
| ABC Software Inc. | Jane Smith | Empresa Limitada | CTO Engenharia | emprega |
| ABC Software Inc. | Alex Jones | Empresa Limitada | Gerente de Projeto | emprega |
Voltando no tempo, você veria que esse relacionamento começou antes de Jane Smith e Alex Jones serem contratados; eles tiveram que se candidatar a empregos na ABC Software Inc. O relacionamento seria assim:
| Relação da Parte | Relação de tipo de função | |||
|---|---|---|---|---|
| 1º Interator (Organização) | 2º Interator (Pessoa) | 1º Interator (Função) | 2º Interator (Função) | Descrição |
| ABC Software Inc. | Jane Smith | Empresa Limitada | Requerente | seleciona |
| ABC Software Inc. | Alex Jones | Empresa Limitada | Requerente | seleciona |
Você está começando a ver as possibilidades de que o padrão de relacionamento da parte apoia?
Não temos uma tabela chamada
applicant e outra tabela chamada employee , como pode ser encontrado em outros modelos. Se você pensar bem, eles compartilhariam muitos dos mesmos atributos – nome, endereço, data de nascimento, etc; você teria que copiar os valores de applicant para employee após a contratação bem-sucedida. Mas as pessoas envolvidas foram transformadas de uma coisa para outra? Claro que não! Eles ainda são as mesmas pessoas! Na verdade, é apenas o relacionamento que mudou entre a ABC Software Inc. e Jane Smith ou Alex Jones. E é exatamente isso que o padrão de relacionamento partidário modela.
Continuando:Metadados da equipe do projeto
Antes de podermos criar um
party_relationship tabela para definir o fato de que Jane Smith gerencia Alex Jones, devemos definir a estrutura da equipe de desenvolvimento do projeto. Esta é apenas uma questão de emparelhar papéis pai e filho para formar uma hierarquia válida:| 1º tipo de função | 2º tipo de função | Descrição Direção | Descrição | Tipo de relacionamento |
|---|---|---|---|---|
| Equipe de Desenvolvimento do Projeto | CTO Engenharia | RTL | leads | REAL |
| CTO Engenharia | Gerente de Projeto | LTR | gerencia | REAL |
| Gerente de Projeto | Analista de Sistemas | LTR | gerencia | REAL |
| Gerente de Projeto | Administrador do sistema | LTR | gerencia | REAL |
| Gerente de Projeto | Especialista em Projetos | LTR | gerencia | REAL |
| Gerente de Projeto | Engenheiro de software sênior | LTR | gerencia | REAL |
| Gerente de Projeto | Suporte técnico | LTR | gerencia | REAL |
| Gerente de Projeto | Web Designer | LTR | gerencia | REAL |
| Gerente de Projeto | Engenheiro de controle de qualidade de software | LTR | gerencia | REAL |
| Gerente de Projeto | Escritório de Projetos | LTR | gerencia | REAL |
| Gerente de Projeto | Engenheiro de Segurança da Informação | LTR | gerencia | REAL |
| Gerente de Projeto | Engenheiro de banco de dados | LTR | gerencia | REAL |
| Gerente de Projeto | Suporte técnico | LTR | gerencia | REAL |
| Gerente de Projeto | Gerente de controle de qualidade | LTR | gerencia | REAL |
| Analista de Sistemas | Analista de Requisitos | LTR | gerencia | REAL |
| Analista de Requisitos | Escriturário Técnico | LTR | gerencia | REAL |
| Administrador do sistema | Engenheiro de Hardware Sênior | LTR | gerencia | REAL |
| Engenheiro de Hardware Sênior | Engenheiro de Hardware | LTR | gerencia | REAL |
| Engenheiro de Software Sênior | Engenheiro de software | LTR | gerencia | REAL |
Para todos os papéis acima, o relacionamento é lido da esquerda para a direita – por exemplo, o gerente de projeto gerencia o engenheiro de banco de dados. Alternativamente, você pode adotar o formato da direita para a esquerda (o engenheiro de banco de dados se reporta ao gerente de projeto) se essa for sua convenção preferida.
Finalmente, devemos definir a relação entre nossos dois novos funcionários:
| Relação da Parte | Relação de tipo de função | |||
|---|---|---|---|---|
| 1º Interator (Organização) | 2º Interator (Pessoa) | 1º Interator (Função) | 2º Interator (Função) | Descrição |
| Jane Smith | Alex Jones | CTO Engenharia | Gerente de Projeto | gerencia |
Claro que você pode ter qualquer número de equipes na forma dessa hierarquia. Em certo sentido, portanto,
party_relationship é uma instância de role_type_relationship . Isso é semelhante ao modo como um objeto é uma instância de uma classe na programação OO. Incluindo metadados lógicos
Com referência ao diagrama da equipe de desenvolvimento do projeto, também podemos definir as seguintes relações lógicas entre funções :
| 1º tipo de função | 2º tipo de função | Descrição Direção | Descrição | Tipo de relacionamento |
|---|---|---|---|---|
| Equipe principal | Especialista em Projetos | RTL | é membro de | LÓGICA |
| Equipe principal | Analista de Sistemas | RTL | é membro de | LÓGICA |
| Equipe principal | Analista de Requisitos | RTL | é membro de | LÓGICA |
| Equipe principal | Escriturário Técnico | RTL | é membro de | LÓGICA |
| Equipe principal | Administrador do sistema | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de Hardware Sênior | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de Hardware | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de software sênior | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de software | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de banco de dados | RTL | é membro de | LÓGICA |
| Equipe principal | Suporte técnico | RTL | é membro de | LÓGICA |
| Equipe principal | Gerente de controle de qualidade | RTL | é membro de | LÓGICA |
| Equipe principal | Web Designer | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de controle de qualidade de software | RTL | é membro de | LÓGICA |
| Equipe principal | Escritório de Projetos | RTL | é membro de | LÓGICA |
| Equipe principal | Engenheiro de Segurança da Informação | RTL | é membro de | LÓGICA |
| Equipe de suporte | Web Designer | RTL | é membro de | LÓGICA |
| Equipe de suporte | Engenheiro de controle de qualidade de software | RTL | é membro de | LÓGICA |
| Equipe de suporte | Escritório de Projetos | RTL | é membro de | LÓGICA |
| Equipe de suporte | Engenheiro de Segurança da Informação | RTL | é membro de | LÓGICA |
Observe que
party_relationship nunca é uma instância de um role_type_relationship . Então, qual é o sentido de definir relações lógicas? Bem, isso é provavelmente melhor explicado por meio de um exemplo. Imagine que você deseja enviar uma carta a todos os funcionários que são logicamente membros da equipe de suporte. Para criar uma lista de e-mails, você escreveria uma consulta que retornasse todas as funções do interator LOGICAL Support Team 2 unidas às mesmas funções do interator REAL 2, unidas a
party_relationship , juntou-se ao party . Isso permitiria que você obtivesse os nomes e endereços de todos os envolvidos. Um caso especial
Você deve ter notado algumas entradas incomuns no
role_type tabela de metadados, a saber:| Tipo de função | Tipo de festa |
|---|---|
| Próprio | Pessoa |
| Igual | Organização |
Estas são duas instâncias de um caso especial, que ocorre quando uma parte tem uma relação reflexiva consigo mesma:
| 1º tipo de função | 2º tipo de função | Descrição Direção | Descrição | Tipo de relacionamento |
|---|---|---|---|---|
| Próprio | Analista de Sistemas | LTR | empregado | REAL |
Por exemplo, para um analista de sistema autônomo, os interagentes 1 e 2 em
party_relationship consulte novamente a mesma party row – ou seja, ambas as colunas de chave estrangeira contêm exatamente o mesmo party.ID valor. A importância de ter contexto
Imagine que temos uma pequena equipe de análise que é basicamente formada a partir da filial entre o gerente de projeto e o funcionário técnico:
| 1º tipo de função | 2º tipo de função | Descrição Direção | Descrição | Tipo de relacionamento |
|---|---|---|---|---|
| Pequena equipe de análise | Gerente de Projeto | RTL | leads | REAL |
| Gerente de Projeto | Analista de Sistemas | LTR | gerencia | REAL |
| Analista de Sistemas | Analista de Requisitos | LTR | gerencia | REAL |
| Analista de Requisitos | Escriturário Técnico | LTR | gerencia | REAL |
Cada um dos relacionamentos aqui também existe na estrutura da equipe de desenvolvimento do projeto. Então, como diferenciamos uma relação gerente de projeto → analista de sistema de outra?
Usamos o contexto opcional chave estrangeira entre
role_type_relationship e role_type . Para a pequena equipe de análise, definimos o contexto em todos os relacionamentos para “pequena equipe de análise”, o elemento de nível superior. E fazemos o mesmo para a estrutura da equipe de desenvolvimento do projeto. Quando percorremos a estrutura, fazemos isso apenas para o tipo de equipe em que estamos interessados. Prós e contras do padrão BOM de relacionamento com partes
Se você leu meus outros artigos sobre o assunto, provavelmente adivinhou que sou fã do padrão de design da lista de materiais. É simples, mas muito poderoso. A ressalva é que ele deve ser usado adequadamente e adaptado para que sua implementação permaneça gerenciável.
Nesta implementação de relacionamento com partes do padrão BOM, garantimos que nossos relacionamentos permaneçam precisos definindo primeiro os relacionamentos permitidos entre os interagentes que existem em nosso domínio. Isso impediria, por exemplo, que o Internal Revenue Service fosse “empregado” como web designer na ABC Software Inc.
Que possibilidades surgem ao definir relacionamentos dessa maneira? Bem, sua organização pode precisar saber para quais outras organizações seus funcionários e contratados atuais trabalharam. Isso ajuda a evitar possíveis conflitos de interesse ou até mesmo fraudes. Um exemplo disso é uma organização de premiação. Ele precisa saber em quais escolas seus avaliadores ensinaram anteriormente para garantir que eles não avaliem os exames dessas escolas. Em um modelo de relacionamento com partes, é fácil consultar e obter essas informações.
Por outro lado, sua organização pode querer armazenar as mesmas informações porque pode apresentar oportunidades de negócios. Depende apenas do seu domínio.
Em suma, os insights que você pode obter de dados bem estruturados de relacionamento com as partes podem ser inestimáveis.
