--- term: 'Schema de Banco de Dados' seoTitle: 'O que é um Schema de Banco de Dados? Guia Completo' headline: 'O que é um schema de banco de dados?' slug: schema-de-banco-de-dados category: database shortDefinition: 'Um schema de banco de dados é a planta que define como os dados se organizam — as classes, colunas, tipos e relacionamentos, mas não os dados em si.' relatedTerms: - data-modeling - visual-database-management - class-level-permissions-clp - database-queries contrastsWith: - data-modeling faq: - question: 'O que é um schema de banco de dados, em termos simples?' answer: 'A planta de um banco de dados: quais tabelas ou classes existem, que colunas elas têm, o tipo de cada coluna, as chaves e constraints, e como os registros se relacionam. É metadado — a estrutura, não os dados armazenados. Mude o schema e você muda a forma que os dados podem assumir; os dados em si vivem dentro dessa forma.' - question: 'Qual é a diferença entre schema, banco de dados e instância?' answer: 'Três níveis de zoom. O banco de dados é o sistema inteiro — o motor mais os dados armazenados. O schema é sua estrutura formal, que muda raramente e de forma deliberada. Uma instância são os dados reais em um dado momento, mudando a cada escrita. Um schema, um banco, infinitas instâncias ao longo do tempo.' - question: 'Qual é a diferença entre schema lógico e físico?' answer: 'O schema lógico é o design independente de motor: entidades, atributos, relacionamentos, constraints — o que um diagrama ER desenha. O schema físico é como esse design aterrissa num motor específico: layout de armazenamento, índices, partições. Uma terceira camada, o schema de visão (ou externo), define o que cada consumidor enxerga. O mesmo design, três altitudes.' - question: 'O que um schema realmente contém?' answer: 'Os objetos de schema: tabelas ou classes, colunas com tipos de dados, chaves primárias e estrangeiras, constraints como NOT NULL, UNIQUE e CHECK, índices e views. Em alguns motores, "schema" tem ainda um segundo sentido — um namespace nomeado que agrupa esses objetos e carrega permissões de acesso, que é o que CREATE SCHEMA cria.' - question: 'Bancos NoSQL têm schema?' answer: '"Schemaless" é um nome enganoso — o schema sempre existe; a questão é quem o impõe e quando. Motores relacionais são schema-on-write: a estrutura é validada antes de os dados entrarem. Bancos de documentos usam schema-on-read por padrão: a estrutura vive nas expectativas da aplicação e é checada quando os dados são usados. A maioria das plataformas de documentos hoje também suporta validação, tornando o rigor um dial, não uma dicotomia.' - question: 'O que é uma migração de schema?' answer: 'Uma mudança versionada e roteirizada no schema — adicionar uma coluna, apertar uma constraint — aplicada de forma incremental e em ordem em todos os ambientes. Migrações são como schemas evoluem sem caos: cada mudança é revisável, repetível e reversível, e a versão do schema viaja junto com o código que espera por ela.' - question: 'O que são os schemas star e snowflake?' answer: 'Formatos de schema específicos de analytics. Um star schema coloca uma tabela fato central (eventos, vendas) entre tabelas de dimensão desnormalizadas — poucos joins, agregação rápida. Um snowflake normaliza essas dimensões em subtabelas — menos redundância, mais joins. Eles otimizam cargas de relatório e são primos, não concorrentes, dos schemas transacionais que backends de aplicação usam.' - question: 'Como um schema é definido num Backend as a Service?' answer: 'De duas formas complementares: visualmente — classes e colunas tipadas criadas num dashboard — e por inferência, em que salvar o primeiro objeto cria a classe e as colunas tipadas automaticamente, com campos padrão como objectId, createdAt, updatedAt e um ACL adicionados pela plataforma. O endurecimento de produção depois congela tudo: mudanças de schema vindas do cliente desligadas, evolução posterior pelo dashboard, de propósito.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Database schema (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Database_schema' - name: 'PostgreSQL — Data Definition documentation' url: 'https://www.postgresql.org/docs/current/ddl.html' - name: 'Introduction to database schemas — Prisma Data Guide' url: 'https://www.prisma.io/dataguide/intro/intro-to-schemas' - name: 'Back4app database hub documentation' url: 'https://www.back4app.com/docs' cta: title: 'Um schema que você pode ver' text: 'No Back4app o schema é uma superfície viva: crie classes e colunas tipadas no dashboard ou deixe o primeiro save inferi-las, navegue e evolua tudo visualmente e tranque com permissões por classe na hora de lançar.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-21' translationKey: database-schema --- **Um schema de banco de dados é a planta que define como os dados se organizam — as classes, colunas, tipos e relacionamentos, mas não os dados em si.** A trindade de uma linha que vale memorizar: o *schema* é a planta, a *instância* são os dados em um dado momento, e o *banco de dados* é o prédio inteiro. Plantas mudam raramente e de propósito; os cômodos se reenchem o tempo todo. ## Principais pontos | Pergunta | Resposta | | --- | --- | | O que é | Estrutura como metadado: tabelas/classes, colunas tipadas, chaves, constraints | | O que não é | Os dados — isso é a instância, que muda a cada escrita | | As três altitudes | Lógica (design) · física (armazenamento) · visão (o que cada consumidor vê) | | "Schemaless"? | Nome enganoso — schema-on-read só move a checagem para a hora do uso | | Como evolui | Migrações: mudanças versionadas, roteirizadas e revisáveis | ## A planta, por escrito Um schema na língua nativa — duas tabelas, chaves, uma constraint, um índice e uma view, o que cobre a maior parte do vocabulário: ```sql CREATE TABLE users ( id bigserial PRIMARY KEY, email text NOT NULL UNIQUE, -- constraint: sem duplicatas role text NOT NULL DEFAULT 'member' ); CREATE TABLE orders ( id bigserial PRIMARY KEY, user_id bigint NOT NULL REFERENCES users(id), -- relacionamento total numeric(10,2) CHECK (total >= 0), -- regra que os dados devem obedecer placed timestamptz NOT NULL DEFAULT now() ); CREATE INDEX orders_by_user ON orders (user_id, placed); -- camada física CREATE VIEW recent_orders AS -- camada de views SELECT * FROM orders WHERE placed > now() - interval '30 days'; ``` A mesma planta, numa plataforma de schema flexível, cresce a partir do que você salva — colunas tipadas inferidas na primeira escrita, visíveis imediatamente num dashboard: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // The schema grows typed columns from what you save const event = new Parse.Object('Event'); event.set('name', 'Launch day'); // String event.set('seats', 120); // Number event.set('startsAt', new Date('2026-09-01T18:00:00Z')); // Date event.set('venue', new Parse.GeoPoint(38.72, -9.14)); // GeoPoint await event.save(); // columns exist, typed, visible in the dashboard ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The schema grows typed columns from what you save final event = ParseObject('Event') ..set('name', 'Launch day') // String ..set('seats', 120) // Number ..set('startsAt', DateTime.parse('2026-09-01T18:00:00Z')) // Date ..set('venue', ParseGeoPoint(latitude: 38.72, longitude: -9.14)); await event.save(); // columns exist, typed, visible in the dashboard ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The schema is a typed struct — columns mirror the model struct Event: ParseObject { var objectId: String?; var createdAt: Date? var updatedAt: Date?; var ACL: ParseACL?; var originalData: Data? var name: String? // String column var seats: Int? // Number column var startsAt: Date? // Date column var venue: ParseGeoPoint? // GeoPoint column } var event = Event(); event.name = "Launch day"; event.seats = 120 event.save { _ in } // columns exist, typed, visible in the dashboard ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The schema grows typed columns from what you save val event = ParseObject("Event").apply { put("name", "Launch day") // String put("seats", 120) // Number put("startsAt", Date()) // Date put("venue", ParseGeoPoint(38.72, -9.14)) // GeoPoint } event.saveInBackground() // columns exist, typed, visible in the dashboard ``` ## Lógico vs. físico vs. visão ```mermaid flowchart LR accTitle: As três camadas de schema accDescr: O schema lógico guarda o design independente de motor, com entidades e relacionamentos; o schema físico o mapeia para o armazenamento com índices e partições; os schemas de visão expõem fatias sob medida para cada consumidor. L["Schema lógico
entidades · relacionamentos · constraints
(o diagrama ER)"] P["Schema físico
armazenamento · índices · partições
(a realidade de um motor)"] V["Schemas de visão
fatias sob medida por consumidor"] L --> P --> V ``` | Distinção | Isto | vs. aquilo | | --- | --- | --- | | Schema vs. instância | A planta, muda raramente | O retrato dos dados, muda o tempo todo | | Lógico vs. físico | Design independente de motor | Decisões de armazenamento de um motor específico | | Planta vs. namespace | "O schema" do seu app | `CREATE SCHEMA` — um contêiner nomeado de objetos, com permissões | | Schema-on-write vs. on-read | Validado antes de os dados entrarem (relacional) | Imposto na hora do uso (padrão dos documentos) | | Transacional vs. analítico | Schemas de app normalizados | Formatos star/snowflake feitos para agregação | A terceira linha desarma uma ambiguidade genuína que a maioria dos explicadores pula: em alguns motores a palavra também nomeia um *namespace* — um contêiner de tabelas com permissões — então "o schema" pode significar a planta do seu app ou uma pasta dentro do banco, e o contexto decide. ## Schema-on-write vs. schema-on-read Bancos "schemaless" têm schema — eles só cobram por ele de outro jeito. **Schema-on-write** valida a estrutura antes de os dados entrarem: tipo errado, campo faltando, referência quebrada — rejeitados na porta. **Schema-on-read** aceita escritas com flexibilidade e impõe as expectativas quando os dados são usados — iteração mais rápida, e cada leitor vira um validador. A posição moderna é um dial, não uma guerra: plataformas de documentos adicionam validação, motores relacionais adicionam colunas JSON, e backends gerenciados dividem a diferença — tipos inferidos e impostos por coluna, enquanto colunas novas aparecem sem cerimônia de migração. A pergunta sobre rigor é, no fundo, uma pergunta sobre responsabilidade: *quem* encontra o registro malformado — o banco na hora da escrita ou o seu código às 2 da manhã? ## Como schemas evoluem A planta sobrevive ao primeiro rascunho, e **migrações** são como ela muda sem caos: cada mudança de schema é um script versionado — adicione a coluna, faça o backfill, aperte a constraint — aplicado em ordem, em todos os ambientes, revisado como o código que depende dele. Duas disciplinas carregam a maior parte do valor: fazer mudanças *retrocompatíveis* na janela em que código velho e novo convivem (adicionar, depois migrar, depois remover — nunca renomear no lugar), e manter a versão do schema no repositório, para que código e estrutura viajem juntos. Em plataformas gerenciadas por dashboard, a mesma disciplina vale com outro ferramental — evolua visualmente, mas de propósito, com mudanças de schema vindas do cliente desabilitadas em produção. ## Casos de uso comuns - **Projetar um backend novo.** O schema é a saída da [modelagem de dados](/glossary/data-modeling/): entidades e arestas viram classes, colunas e chaves. - **Impor integridade.** Constraints como regras executáveis — totais não negativos, e-mails únicos — capturadas pelo motor, não por bug report. - **Contrato do time.** O schema é o vocabulário compartilhado entre backend, frontend e analytics; um diagrama ER é documentação que não deriva. - **Alicerce de performance.** Índices e layout físico — o andar de baixo do schema — decidem quais queries continuam rápidas em escala. - **Superfície de segurança.** Permissões no nível do schema controlam quem pode fazer o quê por classe — estrutura e controle de acesso num lugar só. ## Quão estrito seu schema deveria ser? Matriz de decisão | Prefira estrito (schema-on-write) quando… | Prefira flexível (inferir + validar) quando… | | --- | --- | | Erros de dados custam caro (dinheiro, estoque) | Você itera no produto toda semana | | Muitos escritores, um contrato | Um único time é dono do código e dos dados | | A analytics depende de colunas estáveis | Os campos variam de verdade por registro | | Constraints codificam regras de negócio | As regras já vivem na validação server-side de todo jeito | | Migrações são rotina para o time | A cerimônia de migração atrasaria a descoberta | O default pragmático para backends de aplicação: flexível enquanto você aprende, endurecendo quando você lança — infira o schema durante o desenvolvimento e congele-o (sem mudanças de schema pelo cliente, criação de campos desligada) no dia em que os usuários reais chegarem. ## Limitações e trade-offs - **O schema congela premissas.** Cada decisão de tipo de coluna e de cardinalidade é barata hoje e uma migração amanhã — projete para o tamanho seguinte. - **Rigor taxa a iteração.** Todo experimento paga o pedágio da migração; é o preço das garantias, não um defeito. - **Flexibilidade taxa os leitores.** Schema-on-read move a validação para dentro de cada consumidor; sem disciplina, "flexível" vira "cinco formatos do mesmo registro". - **A camada física é invisível até deixar de ser.** Índices e layout não mudam a corretude — só se as queries sobrevivem ao crescimento. - **Permissões de namespace não são design.** `CREATE SCHEMA` organiza e controla o acesso a objetos; ele não torna a planta boa. ## O schema no Back4app O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O schema é uma superfície visível, de primeira classe: defina classes e colunas tipadas no dashboard, ou deixe o primeiro save inferi-las — as abas de código acima criam colunas tipadas reais, com `objectId`, `createdAt`, `updatedAt` e um ACL adicionados a toda classe por padrão. Tudo o que o schema declara se reflete na hora nas [APIs geradas automaticamente](/glossary/pt/apis-geradas-automaticamente/), fica guardado por [permissões no nível de classe](/glossary/class-level-permissions-clp/) e navegável no [dashboard visual](/glossary/visual-database-management/) — a planta, a imposição das regras e a documentação num artefato só.