DISEÑO DE BASE DE DATOS
Recolección y Análisis
Analizar un problema del mundo real
Recolección y análisis de requerimientos de datos:
Proceso durante el cual los diseñadores entrevistan a los futuros usuarios de la base de datos para entender y documentar sus requerimientos de información.
Primeramente, debe mantenerse el funcionamiento del flujo de información. Con esto tratar de determinar la idea del proyecto.
Cuando queremos crear una base de datos debemos saber, ¿Para qué se está creando la base de datos?
NOTA: El resultado de este paso será un conjunto de requerimientos del usuario redactado en forma explícita.
DIAGRAMA EJEMPLO DE LA RECOLECCIÓN Y ANÁLISIS DE REQUERIMIENTOS
Requerimientos funcionales:
Estos consisten en las operaciones definidas por el usuario (transacciones) que se aplicaran a la base de datos.
Para saber cuáles serán nuestros requerimientos funcionales debemos preguntarnos ¿Qué es lo que queremos solucionar? Identificar el problema, para el ejemplo del video club establecemos que se necesita almacenar la información. Que es que el sistema debe hacer, ¿Almacenar información? ¿Generar reportes? Estos ejemplos son los más comunes a la hora de identificar nuestros requerimientos funcionales. Tal como se muestra en la siguiente ilustración, en el cual se plantea los posibles requerimientos funcionales que requiere la base de datos de un Video Club.
NO SON REQUERIMIENTOS FUNCIONALES:
Estos son ejemplos de requerimientos no funcionales, es decir requerimientos aislados que no dependen del sistema y en teoría no deben afectar la performance de este. Son requerimientos que se toman en cuenta pero que no son prioridad. El sistema debe visualizarse y funcionar correctamente en cualquier navegador, especialmente en Internet Explorer, Firebird, Mozilla y Nautilus.
Clasificación de los modelos de datos
En la ilustración anterior aparecen los distintos esquemas que llevan desde el mundo real a la base de datos física. Como se ve aparecen varios esquemas intermedios. Los que están más a la izquierda se alejan más de las características físicas. Los elementos de ese esquema son:
• Mundo real. Contiene la información tal cual la percibimos como seres humanos. Es el punto de partida.
• Esquema conceptual. Representa el modelo de datos de forma independiente del SGBD que se utilizará.
• Esquema canónico (o de base de datos). Representa los datos en un formato más cercano al del ordenador.
• Esquema interno. Representa los datos según el modelo concreto de un sistema gestor de bases de datos (por ejemplo, Oracle)
• Base de datos física. Los datos tal cual son almacenados en disco. Diseño conceptual
Modelo de Datos: Entidad Relación
Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel.
El esquema conceptual contiene una descripción detallada de los requerimientos de información de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones.
La idea obtenida en el paso anterior y con la recopilación de la información previamente hecha. Ahora debe plasmarse en términos de base de datos, en un nivel que pueda entender el cliente. Para esto se debe elegir un modelo conceptual de base de datos, en este caso se utiliza el modelo entidad relación.
El Diseño conceptual implica la creación de un modelo de datos conceptual, se crea a partir de la información recolectada. Este modelo se prueba y se valida de acuerdo a los requisitos definidos por el usuario.
Para ello, previamente se recolecto la mayor cantidad de información y se plasma en un diagrama como el que se presenta en el ejemplo. Suponiendo que se requiere crear una base de datos de un VIDEO CLUB. Utilizando el modelo entidad relación para representarlo sería de esta manera:
EJEMPLO BASICO DEL DISEÑO CONCEPTUAL
MODELO ENTIDAD RELACIÓN DE MANERA BASICA Este modelo de base de datos es independiente de:
Diseño Lógico Modelo de Datos: Relacional
DISEÑO LOGICO (Transformación del modelo de datos)
En este paso de proceso de diseño consiste en implementar de hecho la base de datos con un SGBD (Sistema Manejador de Base de Datos) comercial, transformando el modelo conceptual al modelo de datos empleados por el SGBD (entidad-relación, jerárquico, red o relacional).
El esquema lógico viene a ser el resultado de la transformación de un esquema conceptual es decir del modelo entidad relación, utilizando un modelo de base de datos lógica, en este caso el modelo relacional. Entonces dentro del diseño lógico, se basa en transformar el modelo entidad relación al modelo relacional. Como se muestra en el ejemplo siguiente:
Diseño Físico Almacenamiento de datos
DISEÑO FÍSICO DE LA BASE DE DATOS
Se especifican las estructuras de almacenamiento interno y la organización de los archivos de la base de datos.
El diseñador decide cómo hay que implementar la base de datos, lo primero que debemos hacer es, identificar al sistema gestor de base de datos de destino, el diseño físico estará adaptado aun SGBD en concreto. Esto consiste en describir como queremos representar el modelo lógico de la base de datos.
En el esquema físico se establece como se almacenan los datos, se debe elegir el tipo de dato que corresponde a cada dato del esquema lógico. Como se muestra en el ejemplo siguiente:
Implementación
Implementación de la base de datos
En este paso final elegimos el gestor de la base de datos a utilizar en donde se implementará el esquema físico de la base de datos. El cual puede ser MYSQL, SQL SERVER, entre otros. En la cual estará implementada la base de datos, que utilizará el usuario.
IMPLEMENTACIÓN Principios del proceso de diseño
¿EL PROCESO DE DISEÑO DE UNA BASE DE DATOS SE GUÍA POR ALGUNOS PRINCIPIOS?
El primero menciona que se debe evitar la información duplicada o redundante, ya que estos datos ocupan un espacio y aumenta la probabilidad de que se produzcan errores e incoherencias.
El segundo principio menciona que es importante que la información sea correcta y completa. Si la base de datos contiene información incorrecta, los informes que se recogen contendrán información incorrecta y por lo tanto las decisiones que se tomen estarían mal fundamentadas.
