Modelo CIM

O Cloud Information Model (CIM) é um modelo de dados aberto e independente de aplicativos, destinado a fornecer às empresas um vocabulário compartilhado para as entidades que aparecem em sistemas de CRM, ERP, marketing, serviços e análise. Em vez de cada fornecedor inventar seus próprios nomes de objetos e relacionamentos, o CIM define um conjunto comum de áreas de assunto, entidades e atributos para os quais qualquer sistema pode realizar o mapeamento. O modelo é administrado como um projeto de código aberto sob a The Linux Foundation, que hospeda um amplo portfólio de projetos colaborativos de dados e infraestrutura.

Este artigo explica como o CIM é estruturado, como seus componentes se relacionam entre si, como funcionam os supertipos e subtipos e como as áreas de assunto são organizadas. Também abrange as decisões práticas que um arquiteto enfrenta ao adotar o CIM — mapeamento, governança, versionamento e extensão — e onde o modelo se encaixa em relação a outros padrões do setor.

Principais Conclusões

• O CIM organiza conceitos de negócios em Áreas de Assunto, cada uma contendo Grupos de Entidades, Entidades e Atributos — uma hierarquia que mapeia claramente para esquemas, tabelas e colunas.
• Supertipos e subtipos permitem que o modelo expresse características compartilhadas (uma Parte que é uma pessoa ou uma organização), ao mesmo tempo que permite a especialização.
• O modelo é deliberadamente independente de aplicação: ele descreve conceitos de negócios, e não a implementação de um único fornecedor.
• O CIM é publicado em múltiplos formatos com diagramas de exemplo, para que possa ser consumido tanto por ferramentas de modelagem e geradores de código quanto por documentações.
• O número e o escopo das áreas de assunto crescem com as contribuições do consórcio e da comunidade, portanto a adoção deve levar em conta o versionamento e o gerenciamento de mudanças.
• O CIM é uma opção entre várias; a escolha certa depende de você precisar de um modelo amplo e multidisciplinar ou de um padrão restrito e profundo para um único setor.

Como o CIM é Estruturado

O CIM é organizado em componentes para que o conteúdo possa ser navegado e consumido com mais facilidade. Cada nível da hierarquia responde a uma pergunta diferente, e compreender essa hierarquia é o primeiro passo para usar bem o modelo.

• Área de Assunto (Subject Area) — Um conceito de negócio principal identificado pelo consórcio CIM, como Party. Cada área de assunto contém um ou mais grupos de entidades. Pense em uma área de assunto como um contexto delimitado (bounded context): ela agrupa tudo o que a empresa precisa saber sobre um tema amplo.
• Grupo de Entidades (Entity Group) — Um agrupamento lógico de entidades relacionadas dentro de uma área de assunto, como Account. Os grupos de entidades mantêm grandes áreas de assunto navegáveis e oferecem às equipes uma unidade natural para atribuir a responsabilidade (ownership).
• Entidade (Entity) — Um objeto exclusivo sobre o qual uma organização coleta informações, como um Account Contact. Uma entidade é análoga a uma tabela de banco de dados padrão.
• Atributo (Attribute) — Uma característica exclusiva de uma entidade, como Account Id ou Contact Email. Um atributo é análogo a um campo de banco de dados padrão dentro de uma tabela.

Esta hierarquia de quatro níveis é intencionalmente familiar. Arquitetos de dados que trabalharam com modelagem relacional, modelagem dimensional ou diagramas de entidade-relacionamento reconhecerão o padrão imediatamente. O valor que o CIM agrega não é uma técnica de modelagem inovadora, mas um conjunto compartilhado e pré-negociado de nomes e relacionamentos com o qual múltiplas organizações e fornecedores podem concordar.

Um modelo mental útil: uma área de assunto é aproximadamente um esquema ou um domínio; um grupo de entidades é aproximadamente um namespace ou módulo; uma entidade é uma tabela; um atributo é uma coluna. Esse mapeamento é aproximado — o CIM é um modelo conceitual e lógico, não físico — mas ajuda quando você traduz o CIM para uma implementação física.

Supertipos e Subtipos

Além dos quatro componentes principais, o design do CIM personaliza e estende as entidades em agrupamentos adicionais usando supertipos e subtipos. É aqui que o modelo ganha grande parte de seu poder expressivo.

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

• Supertipo — Uma entidade que é estendida por entidades de subtipo e define atributos comuns para conceitos semelhantes.
• Subtipo — Uma entidade que estende outra entidade e herda os atributos de sua entidade supertipo.

O exemplo clássico é Party. Uma “party” (parte) é qualquer pessoa ou coisa com a qual a empresa interage. Uma pessoa e uma organização são ambas “parties” e compartilham atributos — nome, identificadores, pontos de contato — mas cada uma possui atributos que a outra não tem.

Modelar Party como um supertipo com Person e Organization como subtipos evita a duplicação dos atributos compartilhados e mantém os relacionamentos (por exemplo, “esta oportunidade pertence a esta party”) consistentes, independentemente de qual subtipo esteja envolvido.

Heranças como essa são conceitos bem estabelecidos na modelagem de dados e aparecem em padrões como a UML do Object Management Group e nas convenções de entidade-relacionamento usadas em todo o setor. Ao implementar o CIM fisicamente, você deve decidir como representar a herança:

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

• Tabela única (Single table) — armazena todos os subtipos em uma única tabela com uma coluna discriminadora. Simples de consultar, mas pode gerar muitas colunas anuláveis (nullable).
• Herança de tabela de classe (Class table inheritance) — uma tabela para o supertipo e uma por subtipo, unidas por uma chave compartilhada. Normalizado e limpo, mas requer junções (joins).
• Herança de tabela concreta (Concrete table inheritance) — uma tabela separada e independente por subtipo. Rápido para consultas específicas de subtipo, mas duplica atributos compartilhados.

Não existe uma resposta universalmente correta. A escolha certa depende dos padrões de consulta, do número de subtipos e da frequência com que os atributos compartilhados são lidos juntos. Documente a decisão, pois ela afetará todas as integrações downstream.

As Áreas de Assunto do CIM

As áreas temáticas representam os principais conceitos de negócios que o consórcio modelou até agora. Cada uma é publicada com seus próprios diagramas e formatos, e várias trazem marcadores de versão explícitos (por exemplo, v1.0 ou v0.1.1), refletindo que algumas áreas são mais maduras que outras.

Setup — Define com quem você lida, por exemplo, cliente, fornecedor e vendedor. Também cobre os conceitos de software e infraestrutura que uma organização opera: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job e IoT Device.

Data Model — Os próprios conceitos fundamentais de modelagem.

Hire — Atividades relacionadas à estruturação do seu negócio, por exemplo, unidade de negócios interna e trabalhador. Os grupos de entidades incluem Job Application, Employee, Compensation, Training, Location, Work Territory e Work Report.

Biz Process — Conceitos de processos de negócios e continuidade de negócios.

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

Produce — Manuseio de material que você comprará, movimentará e venderá, por exemplo, produto e produto de estoque. Os grupos de entidades incluem Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order e Sales Agreement.

Market — Atividades usadas para promover seu produto, por exemplo, campanha de marketing e loja virtual. Os grupos de entidades incluem Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy e Web Site.

Sell — Atividades utilizadas para vender seu produto, por exemplo, criação de cotações e oportunidades. Os grupos de entidades incluem Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program e Competitor.

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

Service — Atividades para fornecer suporte para um produto vendido ou atendido, por exemplo, um caso ou uma pesquisa. Os grupos de entidades incluem AI Assistant, Asset, Asset Subscription, Web Content, Case, Task e Event.

Fulfill — Atividades que você executa para atender um pedido de um cliente, por exemplo, remessa e pedido de devolução. Os grupos de entidades incluem Fulfillment Order, Shipment, Return Order, Work Order, Work Resource e Work Forecast.

Interact — Atividades para rastrear o engajamento com usuários finais ou outros sistemas. Os grupos de entidades incluem Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey e Loyalty.

Finance — Atividades para rastrear informações financeiras na empresa, por exemplo, pagamento, fatura e relatório de despesas. Os grupos de entidades incluem Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar e Tax Policy.

Analyze — Atividades relacionadas à análise de dados, por exemplo, análise de padrões, uso de produtos, movimentação de dados, alterações de dados e satisfação do cliente. Os grupos de entidades incluem AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty e Journal.

Observe como as áreas temáticas abrangem tanto preocupações operacionais (Sell, Fulfill, Service) quanto analíticas (Analyze, Finance). Essa amplitude é o ponto central: um modelo compartilhado é mais valioso quando pode descrever o mesmo cliente, produto ou pedido de forma consistente, independentemente de os dados residirem em um sistema transacional ou em um warehouse.

Escolhendo entre CIM e outros padrões

O CIM não é o único modelo compartilhado na empresa. Vários padrões estabelecidos se sobrepõem a partes do seu escopo, e uma arquitetura madura geralmente usa mais de um. A decisão tem menos a ver com escolher um vencedor e mais com a adequação da amplitude e governança do modelo ao seu problema.

Padrão	Foco principal	Força típica	Onde o CIM difere
CIM	Conceitos de negócios cross-domain	Cobertura ampla e agnóstica de aplicação de CRM/ERP/marketing/serviço	Projetado como um guarda-chuva compartilhado entre domínios
OMG Common Core Ontologies / modelos baseados em UML	Notação de modelagem conceitual e ontologias superiores	Semântica formal rigorosa	O CIM é mais diretamente orientado a negócios
Modelos específicos do setor (ex: verticais de varejo, saúde, finanças)	Cobertura profunda de um setor	Precisão dentro da vertical	O CIM troca profundidade por amplitude
Modelos de dados de fornecedores (plataformas CRM/ERP)	Objetos de um único produto	Integração estreita com esse produto	O CIM é neutro em relação ao fornecedor por design

Uma regra prática:

• Se você precisa de um vocabulário compartilhado entre muitos sistemas e fornecedores, um modelo amplo como o CIM é uma ótima opção.
• Se você precisar de semântica profunda, regulamentada e específica do setor, um padrão vertical geralmente será mais preciso, e você poderá mapeá-lo para o CIM nas fronteiras.
• Se você estiver integrando dentro do ecossistema de um único fornecedor, o próprio modelo desse fornecedor pode ser suficiente — mas não ajudará você a se conectar ao próximo fornecedor.

O padrão mais comum no mundo real é uma abordagem hub-and-spoke: o CIM (ou outro modelo canônico) fica no centro, e cada sistema de origem é mapeado para ele. Este é o mesmo princípio por trás dos modelos de dados canônicos no master data management e por trás da ideia de “dimensão conformada” popularizada na modelagem dimensional por Ralph Kimball.

Orientação prática para a adoção do CIM

Adotar um modelo compartilhado é tanto um exercício organizacional quanto técnico. Algumas decisões determinam se o esforço compensará.

Comece com um escopo delimitado. Não tente mapear todos os sistemas para todas as áreas temáticas de uma só vez. Escolha um domínio de alto valor — Party e Sell são pontos de partida comuns porque os dados de clientes e oportunidades são amplamente duplicados — e comprove o mapeamento de ponta a ponta.

Decida sua política de extensão cedo. O CIM foi projetado para crescer com o consórcio e as contribuições, mas sua organização inevitavelmente precisará de atributos que o modelo ainda não define. Estabeleça uma convenção para extensões locais (por exemplo, um prefixo de namespace) para que os atributos personalizados sejam claramente distinguíveis dos padrões e possam ser reconciliados posteriormente.

Trate o versionamento como uma preocupação de primeira classe. As áreas temáticas carregam marcadores de versão como v1.0 e v0.1.1, o que sinaliza que o modelo evolui. Fixe a versão com a qual você constrói, acompanhe as alterações e planeje a migração. Esta é a mesma disciplina que você aplicaria a qualquer dependência.

Mapeie, não copie. O CIM é um modelo conceitual e lógico. Resista à tentação de gerar esquemas físicos diretamente a partir dele sem considerar o desempenho, a indexação e os padrões de acesso dos sistemas que consumirão os dados. Use o modelo para alinhar o significado e, em seguida, projete o armazenamento físico para sua carga de trabalho.

Governe o mapeamento. O mapeamento entre um sistema de origem e o CIM é, por si só, um ativo. Versione-o, revise-o e atribua a propriedade. Ferramentas no espaço de integração de dados — plataformas ETL e ELT, catálogos de dados e ferramentas de linhagem — podem ajudá-lo a rastrear onde cada atributo se origina e como ele flui, que é exatamente o tipo de metadados que a área temática Analyze antecipa com entidades como Data Lineage.

Envolva a comunidade. Como o CIM é de código aberto e orientado por consórcios, as lacunas que você encontra geralmente são lacunas que outros também encontraram. Contribuir com uma entidade ou atributo proposto de volta ao projeto é tanto um ato de boa cidadania quanto uma forma de reduzir sua carga de manutenção a longo prazo.

Formatos, Diagramas e Consumo

Os designs do CIM estão disponíveis em vários formatos para cada domínio, incluindo diagramas de exemplo. Isso é importante porque públicos diferentes consomem um modelo de dados de maneira diferente:

• Arquitetos querem diagramas e visualizações de relacionamento para raciocinar sobre a estrutura.
• Engenheiros desejam definições legíveis por máquina que possam alimentar a geração de código, validação de esquema ou ferramentas de mapeamento.
• Analistas e stewards desejam documentação que explique o que cada entidade e atributo significa em termos de negócio.

Publicar em vários formatos é uma escolha deliberada de design que reduz a barreira à adoção. Ao avaliar qualquer modelo compartilhado, verifique se ele é fornecido em formatos que seu toolchain possa realmente ingerir — um modelo que existe apenas como PDF é muito menos útil do que um com definições estruturadas.

Perguntas Frequentes

O que é o Cloud Information Model (CIM)?

O Cloud Information Model é um modelo de dados aberto e independente de aplicação que define conceitos de negócio compartilhados — como Party, Account e Sales Order — para que diferentes sistemas em nuvem e on-premises possam trocar dados usando um vocabulário comum. Ele é organizado em áreas temáticas, grupos de entidades, entidades e atributos, e é administrado como um projeto de código aberto sob a The Linux Foundation.

Qual é a diferença entre um supertipo e um subtipo no CIM?

Um supertipo é uma entidade que é estendida por entidades de subtipo e define os atributos comuns a conceitos semelhantes. Um subtipo estende outra entidade e herda os atributos de seu supertipo. Por exemplo, Party pode atuar como um supertipo com Person e Organization como subtipos, de modo que os atributos compartilhados são definidos uma vez e os atributos especializados residem no subtipo.

Como o CIM se relaciona com um esquema de banco de dados?

O CIM é um modelo conceitual e lógico, não um esquema físico. Suas entidades são análogas a tabelas de banco de dados e seus atributos a campos, o que torna a tradução intuitiva, mas você ainda deve projetar o armazenamento físico — indexação, particionamento, desnormalização — em torno de seus próprios padrões de consulta, em vez de copiar o modelo literalmente.

O CIM é um substituto para padrões de dados específicos do setor?

Não. O CIM é amplo e cross-domain, enquanto os padrões verticais são profundos e específicos de setor. Muitas organizações usam uma abordagem hub-and-spoke na qual o CIM serve como o modelo canônico no centro e os padrões da indústria ou modelos de fornecedores são mapeados para ele nas extremidades.

Por que as áreas temáticas do CIM têm números de versão?

Marcadores de versão como v1.0 e v0.1.1 indicam que o modelo evolui e que algumas áreas temáticas estão mais maduras que outras. Fixar uma versão, rastrear alterações e planejar migrações é a mesma disciplina de gerenciamento de dependências que você aplicaria a qualquer biblioteca ou esquema compartilhado.

Como lidar com atributos que o CIM não define?

Estabeleça uma convenção de extensão documentada, como um prefixo com namespace, para que os atributos personalizados sejam claramente distinguíveis dos padrões. Em seguida, considere contribuir com a lacuna de volta ao projeto, já que o modelo foi projetado para crescer com contribuições do consórcio e da comunidade.