El diseño de bases de datos es la organización de datos según un modelo de base de datos . El diseñador determina qué datos deben almacenarse y cómo se interrelacionan los elementos de datos. Con esta información, pueden comenzar a ajustar los datos al modelo de base de datos. [1] Un sistema de gestión de bases de datos gestiona los datos en consecuencia.
El diseño de bases de datos implica clasificar datos e identificar interrelaciones. Esta representación teórica de los datos se llama ontología .
En la mayoría de los casos, la persona que diseña una base de datos es una persona con experiencia en el área de 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 la base de datos deben determinarse en cooperación con una persona que tenga experiencia en ese dominio y que sepa qué datos deben almacenarse dentro del sistema.
Este proceso 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 quienes tienen el conocimiento del dominio . Esto se debe a que quienes tienen 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 elementos de datos discretos que deben almacenarse. Los datos que se almacenarán pueden determinarse mediante la Especificación de requisitos. [2]
Una vez que un diseñador de bases de datos conoce los datos que se almacenarán dentro de la base de datos, debe determinar dónde se encuentra la dependencia dentro de los datos. A veces, cuando se cambian datos, es posible que se cambien 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 contrario no se cumple: cuando se le da una dirección y la lista, un nombre no se puede determinar de forma única porque varias personas pueden residir en una dirección. Debido a que una dirección está determinada por un nombre, se considera que una dirección depende de un nombre.
(NOTA: Un error común es pensar que el modelo relacional se llama así debido a que establece las relaciones 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 ).
Una vez que se han determinado las relaciones y dependencias entre las distintas piezas 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 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 pueden definirse como atributos de las clases de objetos involucradas o como métodos que operan sobre las clases de objetos.
La forma en que generalmente se realiza este mapeo es tal que cada conjunto de datos relacionados que dependen de un solo 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 distintos 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 se pueden almacenar como enlaces que conectan las tablas secundarias con las principales. Dado que las relaciones lógicas complejas son en sí mismas tablas, probablemente tendrán vínculos con más de un padre.
Los diseños de bases de datos también incluyen diagramas ER ( modelo entidad-relación ). Un diagrama ER es un diagrama que ayuda a diseñar bases de datos de forma eficiente.
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 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]
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 para el diseño de bases de datos es que el diseñador debe crear un diseño completamente normalizado; Posteriormente se puede realizar una desnormalización selectiva , pero sólo por motivos de rendimiento . La compensación es espacio de almacenamiento versus rendimiento. Cuanto más normalizado esté el diseño, menos redundancia de datos habrá (y por lo tanto, se necesita menos espacio para almacenarlos); sin embargo, los patrones comunes de recuperación de datos ahora pueden necesitar uniones, fusiones y clasificaciones complejas, lo que requiere más datos. ciclos de lectura y cálculo. 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 consta de formas normales que son 1NF,2NF,3NF,BOYCE-CODD NF (3.5NF),4NF y 5NF
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 normalizados y, a menudo, también las relaciones entre las unidades. Si todas las unidades de datos y las relaciones en cuestión suelen recuperarse juntas, este enfoque optimiza el número de recuperaciones. También simplifica cómo se replican los datos, porque ahora hay una unidad de datos claramente identificable cuya coherencia 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 servicios podría requerir más de una llamada de servicio, y esto podría dar lugar a la gestión de múltiples transacciones, lo que puede no ser el preferido.
El diseño físico de la base de datos especifica la configuración física de la base de datos en los medios de almacenamiento. Esto incluye especificaciones detalladas de elementos de datos , tipos de datos , opciones de indexación y otros parámetros que residen en el diccionario de datos 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.