Restricciones asociadas a los datos

Corresponde a las restricciones que permiten asegurar la integridad de las tablas de la base de datos. La primera y más importante es la que determina que cada tabla debe estar identificada de forma única, lo cual asegura que no existan dos tablas con la misma información.

1. Claves primarias

Esta identificación única en el modelo relacional también se conoce como «llave primaria» o «clave principal». Por ejemplo, la entidad «producto» contiene un campo que identifica a cada producto de manera única: el código del producto, que haría las veces de llave primaria para esta tabla.

Es necesario entonces seleccionar siempre un campo, o conjunto de campos, de la entidad como «campo clave» y se debe verificar que este campo sea un identificador representativo de la entidad y que no se repita. En algunas circunstancias es posible que se trate de una clave compuesta (como ocurre en las tablas que se generan a partir de la transformación de relaciones de muchos a muchos), para lo cual se debe verificar si por separado estos campos no tienen características de unicidad individual en esta entidad.

_{Figura 1. Llave primaria. En este caso, la identificación del empleado es un atributo único.
En la tabla «proyecto», a cada proyecto se le asigna un número que también lo identifica de forma única.} 2. Valores únicos

Otra de las restricciones que se encuentra en esta categoría es la que corresponde con la no repetición de datos. Esta restricción se denomina unicidad y permite seleccionar los campos para los cuales no se deben admitir valores repetidos. Por ejemplo, en un registro de usuarios se puede exigir que no se repita el nombre de usuario.

La selección de campos que pueden considerarse únicos debe realizarse de manera concienzuda, ya que no solo imposibilitará el registro de otras filas de datos en la misma entidad, con el valor repetido, sino que además afectará físicamente la estructura de la base de datos al construir índices para estas columnas, así como para la clave principal.

Esta restricción está relacionada con los posibles valores permitidos de un campo en la entidad. En esta categoría se encuentra la especificación del tipo de datos, su obligatoriedad, validación y los valores predeterminados.

1. Tipos de datos

Esta restricción permitirá definir el tipo de información que se espera recibir en el campo. Aquí es necesario introducir el concepto del dominio de los datos, que corresponde con los posibles valores que se pueden admitir en el campo. Por ejemplo, para la entidad «historia clínica», que contiene, entre otros, campos como: tipo de sangre, factor Rh, nombre del paciente y teléfono, se espera que se almacenen respectivamente: los tipos de sangre O, A, B, o AB, en el campo tipo de sangre; positivo o negativo, en el factor Rh; los nombres de pacientes y sus números telefónicos.

De acuerdo con lo anterior, la determinación de los tipos de datos —numéricos, alfanuméricos, fechas, etc.— es necesaria para que el dominio de datos esperado sea posible de registrar.

2. Valores obligatorios

El concepto de obligatoriedad es más fácil de asociar, pues se encuentra con mucha frecuencia en aplicaciones, formularios y sitios web, y se ha estandarizado con el uso del asterisco, el cual indica que un dato solicitado no puede quedar vacío. Siendo los valores nulos la representación de la ausencia de valores en un campo de una entidad, la restricción que impide la omisión de los datos se representa con la expresión «NOT NULL».

Para cumplir con el objetivo de cada una de las tablas definidas en el modelo es necesario verificar cuáles de ellas son de registros obligatorios y cuales de registros opcionales, de acuerdo con las reglas de negocio de la organización. Por ejemplo, para la tabla «cliente», el registro de su identificación, nombre y teléfono debería ser obligatorio, pero el campo «dirección» podría ser opcional, a menos que se le deba enviar un pedido o algún tipo de correspondencia. En este caso, el campo debe ser de registro obligatorio.

3. Reglas a validar

Mediante este tipo de restricciones es posible validar el cumplimiento de condiciones preestablecidas para los datos, pues este tipo de condiciones limitan el rango de valores admitidos en la entidad. Por ejemplo, en una tabla denominada «calificación» es posible especificar que la nota solo admita valores entre 0 y 5. Antes de aplicar el uso de este tipo de integridad, es importante verificar que la condición a establecer esté completamente definida y sin ambigüedades.

4. Valores predeterminados

La definición de valores predeterminados en un campo implica, desde la perspectiva del negocio, establecer un valor con el que puede quedar registrado un campo en caso de ser ignorado por el usuario que registra los datos. Por ejemplo, las fechas de realización de operaciones pueden ser tomadas del sistema operativo sin que el usuario deba especificarlas, otro ejemplo de esto puede ser el registro de una ciudad o la cantidad mínima de un pedido.

_{Figura 2. Dominio de datos. El dominio de un campo corresponde
a todos los posibles valores que este puede tener.}

La integridad referencial permite garantizar que existe una correlación entre los datos proporcionados en una entidad y otra que los describe. En la estructura del modelo relacional se establece el vínculo entre relaciones a través de las «llaves foráneas» o «claves externas», lo cual significa que los valores de estas llaves deben coincidir con los valores de una clave principal en otra entidad.

Por ejemplo, en la tabla «producto» el campo que contiene el código de la categoría a la que pertenece estaría haciendo las veces de llave foránea, la tabla «categorías» presentaría los detalles de las categorías y el campo, que es llave primaria, tendría en sus sus datos almacenados los códigos de las categorías.

La restricción de integridad referencial permite controlar las siguientes condiciones.

• Solo admitirá, en los valores de llaves foráneas, datos que se encuentren como llave primaria en la tabla relacionada.
• Si se trata de eliminar un registro en una tabla padre —tabla de referencia— se verificará si posee registros hijos, en cuyo caso se verificará si la restricción establecida admite la eliminación en cascada o lo impide.
• En caso de modificación de la llave foránea, nuevamente verificará la existencia de esa clave en la tabla padre.
• En caso de modificación de las llaves primarias en una tabla se verificará si posee registros hijos asociados, en cuyo caso se verificará si la restricción establecida admite la actualización en cascada.
_{Figura 3. Integridad referencial. Esta figura representa un modelo relacional de una base de datos
y permite identificar las llaves foráneas; es decir, los campos de una tabla que establecen vínculos con otra.}

En el caso de la tabla «proyecto» la llave foránea se denota con un símbolo en un color diferente y la sigla FK, e indica que el proyecto tiene asociado un cliente cuyos datos se encuentran en otra tabla.

Los anteriores tipos de integridad pueden ser implementados directamente en el modelo físico durante la etapa de creación de la estructura utilizando lenguaje SQL; sin embargo, algunas de las reglas de negocio pueden requerir otros tipos de acciones para su implementación.

Se denomina integridad de transición a las restricciones que determinan cómo un campo puede cambiar de valor de acuerdo con unas reglas definidas a través del tiempo. Por ejemplo, si se han establecido unas categorías para un cliente que pueden ser determinadas por el total de las compras realizadas, podría entonces pasar de ser un cliente básico a un cliente preferencial, si el total de sus compras cumple con el monto que se especificó para ello.

La integridad de transacciones se relaciona con la realización de un conjunto de operaciones de datos, las cuales deben realizarse completamente o no registrarse ninguna. En estas transacciones pueden estar involucradas diferentes tablas y campos. Un ejemplo típico de la integridad de transacciones ocurre cuando se presenta un fallo en el sistema tras ingresar parte de los ítems al momento de registrar un pedido. En este caso, la información registrada debe deshacerse, pues si no se registró la totalidad de los ítems del pedido, dicho pedido no debe quedar registrado en el sistema.