El modelo relacional

El nombre de un cliente, la fecha de un pedido y un precio son datos: hechos registrados. Una base de datos es una colección organizada de datos relacionados. Un sistema de gestión de bases de datos, o SGBD, es el software que almacena y gestiona esa colección. PostgreSQL es un SGBD; la base de datos store de una tienda es una de las colecciones que gestiona.

Almacena cada dato donde corresponde

Supón que una hoja de cálculo repite el teléfono de Maria Garcia en sus 14 ventas. Cambiar el teléfono requiere 14 modificaciones. Una celda olvidada deja registros contradictorios. En una base de datos relacional, customers contiene los datos de Maria una sola vez, con customer_id 1. Cada venta registra ese identificador. Actualizar su teléfono en una fila de cliente permite obtener un único número actualizado en las búsquedas posteriores.

Una base de datos relacional organiza los datos en tablas. «Relacional» procede de relación, el nombre matemático de una tabla. E. F. Codd presentó el modelo en 1970. Su separación central resulta útil: los usuarios describen los datos que quieren mediante tablas y valores; el SGBD se encarga de cómo encontrarlos en el disco.

Reglas y acceso compartido

Una tabla tiene columnas con nombre, tipos de datos y restricciones. Una restricción es una regla que comprueba el SGBD, como «un pedido debe hacer referencia a un cliente existente». Estas comprobaciones protegen los datos compartidos cuando varias aplicaciones utilizan la misma base de datos. La aplicación de los tipos varía: PostgreSQL rechaza texto como 'twelve' en una columna numérica de precios, mientras que las tablas ordinarias de SQLite tienen tipos flexibles.

Un SGBD también gestiona usuarios simultáneos, permisos, copias de seguridad y recuperación. Dos empleados pueden trabajar con datos compartidos sin intercambiar copias independientes de una hoja de cálculo. Los permisos pueden permitir que un usuario de informes lea las ventas y limitar quién puede modificarlas. Un proceso de copia de seguridad y recuperación ayuda a restaurar los datos tras un fallo.

Mantén unido un grupo de cambios

Una transacción trata varios cambios como una unidad: se guardan todos o no se guarda ninguno. Transferir 200 u.m. entre cuentas requiere restarlas de la cuenta corriente y sumarlas a la de ahorro. Si un fallo interrumpe la transferencia antes de completarse, el SGBD puede deshacer la transacción incompleta. Guardar solo la resta dejaría un saldo incorrecto.

Una hoja de cálculo sigue siendo útil para cálculos pequeños y diseños flexibles. Una base de datos proporciona una estructura definida para registros compartidos y reglas. Una hoja de Excel tiene un límite fijo de 1 048 576 filas; las bases de datos suelen gestionar colecciones mucho mayores, sujetas a los límites de almacenamiento, hardware y producto.

Datos diferentes y trabajos diferentes

Los datos estructurados encajan en columnas con nombre compartidas por todas las filas. Los datos semiestructurados, como los documentos JSON, pueden tener campos diferentes en distintos registros. Los datos no estructurados, como el audio o el correo electrónico de formato libre, carecen de esa estructura tabular fija. Las organizaciones suelen combinar bases de datos relacionales con almacenes de documentos, de clave-valor o de archivos.

La carga de trabajo también importa. Un sistema transaccional, también llamado OLTP, registra sucesos cotidianos mediante muchas lecturas y escrituras pequeñas: un pedido, un pago, un cambio de dirección. Un sistema analítico, u OLAP, lee muchos registros almacenados para responder preguntas como «¿Cómo variaron las ventas mensuales por región?». Ambos pueden utilizar tablas y claves relacionales.

SQL, cuyas siglas corresponden a lenguaje de consulta estructurada, es un lenguaje. PostgreSQL, MySQL, SQLite, Microsoft SQL Server y Oracle Database son productos que lo utilizan. SQL Server es un SGBD, no otro nombre del propio SQL.

Cómo accede una aplicación a los datos

En un sistema cliente-servidor, un programa servidor gestiona la base de datos. Un cliente, como un sitio web, una herramienta de informes o un editor de consultas, envía solicitudes a ese servidor. PostgreSQL, MySQL, SQL Server y Oracle suelen funcionar así. Herramientas como psql, pgAdmin, DBeaver y SQL Server Management Studio permiten inspeccionar bases de datos y enviar solicitudes.

Un motor integrado se ejecuta dentro de una aplicación. SQLite utiliza una biblioteca y un archivo ordinario de base de datos, como store.db, sin un servidor de bases de datos independiente. Es habitual en teléfonos, navegadores y aplicaciones de escritorio. Un servicio gestionado en la nube, como Azure SQL Database, Amazon RDS o Google Cloud SQL, permite que un proveedor se encargue de los servidores de bases de datos. «Gestionado» describe quién opera el servicio; no sustituye las tablas y las claves por un modelo diferente.

Una instalación de un SGBD puede gestionar varias bases de datos, como store y payroll. Una conexión selecciona la base de datos que se utilizará, según los permisos.

Indica qué resultado quieres

SQL es declarativo: describe el resultado requerido y el SGBD elige cómo obtenerlo. Lee esta sentencia:

SELECT first_name, city
FROM customers
WHERE state = 'TX';

Solicita los nombres y las ciudades de las filas de clientes cuyo estado es TX. No indica qué página del disco leer primero. Las palabras clave en mayúsculas facilitan la lectura de la sentencia; select y SELECT significan lo mismo. Un punto y coma suele finalizar una sentencia.

Reconoce la función de la sentencia

Algunos libros sitúan SELECT en un grupo independiente de lenguaje de consulta de datos. La distinción útil es la función real de la sentencia: añadir una columna cambia la estructura; añadir un cliente cambia los datos.

SQL se convirtió en un estándar ANSI en 1986 y está estandarizado internacionalmente como ISO/IEC 9075. Los productos añaden sus propios dialectos. Un límite de diez filas se expresa como LIMIT 10 en SQLite, PostgreSQL y MySQL, TOP 10 en SQL Server o FETCH FIRST 10 ROWS ONLY en SQL estándar y Oracle.

Lee texto y otros objetos de base de datos

Los literales de texto utilizan comillas simples: 'TX'. SQL estándar utiliza comillas dobles para los identificadores, como los nombres de columnas. Un apóstrofo dentro del texto se duplica: 'O''Brien' representa O'Brien.

Una vista es una consulta guardada que se utiliza como una tabla; una vista ordinaria no tiene filas propias almacenadas. Un índice es una estructura de búsqueda que puede ayudar a encontrar filas rápidamente. La mayoría de los sistemas crea índices de claves primarias automáticamente. Los procedimientos almacenados y las funciones son código guardado que puede ejecutarse por su nombre.

Una tabla almacena datos sobre un tipo de cosa. Cada fila de customers describe un cliente; cada columna contiene una propiedad. Su intersección contiene un valor.

Lee un registro de lado a lado

Estas son algunas columnas de clientes:

Busca customer_id 4 y lee city: la ciudad de Wei es Seattle. Para saber quién vive en Denver, lee el nombre en la fila de Denver: James Wilson. Una fila contigua describe a otro cliente.

La tabla completa tiene ocho columnas: customer_id, first_name, last_name, email, phone, city, state y zip_code. El teléfono de James es NULL: falta el valor, pero su fila sigue teniendo la columna de teléfono.

Relaciona el vocabulario

Una tupla es una fila completa, no una celda. Un atributo nombra una propiedad compartida por todas las filas. «Registro 4» podría referirse a un identificador o a una posición en pantalla; comprueba a cuál, porque las posiciones pueden cambiar.

Cuenta las dimensiones

El grado cuenta las columnas; la cardinalidad de una tabla cuenta las filas. La tabla completa tiene grado 8 y cardinalidad 4. La representación anterior muestra seis columnas sin cambiar el grado de la tabla.

Añadir un cliente aumenta la cardinalidad a 5; el grado sigue siendo 8. Añadir birth_date aumenta el grado a 9 y da a cada fila un lugar para ese valor, incluso cuando falta. Un cliente nuevo añade una fila, no una columna.

La cardinalidad de una relación, como uno a muchos, describe los vínculos permitidos, no el número de filas de una tabla.

Lee nombres cualificados

Los nombres de columna son únicos dentro de una tabla. orders.customer_id y customers.customer_id distinguen columnas con el mismo nombre en tablas diferentes: el punto separa los nombres de la tabla y de la columna.

snake_case utiliza palabras en minúsculas separadas por guiones bajos, como en zip_code. Los nombres con espacios necesitan comillas en SQL. Los nombres de tabla pueden funcionar en singular o en plural; utiliza una convención coherente.

Una tabla relacional tiene una estructura lógica que va más allá de su aspecto rectangular. En el modelo formal es un conjunto de filas. Los conjuntos no contienen elementos duplicados ni tienen orden. Las columnas se identifican por su nombre, por lo que mover una columna en una representación no cambia el dato que representa.

La identidad no depende de la posición

Un SGBD puede devolver las filas en un orden diferente tras actualizaciones, eliminaciones o un cambio en la forma de leer el almacenamiento. «La tercera fila» no es una forma duradera de identificar a un cliente. customer_id 3 sigue identificando a Aisha aunque su fila aparezca primero. Una consulta que necesita un orden concreto lo solicita con ORDER BY.

Las tablas SQL difieren de las relaciones formales: sin una clave primaria u otra restricción de unicidad adecuada, pueden contener filas idénticas. Dos copias de ('Coffee mug', 12.50) no ofrecen ningún valor que las distinga en esas columnas. Una clave primaria da a cada fila un identificador único e impide las filas completamente duplicadas.

Una columna, un dominio

Un dominio es el conjunto de valores permitidos en una columna. Una cantidad tiene un tipo entero y también puede necesitar una regla que exija que sea positiva. Un código estatal es texto, pero no cualquier texto es un código estatal válido. Los tipos de datos y las restricciones describen al SGBD los valores permitidos.

Todas las filas comparten las mismas columnas. Un pedido no puede adquirir una columna adicional de nota para regalo solo para él. La tabla puede tener una columna gift_note para todos los pedidos, con NULL donde no se haya registrado ninguna nota. Los datos opcionales también tienen un lugar definido.

Mantén separados los valores individuales

Un valor atómico es un único valor para la finalidad de la columna. Una celda de teléfono que contiene «512-555-0147, 512-555-0199» contiene una lista de dos números. Encontrar, comprobar o eliminar solo uno resulta complicado. Una tabla customer_phones puede dar a cada teléfono su propia fila, con customer_id para indicar a quién pertenece.

Atómico no significa que todos los valores de texto deban dividirse en sus partes más pequeñas. El nombre de una ciudad puede contener varias palabras y seguir siendo un único valor de ciudad. La cuestión es si la celda almacena un dato del tipo que representa la columna o una colección que debería gestionarse por separado.

Lee con criterio una exportación de una hoja de cálculo

Una hoja de ventas puede incluir un encabezado repetido a mitad de la hoja, una fila al final llamada «TOTAL» y un precio escrito como «12,50 (oferta)». Son opciones de presentación útiles para una persona, pero mezclan distintos tipos de contenido en las mismas columnas.

Para leerla como una tabla relacional:

1. Trata los nombres de las columnas como encabezado, no como registros de ventas.
2. Mantén cada fila de datos dedicada a una venta; calcula el total a partir de esas filas.
3. Almacena el precio numérico separado de una nota de oferta.
4. Da a cada venta una clave para poder identificar su fila.

Una fila de total mezclada con las ventas podría contarse como otra venta o sumarse de nuevo al total. Una nota mezclada con un precio numérico impide realizar operaciones numéricas ordinarias.

Tablas lógicas y almacenamiento físico

Una tabla es la representación lógica del usuario. El SGBD puede almacenar sus datos en archivos, páginas e índices organizados para un acceso eficiente. La independencia de los datos significa que los cambios en esa organización física no tienen por qué cambiar los nombres de las tablas, los significados de las columnas ni las solicitudes que utilizan las aplicaciones.

Un tipo de datos indica al SGBD qué clase de valor contiene una columna y cómo trabajar con él. La suma numérica, la comparación de texto y la ordenación de fechas son operaciones diferentes. Un nombre de tipo conocido también puede comportarse de forma distinta entre productos de bases de datos.

Números: enteros, exactos y aproximados

En PostgreSQL, MySQL y SQL Server, INTEGER abarca de −2 147 483 648 a 2 147 483 647. BIGINT alcanza 9 223 372 036 854 775 807; el almacenamiento de enteros de SQLite también puede alcanzar ese intervalo.

Para los decimales, la precisión es el número total de dígitos y la escala es el número de dígitos después de la coma decimal. DECIMAL(8, 2) deja seis dígitos antes de la coma: su máximo es 999 999,99. El precio 12,50 cabe; 1 234 567,00 no. PostgreSQL, MySQL, SQL Server y Oracle ofrecen almacenamiento decimal exacto. SQLite acepta esta declaración, pero no exige su precisión ni escala, y puede almacenar fracciones como números binarios de coma flotante.

La coma flotante aproxima muchas fracciones decimales. En doble precisión, sumar 0,1 y 0,2 da 0,30000000000000004. SQLite trata estos literales decimales como números de coma flotante. PostgreSQL trata los literales decimales sin tipo explícito como números exactos, por lo que el mismo cálculo escrito allí puede ser exacto; los valores explícitos de doble precisión muestran la aproximación.

Texto, fechas e indicadores

CHAR(n) es texto de longitud fija; PostgreSQL y SQL Server rellenan los valores más cortos con espacios. VARCHAR(n) permite longitudes variables hasta un límite. SQLite ignora ambos ajustes de longitud y no añade relleno. TEXT contiene texto largo en SQLite, PostgreSQL y MySQL. SQL Server utiliza VARCHAR(MAX) o NVARCHAR(MAX) para este fin; su antiguo tipo TEXT está obsoleto.

Un DATE contiene una fecha del calendario, un TIME una hora del día y el TIMESTAMP de SQL estándar una fecha y hora. Escribe las fechas en formato año-mes-día, como '2026-03-02', para evitar confundir el 2 de marzo con el 3 de febrero. Las fechas con tipo de fecha tienen un formato interno de almacenamiento; la aplicación elige cómo mostrarlas. SQLite no tiene un tipo específico de fecha y suele almacenarlas como texto ISO. SQL Server utiliza DATETIME2 para fecha y hora: su TIMESTAMP significa ROWVERSION, un contador binario de versiones.

Un BOOLEAN representa TRUE o FALSE, o NULL cuando falta el valor. PostgreSQL tiene un tipo booleano; SQL Server utiliza BIT, MySQL trata BOOLEAN como un entero pequeño y SQLite almacena los indicadores como 1 y 0. Los tipos binarios como BLOB o BYTEA de PostgreSQL almacenan bytes, incluidas imágenes pequeñas. Los archivos más grandes suelen almacenarse por separado, con una ruta o URL en una tabla.

La afinidad de tipo de SQLite

En las tablas ordinarias de SQLite, un tipo declarado es una preferencia llamada afinidad de tipo. Una columna INTEGER convierte '42' en el número 42, pero puede conservar 'abc' como texto. Una tabla STRICT de SQLite rechaza el texto que no puede convertirse en un entero válido.

Empieza por el significado de un valor y cómo se utilizará. Un código postal ZIP contiene dígitos, pero nadie suma códigos ZIP para obtener un total con sentido. Una cantidad también contiene dígitos, y sumar cantidades resulta útil. La apariencia por sí sola orienta poco al elegir un tipo.

Haz cinco preguntas

1. ¿Cuáles son los valores habituales y qué valores extremos deben caber?
2. ¿Se utilizarán los valores en operaciones aritméticas?
3. ¿Deben ser exactos o se acepta una aproximación?
4. ¿Cómo deben ordenarse y compararse?
5. ¿Qué tamaño admite valores futuros realistas?

Dinero y mediciones

El dinero necesita valores exactos. En PostgreSQL, MySQL y SQL Server, un precio puede utilizar DECIMAL(8, 2). Tres artículos a 12,50 u.m. cuestan exactamente 37,50 u.m. El almacenamiento binario de coma flotante puede dejar errores mínimos tras sumas repetidas, lo que resta fiabilidad a las comparaciones exactas. En SQLite, declarar DECIMAL no proporciona almacenamiento decimal exacto; utiliza céntimos expresados como enteros para los importes exactos, de modo que 12,50 u.m. se almacene como 1250.

Una medición como el peso puede utilizar REAL cuando se aceptan pequeñas diferencias por redondeo. Elige la unidad como parte del significado de la columna: weight_lb indica las libras en su nombre. Un tipo numérico por sí solo no registra esa unidad.

La moneda también debe quedar definida. Si una tabla mezcla monedas, añade currency_code, como USD, EUR o JPY. Los decimales varían según la moneda, y los importes en distintas monedas deben convertirse antes de sumarlos.

Los códigos y los nombres son texto

Utiliza texto para códigos ZIP, teléfonos, números de cuenta y códigos de inventario. El código ZIP de Boston '02108' pierde su cero inicial al convertirse en entero. VARCHAR(10) también puede contener ZIP+4, como '02108-1234'. Los teléfonos pueden contener un signo más, espacios y guiones. Estos caracteres forman parte de la representación de un identificador, no son signos aritméticos.

Deja espacio para nombres y direcciones reales. «Christopher Montgomery» tiene 22 caracteres, por lo que VARCHAR(10) es demasiado corto. PostgreSQL y SQL Server lo rechazan; MySQL lo rechaza en modo estricto y puede truncarlo en otros modos. SQLite lo almacena porque ignora las longitudes de texto declaradas. Un campo de longitud variable con un límite amplio evita rechazar nombres habituales sin reservar su longitud máxima para cada fila.

La ordenación revela una elección incorrecta

La ordenación de texto compara caracteres. Los números almacenados como texto pueden aparecer en el orden '1', '10', '2', '25', '3'. Una columna numérica ordena esos valores numéricamente. Elegir texto para todos los campos traslada las comprobaciones y conversiones a los cálculos posteriores.

Las fechas tienen un problema parecido. El texto de fechas en formato estadounidense coloca '12/01/2025' después de '03/02/2026' en orden textual, aunque diciembre de 2025 es anterior. Utiliza un tipo de fecha, o texto ISO con formato uniforme en SQLite, para conservar el orden del calendario.

Lee juntos los tipos de un producto

Un producto puede utilizar product_id INTEGER, sku VARCHAR(20), name VARCHAR(100), price DECIMAL(8, 2), weight_lb REAL, in_stock BOOLEAN y added_on DATE. Cada tipo responde a una función: identificación, almacenamiento de códigos, un nombre, dinero exacto, medición, un indicador o una fecha. En SQLite, almacena el precio como céntimos expresados como enteros y la fecha como texto ISO.

NULL indica un valor ausente. Es diferente de cero, de la cadena vacía '' y del texto 'NULL'. Un descuento conocido de 0 significa que no hay descuento; un descuento NULL significa que el importe no está registrado. Una columna que admite NULL permite datos ausentes, mientras que NOT NULL exige un valor.

La ausencia tiene más de un significado

James Wilson no tiene un teléfono registrado. El pedido 102 no tiene fecha de envío porque aún no se ha enviado. Un cliente que es una empresa puede no tener un apellido que corresponda registrar. Todos estos casos pueden representarse con NULL, pero NULL no registra qué motivo se aplica. Un diccionario de datos debe indicar el significado de cada columna.

La cadena vacía es un valor de texto presente en PostgreSQL y SQLite. Actualmente, Oracle trata la cadena vacía como NULL. Las herramientas de consultas pueden mostrar ambos como una celda que parece vacía, por lo que su apariencia no basta para distinguirlos.

Las comparaciones pueden ser desconocidas

Las comparaciones SQL tienen tres resultados posibles: TRUE, FALSE y UNKNOWN. Una comparación en la que interviene NULL, incluida NULL = NULL, es UNKNOWN. No se sabe si dos datos ausentes tienen el mismo valor.

Una cláusula WHERE solo conserva los resultados TRUE. Lee estas condiciones:

• phone IS NULL encuentra los teléfonos ausentes.
• phone IS NOT NULL encuentra los teléfonos registrados.
• phone = NULL da UNKNOWN y no encuentra ninguna fila.

Negar una comparación no recupera un valor ausente. Añade a Daniel Brown, cuyo estado es NULL, a los cuatro clientes de la tienda. La condición state <> 'TX' conserva CO, MA y WA: tres filas. Daniel queda excluido porque la comparación de su estado es UNKNOWN. Para incluir también los estados ausentes, la condición es state <> 'TX' OR state IS NULL.

Combina las condiciones con cuidado

Piensa en UNKNOWN como «podría ser TRUE o FALSE». Un resultado solo queda determinado si ambas posibilidades dan el mismo resultado.

Cálculos y resúmenes

La aritmética ordinaria con NULL da NULL: 5 + NULL es NULL. Un precio de línea multiplicado por una cantidad ausente también es ausente, no cero. Concatenar texto con || y NULL da NULL en PostgreSQL y SQLite; la concatenación de Oracle trata NULL como una cadena vacía.

Las funciones de agregación suelen omitir las entradas NULL. Con cinco clientes, incluidos James y Daniel sin teléfono, COUNT(*) cuenta las cinco filas. COUNT(phone) cuenta los tres teléfonos registrados. El promedio de 4, NULL y 2 es 3, porque la suma de los dos números conocidos se divide entre dos; tratar NULL como cero daría incorrectamente 2.

Utiliza NOT NULL para los datos que deben estar presentes, como una fecha de pedido. No exige un número positivo ni texto no vacío: esas son reglas independientes. Las claves primarias exigen una identidad distinta de NULL; las tablas ordinarias de SQLite tienen una excepción histórica para algunas declaraciones de clave primaria, por lo que declarar NOT NULL explícitamente es importante en ellas.

Una clave identifica una fila mediante sus valores. Los nombres pueden repetirse; los identificadores de cliente distinguen los registros para poder leerlos, modificarlos o vincularlos.

Comprueba la unicidad y la minimalidad

Una superclave es una columna o combinación que identifica una fila de forma única. Una clave candidata es una superclave mínima: eliminar cualquier columna hace perder esa garantía. Elige una candidata como clave primaria; las demás son claves alternativas.

Supón que employee_id, ssn y email son obligatorios y únicos por separado. Cada uno es una clave candidata. (employee_id, department) es una superclave, pero no una candidata: employee_id por sí solo identifica al empleado. Un apellido repetido no supera la prueba de unicidad.

Cuatro clientes con apellidos diferentes no bastan para establecer una clave: un quinto podría compartir un apellido. La unicidad debe cumplirse para todos los datos futuros permitidos. Una repetición descarta una clave propuesta; una muestra sin repeticiones sigue necesitando una regla de negocio que la respalde.

Lee la declaración

Una tabla tiene como máximo una clave primaria. Sus valores son únicos y sus columnas no deben contener NULL. Los valores estables evitan cambios repetidos en las referencias. Busca PRIMARY KEY: ni el nombre de una columna ni su posición la declaran.

Si existe el cliente 1, se rechaza otro cliente con clave 1. Una clave omitida necesita un valor predeterminado o generado. INTEGER PRIMARY KEY de SQLite genera un entero cuando se omite o se indica NULL. Históricamente, algunas otras declaraciones de clave primaria en tablas ordinarias de SQLite permiten NULL; declarar NOT NULL explícitamente, utilizar una tabla STRICT o la forma de clave primaria entera evita esa excepción.

Lee una clave compuesta

En enrollments(student_id, course_id, term, grade), un estudiante puede cursar varias asignaturas y repetir una en otro periodo académico. (student_id, course_id, term) identifica una inscripción: una clave primaria compuesta, no tres claves primarias independientes.

Los componentes individuales pueden repetirse; la combinación completa no. La mayoría de los SGBD crea un índice de clave primaria para las búsquedas, pero la clave no garantiza el orden de salida de las consultas.

Una clave natural procede de datos del mundo real, como el VIN de un vehículo, el ISBN de una edición de un libro o un código estatal. Una clave sustituta existe únicamente para identificar una fila, a menudo como un entero generado o un UUID.

Elige un identificador duradero

Prefiere valores únicos, presentes, estables, compactos y seguros de compartir. Los nombres se repiten; los teléfonos y correos cambian o se comparten. Los números de la Seguridad Social estadounidense son sensibles y algunos clientes no tienen uno; utilizarlos en las tablas que hacen referencia a ellos extiende esa información.

Un customer_id generado permite que Maria conserve el identificador 1 cuando cambian sus datos de contacto. Un state_code natural, como TX, puede funcionar bien porque es compacto, está estandarizado y resulta útil en los registros de direcciones.

Protege por separado los identificadores del negocio

La misma persona puede registrarse dos veces y recibir dos identificadores sustitutos. Los identificadores distinguen filas; no detectan personas duplicadas.

Si el correo debe identificar cada cuenta, utiliza NOT NULL UNIQUE. UNIQUE por sí solo permite varios NULL en PostgreSQL, SQLite y MySQL. SQL Server normalmente permite un NULL en una restricción de unicidad de una sola columna. La presencia y la unicidad son reglas independientes.

El correo obligatorio y único es una clave alternativa. Cambiarlo deja intacto el número sustituto de cliente en los pedidos existentes. Cambiar una clave primaria referenciada también exige mantener la coherencia de las referencias de sus filas hijas.

Reconoce la sintaxis de claves generadas

PostgreSQL también tiene la forma antigua SERIAL. Las eliminaciones, las inserciones fallidas y el trabajo cancelado pueden dejar huecos. Los identificadores 1, 2 y 4 etiquetan tres filas, no cuatro. Renumerarlos para cerrar los huecos puede romper referencias.

Reconoce los UUID

Un UUID es un identificador de 128 bits, normalmente escrito con 36 caracteres y guiones: 7c9e6679-7425-40de-944b-e07fc1f90ae7. Las computadoras pueden generarlos de forma independiente con un riesgo muy bajo de coincidencia, lo que resulta útil cuando se combinarán registros de varios lugares.

Los UUID ocupan más espacio y son más difíciles de leer que los enteros pequeños. Elige según cómo se creen los registros y cómo se haga referencia a ellos. Cualquiera de estos tipos de clave es una etiqueta: su valor máximo no es un recuento de filas y su orden no tiene por qué reflejar el momento de los sucesos.

Una clave foránea es una columna o un grupo de columnas que hace referencia a una clave primaria o a otra clave única adecuada. La tabla que contiene la referencia es la hija; la tabla a la que apunta es la padre. Una clave foránea distinta de NULL debe coincidir con una clave padre existente cuando se aplica la restricción.

Sigue un valor entre tablas

orders.customer_id hace referencia a customers.customer_id. El pedido 102 apunta al cliente 2, James Wilson. Los pedidos 101 y 103 apuntan ambos al cliente 1, Maria Garcia. Se permiten repeticiones en la clave foránea; la clave padre referenciada es única.

Esta regla es la integridad referencial. Se rechaza un pedido para el cliente 99 si el cliente 99 no existe. De lo contrario, sería una fila huérfana: una hija sin un padre coincidente. Un nombre por sí solo no crea ninguna restricción. Una clave foránea llamada placed_by puede hacer referencia a customer_id; la referencia declarada crea el vínculo, con tipos coincidentes para las columnas de clave.

Opcional u obligatorio

Un coupon_id que admite NULL puede ser NULL cuando un pedido no tiene cupón. Un customer_id declarado NOT NULL exige que cada pedido tenga una referencia a un cliente, y la clave foránea exige que ese cliente exista. Estas dos restricciones trabajan juntas: una exige un valor y la otra comprueba la referencia.

Las claves foráneas no tienen por qué cruzar los límites de una tabla. En employees(employee_id, name, manager_id), manager_id puede hacer referencia a employee_id de la misma tabla. Quien ocupa la dirección general puede tener una referencia NULL a su responsable.

Los cambios en el padre necesitan una regla

Con la acción predeterminada, no se puede eliminar al cliente 1 mientras los pedidos 101 y 103 sigan haciendo referencia a ella. La eliminación en cascada de un pedido a sus líneas puede tener sentido porque esas líneas pertenecen a ese pedido. ON UPDATE especifica el comportamiento correspondiente cuando cambia una clave padre. La cascada no significa que eliminar una hija elimine a su padre.

Referencias compuestas y aplicación de restricciones

Si una línea de pedido se identifica mediante (order_id, product_id), un envío que hace referencia a esa línea necesita ambas columnas. La combinación debe coincidir con una línea existente. No basta con encontrar por separado un pedido y un producto: ese producto podría no haber aparecido nunca en ese pedido. Una referencia compuesta obligatoria declara todas sus columnas NOT NULL.

PostgreSQL, SQL Server, Oracle y el motor habitual InnoDB de MySQL hacen cumplir las claves foráneas declaradas. En SQLite, activa y comprueba la aplicación de las restricciones de clave foránea para cada conexión con PRAGMA foreign_keys = ON; antes de confiar en ellas. Una restricción declarada pero desactivada no puede proteger las filas. Las claves foráneas tampoco combinan por sí solas los resultados de las consultas; una consulta debe seguir explícitamente el vínculo, normalmente mediante una combinación.

Para identificar una relación, haz dos preguntas: «Para una fila de aquí, ¿cuántas filas de allí pueden vincularse?» y después la pregunta inversa. Incluye el mínimo y el máximo. La muestra actual indica qué ha ocurrido; las restricciones describen qué se permite.

Un cliente, muchos pedidos

Un cliente puede realizar cero o más pedidos. Cada pedido de la tienda pertenece exactamente a un cliente porque orders.customer_id es una clave foránea que no admite NULL. Esta es una relación uno a muchos. La clave foránea corresponde a orders, el lado muchos: cada pedido almacena una referencia a un cliente.

Maria tiene los pedidos 101 y 103; James tiene el pedido 102. Aisha y Wei no tienen ninguno. Su ausencia de orders es válida. Una clave foránea exige un padre para cada hija, pero no exige que cada padre tenga una hija.

Uno a uno también necesita unicidad

En user_profiles(user_id, bio, photo_url), establece user_id como clave primaria y clave foránea hacia users. Cada perfil hace referencia a un usuario, y un usuario puede tener como máximo un perfil porque la clave del perfil no puede repetirse. Un usuario puede no tener perfil todavía.

Una clave foránea sin unicidad permitiría varios perfiles para el mismo usuario, lo que daría una relación uno a muchos. La restricción de unicidad cambia el máximo. Estas tablas de perfiles independientes pueden separar los datos opcionales o sensibles del registro principal del usuario.

Muchos a muchos utiliza una tabla de pares

Un pedido puede contener varios productos, y un producto puede aparecer en varios pedidos. Una tabla intermedia, también llamada tabla puente, de enlace o de asociación, registra cada emparejamiento:

order_id hace referencia a orders; product_id hace referencia a products. La clave primaria compuesta (order_id, product_id) permite el mismo producto en distintos pedidos, pero impide que el mismo par aparezca dos veces. Dos vínculos uno a muchos implementan la relación muchos a muchos.

quantity y unit_price pertenecen al emparejamiento. Describen cuántas unidades de ese producto se vendieron en ese pedido y el precio cobrado entonces. El precio actual de un producto puede cambiar después; no debe modificar el importe histórico cobrado.

Para el pedido 101, los importes de las dos líneas son dos tazas a 12,50 u.m., que dan 25,00 u.m., y un cargador a 8,99 u.m. Juntos cuestan 33,99 u.m. La cantidad indica cuántas tazas se compraron; almacenar dos líneas de taza duplicadas entraría en conflicto con la clave elegida para esta tabla.

Evita las listas y los espacios fijos

Una celda product_ids que contiene «11,12» oculta varias referencias dentro de un valor de texto. Las columnas como product1, product2 y product3 imponen un límite fijo y dejan espacios sin utilizar. Una tabla intermedia añade una fila por cada emparejamiento adicional y permite que el SGBD compruebe cada referencia por separado.

Una relación autorreferencial utiliza el mismo patrón dentro de una tabla: muchos empleados pueden hacer referencia al mismo responsable mediante manager_id. El responsable también es una fila de empleado. Lee cada vínculo como un papel, para mantener diferenciadas la identidad del empleado y la referencia a su responsable.

Un esquema describe tablas, columnas, tipos de datos y restricciones. Una instancia son los datos almacenados en un momento concreto. Añadir un pedido cambia la instancia; añadir una columna nueva cambia el esquema. El esquema indica qué puede almacenarse, mientras que las filas indican qué está almacenado ahora.

Lee una descripción breve

customers(customer_id, first_name, last_name, email, phone, city, state, zip_code) enumera una tabla y sus columnas. Las notas pueden subrayar las claves primarias o marcarlas con PK, y marcar las referencias con FK. Por ejemplo, orders(order_id PK, customer_id FK → customers, order_date, shipped_date) identifica la clave principal y el vínculo con el cliente.

Lee una definición completa de tabla

CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  customer_id INTEGER NOT NULL REFERENCES customers (customer_id),
  order_date DATE NOT NULL,
  shipped_date DATE
);

Lee una columna cada vez. order_id es la clave primaria entera. customer_id es obligatorio y debe hacer referencia a un cliente. order_date es obligatorio. shipped_date puede ser NULL. Esta definición proporciona la estructura permitida, no una lista de pedidos existentes.

Las restricciones responden preguntas diferentes:

Un valor predeterminado no sustituye un valor no válido que se haya proporcionado. Si status tiene DEFAULT 'pending', omitir el estado aporta 'pending'; un valor proporcionado sigue teniendo que cumplir las demás reglas de la columna.

Combina reglas para una línea de pedido

CREATE TABLE order_items (
  order_id INTEGER NOT NULL REFERENCES orders (order_id),
  product_id INTEGER NOT NULL REFERENCES products (product_id),
  quantity INTEGER NOT NULL CHECK (quantity > 0),
  unit_price DECIMAL(8, 2) NOT NULL,
  PRIMARY KEY (order_id, product_id)
);

La clave primaria al final utiliza dos columnas. Una segunda línea para el mismo pedido y producto se rechaza. La cantidad 0 no supera la comprobación. Una cantidad ausente incumple NOT NULL: la comprobación por sí sola permitiría NULL porque NULL > 0 es UNKNOWN, no FALSE. Declarar NOT NULL explícitamente en ambas partes de la clave también evita la excepción histórica de SQLite que permite NULL en claves compuestas. En SQLite, utiliza céntimos expresados como enteros para un unit_price exacto; la declaración decimal por sí sola no proporciona almacenamiento exacto.

Encuentra el esquema y sus significados

En la interfaz de comandos de SQLite, .schema orders muestra la definición; en psql de PostgreSQL, \d orders la describe. Las vistas INFORMATION_SCHEMA enumeran metadatos estructurales en PostgreSQL, MySQL y SQL Server. SQLite enumera los objetos en sqlite_schema, y las herramientas gráficas muestran tablas y columnas en un árbol.

«Esquema» también designa un espacio de nombres en sistemas como PostgreSQL y SQL Server. sales.orders significa la tabla de pedidos del esquema de ventas. Un diccionario de datos aporta significados que la estructura no puede expresar, como la moneda del precio o si una fecha de envío ausente significa «no enviado». Para ver filas, una consulta como SELECT * FROM orders; lee la instancia actual.

Un diagrama del esquema representa cada tabla como un recuadro. El título nombra la tabla; el contenido enumera las columnas y, a menudo, sus tipos. PK marca las claves primarias y FK las foráneas. Las líneas de relación muestran qué clave foránea hace referencia a qué clave padre.

Identifica primero el tipo de línea

Algunos diagramas utilizan una flecha desde una clave foránea hasta la clave referenciada. Una flecha de orders.customer_id a customers.customer_id describe la dirección de la referencia. Otras herramientas utilizan símbolos en los extremos para describir cuántas filas pueden vincularse. Comprueba la leyenda del diagrama: la dirección de una flecha y la cardinalidad de una relación son información diferente.

Lee los símbolos de pata de cuervo

En la notación de pata de cuervo, una barra significa uno, un círculo significa cero y una pata de tres puntas significa muchos. Cada extremo de línea indica un mínimo y un máximo. El símbolo más cercano a la tabla da el máximo; el otro da el mínimo.

Al leer desde una tabla, mira los símbolos junto a la otra tabla. Esos símbolos describen cuántas filas de allí pueden corresponder a tu única fila inicial.

Recorre clientes y pedidos

La línea de la tienda tiene símbolos de exactamente uno junto a customers y de cero o más junto a orders.

1. Empieza con un cliente. Mira el extremo de los pedidos: el cliente puede tener cero o más pedidos.
2. Empieza con un pedido. Mira el extremo de los clientes: el pedido pertenece exactamente a un cliente.
3. Comprueba la definición: la clave foránea que no admite NULL está en orders, por lo que es el lado muchos y cada pedido necesita un cliente válido.

La pata de cuervo está junto a la tabla que contiene la clave foránea que puede repetirse. Leer el extremo cercano al empezar desde esa misma tabla invierte el significado. Una referencia a cliente que admitiera NULL cambiaría el extremo de los clientes a cero o uno; no limitaría cada cliente a un pedido.

Reconoce una tabla intermedia

La tienda tiene vínculos uno a muchos de orders a order_items y de products a order_items. Ambos extremos muchos se encuentran en order_items. Sus dos claves foráneas forman la clave primaria. Esta estructura permite que un pedido contenga varios productos y que un producto aparezca en varios pedidos.

El diagrama describe conexiones permitidas, no los recuentos actuales. Permite que Maria tenga varios pedidos y que Aisha no tenga ninguno. Para saber cuántos tiene realmente cada una, lee las filas. Un mínimo de uno desde padre a hija puede expresar una regla de negocio adicional; una clave foránea por sí sola no exige que un padre tenga hijas.

Reconoce estilos de diagrama relacionados

Un diagrama entidad-relación creado durante el diseño puede mostrar entidades del negocio antes de que existan las tablas. Los diagramas de estilo Chen utilizan óvalos para los atributos y rombos para las relaciones. Un diagrama del esquema muestra las tablas reales y sus claves declaradas. Ambos ayudan a comunicar la estructura, pero sus símbolos deben leerse según su propia leyenda.

Localiza cada dato solicitado y sigue las claves que lo conectan con el registro inicial. Los nombres pueden repetirse o cambiar; haz coincidir los valores de las claves.

Encuentra el cliente de un pedido

«¿Dónde vive el cliente que realizó el pedido 102?» sigue esta ruta:

1. Busca el pedido 102 mediante orders.order_id.
2. Lee su customer_id: 2.
3. Busca el cliente 2 mediante customers.customer_id.
4. Lee customers.city: Denver.

El número de pedido 102 no es el identificador del cliente. Las combinaciones SQL automatizan estas coincidencias de claves; las posiciones en pantalla no conectan los registros.

Encuentra productos y un total histórico

El pedido 101 tiene estas filas de order_items. Sigue cada product_id hasta products para obtener su nombre:

Utiliza el precio registrado en la línea para calcular el importe cobrado:

• Dos tazas a 12,50 u.m. cuestan 25,00 u.m.
• Un cargador a 8,99 u.m. cuesta 8,99 u.m.
• Total: 33,99 u.m.

El precio actual del producto podría dar un coste incorrecto para un pedido antiguo. El pedido 102 tiene una lámpara a 34,00 u.m.; el pedido 103 tiene cuatro tazas a 12,50 u.m., con un total de 50,00 u.m.

Interpreta los valores ausentes y las reglas

La fecha de envío del pedido 102 es NULL, documentado aquí como «no enviado». Compruébalo con IS NULL, no con una igualdad a NULL.

Lee todas las restricciones pertinentes al evaluar un cambio:

• Una línea para el pedido 104 se rechaza si ese pedido no existe.
• Otra línea con clave (101, 11) se rechaza porque el par existe.
• La cantidad 0 no supera la comprobación de cantidad positiva.
• El comportamiento predeterminado de la clave foránea impide eliminar el producto 11 mientras haya líneas que hagan referencia a él.

Una clave no utilizada no hace válida una fila si falta el destino de su referencia.

Identifica las filas nuevas

Un cliente que vuelve y compra dos productos existentes distintos añade una fila de orders y dos filas de order_items. El cliente y los productos ya existen. Ofrecer un producto nuevo añade una fila de products, sin exigir un pedido.