El diseño de bases de datos es la organización de los datos de acuerdo con un modelo de base de datos . El diseñador determina qué datos deben almacenarse y cómo se relacionan entre sí los elementos de datos. Con esta información, puede comenzar a ajustar los datos al modelo de base de datos. [1] Un sistema de gestión de bases de datos administra los datos en consecuencia.
El diseño de una base de datos es un proceso que consta de varios pasos.
El primer paso del diseño de una base de datos implica clasificar los datos e identificar las interrelaciones. La representación teórica de los datos se denomina ontología o modelo conceptual de datos .
En la mayoría de los casos, la persona que diseña una base de datos es una persona con experiencia en diseño de bases de datos, en lugar de experiencia en el dominio del que se extraen los datos que se almacenarán, por ejemplo, información financiera, información biológica, etc. Por lo tanto, los datos que se almacenarán en una base de datos particular deben determinarse en cooperación con una persona que tenga experiencia en ese dominio y que conozca el significado de los datos que se almacenarán dentro del sistema.
Este proceso es uno que generalmente se considera parte del análisis de requisitos y requiere habilidad por parte del diseñador de la base de datos para obtener la información necesaria de aquellos con el conocimiento del dominio . Esto se debe a que aquellos con el conocimiento del dominio necesario a menudo no pueden expresar claramente los requisitos del sistema para la base de datos, ya que no están acostumbrados a pensar en términos de los elementos de datos discretos que se deben almacenar. Los datos que se almacenarán se pueden determinar mediante la Especificación de requisitos. [2]
Una vez que un diseñador de bases de datos conoce los datos que se almacenarán en la base de datos, debe determinar dónde se encuentra la dependencia dentro de los datos. A veces, cuando se modifican los datos, se pueden estar modificando otros datos que no son visibles. Por ejemplo, en una lista de nombres y direcciones, suponiendo una situación en la que varias personas pueden tener la misma dirección, pero una persona no puede tener más de una dirección, la dirección depende del nombre. Cuando se proporciona un nombre y la lista, la dirección se puede determinar de forma única; sin embargo, lo inverso no se cumple: cuando se proporciona una dirección y la lista, no se puede determinar un nombre de forma única porque varias personas pueden residir en una dirección. Debido a que una dirección se determina por un nombre, se considera que una dirección depende de un nombre.
(NOTA: Un error común es creer que el modelo relacional se llama así debido a las relaciones que establece entre los elementos de datos que contiene. Esto no es cierto. El modelo relacional se llama así porque se basa en estructuras matemáticas conocidas como relaciones ).
La información obtenida puede formalizarse en un diagrama o esquema. En esta etapa se trata de un esquema conceptual .
Uno de los tipos más comunes de esquemas conceptuales son los diagramas ER ( modelo entidad-relación ).
Los atributos en los diagramas ER generalmente se modelan como un óvalo con el nombre del atributo, vinculado a la entidad o relación que contiene el atributo.
Los modelos ER se utilizan comúnmente en el diseño de sistemas de información; por ejemplo, se utilizan para describir los requisitos de información y/o los tipos de información que se almacenarán en la base de datos durante la fase de diseño de la estructura conceptual. [3]
Una vez que se han determinado las relaciones y dependencias entre los distintos elementos de información, es posible organizar los datos en una estructura lógica que luego se puede asignar a los objetos de almacenamiento admitidos por el sistema de gestión de bases de datos . En el caso de las bases de datos relacionales, los objetos de almacenamiento son tablas que almacenan datos en filas y columnas. En una base de datos de objetos, los objetos de almacenamiento corresponden directamente a los objetos utilizados por el lenguaje de programación orientado a objetos utilizado para escribir las aplicaciones que administrarán y accederán a los datos. Las relaciones se pueden definir como atributos de las clases de objetos involucradas o como métodos que operan sobre las clases de objetos.
La forma en que se realiza generalmente esta asignación es tal que cada conjunto de datos relacionados que dependen de un único objeto, ya sea real o abstracto, se coloca en una tabla. Las relaciones entre estos objetos dependientes se almacenan luego como vínculos entre los diversos objetos.
Cada tabla puede representar una implementación de un objeto lógico o una relación que une una o más instancias de uno o más objetos lógicos. Las relaciones entre tablas pueden almacenarse como vínculos que conectan las tablas secundarias con las tablas principales. Dado que las relaciones lógicas complejas son en sí mismas tablas, probablemente tendrán vínculos con más de una tabla principal.
En el campo del diseño de bases de datos relacionales , la normalización es una forma sistemática de garantizar que la estructura de una base de datos sea adecuada para consultas de propósito general y esté libre de ciertas características indeseables (anomalías de inserción, actualización y eliminación que podrían provocar la pérdida de la integridad de los datos ).
Una guía estándar de diseño de bases de datos es que el diseñador debe crear un diseño completamente normalizado; la desnormalización selectiva se puede realizar posteriormente, pero solo por razones de rendimiento . La compensación es espacio de almacenamiento versus rendimiento. Cuanto más normalizado sea el diseño, menos redundancia de datos habrá (y, por lo tanto, ocupará menos espacio para almacenar); sin embargo, los patrones comunes de recuperación de datos ahora pueden necesitar uniones, fusiones y ordenaciones complejas, lo que requiere más ciclos de lectura y cálculo de datos. Algunas disciplinas de modelado, como el enfoque de modelado dimensional para el diseño de almacenes de datos , recomiendan explícitamente diseños no normalizados, es decir, diseños que en gran parte no se adhieren a 3NF . La normalización consiste en formas normales que son 1NF , 2NF , 3NF, Boyce-Codd NF (3.5NF) , 4NF , 5NF y 6NF .
Las bases de datos de documentos adoptan un enfoque diferente. Un documento almacenado en una base de datos de este tipo normalmente contendría más de una unidad de datos normalizada y, a menudo, también las relaciones entre las unidades. Si todas las unidades de datos y las relaciones en cuestión se recuperan juntas, este enfoque optimiza la cantidad de recuperaciones. También simplifica la forma en que se replican los datos, porque ahora hay una unidad de datos claramente identificable cuya consistencia es autónoma. Otra consideración es que leer y escribir un solo documento en dichas bases de datos requerirá una sola transacción, lo que puede ser una consideración importante en una arquitectura de microservicios . En tales situaciones, a menudo, partes del documento se recuperan de otros servicios a través de una API y se almacenan localmente por razones de eficiencia. Si las unidades de datos se dividieran entre los servicios, entonces una lectura (o escritura) para respaldar a un consumidor de servicio podría requerir más de una llamada de servicio, y esto podría resultar en la gestión de múltiples transacciones, lo que puede no ser preferible.
El diseño físico de la base de datos especifica la configuración física de la base de datos en el medio de almacenamiento. Esto incluye la especificación detallada de los elementos y tipos de datos .
Este paso implica especificar las opciones de indexación y otros parámetros que residen en el diccionario de datos del DBMS . Es el diseño detallado de un sistema que incluye módulos y las especificaciones de hardware y software de la base de datos del sistema. Algunos aspectos que se abordan en la capa física:
A nivel de aplicación, otros aspectos del diseño físico pueden incluir la necesidad de definir procedimientos almacenados, o vistas de consultas materializadas, cubos OLAP , etc.
Los siguientes pasos son sugerencias del proceso de modelado de datos para Microsoft Access , un DBMS relacional.