1. 1.Recogida y análisis de requisitos
1.1. Que es
1.1.1. consiste en conocer y analizar con detalle las expectativas, las necesidades y los objetivos de los futuros usuarios de la base de datos
1.2. Se dividen en 3 subfases
1.2.1. Recogida de requisitos
1.2.1.1. Consiste en:
1.2.1.1.1. Tenemos que establecer los actores del sistema de información que interaccionarán con la base de datos. Normalmente se utiliza un grupo de analistas que se encarga de hacer el análisis de requisitos y, muy probablemente, este análisis suele ser informal, incompleto e incluso incoherente en algún punto.
1.2.1.2. las actividades más habituales de esta fase son las siguientes:
1.2.1.2.1. Identificar los grupos de usuarios y las principales áreas de aplicación que utilizarán la base de datos
1.2.1.2.2. Estudiar y analizar la documentación existente relativa a las aplicaciones en uso.
1.2.1.2.3. Estudiar el entorno actual y el uso que se quiere dar a la información.
1.2.1.2.4. Hacer entrevistas y encuestas a los futuros usuarios para que puedan manifestar su opinión
1.2.2. Estructuración y refinamiento de los requisitos
1.2.2.1. Consiste en:
1.2.2.1.1. Es una buena práctica incorporar los usuarios de la base de datos durante el proceso de desarrollo, puesto que así se incrementa su grado de implicación y satisfacción.
1.2.2.2. Por ejemplo:
1.2.2.2.1. El diseño de aplicaciones (JAD)
1.2.3. Formalización de los requisitos
1.2.3.1. Consiste en:
1.2.3.1.1. El paso siguiente es convertir los requisitos a un formato estructurado me diante técnicas de especificación de requisitos
1.2.3.2. Por ejemplo:
1.2.3.2.1. El análisis orientado a objetos (OOA)
1.2.3.2.2. Diagramas de flujo de datos (DFD)
1.2.3.2.3. La notación Z
1.2.3.3. Tipos de recursos:
1.2.3.3.1. Diagramas Texto Tablas Gráficos Diagramas de decisión
1.2.3.4. Por que es importante:
1.2.3.4.1. Detecta y corrige los errores o problemas en las fases iniciales del proyecto es mucho menos costoso que arrastrar los errores hasta las fases finales
2. 2.Diseño conceptual
2.1. Que es:
2.1.1. tiene como objetivo crear un esquema conceptual de alto nivel e independiente de la tecnología a partir de los requisitos, las especificaciones y las restricciones que se han recogido en la fase anterior.
2.2. Cual es su objetivo:
2.2.1. Diseñar un esquema conceptual de la base de datos que sea consistente con los requisitos, las especificaciones y las restricciones impuestas por la problemática que hay que resolver.
2.3. Para que sirve:
2.3.1. El esquema, además, debe servir de referencia para verificar que se han agrupado todos los requisitos y que no hay ningún conflicto entre ellos.
2.4. Modelo ER
2.4.1. Que es ER:
2.4.1.1. En inglés se denomina en tity-relationship model, en español encontramos autores que lo traducen como modelo entidad-relación y otros que lo traducen como mode lo entidad-interrelación
2.4.2. Para que se utiliza:
2.4.2.1. Este modelo es uno de los más utilizados en el diseño conceptual de las aplicaciones de bases de datos, principalmente, debido a su simplicidad y facilidad de uso
2.5. El lenguaje unificado de modelización
2.5.1. Que es:
2.5.1.1. Es un lenguaje gráfico diseñado para especificar, visualizar, modificar, construir y documentar un sistema
2.5.2. Para que sirve:
2.5.2.1. El lenguaje UML incorpora una gran cantidad de diagramas que permiten representar el modelo de un sistema desde perspectivas diferentes. En relación con el diseño conceptual de bases de datos, nos interesa especialmente el diagrama de clases, que permite representar información del dominio de discurso. Los diagramas de clases son diagramas estáticos que describen la estructura de un sistema a partir de las clases o tipos de entidad del sistema.
3. 3.Diseño lógico
3.1. Consiste en :
3.1.1. Se transforma en el modelo conceptual, independiente del tipo de tecnología, en un modelo lógico dependiente del tipo de SGBD en el que se quiere implementar la base de datos.
3.2. Para que sirve:
3.2.1. Si se quiere crear la base de datos en un sistema relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, sus claves primarias y sus claves foráneas correspondientes.
3.3. Se divide en 3 subfases:
3.3.1. Reconsideraciones del modelo conceptual
3.3.1.1. Consiste en:
3.3.1.1.1. Detectar y corregir algunos errores que se suelen producir en los modelos conceptuales y que con viene detectar y reparar lo antes posible para evitar que se propaguen en fases posteriores. Dichos errores se denominan trampas de diseño
3.3.2. Transformación del modelo conceptual en el modelo lógico
3.3.2.1. Consiste en:
3.3.2.1.1. Se centra en el diseño lógico de bases de datos relacionales. Por lo tanto, el modelo lógico generado será aplicable a cualquier base de datos relacional.
3.3.2.2. Modelo relacional
3.3.2.2.1. Que es:
3.3.3. Normalización
3.3.3.1. Consiste en:
3.3.3.1.1. En que las formas normales son declarativas, es decir, cada forma normal indica las restricciones que se deben cumplir, pero no describe ningún procedimiento para conseguirlo
4. 4.Diseño físico
4.1. Consiste en:
4.1.1. Es una fase del proceso de diseño de bases de datos que adapta el esquema lógico obtenido en la fase anterior
4.2. Se divide en:
4.2.1. El nivel físico y el nivel virtual
4.2.1.1. que es:
4.2.1.1.1. El estudio de los niveles físico y virtual de las bases de datos permite ver aspectos como las estructuras de almacenamiento y las rutas de acceso por los ficheros de la base de datos.
4.2.1.2. Criterios:
4.2.1.2.1. Tiempo de respuesta. Es el tiempo que transcurre desde que se envía una petición al SGBD hasta que éste devuelve los datos de la respuesta.
4.2.1.2.2. Uso del espacio. Es la cantidad de espacio de disco utilizado por los fiche ros de la base de datos y las estructuras de rutas de acceso al disco, incluyendo índices y otras rutas de acceso.
4.2.1.2.3. Rendimiento. Es la cantidad media de transacciones que se pueden pro cesar en un minuto de tiempo.
4.2.2. Transformación del modelo lógico en el modelo físico
4.2.2.1. Consiste en:
4.2.2.1.1. Transforma el modelo lógico de una base de datos en un modelo físico, según el SGBD elegido para implementar el sistema de información
4.2.2.2. Considerar una ampliación del lenguaje SQL estándar con las cláusulas propias que cada gestor necesita para definir los componentes del diseño físico
4.2.2.3. Transformar el diseño lógico de la base de datos en un SGBD:
4.2.2.3.1. Partimos de las definiciones de tablas, después se relaciona cada elemento con un espacio adecuado en el nivel virtual y finalmente se relaciona cada espacio virtual con un fichero físico