Tema 1 de 5
El modelo relacional es la forma más extendida de guardar datos transaccionales: inventarios, comercio electrónico, datos de clientes. El examen pregunta sus características, qué es la normalización y para qué sirven las claves. Son conceptos que aparecen también en SQL y en los servicios de Azure.
Contenido
En los primeros sistemas, cada aplicación guardaba los datos en su propia estructura. Para usar esos datos había que conocer a fondo esa estructura, y eran ineficientes, difíciles de mantener y de optimizar. El modelo relacional resolvió ese problema con una forma estándar de representar y consultar datos que puede usar cualquier aplicación.
Su gran ventaja son las tablas: una forma intuitiva, eficiente y flexible de guardar información estructurada. Sirve para cualquier información con elementos relacionados que deben organizarse en una estructura coherente y basada en reglas.
En una base de datos relacional, las entidades del mundo real se modelan como tablas. Una entidad es cualquier cosa sobre la que se quiere guardar información, normalmente objetos y eventos importantes.
Tabla
Una colección de entidades: Cliente, Producto, Pedido, LíneaDePedido.
Fila
Una instancia de la entidad: un cliente concreto, un pedido concreto.
Columna
Un atributo: correo, precio, fecha del pedido.
Las tablas relacionales son un formato de datos estructurados: todas las filas de una tabla tienen las mismas columnas.
Cada columna guarda datos de un tipo concreto. Los tipos disponibles dependen del sistema de base de datos, aunque el ANSI (American National Standards Institute) define tipos estándar que admite la mayoría.
| Columna | Tipo de dato adecuado |
|---|---|
| Email (Cliente) | Texto, de longitud fija o variable |
| Price (Producto) | Numérico decimal |
| Quantity (Pedido) | Numérico entero |
| OrderDate (Pedido) | Fecha y hora |
NULL
No todas las columnas necesitan valor. Una columna MiddleName puede quedar vacía (NULL) para clientes sin segundo nombre o cuyo segundo nombre se desconoce. La columna sigue existiendo en todas las filas.
Proceso de diseño de esquemas que minimiza la duplicación de datos y refuerza su integridad. Hay reglas formales complejas (las «formas normales»), pero en la práctica se resume así:
Separar cada entidad en su propia tabla.
Separar cada atributo diferenciado en su propia columna.
Identificar de forma única cada instancia (fila) con una clave principal.
Usar columnas de clave externa para enlazar entidades relacionadas.
Una empresa registra sus ventas en una hoja de cálculo:
| OrderNo | CustomerName | CustomerAddress | ProductName | UnitPrice | Qty |
|---|---|---|---|---|---|
| 1 | Jane Smith | 42 Oak St Seattle | Widget A | 9.99 | 2 |
| 1 | Jane Smith | 42 Oak St Seattle | Widget B | 4.49 | 1 |
| 2 | Bob Jones | 18 Pine Ave Portland | Widget A | 9.99 | 5 |
| 3 | Jane Smith | 42 Oak St Seattle | Gadget X | 24.99 | 3 |
Problemas
Los datos del cliente y del producto se repiten en cada artículo vendido, y la dirección mezcla calle y ciudad en una sola celda.
Tras normalizar
Tablas Cliente, Producto, Pedido y LíneaDePedido, cada atributo en su columna. Cambiar la dirección de Jane solo exige modificar una fila.
Clave principal (primary key)
Un identificador u otro valor que identifica de forma única cada instancia de la entidad. Ejemplo: el ID de cliente.
Clave externa (foreign key)
Cuando una entidad referencia a otra, guarda la clave principal de la entidad relacionada. Ejemplo: el pedido guarda el ID del cliente.
Así, la dirección del cliente se guarda una sola vez y cada pedido la consulta a través de la tabla Cliente.
Integridad referencial
Un sistema de gestión de bases de datos relacionales (RDBMS) puede garantizar que el valor de una clave externa tenga una clave principal correspondiente en la tabla relacionada. Así impide, por ejemplo, pedidos de clientes inexistentes.
Clave compuesta
Una clave (principal o externa) puede basarse en una combinación única de varias columnas. La tabla LíneaDePedido usa OrderNo + ItemNo para identificar cada línea de un pedido.
| Situación | Concepto | Por qué |
|---|---|---|
| Cambiar la dirección de un cliente en un solo sitio | Normalización | Cada entidad en su tabla, sin duplicados. |
| Identificar de forma única cada producto | Clave principal | Valor único por fila. |
| Guardar en cada pedido a qué cliente pertenece | Clave externa | Referencia a la clave principal de Cliente. |
| Impedir pedidos de clientes que no existen | Integridad referencial | La clave externa debe existir en la tabla relacionada. |
| Identificar una línea de pedido por número de pedido y de línea | Clave compuesta | Combinación única de varias columnas. |
| Filtrar clientes por ciudad sin buscar dentro de un texto | Atributos en columnas separadas | Más granularidad para consultar. |
| Un cliente sin segundo nombre | Valor NULL | La columna existe pero no tiene valor. |
❓ ¿La normalización busca duplicar datos para que las consultas sean más rápidas?
No. Busca minimizar la duplicación y reforzar la integridad. Desnormalizar es lo que se hace en análisis.
❓ ¿Una clave externa identifica de forma única las filas de su propia tabla?
No. Eso es la clave principal; la externa referencia la clave principal de otra tabla.
❓ ¿Una clave puede estar formada por varias columnas?
Sí: es una clave compuesta, como OrderNo + ItemNo.
❓ ¿Si una columna admite NULL, la tabla deja de tener esquema fijo?
No. La columna sigue existiendo; solo puede quedar sin valor.
❓ ¿Qué impide registrar un pedido para un cliente que no existe?
La integridad referencial que aplica el RDBMS sobre la clave externa.
❓ ¿Los tipos de datos son idénticos en todos los sistemas de bases de datos?
No. Dependen del sistema, aunque ANSI define tipos estándar que la mayoría admite.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
En una base de datos de ventas, la tabla Pedido tiene una columna CustomerID que apunta al ID de la tabla Cliente. ¿Qué es CustomerID en la tabla Pedido?
Preguntas originales, cada una con su explicación.
Empezar un simulacro