Curso de Introducción a SQL Server 2005

Para aquellas personas que han trabajado con desarrollo de software, entenderán que la planificación de un programa en uno de los aspectos más importantes para un buen programa.

Cuando vamos a comenzar a crear una base de datos, el principio de todo no es arrancar nuestra herramienta de SQL Server 2005, Management Studio, y mediante sus asistentes ponernos directamente a crear nuestra base de datos, con sus tablas, etc...

Siempre debemos comenzar realizando un análisis de las necesidades que tenemos. Una vez que conocemos las necesidades y partiendo de estas, definimos la estructura lógica de nuestra base de datos, y por último pasamos a diseñarla, bien sea en papel, o mediante las herramientas de diseño que nos ofrece SQL Server 2005.

Por lo tanto tenemos diferenciados claramente tres pasos previos a la hora de planificar la creación de una base de datos:

• Estudio y análisis de las necesidades.
• Definición de los elementos que componen las estructura lógica de la base de datos.
• Diseñar o plasmar esa estructura con diagramas en papel, o con SQL Server 2005.

Estos pasos son importantísimos, en este tipo de desarrollos no podemos utilizar el método de ir probando estructuras hasta que funcionen, y una vez que funciona dar por sentado, que nuestra base de datos está bien diseñada y ya podemos instalarla en un servidor para que se comience a trabajar con ella.

La planificación debe prevenirnos de imprevistos que pueden surgir, y ya no sólo imprevistos del tipo que si tenemos mayor o menor actividad en la base de datos, hablamos de imprevistos que provocan que tengamos que rediseñar nuestras estructuras. Una vez que tenemos la base de datos en explotación, nos encontraremos con el problema de que será muy difícil realizar modificaciones sobre ella, ya que el método de trabajo que marcamos al definir nuestras estructuras, limita las posibles modificaciones futuras.

Con esto puedes hacerte una idea de lo que supone la planificación, invertir tiempo en estos primeros pasos, significa ahorrarnos tiempo en un futuro de posibles modificaciones.

Como hemos dicho, se trata del primer paso que debemos analizar.

En este paso, tendremos que estudiar detenidamente que tipo de necesidad tiene nuestro cliente. Serán necesarias tantas reuniones como creamos oportunas para que el cliente nos explique cual es la información desea almacenar en nuestra base de datos. Una vez tenemos claro la información fundamental para el trabajo cotidiano de la empresa de nuestro cliente, tendremos que tener pleno conocimiento, de que trabajo quiere hacer con esa información, es decir ¿Cuáles son los resultados que va a requerir de esa información?.

Una vez, que tenemos todo lo necesario para conocer que necesidades tenemos que cubrir con nuestra base de datos, procedemos a identificar todos los objetos que necesitamos, con sus atributos y propiedades, y también como estarán relacionados unos con otros. Estos objetos se convertirán más adelante en tablas, vistas, índices, procedimientos almacenados, etc...

Es lógico penar que estos objetos que hemos planificados no serán los definitivos ni mucho menos, durante la etapa de diseño y normalización que explicaremos más adelante nos irán surgiendo nuestras propias necesidades para cumplir con los objetivos que nos hemos marcado con nuestro cliente, o los encargados de informarnos en la empresa que estamos contratados.

Lo que si debe ser definitivo (en la medida de lo posible) son los elementos que integran la base de datos, las entidades de información que debemos almacenar. Deberemos identificar estos elementos, de modo que podamos distinguir fácilmente unos de otros. Y más adelante, durante la planificación iremos encontrando las relaciones y dependencias que tienen unos con otros. Para entender mejor esta definición vamos a poner un ejemplo.

Vamos a suponer que tenemos como cliente a una empresa que se dedica a la venta de refrescos.

El primer paso es definir las necesidades que surgen de estudiar el funcionamiento de esta empresa. Por lo tanto comenzamos describiendo el funcionamiento de la empresa.

Nuestra empresa se dedica principalmente a la venta de bebidas, estas bebidas las producen las fabricante y las recibimos de estas a través de unas distribuidoras a las que previamente habremos realizado unos pedidos.

Una vez que hemos recibido los pedidos, estos permanecen en nuestro almacén, para que podamos realizar las ventas a nuestros clientes.

Está claro que una empresa de bebidas tiene un funcionamiento mucho más complejo que lo que acabamos de definir, pero para el objetivo que buscamos, nos es suficiente.

Hemos subrayado las entidades de información que han ido surgiendo en la descripción de las necesidades de la empresa que hemos tomado como ejemplo. Todas estas entidades forman un conjunto de entidades, como puedes ver en la siguiente figura:

Una vez que tenemos descrita y definida la información de la etapa de análisis de necesidades y de las indicaciones del trabajo que se desea realizar sobre esas entidades marcadas, comenzamos con la etapa de planificación de la base de datos.

La etapa de planificación tiene el objetivo de definir las diferentes propiedades de cada entidad y analizar que relaciones serán necesarias entre ellas o con más elementos o entidades.

A primera vista, parece claro que cada una de las entidades de nuestro conjunto puede ser representada en una tabla en nuestra base de datos final.

Las propiedades de cada una de estas tablas, no son otra cosa que las columnas o campos que la van a formar. Es decir, los datos que nos interesa almacenar para las bebidas, pedidos, clientes, fabricantes etc...

Otra característica a definir en esta etapa son las dependencias que tendrán las tablas. ¿A qué cliente estamos realizando una venta? ¿Que fabricante a producido una determinada bebida?.

Una vez realizado este estudio, continuamos con un proceso de normalización, el cual modificará el número de entidades o tablas, de tal manera que puede aumentar el número de tablas pero disminuir la cantidad de información que almacena en cada una. Este proceso de normalización es de vital importancia, y lo estudiaremos con detenimiento en este mismo capítulo.

Partiendo de las entidades que hemos definido en nuestro conjunto como resultado del estudio de necesidades, vamos a analizar las propiedades de cada una de estas entidades.

Comenzamos con la más lógica, Bebidas. ¿Cuáles podrían ser las propiedades fundamentales? Piensa por ejemplo que dato te interesaría para realizar una búsqueda: el nombre de la bebida, y el fabricante.

También necesitaremos saber que distribuidora nos ha entregado esa bebida. Estas propiedades o campos y los anteriores, son los esenciales para cada bebida, por último podremos añadir otros campos que nos interesen, precio, el envase, cantidad, fecha de caducidad, si es alcohólica o no, en caso de ser alcohólica los grados y el número de lote.

Con estas propiedades ya podemos definir las columnas o campos de nuestra tabla Bebidas.

Del mismo modo podemos ir definiendo las propiedades del resto de las tablas que representan nuestras entidades en la base de datos:

Todas estas propiedades definidas para cada tabla, son de carácter temporal y no son definitivas, veremos como en el proceso de normalización, tendremos que realizar modificaciones como ya hemos comentado.

Hemos visto como las tablas formaban un conjunto de entidades. Nunca debes pensar en una tabla como un elemento aislado, cada una de las tablas forma parte de nuestro conjunto, y el conjunto vendría a ser la base de datos. Por lo tanto, cada tabla es la parte de un nivel superior y no puede ser tratada individualmente, ya que como parte de un todo, tendrá dependencias con el resto de tablas de la base de datos.

Ese es precisamente el trabajo que debemos llevar a cabo ahora, analizar las dependencias que tiene cada tabla con el resto para poder representarla la estructura lógica de la base de datos.

Estas dependencias reciben el nombre de relaciones, y estudiaremos que tipo de relaciones podemos tener, de momento, para nuestro ejemplo las veremos de un modo muy sencillo. Podemos encontrarnos tablas que dependen únicamente de una segunda tabla, mientras que habrá otras que dependerán de varias. Otro caso que nos podemos encontrar son tablas que tienen una relación única, como iremos viendo.

Cojamos el ejemplo de la tablas Bebidas y Distribuidoras, estas tablas tendrán una relación entre ellas de "uno a muchos". La razón de porque tendrán esta relación y porque recibe esa descripción de "uno a muchos" es la siguiente. Esta claro, que en la tabla distribuidoras almacenamos los datos de cada una de las distribuidoras que tenemos, y que lógicamente una distribuidora, aparecerá sólo una vez en esta tabla, es absurdo tener repetida la misma información. En cambio, si vamos a la tabla bebidas, donde almacenamos cada bebida, sabemos que una distribuidora no nos entregará una única bebida, sino varias. Por lo tanto, tendremos varias bebidas que han sido entregadas por la misma distribuidora.

Resumiendo, una distribuidora sólo aparece una vez en la tabla distribuidoras, mientras que en la tabla bebidas aparecerá muchas veces (no sabemos cuantas). Por eso afirmamos que la relación entre estas tablas es de una (bebidas) a muchas (distribuidora). Si representamos de modo gráfico esta relación podría ser como ves en la siguiente figura:

Tomemos ahora como ejemplo la relación entre las tablas Bebidas y Almacén.

La dependencia entre estas tablas es una relación "uno a uno", el motivo es el siguiente. Cada una de las bebidas que tenemos en nuestra tabla bebidas, tiene una situación determinada en el almacén, por lo tanto, existirán las mismas filas en la tabla almacén como tenemos en la tabla bebidas. Así pues a un registro de la tabla bebida le corresponde un registro en la tabla almacén. De ahí la definición de relación uno a uno.

Podemos representar esta relación gráficamente de la siguiente forma:

Si continuamos con el mismo estudio de dependencias con el resto de la tabla de nuestra base de datos, veremos que la tabla ventas depende de los clientes con relación uno a muchos y a su vez depende de la tabla bebidas, y la tabla almacén teniendo dependencias de varias tablas. Si representamos todas estas relaciones tendremos:

Estudia con detenimiento la figura anterior, y trata de entender las dependencias que hemos representado, y el motivo de estas relaciones a partir de los ejemplos de relaciones uno a uno y uno a mucho que hemos descrito anteriormente.