2.1. Diseño conceptual
El diseño de la base de datos se lleva a cabo en tres etapas:
- diseño conceptual;
- diseño lógico;
- diseño físico.
El propósito de la fase de diseño conceptual es crear un modelo de datos conceptual basado en las ideas de los usuarios sobre el tema. Para lograrlo, se llevan a cabo una serie de procedimientos secuenciales. Un ejemplo de un esquema de entidad (conceptual):
1. Definición de entidades y su documentación. Para identificar entidades, se definen objetos que existen independientemente de otros. Tales objetos son entidades. Cada entidad recibe un nombre significativo que los usuarios pueden entender. Los nombres y descripciones de las entidades se ingresan en el diccionario de datos. Si es posible, se establece el número esperado de instancias de cada entidad.
2. Determinación de las relaciones entre entidades y su documentación. Solo se definen aquellas relaciones entre entidades que son necesarias para satisfacer los requisitos de diseño de la base de datos. Se establece el tipo de cada uno. Se revela la clase de pertenencia de las entidades. A los enlaces se les asignan nombres significativos expresados por verbos. Se ingresa en el diccionario de datos una descripción detallada de cada conexión, indicando su tipo y la clase de pertenencia de las entidades que participan en la conexión.
3. Creación de un modelo ER del área temática. Los diagramas ER se utilizan para representar entidades y relaciones entre ellas. En base a ellos, se crea una única imagen visual del área de estudio modelada: el modelo ER del área de estudio.
4. Definición de atributos y su documentación. Se revelan todos los atributos que describen las entidades del modelo ER creado. Cada atributo recibe un nombre significativo que los usuarios pueden entender. La siguiente información se almacena en el diccionario de datos para cada atributo:
- nombre y descripción del atributo;
- tipo y dimensión de los valores;
- el valor predeterminado para el atributo (si lo hay);
- si el atributo puede tener valores NULL;
- si el atributo es compuesto y, de ser así, de qué atributos simples consiste. Por ejemplo, el atributo "Nombre completo del cliente" puede constar de atributos simples "Apellido", "Nombre", "Patronímico" o puede ser simple y contener valores únicos, como "Sidorsky Evgeniy Mikhailovich". Si el usuario no necesita acceso a elementos individuales del "Nombre", entonces el atributo se presenta como simple;
- si se calcula el atributo y, de ser así, cómo se calculan sus valores.
5. Definición de los valores de los atributos y su documentación. Para cada atributo de una entidad que participa en el modelo ER, se determina un conjunto de valores válidos y se le asigna un nombre. Por ejemplo, el atributo "Tipo de cuenta" solo puede tener los valores "depósito", "actual", "bajo demanda", "cuenta de tarjeta". Las entradas del diccionario de datos relacionadas con los atributos se actualizan con los nombres de los conjuntos de valores de atributo.
6. Definición de claves primarias para entidades y su documentación. Este paso está guiado por la definición de una clave primaria, como un atributo o conjunto de atributos de una entidad que permite la identificación única de sus instancias. La información clave principal se coloca en el diccionario de datos.
7. Discusión del modelo conceptual de datos con los usuarios finales. El modelo de datos conceptual está representado por un modelo ER con documentación adjunta que contiene una descripción del modelo de datos desarrollado. Si se encuentran inconsistencias de dominio, se realizan cambios en el modelo hasta que los usuarios confirmen que el modelo propuesto por ellos refleja adecuadamente sus puntos de vista personales.
2.2 Diseño lógico
El propósito de la etapa de diseño lógico es transformar el modelo conceptual basado en el modelo de datos seleccionado en un modelo lógico que sea independiente de las características del SGBD utilizado posteriormente para la implementación física de la base de datos. Para lograrlo, se realizan los siguientes procedimientos.
Un ejemplo de un esquema de base de datos lógica.
1. Elegir un modelo de datos. La mayoría de las veces, se elige un modelo de datos relacionales debido a la claridad de la presentación tabular de los datos y la conveniencia de trabajar con ellos.
2. Definir un conjunto de tablas basadas en el modelo ER y documentarlas. Se crea una tabla para cada entidad del modelo ER. El nombre de la entidad es el nombre de la tabla. Las relaciones entre tablas se establecen mediante el mecanismo de claves primarias y foráneas. Se documentan las estructuras de las tablas y las relaciones establecidas entre ellas.
3. Normalización de tablas. Para realizar correctamente la normalización, el diseñador debe comprender profundamente la semántica y los patrones de uso de los datos. En este paso, comprueba la corrección de la estructura de las tablas creadas en el paso anterior aplicándoles el procedimiento de normalización. Consiste en llevar cada una de las tablas al menos a la 3ª FN. Como resultado de la normalización se obtiene un diseño de base de datos muy flexible, lo que facilita realizar las ampliaciones necesarias a la misma.
4. Comprobación del modelo lógico de datos para la posibilidad de realizar todas las transacciones proporcionadas por los usuarios. Una transacción es un conjunto de acciones realizadas por un usuario individual o un programa de aplicación para cambiar el contenido de una base de datos. Entonces, un ejemplo de una transacción en el proyecto BANCO puede ser la transferencia del derecho de administrar las cuentas de un determinado cliente a otro cliente. En este caso, será necesario realizar varios cambios en la base de datos a la vez. Si una computadora falla durante una transacción, la base de datos estará en un estado inconsistente porque ya se han realizado algunos cambios y otros no. Por lo tanto, todos los cambios parciales se deben deshacer para devolver la base de datos a su estado consistente anterior.
La lista de transacciones está determinada por las acciones de los usuarios en el área temática. Utilizando el modelo ER, el diccionario de datos y las relaciones establecidas entre claves primarias y foráneas, se intenta realizar todas las operaciones de acceso a datos necesarias de forma manual. Si alguna operación manual falla, entonces el modelo de datos lógicos compilados es inadecuado y contiene errores que deben eliminarse. Quizás estén relacionados con una brecha en el modelo de una entidad, relación o atributo.
5. Determinación de los requisitos de soporte de integridad de datos y su documentación. Estos requisitos son restricciones que se implementan para evitar que se ingresen datos contradictorios en la base de datos. En este paso, los problemas de integridad de datos se cubren sin tener en cuenta los aspectos específicos de su implementación. Se deben considerar los siguientes tipos de restricciones:
- datos requeridos. Averiguar si hay atributos que no pueden tener valores NULL;
- Restricciones en los valores de los atributos. Se definen valores válidos para los atributos;
- integridad de la entidad. Se logra si la clave primaria de la entidad no contiene valores NULL;
- integridad referencial. Se entiende que el valor de la clave externa debe estar presente en la clave principal de una de las filas de la tabla para la entidad matriz;
- restricciones impuestas por las reglas de negocio. Por ejemplo, en el caso del proyecto BANCO, se puede adoptar una regla que prohíba al cliente administrar, digamos, más de tres cuentas.
La información sobre todas las restricciones de integridad de datos establecidas se coloca en el diccionario de datos.
6. Creación de la versión final del modelo lógico de datos y discusión con los usuarios. Este paso prepara la versión final del modelo ER, que representa el modelo de datos lógicos. El modelo en sí y la documentación actualizada, incluido el diccionario de datos y el esquema de enlace de la tabla relacional, se presentan para su revisión y análisis por parte de los usuarios, quienes deben asegurarse de que represente con precisión el área temática.
2.3. Diseño físico
El propósito de la etapa de diseño físico es describir una implementación específica de una base de datos ubicada en la memoria externa de una computadora. Esta es una descripción de la estructura de almacenamiento de datos y los métodos eficientes para acceder a los datos de la base de datos. En el diseño lógico, responden a la pregunta: qué se debe hacer, y en el diseño físico, se elige una forma de hacerlo. Los procedimientos de diseño físico son los siguientes.
1. Diseño de tablas de base de datos utilizando el SGBD seleccionado. Se selecciona un DBMS relacional para crear una base de datos alojada en medios de máquina. Su funcionalidad para el diseño de mesas está profundamente estudiada. Luego se realiza el diseño de las tablas y el esquema de su conexión en el entorno DBMS. El proyecto de base de datos preparado se describe en la documentación adjunta.
2. Implementación de reglas de negocio en el entorno del SGBD seleccionado. La actualización de la información en las tablas puede estar limitada por las reglas comerciales. La forma en que se implementan depende del DBMS elegido. Algunos sistemas para implementar los requisitos del área temática ofrecen más funciones, otros menos. En algunos sistemas, no hay soporte para implementar reglas comerciales en absoluto. En este caso, se desarrollan aplicaciones para implementar sus limitaciones.
Todas las decisiones tomadas en relación con la implementación de las reglas comerciales del dominio se describen en detalle en la documentación adjunta.
3. Diseño de la organización física de la base de datos. Este paso selecciona la mejor organización de archivos para las tablas. Se identifican las transacciones que se realizarán en la base de datos que se está diseñando y se destacan las más importantes. Se analiza el rendimiento de las transacciones: la cantidad de transacciones que se pueden procesar en un intervalo de tiempo determinado y el tiempo de respuesta: el período de tiempo necesario para completar una transacción. Se esfuerzan por aumentar el rendimiento de las transacciones y reducir el tiempo de respuesta.
En base a estos indicadores, se toman decisiones para optimizar el rendimiento de la base de datos definiendo índices en tablas que agilicen la selección de datos de la base de datos, o reduciendo los requisitos para el nivel de normalización de tablas. Se estima el espacio en disco necesario para albergar la base de datos creada. Esfuércese por minimizarlo.
Las decisiones tomadas sobre los temas anteriores están documentadas.
4. Desarrollo de una estrategia de protección de bases de datos. La base de datos es un recurso corporativo valioso y se presta mucha atención a su protección. Para hacer esto, los diseñadores deben tener una comprensión completa y clara de todas las protecciones proporcionadas por el DBMS seleccionado.
5. Organización del seguimiento del funcionamiento de la base de datos y su ajuste. Después de la creación del proyecto físico de la base de datos, se organiza un seguimiento continuo de su funcionamiento. La información resultante sobre el nivel de rendimiento de la base de datos se utiliza para ajustarla. Para ello también intervienen los medios del DBMS seleccionado.
Las decisiones de realizar cambios en una base de datos en funcionamiento deben considerarse y sopesarse minuciosamente.