--- term: 'Esquema de Base de Datos' seoTitle: '¿Qué es un Esquema de Base de Datos? Guía Completa' headline: '¿Qué es un esquema de base de datos?' slug: esquema-de-base-de-datos category: database shortDefinition: 'Un esquema de base de datos es un plano que define cómo se organizan los datos — las clases, columnas, tipos y relaciones, pero no los datos.' relatedTerms: - data-modeling - visual-database-management - class-level-permissions-clp - database-queries contrastsWith: - data-modeling faq: - question: '¿Qué es un esquema de base de datos, en términos simples?' answer: 'El plano de una base de datos: qué tablas o clases existen, qué columnas tienen, el tipo de cada columna, las claves y constraints, y cómo se relacionan los registros. Son metadatos — la estructura, no los datos almacenados. Cambia el esquema y cambias la forma que los datos pueden tomar; los datos en sí viven dentro de esa forma.' - question: '¿Cuál es la diferencia entre esquema, base de datos e instancia?' answer: 'Tres niveles de zoom. La base de datos es el sistema completo — el motor más los datos almacenados. El esquema es su estructura formal, que cambia rara vez y con deliberación. Una instancia son los datos reales en un momento dado, que cambian con cada escritura. Un esquema, una base de datos, infinitas instancias a lo largo del tiempo.' - question: '¿Cuál es la diferencia entre un esquema lógico y uno físico?' answer: 'El esquema lógico es el diseño independiente del motor: entidades, atributos, relaciones, constraints — lo que dibuja un diagrama ER. El esquema físico es cómo ese diseño aterriza en un motor específico: layout de almacenamiento, índices, particiones. Una tercera capa, el esquema de vista (o externo), define lo que cada consumidor ve. El mismo diseño, tres altitudes.' - question: '¿Qué contiene realmente un esquema?' answer: 'Los objetos del esquema: tablas o clases, columnas con tipos de datos, claves primarias y foráneas, constraints como NOT NULL, UNIQUE y CHECK, índices y vistas. En algunos motores "schema" tiene además un segundo sentido — un namespace con nombre que agrupa esos objetos y lleva permisos de acceso, que es lo que CREATE SCHEMA crea.' - question: '¿Las bases de datos NoSQL tienen esquema?' answer: '"Schemaless" es un nombre engañoso — el esquema siempre existe; la pregunta es quién lo impone y cuándo. Los motores relacionales son schema-on-write: la estructura se valida antes de que los datos entren. Las bases de documentos usan schema-on-read por defecto: la estructura vive en las expectativas de la aplicación y se verifica al usar los datos. La mayoría de las plataformas de documentos hoy también soporta validación, volviendo el rigor una perilla y no una dicotomía.' - question: '¿Qué es una migración de esquema?' answer: 'Un cambio al esquema, versionado y en forma de script — agregar una columna, endurecer un constraint — aplicado de manera incremental y en orden en todos los entornos. Las migraciones son la forma en que los esquemas evolucionan sin caos: cada cambio es revisable, repetible y reversible, y la versión del esquema viaja con el código que la espera.' - question: '¿Qué son los esquemas star y snowflake?' answer: 'Formas de esquema específicas de analítica. Un esquema star coloca una tabla de hechos central (eventos, ventas) entre tablas de dimensión desnormalizadas — pocos joins, agregación rápida. Un snowflake normaliza esas dimensiones en subtablas — menos redundancia, más joins. Optimizan cargas de reportes y son primos, no competidores, de los esquemas transaccionales que usan los backends de aplicación.' - question: '¿Cómo se define un esquema en un Backend as a Service?' answer: 'De dos maneras complementarias: visualmente — clases y columnas tipadas creadas en un dashboard — y por inferencia, donde guardar el primer objeto crea la clase y las columnas tipadas automáticamente, con campos por defecto como objectId, createdAt, updatedAt y un ACL agregados por la plataforma. El endurecimiento de producción luego lo congela: cambios de esquema desde el cliente apagados, y la evolución posterior por el dashboard, a 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: 'Un esquema que puedes ver' text: 'En Back4app el esquema es una superficie viva: crea clases y columnas tipadas en el dashboard o deja que el primer guardado las infiera, explora y evoluciona todo visualmente, y asegúralo con permisos a nivel de clase cuando lances.' linkText: 'Empieza gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-31' translationKey: database-schema --- **Un esquema de base de datos es un plano que define cómo se organizan los datos — las clases, columnas, tipos y relaciones, pero no los datos.** La trinidad de una línea que vale la pena memorizar: el *esquema* es el plano, una *instancia* son los datos en un momento dado, y la *base de datos* es el edificio completo. Los planos cambian rara vez y con deliberación; las habitaciones se rellenan constantemente. ## Puntos clave | Pregunta | Respuesta | | --- | --- | | Qué es | Estructura como metadatos: tablas/clases, columnas tipadas, claves, constraints | | Qué no es | Los datos — eso es la instancia, que cambia con cada escritura | | Las tres altitudes | Lógico (diseño) · físico (almacenamiento) · vista (lo que cada consumidor ve) | | ¿"Schemaless"? | Un nombre engañoso — schema-on-read solo mueve la validación al momento de la consulta | | Cómo evoluciona | Migraciones: cambios versionados, en scripts, revisables | ## El plano, por escrito Un esquema en su lengua nativa — dos tablas, claves, un constraint, un índice y una vista, que es la mayor parte del vocabulario: ```sql CREATE TABLE users ( id bigserial PRIMARY KEY, email text NOT NULL UNIQUE, -- constraint: sin duplicados role text NOT NULL DEFAULT 'member' ); CREATE TABLE orders ( id bigserial PRIMARY KEY, user_id bigint NOT NULL REFERENCES users(id), -- relación total numeric(10,2) CHECK (total >= 0), -- regla que los datos deben cumplir placed timestamptz NOT NULL DEFAULT now() ); CREATE INDEX orders_by_user ON orders (user_id, placed); -- capa física CREATE VIEW recent_orders AS -- capa de vistas SELECT * FROM orders WHERE placed > now() - interval '30 days'; ``` El mismo plano, en una plataforma de schema flexible, crece a partir de lo que guardas — columnas tipadas inferidas en la primera escritura, visibles de inmediato en un 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. vista ```mermaid flowchart LR accTitle: Las tres capas del esquema accDescr: El esquema lógico contiene el diseño independiente del motor, con entidades y relaciones; el esquema físico lo mapea al almacenamiento con índices y particiones; los esquemas de vista exponen porciones a la medida de cada consumidor. L["Esquema lógico
entidades · relaciones · constraints
(el diagrama ER)"] P["Esquema físico
almacenamiento · índices · particiones
(la realidad de un motor)"] V["Esquemas de vista
porciones a la medida por consumidor"] L --> P --> V ``` | Distinción | Esto | vs. aquello | | --- | --- | --- | | Esquema vs. instancia | El plano, cambia rara vez | La foto de los datos, cambia constantemente | | Lógico vs. físico | Diseño independiente del motor | Decisiones de almacenamiento de un motor específico | | Plano vs. namespace | "El esquema" de tu app | `CREATE SCHEMA` — un contenedor con nombre de objetos, con permisos | | Schema-on-write vs. on-read | Validado antes de que los datos entren (relacional) | Impuesto al momento del uso (el default de documentos) | | Transaccional vs. analítico | Esquemas de app normalizados | Formas star/snowflake hechas para agregación | La tercera fila desactiva una ambigüedad genuina que la mayoría de los explicadores omite: en algunos motores la palabra también nombra un *namespace* — un contenedor de tablas con permisos — así que "el schema" puede significar el plano de tu app o una carpeta dentro de la base de datos, y el contexto decide. ## Schema-on-write vs. schema-on-read Las bases de datos "schemaless" tienen esquema — solo que lo cobran de otra manera. **Schema-on-write** valida la estructura antes de que los datos entren: tipo equivocado, campo faltante, referencia rota — rechazados en la puerta. **Schema-on-read** acepta escrituras con flexibilidad e impone las expectativas cuando los datos se usan — iteración más rápida, y cada lector se convierte en un validador. La postura moderna es una perilla, no una guerra: las plataformas de documentos agregan validación, los motores relacionales agregan columnas JSON, y los backends gestionados parten la diferencia — tipos inferidos e impuestos por columna, mientras las columnas nuevas aparecen sin ceremonia de migración. La pregunta sobre el rigor es en realidad una pregunta sobre responsabilidad: ¿*quién* encuentra el registro malformado — la base de datos al escribir o tu código a las 2 de la mañana? ## Cómo evolucionan los esquemas El plano sobrevive a su primer borrador, y las **migraciones** son la manera en que cambia sin caos: cada cambio de esquema es un script versionado — agrega la columna, haz el backfill, endurece el constraint — aplicado en orden, en cada entorno, revisado como el código que depende de él. Dos disciplinas cargan la mayor parte del valor: hacer cambios *retrocompatibles* en la ventana en que el código viejo y el nuevo conviven (agregar, luego migrar, luego eliminar — nunca renombrar en el lugar), y mantener la versión del esquema en el repositorio para que código y estructura viajen juntos. En plataformas gestionadas por dashboard aplica la misma disciplina con otras herramientas — evoluciona visualmente, pero con deliberación, con los cambios de esquema desde el cliente deshabilitados en producción. ## Casos de uso comunes - **Diseñar un backend nuevo.** El esquema es la salida del [modelado de datos](/glossary/data-modeling/): entidades y aristas se convierten en clases, columnas y claves. - **Imponer integridad.** Constraints como reglas ejecutables — totales no negativos, emails únicos — capturadas por el motor, no por reportes de bugs. - **Contrato del equipo.** El esquema es el vocabulario compartido entre backend, frontend y analítica; un diagrama ER es documentación que no puede desincronizarse. - **Cimientos de performance.** Los índices y el layout físico — el piso de abajo del esquema — deciden qué queries se mantienen rápidas a escala. - **Superficie de seguridad.** Los permisos a nivel de esquema controlan quién puede hacer qué por clase — estructura y control de acceso en un solo lugar. ## ¿Qué tan estricto debería ser tu esquema? Matriz de decisión | Prefiere estricto (schema-on-write) cuando… | Prefiere flexible (inferir + validar) cuando… | | --- | --- | | Los errores de datos cuestan caro (dinero, inventario) | Estás iterando el producto cada semana | | Muchos escritores, un solo contrato | Un solo equipo es dueño del código y de los datos | | La analítica depende de columnas estables | Los campos varían genuinamente por registro | | Los constraints codifican reglas de negocio | Las reglas ya viven en la validación server-side de todos modos | | Las migraciones son rutina para el equipo | La ceremonia de migración frenaría el descubrimiento | El default pragmático para backends de aplicación: flexible mientras aprendes, endureciendo cuando lanzas — infiere el esquema durante el desarrollo, y congélalo (sin cambios de esquema desde el cliente, creación de campos apagada) el día en que lleguen los usuarios reales. ## Limitaciones y trade-offs - **El esquema congela supuestos.** Cada decisión de tipo de columna y de cardinalidad es barata hoy y una migración mañana — diseña para la talla siguiente. - **El rigor le cobra a la iteración.** Cada experimento paga el peaje de la migración; ese es el precio de las garantías, no un defecto. - **La flexibilidad les cobra a los lectores.** Schema-on-read mueve la validación a cada consumidor; sin disciplina, "flexible" se convierte en "cinco formas del mismo registro". - **La capa física es invisible hasta que deja de serlo.** Los índices y el layout no cambian la corrección — solo si las queries sobreviven al crecimiento. - **Los permisos por namespace no son diseño.** `CREATE SCHEMA` organiza y controla el acceso a objetos; no hace que el plano sea bueno. ## El esquema en Back4app Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El esquema es una superficie visible, de primera clase: define clases y columnas tipadas en el dashboard, o deja que el primer guardado las infiera — las pestañas de código de arriba crean columnas tipadas reales, con `objectId`, `createdAt`, `updatedAt` y un ACL agregados a cada clase por defecto. Todo lo que el esquema declara se refleja al instante en las [APIs generadas automáticamente](/glossary/es/apis-generadas-automaticamente/), queda custodiado por [permisos a nivel de clase](/glossary/class-level-permissions-clp/) y es navegable en el [dashboard visual](/glossary/visual-database-management/) — el plano, la imposición de las reglas y la documentación en un solo artefacto.