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)