Pular para o conteúdo
SteveTechArcSteveTechArc Courses

Construa o modelo lógico

Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Five different dog collars on pegs by a home's front door, each with its own blank metal tag, beside a leash, a brush and a water bowl.
Imagem gerada com IA

Módulo 3 de 6 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Desenhe os relacionamentos · Próximo: Coloque os dados onde eles pertencem

A pergunta que este módulo responde: Como transformo um modelo conceitual num modelo de dados lógico?

O modelo conceitual nos disse o que existe na Steve Trucking e como se relaciona: Parceiros varejistas e seus centros de distribuição, manifestos e entregas, Destinatários, rotas e paradas, equipes, caminhões e atribuições de equipe. Isso basta para uma conversa muito produtiva com o negócio. Mas em algum momento preciso de mais detalhe. O que precisamos saber sobre uma entrega? O que torna um centro de distribuição diferente de outro? Como identificamos um Destinatário? O que pertence a uma atribuição de equipe em vez de à equipe ou ao caminhão? Essas perguntas nos levam de um modelo conceitual para um modelo de dados lógico, e ainda não estamos construindo no Salesforce.

Senta, fica, modelo

Seção intitulada “Senta, fica, modelo ”

Primeiro, de volta aos cachorros. Temos as caixas e as linhas. Agora duas perguntas novas: o que sabemos sobre cada coisa, e como distinguimos uma da outra?

O que a descreve? Um cachorro tem um nome e uma data de nascimento. Um dono tem um nome, um número de telefone e um endereço. Um truque tem um nome e uma dificuldade. Cada fato vai na caixa que ele descreve.

Depois, a junção. O quão bem a Bella faz o Senta, e quando o aprendeu: isso descreve a Bella? Não exatamente; ela é melhor em alguns truques do que em outros. Descreve o Senta? Não; cada cachorro faz o Senta de um jeito. Descreve a Bella e o Senta juntos, então pertence ao Truque do cachorro: o nível de habilidade e a data em que aprendeu. É por isso que a junção existe: alguns fatos só pertencem ao par.

Qual cachorro é qual? Tente o nome primeiro. Há muitos cachorros chamados Max, então o nome não é único. O telefone do dono? O Marcus tem dois cachorros no mesmo telefone, as pessoas mudam de número, e é um dado pessoal de alguém, que seria copiado para todo sistema que um dia apontar para um cachorro. O número do microchip parece melhor: é único e não muda. Mas um filhote novo pode ainda não ter chip, e uma chave não pode ficar em branco. Então o microchip fica, como algo pelo qual o cachorro também é conhecido, e o cachorro ganha seu próprio ID do cachorro: um número que faz um único trabalho sem graça, distinguir um cachorro do outro.

O modelo dos cachorros com chaves e atributos O modelo dos cachorros como modelo de dados detalhado. Cada caixa lista seu ID de registro e alguns campos. Dono: ID do dono, nome, telefone, CEP, cidade. Criador: ID do criador, nome, cidade. Cachorro: ID do cachorro, também conhecido pelo número do microchip, o ID do dono e o ID do criador, nome, data de nascimento. Raça, ainda sem ligação: ID da raça, nome, porte. Truque: ID do truque, nome, dificuldade. Truque do cachorro, entre Cachorro e Truque: ID do truque do cachorro, o ID do cachorro e o ID do truque, nível de habilidade, data em que aprendeu. Avaliação do truque, abaixo de Truque do cachorro: seu ID, o ID do truque do cachorro, data, nível de habilidade, avaliado por. As linhas são as mesmas de antes: um Dono é dono de Cachorros, um Criador cria Cachorros (um Cachorro tem zero ou um Criador), um Cachorro sabe Truques do cachorro, um Truque está em Truques do cachorro, e um Truque do cachorro é avaliado em Avaliações do truque. é dono de cria sabe está em é avaliado em Dono ID do dono ID DE REGISTRO Nome Telefone ZIP Cidade Criador ID do criador ID DE REGISTRO Nome Cidade Cachorro ID do cachorro ID DE REGISTRO Número do microchip TAMBÉM CONHECIDO COMO ID do dono ID do criador Nome Data de nascimento Raça ID da raça ID DE REGISTRO Nome Porte Truque do cachorro ID do truque do cachorro ID DE REGISTRO ID do cachorro ID do truque Nível de habilidade Aprendeu em Truque ID do truque ID DE REGISTRO Nome Dificuldade Avaliação do truque ID da avaliação do truque ID DE REGISTRO ID do truque do cachorro Data Nível de habilidade Avaliado por exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Essas são as mesmas perguntas que agora vamos fazer à Steve Trucking, e os motivos pelos quais o nome, o telefone e o microchip não servem viram uma regra que sigo há anos.

O conceitual me diz o que existe; o lógico me diz o que isso significa como dado

Seção intitulada “O conceitual me diz o que existe; o lógico me diz o que isso significa como dado ”

Pegue o Caminhão. O que preciso saber sobre um caminhão? Talvez o número da unidade, o chassi (VIN), a marca, o modelo, o ano do modelo, a placa, a quilometragem atual e o status. Esses são atributos do Caminhão.

Agora pegue a Entrega. Talvez o número do pedido do Parceiro varejista, a data de entrega, a janela prometida, o horário real de chegada, o status, e se ela inclui instalação ou recolhimento. De novo, atributos.

O modelo conceitual nos disse que a Entrega existe. O modelo lógico começa a nos dizer o que uma entrega significa como dado. Uma caixa simples como Caminhão ou Entrega pode representar um conjunto inteiro de campos.

De caixas a entidades com atributos Três caixas conceituais à esquerda (Caminhão, Entrega, Centro de distribuição), cada uma ligada por uma linha “vira” a uma entidade lógica à direita que lista seus atributos. Caminhão: número da unidade, chassi (VIN), marca, modelo, ano do modelo, placa, quilometragem atual, status. Entrega: número do pedido do parceiro, data de entrega, janela prometida, chegada real, status, inclui instalação, inclui recolhimento. Centro de distribuição: nome, endereço, mercado, telefone. CONCEITUAL: O QUE EXISTE LÓGICO: O QUE SIGNIFICA COMO DADO vira vira vira Caminhão o veículo Caminhão Número da unidade VIN Marca Modelo Ano do modelo Placa Quilometragem atual Status Entrega um pedido para um Destinatário Entrega Número do pedido do parceiro Data de entrega Janela prometida Chegada real Status Inclui instalação Inclui recolhimento Centro de distribuição de onde saem as entregas Centro de distribuição Nome Endereço Mercado Telefone A maioria dos nossos diagramas mantém a caixa simples: os campos crescem, ficam desatualizados e carregam detalhes (nome de API, rótulo, tipo, tamanho). © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Mesmo assim, na maioria dos nossos diagramas as caixas continuam simples, por três motivos. O número de campos cresce. Os campos ficam obsoletos rapidamente. E cada campo tem detalhes difíceis de mostrar num modelo de objetos: o nome de API, o rótulo, o tipo de dado e o tamanho. Esses detalhes com certeza serão registrados, só não no primeiro modelo de dados. Quando mostrar alguns campos-chave realmente ajuda a contar a história, desenho um modelo de dados detalhado: um recorte focado, só com os campos que importam para o ponto.

Os atributos devem descrever a entidade

Seção intitulada “Os atributos devem descrever a entidade ”

Eis uma pergunta simples que uso ao olhar para um atributo: o que isto descreve? A marca do caminhão claramente descreve o caminhão. Mas e os nomes dos membros da equipe numa entrega? Eles descrevem a entrega? Ou descrevem uma equipe, que teve uma atribuição de equipe, que cobriu a rota, que incluía esta parada?

É aqui que um modelo de dados começa a expor coisas que parecem perfeitamente razoáveis numa tela. Um coordenador diz: “Quero ver os nomes da equipe na entrega.” Esse é um requisito válido de experiência do usuário. Não é necessariamente um requisito de armazenar os nomes da equipe na entrega. São duas coisas diferentes, e vamos voltar a isso com a normalização. Por enquanto, crie o hábito de perguntar que coisa este fato realmente descreve. Essa pergunta vai lhe poupar muita dor de cabeça.

Depois precisamos falar de IDs únicos

Seção intitulada “Depois precisamos falar de IDs únicos ”

Atributos descrevem coisas. Mas há outro problema a resolver: como sei qual coisa é qual?

Dois Destinatários se chamam João Silva. São a mesma pessoa? Talvez; talvez não. Um nome não basta. Um endereço? As pessoas se mudam. Números de telefone mudam. Endereços de e-mail mudam. Até o nome de um Parceiro varejista pode mudar.

Isso nos leva às chaves: o que nos permite identificar algo de forma única no nosso modelo. É uma área em que desenvolvi uma opinião bem firme ao longo dos anos. Para um identificador, quero quatro coisas:

Único. Imutável. Sem significado. Nunca dado pessoal (PII).

Único. Um identificador precisa identificar exatamente uma coisa. Se duas entregas podem ter o mesmo valor, ele não é um identificador confiável de entrega. Nomes normalmente não são únicos, endereços não são necessariamente únicos, e números de telefone são compartilhados. Até valores que parecem únicos hoje podem deixar de ser quando você tiver dados suficientes. Então pergunte: dois destes podem algum dia ter o mesmo valor? Se a resposta é sim, tenha muito cuidado ao usá-lo como ID único do registro.

Imutável. Este passa despercebido. Se identificamos um Parceiro varejista pelo nome e o parceiro muda de nome, ganhamos um novo parceiro? Não. A entidade de negócio continuou a mesma; um dos seus atributos mudou. O ID único de um registro deve sobreviver às mudanças da coisa que ele identifica, o que descarta nomes, endereços de e-mail, números de telefone, endereços e nomes de usuário, por mais convenientes que pareçam quando estamos construindo um sistema pela primeira vez.

Sem significado. Isto soa estranho na primeira vez que você ouve. Por que eu iria querer um identificador sem significado? Porque o significado muda. Imagine que alguém monta um ID de entrega que codifica o CD, o Parceiro varejista, a data de entrega e um número sequencial: PHX-KEY-20261002-0042. Parece engenhoso. Aí o Destinatário reagenda para sexta-feira. Mudamos o identificador? Se não mudamos, ele está mentindo para nós. Se mudamos, alteramos o ID único da entrega porque um dos seus atributos mudou, e todo sistema que guardou o ID antigo acabou de perdê-la de vista. O identificador estava tentando fazer dois trabalhos: identificar a entrega e descrevê-la. Prefiro deixar os atributos descreverem e deixar o identificador fazer um trabalho chato: identificar. Identificadores chatos são bons identificadores.

Nunca dado pessoal. Este é importante o bastante para eu mantê-lo separado. Não use informação pessoal identificável como identificador só porque parece única. Na Steve Trucking, é tentador reconhecer um Destinatário pelo número de telefone. Mas uma chave é copiada para todo lugar em que os sistemas precisam conectar registros: integrações, exportações, logs, arquivos de status devolvidos aos Parceiros varejistas, o data warehouse, dados de teste. Faça de um número de telefone a chave, e você espalhou dados pessoais de um Destinatário pela arquitetura inteira.

Uma chave também precisa existir em todo registro: nunca nula ou em branco. Se algumas pessoas não vão, ou não deveriam precisar, fornecer um valor, esse valor não pode ser a chave. É por isso que os sistemas emitem seus próprios identificadores internos, e os dados pessoais, se você precisar deles, viram um atributo protegido.

Então minha regra é: único, imutável, sem significado, nunca dado pessoal.

Chaves naturais e chaves substitutas

Seção intitulada “Chaves naturais e chaves substitutas ”

O pessoal de banco de dados tem nomes para parte disto. Uma chave natural já existe nos dados do negócio: o chassi (VIN) de um caminhão é um bom exemplo. Nossa aplicação não o inventou, e ele já tem significado. Uma chave substituta (surrogate key) é criada especificamente para identificar o registro; ela não descreve nada, só identifica.

Na maioria das arquiteturas, prefiro uma chave substituta como ID de registro interno e mantenho os identificadores naturais importantes como atributos. Isso não torna os identificadores naturais ruins; muitas vezes são extremamente importantes. Só não os transformo automaticamente no ID único do registro. Pergunte o que acontece se o valor for corrigido, reformatado, substituído, reutilizado, estiver faltando, ou chegar de mais de um sistema de origem. É aí que uma decisão de aparência simples vira uma decisão de arquitetura.

Uma coisa pode ter vários identificadores úteis

Seção intitulada “Uma coisa pode ter vários identificadores úteis ”

O ID de registro interno não é necessariamente o identificador que todos os outros sistemas usam. A Steve Trucking pode identificar uma entrega internamente com um ID gerado. Cada Parceiro varejista conhece a mesma entrega pelo seu próprio número de pedido: a Keystone no manifesto em CSV, a Redrock na sua API, a Brightwave nas suas mensagens EDI. E os oito anos de histórico no RouteDesk, a ferramenta de despacho legada, usam os IDs de entrega do próprio RouteDesk.

Esses identificadores importam. Precisamos guardá-los e mapeá-los corretamente, porque uma atualização de status precisa voltar para cada parceiro com o número dele. Mas eles não precisam todos virar o ID único da entrega. “Qual é o ID?” pode ter mais de uma resposta, e o arquiteto precisa saber qual ID tem autoridade em qual contexto. Vamos voltar a isso com dados mestres e integração.

Os relacionamentos dependem de IDs únicos

Seção intitulada “Os relacionamentos dependem de IDs únicos ”

Agora volte às linhas que desenhamos. Um manifesto lista entregas. Um Destinatário recebe entregas. Uma equipe tem atribuições de equipe. Esses relacionamentos só funcionam porque conseguimos identificar de forma confiável as coisas nas duas pontas.

É aqui que isso pega na Steve Trucking. Um Parceiro varejista revisa o manifesto no próprio dia: um pedido cancelado, um item trocado, um endereço novo. Se não conseguimos casar a linha revisada com a entrega que já temos, pelo número de pedido do parceiro, criamos uma segunda entrega para a mesma geladeira, e uma equipe pode aparecer duas vezes. Caixas, atributos, chaves e relacionamentos não são ideias separadas. São todos partes do mesmo modelo.

Um modelo de dados detalhado e focado Um modelo de dados detalhado e focado da Steve Trucking, em três grupos. Cada entidade lista seu ID de registro (um ID único interno gerado), qualquer outro identificador pelo qual também é conhecida e alguns campos-chave. Parceiro varejista (nome, endereço de cobrança, status) opera Centros de distribuição e envia Entregas. Uma Entrega também é conhecida pelo número do pedido do parceiro e pelo ID da entrega no RouteDesk; ela é entregue a um Destinatário (nome, endereço, telefone, e-mail), sai de um Centro de distribuição (nome, endereço, mercado) e contém Itens de entrega (produto, quantidade, inclui instalação). Uma Equipe trabalha em Atribuições de equipe, e um Caminhão (também conhecido pelo chassi, o VIN, e pelo número da unidade) é usado em Atribuições de equipe, que têm uma data de início e uma data de fim. DADOS DE CLIENTES DADOS TRANSACIONAIS DADOS DE REFERÊNCIA opera envia é entregue em sai de contém trabalha em usado em Parceiro varejista ID do parceiro varejista ID DE REGISTRO Nome Endereço de cobrança Status Destinatário ID do destinatário ID DE REGISTRO Nome Endereço Telefone E-mail Entrega ID da entrega ID DE REGISTRO Número do pedido do parceiro TAMBÉM CONHECIDO COMO ID da entrega no RouteDesk TAMBÉM CONHECIDO COMO Data de entrega Janela prometida Status Item de entrega ID do item de entrega ID DE REGISTRO Produto Quantidade Inclui instalação Atribuição de equipe ID da atribuição de equipe ID DE REGISTRO Data de início Data de fim Centro de distribuição ID do centro de distribuição ID DE REGISTRO Nome Endereço Mercado Equipe ID da equipe ID DE REGISTRO Nome Status Caminhão ID do caminhão ID DE REGISTRO VIN TAMBÉM CONHECIDO COMO Número da unidade TAMBÉM CONHECIDO COMO Marca Modelo Placa Status exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Neste ponto você pode estar pensando: “O Salesforce dá um ID a todo registro.” Correto, e vamos chegar lá. Se os dados vivem no Salesforce, todo registro recebe um ID gerado pelo Salesforce. Ele é críptico e difícil de ler, então normalmente também expomos um campo de ID que as pessoas conseguem usar, como um número de entrega D-000184227, um campo de numeração automática. As pessoas muitas vezes acham que esse número é o ID de registro, mas não é: o ID do Salesforce continua lá embaixo. Um sistema ou banco de dados externo, Oracle ou SQL Server, também tem seus próprios IDs únicos. Mas a arquitetura pode acabar incluindo o Salesforce, o ERP financeiro, o Snowflake, o Data 360, os sistemas dos parceiros e sistemas que ainda nem existem. O modelo lógico descreve os dados do negócio sem fazer cada decisão depender de uma tecnologia. Como o Salesforce o implementa fisicamente é um passo posterior.

O que um arquiteto decide aqui

Seção intitulada “O que um arquiteto decide aqui ”

Ao transformar um modelo conceitual num modelo lógico, estou decidindo:

  • Quais atributos realmente descrevem cada entidade.
  • Como cada entidade é identificada de forma única, e se esse identificador é estável o bastante para ser o seu ID único.
  • Quais identificadores de negócio (números de pedido de parceiros, IDs legados) precisam ser guardados e mapeados.
  • Se informação sensível está sendo usada como chave.
  • Se os relacionamentos conectam as entidades por IDs únicos confiáveis.

Agora temos entidades, relacionamentos, atributos e IDs únicos: os primeiros traços de um modelo de dados lógico de verdade. Mas ainda há um problema. É muito fácil colocar dados perfeitamente válidos no lugar errado. É aí que entra a normalização.

Para saber mais

Seção intitulada “Para saber mais ”