Modelo de Informações da Nuvem

O Cloud Information Model (CIM) é um esquema aberto e independente de aplicação para descrever as entidades que circulam em uma empresa moderna: partes, produtos, pedidos, pagamentos e os relacionamentos que os unem. Em vez de inventar um modelo de dados personalizado para cada integração, o CIM oferece um vocabulário compartilhado para que um CRM, um ERP, uma plataforma de comércio e um armazém analítico possam concordar sobre o que realmente significa um “Pedido de Venda” ou um “Tipo de Relacionamento de Produto”. Este artigo percorre os grupos de entidades que compõem o modelo e, em seguida, detalha uma entidade representativa — ProductRelationshipType — para mostrar como o CIM expressa relacionamentos, papéis e chaves na prática.

Principais Conclusões

• O CIM organiza os dados empresariais em grupos de entidades (Parte, Produto, Pedido de Venda, Pagamento e outros) que podem ser adotados de forma incremental, em vez de todos de uma vez.
• Cada entidade é definida com uma URI de Termo, uma descrição, propriedades escalares e propriedades de link — uma estrutura que mapeia claramente para JSON-LD, RDF e armazenamentos de grafos de propriedades.
• Entidades de relacionamento como ProductRelationshipType codificam papéis (pai/filho) para que bundles, opções e coberturas possam ser modelados sem a necessidade de codificar a lógica de negócios (hard-coding).
• O modelo é deliberadamente independente de aplicação: ele descreve o que os dados significam, não como um determinado fornecedor os armazena.
• A adoção do CIM é um exercício de mapeamento, não uma substituição total (rip-and-replace) — você alinha os sistemas existentes a termos compartilhados e reconcilia as lacunas.

Por que um Modelo Compartilhado é Importante

A integração empresarial tem um modo de falha familiar: cada sistema fala seu próprio dialeto. O Salesforce chama de Account, o SAP chama de Business Partner e um serviço de faturamento interno chama de Customer. Quando você cria mapeamentos ponto a ponto entre cada par, o número de traduções cresce com o quadrado dos sistemas envolvidos, e cada novo sistema multiplica a carga de manutenção.

Um modelo canônico resolve esse problema quadrático. Você mapeia cada sistema uma vez para o modelo compartilhado, e o modelo compartilhado se torna o hub. Este é o mesmo instinto arquitetônico por trás de padrões como OAGIS (Open Applications Group Integration Specification), o Common Warehouse Metamodel da OMG e o vocabulário de comércio do schema.org.

O CIM segue essa tradição, mas é dimensionado para a interoperabilidade da era da nuvem e publicado como termos abertos com URIs desreferenciáveis.

A recompensa prática é que um arquiteto de dados pode responder a perguntas como “quais sistemas detêm o registro autoritativo de uma Parte?” ou “como representamos um bundle de produtos de forma consistente no catálogo e no pedido?” usando um único ponto de referência.

Visão Geral dos Grupos de Entidades

O CIM não é um esquema monolítico único; é um conjunto de grupos fracamente acoplados. Os grupos nomeados no modelo incluem:

Related: Fivetran — O pipeline ELT totalmente gerenciado que continua funcionando.

• Account — o contexto de relacionamento comercial de uma parte.
• Contact Point — números de telefone, endereços de e-mail e canais de acessibilidade semelhantes.
• Lead — uma parte prospectiva ainda não qualificada.
• Party e Party Role — o conceito geral de um ator e os papéis que ele desempenha (cliente, fornecedor, funcionário).
• Payment e Payment Method — como o dinheiro se move e os instrumentos utilizados.
• Product Attribute, Product Catalog e Product — os bens e serviços vendáveis e descritíveis.
• Sales Order e sua grande família de subentidades — o coração transacional do modelo.
• Shipment — atendimento e logística.

O grupo Sales Order é, de longe, o mais granular, e vale a pena entender o porquê. Um pedido é onde as regras de negócio se concentram: preços, impostos, ajustes, agrupamentos de entrega e notas por linha, todos anexados a ele.

O CIM decompõe o pedido em muitas entidades pequenas — Sales Order Product, Sales Order Price Adjustment, Sales Order Tax, Sales Order Delivery Group, Sales Order Payment Summary, Sales Order Change Log e mais — em vez de uma única tabela larga. Essa decomposição é uma escolha deliberada de design: ela permite que cada preocupação evolua de forma independente e permite que os sistemas assinem apenas as fatias que lhes interessam.

Anatomia de uma Entidade CIM

Cada entidade no CIM segue o mesmo formato, o que torna o modelo previsível para consumo programático. Considere ProductRelationshipType, a entidade que descreve por que dois produtos estão relacionados.

Se você estiver comprando: Boomi AtomSphere — Enterprise iPaaS para integração híbrida de nuvem local.

• URI do Termo — http://cloudinformationmodel.org/model/ProductRelationshipType. Este é o identificador globalmente exclusivo do conceito. Por ser uma URI, pode ser desreferenciada e usada diretamente em grafos RDF/JSON-LD.
• Descrição — “Razões pelas quais os produtos estão relacionados, como bundle, opção ou cobertura.” Isso indica que a entidade é um tipo ou classificação, e não a instância do relacionamento em si.
• Propriedades Escalares — os campos primitivos que transportam dados.
• Propriedades de Link — referências a outras entidades. ProductRelationshipType não possui nenhuma, o que por si só é informativo: é uma entidade folha, um vocabulário controlado em vez de um hub.

As propriedades escalares são:

Propriedade	URI do Termo	Intervalo	Obrigatório	Descrição
id	.../model/id	guid	sim	Chave primária
parentProductRole	.../model/parentProductRole	string	sim	O primeiro papel no relacionamento, ex: “Consists of”
childProductRole	.../model/childProductRole	string	sim	O segundo papel no relacionamento, ex: “Component of”

O fato de o id ser um GUID é uma convenção significativa: significa que os identificadores são globalmente únicos sem a necessidade de coordenação entre sistemas, que é exatamente o que se deseja quando registros são criados em nuvens diferentes e posteriormente mesclados.

Modelando Relacionamentos com Papéis

A parte mais instrutiva de ProductRelationshipType é o par de propriedades de papel. Um relacionamento de produto é direcional, e o CIM captura essa direção com dois papéis nomeados em vez de uma única string de “tipo” opaca.

Pense em um pacote. Um “Kit Inicial” consiste em um “Roteador” e um “Cabo”. Em termos de CIM:

• O produto pai desempenha a função descrita por parentProductRole — por exemplo, “Consiste em”.
• O produto filho desempenha a função descrita por childProductRole — por exemplo, “Componente de”.

Ao armazenar ambas as funções como strings no tipo, você obtém uma definição reutilizável. Qualquer número de links reais de produto para produto pode fazer referência à mesma linha ProductRelationshipType, portanto, o vocabulário permanece pequeno e consistente enquanto as instâncias de relacionamento permanecem numerosas. Este é um padrão de normalização clássico: separe o tipo de relacionamento de suas instâncias.

A descrição nomeia explicitamente três “sabores” — pacote, opção e cobertura — o que sugere a gama de semânticas comerciais que o modelo pretende cobrir:

Related: Matillion — ELT push-down desenvolvido para data warehouses em nuvem.

• Pacote — produtos vendidos juntos como uma unidade (pai “consiste em” filhos).
• Opção — uma escolha ou complemento associado a um produto base.
• Cobertura — um produto que envolve ou protege outro, comum em contextos de seguro e garantia.

Como Decidir Seu Vocabulário de Funções

Como parentProductRole e childProductRole são strings de formato livre, o modelo não dita sua redação exata. Essa flexibilidade é tanto um recurso quanto um risco. Algumas regras práticas:

1. Escolha um vocabulário controlado e congele-o. Concorde com um pequeno conjunto de frases de função (“Consiste em” / “Componente de”, “Complemento opcional para” / “Tem opção”) e documente-as. Texto livre convida à deriva.
2. Mantenha as funções simétricas e legíveis em ambas as direções. Um bom teste: você consegue ler o relacionamento em voz alta de qualquer extremidade e ele faz sentido?
3. Não sobrecarregue as funções com lógica de negócios. Se uma função precisa de comportamento condicional, essa lógica pertence à aplicação consumidora, não à string.
4. Versione seu vocabulário. Ao adicionar uma função, trate-a como uma alteração de esquema com um caminho de migração, não como uma inserção ad-hoc.

Adotando o CIM na Prática

Adotar um modelo canônico é uma disciplina de mapeamento, não uma migração. Uma sequência viável:

• Inventarie seus sistemas de registro. Para cada grupo de entidades, decida qual sistema é autoritativo. Party pode residir no CRM; Product no PIM; Sales Order no ERP.
• Mapeie cada fonte para os termos CIM. Construa uma tabela de campo de origem $\rightarrow$ propriedade CIM. Onde uma fonte não tem equivalente, anote a lacuna; onde o CIM não tem equivalente, anote a extensão.
• Reconcilie identificadores. A convenção de GUID do CIM significa que você normalmente manterá uma tabela de correspondência (crosswalk) entre chaves nativas e valores id do CIM.
• Escolha uma serialização. Os termos baseados em URI do CIM mapeiam-se naturalmente para JSON-LD e RDF; eles também se traduzem perfeitamente para tabelas relacionais ou um grafo de propriedades. O modelo não impõe uma tecnologia de armazenamento.
• Governe o vocabulário. As strings de função, enumerações e extensões que você adicionar são as partes com maior probabilidade de sofrer deriva, portanto, coloque-as sob controle de mudanças.

Um modelo mental útil é tratar o CIM como o esquema de intercâmbio e seus repositórios operacionais como o sistema de registro. Você não está pedindo que cada aplicação abandone seu modelo nativo; está pedindo que publiquem e consumam um modelo compartilhado nas fronteiras.

Favorito do leitor: Airbyte — ELT de código aberto com opção de nuvem gerenciada.

Ressalvas e Trade-offs

Nenhum modelo canônico é isento de custos, e o CIM não é exceção.

• A abstração tem um preço. Um modelo geral o suficiente para abranger indústrias não se ajustará perfeitamente a nenhuma delas. Espere adicionar extensões.
• O grupo Sales Order é pesado. Sua decomposição refinada é poderosa, mas significa mais joins e mais entidades para mapear. Equipes com fluxos de pedidos simples podem adotar apenas um subconjunto.
• Strings de função de formato livre precisam de governança. Como observado, a flexibilidade em parentProductRole e childProductRole é tão boa quanto a disciplina em torno dela.
• Modelos abertos evoluem. Como o CIM é orientado à comunidade, termos podem ser adicionados ou refinados ao longo do tempo. Fixe uma versão e revise as alterações deliberadamente.

O trade-off é essencialmente o clássico entre fidelidade a um sistema específico e portabilidade entre sistemas. O CIM otimiza a portabilidade, que é a escolha certa quando a interoperabilidade é o objetivo.

Perguntas Frequentes

O que é o Cloud Information Model?

O Cloud Information Model é um modelo de dados aberto e agnóstico de aplicação que define entidades e termos compartilhados para dados corporativos, como partes, produtos, pedidos e pagamentos. Ele fornece um vocabulário comum para que diferentes sistemas em nuvem e on-premises possam trocar dados sem mapeamentos ponto a ponto personalizados.

Para que é usado o ProductRelationshipType?

O ProductRelationshipType define as razões pelas quais dois produtos estão relacionados — por exemplo, um pacote, uma opção ou uma cobertura. Ele armazena uma função de pai e uma função de filho para que links direcionais de produto para produto possam referenciar uma definição compartilhada e reutilizável, em vez de repetir a semântica em cada link.

Por que o CIM usa GUIDs para chaves primárias?

Usar um GUID para a propriedade id significa que os identificadores são globalmente únicos sem a necessidade de coordenação central. Isso é importante em ambientes multi-nuvem e multi-fornecedor, onde registros são criados em sistemas diferentes e posteriormente mesclados, pois colisões são efetivamente evitadas.

O CIM é um esquema de banco de dados ou um formato de troca de dados?

É melhor compreendido como um modelo conceitual e de intercâmbio do que como um esquema de banco de dados físico. Seus termos baseados em URI mapeiam-se naturalmente para JSON-LD, RDF, tabelas relacionais ou grafos de propriedades, portanto, você pode implementá-lo em qualquer tecnologia de armazenamento que sua arquitetura já utilize.

Como o CIM se relaciona com outros padrões como OAGIS ou schema.org?

O CIM compartilha o objetivo desses esforços — um vocabulário compartilhado para interoperabilidade — mas é dimensionado para a integração empresarial da era da nuvem e publicado como termos abertos e desreferenciáveis. Na prática, você pode mapear o CIM para outros padrões nas extremidades onde os parceiros os exigem.

Tenho que adotar todo o modelo de uma vez?

Não. O CIM é organizado em grupos de entidades fracamente acoplados, portanto, você pode adotar os grupos de que precisa — por exemplo, Party e Product — e expandir posteriormente. A maioria das equipes começa com as entidades que causam mais problemas de integração e cresce a partir daí.

Leitura adicional

• Pedido de venda — Wikipedia
• Resource Description Framework (RDF) — Wikipedia
• JSON-LD — Wikipedia
• schema.org — vocabulário compartilhado para dados estruturados na web