ACCESS TUTOR PERSONAL

 

PLANIFICACION Y DISEÑO DE UNA BASE DE DATOS

 

 

I . Planificación de la Base de datos

 

Cuando se tiene que construir una base de datos, existe la tentación de sentarse inmediatamente en la computadora, arrancar el Gestor de Bases de Datos, y empezar a crear tablas. Bien, esto no hay que hacer. Hay un proceso que es imprescindible seguir para desarrollar una base de datos relacional bien diseñada y, al principio, hay un camino largo a recorrer antes de crear las tablas de la aplicación. No será necesariamente un largo camino en cuanto a tiempo, sino ciertamente en pensamiento.
Un enfoque sistemático del diseño ayudará mucho al diseñador, le ahorrará mucho tiempo y se acercará mucho más a lo que el cliente realmente necesita. En este tema, se describirán los pasos a seguir en un proceso de diseño.

A la hora de redactar tablas y campos, hay que utilizar una muy baja tecnología en el proceso de diseño: lápiz y papel. Habrá muchas lagunas a rellenar en esta parte del proceso de diseño. Cuando uno comienza a construir sus propias bases de datos , puedes perteneces a esa la clase de personas que no puede pensar a menos que vea una pantalla de computadora, en cuyo caso hay instrumentos de software disponibles para modelar una base de datos. Estos instrumentos (ingeniería de software automatizada) pueden ser usados para crear diagramas o para crear la documentación del diseño; pueden ser útiles en particular cuando un equipo trabaja sobre el diseño de una base de datos. Además, algunas de estas herramientas pueden generar comandos que crearán realmente las tablas en la Base de Datos.

La idea es dibujar un diagrama de las tablas y campos y como los datos están relacionados. Esto es lo que se llaman generalmente relación de entidad, ER, o diagramas de E/R. Hay varios sistemas formales para crear estos diagramas que usan un juego específico de símbolos para representar ciertos objetos y tipos de relaciones. En este punto de su carrera en el diseño, sería bueno disponer de cualquier cosa que ahorre trabajo. Además, un sistema formal se hace más necesario cuando un grupo de la gente trabaja sobre el mismo diseño. Además, la utilización de un método estandarizado es provechoso para documentar su diseño para aquellos que vengan detrás.

 

 

 

El Proceso de Diseño

  1. Identificar el objetivo de la base de datos.
  2. Revisar la base de datos existente, si la hay.
  3. Hacer una lista preliminar de campos.
  4. Hacer una lista preliminar de tablas y colocar en ellas los campos.
  5. Identificar los campos claves.
  6. Redactar las relaciones entre las tablas.
  7. Entrar datos de muestra y normalizar los datos.
  8. Revisión y fin del diseño.

Después de un proceso de diseño simplemente hay que asegurarse que se tiene la información necesaria para crear la base de datos y que cumple con los principios de una base de datos relacional. En este tema, utilizando el  proceso descrito , se podrá  llegar al punto de haber diseñado bien tablas y relaciones, y entender como se extraerán los datos de las tablas. A partir de aquí, el diseñador ya puede empezar a crear el resto de los objetos, consultas, formularios, informes, etc

En este tema, se examinará el perfil del proceso. Eres el diseñador de base de datos y la información contenida representa al cliente (la persona que ha expresado la necesidad de una base de datos).

¿Por dónde empezar?

  1. Identificar el objetivo de la base de datos.

Muy raramente se recibe una especificación detallada para la base de datos. El deseo de una base de datos es por lo general expresado al principio como cosas que el cliente quiere que haga. Cosas como:

Esto sera toda la información recibida por lo general para clarificar el alcance de la base de datos solicitada. Hay que recordar que una base de datos sostiene la información relacionada. Si el cliente quiere el catálogo de producto en Web e información de ventas y de empleados y datos sobre competidores, tal vez se esté hablando de más de una base de datos. Esto implica la necesidad de comprender igualmente del alcance del proyecto y los resultados esperados (preferentemente por orden de la importancia). Puede ser provechoso escribir una declaración del objetivo para la base de datos y las partes que puedan desprenderse. Algo como: "la base de datos de Ventas almacenará la información sobre clientes, ventas, y detalle de las ventas. Se utilizara la entrada de ventas y mensualmente se hará un informe de ventas." Una declaración como esta puede ayudar a definir los límites de la información que la base de datos contendrá.

 

 

 

Las primeras etapas del diseño de base de datos son una fase intensiva de trato personal, y la comunicación clara y explícita es esencial. El proceso no son pasos aislados, sino iterativo. Es decir, se tendrá que acudir al cliente para aclaración e información adicional cada vez con mas intensidad a medida que se avance en el proceso. Tal como avancen los progresos de diseño, también deberá conseguirse la confirmación que se está en el buen camino y que todos los datos necesarios están contemplados.

Si no se conoce todo esto en las primeras fases del desarrollo de la aplicación, habrá que hacerlo mas tarde o mas temprano, ya que siempre hay unas reglas que el cliente debe seguir y que el diseñador debe implantar en la base de datos. Por ejemplo, se requiere conocer si un campo puede contener solo valores numéricos o combinado con valores de texto, o si tendrá ceros al principio del campo, si se requiere siempre que contenga datos, etc.. Las reglas que precise el cliente pueden determinar también la estructura y las relaciones entre tablas. También, será difícil determinar que valores son únicos y como se relacionan unas tablas con otras si no se entiende el sentido de los datos.

 

2. Revisión datos existentes.

Una gran herramienta para iniciar una aplicación es ver documetación sobre los datos existentes . Hojas de cálculo, albaranes, facturas, documentación en general.

Una forma que ayuda mucho en la primera parte del desarrollo es mirar las necesidades del cliente, iniciando por el final. Por ejemplo, si analizamos un informe de ventas que nos proporcione el cliente podemos ver mucha información, incluso la forma de relacionar las tablas. Sabremos tambien si estos datos hay que agruparlos, por ejemplo, por vendedor o por población. Esto nos ayudará a saber qué campos y tablas necesitaremos para conseguir el objetivo final que se muestra en el informe del cliente.

Cuanta más información se pueda recabar, más fácil será dar los primeros pasos y acercarse desde el principio al diseño más correcto posible. Para evitar un trabajo suplementario y correcciones innecesarias, hazlo bien la primera vez.

 

3. Hacer una lista preliminar de campos.

Con todo lo que se ha aprendido de la documentación obtenida conviene hacer una lista preliminar de los campos de datos para ser incluidos en la base de datos. Hay que tener en cuenta que normalmente los clientes para una base de datos expresan su necesidad de información, pero es trabajo del diseñador  pensar en que datos son necesarios para entregar aquella información.

 

 

Cada campo debería ser atómico; este significa que cada uno debería sostener el valor significativo más pequeño y, por lo tanto, no debería contener múltiples valores. El incumplimiento más común de esta regla es almacenar el nombre de una persona y el apellido en el mismo campo.

No conviene nunca guardar campos calculados sobre los datos de otros campos, ya que si cambian los que lo originan pueden producirse errores si no se vigila estrechamente esta incidencia.

Para continuar …

El resto de los pasos en el proceso de diseño será dirigido en temas subsecuentes. Como son:

  1. Hacer una lista preliminar de tablas y sus campos.
  2. Identificar los campos claves.
  3. Redactar las relaciones de las tablas.
  4. Entrar datos de muestra y normalizar los datos.
  5. Revisión y finalización del diseño.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

II . Diseñar buenas Bases de Datos

 

Las bases de datos tienen la reputación de ser difíciles de construir y complicadas de mantener. El potencial del software de base de datos actual hace posible crear una base de datos con unos cuantos clicks de ratón. Sin embargo, las bases de datos creadas por este camino son las que resultan difíciles de mantener y de trabajar con porque suelen estar mal diseñadas. El software actual hace fácil construir una base de datos, pero no ayuda mucho respecto de diseño de la creación de base de datos.


El diseño de una base de datos no tiene nada que ver con la utilización de computadoras. Hay que hacerlo a través de investigación y planificación. El proceso de diseño debería ser completamente independiente de las opciones de software. Los elementos básicos del proceso de diseño son:

  1. La definición del problema u objetivo
  2. La investigación de la base de datos existente
  3. Diseño de las estructuras de datos
  4. Construcción de relaciones
  5. Aplicación de reglas y restricciones
  6. Creación de vistas e informes
  7. Realización del diseño

Notese que la realización del diseño de base de datos en el software es el paso final. Todos los pasos precedentes son completamente independientes de cualquier software u otras preocupaciones de realización.

La definición del problema u objetivo. El paso más importante en el diseño de base de datos es el primero: la definición del problema marcará el objetivo de la base de datos. Es importante sin embargo, distinguir entre:

El primer paso del diseño de base de datos debe delimitar claramente la naturaleza de los datos que tienen que ser almacenados, no las preguntas que convertirán los datos en información.

Este puede parecer un poco contradictorio al principio, ya que el objetivo de una base de datos es proporcionar la información apropiada para responder preguntas. Sin embargo, el problema con el diseño de bases de datos para responder preguntas específicas o puntuales es que invariablemente las preguntas acaban excluyéndose, se cambian con el tiempo, o hasta se reemplazan por otras.

Cuando esto sucede, que una base de datos se diseñó únicamente para contestar las preguntas originales se convierte en inútil. Por el contrario, si la base de datos está diseñada recopilando toda la información de cada un individuo o la organización dirigidas hacia un problema u objetivo concreto, la información para contestar cualquier pregunta u objetivo planteados puede ser teóricamente canalizada.

 

 

 

La investigación de la base de datos existente. En la mayor parte de situaciones de diseño de base de datos, hay algún tipo de base de datos ya existente. Tal base de datos puede consistir en PostIts, albaranes de pedidos en papel, una hoja de cálculo de datos de ventas, un archivo de procesador de texto de nombres y direcciones, o una base de datos hecha y derecha digital (posiblemente en un paquete de software anticuado o sistema de herencia más viejo). Sin tener en cuenta su formato, esto proporciona una información esencial: los datos que la organización actualmente encuentra útil. Este es un punto de partida excelente para determinar la estructura de datos esencial de la base de datos. La información de base de datos existente puede proporcionar también el núcleo para el contenido de la nueva base de datos.

Diseño de las estructuras de datos. Puesto que una base de datos es esencialmente una colección de tablas de datos, el siguiente paso en el proceso de diseño debe ser identificar y describir las estructuras de los datos. Cada tabla en una base de datos debería representar algún objeto distinto sustancial o físico. Entonces parece razonable analizar simplemente los asuntos u objetos físicos relevantes al objetivo de la base de datos, para luego hacer una lista de tablas.

Este puede dar buenos resultados, pero es mucho mejor analizar objetivamente los campos actuales identificados como esenciales en su investigación y ver que agrupaciones lógicas sugieren. En muchos casos, estructuras que parecen distintas son realmente variaciones subyacentes del mismo sujeto. En otros casos, efectivamente son distintas. Y para complicar el asunto, las organizaciones pueden usar los mismos términos para describir datos que usan o agrupan de modos fundamentalmente distintos.

Una vez que las tablas han sido determinadas y los campos han sido adjudicados a cada una, el siguiente paso debe desarrollar las especificaciones para cada campo. El campo perfecto debería ser atómico: debería ser único en todas las tablas de la base de datos (a menos que  utilice como una clave) y contener un valor unico, y no debería ser posible dividirlo en componentes más pequeños. Este es también el momento apropiado para comenzar a pensar en el tipo de datos de cada campo. Esta información debería estar bastante clara de la fase de investigación del proyecto, pero a veces las preguntas permanecen. Se suele avanzar en el planning y arreglar estos terminos con posterioridad, como la identificación del tipo de campos y el examen (o reexamen) de los datos existentes que se han reunido. ¡Es mucho más fácil y más barato fijar esto ahora que esperar hasta que la base de datos esté siendo utilizada!

Construcción de relaciones. Una vez que las estructuras de datos están en su lugar, el siguiente paso debe establecer las relaciones entre las tablas de la base de datos. Primero hay que asegurarse que cada tabla tiene una clave única que puede identificar los registros individuales en cada tabla. Cualquier campo en la base de datos que contiene valores únicos es un campo aceptable para usar como clave. Sin embargo, esto es una práctica mucho mejor añadir un campo arbitrario a cada tabla que contiene un valor sin sentido, pero único. Este valor es típicamente un número entero que es adjudicado a cada registro cuando es entrado y nunca otra vez repetido. Este asegura que cada registro entrado tendrá una clave única.

 

 

 

La realización de reglas y restricciones. En este punto, los campos en la base de datos son todavía bastante amorfos. Definiendo los campos cuando sea texto o numérico una aproximación para los tipos de datos que el cliente tiene que almacenar, pero hay lugar para un refinamiento adicional. Las reglas y las restricciones conducen a una entrada de datos más limpia y así se consigue mejor información del uso de los datos. Las reglas de validación y las restricciones limitan el formato que los datos pueden tener o el camino por el que las tablas de datos pueden estar relacionadas unas con otras.

Algunas de estas restricciones son impuestas por la naturaleza de los datos sí mismo; los números de seguridad social están siempre en el mismo formato de dígitos. Este tipo de restricción se pone en práctica normalmente para asegurarse que los datos son completos y exactos. En otros casos, la situación por sí misma obliga explícitamente a restringir los datos. Los valores posibles para los datos son por lo general comprobados contra una lista o la opción de valores es por otra parte obligada. Este tipo de la restricción es por lo general fácil de poner en práctica y fácil de cambiarse.

Creación de vistas e informes. Ahora que el diseño de datos está esencialmente completo, el paso penúltimo debe ser el de crear las especificaciones que ayudarán a convertir los datos en  información útil en forma de un informe o una vista de los datos. Las vistas son simplemente colecciones combinadas de los datos disponibles en la base de datos. Podría ser tan simple como un subconjunto de una tabla de datos existente o tan complicado como una colección de múltiples tablas unidas sobre un juego particular de criterios. Los informes por otra parte, son típicamente fotos de la base de datos en un punto particular a tiempo.

La realización del diseño en software. Todo el trabajo hasta este punto se ha llevado a cabo sin preocuparse explícitamente de los detalles del programa. De hecho, el diseño debería existir sólo como diagramas y notas sobre el papel. Esto es sobre todo importante en un punto posterior cuando uno mismo o alguien más tenga que actualizar la base de datos o pointegrarla en otro paquete. Este es el momento de arrancar el ordenador y ponerse a a trabajar en la base de datos.