1.1 Introducción
Diseñar una base de datos es algo similar a diseñar la arquitectura de un proyecto Java. Puede colocar todos los datos en un par de tablas o puede crear una hermosa estructura de datos a partir de esquemas y docenas de tablas.
Estas son las tareas a las que normalmente se enfrenta un desarrollador al diseñar una base de datos:
- Asegurarse de que toda la información necesaria se almacene en la base de datos.
- Garantizar la posibilidad de obtener datos sobre todas las solicitudes necesarias.
- Reducir la redundancia y la duplicación de datos.
- Garantizar la integridad de la base de datos
- Optimización de la velocidad de acceso a datos
Lo más importante que debe recordar es que no puede crear una estructura de base de datos ideal, porque. al igual que su código, también cambiará constantemente. Hay tres cosas que debe tener en cuenta al diseñar la estructura de su base de datos:
- La estructura debe ser lo suficientemente buena.
- Debe haber una lógica en todo lo que otras personas puedan entender.
- La optimización prematura es la fuente de todos los males.
No tiene que crear la mejor estructura de base de datos del mundo. Ella seguirá cambiando. Su tarea es asegurarse de que después de 20 cambios en la estructura de su base de datos, sea lo suficientemente fácil de resolver.
Lo más probable es que en los primeros años de tu trabajo, nadie confíe en ti para diseñar una base desde cero. Realizará cambios en un esquema existente. Debe tratar de comprender sobre la base de qué principios se organiza y adherirse a ellos . Con su estatuto, no suben al monasterio de otra persona.
No optimice la base de datos hasta que sea necesario. Si la tabla tiene solo un par de cientos de filas, lo más probable es que el DBMS la mantenga en la memoria y le haga consultas en caché.
Por otro lado, debería poder acelerar el trabajo de solicitudes importantes por decenas o incluso cientos de veces. Y sería bueno si supieras cómo hacerlo. ¿Cómo se dice en la secundaria en el primer año? "Olvida todo lo que te enseñaron en la escuela..."
Si sabe qué es la normalización de la base de datos, entonces me apresuro a complacerlo, en su trabajo lo más probable es que se ocupe de la desnormalización . Nada es más importante para los santuarios del proyecto que la velocidad de la base de datos. Y si, para acelerar la selección de datos de la base de datos, necesita combinar 200 (!) Tablas en una (con una redundancia monstruosa), tendrá que hacerlo.
1.2 Diseño de la biblioteca
Profundicemos un poco en el tema y pensemos en el diseño de bases de datos usando algo tan simple como una biblioteca de libros típica.
La tarea principal de cualquier biblioteca es el procesamiento del fondo de libros. Es fácil distinguir tres grupos principales de usuarios del sistema: lector, bibliotecario, administrador . La actividad de cada uno se muestra en un diagrama de casos de uso.
Ya ahora, se pueden distinguir algunas entidades y relaciones de la futura base de datos:
Con este enfoque, no queda claro cómo conectar al lector con el libro (el lector no tiene una ariedad en la relación “emisión/recepción”. Si el libro tiene varios ejemplares, entonces puede ser emitido a varios lectores. Incluso si un libro se entiende como una copia, cuando se guarde en la tabla de libros del lector actual, será imposible obtener información sobre quién (y cuántas veces) tomó este libro antes.
La solución puede ser la introducción de una entidad adicional : una tarjeta para emitir un libro. Cuando se entrega el libro al lector, se crea una tarjeta y, cuando se entrega el libro, se le coloca la marca correspondiente. Con la ayuda de estas tarjetas, se determinan las deudas de cada usuario y se calculan estadísticas sobre el uso de libros. Al reservar literatura por parte del lector, también se inicia una tarjeta; si el lector no toma la literatura reservada dentro de un período determinado, la tarjeta se destruye. Hay un límite en la cantidad de libros que un lector puede reservar.
Al seleccionar literatura, el usuario visualiza el catálogo de literatura con la posibilidad de filtrar los resultados de la búsqueda por autor, título, año de publicación.
Es posible calcular las estadísticas de todos los libros de la biblioteca, mientras que el número de copias emitidas del libro durante un período de tiempo determinado. También puede establecer el número mínimo de instancias de libros para las que se realiza el cálculo. Según estas estadísticas, los libros que no se utilizan se dan de baja de la biblioteca.
Se pueden distinguir las siguientes entidades principales del área temática:
- usuario (bibliotecarios y administradores);
- lector;
- Sala de lectura;
- libro;
- tarjeta de emisión de libros;
- tarjeta de reserva de libro.
El diagrama ER modificado de la base de datos se muestra en la figura.
De acuerdo con los casos de uso que se muestran en la Figura 1, la base de datos debe implementar las siguientes consultas (no es una lista exhaustiva):
- mostrar libros que coincidan con las condiciones especificadas;
- mostrar a los usuarios que tienen tarjetas de emisión de libros que no han sido cerrados a tiempo (el bibliotecario está buscando deudores);
- mostrar todos los libros que corresponden a las tarjetas de préstamo de libros del usuario dado que no se cerraron a tiempo (el usuario vino a la biblioteca por nuevos libros; debe ver si es un deudor e informarle al respecto);
- eliminar todas las tarjetas de reserva creadas hace más de N segundos;
- mostrar todos los libros correspondientes a las tarjetas de reserva de libros sin cerrar del usuario especificado (el lector pidió libros y vino a la biblioteca por ellos; el bibliotecario necesita obtener esta lista para distribuirla).
1.3 Formación del esquema
Para formar un esquema de datos, primero debe complementar el diagrama ER con los detalles de las entidades (perfeccionarlo). A veces, al mismo tiempo, es posible encontrar errores al construir un diagrama ER: en esta tarea, se descubrió que el libro debía estar "de alguna manera" conectado con la sala de la biblioteca.
Esto se puede hacer colocando el "número de sala" requerido en el libro; sin embargo, con este enfoque, el mismo libro deberá describirse en la base de datos varias veces (si ocurre en diferentes salas). Un enfoque más correcto es introducir una entidad adicional "colocación de libros". La figura muestra un diagrama ER con una entidad adicional y accesorios.
El diagrama ER anterior refleja las principales tablas, relaciones y atributos; sobre esta base, puede construir un modelo de base de datos. No existe un estándar para el diagrama ER, pero hay una serie de notaciones (Chen, IDEFIX, Martin, etc.), pero no se pudo encontrar ni el estándar ni las notaciones para el modelo de dominio. Sin embargo, en el curso de la construcción de dicho diagrama, los campos clave (externos e internos) se resaltan necesariamente, a veces índices y tipos de datos.
En este caso, en el siguiente diagrama:
- para enlaces, se usa la notación de Martin ("patas de gallo");
- las tablas se muestran como rectángulos divididos en 3 secciones:
- nombre de la tabla;
- teclas internas (marcadas con un marcador);
- los campos restantes, mientras que los obligatorios están marcados con un marcador.
Al desarrollar este modelo, había un deseo de unir la tabla de administradores con la tabla de bibliotecarios; sin embargo, agregue la tabla de usuarios:
- el administrador no está asociado a una sala concreta (habría que rellenar el campo correspondiente con valores nulos);
- esto probablemente complicaría la distribución de los derechos de acceso: ahora solo el administrador de la base de datos (que trabaja a través de un panel DBMS especial y no tiene una cuenta en el sistema que se está desarrollando) tiene acceso a la tabla de administradores. Sin embargo, al unir tablas, las consultas de los usuarios requerirían acceso a la nueva tabla.
Al construir este diagrama, se encontró y corrigió una falla en el diagrama ER: se agregó una tabla librarians_roomsque une a los bibliotecarios y los pasillos. Esto es necesario porque un bibliotecario puede trabajar en varias salas, pero varios bibliotecarios pueden trabajar en la misma sala.
Al diseñar bases de datos, debe poder razonar al menos como el ejemplo anterior. Si crees que lo has conseguido, vayamos más allá: aún más teoría.