Modelos para el diseño de sistemas basados ​​en bases de datos. Etapas del diseño de una base de datos. Etapa V. Síntesis de un modelo informático de un objeto.

Se pueden distinguir las siguientes etapas del desarrollo de una base de datos:

· diseño;

· implementación de software;

· llenado y funcionamiento.

La etapa de diseño es construcción teórica el modelo de información de la base de datos original. Incluye:

· recopilación de información sobre el área temática, su estructura, flujos de información de entrada y salida de datos, estudio de tareas de automatización, análisis y selección de objetos sistema original y determinar las conexiones entre ellos;

· determinación de propiedades y características de cada objeto en la base de datos, a qué campos (atributos) se asignan, se compilan las tablas fuente y las relaciones entre ellas, se determinan los elementos de datos incluidos en la base de datos, las restricciones sobre los valores de los datos, etc.

· asignación de claves primarias (campos) para cada objeto y normalización (particionamiento) de tablas fuente;

· verificar la exactitud del proyecto, que debe mostrar todos los objetos seleccionados, sus atributos y procesos descritos en el nivel de detalle requerido, mostrar el área temática que requiere resolver el problema;

· definición estructura lógica bases de datos;

· resolver problemas de protección y mantenimiento de la integridad de la base de datos. Garantizar la integridad de los datos se refiere a un sistema de medidas destinadas a mantener la exactitud de los datos en la base de datos en cualquier momento.

La etapa de implementación de software está asociada al desarrollo de aplicaciones en una computadora, para lo cual se deben realizar los siguientes pasos:

· describir las tablas resultantes usando un DBMS e ingresarlas en la computadora;

· para los usuarios del sistema de información, desarrollar interfaces para trabajar con la base de datos, es decir, formularios de pantalla para ingresar y mostrar datos, informes para imprimir datos resumidos, consultas para obtener datos;

· desarrollar un procedimiento para mantener y mantener la base de datos en funcionamiento, trabajo usuarios finales;

· probar el sistema, redactar instrucciones para trabajar con él y formar al personal.

La fase de operación y llenado comienza con el llenado de la base de datos con datos específicos. Incluye el mantenimiento directo de la base de datos y su mantenimiento.

Al desarrollar bases de datos para grandes empresas y corporaciones, el análisis y modelado se realizan utilizando herramientas de software especiales, como las herramientas CASE, que permiten modelar flujos de datos, procesos y funciones de la empresa, identificar cuellos de botella y hacer recomendaciones para la organización eficaz de la empresa. Estructura y procesos de negocio en la empresa.

Además de construir modelos del estado actual de la empresa y realizar análisis, el software de modelado le permite crear especificaciones y construir un proyecto. sistema futuro Además, se puede obtener el código de programa para los DBMS más comunes. Así, la etapa de modelado puede abarcar la etapa de diseño y parte de la etapa de implementación del sistema de información.

Diseño conceptual de bases de datos.

La primera fase del proceso de diseño de una base de datos se denomina diseño conceptual de la base de datos. Consiste en crear modelo conceptual datos para la parte analizada de los objetos del sistema en estudio. Este modelo de datos se crea en base a la información registrada en las especificaciones de requisitos del usuario. El diseño conceptual de una base de datos es absolutamente independiente de detalles de su implementación como el tipo de DBMS seleccionado, el conjunto de programas de aplicación a crear, los lenguajes de programación utilizados, el tipo de base de datos seleccionado. plataforma informática, así como de cualquier otra característica implementación física. El modelo de datos conceptual creado es la fuente de información para la fase. diseño lógico bases de datos.

Diseño de bases de datos lógicas

La segunda fase del diseño de una base de datos se denomina diseño lógico de una base de datos. Su propósito es crear un modelo de datos lógico. El modelo de datos conceptual creado en el paso anterior se refina y transforma en un modelo de datos lógico. El modelo de datos lógico tiene en cuenta las características del modelo de organización de datos seleccionado en el DBMS (por ejemplo, un modelo relacional o de red).

Si el modelo de datos conceptual no depende de ningún aspecto físico de la implementación, entonces el modelo de datos lógico se crea basándose en el modelo de organización de datos seleccionado en el DBMS. En otras palabras, en esta etapa ya debería saberse qué DBMS se utilizará: relacional, de red, jerárquico u orientado a objetos. Sin embargo, en esta etapa, se ignoran todos los demás aspectos del DBMS seleccionado, por ejemplo, cualquier característica de la organización física de sus estructuras de almacenamiento de datos y la construcción de índices.

Durante el proceso de desarrollo, el modelo de datos lógicos se prueba y verifica constantemente para garantizar que cumpla con los requisitos del usuario. Para comprobar la exactitud del modelo de datos lógico, se utiliza el método de normalización. La normalización garantiza que las relaciones derivadas del modelo de datos existente no tengan redundancia de datos que pueda causar anomalías en las actualizaciones después de que se implementen físicamente. Entre otras cosas, el modelo de datos lógico debe soportar todas las transacciones requeridas por los usuarios.

El modelo de datos lógico construido informa la fase de diseño físico y proporciona al diseñador de la base de datos física los medios para hacer las concesiones necesarias para lograr los objetivos establecidos, lo cual es muy importante para un diseño eficaz. El modelo lógico de datos también juega papel importante en la etapa de operación y mantenimiento de un sistema listo para usar. Con un soporte adecuadamente organizado, un modelo de datos actualizado le permite representar con precisión y claridad cualquier cambio realizado en la base de datos y evaluar su impacto en los programas de aplicación.

Normalización de bases de datos

Al diseñar bases de datos, lo más importante es definir las estructuras de las tablas y las relaciones entre ellas. Los errores en la estructura de datos son difíciles, y a menudo imposibles, de corregir mediante programación. Cuanto mejor sea la estructura de los datos, más fácil será programar la base de datos. La teoría del diseño de bases de datos contiene el concepto de formas normales destinadas a optimizar la estructura de la base de datos. Las formas normales son una secuencia lineal de reglas aplicadas a la base de datos, y cuanto mayor sea el número de la forma normal, más perfecta será la estructura de la base de datos. La normalización es un proceso de varios pasos en el que las tablas de la base de datos se organizan, separan y los datos se ordenan. El propósito de la normalización es eliminar algunas características indeseables de la base de datos. En particular, el objetivo es eliminar algunos tipos de redundancia de datos y así evitar anomalías cuando los datos cambian. Las anomalías en el cambio de datos son dificultades durante la inserción, modificación y eliminación de datos que surgen debido a la estructura de la base de datos. Aunque hay muchos niveles, normalmente basta con normalizar a la Tercera Forma Normal.

Consideremos un ejemplo de normalización de la base de datos de gestión de entrega de pedidos. Una base de datos de "Ventas" desordenada constaría de una tabla (Fig. 7).

Fig.7. DB "Ventas"

En la tabla, cada registro contiene información sobre varios pedidos de un cliente. Debido a que la columna de información del producto contiene demasiados datos, es difícil obtener información organizada de esta tabla (por ejemplo, crear un informe sobre las compras totales de varios tipos de productos).

Primera forma normal

La primera forma normal determina la atomicidad de todos los datos contenidos en las columnas. La palabra "átomo" proviene del latín "atomis", que literalmente significa "no divisible". La primera forma normal especifica que solo hay un valor en cada posición definida por fila y columna, en lugar de una matriz o lista de valores. Los beneficios de este requisito son obvios: si las listas de valores se almacenan en una sola columna, no hay una manera fácil de manipular esos valores. Por supuesto, esto aumenta la cantidad de registros en la tabla.

Normalicemos la base de datos "Ventas" a la primera forma normal (Fig. 8).

Fig.8. Primera forma normal

3.3.2. Segunda forma normal

Puede pasar a la Segunda Forma Normal desde una tabla que ya corresponde a la Primera Forma Normal. Además, se debe cumplir la siguiente condición: cada campo que no sea clave debe depender completamente de la clave principal.

Normalicemos la base de datos "Ventas" a la segunda forma normal. Separaremos toda la información no relacionada con pedidos individuales en una tabla separada. Como resultado, en lugar de una tabla de "Ventas", obtenemos dos: la tabla de "Pedidos" (Fig. 9) y la tabla de "Productos" (Fig. 10).

Fig.9. Tabla "Pedidos"

Figura 10. Tabla "Productos"

Por tanto, el tipo de producto se almacena en una sola tabla. Tenga en cuenta que no se pierde información durante la normalización.

3.3.3. Tercera forma normal

Se considera que una tabla se ajusta a la Tercera Forma Normal si se ajusta a la Segunda Forma Normal y todas las columnas que no son clave son mutuamente independientes. Una columna cuyos valores se derivan de datos de otras columnas es un ejemplo de dependencia.

Normalicemos la base de datos "Ventas" a la tercera forma normal. Para hacer esto, elimine la columna "Total" de la tabla "Pedidos". Los valores de esta columna no dependen de ninguna clave y se pueden calcular mediante la fórmula ("Precio")*("Cantidad"). Así, se obtuvo la base de datos “Ventas” con estructura optima, que consta de dos tablas (Fig. 11).

Arroz. 11. Base de datos normalizada "Ventas"

3.2 Implementación del software de la base de datos.

La implementación del software de la base de datos se lleva a cabo mediante la creación de un DBMS de destino en el lenguaje de definición de datos (DDL). Los comandos DDL se compilan y utilizan para crear esquemas y archivos vacios bases de datos. En la misma etapa, se definen todas las vistas de usuario específicas.

Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación. Algunos elementos de estos programas de aplicación serán transacciones de procesamiento de bases de datos escritas en el lenguaje de manipulación de datos (DML) del DBMS de destino y llamadas desde programas en lenguaje básico programación, por ejemplo, en Visual Basic, C++, Java. Esta fase también crea otros componentes del proyecto de aplicación, como pantallas de menú, formularios de entrada de datos e informes. Hay que tener en cuenta que muchos DBMS existentes tienen sus propios propias herramientas desarrollos que le permiten crear rápidamente aplicaciones utilizando lenguajes de consulta no procedimentales, una variedad de generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.

Esta etapa también implementa las funciones de soporte de integridad y protección de la base de datos de la aplicación. Algunos de ellos se describen utilizando DDL, mientras que otros pueden necesitar definirse por otros medios, por ejemplo, utilizando utilidades DBMS adicionales o creando programas de aplicación que implementen las funciones requeridas.

3.2.1. Desarrollo de aplicaciones

El desarrollo de aplicaciones es el diseño de una interfaz de usuario y programas de aplicación diseñados para trabajar con una base de datos. En la mayoría de los casos, el diseño de la aplicación no se puede completar hasta que se complete el diseño de la base de datos. Por otro lado, la base de datos está diseñada para soportar aplicaciones y, por lo tanto, debe intercambiarse información constantemente entre las fases de diseño de la base de datos y diseño de aplicaciones para esa base de datos.

Debe asegurarse de que toda la funcionalidad requerida por las especificaciones de requisitos del usuario sea compatible con la interfaz de usuario de las aplicaciones relevantes. Esto se aplica tanto al diseño de programas de aplicación para acceder a la información de la base de datos como al diseño de transacciones, es decir. Diseñar métodos de acceso a bases de datos.

Además de diseñar cómo el usuario puede acceder a la funcionalidad que necesita, también se debe diseñar la forma adecuada. interfaz de usuario aplicaciones de bases de datos. Esta interfaz debe proporcionar la información que el usuario necesita de la forma que más le convenga.

3.2.2 Pruebas de bases de datos

La prueba es el proceso de ejecutar programas de aplicación para encontrar errores. Antes de utilizar un nuevo sistema en la práctica, se debe probar minuciosamente. Esto se puede lograr desarrollando un algoritmo de prueba bien pensado utilizando datos reales, que deben estructurarse de tal manera que todo el proceso de prueba se lleve a cabo de manera estrictamente secuencial y metódicamente correcta. La tarea de probar no es el proceso de demostrar la ausencia de errores; es poco probable que sea posible demostrar la ausencia de errores en el software; por el contrario, solo puede mostrar su presencia. Si las pruebas se realizan con éxito, seguramente se revelarán errores en los programas de aplicación y en las estructuras de las bases de datos. Como subproducto, las pruebas sólo pueden demostrar que la base de datos y los programas de aplicación funcionan dentro de sus especificaciones y al mismo tiempo cumplen con los requisitos de rendimiento existentes. Además, la recopilación de datos estadísticos en la etapa de prueba nos permite establecer indicadores de confiabilidad y calidad del software creado.

Al igual que con el diseño de bases de datos, los usuarios del nuevo sistema deben participar en el proceso de prueba. Idealmente, las pruebas del sistema deberían realizarse en un conjunto de equipos separado, pero a menudo esto simplemente no es posible. Cuando se utilizan datos reales, es importante crearlos primero. copias de seguridad, en caso de que resulten dañados como consecuencia de errores. Una vez finalizadas las pruebas, el proceso de creación de un sistema de aplicación se considera completo y puede transferirse a operación industrial.

3.3 Operación y mantenimiento de la base de datos

Operación y mantenimiento: soporte para el funcionamiento normal de la base de datos.

En los pasos anteriores, la aplicación de base de datos se implementó y probó completamente. El sistema está entrando ahora en la etapa final de su ciclo vital, llamado operación y mantenimiento. Incluye realizar acciones como:

· seguimiento del rendimiento del sistema. Si el rendimiento cae por debajo de niveles aceptables, es posible que sea necesaria una reorganización adicional de la base de datos;

· mantenimiento y modernización (si es necesario) de aplicaciones de bases de datos. Se incorporan nuevos requisitos a la aplicación de base de datos cuando se vuelven a ejecutar los pasos anteriores del ciclo de vida.

Una vez que la base de datos se pone en uso, su funcionamiento debe monitorearse continuamente para garantizar que el desempeño y otros indicadores cumplan con los requisitos. Un DBMS típico normalmente proporciona varias utilidades administración de bases de datos, incluidas utilidades para cargar datos y monitorear el funcionamiento del sistema. Utilidades similares son capaces de monitorear el rendimiento del sistema y proporcionar información sobre varias métricas, como los niveles de utilización de la base de datos, la efectividad del sistema de bloqueo (incluido el número de interbloqueos que se han producido) y las estrategias de ejecución de consultas elegidas. El administrador de la base de datos puede utilizar esta información para ajustar el sistema y mejorar su rendimiento (por ejemplo, creando índices adicionales), acelerar la ejecución de consultas, cambiar estructuras de almacenamiento, fusionar o dividir tablas individuales.

El proceso de monitoreo debe mantenerse durante toda la vida de la aplicación, permitiendo una reorganización efectiva de la base de datos en cualquier momento para cumplir con los requisitos cambiantes. Dichos cambios brindan información sobre las mejoras más probables a la base de datos y los recursos que pueden ser necesarios en el futuro. Si el DBMS que está utilizando no tiene algunas de las utilidades necesarias, entonces el administrador deberá desarrollarlas él mismo o comprar las necesarias. herramientas adicionales de desarrolladores externos.

4. SGBD de Microsoft Access

4.1. Propósito y información general acerca del SGBD de Microsoft Access

sistema microsoft Access es un sistema de gestión de bases de datos, utiliza un modelo de datos relacional y es parte de un paquete de aplicación. oficina de microsoft. Está diseñado para almacenar, ingresar, buscar y editar datos, así como para mostrarlos de una forma conveniente.

Las áreas de aplicación de Microsoft Access incluyen las siguientes:

· en pequeñas empresas (contabilidad, registro de pedidos, mantenimiento de información de clientes, mantenimiento de información sobre contactos comerciales);

· en grandes corporaciones (aplicaciones para grupos de trabajo, sistemas de procesamiento de información);

· como DBMS personal (directorio de direcciones, gestión de carteras de inversiones, libros de cocina, catálogos de libros, discos, vídeos, etc.).

Access es uno de los sistemas de gestión de bases de datos más potentes, convenientes y sencillos. Porque Access está incluido en composición de microsoft Office, tiene muchas de las mismas características que las aplicaciones de Office y puede intercambiar información con ellas. Por ejemplo, cuando trabaja en Access, puede abrir y editar archivos y usar el portapapeles para copiar datos de otras aplicaciones.

Las herramientas para desarrollar objetos en Access son "asistentes" y "constructores". Este programas especiales, que se utilizan para crear y editar tablas, consultas, varios tipos de formularios e informes. Normalmente, el "maestro" se utiliza para crear y el "constructor" se utiliza para editar objetos. El proceso de edición implica cambiar la apariencia de algún objeto para mejorarlo. Al editar un formulario, puede cambiar los nombres y el orden de los campos, aumentar o disminuir el tamaño del área de entrada de datos, etc. Puede utilizar el "constructor" para crear formularios, pero este es un trabajo que requiere mucha mano de obra. Access incluye herramientas de software especiales que le ayudan a analizar estructuras de datos, importar hojas de cálculo y datos de texto, mejorar el rendimiento de las aplicaciones y crear y personalizar aplicaciones utilizando plantillas integradas. Para automatizar completamente sus aplicaciones, puede utilizar macros para vincular datos a formularios e informes.

Access implementa la gestión de bases de datos relacionales. El sistema admite claves primarias y externas. Garantiza la integridad de los datos a nivel del kernel, lo que no permite operaciones de actualización o eliminación incompatibles. Las tablas en Access están equipadas con herramientas de validación de datos, es decir. No se permiten entradas no válidas. Cada campo de la tabla tiene su propio formato y descripciones estándar, lo que facilita la entrada de datos. Access admite los siguientes tipos de campos, incluidos: tabulador, texto, numérico, contador, moneda, fecha/hora, MEMO, booleano, hipervínculo, objeto OLE, adjunto y campos calculados. Si no hay valores en los campos, el sistema proporciona apoyo total valores vacíos.

En Access puedes usar herramientas graficas, como en Microsoft Word, Excel, PowerPoint y otras aplicaciones que le permiten crear varios tipos gráficos y diagramas. Puede crear histogramas, gráficos 2D y 3D. Puede agregar todo tipo de objetos a los formularios e informes de Access: imágenes, diagramas, clips de audio y vídeo. Al vincular estos objetos a una base de datos desarrollada, se pueden crear formularios e informes dinámicos. También puedes utilizar macros en Access para automatizar determinadas tareas. Le permiten abrir y cerrar formularios e informes, crear menús y cuadros de diálogo para automatizar la creación de diversas tareas de la aplicación.

En Access, puede obtener ayuda contextual haciendo clic en y aparecerá la pantalla información de fondo sobre el tema que interesa al usuario en ese momento. Al mismo tiempo, puede navegar fácilmente a la tabla de contenido del sistema de ayuda, información específica, un historial de accesos anteriores y marcadores. La información de la base de datos se almacena en un archivo con la extensión .accdb.

4.2. Objetos de Microsoft Acceso

Cuando inicia Access DBMS, aparece una ventana para crear una nueva base de datos o para trabajar con bases de datos creadas previamente o plantillas existentes (Fig. 12).

Arroz. 12. Acceso de lanzamiento

Las plantillas son estructuras de bases de datos vacías en las que se definen tipos de campos, se crean objetos básicos, se establecen relaciones entre tablas, etc.

Al crear una nueva base de datos Acceder a los datos abrirá una tabla vacía que contiene una fila y dos columnas (Figura 13).

Figura 13. Nueva ventana de base de datos

El lado izquierdo de la ventana (área de navegación) muestra todos los objetos de la base de datos creados, mientras que solo vemos una tabla vacía, porque los objetos creados ya no están en la nueva base de datos (Fig. 13). Los principales objetos del DBMS de Access incluyen los siguientes.

Mesas. Las tablas son los objetos principales de las bases de datos porque almacenan todos los datos y definen la estructura de la base de datos. Una base de datos puede contener miles de tablas, cuyos tamaños están limitados únicamente por espacio disponible en el disco duro de la computadora. La cantidad de registros en las tablas está determinada por el tamaño del disco duro y la cantidad de campos no supera los 255.

Las tablas en Access se pueden crear de la siguiente manera:

· en modo “diseñador”;

· en el modo de introducir datos en una tabla.

Puede crear una tabla importando o creando un enlace a datos almacenados en otro lugar. Esto se puede hacer, por ejemplo, con datos almacenados en un archivo Excel, en lista de ventanas SharePoint Services, archivo XML, otra base de datos de MS ACCESS. Una lista de SharePoint le permite brindar acceso a datos a usuarios que no tienen instalada la aplicación MS ACCESS. Cuando importa datos, se crea una copia de ellos en una nueva tabla en la base de datos actual. Los cambios posteriores realizados en los datos originales no afectarán los datos importados y viceversa. Cuando se realiza el enlace de datos, se crea una tabla vinculada en la base de datos actual que proporciona una conexión dinámica a los datos almacenados en otro lugar. Los cambios en los datos de una tabla vinculada se reflejan en la fuente y los cambios en la fuente se reflejan en la tabla vinculada.

La vista Hoja de datos muestra los datos almacenados en la tabla, mientras que la vista Diseño muestra la estructura de la tabla.

Si las tablas tienen campos comunes, puede usar una subtabla para insertar registros de otra en una tabla. Este enfoque le permite ver simultáneamente datos de varias tablas.

Solicitudes. Las solicitudes son medios especiales, diseñado para buscar y analizar información en tablas de bases de datos que cumplan ciertos criterios. Los registros encontrados, llamados resultados de la consulta, se pueden ver, editar y analizar. de varias maneras. Además, los resultados de una consulta se pueden utilizar como base para crear otros objetos de Access. Existen diferentes tipos de consultas, las más comunes son las consultas de selección, las consultas paramétricas y cruzadas, las consultas de eliminación de registros, las consultas de cambio y otras. Se utilizan con menos frecuencia las consultas de acción y las consultas SQL (lenguaje de consulta estructurado). Si la solicitud deseada no, entonces se puede crear adicionalmente.

Las solicitudes se generan de varias maneras, por ejemplo, usando el "asistente" también puede crear una solicitud manualmente en el modo "diseñador"; El tipo de consulta más simple y más utilizado es la consulta de selección. Estas consultas seleccionan datos de una o más tablas y los forman nueva mesa, cuyas entradas se pueden modificar. Las consultas seleccionadas se utilizan para calcular sumas, promedios y otros totales. Por tanto, las consultas utilizan datos de las tablas principales y crean tablas temporales.

Formularios. Los formularios se utilizan para ingresar y editar registros en tablas de bases de datos. Los formularios se pueden mostrar en tres modos: un modo para entrada de datos, un modo de tabla donde los datos se presentan en formato tabular y un modo de "diseño" que le permite realizar cambios y adiciones a los formularios.

Los elementos principales del formulario son las inscripciones, que indican el texto que se muestra directamente en el formulario, y los campos que contienen los valores de los campos de la tabla. Aunque el modo Generador le permite crear un formulario desde cero, normalmente se utiliza para refinar y mejorar los formularios creados con el Asistente. Además de las herramientas anteriores, también se pueden crear formularios utilizando las siguientes herramientas:

· "forma";

· “forma dividida”;

· “varios elementos”;

· "formulario vacío".

Es más eficaz utilizar formularios para la entrada de datos en forma de formularios especiales, ya que el formulario puede parecerse a un formulario. El uso de formularios le permite ingresar datos en una forma fácil de usar en documentos familiares. Los formularios de E/S le permiten ingresar datos en la base de datos, verlos, cambiar valores de campos, agregar y eliminar registros. El formulario puede contener un botón utilizado para imprimir un informe, abrir otros objetos o ejecución automática otras tareas.

Informes. Los informes se utilizan para mostrar información en tablas en un formato que se presenta claramente tanto en la pantalla del monitor como en papel. Un informe es un medio eficaz para imprimir datos de una base de datos en la forma requerida por el usuario (en forma de certificados, exámenes, tablas, etc.). Además de los datos extraídos de múltiples tablas y consultas, los informes pueden incluir elementos de diseño que se encuentran en documentos impresos, como títulos, encabezados y pies de página.

El informe se puede mostrar en cuatro modos: en el modo "diseñador", que le permite cambiar la apariencia del informe, en el modo de visualización de muestra, en el que puede mostrar todos los elementos del informe terminado, pero en forma abreviada. formulario, en el modo "diseño", que le permite mostrarlo más claramente (en comparación con el modo de diseño) y formatear el informe, y en avance, donde se muestra el informe tal como será impreso.

Tablas, consultas, formularios e informes son los objetos más utilizados en el desarrollo de bases de datos de Access.

Sin embargo, las capacidades de la base de datos se pueden ampliar significativamente mediante el uso de páginas de acceso, macros y módulos.

Paginas. Para proporcionar a los usuarios de Internet acceso a la información, se pueden crear páginas especiales de acceso a datos en la base de datos. Al utilizar las páginas de acceso a datos, puede ver, agregar, cambiar y manipular datos almacenados en la base de datos. Las páginas de acceso a datos también pueden contener datos de otras fuentes, como Excel. Para publicar información de una base de datos en Acceso web incluir un “asistente” que proporcione la creación de una página de acceso.

Macros. Las macros son pequeños programas de uno o más comandos de macro que realizan operaciones específicas, como abrir un formulario, imprimir informes, hacer clic en un botón, etc. Esto es especialmente útil si planea compartir la base de datos con usuarios no calificados. Por ejemplo, puede escribir macros que contengan una secuencia de comandos que realicen tareas rutinarias, o asociar acciones como abrir un formulario o imprimir un informe con botones en un pulsador.

Módulos Un módulo es un objeto de base de datos que le permite crear bibliotecas de rutinas y funciones utilizadas en toda la aplicación. Usando códigos de módulo, puede resolver problemas como manejar errores de entrada, declarar y usar variables, organizar bucles, etc.

La esencia del diseño de una base de datos, como cualquier otro proceso de diseño, es crear una descripción de un nuevo sistema que no ha existido previamente en esta forma, que, una vez implementado, sea capaz de funcionar en condiciones apropiadas. De esto se deduce que las etapas del diseño de la base de datos deben reflejar de manera consistente y lógica la esencia de este proceso.

Contenidos del diseño y puesta en fase de la base de datos.

La intención del diseño se basa en alguna necesidad social formulada. Esta necesidad tiene un entorno para su aparición y un público objetivo de consumidores que utilizarán el resultado del diseño. En consecuencia, el proceso de diseño de una base de datos comienza con el estudio de una necesidad determinada desde el punto de vista de los consumidores y el entorno funcional de su ubicación prevista. Es decir, la primera etapa consiste en recopilar información y definir un modelo del área temática del sistema, así como examinarlo desde el punto de vista del público objetivo. En general, para determinar los requisitos del sistema, se determina el alcance de las actividades así como los límites de las aplicaciones de bases de datos.

A continuación, el diseñador, que ya tiene ciertas ideas sobre lo que necesita crear, aclara las tareas supuestamente resueltas por la aplicación, crea una lista de ellas (especialmente si el desarrollo del proyecto es una base de datos grande y compleja), aclara la secuencia de resolución. problemas y realiza análisis de datos. Este proceso también es un proceso paso a paso. trabajo de proyecto, pero generalmente en una estructura de diseño estos pasos se absorben en el escenario diseño conceptual– la etapa de identificación de objetos, atributos, conexiones.

La creación de un conceptual (modelo de información) implica la formación preliminar de requisitos conceptuales del usuario, incluidos los requisitos para aplicaciones que pueden no implementarse de inmediato, pero teniendo en cuenta cuáles mejorarán la funcionalidad del sistema en el futuro. Al tratar con representaciones de conjuntos de objetos abstractos (sin especificar métodos de almacenamiento físico) y sus relaciones, el modelo conceptual corresponde esencialmente al modelo de dominio. Por eso, en la literatura, la primera etapa del diseño de una base de datos se denomina diseño infológico.

A continuación, le sigue una etapa separada (o una adición a la anterior) a la etapa de formación de requisitos para el entorno operativo, donde se evalúan los requisitos de los recursos informáticos capaces de garantizar el funcionamiento del sistema. En consecuencia, cuanto mayor sea el volumen de la base de datos diseñada, mayor actividad del usuario y la intensidad de las solicitudes, mayores son los requisitos que se imponen a los recursos: en la configuración de la computadora, en el tipo y la versión Sistema operativo. Por ejemplo, el modo de funcionamiento multiusuario de la futura base de datos requiere conexión de red utilizando un sistema operativo adecuado para la multitarea.

El siguiente paso es que el diseñador seleccione un sistema de gestión de bases de datos (DBMS), así como herramientas de naturaleza programática. Posteriormente, el modelo conceptual debe ser transferido a un modelo de datos compatible con el sistema de gestión seleccionado. Pero a menudo esto implica realizar modificaciones y cambios en el modelo conceptual, ya que las interconexiones entre los objetos reflejados en el modelo conceptual no siempre se pueden implementar utilizando los medios de un DBMS determinado.

Esta circunstancia determina el surgimiento de la siguiente etapa: el surgimiento de un modelo conceptual provisto de los medios de un DBMS específico. este paso Corresponde a la etapa de diseño lógico (creación de un modelo lógico).

Finalmente, la etapa final del diseño de una base de datos es el diseño físico: la etapa de vincular la estructura lógica y el entorno de almacenamiento físico.

Así, las principales etapas del diseño de forma detallada se presentan en las siguientes etapas:

• diseño de información,
• formación de requisitos para el entorno operativo
• selección del sistema de control y software de base de datos,
• diseño lógico,
• diseño físico

Los principales se analizarán con más detalle a continuación.

Diseño infológico

La identificación de entidades forma la base semántica del diseño infológico. Una entidad aquí es un objeto (abstracto o concreto), cuya información se acumulará en el sistema. En el modelo de información del área temática en fácil de usar En términos que no dependen de la implementación específica de la base de datos, se describen la estructura y propiedades dinámicas del área temática. Pero los términos se toman en una escala estándar. Es decir, la descripción no se expresa a través de objetos individuales del área temática y sus relaciones, sino a través de:

• descripción de tipos de objetos,
• restricciones de integridad asociadas con el tipo descrito,
• procesos que conducen a la evolución de un área temática: su transición a otro estado.

Se puede crear un modelo de información utilizando varios métodos y enfoques:

1. El enfoque funcional se basa en las tareas asignadas. Se denomina funcional porque se utiliza si se conocen las funciones y tareas de las personas que atenderán sus necesidades de información con ayuda de la base de datos diseñada.
2. El enfoque temático se centra en la información sobre la información que estará contenida en la base de datos, a pesar de que es posible que la estructura de la consulta no esté definida. En este caso, la investigación en un área temática se centra en su visualización más adecuada en la base de datos en el contexto de toda la gama de solicitudes de información esperadas.
3. Un enfoque integrado que utiliza el método “entidad-relación” combina las ventajas de los dos anteriores. El método se reduce a dividir toda el área temática en partes locales, que se modelan por separado y luego se combinan nuevamente para formar un área completa.

Dado que el uso del método entidad-relación es un método de diseño combinado para en esta etapa, se convierte en una prioridad con más frecuencia que otros.

Cuando se dividen metódicamente, las representaciones locales deben, si es posible, incluir información que sea suficiente para resolver un problema separado o para satisfacer las necesidades de un determinado grupo de usuarios potenciales. Cada una de estas áreas contiene entre 6 y 7 entidades y corresponde a una aplicación externa independiente.

La dependencia de las entidades se refleja en su división en fuertes (base, padre) y débiles (hijo). Una entidad fuerte (por ejemplo, un lector en una biblioteca) puede existir en la base de datos por sí sola, pero una entidad débil (por ejemplo, la suscripción de este lector) está "adjunta" a una fuerte y no existe por separado.

Es necesario separar los conceptos de "instancia de entidad" (un objeto caracterizado por valores de propiedad específicos) y el concepto de "tipo de entidad", un objeto caracterizado por un nombre común y una lista de propiedades.

Para cada entidad individual se seleccionan atributos (un conjunto de propiedades) que, según el criterio, pueden ser:

• identificando (con un valor único para entidades de ese tipo, haciéndolas claves potenciales) o descriptivo;
• de un solo valor o de varios valores (con el número apropiado de valores para una instancia de entidad);
• básico (independiente de otros atributos) o derivado (calculado en base a los valores de otros atributos);
• simple (un componente indivisible) o compuesto (combinado de varios componentes).

Después de esto, se especifica el atributo, las conexiones se especifican en la vista local (divididas en opcionales y obligatorias) y las vistas locales se fusionan. Si el número de áreas locales es de hasta 4 o 5, se pueden combinar en un solo paso. . Si el número aumenta, la fusión binaria de áreas se produce en varias etapas.

Durante esta y otras etapas intermedias, se refleja el carácter iterativo del diseño, que se expresa aquí en el hecho de que para eliminar contradicciones es necesario volver a la etapa de modelar representaciones locales para su aclaración y cambio (por ejemplo, para cambiar los mismos nombres de objetos semánticamente diferentes o para coordinar atributos de integridad en los mismos atributos en diferentes aplicaciones).

Selección de un sistema de control y software de base de datos.

La elección del sistema de gestión de bases de datos depende implementación práctica sistema de información. Los criterios más importantes en el proceso de selección son los siguientes parámetros:

• tipo de modelo de datos y su conformidad con las necesidades del área temática,
• reserva de posibilidades en caso de ampliación del sistema de información,
• características de rendimiento del sistema seleccionado,
• confiabilidad operativa y conveniencia del DBMS,
• herramientas dirigidas al personal de administración de datos,
• el costo del DBMS en sí y el software adicional.

Es casi seguro que los errores al elegir un DBMS provocarán posteriormente la necesidad de ajustar los modelos conceptuales y lógicos.

Diseño de base de datos lógica

La estructura lógica de la base de datos debe corresponder al modelo lógico del área temática y tener en cuenta la conexión del modelo de datos con el DBMS compatible. Por tanto, la etapa comienza con la elección de un modelo de datos, donde es importante tener en cuenta su sencillez y claridad.

Es preferible que la estructura natural de los datos coincida con el modelo que la representa. Entonces, por ejemplo, si los datos se presentan en forma de estructura jerárquica, entonces es mejor elegir un modelo jerárquico. Sin embargo, en la práctica, esta elección suele estar determinada por el sistema de gestión de la base de datos y no por el modelo de datos. Por lo tanto, el modelo conceptual se traduce realmente en un modelo de datos que es compatible con el sistema de gestión de bases de datos seleccionado.

Esto también refleja la naturaleza del diseño, que permite la posibilidad (o necesidad) de regresar al modelo conceptual para cambiarlo si las relaciones entre objetos (o atributos de objetos) allí reflejadas no pueden implementarse utilizando el DBMS elegido.

Al finalizar la etapa se deben generar esquemas de bases de datos de ambos niveles de arquitectura (conceptual y externo), creados en el lenguaje de definición de datos soportado por el SGBD seleccionado.

Los esquemas de bases de datos se forman utilizando uno de dos enfoques diferentes:

• o utilizando un enfoque ascendente, cuando el trabajo se realiza desde niveles más bajos definir atributos agrupados en relaciones que representan objetos basados ​​en relaciones existentes entre atributos;
• o utilizar un enfoque inverso, de arriba hacia abajo, que se utiliza cuando el número de atributos aumenta significativamente (hasta cientos y miles).

El segundo enfoque implica definir una serie de entidades de alto nivel y sus relaciones con detalles posteriores para el nivel requerido, lo que se refleja, por ejemplo, en un modelo creado a partir del método “entidad-relación”. Pero en la práctica ambos enfoques suelen combinarse.

Diseño de base de datos física.

En siguiente etapa En el diseño físico de la base de datos, la estructura lógica se muestra en forma de una estructura de almacenamiento de base de datos, es decir, está vinculada a un entorno de almacenamiento físico donde los datos se colocarán de la manera más eficiente posible. Aquí se describe en detalle el esquema de datos, indicando todos los tipos, campos, tamaños y restricciones. Además de desarrollar índices y tablas, se definen consultas básicas.

La construcción de un modelo físico implica resolver problemas en gran medida contradictorios:

1. tareas de minimizar el espacio de almacenamiento de datos,
2. retos para lograr integridad, seguridad y máximo rendimiento.

La segunda tarea entra en conflicto con la primera porque, por ejemplo:

• Para un funcionamiento eficiente de las transacciones, es necesario reservar espacio en disco para objetos temporales,
• para aumentar la velocidad de búsqueda, debe crear índices, cuyo número está determinado por el número de todos posibles combinaciones participando en la búsqueda de campos,
• Para restaurar los datos, se crearán copias de seguridad de la base de datos y se mantendrá un registro de todos los cambios.

Todo esto aumenta el tamaño de la base de datos, por lo que el diseñador busca un equilibrio razonable en el que los problemas se resuelvan de manera óptima colocando los datos de manera inteligente en el espacio de la memoria, pero no a expensas de la seguridad de la base de datos, que incluye tanto la protección contra el acceso no autorizado como la protección. de fracasos.

Para completar la creación del modelo físico se evalúa características de rendimiento(velocidad de búsqueda, eficiencia de ejecución de consultas y consumo de recursos, corrección de las operaciones). A veces, esta etapa, al igual que las etapas de implementación, prueba y optimización de la base de datos, así como el mantenimiento y la operación, se lleva fuera del diseño inmediato de la base de datos.

Si sigue los principios descritos en este artículo, puede crear una base de datos que funcione como se esperaba y pueda adaptarse a nuevos requisitos en el futuro. Examinaremos los principios básicos. diseño de base de datos, así como formas de optimizarlo.

Proceso de diseño de bases de datos

Base de datos correctamente estructurada:

• Te ayuda a ahorrar dinero espacio en disco eliminando datos innecesarios;
• Mantiene la precisión e integridad de los datos;
• Proporciona un cómodo acceso a los datos.

El desarrollo de la base de datos incluye las siguientes etapas:

1. Análisis de requisitos o determinación del propósito de la base de datos;
2. Organizar datos en tablas;
3. Especificar claves primarias y analizar relaciones;
4. Normalización de tablas.

Consideremos cada uno etapa de diseño de base de datos más detalles. Tenga en cuenta que este tutorial cubre el modelo de base de datos relacional de Edgar Codd, escrito en lenguaje SQL (en lugar de modelos jerárquicos, de red o de objetos).

Análisis de requisitos: determinación del propósito de la base de datos

Por ejemplo, si está creando una base de datos para una biblioteca pública, debe considerar cómo deben acceder a la base de datos tanto los lectores como los bibliotecarios.

A continuación se muestran algunas formas de recopilar información antes de crear una base de datos:

• Entrevistar a personas que lo utilizarán;
• Análisis de formularios comerciales como facturas, cronogramas, encuestas;
• consideración de todos sistemas existentes datos ( incluyendo archivos físicos y digitales).

Comience recopilando datos existentes que se incluirán en la base de datos. A continuación, determine los tipos de datos que desea guardar. Así como objetos que describen estos datos. Por ejemplo:

Clientela

• DIRECCIÓN;
• Ciudad, Estado, Código Postal;
• Dirección de correo electrónico.

Bienes

• Nombre;
• Precio;
• Cantidad en stock;
• Cantidad a ordenar.

Órdenes

• Número de orden;
• Representante de ventas;
• Fecha;
• Producto;
• Cantidad;
• Precio;
• Precio.

Al diseñar una base de datos relacional, esta información luego pasará a formar parte del diccionario de datos, que describe las tablas y campos de la base de datos. Divide la información en las partes más pequeñas posibles. Por ejemplo, considere dividir el campo dirección postal y estado para que puedas filtrar a las personas por el estado en el que viven.

Una vez que haya decidido qué datos se incluirán en la base de datos, de dónde provendrán y cómo se utilizarán, puede comenzar a planificar la base de datos real.

Estructura de la base de datos: bloques de construcción

El siguiente paso es representar visualmente la base de datos. Para hacer esto, necesita saber exactamente cómo están estructuradas las bases de datos relacionales. Dentro de una base de datos, los datos relacionados se agrupan en tablas, cada una de las cuales consta de filas y columnas.

Para convertir listas de datos en tablas, comience creando una tabla para cada tipo de objeto, como productos, ventas, clientes y pedidos. He aquí un ejemplo:

Cada fila de una tabla se llama registro. Los registros incluyen información sobre algo o alguien, como un cliente específico. columnas (también llamados campos o atributos) contienen el mismo tipo de información que se muestra para cada registro, por ejemplo, las direcciones de todos los clientes enumerados en la tabla.

Para garantizar la coherencia entre registros al diseñar su modelo de base de datos, asigne el tipo de datos apropiado a cada columna. A tipos comunes los datos incluyen:

• CHAR: longitud de texto específica;
• VARCHAR - texto de varias longitudes;
• TEXTO: gran cantidad de texto;
• INT es un número entero positivo o negativo;
• FLOAT, DOUBLE - números de coma flotante;
• BLOB: datos binarios.

Algunos DBMS también ofrecen un tipo de datos de numeración automática, que genera automáticamente un número único en cada fila.

EN representación visual En la base de datos, cada tabla estará representada por un bloque en el diagrama. El encabezado de cada bloque debe indicar lo que describen los datos de esa tabla y los atributos deben enumerarse a continuación:

En diseñar una base de datos de información debe decidir qué atributos, si los hay, servirán como clave principal para cada tabla. Clave primaria ( PAQUETE.) es un identificador único para de este objeto. Con él, puedes seleccionar los datos de un cliente específico, incluso si solo conoces ese valor.

Los atributos elegidos como claves principales deben ser únicos, inmutables y no pueden establecerse en NULL ( no pueden estar vacíos). Por este motivo, los números de pedido y los nombres de usuario son claves primarias adecuadas, pero los números de teléfono o las direcciones no lo son. También puede utilizar varios campos al mismo tiempo como clave principal ( esto se llama clave compuesta).

Cuando llega el momento de crear la base de datos real, implementa tanto la estructura lógica como la física a través del lenguaje de definición de datos compatible con su DBMS.

También debe evaluar el tamaño de su base de datos para asegurarse de que puede obtener el nivel de rendimiento que necesita y que tiene suficiente espacio para almacenar los datos.

Creando relaciones entre entidades

Ahora que los datos se han convertido en tablas, debemos analizar las relaciones entre ellos. La complejidad de una base de datos está determinada por el número de elementos que interactúan entre dos tablas vinculadas. Determinar la complejidad ayuda a garantizar que divida sus datos en tablas de la manera más eficiente.

Cada objeto se puede interconectar con otro mediante uno de tres tipos de relaciones:

Comunicación uno a uno

Cuando solo hay una instancia del objeto A para cada instancia del objeto B, se dice que tienen una relación uno a uno ( a menudo denotado 1:1). Puedes indicar este tipo de relación en un diagrama ER con una línea con un guión en cada extremo:

Si no tiene ningún motivo para separar estos datos al diseñar y desarrollar bases de datos, una relación 1:1 normalmente indica que es mejor combinar estas tablas en una sola.

Pero en determinadas circunstancias, tiene más sentido crear tablas con relaciones 1:1. Si tiene un campo de datos opcional, como "descripción", que se deja en blanco para muchos registros, puede mover todas las descripciones a una tabla separada, excluyendo campos vacios y mejorar el rendimiento de la base de datos.

Para garantizar que los datos estén correlacionados correctamente, deberá incluir al menos una columna idéntica en cada tabla. Lo más probable es que esta sea la clave principal.

Comunicación uno a muchos

Estas relaciones ocurren cuando un registro en una tabla está relacionado con varios registros en otra. Por ejemplo, un cliente puede realizar muchos pedidos o un lector puede pedir prestados varios libros de la biblioteca. Las relaciones uno a muchos (1:M) se indican mediante la llamada marca de pata de gallo, como en este ejemplo:

Para implementar una relación 1:M, agregue la clave principal de "una" tabla como atributo a la otra tabla. Si la clave principal se especifica de esta manera en otra tabla, se denomina clave externa. La tabla en el lado "1" de la relación es la tabla principal de la tabla secundaria en el otro lado.

Comunicación muchos a muchos

Cuando varios objetos de una tabla pueden estar relacionados con varios objetos de otra. Dicen que tienen una conexión" muchos a muchos» ( MINNESOTA). Por ejemplo, en el caso de estudiantes y cursos, ya que un estudiante puede tomar muchos cursos y a cada curso pueden asistir muchos estudiantes.

En un diagrama ER, estas relaciones se representan mediante las siguientes líneas:

Al diseñar una estructura de base de datos, es imposible implementar este tipo de conexión. En lugar de ello, es necesario dividirlos en dos relaciones de uno a muchos.

Para hacer esto, necesita crear una nueva entidad entre estas dos tablas. Si existe una relación M:N entre ventas y productos, puedes llamar a este nuevo objeto " productos_vendidos", ya que contendrá datos de cada venta. Tanto la tabla de ventas como la tabla de productos tendrán una relación 1:M con productos_vendidos. Este tipo de objeto intermedio en varios modelos denomina tabla de vínculos, objeto de asociación o tabla de vínculos.

Cada entrada en la tabla de relaciones corresponderá a dos entidades de tablas vecinas. Por ejemplo, una tabla de conexiones entre estudiantes y cursos podría verse así:

¿Obligatorio o no?

Otra forma de analizar las conexiones es considerar qué lado de la relación debe existir para que exista el otro. El lado opcional puede estar marcado con un círculo en la línea. Por ejemplo, un país debe existir para tener un representante en las Naciones Unidas, y no al revés:

Dos objetos pueden ser interdependientes ( uno no puede existir sin el otro).

Conexiones recursivas

A veces, al diseñar una base de datos, una tabla apunta a sí misma. Por ejemplo, una tabla de empleados podría tener un atributo "gerente" que hace referencia a otra persona en la misma tabla. Esto se llama enlaces recursivos.

Conexiones adicionales

Las conexiones extrañas son aquellas que se expresan más de una vez. Normalmente, puede eliminar una de estas relaciones sin perder información importante. Por ejemplo, si el objeto "estudiantes" tiene una relación directa con otro objeto llamado "profesores", pero también tiene una relación indirecta con los profesores a través de "asignaturas", es necesario eliminar la relación entre "estudiantes" y "profesores". Porque la única forma en que a los estudiantes se les asignan profesores es a través de las materias.

Normalización de bases de datos

Después del diseño preliminar de la base de datos, puede aplicar reglas de normalización para garantizar que las tablas estén estructuradas correctamente.

Al mismo tiempo, no es necesario normalizar todas las bases de datos. En general, bases de datos con procesamiento de transacciones en tiempo real ( OLTP), debe normalizarse.

Bases de datos con interactivo procesamiento analítico (OLAP), que permite un análisis de datos más fácil y rápido, puede ser más eficaz con un cierto grado de desnormalización. El criterio principal aquí es la velocidad de los cálculos. Cada forma o nivel de normalización incluye reglas asociadas con las formas inferiores.

Primera forma de normalización

La primera forma de normalización ( abreviado 1NF) afirma que durante diseño lógico de base de datos Cada celda de una tabla sólo puede tener un valor, no una lista de valores. Por tanto, una tabla como la siguiente no corresponde a 1NF:

Es posible que desees evitar esta limitación dividiendo los datos en columnas adicionales. Pero esto también va en contra de las reglas: una tabla con grupos de atributos duplicados o estrechamente relacionados no cumple con la primera forma de normalización. Por ejemplo, la siguiente tabla no corresponde a 1NF:

En su lugar, durante el diseño físico de la base de datos, divida los datos en varias tablas o registros hasta que cada celda contenga solo un valor y no haya columnas adicionales. Estos datos se consideran desglosados ​​al mínimo tamaño utilizable. En la tabla anterior, puede crear una tabla adicional " Detalles de venta”, que relacionará productos específicos con ventas. "Ventas" tendrá una relación 1:M con " Detalles de venta».

Segunda forma de normalización

La segunda forma de normalización ( 2FN) estipula que cada uno de los atributos debe depender enteramente de la clave primaria. Cada atributo debe depender directamente de toda la clave primaria y no indirectamente a través de otro atributo.

Por ejemplo, el atributo “edad” depende del “cumpleaños”, que a su vez depende del “cédula de estudiante”, tiene una dependencia funcional. Una tabla que contenga estos atributos no se ajustará a la segunda forma de normalización.

Además, una tabla con una clave primaria que consta de varios campos viola la segunda forma de normalización si uno o más campos no dependen de cada parte de la clave.

Por lo tanto, una tabla con estos campos no coincidirá con la segunda forma de normalización, ya que el atributo "nombre del producto" depende del ID del producto, pero no del número de pedido:

• Número de pedido (clave principal);
• ID del producto (clave principal);
• Nombre del producto.

Tercera forma de normalización

La tercera forma de normalización ( 3NF) : Cada columna que no sea clave debe ser independiente de todas las demás columnas. si en diseño de bases de datos relacionales cambiar un valor en una columna que no es clave provoca que otro valor cambie; esta tabla no cumple con la tercera forma de normalización.

Según 3NF, no se pueden almacenar datos derivados en una tabla, como la columna "Impuestos", que en el siguiente ejemplo depende directamente de costo total orden:

Hubo un tiempo en que se propusieron formas adicionales de normalización. Incluyendo la forma de normalización Boyce-Codd, las formas cuatro a seis y la normalización de clave de dominio, pero las tres primeras son las más comunes.

Datos multidimensionales

Es posible que algunos usuarios necesiten acceder a varias vistas del mismo tipo de datos, especialmente en bases de datos OLAP. Por ejemplo, es posible que quieran saber las ventas por cliente, país y mes. En esta situación, es mejor crear una tabla central a la que puedan hacer referencia las tablas de clientes, países y meses. Por ejemplo:

Reglas de integridad de datos

También usando herramientas de diseño de bases de datos es necesario configurar la base de datos teniendo en cuenta la capacidad de verificar que los datos cumplan con ciertas reglas. Muchos DBMS, como Microsoft Access, aplican automáticamente algunas de estas reglas.

La regla de integridad establece que una clave primaria nunca puede ser NULL. Si una clave consta de varias columnas, ninguna de ellas puede ser NULL. De lo contrario, puede identificar ambiguamente la entrada.

La regla de integridad referencial requiere que cada clave externa especificada en una tabla se asigne a una clave primaria en la tabla a la que hace referencia. Si se cambia o elimina una clave principal, esos cambios deben implementarse en todos los objetos a los que hace referencia esa clave en la base de datos.

Las reglas de integridad de la lógica empresarial garantizan que los datos se ajusten a ciertos parámetros lógicos. Por ejemplo, la hora de la reunión debe estar dentro del horario comercial estándar.

Agregar índices y vistas

Un índice es una copia ordenada de una o más columnas con valores en orden ascendente o descendente. Agregar un índice le permite encontrar registros más rápido. En lugar de volver a ordenar cada consulta, el sistema puede acceder a los registros en el orden especificado por el índice.

Aunque los índices aceleran la recuperación de datos, pueden ralentizar la adición, actualización y eliminación de datos porque el índice debe reconstruirse cada vez que cambia un registro.

Una vista es una solicitud de datos guardada. Las vistas pueden incluir datos de varias tablas o mostrar parte de una tabla.

Propiedades avanzadas

Después diseño del modelo de base de datos Puede refinar su base de datos utilizando propiedades avanzadas como texto de ayuda, máscaras de entrada y reglas de formato que se aplican a esquema específico, vista o columna. La ventaja de este método es que, dado que estas reglas se almacenan en la propia base de datos, la presentación de los datos será coherente en varios programas que accedan a los datos.

SQL y UML

Lenguaje de modelado unificado ( UML) es otro método visual expresiones sistemas complejos, creado en un lenguaje orientado a objetos. Algunos de los conceptos mencionados en este tutorial se conocen en UML como diferentes nombres. Por ejemplo, un objeto en UML se conoce como clase.

UML no se utiliza con tanta frecuencia hoy en día. Hoy en día se utiliza académicamente y en la comunicación entre los desarrolladores de software y sus clientes.

Sistemas de gestión de bases de datos.

La estructura de la base de datos diseñada depende del DBMS que esté utilizando. Algunos de los más comunes:

• Base de datos Oracle;
• MySQL;
• Servidor Microsoft SQL;
• PostgreSQL;
• IBMDB2.

Se puede seleccionar un sistema de gestión de bases de datos adecuado según el costo, el sistema operativo instalado y la disponibilidad. varias funciones etc.

Traducción del artículo " Tutorial de estructura y diseño de bases de datos» equipo de proyecto amigable

En el primer artículo de la serie "Datos en WordPress", proporcioné una descripción general del uso de bases de datos relacionales en WordPress: qué tablas se utilizan y qué datos...

Para proteger los datos confidenciales, MySQL 5.7 introdujo la capacidad de cifrar datos utilizando el motor InnoDB. En este artículo, explicaré los principios del cifrado de bases de datos,…

Tareas básicas de diseño de bases de datos

Tareas principales:

• Garantizar que toda la información necesaria se almacene en la base de datos.
• Garantizar la capacidad de obtener datos para todas las solicitudes necesarias.
• Reduzca la redundancia y duplicación de datos.
• Garantizar la integridad de los datos (corrección de su contenido): eliminar contradicciones en el contenido de los datos, eliminar su pérdida, etc.

Etapas básicas del diseño de bases de datos.

Diseño conceptual (infológico)- construcción de un modelo semántico del área temática, es decir, un modelo de información del más alto nivel de abstracción. Dicho modelo se crea sin centrarse en ningún DBMS ni modelo de datos específicos. Los términos “modelo semántico”, “modelo conceptual” y “modelo infológico” son sinónimos. Además, en este contexto, las palabras "modelo de base de datos" y "modelo de dominio" se pueden utilizar por igual (por ejemplo, "modelo de base de datos conceptual" y "modelo de dominio conceptual"), ya que dicho modelo es a la vez una imagen de la realidad y una base de datos de diseño de imágenes para esta realidad.

El tipo específico y el contenido del modelo de base de datos conceptual están determinados por el aparato formal elegido para este propósito. Comúnmente se utilizan notaciones gráficas similares a los diagramas ER.

Muy a menudo, el modelo de base de datos conceptual incluye:

• descripción objetos de información, o conceptos del área temática y conexiones entre ellos.
• descripción de las restricciones de integridad, es decir requisitos para valores de datos aceptables y relaciones entre ellos.

Diseño lógico (datalógico)- crear un esquema de base de datos basado en un modelo de datos específico, por ejemplo, un modelo de datos relacional. Para modelo relacional modelo de datos de datos: un conjunto de diagramas de relaciones, que generalmente indican claves primarias, así como "vínculos" entre relaciones, que son claves externas.

La transformación de un modelo conceptual en un modelo lógico suele realizarse según reglas formales. Esta etapa puede automatizarse en gran medida.

En la etapa de diseño lógico, se tienen en cuenta los detalles. modelo específico datos, pero es posible que no se tengan en cuenta las características específicas de un DBMS en particular.

Diseño físico

Diseño físico - crear un esquema de base de datos para un DBMS específico. Los detalles de un DBMS en particular pueden incluir restricciones en la denominación de los objetos de la base de datos, restricciones en los tipos de datos admitidos, etc. Además, las características específicas de un DBMS en particular durante el diseño físico incluyen la elección de soluciones relacionadas con el entorno físico de almacenamiento de datos (elección de métodos de gestión memoria de disco, dividir la base de datos en archivos y dispositivos, métodos de acceso a los datos), crear índices, etc.

Normalización

Al diseñar bases de datos relacionales, generalmente se realiza algo llamado normalización.

Modelos entidad-relación

Modelo entidad-relación “Modelo Entidad-Relación” ), o el modelo ER propuesto por P. Chen en 1976, es el más conocido representante clase de modelos semánticos (conceptuales, infológicos) del área temática. El modelo ER generalmente se representa en forma gráfica, utilizando la notación original de P. Chen, llamada diagrama ER, o usando otras notaciones gráficas ( pata de gallo, Ingeniería de la información etc.).

Las principales ventajas de los modelos ER:

• visibilidad;
• Los modelos le permiten diseñar bases de datos con un gran número objetos y atributos;
• Los modelos ER se implementan en muchos sistemas de diseño de bases de datos asistidos por computadora (por ejemplo, ERWin).

Elementos básicos de los modelos ER:

• objetos (entidades);
• atributos del objeto;
• conexiones entre objetos.

Una entidad es un objeto de dominio que tiene atributos.

La relación entre entidades se caracteriza por:

• tipo de conexión (1:1, 1:N, N:M);
• clase de membresía. Una clase puede ser obligatoria u opcional. Si cada instancia de entidad está involucrada en una relación, entonces la clase de membresía es obligatoria; de lo contrario, es opcional.

Modelos semánticos

El modelo semántico (modelo conceptual, modelo infológico) es un modelo de un área temática diseñado para representar la semántica de un área temática en el más alto nivel de abstracción. Esto significa que se elimina o minimiza la necesidad de utilizar conceptos de "bajo nivel" asociados con aspectos específicos. representación física y almacenamiento de datos.

Fecha K. J. Introducción a los sistemas de bases de datos. - 8ª ed. - M.: “Williams”, 2006:

El modelado semántico ha sido objeto de intensas investigaciones desde finales de los años 1970. La principal motivación para dicha investigación (es decir, el problema que los investigadores intentaban resolver) fue siguiente hecho. El hecho es que los sistemas de bases de datos suelen tener un conocimiento muy limitado sobre el significado de los datos almacenados en ellos. En la mayoría de los casos, sólo permiten la manipulación de datos de ciertos tipos simples y definen algunas restricciones de integridad simples impuestas a estos datos. Cualquier interpretación más compleja es responsabilidad del usuario. Sin embargo, sería fantástico si los sistemas pudieran tener un poco más de conocimientos y ser un poco más inteligentes a la hora de responder a las consultas de los usuarios, además de admitir interfaces de usuario más complejas (es decir, de mayor nivel).
[…]
Las ideas de modelado semántico pueden resultar útiles como herramienta de diseño de bases de datos incluso si no están respaldadas directamente por el DBMS.

El representante más famoso de la clase. modelos semánticos es el modelo entidad-relación (modelo ER).

Literatura

• Fecha K.J. Introducción a los Sistemas de Bases de Datos. - 8ª ed. - M.: “Williams”, 2006. - 1328 p. -ISBN 0-321-19784-4
• Kogalovsky M.R. Tecnologías avanzadas de sistemas de información. - M.: Prensa DMK; Empresa de TI, 2003. - 288 p. -ISBN 5-279-02276-4
• Kogalovsky M.R. Enciclopedia de tecnologías de bases de datos. - M.: Finanzas y Estadísticas, 2002. - 800 p. -ISBN 5-279-02276-4
• Kuznetsov S.D. Conceptos básicos de bases de datos. - 2ª ed. - M.: Universidad de Internet Tecnologías de la información; BINOMIO. Laboratorio de Conocimiento, 2007. - 484 p. -ISBN 978-5-94774-736-2
• Connolly T., Begg K. Bases de datos. Diseño, implementación y soporte. Teoría y práctica = Sistemas de bases de datos: un enfoque práctico para el diseño, implementación y gestión. - 3ª edición. - M.: “Williams”, 2003. - 1436 p. -ISBN 0-201-70857-4
• García-Molina G., Ullman J., Widom J. Sistemas de bases de datos. Curso completo. - M.: “Williams”, 2003. - 1088 p. -ISBN 5-8459-0384-X

Ver también

• Métodos de diseño

Campo de golf

• El modelo entidad-relación es un paso hacia una visión unificada de los datos - Citforum
• Ampliando el modelo relacional para reflejar mejor la semántica - Citforum
• Una guía para diseñar bases de datos de sitios web "para principiantes"
• Un método para diseñar la estructura lógica de una base de datos relacional sin normalización de tablas.

Notas

Fundación Wikimedia.

2010.

Vea qué es "Diseño de base de datos" en otros diccionarios: El administrador de base de datos es una persona responsable de desarrollar los requisitos de una base de datos, su diseño, implementación, uso eficiente y apoyo, incluida la gestión cuentas

usuarios de bases de datos y protección contra personas no autorizadas... ... Wikipedia

- (Refactorización de bases de datos en inglés) es un simple cambio en el esquema de la base de datos que ayuda a mejorar su diseño manteniendo la semántica funcional e informativa. En otras palabras, la consecuencia de la refactorización de la base de datos no puede ser... ... Wikipedia DISEÑO - una de las formas de reflexión avanzada de la realidad, el proceso de creación de un prototipo (prototipo) de un objeto, fenómeno o proceso propuesto a través de un específico. métodos. P. es forma específica manifestaciones de pronóstico funciones de control,... ...

Enciclopedia sociológica rusa

La solicitud "DB" se redirige aquí; ver también otros significados. Una base de datos presentada de forma objetiva es una colección de materiales independientes (artículos, cálculos, reglamentos, decisiones judiciales y otros materiales similares), ... ... Wikipedia

Pasos de diseño de base de datos.

• El proceso de diseño incluye las siguientes etapas:
• 1. Diseño infológico.
• 2. Determinar los requisitos para el entorno operativo en el que operará el sistema de información.
• 3. Selección de un sistema de gestión de bases de datos (DBMS) y otras herramientas de software.
• 4. Diseño de bases de datos datalógicas (lógicas).

5. Diseño físico de la base de datos. En la primera etapa, el desarrollador (administrador de la base de datos) combina vistas privadas del contenido de la base de datos obtenidas de entrevistas con los usuarios con sus propias vistas de los datos que pueden ser necesarios en aplicaciones futuras, creando descripción informal generalizada de una base de datos . Esta descripción se realiza utilizando lenguaje natural, fórmulas matemáticas , tablas, gráficos y otras herramientas que sean comprensibles para todas las personas que trabajan en el diseño de bases de datos. Esta descripción del área temática se llama

El modelo de datos infológicos es un modelo orientado a humanos y es completamente independiente de los parámetros físicos del entorno de almacenamiento de datos. Un medio de almacenamiento de datos de este tipo puede ser la memoria humana en lugar de una computadora. Por lo tanto, el modelo de información no cambia hasta que algunos cambios en el mundo real requieran que se le realicen cambios apropiados para que este modelo continúe reflejando el área temática.

El resto de modelos, datalógicos y físicos, están orientados a ordenador. Con su ayuda, el DBMS permite a los programas y usuarios acceder a los datos almacenados sólo por sus nombres, sin preocuparse por la ubicación física de estos datos. El DBMS encuentra los datos necesarios en dispositivos de almacenamiento externos utilizando modelo de datos físicos.

Dado que el acceso especificado se realiza mediante un DBMS específico, los modelos deben describirse en el lenguaje de descripción de datos de este DBMS. Esta descripción se llama modelo de datos datalógicos.

Arquitectura de tres niveles (infológico, datalógico y capas fisicas) le permite garantizar la independencia de los datos almacenados de los programas que los utilizan. El desarrollador puede, si es necesario, reescribir los datos almacenados en otros medios de almacenamiento o reorganizar su estructura física cambiando solo el modelo de datos físicos. El DBA puede conectar cualquier número de nuevos usuarios (nuevas aplicaciones) al sistema, agregándolos, si es necesario, al modelo datalógico. Estos cambios en los modelos físico y datalógico no serán notados por los usuarios existentes del sistema (serán “transparentes” para ellos), al igual que los nuevos usuarios no serán notados. Por lo tanto, la independencia de los datos permite el desarrollo de un sistema de base de datos sin interrumpir las aplicaciones existentes.

Modelo infológico (lógico-informativo). El objetivo de la etapa de diseño infológico es obtener modelos semánticos (conceptuales) que reflejen el área temática y las necesidades de información de los usuarios. Por lo tanto, esta etapa también se denomina modelado semántico. El modelado semántico es el modelado de la estructura de datos basado en el significado de esos datos.

Concepto “Área temática”- básico en teoría de bases de datos y no tiene una definición estricta. Se desprende de los conceptos de "objeto" y "sujeto". Área temática(POR)- Parte mundo real, a estudiar con el objetivo de organizar la gestión y, en definitiva, la automatización. El software parece ser mucho fragmentos, que se caracterizan por muchos objetos, muchos procesos que utilizan objetos, así como muchos usuarios, se caracterizan por una vista única del área temática.

Objeto llamado fenómeno del mundo exterior. Esto es algo que realmente existe: una persona, un producto, un producto o un proceso: registro de nacimiento, recepción de bienes, producción de productos. Cada objeto tiene una gran cantidad de propiedades.

Ejemplos.

Objeto " Humano"tiene las propiedades: altura, nombre, fecha de nacimiento...,

objeto - " Producto"tiene propiedades: calidad, fecha de fabricación, apariencia….

Existen numerosas conexiones entre objetos. Por ejemplo:

• · Humano compra, vende, produce Producto
• · Producto creado, comprado, vendido Humano.

Artículo - un modelo de un objeto real, en el que sólo se registran las propiedades y conexiones asignadas al SI. La totalidad de los elementos seleccionados forman núcleo de objeto área temática y la totalidad de sus relaciones - estructura de un fragmento de la realidad . Eso. El concepto de "Dominio Sujeto" corresponde al punto de vista del consumidor sobre el núcleo del objeto: identifica sólo aquellos objetos, propiedades de objetos y conexiones entre objetos que son valiosos para el SI y deben almacenarse en la base de datos.

Todas las acciones para identificar el núcleo del área temática se llevan a cabo en la etapa de análisis de SI.

El núcleo de objetos del sistema no permanece constante durante el ciclo de vida de un SI: los objetos desaparecen y aparecen, sus propiedades y relaciones cambian. Las cadenas de estos cambios registrados a lo largo del tiempo se denominan trayectorias del área temática, y la totalidad propiedades generales trayectoria - semántica de dominio

Hay varias técnicas de modelado de dominios disponibles. Una de las técnicas más populares actualmente se basa en el uso de diagramas gráficos que incluyen un pequeño número de componentes heterogéneos ERD (Entity-Relationship Diagrams). En la literatura rusa, estos diagramas se denominan “objeto-relación” o “entidad-conexión”.

El modelo ERD fue propuesto en 1976. Peter Ping-Sheng Chen. Posteriormente, muchos autores desarrollaron sus propias versiones de dichos modelos (notación Martin, notación IDEF1X, notación Barker), pero todas ellas se basan en diagramas gráficos propuestos por Chen.

La mayoría de los enfoques modernos para el diseño de bases de datos relacionales se basan en el uso de variaciones del modelo ER.

De hecho, todas las versiones de diagramas entidad-relación parten de la misma idea: un dibujo siempre es más claro. descripción del texto. Todos estos diagramas utilizan una representación gráfica de entidades de dominio, sus propiedades (atributos) y relaciones entre entidades.

Nos familiarizaremos con los diagramas ER en notación de Barker, cuyas ideas principales son bastante fáciles de entender.

Conceptos básicos de los diagramas ER. Los conceptos principales del modelo ER son entidad, relación y atributo.

Para mayor expresividad y mejor comprensión, el nombre de la entidad puede ir acompañado de ejemplos de objetos específicos de este tipo.

Definición 1. Esencia es un objeto real o imaginable, cuya información debe ser almacenada y accesible. Las entidades pueden ser personas, lugares, aviones, vuelos, gustos, colores, etc.

Cada entidad debe tener un nombre expresado por un sustantivo singular. En este caso, el nombre de la entidad es el nombre del tipo, no algún instancia específica este tipo. El concepto de tipo de entidad se refiere a un conjunto de individuos, objetos, eventos o ideas homogéneos que actúan como un todo.

Ejemplos de entidades pueden ser clases de objetos como "Proveedor", "Empleado", "Factura".

Cada entidad en el modelo se representa como un rectángulo que contiene el nombre de la entidad:

Definición 2. Instancia de entidad es un representante específico de una entidad determinada.

Por ejemplo, un representante de la entidad "Empleado" puede ser el "Empleado Ivanov".

Las instancias de entidad deben ser distinguible, es decir. Las entidades deben tener algunas propiedades que sean únicas para cada instancia de esa entidad.

Definición 3. atributo de entidad es una característica nombrada de una entidad. Su nombre debe ser único para un tipo de entidad en particular, pero puede ser el mismo para diferentes tipos de entidad (por ejemplo, se puede definir COLOR para muchas entidades: PERRO, COCHE, PINTURA, etc.). Los atributos se utilizan para definir qué información se debe recopilar sobre una entidad. Ejemplos de atributos para la entidad COCHE son TIPO, MARCA, MATRÍCULA, COLOR, etc.

También aquí hay una distinción entre tipo de atributo e instancia. El tipo de atributo COLOR tiene muchas instancias o valores: Rojo, Azul, Plátano, Noche Blanca, etc., pero a cada instancia de entidad se le asigna solo un valor de atributo.

No existe una diferencia absoluta entre tipos de entidades y atributos. Un atributo es tal sólo en relación con el tipo de entidad. En otro contexto, un atributo puede actuar como una entidad independiente. Por ejemplo, para una planta de automóviles, el color es sólo un atributo del producto de producción, pero para una fábrica de pinturas y barnices, el color es un tipo de entidad.

Cada atributo recibe un nombre que es único dentro de la entidad. El nombre del atributo debe expresarse como un sustantivo singular (posiblemente con adjetivos característicos).

Ejemplos de atributos de la entidad "Empleado" pueden ser atributos tales como "Número de personal", "Apellido", "Nombre", "Patronímico", "Posición", "Salario", etc.

Los atributos se representan dentro de un rectángulo que define la entidad:

Los atributos se pueden clasificar en uno de tres tipos diferentes: descriptivos, indicativos o auxiliares.

Descriptivo Los atributos representan hechos intrínsecos a cada instancia de una entidad.

Señalando Los atributos se utilizan para dar un nombre o designación a instancias de una entidad.

Auxiliar Los atributos se utilizan para asociar una instancia de una entidad con una instancia de otra. Los atributos están sujetos a reglas estrictamente definidas.

Definición 4. Clave de entidad - un conjunto mínimo de atributos cuyos valores se pueden utilizar para encontrar de forma única la instancia requerida de una entidad. Minimidad significa que excluir cualquier atributo del conjunto no permite identificar la entidad por los restantes.

Por ejemplo, para una entidad Cronograma la clave es el atributo Número_de_vuelo o establecer: punto_origen, Hora de salida Y Destino(siempre que un avión vuele de un punto a otro en un momento dado).

Una entidad puede tener varias claves diferentes.

Los atributos clave se muestran subrayados en el diagrama:

Definición 5. Conexión - esto es algún tipo de asociación entre dos entidades. Una entidad puede estar conectada a otra entidad o consigo misma. Las relaciones permiten que una entidad encuentre otras entidades relacionadas con ella.

Si el propósito de la base de datos fuera sólo almacenar datos individuales y no relacionados, entonces su estructura podría ser muy simple. Sin embargo, uno de los principales requisitos para organizar una base de datos es asegurar la capacidad de encontrar unas entidades por los valores de otras, para lo cual es necesario establecer ciertas conexiones entre ellas. Y dado que las bases de datos reales suelen contener cientos o incluso miles de entidades, en teoría se pueden establecer más de un millón de conexiones entre ellas. La presencia de tal multitud de conexiones determina la complejidad de los modelos de información.

Por ejemplo, las conexiones entre entidades se pueden expresar mediante las siguientes frases: "Un EMPLEADO puede tener varios HIJOS", "Cada EMPLEADO debe estar inscrito exactamente en un DEPARTAMENTO".

Gráficamente, la relación se representa mediante una línea que conecta dos entidades:

Cada enlace tiene dos extremos y uno o dos nombres. El nombre suele expresarse en forma verbal indefinida: “tener”, “pertenecer”, etc. Cada nombre se refiere a su propio extremo de la conexión. A veces los nombres no se escriben porque son obvios.

Cada enlace puede tener uno de los siguientes tipos de comunicacion :

Tipo de comunicación cara a cara significa que una instancia de la primera entidad (izquierda) está asociada con una instancia de la segunda entidad (derecha). Una relación uno a uno indica con mayor frecuencia que en realidad tenemos una sola entidad, dividida incorrectamente en dos.

Tipo de comunicación uno a muchos significa que una instancia de la primera entidad (izquierda) está asociada con varias instancias de la segunda entidad (derecha). Este es el tipo de comunicación más utilizado. La entidad izquierda (en el lado "uno") se llama de los padres , derecha (desde el lado "muchos") - filial . (ver foto para una representación gráfica de la conexión)

Tipo de comunicación muchos a muchos significa que cada instancia de la primera entidad puede asociarse con múltiples instancias de la segunda entidad, y cada instancia de la segunda entidad puede asociarse con múltiples instancias de la primera entidad. El tipo de relación de muchos a muchos es temporario tipo de comunicación aceptable en las primeras etapas del desarrollo del modelo. En el futuro, este tipo de relación deberá ser reemplazada por dos relaciones de uno a muchos mediante la creación de una entidad intermedia.

Cada conexión puede tener una de dos modalidades de comunicación :

Modalidad" Tal vez puede estar relacionado con una o más instancias de otra entidad, o tal vez no relacionado ni un solo ejemplar.

Modalidad" debe " significa que una instancia de una entidad debe estar asociado con al menos un una instancia de otra entidad.

La comunicación puede tener modalidad diferente desde diferentes extremos.

La sintaxis gráfica descrita permite definitivamente Lea los diagramas usando la siguiente estructura de frases:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Cada enlace se puede leer de izquierda a derecha o de derecha a izquierda. Por ejemplo, la relación presentada en la Figura 4 anterior dice así:

De izquierda a derecha: "cada empleado puede tener varios hijos".

De derecha a izquierda: “Cada hijo debe pertenecer exactamente a un empleado”.

Formas normales de circuitos ER. Al igual que en los diagramas de bases de datos relacionales, los diagramas ER introducen el concepto de formas normales y su significado coincide estrechamente con el significado de las formas normales relacionales. Sólo daremos definiciones muy breves e informales de las tres primeras formas normales.

EN primera normalidad En la forma del diagrama ER, se eliminan los atributos duplicados o grupos de atributos, es decir, Se identifican entidades implícitas “disfrazadas” de atributos.

En segunda normalidad forma, se eliminan los atributos que dependen sólo de la pieza. identificador único(clave de entidad). Esta parte del identificador único identifica una entidad individual.

EN tercera normalidad El formulario elimina atributos que dependen de atributos que no están incluidos en el identificador único (clave de entidad). Estos atributos son la base de una sola entidad.

Si las entidades están definidas correctamente, las tablas resultantes estarán inmediatamente en 3NF. La principal ventaja del método es que el modelo se construye mediante sucesivos refinamientos de los diagramas iniciales.

Obteniendo el esquema relacional del esquema ER:

Paso 1. Cada entidad simple se convierte en una mesa. Una entidad simple es una entidad que no es un subtipo y no tiene subtipos. El nombre de la entidad se convierte en el nombre de la tabla.

Paso 2. Cada atributo se convierte en una posible columna con el mismo nombre; Se puede seleccionar un formato más preciso. Las columnas correspondientes a atributos opcionales pueden contener valores nulos; las columnas correspondientes a los atributos requeridos no pueden hacerlo.

Paso 3. Los componentes del identificador único de la entidad se convierten en la clave principal de la tabla. Si hay varios identificadores únicos posibles, se elige el más utilizado. Si el identificador único incluye relaciones, se agrega una copia del identificador único de la entidad en el otro extremo de la relación al número de columnas de clave principal (este proceso puede continuar de forma recursiva). Estas columnas se nombran utilizando nombres finales de relaciones y/o nombres de entidades.

Paso 4. Las relaciones de muchos a uno (y de uno a uno) se convierten en claves externas. Aquellos. Se realiza una copia del identificador único del extremo "único" de la relación y las columnas correspondientes constituyen la clave externa. Conexiones opcionales hacer coincidir columnas que permiten valores nulos; Relaciones obligatorias: para columnas que no permiten valores nulos.

Paso 5. Los índices se crean a partir de la clave principal (un índice único), las claves externas y aquellos atributos en los que se pretende basar principalmente las consultas.

Paso 6. Si hubiera subtipos en el esquema conceptual, entonces son posibles dos formas:

• · todos los subtipos en una(s) tabla(s)
• · para cada subtipo - mesa separada(b)

El método (a) crea una tabla para el supertipo más externo y se pueden crear vistas para los subtipos. Se agrega a la tabla al menos una columna que contiene el código TIPO; se convierte en parte de la clave principal.

Cuando se utiliza el método (b), para cada subtipo de primer nivel (para los inferiores, vistas), el supertipo se recrea utilizando la vista UNION (las columnas comunes, columnas de supertipo, se seleccionan de todas las tablas de subtipos).

Todo en una mesa	Tabla - por subtipo
Ventajas
Todo se mantiene junto Fácil acceso a supertipos y subtipos. Se requieren menos mesas	Las reglas de subtipificación son más claras Los programas funcionan solo con las tablas necesarias.
Defectos
Una solución demasiado general Requiere lógica adicional para manejar diferentes conjuntos de columnas y diferentes restricciones Posible cuello de botella (debido al bloqueo) Las columnas de subtipo deben ser opcionales Algunos DBMS requieren memoria adicional para almacenar valores nulos	demasiadas mesas Columnas confusas en la vista UNION Posible pérdida de rendimiento al trabajar a través de UNION No es posible realizar modificaciones en un supertipo.

Paso 7 Hay dos formas de trabajar con relaciones exclusivas:

• · dominio(s) general(es)
• · claves foráneas explícitas (b)

Si las claves externas restantes están todas en el mismo dominio, es decir tienen un formato común (método (a)), luego se crean dos columnas: el identificador de relación y el identificador de entidad. La columna ID del enlace se utiliza para distinguir los enlaces cubiertos por el arco de exclusión. La columna de identificador de entidad se utiliza para almacenar los valores de identificador único de la entidad en el otro extremo de la relación correspondiente.

Si las claves externas resultantes no pertenecen al mismo dominio, entonces se crean columnas de clave externa explícitas para cada relación cubierta por el arco de exclusión; todas estas columnas pueden contener valores nulos.

Un ejemplo de desarrollo de un modelo ER simple. Al desarrollar modelos ER, debemos obtener la siguiente información sobre el área temática:

• 1. Lista de entidades de dominio.
• 2. Lista de atributos de entidad.
• 3. Descripción de las relaciones entre entidades.

Los diagramas ER son convenientes porque el proceso de identificación de entidades, atributos y relaciones es iterativo. Habiendo desarrollado la primera versión aproximada de los diagramas, los perfeccionamos entrevistando a expertos en la materia. En este caso, la documentación en la que se registran los resultados de las conversaciones son los propios diagramas ER.

Supongamos que nos enfrentamos a la tarea de desarrollar un sistema de información para una determinada empresa comercial mayorista. En primer lugar, debemos estudiar el área temática y los procesos que en ella ocurren. Para ello entrevistamos a empleados de la empresa, leemos documentación, estudiamos formularios de pedido, facturas, etc.

Por ejemplo, durante una conversación con un gerente de ventas, resultó que él (el gerente) cree que el sistema diseñado debería realizar las siguientes acciones:

• · Almacenar información del cliente.
• · Imprimir facturas de mercancías liberadas.
• · Monitorear la disponibilidad de mercancías en el almacén.

Seleccionemos todos los sustantivos en estas oraciones; estos serán candidatos potenciales para entidades y atributos, y analicémoslos (resaltaremos los términos poco claros con un signo de interrogación):

• · Comprador
• · Factura es un claro candidato a la entidad.
• · Producto- un candidato claro para la entidad
• · (?)Depósito- En general, ¿cuántos almacenes tiene la empresa? Si son varios, entonces será candidato a una nueva entidad.
• · (?) Disponibilidad del producto- Lo más probable es que sea un atributo, pero ¿un atributo de qué entidad?

Inmediatamente surge una conexión obvia entre las entidades: "los compradores pueden comprar muchos bienes" y "los bienes pueden venderse a muchos compradores". La primera versión del diagrama se ve así:

Después de hacerle preguntas adicionales al gerente, descubrimos que la empresa tiene varios almacenes. Además, cada producto puede almacenarse en varios almacenes y venderse desde cualquier almacén.

¿Dónde debo colocar las entidades “Factura” y “Almacén” y a qué debo vincularlas? Preguntémonos, ¿cómo se relacionan estas entidades entre sí y con las entidades “Comprador” y “Producto”?

• · Los compradores compran bienes y reciben facturas que contienen datos sobre la cantidad y el precio de los bienes adquiridos.
• · Cada comprador puede recibir varias facturas.
• · Cada factura debe emitirse a un solo comprador.
• · Cada factura debe contener varios bienes (no hay facturas vacías). Cada producto, a su vez, puede venderse a varios compradores mediante varias facturas.
• · Además, cada factura debe emitirse desde un almacén específico y muchas facturas se pueden emitir desde cualquier almacén.

Así, tras la aclaración, el diagrama quedará así:

visualización de información de atributos infológicos

Es hora de pensar en los atributos de las entidades. Hablando con los empleados de la empresa, descubrimos lo siguiente:

• · Cada comprador es una persona jurídica y tiene un nombre, dirección y datos bancarios.
• · Cada producto tiene un nombre, precio, y además se caracteriza por unidades de medida.
• · Cada factura tiene un número único, fecha de emisión, una lista de bienes con cantidades y precios, así como el monto total de la factura. La factura se emite desde un almacén específico y a un comprador específico.
• · Cada almacén tiene su propio nombre.

Anotemos nuevamente todos los sustantivos que serán atributos potenciales y analicémoslos:

• · entidad legal - El término es retórico, no trabajamos con particulares. No prestamos atención.
• · nombre del comprador
• · DIRECCIÓN- una característica clara del comprador.
• · Datos bancarios- una característica clara del comprador.
• · Nombre del producto
• · (?) Precio del producto- Parece que es una característica del producto. ¿Esta característica difiere del precio de la factura?
• · Unidad de medida- una característica clara del producto.
• · Número de factura- una característica clara y única de la factura.
• · fecha de factura- una característica clara de la factura.
• · (?)Lista de mercancías en la factura.- una lista no puede ser un atributo. Probablemente necesites separar esta lista en una entidad separada.
• · (?)Cantidad de mercancías en la factura- Esta es una característica obvia, pero ¿una característica de qué? Esta es una característica no sólo de un “producto”, sino de un “producto en la factura”.
• · (?)El precio de la mercancía en la factura.- Nuevamente, esto no debería ser solo una descripción del producto, sino una descripción del producto en la factura. Pero el precio del producto ya lo hemos visto arriba, ¿es lo mismo?
• · Monto de la factura- una característica clara de la factura. Esta característica no es independiente. El importe de la factura es igual a la suma de los costes de todos los bienes incluidos en la factura.
• · Nombre del almacén- una característica clara del almacén.

Durante una conversación adicional con el gerente, fue posible aclarar varios conceptos de precios. Resultó que cada producto tiene un precio actual determinado. Este es el precio al que se vende actualmente el producto. Naturalmente, este precio puede cambiar con el tiempo. El precio de un mismo producto en diferentes facturas emitidas en diferentes tiempos, puede ser diferente. Así hay dos precios- el precio de la mercancía en la factura y el precio actual de la mercancía.

Con el concepto emergente de "Lista de bienes en la factura", todo está bastante claro.

Las entidades "Factura" y "Producto" están relacionadas entre sí por una relación de tipo muchos a muchos. Tal conexión, como señalamos anteriormente, debería ser dividir en dos relaciones de uno a muchos. Esto requiere adicional esencia.

Esta entidad será la entidad “Lista de bienes en la factura”. Su conexión con las entidades “Factura” y “Producto” se caracteriza por las siguientes frases

- "cada factura debe tener varias entradas de la lista de mercancías en la factura",

• - "cada entrada de la lista de mercancías en la factura debe incluirse exactamente en una factura",
• - "cada producto puede incluirse en varios registros de la lista de mercancías de la factura",
• - “cada entrada de la lista de mercancías de la factura debe estar asociada exactamente a un producto”.

Los atributos "Cantidad de bienes en factura" y "Precio de bienes en factura" son atributos de la entidad "Lista de bienes en factura".

Haremos lo mismo con la conexión que conecta las entidades “Almacén” y “Producto”. vamos a presentar adicional entidad "Artículo en almacén". El atributo de esta entidad será “Cantidad de bienes en stock”. Así, el producto estará listado en cualquier almacén y su cantidad en cada almacén será diferente.

Ahora puedes poner todo esto en un diagrama:

Modelos ER conceptuales y físicos. El diagrama ER de ejemplo desarrollado anteriormente es un ejemplo diagrama conceptual. Esto significa que el diagrama no tiene en cuenta características de un DBMS específico. A partir de este diagrama conceptual se puede construir diagrama fisico, que ya tendrá en cuenta características del DBMS como tipos y nombres permitidos de campos y tablas, restricciones de integridad, etc. Una versión física del diagrama anterior podría verse, por ejemplo, así:

En este diagrama, cada entidad representa una tabla de base de datos, cada atributo se convierte en una columna de la tabla correspondiente. Tenga en cuenta que en muchas tablas, por ejemplo, "CUST_DETAIL" y "PROD_IN_SKLAD", correspondientes a las entidades "Registro de lista de facturas" y "Artículo en almacén", han aparecido nuevos atributos que no estaban en el modelo conceptual: esta es la clave. atributos de las tablas principales, migrado en tablas secundarias para proporcionar relaciones entre tablas utilizando claves externas.

Las tablas resultantes están en 3NF.

Los diagramas entidad-relación le permiten utilizar notaciones gráficas visuales para modelar entidades y sus relaciones.

Distinguir conceptual Y físico Diagramas ER. Los diagramas conceptuales no tienen en cuenta las características específicas de DBMS específicos. Los diagramas físicos se basan en los conceptuales y representan un prototipo de una base de datos específica. Las entidades definidas en el diagrama conceptual se convierten en tablas, los atributos se convierten en columnas de la tabla (teniendo en cuenta los tipos de datos y nombres de columnas permitidos para un DBMS determinado), las conexiones se implementan mediante migración atributos clave entidades matrices y creación de claves foráneas.

Elementos más complejos del modelo ER. Nos centramos únicamente en los conceptos más básicos y obvios del modelo de datos ER. Los elementos más complejos del modelo incluyen los siguientes:

· Subtipos y supertipos de entidades. Como en los lenguajes de programación con avanzado. sistemas estándar(por ejemplo, en lenguajes de programación orientados a objetos), se introduce la posibilidad de heredar un tipo de entidad basándose en uno o más supertipos.

Una entidad se puede dividir en dos o más subtipos mutuamente excluyentes, cada uno de los cuales incluye atributos generales y/o comunicaciones. Estos atributos y/o relaciones comunes se definen explícitamente una vez en un nivel superior. Los subtipos pueden definir sus propios atributos y/o relaciones. En principio, la subtipificación puede continuar durante más niveles bajos, pero la experiencia demuestra que en la mayoría de los casos dos o tres niveles son suficientes.

La entidad a partir de la cual se definen los subtipos se denomina supertipo. Los subtipos deben formarse. conjunto completo, es decir. cualquier instancia de un supertipo debe pertenecer a algún subtipo. A veces, para completar, es necesario definir un subtipo adicional OTROS.

Ejemplo: Supertipo AERONAVE

¿Cómo se supone que debes leer esto? Del supertipo: AERONAVE, que debe ser AVIÓN, HELICÓPTERO, CLICKER DE PÁJAROS u OTRA AERONAVE. Del subtipo: HELICÓPTERO, que pertenece al tipo de AERONAVE. De un subtipo, que también es supertipo: AVIÓN, que pertenece al tipo de AERONAVE y debe ser PLANEADOR o AVIÓN A MOTOR.

En ocasiones es conveniente tener dos o más subtipos diferentes de una entidad. Por ejemplo, la esencia de PERSONA se puede dividir en subtipos según características profesionales (PROGRAMADOR, LECHE, etc.), o quizás según género (HOMBRE, MUJER).

• · Conexiones de muchos a muchos. A veces es necesario vincular entidades de tal manera que pueda haber múltiples instancias de la entidad en ambos extremos del vínculo (por ejemplo, todos los miembros de una cooperativa poseen conjuntamente la propiedad de la cooperativa). Para ello se introduce un tipo de relación “muchos a muchos”.
• · Grados de conexión especificados. A veces es útil determinar cantidad posible instancias de entidad que participan en una relación determinada (por ejemplo, a un empleado se le permite participar en no más de tres proyectos a la vez). Para expresar esta restricción semántica, se permite indicar al final de la conexión su grado máximo u obligatorio.
• · Eliminaciones en cascada de instancias de entidades. Algunas relaciones son tan fuertes (en el caso de una relación de uno a muchos, por supuesto) que cuando elimina la instancia de entidad de referencia (correspondiente a un extremo de la relación), también debe eliminar todas las instancias de entidad correspondientes al muchos terminan la relación. El correspondiente requisito de "eliminación en cascada" se puede formular al definir una entidad.
• · Dominios. Al igual que con el modelo de datos relacionales, es útil poder definir potencialmente conjunto admisible valores de atributos de entidad (dominio).

La interpretación intuitiva más correcta del concepto de dominio es entender el dominio como un conjunto potencial admisible de valores de un tipo determinado. Por ejemplo, el dominio "Nombres" se define en tipo básico cadenas de caracteres, pero sus valores solo pueden incluir aquellas cadenas que pueden representar un nombre (en particular, dichas cadenas no pueden comenzar con un carácter suave).

También cabe señalar la carga semántica del concepto de dominio: los datos se consideran comparables sólo si pertenecen al mismo dominio. En nuestro ejemplo, los valores de dominio "Números de brecha" y "Números de grupo" son de tipo entero, pero no son comparables.

Estos y otros elementos más complejos del modelo de datos Entidad-Relación lo hacen significativamente más poderoso, pero al mismo tiempo lo hacen algo más difícil de usar.