Proceso de Diseño de una Base de Datos

Proceso de Diseño de una Base de Datos

Este proceso lo voy basar en un marco de medianas y pequeñas empresas, ya que hablar de este proceso en un proyecto de una gran empresa extendería el tema al limite de PMI y PMBOK que no son parte de este apartado.

Basado en lo anterior veamos las etapas a un nivel de micro-actividades

Realidad Empresarial u Organizativa

Por lo general en medianas y pequeñas empresas encontramos que la implementación de una base de datos por lo general va asociada al desarrollo de alguna herramienta informática que busque la satisfacción de una necesidad en particular de manera general o de forma particular en un área funcional o de negocio. Por ejemplo de forma general podemos encontrar la necesidad de integración cliente-empresa y proveedor-empresa (ambas de forma bidireccional), es así como esta necesidad involucra diferentes áreas de la empresa o en algunas encontraremos temas más específicos como la elaboración de un sistema de carnetización, en cualquier caso encontraremos también la necesidad de interactuar con otros sistemas aquí veríamos la necesidad de crear una capa intermedia de datos para la obtención del archivo plano de estudiantes matriculados para ser entregado al sistema de bibliotecas. Bien hasta ahí vemos que toda organización requiere de los servicios de un DBA que solucione o haga parte de la solución de la necesidad, ya veremos como estos dos componentes de la empresa (el funcional o de negocio y el técnico) deben trabajar en equipo para lograr Diseñar una Base de datos que responda a la necesidad.

Definición de grupo de trabajo

En todo diseño debemos identificar los diferentes componentes humanos que estarán involucrados en el proceso, sabemos que existe una necesidad y que aquellos que la palpan y conocen de ella son aquellos empleados que hacen parte del área funcional afectada (o de las áreas), bien entonces es claro que debe haber un componente funcional, pero no serían todos los del área de ventas, producción y facturación, pues bien conocemos “divide y vencerás” bien aquí aplicamos esto, tendremos por parte del negocio un “Líder Funcional” aquel que conoce de forma general y particular la necesidad y tendremos un “Líder Técnico” (este eres tú, así que presta atención) aquel que conoce del tema de bases de datos, programación, plataforma etc.. La parte que es de idioma “mandarín” para los funcionales la manejará este líder y estará a cargo del Diseño de la Base de datos.

Pues bien hasta ahora es claro tenemos dos cabezas una funcional y una técnica (dos piensan más que una), en aquellos casos en los que las áreas funcionales afectadas sean muchas el Líder Funcional deberá tener un grupo de apoyo compuesto por lo que llamamos en el negocio “Key Users” que son aquellas personas que de cada área funcional maneja la “minucia” de la problemática (recuerda divide y vencerás), esto también aplica para el Líder Técnico, si el tema es especializado pues creará su grupo de Key Users en los temas involucrados en la problemática ( y ahora tendremos más cabezas pensando).

Recolección de Requerimientos

En esta fase es donde los Lideres se reúnen utilizando métodos de debate y establecen los requerimientos generales y particulares fruto de la necesidad o problemática presentada.

Definimos de forma macro y micro todos y cada uno de los componentes que queremos resolver.

Esta fase es gerencial ya que los líderes presentan los requerimientos a la alta gerencia (que entre otras cosas es bueno hacerlo porque el compromiso debe venir desde lo más alto) y se aprueban.

Análisis de requerimientos

El análisis de requerimiento en ocasiones lo podemos realizar dentro de la fase anterior pero particularmente lo separo por que de aquí sale de forma definitiva el primer entregable importante para las fases subsiguientes aquí nos vamos hasta los Key Users y de la “minucia” del negocio siempre encontramos cositas que se escapan en la fase anterior, basado en lo analizado con los Key Users (recuerda que no por estar jerárquicamente abajo no son menos importantes) ya podemos decir que tenemos contemplado “todo” de la problemática.

Entregable 1. Alcance del diseño

Luego de establecer los componentes micro y macro y luego de analizar con los que saben de la cosa (Líder Técnico – Key Users) se redacta lo que para muchos es el documento que regirá de aquí en adelante el proceso de diseño, a este documente comúnmente lo conocemos como Alcance del Diseño.

Nota Importante: Si en las fases siguientes este documento sufre cambios cuidado!!! Puedes entrar en círculo vicioso por eso debes tener claro que la redacción de este documento debe ser estricta.

Entregable 2: Plan de trabajo

Aquí definimos (Funcional y Técnico) las fechas y actividades que requiere el diseño, por lo general basado en el alcance ya es mucho más fácil y para nuestro caso de estudio son aquellas actividades que nos conllevan a tener un modelo conceptual de la problemática.

Modelamiento Conceptual

Basados en el Documento de Alcance comenzamos nuestra labor técnica, en nuestro caso aplicar todo lo que hemos aprendido en el curso de Diseño de Bases de Datos, realizamos 0FN, 1FN, 2FN y 3FN y hacemos sentir orgulloso a nuestro tutor de paso.

Utilizamos el método de modelamiento Entidad – Relación el más común y uno de los más fáciles, (desde mi punto de vista), para hacer una representación gráfica de la problemática.

Este modelo no sale a la primera, por lo general debes presentar varios prototipos del mismo hasta llegar a uno que sea lo más aproximado a la problemática.

Entregable 3: Modelo Entidad Relación y Diccionario de Datos

Bueno en realidad primero el Diccionario de Datos que define cada campo, tipo de datos, dominio y descripción del mismo, veamos un ejemplo para ser mas concretos.

http://www.monografias.com/trabajos59/administracion-diseno-db/administracion-diseno-db2.shtml

Generamos nuestra representación gráfica final es decir nuestro modelo entidad relación, también tengo un ejemplo para que te sea más sencillo:

Uno sencillo: http://es.wikipedia.org/wiki/Archivo:Ejemplo_Diagrama_E-R_extendido.PNG

Uno más complejo para que veas en que líos puedes llegar a meterte: http://4.bp.blogspot.com/_3uuCWCr7GmM/S9G94ddb5II/AAAAAAAAAJ8/JCVqqqrlXQ0/s1600/EntidadRelacionTienda-733693.JPG

Transformación del Modelo a Modelo de Datos

Esta etapa, luego de tener nuestro entidad relación, determina básicamente el SGBD (Sistema de Gestión de Base de Datos) que utilizaremos ya sea Oracle, SQL Server, MySql, Postgres en sus colores y sabores, entre otros claro está DB2, Informix etc...

Así ya estamos en algo más dependiente a herramientas de software, para algunos la fase de diseño culmina aquí ya que esto ya sale del diseño pero yo la incluyo, nunca esta demás alguito que ayude a tener mayor visión

Entregable 4: Diseño Físico

La forma como será almacenada nuestra base de datos, sistemas de archivos, porque toda base de datos tiene archivos de datos, apartándome del tema, esto es importante ya que cuando nuestra base de datos crezca veremos que el rendimiento comenzara a disminuir y si no hacemos este entregable de manera proyectada, tendremos problemas de afinamiento mas adelante.

Creación de la Base de Datos

Mediante nuestro SGBD y con sentencias SQL creamos nuestra base de datos y asi culminamos entregando lo más importante un producto que resuelva nuestra problemática.