Pular para o conteúdo
SteveTechArcSteveTechArc Courses

Construa o modelo lógico

Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 sustenta-se sozinho. Anterior: Desenhe as relações · 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 disse-nos o que existe na Steve Trucking e como se relaciona: Parceiros retalhistas e os seus centros de distribuição, manifestos e entregas, Destinatários, rotas e paragens, equipas, camiões e atribuições de equipa. Isso basta para uma conversa muito produtiva com o negócio. Mas a dada altura preciso de mais pormenor. O que precisamos de 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 equipa em vez de à equipa ou ao camião? Estas perguntas levam-nos de um modelo conceitual para um modelo de dados lógico, e ainda não estamos a construir no Salesforce.

Senta, fica, modelo

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

Primeiro, de volta aos cães. 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 cão tem um nome e uma data de nascimento. Um dono tem um nome, um número de telefone e uma morada. Um truque tem um nome e uma dificuldade. Cada facto vai na caixa que descreve.

Depois, a junção. Quão bem a Bella faz o Senta, e quando o aprendeu: isso descreve a Bella? Não exatamente; ela é melhor nalguns truques do que noutros. Descreve o Senta? Não; cada cão faz o Senta à sua maneira. Descreve a Bella e o Senta em conjunto, por isso pertence ao Truque do cão: o nível de habilidade e a data em que o aprendeu. É por isso que a junção existe: alguns factos só pertencem ao par.

Qual cão é qual? Experimente primeiro o nome. Há muitos cães chamados Max, por isso o nome não é único. O telefone do dono? O Marcus tem dois cães com o mesmo telefone, as pessoas mudam de número, e é um dado pessoal de alguém, que seria copiado para todos os sistemas que algum dia apontem para um cão. O número do microchip parece melhor: é único e não muda. Mas um cachorro novo pode ainda não ter chip, e uma chave não pode ficar em branco. Por isso, o microchip fica, como algo pelo qual o cão também é conhecido, e o cão ganha o seu próprio ID do cão: um número que faz um único trabalho aborrecido, distinguir um cão de outro.

O modelo dos cães com chaves e atributos O modelo dos cães como modelo de dados detalhado. Cada caixa lista o seu ID de registo e alguns campos. Dono: ID do dono, nome, telefone, código postal, cidade. Criador: ID do criador, nome, cidade. Cão: ID do cão, 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 cão, entre Cão e Truque: ID do truque do cão, o ID do cão e o ID do truque, nível de habilidade, data em que aprendeu. Avaliação do truque, abaixo de Truque do cão: o seu ID, o ID do truque do cão, data, nível de habilidade, avaliado por. As linhas são as mesmas de antes: um Dono é dono de Cães, um Criador cria Cães (um Cão tem zero ou um Criador), um Cão sabe Truques do cão, um Truque está em Truques do cão, e um Truque do cão é avaliado em Avaliações do truque. é dono de cria sabe está em é avaliado em Dono ID do dono ID DE REGISTO Nome Telefone ZIP Cidade Criador ID do criador ID DE REGISTO Nome Cidade Cão ID do cão ID DE REGISTO 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 REGISTO Nome Porte Truque do cão ID do truque do cão ID DE REGISTO ID do cão ID do truque Nível de habilidade Aprendeu em Truque ID do truque ID DE REGISTO Nome Dificuldade Avaliação do truque ID da avaliação do truque ID DE REGISTO ID do truque do cão 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

Estas 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 tornam-se uma regra que sigo há anos.

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

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

Pegue no Camião. O que preciso de saber sobre um camião? Talvez o número da unidade, o número de quadro (VIN), a marca, o modelo, o ano do modelo, a matrícula, a quilometragem atual e o estado. Estes são atributos do Camião.

Agora pegue na Entrega. Talvez o número de encomenda do Parceiro retalhista, a data de entrega, a janela prometida, a hora real de chegada, o estado, e se inclui instalação ou recolha. Mais uma vez, atributos.

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

De caixas a entidades com atributos Três caixas conceituais à esquerda (Camião, Entrega, Centro de distribuição), cada uma ligada por uma linha «torna-se» a uma entidade lógica à direita que lista os seus atributos. Camião: número da unidade, número de quadro (VIN), marca, modelo, ano do modelo, matrícula, quilometragem atual, estado. Entrega: número de encomenda do parceiro, data de entrega, janela prometida, chegada real, estado, inclui instalação, inclui recolha. Centro de distribuição: nome, morada, mercado, telefone. CONCEITUAL: O QUE EXISTE LÓGICO: O QUE SIGNIFICA COMO DADO torna se torna se torna se Camião o veículo Camião Número da unidade VIN Marca Modelo Ano do modelo Matrícula Quilometragem atual Estado Entrega uma encomenda para um Destinatário Entrega Número de encomenda do parceiro Data de entrega Janela prometida Chegada real Estado Inclui instalação Inclui recolha Centro de distribuição de onde saem as entregas Centro de distribuição Nome Morada 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 desatualizados rapidamente. E cada campo tem pormenores difíceis de mostrar num modelo de objetos: o nome de API, o rótulo, o tipo de dado e o tamanho. Esses pormenores serão com certeza registados, só não no primeiro modelo de dados. Quando mostrar alguns campos-chave ajuda realmente 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 é que isto descreve? A marca do camião descreve claramente o camião. Mas e os nomes dos membros da equipa numa entrega? Descrevem a entrega? Ou descrevem uma equipa, que teve uma atribuição de equipa, que cobriu a rota, que incluía esta paragem?

É aqui que um modelo de dados começa a expor coisas que parecem perfeitamente razoáveis num ecrã. Um coordenador diz: «Quero ver os nomes da equipa na entrega.» É um requisito válido de experiência do utilizador. Não é necessariamente um requisito de armazenar os nomes da equipa na entrega. São duas coisas diferentes, e vamos voltar a isso com a normalização. Por agora, ganhe o hábito de perguntar que coisa este facto descreve realmente. Essa pergunta vai poupar-lhe muitas dores de cabeça.

Depois temos de falar de IDs únicos

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

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

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

Isso leva-nos à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 de identificar exatamente uma coisa. Se duas entregas podem ter o mesmo valor, não é um identificador fiável de entrega. Os nomes normalmente não são únicos, as moradas não são necessariamente únicas, e os números de telefone são partilhados. Até valores que parecem únicos hoje podem deixar de o ser quando tiver dados suficientes. Por isso pergunte: dois destes podem alguma vez ter o mesmo valor? Se a resposta é sim, tenha muito cuidado ao usá-lo como ID único do registo.

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

Sem significado. Isto soa estranho da primeira vez que se ouve. Porque haveria eu de querer um identificador sem significado? Porque o significado muda. Imagine que alguém monta um ID de entrega que codifica o CD, o Parceiro retalhista, a data de entrega e um número sequencial: PHX-KEY-20261002-0042. Parece engenhoso. Depois o Destinatário reagenda para sexta-feira. Mudamos o identificador? Se não mudamos, está a mentir-nos. Se mudamos, alterámos o ID único da entrega porque um dos seus atributos mudou, e cada sistema que guardou o ID antigo acabou de a perder de vista. O identificador estava a tentar fazer dois trabalhos: identificar a entrega e descrevê-la. Prefiro deixar os atributos descrever e deixar o identificador fazer um trabalho aborrecido: identificar. Identificadores aborrecidos são bons identificadores.

Nunca dado pessoal. Este é suficientemente importante para o manter à parte. 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 todos os sítios onde os sistemas precisam de ligar registos: integrações, exportações, logs, ficheiros de estado devolvidos aos Parceiros retalhistas, o data warehouse, dados de teste. Faça de um número de telefone a chave, e espalhou dados pessoais de um Destinatário pela arquitetura inteira.

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

Por isso a 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 das bases de dados tem nomes para parte disto. Uma chave natural já existe nos dados do negócio: o número de quadro (VIN) de um camião é um bom exemplo. A nossa aplicação não o inventou, e já tem significado. Uma chave substituta (surrogate key) é criada especificamente para identificar o registo; não descreve nada, só identifica.

Na maioria das arquiteturas, prefiro uma chave substituta como ID de registo interno e mantenho os identificadores naturais importantes como atributos. Isso não torna os identificadores naturais maus; muitas vezes são extremamente importantes. Só não os transformo automaticamente no ID único do registo. Pergunte o que acontece se o valor for corrigido, reformatado, substituído, reutilizado, estiver em falta, ou chegar de mais do que um sistema de origem. É aí que uma decisão de aparência simples se torna 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 registo 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 retalhista conhece a mesma entrega pelo seu próprio número de encomenda: 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.

Estes identificadores importam. Precisamos de os guardar e mapear corretamente, porque uma atualização de estado tem de voltar a cada parceiro com o número dele. Mas não precisam todos de se tornar o ID único da entrega. «Qual é o ID?» pode ter mais do que uma resposta, e o arquiteto precisa de saber que ID tem autoridade em que contexto. Vamos voltar a isto com dados mestres e integração.

As relações dependem de IDs únicos

Seção intitulada “As relações dependem de IDs únicos ”

Agora volte às linhas que desenhámos. Um manifesto lista entregas. Um Destinatário recebe entregas. Uma equipa tem atribuições de equipa. Estas relações só funcionam porque conseguimos identificar de forma fiável as coisas nas duas pontas.

É aqui que isto pesa na Steve Trucking. Um Parceiro retalhista revê o manifesto no próprio dia: uma encomenda cancelada, um artigo trocado, uma morada nova. Se não conseguimos fazer corresponder a linha revista à entrega que já temos, pelo número de encomenda do parceiro, criamos uma segunda entrega para o mesmo frigorífico, e uma equipa pode aparecer duas vezes. Caixas, atributos, chaves e relações não são ideias separadas. São todas 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 o seu ID de registo (um ID único interno gerado), qualquer outro identificador pelo qual também é conhecida e alguns campos-chave. O Parceiro retalhista (nome, morada de faturação, estado) opera Centros de distribuição e envia Entregas. Uma Entrega também é conhecida pelo número de encomenda do parceiro e pelo ID da entrega no RouteDesk; é entregue a um Destinatário (nome, morada, telefone, e-mail), sai de um Centro de distribuição (nome, morada, mercado) e contém Itens de entrega (produto, quantidade, inclui instalação). Uma Equipa trabalha em Atribuições de equipa, e um Camião (também conhecido pelo número de quadro, o VIN, e pelo número da unidade) é usado em Atribuições de equipa, 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 retalhista ID do parceiro retalhista ID DE REGISTO Nome Morada de faturação Estado Destinatário ID do destinatário ID DE REGISTO Nome Morada Telefone E-mail Entrega ID da entrega ID DE REGISTO Número de encomenda do parceiro TAMBÉM CONHECIDO COMO ID da entrega no RouteDesk TAMBÉM CONHECIDO COMO Data de entrega Janela prometida Estado Item de entrega ID do item de entrega ID DE REGISTO Produto Quantidade Inclui instalação Atribuição de equipa ID da atribuição de equipa ID DE REGISTO Data de início Data de fim Centro de distribuição ID do centro de distribuição ID DE REGISTO Nome Morada Mercado Equipa ID da equipa ID DE REGISTO Nome Estado Camião ID do camião ID DE REGISTO VIN TAMBÉM CONHECIDO COMO Número da unidade TAMBÉM CONHECIDO COMO Marca Modelo Matrícula Estado exatamente um zero ou um um ou muitos zero ou muitos © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Neste ponto pode estar a pensar: «O Salesforce dá um ID a cada registo.» Correto, e vamos lá chegar. Se os dados vivem no Salesforce, cada registo recebe um ID gerado pelo Salesforce. É críptico e difícil de ler, por isso 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 registo, mas não é: o ID do Salesforce continua lá por baixo. Um sistema ou base de dados externo, Oracle ou SQL Server, também tem os seus próprios IDs únicos. Mas a arquitetura pode acabar por incluir 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. A forma 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 a decidir:

  • Que atributos descrevem realmente cada entidade.
  • Como cada entidade é identificada de forma única, e se esse identificador é suficientemente estável para ser o seu ID único.
  • Que identificadores de negócio (números de encomenda de parceiros, IDs legados) precisam de ser guardados e mapeados.
  • Se informação sensível está a ser usada como chave.
  • Se as relações ligam as entidades por IDs únicos fiáveis.

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

Para saber mais

Seção intitulada “Para saber mais ”