Google Sheet para esquema relacional: um plano de modelagem passo a passo

Por que planilhas viram bagunça quando viram um banco de dados

Uma planilha é ótima para uma lista pequena. Você pode mudar colunas na hora, adicionar notas em qualquer lugar e consertar problemas visualmente. Essa liberdade começa a entrar em colapso quando o arquivo vira a fonte de verdade compartilhada.

À medida que os dados crescem, os mesmos problemas aparecem repetidamente. Você vê duplicatas porque não há um lugar único para armazenar um cliente ou produto. Surgem valores conflitantes porque duas linhas discordam sobre a mesma coisa, como um número de telefone. Filtrar e gerar relatórios fica frustrante porque algumas colunas escondem listas ("Tags", "Products", "Attendees") ou misturam formatos ("$1,200", "1200", "1.2k").

Migrar de uma Google Sheet para um esquema relacional é sobre segurança. Um banco de dados impõe uma estrutura mais clara para que você possa consultar, validar e atualizar dados sem criar novas contradições.

Um modelo mental útil: uma linha deve representar uma coisa real. Se uma linha representa um negócio, um cliente e uma lista de produtos, atualizar qualquer um desses depois será doloroso.

Um teste rápido: uma única linha alguma vez precisa de dois valores para o mesmo campo?

• Um pedido tem vários produtos
• Um projeto tem vários membros da equipe
• Um cliente tem vários endereços

Se a resposta for sim, não é um problema de “linha larga”. É um problema de “tabela separada”. Uma vez modelado corretamente, você pode construir formulários e validações por cima em vez de depender de edições manuais frágeis.

Comece definindo o que a planilha realmente significa

Uma planilha pode parecer organizada e ainda significar coisas diferentes para pessoas diferentes. Antes de converter uma Google Sheet para um esquema relacional, concorde sobre o que a planilha está rastreando.

Comece pelos resultados, não pelas colunas. Quais decisões os dados devem suportar: um relatório semanal de receita, uma lista de tickets atrasados, um fluxo que atribui follow-ups ou uma consulta rápida durante uma ligação com o cliente? Se você não consegue nomear uma decisão, esse campo muitas vezes não pertence ao banco de dados.

Em seguida, identifique os substantivos escondidos nos cabeçalhos e nas notas. Eles geralmente viram suas futuras tabelas: customers, orders, products, invoices, tickets, agents, locations. Se uma coluna mistura dois substantivos (como “Customer + Company”), você está armazenando várias coisas em um só lugar.

Combine definições cedo

Pequenas diferenças de significado viram grandes limpezas depois. Fiquem claros sobre o básico:

• O que conta como um “order” (um orçamento, uma compra paga ou ambos)?
• O que é um “customer” (pessoa, empresa ou ambos)?
• Um pedido pode ter múltiplos produtos?
• Um email pode pertencer a vários clientes?
• O que “status” deve mostrar (estado atual ou histórico)?

Exemplo: se sua planilha tem uma linha por “Order” mas a célula “Products” contém uma lista separada por vírgula, decida se essa linha representa um checkout, um envio ou uma fatura. Cada escolha leva a um esquema diferente.

Congele uma cópia da planilha original como somente leitura. Você a usará para validar que as novas tabelas ainda respondem às mesmas perguntas.

Limpe a planilha para que a estrutura fique visível

Antes de converter uma Google Sheet para um esquema relacional, faça a planilha parecer dados, não um relatório. Bancos de dados precisam de linhas e colunas consistentes. Layout decorativo esconde padrões que você precisa modelar.

Remova truques de layout como células mescladas, múltiplas linhas de cabeçalho e subtotais dentro do intervalo de dados. Mantenha uma linha de cabeçalho e depois apenas linhas de registros. Se precisar de totais, coloque-os em uma aba de resumo separada para não misturarem com os registros reais.

Depois, padronize formatos em cada coluna. Um banco de dados não pode adivinhar que “1/2/24”, “2024-02-01” e “Feb 1” são a mesma data. O mesmo vale para telefones, moeda e nomes. Escolha um formato e use-o em todo lugar, mesmo que pareça rígido.

Uma limpeza curta que costuma compensar:

• Certifique-se de que cada linha representa uma coisa (um pedido, um cliente, um ticket).
• Remova linhas e colunas espaçadoras em branco.
• Substitua “N/A”, “-” e strings vazias por uma regra única que você vai manter.
• Marque quais colunas são calculadas vs digitadas por uma pessoa.

Finalmente, sinalize qualquer célula que contenha múltiplos valores, como “red, blue, green” em uma coluna. Não resolva o esquema ainda. Apenas marque essas colunas para lembrar que elas virarão linhas separadas depois.

Identifique grupos repetidos e campos que escondem listas

O maior sinal de alerta em modelagem de dados de planilha é repetição. Planilhas costumam comprimir “mais de uma coisa” em uma única linha repetindo colunas ou juntando múltiplos valores numa célula. Isso funciona para acompanhamento rápido e quebra quando você precisa filtrar, reportar ou atualizar consistentemente.

Padrões que geralmente significam “isso deve ser outra tabela”

Procure por estas formas:

• Colunas numeradas como Item 1, Item 2, Item 3 ou Phone 1, Phone 2.
• Blocos repetidos como campos de endereço duplicados para “Home” e “Work”.
• Células com vírgulas, quebras de linha ou “e” que combinam valores (por exemplo, “Mouse, Keyboard, Monitor”).
• Uma coluna que mistura dois conceitos, como “Approved 2025-01-10” ou “Alex (Manager)”.
• Uma linha que representa dois níveis ao mesmo tempo, como uma linha de Order que também tenta armazenar todos os Order Items.

Exemplo: se seu tracker de vendas usa Order ID, Customer, Product 1, Qty 1, Product 2, Qty 2, você vai bater numa parede. Alguns pedidos têm 1 item, outros 8. A planilha ou cresce para os lados indefinidamente ou começa a perder dados. Em um modelo relacional, “Orders” vira uma tabela e “Order Items” vira outra tabela com uma linha por produto no pedido.

Para “listas em célula”, trate cada valor como um registro próprio. Uma célula que diz “Email, SMS” geralmente significa que você precisa de uma tabela separada (ou uma tabela de junção) para rastrear canais claramente.

Colunas mistas são mais silenciosas, mas igualmente arriscadas. Separe-as cedo para que cada campo armazene um fato claro.

Crie tabelas a partir das entidades que você encontrou

Uma vez que você consiga nomear as coisas do mundo real na planilha, transforme cada uma em sua própria tabela. Sua planilha deixa de ser uma grande grade e vira um conjunto de listas menores e com propósito.

Se uma linha mistura detalhes sobre duas coisas diferentes, provavelmente precisa de duas tabelas. Uma linha de vendas pode incluir info do cliente (nome, telefone), info do pedido (data, status) e info do produto (SKU, preço). Clientes não mudam a cada pedido, e produtos não dependem de um único pedido. Separá-los evita edições duplicadas e valores desencontrados.

Antes de finalizar, escreva uma frase de propósito para cada tabela. Se você não consegue descrever o que a tabela representa sem dizer “e também”, ela costuma ser ampla demais.

Regras práticas:

• Mantenha atributos que descrevem a mesma coisa e compartilham o mesmo ciclo de vida juntos (customer name e customer email).
• Mova qualquer coisa que possa aparecer várias vezes para sua própria tabela (múltiplos itens de pedido, múltiplos endereços).
• Se uma célula contém uma lista (valores separados por vírgula, colunas repetidas), isso é uma tabela separada.
• Se dois conjuntos de campos mudam por razões diferentes, separe-os (status do pedido vs contato do cliente).

Então nomeie colunas de forma clara e consistente. Prefira substantivos simples e evite rótulos vagos como “Info” ou “Details”.

Escolha chaves que permaneçam estáveis ao longo do tempo

Escolha uma chave primária para cada tabela cedo. Uma boa chave é entediante: nunca muda, está sempre presente e identifica uma linha e só uma linha.

Chaves naturais (valores do mundo real) funcionam, mas só se forem realmente estáveis. Um SKU costuma ser uma boa chave natural porque tende a ser permanente. Emails parecem estáveis, mas pessoas mudam de email, compartilham caixas e criam duplicatas como “john@” e “john.work@”. Nomes, telefones e endereços mudam e não são garantidamente únicos.

Um padrão seguro é um ID auto-gerado (como customer_id, order_id). Mantenha o identificador natural como campo normal e adicione uma regra de unicidade quando fizer sentido para o negócio. Se um email mudar, o customer_id permanece e os pedidos relacionados continuam apontando para o cliente certo.

Regras simples para chaves:

• Use um ID auto quando o identificador do mundo real puder mudar, faltar ou ser reutilizado.
• Use chave natural apenas quando você a controla e ela foi desenhada para ser permanente (por exemplo, SKU).
• Marque campos como únicos só quando duplicatas forem erradas.
• Permita NULL apenas quando “desconhecido” for um estado válido; caso contrário, exija um valor.
• Anote o que “único” significa (único por tabela, por empresa ou por período de tempo).

Exemplo: em uma tabela Contacts, use contact_id como chave primária. Mantenha email único só se sua regra for um contato por email. Permita phone vazio porque nem todo mundo o compartilha.

Mapeie relacionamentos sem chutar

A maioria dos erros difíceis vem de chutar como as coisas se relacionam. Use uma regra simples: se uma linha “possui” muitos de algo, isso é um-para-muitos. Coloque a chave estrangeira no lado “muitos”.

Exemplo: um Customer pode ter muitos Orders. A tabela Orders deve armazenar customer_id. Se você mantiver uma lista separada por vírgula de números de pedido dentro de Customers, surgirão duplicatas e dados faltantes rapidamente.

Muitos-para-muitos é a armadilha comum em planilhas. Se um Order pode incluir muitos Products e um Product pode aparecer em muitos Orders, você precisa de uma tabela de junção (geralmente chamada line items). Ela normalmente inclui order_id, product_id e campos como quantidade e o preço no momento da compra.

Relacionamentos um-para-um são raros. Fazem sentido quando os dados extras são opcionais ou separados por privacidade ou performance (por exemplo, User e UserProfile). São sinal de alerta quando você separa uma tabela só porque a planilha tinha duas abas.

Histórico precisa de sua própria estrutura. Se valores podem mudar ao longo do tempo (status, preço, endereço), evite sobrescrever uma única coluna. Armazene mudanças como linhas em uma tabela de histórico para poder responder “o que era verdade naquela data?”

Normalize o suficiente para evitar contradições

Uma regra simples: armazene um fato em um só lugar. Se o telefone de um cliente aparece em cinco linhas, alguém vai atualizar quatro delas e esquecer a quinta.

Normalização em termos práticos:

1NF, 2NF, 3NF em termos práticos

Primeira forma normal (1NF) significa que cada célula contém um valor. Se uma coluna contém “red, blue, green” ou “SKU1|SKU2|SKU3”, isso é uma lista oculta. Quebre em linhas em uma tabela relacionada.

Segunda forma normal (2NF) aparece mais em itens de pedido. Se você tem OrderItems e a chave é (OrderID, ProductID), então campos como CustomerName não pertencem ali. Eles dependem do pedido, não do produto.

Terceira forma normal (3NF) significa que campos não-chave não devem depender de outros campos não-chave. Exemplo: se você armazena ZipCode e City, e City é determinado pelo ZipCode, você corre risco de inconsistência.

Um rápido auto-check:

• O mesmo valor pode ser editado em mais de um lugar?
• Uma mudança exigiria atualizar muitas linhas?
• Você está armazenando rótulos que podem ser derivados de um ID?
• Totais estão armazenados ao lado das linhas brutas que os produzem?

Quando desnormalizar é OK

Desnormalize principalmente para relatórios de leitura intensiva, e faça isso com segurança: trate a tabela de relatório como uma cópia que você pode recriar. Mantenha tabelas normalizadas como fonte da verdade.

Para valores derivados como totais, saldos e status, não os duplique a menos que você tenha uma regra clara de recálculo. Uma abordagem prática: armazene transações brutas, calcule totais em consultas e só faça cache quando a performance exigir.

Armadilhas comuns de modelagem que geram limpeza no futuro

A maioria dos problemas de “funcionou na planilha” vem de significado, não de ferramentas. O objetivo é fazer toda linha dizer uma coisa clara, do mesmo jeito, toda vez.

Armadilhas comuns:

• Usar nomes como IDs. “John Smith” não é identificador único e nomes mudam. Use um ID gerado (ou um email/telefone verificado) e trate nomes como rótulos de exibição.
• Empacotar listas numa célula. Parece simples, mas quebra busca, validação e relatórios. Listas pertencem a uma tabela relacionada.
• Misturar estado atual com histórico. Uma coluna Status não consegue dizer o estado mais recente e como ele mudou. Se o tempo importa, grave mudanças como eventos com timestamps.
• Sobrecarregar uma tabela para significar várias coisas. Uma planilha de Contacts que inclui customers, vendors e employees vira um emaranhado de campos que só se aplicam a algumas linhas. Separe por função ou mantenha uma tabela Person e adicione tabelas específicas por função.
• Ignorar campos obrigatórios vs opcionais. Se campos-chave podem ficar em branco, você terá linhas que não conseguem fazer joins corretamente. Decida o que é obrigatório e aplique cedo.

Se sua tabela Orders tem colunas como Item 1, Item 2, Item 3, você está vendo um grupo repetido. Planeje uma tabela Orders e uma OrderItems.

Checklist rápido antes de confirmar o esquema

Antes de travar o esquema, faça uma última revisão por clareza. A maior parte da dor futura vem de pequenos atalhos que pareciam inofensivos no começo.

Pergunte se cada tabela responde a uma pergunta simples. “Customers” deve significar clientes, não clientes mais o último pedido mais notas de ligação. Se não consegue descrever uma tabela em uma frase curta, ela está misturando coisas.

Verificações finais:

• Você consegue apontar a coluna (ou conjunto de colunas) que identifica unicamente cada linha, mesmo se nomes mudarem?
• Há células com mais de um valor (tags separadas por vírgula, múltiplos emails, colunas Item1/Item2)? Se sim, divida em uma tabela filha.
• Para cada relacionamento, ele está armazenado como uma chave estrangeira intencional? Para muitos-para-muitos, existe uma tabela de junção?
• Campos importantes têm regras (obrigatórios onde faltar quebra o processo, únicos onde duplicatas são prejudiciais)?
• Você consegue atualizar um fato (endereço do cliente, preço do produto, função do funcionário) em exatamente um lugar?

Teste da vida real: imagine alguém entra o mesmo cliente duas vezes com grafia ligeiramente diferente. Se seu esquema facilita isso, adicione uma chave melhor ou uma regra de unicidade.

Exemplo: transformar uma planilha de vendas em tabelas limpas

Imagine um tracker de vendas onde cada linha é um negócio. Ele tem colunas como Customer Name, Customer Email, Deal Amount, Stage, Close Date, Products (lista separada por vírgula) e Notes (às vezes várias notas numa célula).

Essa única linha esconde dois grupos repetidos: products (um negócio pode incluir muitos produtos) e notes (um negócio pode ter muitas notas). É aí que as conversões costumam dar errado, porque listas dentro de células são difíceis de consultar e fáceis de contradizer.

Um modelo “depois” limpo que corresponde ao comportamento real do trabalho:

• Customers (CustomerId, Name, Email)
• Deals (DealId, CustomerId, Amount, Stage, CloseDate)
• Products (ProductId, Name, SKU)
• DealProducts (DealId, ProductId, Quantity, UnitPrice)
• DealNotes (NoteId, DealId, NoteText, CreatedAt)

CustomerId, DealId e ProductId são identificadores estáveis. DealProducts resolve o relacionamento muitos-para-muitos: um negócio pode incluir muitos produtos e um produto pode aparecer em muitos negócios. DealNotes mantém as notas separadas, então você não termina com “Note 1, Note 2, Note 3” em colunas.

Antes da modelagem, um relatório como “receita por produto” significa dividir strings e torcer para que os nomes tenham sido digitados consistentemente. Depois da modelagem, vira uma consulta simples sobre DealProducts juntada a Deals e Products.

Próximos passos: do esquema para um app funcionando

Quando seu esquema parecer certo no papel, leve-o para um banco de dados real e teste com dados reais. Não importe tudo de uma vez. Carregue um lote pequeno primeiro, corrija o que quebrar e repita.

Uma ordem prática que mantém o risco baixo:

• Crie as tabelas e os relacionamentos.
• Importe 50 a 200 linhas, verifique totais e faça conferências pontuais.
• Corrija problemas de mapeamento (colunas erradas, IDs faltando, duplicatas) e reimporte.
• Quando estiver estável, carregue o resto.

Adicione regras de validação cedo para que hábitos bagunçados de planilha não retornem. Torne campos obrigatórios realmente obrigatórios, limite valores permitidos (como status), valide formatos (datas e emails) e use chaves estrangeiras para que você não crie um pedido para um cliente inexistente.

Então pare de usar a planilha para atualizações. Proteger seus dados fica muito mais fácil quando as pessoas têm formulários simples e fluxos de trabalho claros.

Se você quer transformar o esquema em uma ferramenta interna sem escrever código, AppMaster (appmaster.io) pode ajudar: modele tabelas e relacionamentos visualmente e gere backend pronto para produção, web app e apps nativos a partir do mesmo modelo.