Amigándonos con las Bases de Datos

Dándonos cuenta o no, todos estamos registrados en decenas de Bases de Datos: como clientes de las empresas de servicios, como abonados al cable o como socios de una prepaga. Queriéndolo o no las Bases de datos figuran en nuestras vidas desde hace años, así que será mejor que nos vayamos amigando con ellas.
Este es un sitio destinado a todos aquellos que se vean en la necesidad de saciar sus inquietudes acerca de la creación y explotación de mismas.
Quienes alguna vez han intentado diseñar correctamente una, aunque sea pequeña, y luego poder plasmarla en un software como Microsoft Access, habrán notado cuan engorroso puede ser.
La idea no es desalentar la investigación ni el autoaprendizaje, sino todo lo contrario. La intención es que todos aquellos que se encuentren perdidos en la tarea, encuentren en este lugar la posibilidad de dejar sus dudas para que otros puedan ayudarlo. Cada uno con su aporte podrá permitir en avance de todos.
Del mismo modo encontrarán novedades, trucos, ejemplos y ejercicios que les permitirá seguir mejorando los que ya hayan logrado.

Ciclo de Vida de un Sistema de Base de Datos

El desarrollo de una Base de Datos atraviesa distintas etapas. Todo este proceso recibe el nombre de Ciclo de Vida.

Este concepto de ciclo de vida tiene su origen en el que se aplica a cualquier software.  

Veamos entonces las diferencias cuando este ciclo de vida se refiere a una Base de datos.

Ciclo De Vida from Angeles Hernández Reyes

Análisis de Requerimientos

Para poder arribar con éxito a un buen diseño de Base de Datos es necesario hacer un detallado análisis de los requerimientos del sistema al cual nos enfrentamos. Pero qué implica exactamente este análisis?

* Consiste en especificar lo que se requiere que haga el sistema o la aplicación.
* Permite que las personas observen los elementos lógicos separados de los componentes físico. Después de lo cual se podrá desarrollar un modelo físico eficiente para la situación donde será utilizado.

¿Porque no analizamos requisitos al mismo tiempo que diseñamos e implementamos el sistema ?
La respuesta es que el Diseño e Implementación son mucho más que el análisis (refinamiento y estructuración de los requisitos) por lo que se requiere una separación de intereses.
– El Análisis: prepara y simplifica la siguiente actividad de diseño e implementación, delimitando los temas que deben resolverse y las decisiones que deben tomarse en esas actividades.
– En el Diseño: debemos modelar el sistema y encontrar su forma incluyendo su arquitectura: una forma que de vida a todos los requisitos incorporados en el sistema.

Es necesario recabar toda la información posible sobre la realidad, para luego analizarla con detenimiento, desde distintos puntos de vista con el fin de lograr diseñar un modelo que la represente de manera abstracta lo más fielmente posible.



Debemos efectuarnos algunas preguntas con el fin de analizar nuestro sistema:

¿Qué? ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?

Preguntas básicas y simples que nos permitirán luego realizar otras más puntuales:
* ¿Cuáles son los objetos de datos primarios que va a procesar el sistema?
* ¿Cuál es la composición de cada uno de estos objetos y qué atributos los describen?
* ¿Cuál son las relaciones entre dichos objetos?
* ¿Qué Procesos realiza nuestro sistema? ¿Cuándo se realizan? ¿Quién los hace?
* ¿Qué intercambio de información existe dentro de los componentes del sistema? ¿Y con el exterior?
* ¿Cuáles son los límites del sistema?
* ¿Existen excepciones a tener en cuenta para la realización de los procesos?
* ¿Cómo se almacena la información actualmente? ¿Qué datos se registran? ¿Quién lo hace?

De allí surgirán:

Entidades
* Abstracciones de un objeto del mundo real.
* Representación una colección de objetos que tienen propiedades comunes.
* Ejemplo: CLIENTE
Atributos
* Propiedades de una entidad
* Ejemplo: Nombre y apellido, edad, dirección, etc.
Relaciones o Flujo de datos
* Intercambio de información entre entidades
* Representan datos en movimiento lógicamente relacionados.
* Describen el movimiento de paquetes de datos de una parte del sistema a otra.
Procesos
* Una actividad, tarea, proceso, función, etc.
* Transforma entradas en salidas
Almacenes
* Colección de datos en reposo.
* archivo en disco
* datos en un fichero de papel
* Ejemplo: una FACTURA
Terminadores o Entidades Externas.
* Representan objetos con los cuales el sistema se comunica.
* Personas, agrupamientos, organizaciones
* otros sistemas de software o hardware
* Se encuentran por fuera del sistema.

El análisis de requerimientos solicita entendimiento, clasificación, organización, priorización y validación.
En todo momento debemos considerar los límites del sistema, teniendo en claro cuál es su objetivo primario ¿Qué es lo que queremos que el sistema haga? ¿Qué salidas de información queremos obtener? Sólo de esta manera se podrá diferenciar qué de toda la información recolectada debemos almacenar y cómo deberá ser el diseño que se ajuste a ella.

Consejos para un buen diseño de Base de Datos

Diseñar una base de datos no es algo sencillo y sí muy importante, ya que un mal diseño trae dificultades para desarrollar la aplicación o bien, una aplicación compleja.
Para facilitar esa tarea, aquí van algunos consejos:
• Entender el flujo de los datos: Antes de sentarse a diseñar, es importante entender cómo fluye la información: cómo se relacionan los datos entre sí, cuáles son las salidas que se quieren obtener, cómo se llega a esos resultados, que datos deberán ser cargados, etc. La idea es entender al sistema. Aunque no esté informatizado, poder hacer un seguimiento manual

• Dibujar un esquema: Aunque sea aburrido y parezca innecesario, tomarse unos minutos y plasmar en papel las ideas de cómo organizar la información, más que hacernos perder tiempo, créanme les ahorrará muchos problemas futuros.
• Nombres significativos: los nombres deben significar algo, debe ser sencillo de comprender a simple vista, no solo por si la base va a ser compartida por varios diseñadores, sino para uno mismo. Del mismo modo, la nomenclatura debiera ser constante en todo el diseño para que cuando queramos modificarla pasado un tiempo nos sea más fácil entender lo realizado.
• Desagrupar: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor abarcarlo todo en una única tabla.
• Repetición de datos: Básicamente, las reglas de Normalización están encaminadas a eliminar redundancias e inconsistencias de dependencia en el diseño de las tablas. La mínima redundancia aceptable en un buen diseño es la repetición de los campos clave, necesario para establecer las relaciones entre las tablas
• Evitar campos calculados: Cualquier dato que sea posible obtenerlo a partir de otros ya almacenados, no debiera ser registrado. Es otra forma de redundancia.
• Colocar campos claves: Si bien no es obligatorio que todas las tablas la posean, asignar una clave primaria a una tabla evita repetición de registros, facilita la localización de los mismos y permite la relación de esta tabla con las otras.
• Pensar en las relaciones: Al momento de diseñar una tabla es importante contemplar con qué otras tablas se relacionará y qué tipo de relación tendrá (1:1; 1:N; N:N) y adaptar el diseño según sea el caso.
• Relaciones N:N: Este tipo de relación es muy frecuente de encontrar a la hora de diseñar. Debido a que el Access no la soporta, se deberá tener en cuenta que siempre habrá que generar una tabla que permita la unión entre ambas. En ésta, será necesario llevar al menos, los campos claves de aquellas que se quieren relacionar (teniendo en cuenta que la clave de esta tabla unión será, con seguridad, múltiple)
• Proteger la integridad de los datos: La integridad en los datos almacenados hará tener confianza en la información brindada por esta. Para esto, hay que tener en cuenta las reglas de campos nulos, tipos de datos y tamaños de los campos para poder definir integridad de la información.
• Probar el diseño: Una vez realizado el diseño en la Base de Datos, es necesario probarlo, para ello es recomendable cargar un amplio espectro de registros, verificando que se contemplen todas las posibilidades futuras (las que debiera aceptar la base y las que no debiera, para comprobar como responde en cada caso)

Normalización

El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Disminuir problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

Este proceso se basa en la transformación o adaptación de las tablas del Modelo Relacional a las llamadas "formas normales".

Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.

En la siguiente tabla se describe brevemente en que consiste cada una de las reglas, que posteriormente se explican con más detalle.

Regla	Descripción
Primera Forma Normal (1FN)	Incluye la eliminación de todos los grupos repetidos.
Segunda Forma Normal (2FN)	Asegura que todas las columnas que no son clave sean  dependientes de la clave principal completa.
Tercera Forma Normal (3FN)	Elimina cualquier dependencia transitiva. Una dependencia transitiva es aquella en la cual las columnas que no son clave son dependientes de otras columnas que tampoco lo son.

Transformación del Modelo E-R al Modelo Relacional

Como segundo paso, luego de haber logrado establecer el Modelo E-R, es preciso transformarlo al Modelo Relacional.

Si bien no es una actividad compleja, tiene ciertos aspectos que deben ser tenidos en cuenta.

Para ayudar a su comprensión veamos este tutorial.

Y este ejemplo