Última actualización: 2026-10-19

Contenido de esta página

• ¿Qué son los fundamentos de bases de datos?
• Tabla, registro y campo: los conceptos básicos de una base de datos
• Esquema e instancia: el molde y lo que hay dentro
• Claves: candidata, primaria, alternativa, compuesta y foránea
• Cardinalidad de las relaciones e integridad: las reglas entre tablas
• DDL, DML, DCL y TCL: las cuatro familias de sentencias SQL
• Arquitectura ANSI/SPARC de tres niveles e independencia de datos
• Redundancia y anomalías: lo que sale mal con un mal diseño
• Glosario de bases de datos de la A a la Z (40 términos)
• Temario de un curso de fundamentos de bases de datos
• ¿Por qué empezar un curso por el vocabulario?

Historia real. En junio de 1970, Edgar F. Codd publicó el artículo que propuso el modelo relacional de datos [1]. Trabajaba en el laboratorio de IBM, el fabricante estadounidense de computadores, en San José, California. Entre sus definiciones dejó una queja que no era matemática, sino de vocabulario. Escribió que «buena parte de la confusión en la terminología actual se debe a no distinguir entre tipo e instancia (como en “registro”)» [1]. La traducción es mía, como la de la otra cita en inglés de esta página.

La palabra «registro» servía para dos cosas. A veces nombraba el molde, es decir, los campos que tiene la ficha de cualquier cliente. Otras veces nombraba una ficha ya llena, la de un cliente concreto con su nombre y su teléfono. Dos personas podían usar la misma palabra para cosas distintas sin notarlo.

Esta página parte de esa distinción.

Antes de diseñar una tabla o escribir una consulta hace falta un vocabulario en el que cada palabra signifique una sola cosa. Eso son los fundamentos de bases de datos. Esta página los reúne en 40 términos, con un ejemplo y el error que más se repite en cada uno, y cierra con el temario de un curso.

¿Qué son los fundamentos de bases de datos?

Los fundamentos de bases de datos son los conceptos que se necesitan antes de diseñar o consultar cualquier base. Explican cómo se organizan los datos en tablas, cómo se identifica cada fila y qué reglas impiden datos incoherentes. También nombran las familias de órdenes con que se trabaja y los niveles en que se describe todo eso. Un curso universitario empieza justo por ahí, antes de llegar al lenguaje de consulta [2].

La tabla agrupa ese vocabulario en seis bloques. Cada término tiene abajo su propia entrada.

Bloque	Pregunta que responde	Términos clave
Estructura	¿Dónde y cómo se guardan los datos?	tabla, registro, campo, dominio, valor nulo, grado
Molde y contenido	¿Qué parte es fija y qué parte cambia?	esquema, instancia, modelo de datos
Claves	¿Cómo se distingue una fila de otra y cómo se conectan las tablas?	clave candidata, primaria, alternativa, compuesta y foránea
Reglas	¿Qué impide guardar datos imposibles?	cardinalidad, integridad referencial, integridad de entidad, restricción
Lenguaje	¿Con qué órdenes se crea, se llena y se protege una base?	DDL, DML, DCL, TCL, transacción
Arquitectura y diseño	¿Por qué un cambio no rompe todo y qué sale mal con un mal diseño?	tres niveles, independencia, redundancia, anomalías, normalización

Concepto de base de datos en una frase

Una base de datos es una colección organizada de datos sobre un problema concreto, que pueden compartir varios usuarios o programas [3]. Qué es en detalle, para qué sirve y qué tipos existen lo desarrolla la guía qué es una base de datos.

Fundamentos de una base de datos: sus elementos básicos

El curso de la Universidad de Cantabria resume en un esquema lo que guarda una base de datos: datos, relaciones entre ellos y restricciones [3]. Esas tres piezas sirven para almacenar, controlar, consultar y actualizar información [3]. Todo lo demás de esta página es el detalle de esas tres palabras.

Tabla, registro y campo: los conceptos básicos de una base de datos

Una tabla organiza la información de un tema en filas y columnas, como el cuaderno de un contador o una hoja de cálculo [4]. Cada fila es un registro y cada columna es un campo [4]. Esa terna, tabla, registro y campo, es la primera que se aprende y la que más nombres distintos recibe según el libro.

En la práctica (y en Excel)	En una base de datos	En el modelo relacional
Hoja	Tabla	Relación
Fila	Registro	Tupla
Columna	Campo	Atributo
Tipo de dato permitido	Tipo de la columna	Dominio

Los equivalentes de la última columna salen de la terminología del modelo relacional [5]. La equivalencia entre tabla y relación tiene una advertencia, que aparece abajo en su propia entrada.

Tabla

Una tabla tiene un número fijo de columnas, cada una con nombre, y un número variable de filas que refleja cuántos datos hay en cada momento [6].

• Ejemplo: la tabla municipio, con una fila por municipio y tres columnas: código, nombre y departamento.
• Error típico: creer que las filas guardan un orden. SQL no garantiza ningún orden al leer una tabla; si lo necesita, debe pedirlo con la cláusula ORDER BY (ordenar por) [6].

Registro (fila o tupla)

Un registro reúne, en una sola fila, la información de una cosa concreta: un producto, un pedido, un cliente [4]. En el modelo relacional, cada fila es una tupla, una ocurrencia de la relación [5].

• Ejemplo: la fila de Bucaramanga, con su código, su nombre y su departamento.
• Error típico: suponer que el gestor impide filas repetidas. Sin una clave, SQL permite guardar varias filas idénticas en la misma tabla [6].

Campo (columna o atributo)

Un campo es un único dato que aparece en todos los registros de la tabla, como el nombre o el precio de un producto [4]. En el modelo relacional se llama atributo y representa una propiedad de la relación [5].

• Ejemplo: el campo nombre de la tabla municipio.
• Error típico: meter dos datos en un campo. Microsoft recomienda separar en campos distintos el nombre y los apellidos, o el producto y su categoría [4].

Dominio

El dominio es el conjunto de valores válidos que puede tomar un atributo; existe aparte de cualquier tabla y varios atributos pueden compartirlo [5].

• Ejemplo: los días de la semana, o los códigos de municipio de cinco dígitos.
• Error típico: dar por hecho que declarar el tipo de columna basta para cerrar el dominio. SQLite es flexible: si una columna INTEGER (de números enteros) recibe el texto ‘xyz’, guarda el texto tal cual, salvo que la tabla se declare STRICT, opción disponible desde la versión 3.37.0 [7].

Valor nulo (NULL)

El valor nulo representa información desconocida, inaplicable o no proporcionada, como la fecha de devolución de un préstamo que sigue abierto [5].

• Ejemplo: la profesión de un menor de edad en una tabla de personas.
• Error típico: tratar el nulo como un cero. Una suma con un operando nulo da nulo, y las funciones de agregación ignoran esas filas, salvo count(*) [5].

Grado y cardinalidad de una tabla

El grado de una relación es su número de atributos, y su cardinalidad, el número de tuplas que contiene [5]. Codd ya hablaba de relaciones de grado n en su artículo de 1970 [1].

• Ejemplo: una tabla de municipios con 3 columnas y 3 filas tiene grado 3 y cardinalidad 3.
• Error típico: confundir esta cardinalidad, que cuenta filas, con la cardinalidad de una relación entre tablas, que dice cuántas filas de una tabla se asocian con otra (ver más abajo).

Relación

En el modelo relacional, relación es el término matemático para lo que en la práctica se llama tabla [8]. Por eso el modelo se llama relacional: por las tablas, no por los vínculos entre ellas [5].

• Ejemplo: la relación cliente, con atributos nombre, calle y ciudad.
• Error típico: usar «relación» y «tabla» como sinónimos exactos. Una relación es un conjunto, así que no admite dos tuplas iguales ni tiene orden; una tabla puede tener filas repetidas y un orden de grabación [5].

Esquema e instancia: el molde y lo que hay dentro

El esquema es la estructura de la base: los atributos con sus dominios. La instancia es el conjunto de tuplas que hay guardadas en un momento determinado [5]. Es la distinción entre tipo e instancia que pedía Codd, ahora con nombre propio.

Esquema

Un esquema es la descripción de una colección de datos según un modelo de datos; define su estructura [9]. Sin esquema, advierte el curso de bases de datos de Carnegie Mellon, solo quedan bits sin significado [9].

• Ejemplo: municipio (cod_mpio, nombre, cod_dpto), con el tipo de cada columna.
• Error típico: llamar esquema a los datos. El esquema cambia poco y casi siempre con una orden explícita; los datos cambian con cada venta o matrícula.

Instancia

La instancia son los datos que la base contiene en un momento determinado [5].

• Ejemplo: las tres filas de la tabla municipio a las 10 de la mañana de hoy.
• Error típico: describir una base de datos por una instancia. Que hoy ningún municipio tenga nombre repetido no significa que el esquema lo prohíba; eso solo lo garantiza una restricción.

Modelo de datos

Un modelo de datos es un conjunto de conceptos, reglas y convenciones para describir los datos, sus relaciones, su significado y sus restricciones [5]. El relacional es el más común; también existen el de documentos, el de grafos o el de clave-valor [9].

• Ejemplo: el modelo relacional, que describe todo como tablas.
• Error típico: confundir el modelo con el producto. MySQL o PostgreSQL son programas que implementan el modelo relacional, no el modelo mismo.

Claves: candidata, primaria, alternativa, compuesta y foránea

Una clave es la columna, o el grupo de columnas, que identifica cada fila sin ambigüedad. Codd ya preveía en 1970 que una relación tuviera más de una combinación capaz de hacerlo, y que se eligiera una de ellas como clave primaria [1]. Hoy cursos como el de la Universidad de Cantabria llaman claves candidatas a todas esas combinaciones posibles [5].

Clave candidata

Una clave candidata es un conjunto de atributos que identifica cada tupla de forma única y mínima, es decir, sin atributos de sobra [5]. Toda relación tiene al menos una [5].

• Ejemplo: en una tabla de empleados, el número de empleado y el número de documento de identidad.
• Error típico: añadir columnas «por si acaso». Si el documento ya identifica a la persona, documento más nombre deja de ser mínimo y ya no es candidata.

Clave primaria

La clave primaria es la clave candidata que el diseñador elige para identificar las filas; sus valores no se repiten ni pueden quedar vacíos [5] [10]. Una tabla puede tener como máximo una [10].

• Ejemplo: cod_mpio en la tabla municipio.
• Error típico: suponer que el gestor obliga a declararla. La teoría relacional pide que toda tabla tenga clave primaria, pero PostgreSQL no lo exige, aunque recomienda seguir la regla [10].

Clave alternativa

Las claves alternativas son las claves candidatas que no se escogieron como primaria [5].

• Ejemplo: si la primaria de empleados es el número interno, el documento de identidad queda como alternativa.
• Error típico: dejarla sin protección. Para que no se repita hay que declararla con la restricción UNIQUE, que es justo la que permite definir claves alternativas [5].

Clave compuesta

Una clave compuesta es la que necesita más de una columna para identificar cada fila; PostgreSQL permite declarar así una clave primaria [10].

• Ejemplo: en una tabla de notas, la pareja estudiante y asignatura.
• Error típico: pensar que cada columna debe ser única por separado. En el ejemplo de Codd, la combinación de proveedor, pieza y proyecto es la clave primaria, mientras que cada una de esas columnas, por separado, es una clave foránea [1].

Clave foránea (ajena o externa)

Una clave foránea es la columna de una tabla cuyos valores deben coincidir con los de una clave de otra tabla, o de la misma [5]. Así se conectan las tablas: la columna del proveedor en la tabla de productos apunta a la tabla de proveedores [4].

• Ejemplo: cod_dpto en la tabla municipio, que apunta a la tabla departamento.
• Error típico: creer que solo puede apuntar a la clave primaria. En PostgreSQL puede apuntar a columnas declaradas como primaria o como únicas [10].

Cardinalidad de las relaciones e integridad: las reglas entre tablas

Las claves conectan las tablas; las reglas de integridad impiden que esa conexión se rompa. Aquí entran la cardinalidad de una relación entre tablas, las dos integridades clásicas y las restricciones que el gestor revisa en cada cambio.

Cardinalidad de una relación: 1:1, 1:N y N:M

La cardinalidad de una relación entre tablas dice cuántas filas de una tabla pueden asociarse con una fila de la otra: uno a uno, uno a varios o varios a varios [4].

• Ejemplo: un proveedor puede surtir muchos productos (uno a varios); un pedido incluye varios productos y un producto aparece en muchos pedidos (varios a varios) [4].
• Error típico: resolver un varios a varios con una sola columna. Hace falta una tabla intermedia, como los detalles de pedido, que guarde cada pareja [4]. Los tres tipos, con ejemplos resueltos, están en la guía de bases de datos relacionales.

Integridad referencial

La integridad referencial es la regla de que todo valor de una clave foránea coincida con un valor de la clave a la que apunta, o sea nulo [5]. En PostgreSQL, esa restricción hace imposible crear un pedido de un producto que no existe en la tabla de productos [10].

• Ejemplo: no se puede registrar un municipio del departamento 99 si ese departamento no existe.
• Error típico: confiar en que el gestor la revisa siempre. En SQLite viene apagada por compatibilidad y hay que activarla en cada conexión con la orden PRAGMA foreign_keys = ON (activar las claves foráneas) [11].

Integridad de entidad

La regla de integridad de entidad dice que ningún atributo que forme parte de la clave primaria puede tomar un valor nulo [5].

• Ejemplo: un municipio sin código no puede entrar a la tabla.
• Error típico: permitir nulos en una parte de una clave compuesta. La regla aplica a cada columna de la clave, no solo a la primera.

Restricción (CHECK, UNIQUE y NOT NULL)

Una restricción es una condición que debe cumplirse en cualquier instancia de la base; las más comunes son las de unicidad y las de clave foránea [9]. CHECK (verificar) comprueba una condición en cada cambio, UNIQUE (único) impide repetidos y NOT NULL (no nulo) impide vacíos [5].

• Ejemplo: CHECK (length(cod_mpio) = 5) rechaza un código de municipio con cuatro dígitos.
• Error típico: validar solo en el formulario. Cuando las reglas viven en el código de cada programa y no en la base, cambiarlas o añadir una nueva es difícil y costoso [3].

DDL, DML, DCL y TCL: las cuatro familias de sentencias SQL

SQL (lenguaje de consulta estructurado) es el idioma estándar para trabajar con bases de datos relacionales. Lo fija la norma internacional ISO/IEC 9075, y su parte 1 define el marco conceptual y los términos de las demás partes [12]. Sus sentencias se suelen agrupar en cuatro familias. Ya la propuesta de 1975 de la arquitectura de tres niveles pedía lenguajes de definición, de manipulación y de control de datos [13].

Familia	Para qué sirve	Sentencias típicas
DDL (lenguaje de definición de datos)	Crear, cambiar y borrar la estructura	CREATE, ALTER, DROP
DML (lenguaje de manipulación de datos)	Leer y cambiar los datos	SELECT, INSERT, UPDATE, DELETE
DCL (lenguaje de control de datos)	Dar y quitar permisos	GRANT, REVOKE
TCL (control de transacciones)	Confirmar o deshacer cambios en bloque	COMMIT, ROLLBACK, SAVEPOINT

La agrupación no es universal. Oracle, por ejemplo, clasifica GRANT (conceder) y REVOKE (revocar) dentro del DDL, y separa las sentencias de control de transacciones [14]. La sintaxis completa de cada orden es tema de la guía de SQL.

DDL: definir la estructura

El DDL, sigla en inglés del lenguaje de definición de datos, agrupa las órdenes que crean, alteran y eliminan objetos como tablas e índices [14].

• Ejemplo: CREATE TABLE municipio (...).
• Error típico: olvidar que en Oracle cada sentencia DDL confirma la transacción en curso antes y después de ejecutarse, así que no se puede deshacer con ROLLBACK [14].

DML: leer y cambiar los datos

El DML, el lenguaje de manipulación de datos, agrupa las órdenes que consultan y modifican los datos de objetos que ya existen [14].

• Ejemplo: INSERT INTO municipio VALUES ('68001', 'BUCARAMANGA', '68').
• Error típico: discutir si SELECT es DML como si hubiera una sola respuesta. Oracle lo cuenta como una forma limitada de DML [14]; otros textos, como la guía de SQL de este sitio, lo apartan en una quinta familia, el DQL (lenguaje de consulta de datos).

DCL: controlar quién puede hacer qué

El DCL, el lenguaje de control de datos, concede y retira permisos sobre los objetos de la base. En PostgreSQL, GRANT da privilegios sobre una tabla, una vista o un esquema, o la pertenencia a un rol [15].

• Ejemplo: en PostgreSQL, la última orden del código de abajo deja que el rol analista lea la tabla municipio, siempre que ese rol exista antes; en SQLite, esa misma orden falla.
• Error típico: buscar GRANT en SQLite. SQLite lee y escribe un archivo común, así que no implementa GRANT ni REVOKE; los únicos permisos son los del sistema operativo sobre ese archivo [16].

TCL: confirmar o deshacer en bloque

El TCL (control de transacciones) agrupa las órdenes que gestionan los cambios hechos con DML: confirmarlos con COMMIT, deshacerlos con ROLLBACK o marcar puntos intermedios con SAVEPOINT [14].

• Ejemplo: BEGIN (empezar), luego varios UPDATE y al final COMMIT.
• Error típico: creer que sin esa orden de inicio no hay transacción. En SQLite, toda orden que toca la base abre una transacción automática si no hay otra activa, y la confirma al terminar [17].

Transacción

Una transacción agrupa varios pasos en una sola operación de todo o nada: si algo falla a mitad de camino, ninguno de los pasos afecta la base [18].

• Ejemplo: una transferencia que resta de una cuenta y suma en otra.
• Error típico: ejecutar los dos pasos por separado. Si el sistema cae entre la resta y la suma, el dinero desaparece de un lado sin llegar al otro.

Ejemplo en SQLite: las cuatro familias con municipios de Colombia

El ejemplo usa códigos reales de la DIVIPOLA, la lista oficial de códigos de departamentos y municipios. La publica el DANE, la entidad de estadística de Colombia, con corte al 30 de diciembre de 2024 [19]. Lo probé en SQLite 3.53.1, versión publicada en mayo de 2026 [20].

-- En SQLite las claves foráneas vienen apagadas: se activan por conexión
PRAGMA foreign_keys = ON;

-- DDL: define la estructura (el esquema)
CREATE TABLE departamento (
  cod_dpto TEXT PRIMARY KEY,      -- texto, para no perder el cero inicial
  nombre   TEXT NOT NULL
);
CREATE TABLE municipio (
  cod_mpio TEXT PRIMARY KEY CHECK (length(cod_mpio) = 5),
  nombre   TEXT NOT NULL,
  cod_dpto TEXT NOT NULL REFERENCES departamento (cod_dpto)
);

-- DML: llena, corrige y consulta los datos (la instancia)
INSERT INTO departamento VALUES ('05', 'ANTIOQUIA'), ('68', 'SANTANDER');
INSERT INTO municipio VALUES
  ('05001', 'MEDELLÍN', '05'),
  ('68001', 'BUCARAMANGA', '68'),
  ('68307', 'GIRÓN', '68');
UPDATE municipio SET nombre = 'Girón' WHERE cod_mpio = '68307';
SELECT cod_mpio, nombre FROM municipio WHERE cod_dpto = '68' ORDER BY cod_mpio;
-- 68001|BUCARAMANGA
-- 68307|Girón

-- Integridad referencial: el departamento 99 no existe
INSERT INTO municipio VALUES ('99001', 'INVENTADO', '99');
-- Falla: FOREIGN KEY constraint failed

-- TCL: todo o nada
BEGIN;
DELETE FROM municipio WHERE cod_dpto = '68';
ROLLBACK;                         -- deshace el borrado
SELECT count(*) FROM municipio;
-- 3

-- DCL: no existe en SQLite
GRANT SELECT ON municipio TO analista;
-- Falla: near "GRANT": syntax error

Un detalle del ejemplo enseña tanto como el resto. Si el código de municipio se guarda como número, el cero de Antioquia se pierde.

CREATE TABLE prueba (codigo INTEGER);
INSERT INTO prueba VALUES ('05001');
SELECT codigo, typeof(codigo) FROM prueba;
-- 5001|integer

SQLite convierte a entero el texto que llega a una columna INTEGER cuando puede hacerlo sin pérdida aparente, como el ‘123’ de su propia documentación [7]. Por eso un código, aunque solo tenga dígitos, se declara como texto.

Arquitectura ANSI/SPARC de tres niveles e independencia de datos

La arquitectura de tres niveles describe una misma base de datos desde tres alturas: la de cada usuario, la de la organización completa y la del almacenamiento físico. La propuso en 1975 el grupo de estudio ANSI/X3/SPARC sobre sistemas gestores de bases de datos, de ahí el nombre, para separar los programas de los datos [3] [21]. Un informe del grupo sobre ese marco se publicó en 1978 [22].

Nivel	Qué describe	Quién lo usa	Ejemplo
Externo (vistas)	Lo que ve cada usuario o programa	Usuarios y aplicaciones	La lista de municipios que consulta una alcaldía
Conceptual	La estructura lógica completa: entidades, atributos, relaciones y restricciones	Quien diseña y administra la base	Las tablas municipio y departamento con sus claves
Interno	Cómo se guardan los datos en disco: archivos, índices, estructuras	El gestor y su administrador	El índice sobre cod_mpio

Las descripciones de cada nivel siguen los apuntes de las universidades de Cantabria y Granada [3] [13]. Codd había planteado la meta cinco años antes: «los futuros usuarios de grandes bancos de datos deben estar protegidos de tener que saber cómo están organizados los datos en la máquina» [1].

Nivel externo y vista

El nivel externo reúne los esquemas con la perspectiva de cada usuario o proceso, y permite ocultar datos sensibles [3]. En el modelo relacional, esos esquemas externos corresponden a las vistas [5].

• Ejemplo: una vista de pacientes que muestra la cita pero no el diagnóstico.
• Error típico: creer que toda vista se puede actualizar. En el modelo relacional no todas las vistas son actualizables [5].

Nivel conceptual

El nivel conceptual describe la estructura lógica de toda la base, sin detalles de almacenamiento, e integra todos los esquemas externos [3] [13].

• Ejemplo: el diagrama con todas las tablas, columnas, claves y reglas de un sistema de matrícula.
• Error típico: dejar las restricciones fuera. El esquema conceptual debe incluir las restricciones de integridad, no solo las tablas [13].

Nivel interno

El nivel interno describe la estructura física: árboles, índices y archivos. Cada gestor implementa el suyo, sin un estándar común [3].

• Ejemplo: el índice de tipo árbol B que PostgreSQL crea por su cuenta al declarar una clave primaria [10].
• Error típico: esperar que dos gestores guarden igual la misma tabla. El nivel interno es propio de cada producto.

Independencia física

La independencia física es la capacidad de cambiar el nivel interno sin tocar el nivel conceptual ni el externo [3].

• Ejemplo: añadir un índice o ampliar el espacio de almacenamiento sin reescribir ninguna consulta [3].
• Error típico: dar por hecho que todo gestor relacional separa con limpieza los tres niveles. En la práctica, muchos no distinguen con claridad el esquema conceptual del interno [5].

Independencia lógica

La independencia lógica es la capacidad de cambiar el nivel conceptual sin tener que cambiar las vistas ni los programas [3].

• Ejemplo: añadir un atributo nuevo a una tabla sin que fallen los informes que ya existían [3].
• Error típico: confundirla con la física. La física protege de cambios en cómo se guarda; la lógica, de cambios en qué se guarda.

Redundancia y anomalías: lo que sale mal con un mal diseño

La redundancia es la repetición de datos guardados, y puede causar anomalías, entre ellas al insertar, borrar o actualizar [23]. Microsoft lo resume como el primer principio del buen diseño: la información duplicada desperdicia espacio y aumenta la probabilidad de errores e incoherencias [4].

Para verlo, imagine una sola tabla que repite el nombre del departamento en cada fila de municipio.

cod_mpio	municipio	cod_dpto	departamento
68001	BUCARAMANGA	68	SANTANDER
68307	GIRÓN	68	SANTANDER
05001	MEDELLÍN	05	ANTIOQUIA

Redundancia

Redundancia es guardar el mismo dato en más de un lugar [23].

• Ejemplo: «SANTANDER» escrito en cada fila de un municipio santandereano.
• Error típico: creer que toda repetición es un defecto. La desnormalización repite datos a propósito para ganar velocidad cuando los datos no se van a actualizar [23].

Anomalía de inserción

La anomalía de inserción aparece cuando no se puede guardar un dato sin guardar a la vez otro que no tiene relación con él [23].

• Ejemplo: en la tabla de arriba no se puede registrar un departamento nuevo hasta tener al menos uno de sus municipios.
• Error típico: «resolverla» con filas a medio llenar, que luego aparecen como municipios vacíos en los conteos.

Anomalía de actualización

La anomalía de actualización ocurre porque, si se cambia una copia de un dato repetido, hay que cambiar todas para no dejar contradicciones [23].

• Ejemplo: corregir el nombre de un departamento en una fila y olvidarlo en las demás.
• Error típico: corregir solo la fila que se ve en pantalla.

Anomalía de borrado

La anomalía de borrado ocurre cuando no se puede eliminar un dato sin perder otro que no tenía relación con él [23].

• Ejemplo: si se borra Medellín, la única fila de Antioquia en la tabla, desaparece también el departamento.
• Error típico: descubrirla solo cuando un informe pierde una categoría completa.

Normalización

La normalización lleva las tablas a formas normales, sobre todo descomponiéndolas en varias, para reducir las anomalías [23]. La palabra la acuñó Codd en su artículo de 1970, y de ese texto sale la primera forma normal [1] [23].

• Ejemplo: separar departamento y municipio en dos tablas unidas por cod_dpto, como en el código de arriba.
• Error típico: buscar la forma normal perfecta. No existe una forma normal ideal para todas las tablas [23]. El procedimiento paso a paso es parte del diseño de bases de datos, una unidad propia del temario.

Glosario de bases de datos de la A a la Z (40 términos)

Cada término enlaza a su entrada con ejemplo y error típico. Los que no tienen entrada propia llevan aquí su definición completa.

Término	Qué es, en una línea
Anomalía de actualización	Contradicción que deja cambiar solo una de las copias de un dato
Anomalía de borrado	Pérdida de un dato ajeno al eliminar otro
Anomalía de inserción	Imposibilidad de guardar un dato sin otro que no viene al caso
Arquitectura ANSI/SPARC	Descripción de la base en tres niveles: externo, conceptual e interno
Base de datos	Colección organizada de datos de un problema, compartida por usuarios o programas [3]. Ejemplo: el inventario de una tienda. Error típico: llamar base de datos al programa que la gestiona
Campo	Columna; el mismo dato en todos los registros
Cardinalidad de una relación	Cuántas filas de una tabla se asocian con otra: 1:1, 1:N o N:M
Cardinalidad de una tabla	Número de filas o tuplas
Clave alternativa	Candidata que no se eligió como primaria
Clave candidata	Conjunto mínimo de columnas que identifica cada fila
Clave compuesta	Clave formada por dos o más columnas
Clave foránea	Columna que apunta a la clave de otra tabla
Clave primaria	Candidata elegida como identificador oficial de la tabla
DCL	Órdenes que dan y quitan permisos
DDL	Órdenes que crean, alteran y borran la estructura
DML	Órdenes que leen y modifican los datos
Dominio	Conjunto de valores válidos de un atributo
Esquema	Estructura de la base: tablas, columnas y tipos
Grado	Número de columnas o atributos
Independencia física	Cambiar el almacenamiento sin tocar programas ni vistas
Independencia lógica	Cambiar la estructura lógica sin tocar programas ni vistas
Índice	Estructura adicional que acelera las búsquedas en una tabla, a cambio de recargar las actualizaciones [3]. Ejemplo: un índice sobre el título en una tabla de libros. Error típico: crear índices en todas las columnas
Instancia	Los datos guardados en un momento dado
Integridad de entidad	Ninguna parte de la clave primaria puede ser nula
Integridad referencial	Toda clave foránea apunta a algo que existe
Modelo de datos	Conceptos y reglas para describir datos y restricciones
Nivel conceptual	Estructura lógica completa de la base
Nivel externo	Lo que ve cada usuario: sus vistas
Nivel interno	Cómo se guardan los datos en el disco
Normalización	Dividir tablas para reducir la redundancia
Redundancia	El mismo dato guardado en varios lugares
Registro	Fila; los datos de una cosa concreta
Relación	Término matemático para la tabla del modelo relacional
Restricción	Condición que los datos deben cumplir siempre
SGBD (sistema gestor de bases de datos)	Programa que mantiene bases de datos y responde consultas sobre ellas [3]. Ejemplo: PostgreSQL o SQLite. Error típico: confundir la base de datos con el gestor, que es el software que la administra [9]
Tabla	Filas y columnas sobre un mismo tema
TCL	Órdenes que confirman o deshacen transacciones
Transacción	Grupo de pasos que se ejecuta entero o no se ejecuta
Valor nulo	Marca de dato desconocido, inaplicable o ausente
Vista	Tabla virtual definida por una consulta; en el modelo relacional cumple el papel del esquema externo [5]. Ejemplo: una lista de estudiantes sin sus notas. Error típico: suponer que toda vista admite cambios (ver nivel externo)

Temario de un curso de fundamentos de bases de datos

Un curso de fundamentos de bases de datos suele ir de los conceptos al lenguaje y de ahí a la administración. El de la Universidad de Cantabria, de 6 créditos, se organiza en seis temas: introducción, modelo relacional, lenguaje SQL, administración, diseño y desarrollo de aplicaciones, y otros modelos de datos [2]. El temario de abajo toma ese recorrido y añade tres unidades propias: arquitectura, diseño de la base y práctica.

Unidad	Qué se estudia	Términos de este glosario	Dónde seguir en este sitio
1. Introducción	Dato, base de datos y gestor; de los archivos a la base de datos	base de datos, SGBD, modelo de datos	Qué es una base de datos e historia de las bases de datos
2. Modelo relacional	Tablas, claves, restricciones y valores nulos	tabla, registro, campo, dominio, claves, integridad	Bases de datos relacionales
3. Arquitectura	Los tres niveles y la independencia de datos	niveles externo, conceptual e interno; independencia	Esta página
4. Diseño	Del problema a las tablas: entidades, cardinalidad y normalización	cardinalidad, redundancia, anomalías, normalización	Ejemplos resueltos en bases de datos relacionales
5. Lenguaje SQL	Definir, manipular y consultar	DDL, DML, índice, vista	Qué es SQL
6. Transacciones y administración	Todo o nada, permisos y seguridad	TCL, transacción, DCL	Glosario de ciencia de datos (transacciones y ACID)
7. Otros modelos de datos	Documentos, grafos, clave-valor y vectores	modelo de datos	Qué es una base de datos (tipos)
8. Práctica	Consultar datos reales	todos	Bases de datos para practicar y ejemplos de bases de datos

¿Por qué empezar un curso por el vocabulario?

La DIVIPOLA que publica el DANE trae siete columnas, entre ellas cod_dpto y cod_mpio [19]. Quien conoce este glosario lee ahí una clave y su referencia aunque la ficha no use esas palabras. Quien no lo conoce ve dos columnas de números y, con suerte, no les borra el cero.

Creo que ese es el argumento más fuerte para empezar por las definiciones y no por el programa de moda. Los gestores cambian de versión cada pocos meses, como muestra el historial de SQLite [20]; la distinción entre esquema e instancia que pedía Codd lleva más de medio siglo sin cambiar. Una persona que la domina puede leer los datos abiertos de su municipio y preguntar por qué no cuadran. Esa pregunta, más que cualquier herramienta, es la que abre la puerta a trabajar con datos.

Preguntas frecuentes

¿Qué se ve en un curso de fundamentos de bases de datos? Se ve el vocabulario y la lógica que vienen antes de cualquier programa. Se aprende cómo se organiza la información en tablas, cómo se identifica cada fila con una clave y qué reglas protegen los datos. Luego vienen los tres niveles en que se describe una base y las familias de sentencias de SQL. Después llegan el diseño, la escritura de consultas, las transacciones y la administración. El temario de esta página resume ese recorrido en ocho unidades.

¿Cuál es la diferencia entre tabla, registro y campo? La tabla es el contenedor de un tema, por ejemplo los municipios. El registro es una fila de esa tabla con los datos de un solo municipio. El campo es una columna, el mismo tipo de dato repetido en todos los registros, como el nombre. En el lenguaje del modelo relacional, esas tres palabras se convierten en relación, tupla y atributo.

¿Hay un PDF de fundamentos de bases de datos para estudiar? Esta página no tiene versión en PDF. El curso abierto de la Universidad de Cantabria publica sus temas en PDF con una licencia abierta (Creative Commons BY-NC-SA 3.0) [3]. Sirve como lectura complementaria de las primeras unidades.

¿Qué diferencia hay entre clave primaria y clave foránea? La primaria identifica cada fila de su propia tabla y no admite repetidos ni vacíos. La foránea vive en otra tabla y guarda valores que deben existir en la tabla a la que apunta. Una tabla tiene como máximo una primaria, pero puede tener varias foráneas, una por cada tabla con la que se conecta.

¿Una base de datos y un SGBD son lo mismo? No. La base de datos son los datos organizados; el sistema gestor de bases de datos, o SGBD, es el programa que los guarda, los protege y responde las consultas. PostgreSQL, MySQL y SQLite son gestores, y cada uno puede administrar muchas bases distintas.

Referencias

1. Codd, Edgar F. A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, vol. 13, n.º 6, junio de 1970, pp. 377-387 (DOI 10.1145/362384.362685) — laboratorio de IBM en San José; la confusión de terminología entre tipo e instancia, con «registro» como ejemplo; los usuarios deben estar protegidos de conocer la organización interna de los datos; relaciones de grado n; varias claves primarias no redundantes, de las que se elige una; clave foránea y el ejemplo de la relación supply; el término normalización. Texto leído en la copia que aloja la Universidad de Pensilvania. Universidad de Pensilvania: copia del artículo de Codd (1970) — Consultada: 2026-10-19.
2. Universidad de Cantabria, OpenCourseWare. Bases de Datos (2011), Marta Elena Zorrilla Pantaleón y Rafael Duque Medina — asignatura G657 del Grado en Ingeniería Informática, 6 créditos ECTS; programa en seis temas: introducción, modelo relacional, lenguaje SQL, administración, diseño y desarrollo de aplicaciones y otros modelos de datos. Universidad de Cantabria: curso Bases de Datos (OCW) — Consultada: 2026-10-19.
3. Zorrilla Pantaleón, Marta Elena y Duque Medina, Rafael. Tema 01. Introducción a las BD relacionales, curso Bases de Datos, OCW Universidad de Cantabria, 2011, licencia Creative Commons BY-NC-SA 3.0 — definiciones de base de datos y de sistema gestor; datos, relaciones y restricciones; arquitectura ANSI-SPARC (1975) en tres niveles; independencia lógica y física con ejemplos; restricciones escritas en el código de los programas; índices; problemas de un mal diseño. Universidad de Cantabria: Tema 1, introducción a las bases de datos (PDF) — Consultada: 2026-10-19.
4. Microsoft. Conceptos básicos del diseño de una base de datos (soporte de Access) — tablas como filas y columnas; registro y campo; separar nombre y apellidos en campos distintos; la información duplicada desperdicia espacio y aumenta errores e incoherencias; relaciones uno a varios, varios a varios y uno a uno; clave externa; tabla de detalles de pedido. Microsoft Soporte: conceptos básicos del diseño de una base de datos — Consultada: 2026-10-19.
5. Zorrilla Pantaleón, Marta Elena y Duque Medina, Rafael. Tema 02. El modelo relacional, curso Bases de Datos, OCW Universidad de Cantabria, 2011 — relación, dominio, atributo y tupla; esquema e instancia; cardinalidad (número de tuplas) y grado (número de atributos); una relación no es una tabla; claves candidata, primaria, alternativa y ajena; integridad de entidad y referencial; valores nulos; restricciones; vistas y arquitectura ANSI-SPARC. Universidad de Cantabria: Tema 2, el modelo relacional (PDF) — Consultada: 2026-10-19.
6. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 5.1. Table Basics — número fijo de columnas y variable de filas; SQL no garantiza el orden de las filas; pueden existir filas idénticas. PostgreSQL 18: Table Basics — Consultada: 2026-10-19.
7. SQLite. STRICT Tables — tipado flexible: una columna INTEGER convierte ‘123’ en el entero 123 y guarda ‘xyz’ como texto; las tablas STRICT existen desde la versión 3.37.0 (2021-11-27). SQLite: STRICT Tables — Consultada: 2026-10-19.
8. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 2.2. Concepts — «relación» es, en esencia, el término matemático para «tabla». PostgreSQL 18: Concepts — Consultada: 2026-10-19.
9. Pavlo, Andrew. Lecture #01: Relational Model & Algebra, curso 15-445/645 Database Systems, Carnegie Mellon University, otoño de 2024 — se suele confundir la base de datos con el sistema gestor; modelos de datos (relacional, clave-valor, grafos, documentos); definición de esquema y su ausencia como «bits sin significado»; definición de restricción. Carnegie Mellon University: notas de la clase 1 de 15-445 (PDF) — Consultada: 2026-10-19.
10. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 5.5. Constraints — la clave primaria exige valores únicos y no nulos, puede abarcar varias columnas, crea un índice árbol B y hay como máximo una por tabla; la teoría relacional pide clave primaria, pero PostgreSQL no lo impone; la clave foránea mantiene la integridad referencial y debe apuntar a una clave primaria o a columnas únicas. PostgreSQL 18: Constraints — Consultada: 2026-10-19.
11. SQLite. SQLite Foreign Key Support — las restricciones de clave foránea vienen desactivadas por compatibilidad y se activan en cada conexión con PRAGMA foreign_keys. SQLite: Foreign Key Support — Consultada: 2026-10-19.
12. ISO/IEC JTC 1/SC 32. ISO/IEC 9075-1:2023 Information technology — Database languages SQL — Part 1: Framework (SQL/Framework), edición 6, junio de 2023 — describe el marco conceptual de la serie y define los términos y la notación que usan las demás partes. Ficha leída en la copia de web.archive.org del 2026-01-09, porque iso.org rechaza la descarga automática. ISO: ficha de la norma ISO/IEC 9075-1:2023 — Consultada: 2026-10-19.
13. Universidad de Granada, asignatura Bases de Datos (Ingeniería Técnica de Gestión). Tema 2. Arquitectura de un sistema de gestión de bases de datos — arquitectura ANSI/SPARC (1975) en tres niveles; recomendación de lenguajes DDL, DML y DCL para cada nivel; esquemas externo, conceptual (con restricciones de integridad) e interno; correspondencias entre niveles. Universidad de Granada: tema 2 de Bases de Datos (PDF) — Consultada: 2026-10-19.
14. Oracle. SQL Language Reference, Types of SQL Statements (documentación de Oracle AI Database 26ai) — tipos de sentencias; el DDL incluye crear, alterar y borrar objetos y conceder y revocar privilegios; confirmación implícita antes y después de cada DDL; el DML incluye SELECT como forma limitada; COMMIT, ROLLBACK y SAVEPOINT como control de transacciones. Oracle: Types of SQL Statements — Consultada: 2026-10-19.
15. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, GRANT — concede privilegios sobre objetos como tablas, vistas o esquemas, o la pertenencia a un rol. PostgreSQL 18: GRANT — Consultada: 2026-10-19.
16. SQLite. SQL Features That SQLite Does Not Implement — GRANT y REVOKE no están implementados; solo aplican los permisos del sistema operativo sobre el archivo. SQLite: funciones de SQL que no implementa — Consultada: 2026-10-19.
17. SQLite. Transaction — toda orden que accede a la base inicia una transacción automática si no hay otra activa y la confirma al terminar. SQLite: Transaction — Consultada: 2026-10-19.
18. PostgreSQL Global Development Group. PostgreSQL 18 Documentation, 3.4. Transactions — una transacción agrupa varios pasos en una operación de todo o nada. PostgreSQL 18: Transactions — Consultada: 2026-10-19.
19. Departamento Administrativo Nacional de Estadística (DANE). DIVIPOLA – Códigos municipios, conjunto de datos en datos.gov.co, actualización con corte al 30 de diciembre de 2024 — columnas cod_dpto, dpto, cod_mpio, nom_mpio, tipo_municipio, longitud y latitud; códigos 05001 (Medellín), 68001 (Bucaramanga) y 68307 (Girón). datos.gov.co: DIVIPOLA, códigos de municipios del DANE — Consultada: 2026-10-19.
20. SQLite. History Of SQLite Releases — la versión 3.53.1 se publicó el 2026-05-05; la más reciente a la fecha de consulta es la 3.54.1 (2026-10-16). SQLite: historial de versiones — Consultada: 2026-10-19.
21. ACM SIGMOD. FDT, Bulletin of ACM SIGMOD, vol. 7, n.º 3-4, septiembre de 1975, nota editorial — menciona el número anterior del boletín, dedicado al «ANSI/X3/SPARC, Study Group on Data Base Management Systems, Interim Report, 75-02-08». SIGMOD Record: FDT de septiembre de 1975 (PDF) — Consultada: 2026-10-19.
22. Tsichritzis, Dennis y Klug, Anthony. The ANSI/X3/SPARC DBMS framework report of the study group on database management systems, Information Systems, vol. 3, n.º 3, 1978, pp. 173-191 — informe del grupo de estudio sobre el marco ANSI/X3/SPARC. Information Systems: DOI 10.1016/0306-4379(78)90001-7 — Consultada: 2026-10-19.
23. Bhattacharyya, Malay. Database Management Systems, Class VI (redundancia y normalización), Indian Statistical Institute, primavera de 2026 — la redundancia puede causar anomalías de inserción, borrado y actualización, entre otros problemas; se corrigen descomponiendo la base; la desnormalización mejora el rendimiento cuando los datos no se actualizan; no hay forma normal ideal; 1NF atribuida a Codd (1970). Indian Statistical Institute: clase VI de Database Management Systems (PDF) — Consultada: 2026-10-19.

Cómo investigamos esta página

• Pregunta que responde: Cuáles son los conceptos básicos de un curso de bases de datos y cómo se definen, con ejemplo y error típico.
• Fuentes: identificadas 38 → incluidas 23
• Criterios de inclusión: artículo original de Codd, documentación oficial de PostgreSQL, SQLite, Oracle y Microsoft, norma ISO de SQL, cursos universitarios abiertos y datos del DANE; nada de enciclopedias ni blogs de cursos.
• Fecha de corte de los datos: 2026-10-19