Realización de cambios en la estructura de tablas y creación de relaciones

11.2 Realización de cambios en la estructura de tablas y creación de relaciones

Una vez que hemos comprendido los conceptos fundamentales de las bases de datos relacionales y familiarizado con la interfaz de la aplicación, es momento de abordar las tareas prácticas de modificación de estructuras y establecimiento de relaciones entre tablas. Esta es una competencia esencial en la gestión de sistemas de información, ya que las bases de datos raramente se mantienen estáticas: la evolución del negocio, los cambios normativos y la necesidad de capturar nuevos datos requieren ajustes continuos en su estructura.

En este apartado aprenderemos a realizar cambios en la definición de las tablas existentes, a ajustar los tipos de datos según nuevas necesidades y a crear las relaciones que garantizan la integridad referencial del sistema. Estos cambios forman parte del ciclo de vida de las bases de datos y demandan una comprensión clara de cómo impactan en el resto del sistema.

Modificación de estructuras de tablas

La modificación de una tabla existente permite agregar nuevos campos, cambiar características de campos existentes o eliminar columnas. En una aplicación de bases de datos, este proceso generalmente se realiza a través del modo diseño o editor de tablas.

Para modificar una tabla, accedemos a la vista diseño donde podemos visualizar la estructura completa: nombres de campos, tipos de datos, tamaños, restricciones y propiedades especiales. Desde aquí podemos insertar nuevos campos entre los existentes o al final de la tabla. Por ejemplo, si disponemos de una tabla de clientes y necesitamos añadir un campo de teléfono secundario, lo insertamos en la posición adecuada y especificamos sus características.

Los cambios en tipos de datos merecen especial atención. Si modificamos un campo de texto a numérico, es posible que se produzcan errores en los registros existentes si contienen valores no compatibles. Las aplicaciones generalmente ofrecen opciones para convertir datos o advertir sobre incompatibilidades. Igualmente, cambiar el tamaño de un campo de texto de cien a cincuenta caracteres puede provocar la pérdida de datos si existen registros que superan esa longitud.

Tipos de datos y propiedades de campos

La elección correcta del tipo de dato es fundamental para la integridad y eficiencia de la base de datos. Los tipos más comunes son:

• Texto: para caracteres alfabéticos, numéricos combinados, referencias. Se especifica la longitud máxima.
• Número: para valores numéricos, con variantes de precisión (entero, simple, doble).
• Fecha/Hora: para almacenar fechas, horas o combinaciones, con formato específico.
• Sí/No o Booleano: para valores verdadero o falso, muy utilizados en campos de estado o activación.
• Moneda: tipo especializado para valores económicos con precisión decimal garantizada.
• Objeto OLE: para incrustar documentos o imágenes dentro de la base de datos.

Cada campo posee además propiedades adicionales: valor predeterminado (el que se asigna automáticamente si no se introduce un valor), validación (reglas que debe cumplir el dato), requerido (si debe obligatoriamente contener un valor), y índice (para optimizar búsquedas).

Eliminación de campos y consecuencias

La eliminación de un campo requiere cautela. Si un campo está siendo utilizado en consultas, formularios, informes o relaciones, su eliminación puede romper estas dependencias. Antes de eliminar, es conveniente realizar un análisis de dónde se usa ese campo en el sistema. Muchas aplicaciones ofrecen funcionalidad de búsqueda de referencias para identificar qué objetos dependen de un campo determinado.

Cuando eliminamos un campo, también se eliminan todos los datos contenidos en ese campo para todos los registros. Esta acción generalmente no es reversible, aunque es recomendable realizar una copia de seguridad previa.

Creación de relaciones entre tablas

Las relaciones son vínculos lógicos que establecen cómo se conectan los datos de diferentes tablas. Son el mecanismo que permite desnormalizar el almacenamiento (separar datos en múltiples tablas) manteniendo la capacidad de consultarlos conjuntamente.

Una relación se establece mediante campos clave: una tabla tiene una clave primaria (el identificador único de cada registro) y otra tabla tiene una clave externa (campo que referencia la clave primaria de la primera tabla). Por ejemplo, en una base de datos de ventas, la tabla Clientes contiene un campo IdCliente (clave primaria), y la tabla Pedidos contiene un campo IdCliente (clave externa) que apunta al cliente responsable de cada pedido.

Tipos de relaciones

Las relaciones se clasifican según la multiplicidad de registros que pueden participar en ambos lados:

Uno a muchos (1:N): Es la más común. Un registro de la tabla primaria puede estar relacionado con múltiples registros de la tabla secundaria. Un cliente puede tener múltiples pedidos, pero cada pedido pertenece a un único cliente.

Uno a uno (1:1): Un registro de una tabla se relaciona con exactamente un registro de la otra tabla. Ejemplo: cada empleado tiene una única ficha de salud ocupacional. Esta relación es menos frecuente y generalmente indica que podría haberse consolidado la información en una sola tabla.

Muchos a muchos (N:N): Múltiples registros de una tabla se relacionan con múltiples registros de otra tabla. Ejemplo: estudiantes y cursos (un estudiante cursa varios cursos, cada curso tiene varios estudiantes). Esta relación se implementa mediante una tabla intermedia o de unión que contiene las claves externas de ambas tablas.

Integridad referencial

Cuando creamos una relación, podemos establecer reglas de integridad referencial que garantizan consistencia en los datos. Estas reglas definen qué ocurre cuando intentamos eliminar o modificar registros que tienen relaciones:

• Restricción: no permite la eliminación si existen registros relacionados.
• Cascada: elimina automáticamente todos los registros relacionados. Debe usarse con cuidado.
• Establecer a nulo: asigna valor nulo a la clave externa en los registros relacionados.

Caso práctico: restructuración de base de datos de inventario

Imaginemos que disponemos de una tabla de Productos que originalmente solo contenía nombre y precio. El negocio ha crecido y necesita organizar productos por categorías, registrar proveedores y mantener historial de cambios de precio. En lugar de añadir campos directamente, creamos tablas normalizadas: Categorías con su propia clave primaria, Proveedores con información de contacto, e HistorialPrecios para registrar cambios temporales.

Modificamos la tabla Productos eliminando el campo categoría texto y añadiendo IdCategoria (clave externa). Creamos una relación uno a muchos entre Categorías y Productos. De igual forma, añadimos IdProveedor. Para el historial, creamos HistorialPrecios con IdProducto (clave externa), FechaInicio, FechaFin y Precio, donde cada producto puede tener múltiples registros históricos.

Este proceso implica: crear las nuevas tablas con sus claves primarias, agregar campos de clave externa en Productos, establecer las relaciones con sus reglas de integridad (si un producto se elimina, no eliminamos la categoría, pero si una categoría se elimina, restringimos la operación o cascada según política), y finalmente migrar datos existentes a la nueva estructura.

Ideas clave

• Las modificaciones de estructura requieren análisis previo de cómo impactarán en formularios, consultas e informes existentes.
• Antes de cambiar tipos de datos o eliminar campos, es imprescindible realizar copias de seguridad y evaluar compatibilidad con datos existentes.
• Las relaciones se establecen mediante claves primarias y externas, permitiendo conectar información normalizada en múltiples tablas.
• La integridad referencial protege la consistencia del sistema mediante reglas que controlan qué ocurre cuando se modifican o eliminan datos relacionados.
• El diseño normalizado (separación de datos en múltiples tablas relacionadas) es superior a un enfoque con campos desnormalizados, permitiendo flexibilidad y mantenibilidad.
• Las relaciones muchos a muchos requieren una tabla intermedia para conectar correctamente dos tablas sin redundancia de datos.