Tema 2: Introducción al diseño de bases de datos

Componentes de una base de datos SQL Server

Una base de datos SQL Server consiste en una colección de tablas que guardan conjuntos específicos de datos estructurados. Una tabla (entidad) contiene una colección de filas (tuplas) y columnas (atributos). Cada columna en la tabla se diseña para guardar un cierto tipo de información (por ejemplo, fechas, nombres, montos, o números). Las tablas tienen varios tipos de controles (restricciones, reglas, desencadenadores, valores por defecto, y tipos de datos de usuario) que aseguran la validez de los datos. Las tablas pueden tener índices (similar a los de los libros) que permiten encontrar las filas rápidamente. Usted puede agregar restricciones de integridad referencial a las tablas para asegurar la consistencia entre los datos interrelacionados en tablas diferentes. Una base de datos también puede utilizar procedimientos almacenados que usan Transact-SQL programando código para realizar operaciones con los datos en la base de datos, como guardar vistas que proporcionan acceso personalizado a los datos de la tabla.

Por ejemplo, suponga que se crea una base de datos llamada MiCoBD para manejar los datos en su compañía. En la base de datos MiCoBD, crea una tabla llamada Empleados para guardar información sobre cada empleado, y la tabla contiene las columnas EmpID, Apellido, Nombre, Dept, y Cargo. Para asegurar que nunca dos empleados tengan el mismo EmpID y que la columna de Dept contiene números sólo válidos para las secciones en su compañía, usted debe agregar restricciones a la tabla. Si usted quisiera realizar búsquedas rápidas para encontrar los datos de un empleado basado en el ID del empleado, usted definiría índices. Por cada empleado, se agrega una fila de datos a la tabla Empleados, para esto usted crea que un procedimiento almacenado llamado AgregarEmp que se personaliza para aceptar los valores de los datos por un nuevo empleado y que realiza la operación de agregar la fila a la tabla Empleados. Se podría necesitar un resumen departamental de empleados, por lo que usted define una vista llamada EmpsDept que combina datos de las tablas Secciones y Empleados. Figura 2.1 muestra las partes de la base de datos MiCoBD.

Normalizar un diseño de base de datos

A continuación se verá el tema de normalización desde un punto vista práctico, resaltando aquellos conceptos útiles y comentando las limitaciones que deben tenerse en cuenta en el proceso de normalizado de una base de datos.

Perfeccionar un diseño de base de datos incluye el proceso de normalización. Normalizar un diseño lógico de base de datos involucra usar métodos formales para separar los datos en múltiples tablas relacionadas. Tener un número mayor de tablas con pocas columnas es característico de una base de datos normalizada; mientras que tener pocas tablas con más columnas cada una es característico de una base de datos no-normalizada.

Una normalización razonable mejora a menudo el comportamiento general del sistema. Cuando se utilizan los índices, el SQL Server 2000 Query Optimizer (Optimizador de Consultas de SQL Server) es muy eficiente al seleccionar interrelaciones entre las tablas.
Un aumento de la normalización produce una mayor cantidad y complejidad de combinaciones entre las tablas requeridas para recuperar los datos. Demasiadas combinaciones complejas entre varias tablas puede deteriorar el rendimiento en las consultas. Una normalización razonable debería incluir la mínima cantidad de consultas habituales posible que involucren más de cuatro tablas relacionadas.

Una base de datos que se usa principalmente para soporte de decisión (al revés de una base de datos operacional que realiza tareas de actualización de datos) podría no tener actualizaciones redundantes y podría ser más entendible y eficaz para las consultas si el diseño no se normaliza totalmente. No obstante, tener datos no-normalizados es el error de diseño más común en aplicaciones de base de datos más que tener datos demasiado normalizados. Empezar con un diseño completamente normalizado y a partir de allí desnormalizar selectivamente algunas tablas por razones específicas de rendimiento de las consultas es una buena estrategia.

A veces el diseño de la base de datos lógico ya está definido, tal el caso de una base de datos existente, y el rediseño total no es factible. Pero aún entonces, podría ser posible normalizar una tabla grande selectivamente en varias tablas más pequeñas. Si la base de datos es accedida a través de los procedimientos almacenados, este cambio del esquema podría tener lugar sin afectar las aplicaciones. Si no, podría ser posible crear una vista que esconde de las aplicaciones el cambio del esquema.

Lograr una base de datos bien diseñada

En la teoría de diseño de base de datos relacionales, las reglas de normalización identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseñada. Estas reglas pueden ponerse bastante complicadas y pueden ir más allá del alcance del presente. De todos modos, hay algunas reglas que pueden ayudarlo a lograr un diseño de la base de datos correcto. Una tabla debe tener un identificador, debe guardar datos para sólo un solo tipo de entidad, debería evitar columnas que acepten valores nulos, y no debe tener valores o columnas repetidas.

Una Tabla debe Tener un Identificador

La regla fundamental de la teoría del diseño de base de datos es que cada tabla debe tener un identificador de las filas, que es una columna o un conjunto de columnas que toman valores únicos para cada registro de la tabla. Cada tabla debe tener una columna de ID, y ningún registro puede compartir el mismo valor de ID con otro. La columna (o columnas) que sirve como identificador único de la fila para una tabla constituye la clave primaria de la tabla.

En la Figura 2.2, la tabla Empleados no incluye una columna que identifica unívocamente cada fila dentro de la tabla. Fíjese que el nombre de David Mendlen aparece dos veces. Al no haber ningún identificador único en esta tabla, no hay ninguna manera de distinguir fácilmente una fila de otra. Esta situación podría ser un problema, más aún, si ambos empleados trabajaron en la misma sección y tienen el mismo tipo de trabajo.

Usted puede normalizar la tabla agregando una columna que singularmente identifique cada fila. Fíjese que cada instancia de David Mendlen tiene un único valor de EmpID.

Una Tabla debe Guardar Datos para un Solo Tipo de Entidad
Intentar guardar demasiada información en una tabla puede afectar la administración eficaz y fiable de los datos en la tabla. 

Aunque es posible tener columnas que contienen información para el libro y su editor en la misma tabla, este diseño lleva a varios problemas. La información del editor debe agregarse y debe guardarse redundantemente para cada libro publicado por un editor dado. Esta información usa espacio extra de almacenamiento en la base de datos. Si la dirección del editor cambia, el cambio debe realizarse en todos los registros de libros de ese editor. Además, si el último libro de un editor es eliminado de la tabla Libros, la información de ese editor se pierde.

En una base de datos normalizada, se guardaría la información sobre los libros y editores en por lo menos dos tablas: una para los libros y una para los editores.

 

La información sobre el editor tiene que ser grabada sólo una vez y quedar vinculada a cada libro de ese editor. Si la información del editor cambia, debe cambiarse en sólo un lugar, y la información del editor estará allí aún cuando el editor no tenga ningún libro en la base de datos.

Una Tabla debe Evitar Columnas que acepten valores nulos

Las tablas pueden tener columnas definidas para permitir valores nulos. Un valor nulo indica que el registro no tiene valor por ese atributo. Aunque puede ser útil permitir valores nulos en casos aislados, es mejor usarlos muy poco porque ellos requieren un manejo especial con el consiguiente aumento de la complejidad de las operaciones de datos. Si tiene una tabla que tiene varias columnas que permiten valores nulos y varias de las filas tienen valores nulos en dichas columnas, debería considerar poner estas columnas en otra tabla vinculada a la tabla primaria. Guardar los datos en dos tablas separadas permite que la tabla primaria sea simple en su diseño pero a la vez mantener la capacidad de almacenar información ocasional.

Una Tabla no Debe tener Valores o Columnas Repetidas

Una tabla no debe contener una lista de valores para un pedazo específico de información. Por ejemplo, suponga que usted quiere consultar los títulos de libros y sus autores. Aunque la mayoría de los libros podrían tener sólo un autor, muchos de ellos podrían tener dos o más. Si hay sólo una columna en la tabla Libros para el nombre del autor, esta situación presenta un problema. Una solución es guardar el nombre de ambos autores en una columna, pero mostrar una lista de autores individuales sería entonces difícil. Otra solución es cambiar la estructura de la tabla para agregar otra columna para el nombre del segundo autor, pero esta solución guarda sólo dos autores. Debería agregarse otra columna si algún libro tiene tres autores.

Si usted encuentra que necesita guardar una lista de valores en una sola columna o si tiene columnas múltiples para una sola pieza de datos (Autor1, Autor2, y así sucesivamente), debe considerar poner los datos duplicados en otra tabla con un vínculo a la tabla primaria. En el caso de la tabla Libros, usted podría crear una tabla primaria adicional para los autores y luego crear una tercera tabla que vincule los libros a sus autores y almacene los valores repetidos. Este diseño habilita cualquier número de autores para un libro sin modificar la definición de la tabla y no desperdicia espacio libre para almacenar libros que tienen un solo autor.

Relaciones entre entidades

En una base de datos relacional, las relaciones entre entidades ayudan a prevenir datos redundantes. Una relación entre entidades trabaja vinculando datos de dos tablas a través de columnas clave, que generalmente tienen el mismo nombre en ambas tablas. En la mayoría de los casos, la relación entre entidades vincula la clave primaria de una tabla que proporciona a un identificador único para cada fila con una entrada en la clave foránea de la otra tabla. Se discuten claves primarias y las claves foráneas en más detalle en Tema 5, "Llevando a cabo Integridad de los Datos."

Hay tres tipos de relaciones entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de relación depende de cómo se definen las columnas relacionadas.

Relaciones entre tablas uno-a-uno

En una relación uno-a-uno, una fila en tabla A no tiene más de una fila vinculada en tabla B (y viceversa). Una referencia uno-a-uno se crea si las dos columnas relacionadas son claves primarias o tienen restricción de unicidad. Este tipo de referencia no es común, sin embargo, porque la información relacionada de esta manera normalmente estaría en una sola tabla.

Relaciones entre tablas uno-a-muchos

Una relación uno-a-muchos es el tipo más común de relación entre entidades. En este tipo de relación, una fila en la tabla A tiene muchas filas vinculadas en la tabla B, pero una fila en la tabla B tiene una única fila vinculada en la tabla A. Por ejemplo, las tablas Editores y Título mencionadas previamente tienen una relación uno-a-muchos. Cada editor produce muchos títulos, pero cada título tiene un solo editor. Una relación uno-a-muchos se crea si solo una de las columnas relacionadas es una clave primaria o tiene una restricción de unicidad.

Relación entre tablas muchos-a-muchos

En una relación muchos-a-muchos, una fila en tabla A tiene muchas filas vinculadas en tabla B (y viceversa). Se puede crear tal relación definiendo una tercera tabla, llamada tabla de unión cuya clave primaria consiste en las claves foráneas de ambas tablas A y B. En las Figuras 2.6 y 2.7, usted vio cómo la información del autor puede separarse en otra tabla. La tabla Libros y la tabla Autores tienen una relación muchos-a-muchos. Cada una de estas tablas tiene una relación uno-a-muchos con la tabla de LibrosAutores que sirve como la tabla de la unión entre las dos tablas primarias.

Resumen del tema

Una base de datos SQL Server consiste en una colección de tablas que guardan un conjunto específico de datos estructurados. Una tabla contiene una colección de filas y columnas. Cada columna en la tabla se diseña para guardar un cierto tipo de información (por ejemplo, fechas, nombres, montos, o números). El diseño lógico de la base de datos, incluyendo las tablas y las relaciones entre ellas, es el corazón de una base de datos relacional optimizada. Perfeccionar un diseño de base de datos incluye el proceso de normalización. Normalizar un diseño lógico de base de datos lógico involucra usar métodos formales para separar los datos en múltiples tablas relacionadas. A medida que la normalización aumenta, incrementa el número y la complejidad de los vínculos que son necesarios para recuperar los datos. Las reglas de normalización identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseñada. Las tablas en una base de datos normalizada deben tener un identificador, deben guardar sólo datos para un solo tipo de entidad, deben evitar columnas que acepten valores nulos, y no deben tener valores o columnas repetidos. Usted puede crear relaciones entre sus tablas en un diagrama de la base de datos y mostrar cómo se vinculan las columnas en una tabla a las columnas de otra tabla. En una base de datos relacional, las relaciones ayudan a prevenir datos redundantes. Una relación trabaja vinculando datos de las columnas, generalmente columnas clave que tienen el mismo nombre en ambas tablas. Hay tres tipos de relaciones entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de relación entre tablas depende de cómo usted define las columnas relacionadas.