Diseño de bases de datos

En la mayoría de los casos, la persona que diseña una base de datos es experta en diseño de bases de datos, en lugar de experta en el ámbito 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 específica deben determinarse en colaboración con una persona experta en ese ámbito y que conozca el significado de los datos que se almacenarán en el sistema.

Este proceso se considera generalmente 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 poseen el conocimiento del dominio . Esto se debe a que quienes poseen dicho conocimiento a menudo no pueden expresar con claridad 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 deben almacenarse. Los datos que se almacenarán pueden determinarse mediante la Especificación de Requisitos. ^{[ 2 ]}

Una vez que el diseñador de la base de datos conoce los datos que se almacenarán, debe determinar las dependencias entre ellos. A veces, al modificar datos, se modifican otros datos que no son visibles. Por ejemplo, en una lista de nombres y direcciones, suponiendo que varias personas pueden tener la misma dirección, pero una persona no puede tener más de una, la dirección depende del nombre. Si se proporciona un nombre y la lista, la dirección se puede determinar de forma unívoca; sin embargo, lo contrario no es cierto: si se proporciona una dirección y la lista, un nombre no se puede determinar de forma unívoca porque varias personas pueden residir en una misma dirección. Dado 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í porque establece relaciones entre los elementos de datos que lo componen. Esto no es cierto. El modelo relacional se denomina así porque se basa en las 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 .

Diagrama ER (modelo entidad-relación)

Uno de los tipos más comunes de esquemas conceptuales son los diagramas ER ( modelo entidad-relación ).

En los diagramas ER, los atributos suelen representarse como un óvalo con el nombre del atributo, vinculado a la entidad o relación que contiene dicho 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 ]}

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; la desnormalización selectiva puede realizarse posteriormente, pero solo por razones de rendimiento . ^{[ 4 ]} La compensación es espacio de almacenamiento versus rendimiento. Cuanto más normalizado esté el diseño, menor será la redundancia de datos (y por lo tanto, ocupará menos espacio para almacenar), sin embargo, los patrones comunes de recuperación de datos ahora pueden requerir uniones, fusiones y ordenaciones complejas, lo que consume más ciclos de lectura y cómputo 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 la 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 de estas bases de datos suele contener más de una unidad de datos normalizada y, a menudo, también las relaciones entre dichas unidades. Si todas las unidades de datos y las relaciones en cuestión se recuperan con frecuencia de forma conjunta, este enfoque optimiza el número de recuperaciones. Además, simplifica la replicación de datos, ya que ahora existe una unidad de datos claramente identificable cuya consistencia es autónoma. Otra consideración importante es que la lectura y escritura de un único documento en estas bases de datos requiere una sola transacción, lo cual puede ser crucial en una arquitectura de microservicios . En estos casos, a menudo se recuperan partes del documento de otros servicios mediante una API y se almacenan localmente por motivos de eficiencia. Si las unidades de datos se distribuyeran entre los servicios, una lectura (o escritura) para dar soporte a un consumidor del servicio podría requerir más de una llamada al servicio, lo que podría resultar en la gestión de múltiples transacciones, algo que podría no ser deseable.

El diseño físico de la base de datos especifica la configuración física de la misma en el medio de almacenamiento. Esto incluye la especificación detallada de los elementos de datos y los tipos de datos .

Este paso implica especificar las opciones de indexación y otros parámetros que residen en el diccionario de datos del sistema de gestión de bases de datos (DBMS ). Se trata del diseño detallado de un sistema que incluye módulos y las especificaciones de hardware y software de la base de datos. Algunos aspectos que se abordan en la capa física son:

• Rendimiento: se aborda principalmente mediante la indexación para las consultas de lectura/actualización/eliminación y la elección del tipo de datos para las consultas de inserción.
• Replicación: ¿qué datos se copian a otra base de datos y con qué frecuencia? ¿Hay varios servidores maestros o uno solo?
• Alta disponibilidad: ya sea que la configuración sea activo-pasivo o activo-activo, la topología, el esquema de coordinación, los objetivos de confiabilidad, etc., deben estar definidos.
• Particionamiento: si la base de datos está distribuida, ¿cómo se distribuyen los datos de una sola entidad entre todas las particiones de la base de datos y cómo se tiene en cuenta el fallo de una partición?
• Planes de copia de seguridad y restauración.

A nivel de aplicación, otros aspectos del diseño físico pueden incluir la necesidad de definir procedimientos almacenados, vistas de consulta materializadas, cubos OLAP , etc.