Curso de Introducción a SQL Server 2008

La normalización es el mecanismo de toma de decisiones con el objetivo de recoger todos los datos de la información que se almacenará en una base de datos y distribuirlos en tablas.

Para tomar estas decisiones tenemos un número de formas normales que nos ayudará a diseñar la mejor estructura lógica con el mayor rendimiento posible.

Las formas normales, son los modelos o maneras en que se pueden representar la estructura de tablas. Gracias a estos modelos conseguiremos mayor eficacia. Pero no entiendas por eficacia como una reducción del tamaño, nos estamos refiriendo a que obtendremos una estructura muy bien organizada, de tal modo que será escalable fácilmente, permitiendo realizar modificaciones en un futuro sin muchos problemas. Aunque habrá veces donde gracias a la normalización también se reduzca el tamaño, este no es el objetivo que buscamos.

La función de la normalización es favorecer la integridad de los datos, sin importar la actividad que se desarrolle sobre la base de datos. Trata de evitar lo máximo posible la posibilidad de introducir datos que no sean razonables. Dentro del proceso de normalización podemos distinguir cuatro tipo de integridades:

• Integridad de entidad.
• Integridad de dominio.
• Integridad referencial.
• Integridad definida por el usuario.

Vamos a explicar cada una de estas integridades y al final de cada una nombraremos que herramientas nos ofrece SQL Server 2008 para cumplir con estas integridades, si desconoces estas herramientas, tranquilo porque las veremos con más detenimiento en las siguientes lecciones, tan sólo que te suene para cuando lleguemos a verlas con más detenimiento.

Hasta ahora hemos utilizado en varias ocasiones la palabra entidad. Una entidad se define como un concepto del mundo real, de modo que nuestras bases de datos guardan información sobre entidades. Estas entidades puede ser de diferente carácter:

• Entidades físicas: un libro, una bebida, un empleado
• Entidades conceptuales: una empresa
• Entidades como eventos: una alerta de nuestra agenda que nos recuerda una tarea.

Uno de los pasos de nuestro proceso de planificación es detectar estas entidades que están relacionadas con la base de datos.

La integridad de entidad pretende que cada entidad que se guarda en la base de datos sea identificable de un modo único, es decir, que evitemos la información redundante.

Ahora bien, la identificación de entidades no es única, podemos tener varios modos de entidad para un mismo objeto real. Por ejemplo, seguimos con el ejemplo de nuestra empresa dedicada a la venta de bebidas, podríamos identificar las bebidas de un modo general, a un modo más individual:

• Todas las bebidas en un sólo grupo.
• Todas las bebidas de la misma marca en un grupo.
• Agrupar las bebidas en función de si son alcohólicas o no.
• Cada bebida de modo individual.
• Un hecho sobre una determinada bebida, como puede ser el sabor de un refresco.

¿Qué criterio debemos seguir entonces para identificar que es una entidad en nuestra base de datos?

La respuesta a esta pregunta dependerá de lo que deseemos hacer con estos datos. Lo más razonable es que se identifique como entidad aquellas cosas con las que vas a trabajar de modo unitario. Dicho de un modo más claro, la información que se almacena unida (de modo unitario) es más cómodo trabajar con ella, o recuperar esa información en una única operación.

Para tomar estas decisiones, simplemente debes realizarte las preguntas de la función que deseas realizar sobre los datos. Por ejemplo, ¿Cuántas bebidas tenemos de un determinado fabricante?, se puede decir que nuestra entidad será todas las bebidas que provienen de un determinado fabricante.

En cambio, si nos realizamos preguntas como ¿En que fecha llegó al almacén una determinada bebida? Estamos requiriendo que le entidad sea cada bebida de modo individual.

Con las entidades ya identificadas, ahora debemos identificar los hechos que nos dan la descripción de cada entidad, en el ejemplo de las bebidas ya los hemos descrito, ya que estamos hablando de los campos:

• nombre
• fabricante
• distribuidora
• ...

Como siguiente paso, tenemos que identificar la entidad o grupo de entidades que en cierta medida, comparten este grupo de hechos que acabamos de describir. Para nuestro ejemplo está claro que sería las bebidas que vendemos en la empresa.

Una vez vistos estos pasaos de la integridad de entidad, veamos cómo se relacionan o se representan en una base de datos:

• Una entidad se representa como el registro de una tabla.
• Un hecho (como ya hemos dicho) sería el campo o columna de la tabla.
• Un grupo de entidades que comparten unos hechos, representaría una tabla.
• Y como es lógico, la tabla está formada por la cuadricula que se crea al unir las entidades con los hechos, por lo que cada entidad tiene un valor para cada hecho determinado.
• El conjunto de todos estos valores, representa todo lo que podemos saber de una entidad.

Presta atención a lo que vamos a explicar a continuación, es muy importante. Cada entidad almacenada debe tener una clave principal. Una clave principal es un hecho, o grupo de hechos, que distinguen esa entidad del resto de entidades que comparten unos mismos hechos. Bueno, visto así puede parecer un poco complicado, simplemente estamos explicando que cada registro de una tabla, debe tener un campo que identifique de modo exclusivo ese registro respecto al resto de registros de esa tabla.

Para el ejemplo de nuestra empresa de bebidas, los fabricantes que producen las bebidas que acaban en nuestro almacén, pueden ser muchísimas empresas, para identificar cada empresa del resto, tenemos el NIF de la empresa, sabemos que ese código es único y exclusivo para cada empresa y que no estará repetido en ninguna otra. Pues perfectamente el NIF sería nuestra clave principal. En caso de no encontrar un hecho o campo que pueda ser clave principal, lo que demos hacer nosotros es crear un código que identifique exclusivamente cada registro. En caso de vernos obligados a añadir nosotros mismos un campo que haga las funciones de clave principal, estamos utilizando lo que se denomina una clave principal suplente. Mientras que si utilizamos un campo que ya existe como un hecho de la entidad, se denomina clave principal natural.

Otra posibilidad, es utilizar claves principales compuestas, estas claves principales son el resultado de unir dos columnas de nuestra tabla para formar una clave principal.

Para elegir una clave principal debemos valorar tanto los datos actuales como los datos futuros, ya que podemos seleccionar una columna como clave principal, porque actualmente nos sirve como tal ya que identifica cada registro, pero en un futuro pueden añadirse valores que se repiten para ese campo, siendo necesario utilizar otra columna como clave principal, o crear una compuesta.

Es de una gran importancia que definamos correctamente cada registro, ya que es la principal "herramienta" de la que se sirve el servidor de base de datos, para seleccionar la información que necesitamos. Mediante una clave principal el servidor conoce con qué información queremos trabajar en cada momento. En caso de cometer errores y no tener claves principales que identifique de manera única cada entidad, tendríamos problemas con registros repetidos, ya que el servidor no sabría a que registro o entidad nos estamos refiriendo en nuestra actividad,  y nos lanzaría continuas excepciones.

Con las claves principales identificadas, SQL Server nos ofrece unas características que nos ayudan a forzar la integridad de entidad:

• Introducir índices únicos en un campo para evitar la duplicación de datos por parte de los usuarios.
• Restricciones PRIMARY KEY o UNIQUE KEY
• Propiedad Identidad.

Todas estas características las iremos viendo más adelante.

Ya hemos visto que la integridad de identidad permite obtener los datos almacenados en una base de datos. Con la integridad de dominio conseguimos controlar la información que guardamos en la base de datos. Como dominio, podemos entender como un conjunto de normas de negocio que gestionan la disponibilidad de datos en una determinada columna de una tabla. Por ejemplo que sólo podamos introducir nombres de fabricantes validados por un dominio de valores.

Tenemos una integridad de dominio básica, como no poder introducir letras en campos destinados para almacenar números. A mayor número de limitaciones, mejor aseguraremos el correcto funcionamiento de nuestra base de datos.

Estas normas o reglas de integridad de dominio pueden indicar que campos son necesarios tener obligatoriamente con valores (no se pueden dejar vacíos, NULL) para que la base de datos no tenga datos sin conectar en el caso de tener relaciones o dependencias entre tablas.

Las herramientas que nos ofrece SQL Server para asegurar la integridad de dominio y que iremos estudiando son:

• Tipos de datos
• Tipos de datos definidos por el usuario.
• Restricciones:
• CHECK
• DEFAULT
• FOREIGN KEY
• Reglas
• NOT NULL

Para ver este tipo de integridad tienes que pensar en las dependencias de tablas que hemos visto en la base de datos que hemos puesto como ejemplo de la empresa de venta de bebidas.

Hemos visto por ejemplo que para cada registro de la tabla Bebidas, teníamos un registro en la tabla Almacén. Y otro tipo de dependencias o relaciones que habíamos denominado relaciones "uno a muchos".

Estas relaciones se producen entre columnas comunes de las tablas que se relacionan. Como pude ser el nombre de una bebida, el de una distribuidora etc...

Con la integridad referencial tratamos de asegurar que las filas relacionadas entre tablas, no dejen de estarlo, o varíen esta relación cuando llevemos modificaciones a los datos. Con esta integridad limitaremos la actividad que puede realiza un usuario sobre la base de datos.

Vamos a ponernos en un ejemplo sencillo, nuestra tabla bebidas tiene una columna llamada "Distribuidoras", que se relaciona con nuestra tabla "Distribuidora" mediante esta misma columna. Ya hemos comentado este tipo de dependencia en este mismo tema. Llevando a cabo una integridad referencial, limitaremos las siguientes tareas a un usuario:

• El usuario no podrá cambiar el nombre de una distribuidora en una de las tablas, ya que si así lo hace, este valor no será el mismo en las dos tablas, y provoca que la relación quede rota. Un registro o varios (dependiendo de en que tabla realice esa modificación) se quedará sin su pareja y no podrá encontrar la relación.
• No podrá eliminar registros de la tabla distribuidora que se encuentren en la tabla Bebidas. Ya que todos aquellos registros de la tabla Bebidas que estuviesen vinculados a la Distribuidora eliminada se quedarán sin relación.
• No puede añadir registros nuevos en la tabla bebida cuyo campo Distribuidora no coincida con ninguna de las distribuidoras añadidos en la tabla Distribuidoras.

Por lo tanto, lo que debemos comprender de la integridad referencial es que existen relaciones entre tablas que deben permanecer invariables sea cual sea la actividad sobre ellas.

Para mantener esta integridad SQL Server nos ofrece:

• Restricciones FOREIGN KEY.
• Restricciones CHECK.
• Desencadenadores y procedimientos almacenados.

Las tres integridades que acabamos de ver, están todas integradas en las bases de datos. Además no son exclusivas para SQL Server 2008, sino que las encontrarás en cualquier base de datos. Si bien puede que no estén completamente integradas y funcionales, son compatibles en cualquier ámbito.

La integridad que vamos a ver en este apartado, recoge todas las reglas que no están incluidas en ninguna de las integridades anteriores.

Un ejemplo de este tipo de integridad de usuario, sería obligar a que una determinada bebida siempre tenga dos tipos de envases. Este tipo de integridad no la cubre ni la de entidad, ni de dominio, ni referencial. Únicamente podemos controlarla mediante procedimientos almacenados, desencadenadores o reglas que se almacenen en la base de datos.

Esta integridad puede ser controlada también desde los programas clientes que conectan a la base de datos. Mediante el código de programación estos programas pueden comprobar antes de enviar los datos al servidor, si estos cumplen con un determinado juego de normas. De este modo el usuario estará limitado al utilizar el interface del programa, recibiendo los pertinentes avisos del modo de introducir los datos.

Ahora bien, aunque es completamente válido implementar esta integridad en el programa de cliente, lo más eficaz es colocarlo en el servidor, en la propia base de datos. Ya que no sabemos ni el número ni el tipo de programas que se conectará a la base de datos, y nosotros como desarrolladores tendríamos que incluir este tipo de restricciones en cada uno de los programas desarrollados, a parte del peligro que supondría aquellos programas clientes, que nuestra empresa a adquirido y a los que no tenemos acceso para modificar e incluir estas reglas.

Las formas normales definen una serie de normas o reglas que ayudan a organizar los datos en la estructura lógica de una base de datos.

Cada una de las formas que vamos a ir explicando heredan las reglas de su antecesora, así la forma normal C, incluye las reglas de las formas A y B. Para entender desde un sentido practico los diferentes modos de normalización, vamos a tomar como ejemplo la base de datos de la empresa vendedora de bebidas.

Recordamos la tabla Bebidas de esta base de datos:

Vamos a suponer que tenemos esta tabla con los siguientes datos:

Debes tener claro que esta tabla contiene los datos sin ser normalizados, si bien son los datos que deseamos gestionar. A continuación, nos basaremos en esta tabla para ver como aplicar sobre ella el proceso de normalización. Por supuesto, sólo es una tabla de prueba, los campos que en un caso deberíamos controlar serían muchos más.

Twitter Meneame Delicious Technorati Digg Facebook