stringtranslate.com

Diseño de base de datos

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 se deben almacenar 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.

Modelado de datos conceptuales

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 .

Determinación de los datos que se almacenarán

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]

Determinación de relaciones de datos

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. Esto no es cierto. El modelo relacional se llama así porque se basa en estructuras matemáticas conocidas como relaciones ).

Esquema conceptual

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)

Ejemplo de diagrama de entidad-relación

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]

Modelado lógico de datos

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 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 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.

Normalización

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 lo preferido.

Diseño físico

Modelado de datos físicos

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 .

Otro diseño físico

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.

Ejemplo: modelado de datos de bases de datos relacionales

Los siguientes pasos son sugerencias del proceso de modelado de datos para Microsoft Access , un DBMS relacional.

  1. Determinar el propósito de la base de datos : esto ayuda a prepararse para los pasos restantes.
  2. Encuentre y organice la información necesaria : reúna todos los tipos de información para registrar en la base de datos, como el nombre del producto y el número de pedido.
  3. Divida la información en tablas : divida los elementos de información en entidades o temas principales, como Productos o Pedidos. Cada tema se convierte entonces en una tabla.
  4. Convierte los elementos de información en columnas : decide qué información se debe almacenar en cada tabla. Cada elemento se convierte en un campo y se muestra como una columna en la tabla. Por ejemplo, una tabla de empleados puede incluir campos como Apellido y Fecha de contratación.
  5. Especificar claves principales : elija la clave principal de cada tabla. La clave principal es una columna o un conjunto de columnas que se utiliza para identificar de forma única cada fila. Un ejemplo podría ser el ID del producto o el ID del pedido.
  6. Establezca las relaciones entre tablas : observe cada tabla y decida cómo se relacionan los datos de una tabla con los de otras tablas. Agregue campos a las tablas o cree tablas nuevas para aclarar las relaciones, según sea necesario.
  7. Refinar el diseño : analizar el diseño para detectar errores. Crear tablas y agregar algunos registros de datos de muestra. Verificar si los resultados de las tablas son los esperados. Realizar ajustes al diseño, según sea necesario.
  8. Aplicar las reglas de normalización : aplique las reglas de normalización de datos para comprobar si las tablas están estructuradas correctamente. Realice los ajustes necesarios en las tablas. [4]

Véase también

Referencias

  1. ^ Teorey, TJ, Lightstone, SS, et al., (2009). Diseño de bases de datos: Conócelo todo. 1.ª ed. Burlington, MA.: Morgan Kaufmann Publishers
  2. ^ Teorey, T.; Lightstone, S. y Nadeau, T. (2005) Modelado y diseño de bases de datos: diseño lógico , 4.ª edición, Morgan Kaufmann Press. ISBN  0-12-685352-5
  3. ^ Javed, Muhammad; Lin, Yuqing (2018). "Proceso iterativo para generar diagramas ER a partir de requisitos sin restricciones". Actas de la 13.ª Conferencia internacional sobre evaluación de nuevos enfoques para la ingeniería de software . SCITEPRESS – Publicaciones científicas y tecnológicas: 192–204. doi : 10.5220/0006778701920204 . ISBN 978-989-758-300-1.
  4. ^ Conceptos básicos de diseño de bases de datos. (sin fecha). Conceptos básicos de diseño de bases de datos. Recuperado el 1 de mayo de 2010 de https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5

Lectura adicional

Enlaces externos