Hay una base conceptual para el diseño de la base de datos.
En el diseño de bases de datos clásico, existen tres modelos: conceptual, lógico y físico.
El modelo conceptual surge del análisis de requisitos y evoluciona a medida que evoluciona el tema subyacente o cuando se desarrolla la comprensión del tema en cuestión. El modelo conceptual fija los datos elementales en cuanto a la forma y la semántica, pero no se ocupa de cuestiones tales como la composición de la tabla.
El modelo lógico usa el modelo relacional de datos. Puede derivarse del modelo conceptual, pero también se ocupa de la composición de las relaciones. La normalización y otros problemas de composición entran en juego aquí. El modelo lógico anticipa el diseño de la tabla y también las consultas y actualizaciones que la aplicación realizará.
El modelo físico implementa relaciones como tablas, y también agrega todas las otras características como índices, espacios de tabla, etc.necesario para realmente construir la base de datos. Se deriva del modelo lógico, pero el volumen de datos, la carga, el rendimiento y el espacio en disco entran en juego.
Esto suena largo y tedioso, pero en realidad es rápido, si sabes cómo hacerlo. Todo se puede hacer en cuestión de semanas, mientras que el resto del equipo sigue debatiendo las especificaciones funcionales. Para un proyecto realmente pequeño (6 tablas, 50 columnas) se puede hacer en días, con solo lápiz y papel. Para proyectos más grandes, hay herramientas que hacen que el diseño sea más automático, menos propenso a errores y fácil de diagramar.
Pero, ¿qué sucede cuando descubres que el modelo conceptual era inexacto o incompleto, y que los otros dos modelos y la base de datos en sí necesitan ser alterados? Ahí es donde el Data Independence viene al rescate. La independencia de los datos para el diseño de la base de datos es lo que hace la encapsulación para el diseño de objetos. A saber, evita que un ajuste menor en un lugar se propague por todos los objetos de la aplicación. Los objetos solo dependen de los datos que usan.
Si se debe agregar una tabla nueva a un esquema, las posibilidades de que se rompa alguna aplicación son infinitamente pequeñas. Incluso si se debe modificar una tabla existente, las consultas que solo usan las columnas antiguas no notarán ninguna diferencia. Incluso cuando los objetos dependen del cambio, aún puede darle un nombre nuevo a la tabla modificada y luego crear una vista con el nombre anterior que haga que parezca que la tabla anterior aún está allí.
Y la independencia física de los datos está casi completa en un buen DBMS. Puede reorganizar datos, agregar y eliminar índices, etc. y no debería tener que cambiar ninguna de las aplicaciones.
En resumen, la gestión del cambio se puede hacer de manera brillante utilizando los buenos productos DBMS que existen. Desafortunadamente, muchos de los administradores de bases de datos y programadores no saben cómo hacer un uso adecuado de estas funciones de DBMS, a pesar de que llevan años funcionando.
¿Qué pasa si le da la vuelta a eso ?: supongamos que las especificaciones del cliente son actualmente solo para un artista por gira, pero en el futuro dos de sus bandas podrían ir de gira juntas, y por lo tanto tocar en los mismos shows. ¿Todavía agregas artist_id a la tabla de fechas recorridas, lo que limita el sistema a 1 artista por tourdate? ¿O piensas en el futuro, convirtiéndolo en una relación HaBtM? – Calvin