Hogar › Teléfono › Los datos de la base de datos relacional se presentan en el formulario. Análisis de datos limitados. Características, estructura y términos asociados al modelo relacional.

Los datos de la base de datos relacional se presentan en el formulario. Análisis de datos limitados. Características, estructura y términos asociados al modelo relacional.

Traducción

Nota del traductor: aunque el artículo es bastante antiguo (publicado hace 2 años) y tiene un título llamativo, todavía da una buena idea de las diferencias entre las bases de datos relacionales y las bases de datos NoSQL, sus ventajas y desventajas, y también proporciona una breve descripción. de almacenamientos no relacionales.

Recientemente, han aparecido muchas bases de datos no relacionales. Esto sugiere que si necesita una escalabilidad bajo demanda prácticamente ilimitada, necesita una base de datos no relacional.

Si esto es cierto, ¿significa que la poderosa base de datos relacional se ha vuelto vulnerable? ¿Significa esto que los días de las bases de datos relacionales están pasando y pronto desaparecerán por completo? En este artículo, analizaremos el popular movimiento de bases de datos no relacionales en su aplicación a diferentes situaciones y veremos si afectará el futuro de las bases de datos relacionales.

Las bases de datos relacionales existen desde hace unos 30 años. Durante este tiempo estallaron varias revoluciones que acabarían con el almacenamiento relacional. Por supuesto, ninguna de estas revoluciones tuvo lugar, y ninguna de ellas afectó ni un ápice la posición de las bases de datos relacionales.

Empecemos por lo básico.

Una base de datos relacional es un conjunto de tablas (entidades). Las tablas constan de columnas y filas (tuplas). Las restricciones se pueden definir dentro de las tablas y existen relaciones entre tablas. Con SQL, puede ejecutar consultas que devuelven conjuntos de datos de una o más tablas. Dentro de una consulta, los datos se obtienen de varias tablas uniéndolas (JOIN), la mayoría de las veces se utilizan para la conexión las mismas columnas que definen las relaciones entre las tablas. La normalización es el proceso de estructurar un modelo de datos para garantizar la coherencia y la falta de redundancia en los datos.

Se accede a las bases de datos relacionales a través de sistemas de gestión de bases de datos relacionales (RDBMS). Casi todos los sistemas de bases de datos que utilizamos son relacionales, como Oracle, SQL Server, MySQL, Sybase, DB2, TeraData, etc.

Las razones de este predominio no son obvias. A lo largo de la historia de las bases de datos relacionales, han ofrecido consistentemente la mejor combinación de simplicidad, robustez, flexibilidad, rendimiento, escalabilidad y compatibilidad en la gestión de datos.

Sin embargo, para ofrecer todas estas características, las tiendas relacionales son increíblemente complejas en su interior. Por ejemplo, una consulta SELECT simple puede tener cientos de rutas de ejecución potenciales que el optimizador evaluará directamente durante la ejecución de la consulta. Todo esto está oculto para los usuarios, pero internamente el RDBMS crea un plan de ejecución basado en cosas como algoritmos de estimación de costos para satisfacer mejor la consulta.

Problemas de bases de datos relacionales

Si bien las tiendas relacionales ofrecen la mejor combinación de simplicidad, solidez, flexibilidad, rendimiento, escalabilidad y compatibilidad, no necesariamente funcionan mejor en cada uno de estos puntos que los sistemas comparables que se centran en una sola característica. Esto no fue un gran problema, ya que el dominio general de los DBMS relacionales superó cualquier deficiencia. Sin embargo, si los BDR convencionales no cubrían las necesidades, siempre había alternativas.

Hoy la situación es un poco diferente. La variedad de aplicaciones está creciendo y con ella crece la importancia de estas características. Y a medida que crece el número de bases de datos, una característica comienza a eclipsar a todas las demás. Esto es escalabilidad. A medida que más aplicaciones se ejecutan con una carga elevada, como los servicios web, sus requisitos de escalabilidad pueden cambiar y crecer muy rápidamente. El primer problema puede resultar muy difícil de resolver si tiene una base de datos relacional ubicada en su propio servidor. Digamos que la carga del servidor se triplica durante la noche. ¿Qué tan rápido puede actualizar su hardware? Resolver el segundo problema también causa dificultades cuando se utilizan bases de datos relacionales.

Las bases de datos relacionales escalan bien sólo si están ubicadas en un único servidor. Cuando los recursos de este servidor se agoten, necesitarás agregar más máquinas y distribuir la carga entre ellas. Y aquí es donde la complejidad de las bases de datos relacionales empieza a jugar en contra de la escalabilidad. Si intenta aumentar el número de servidores no a unos pocos, sino a cientos o miles, la complejidad aumentará en un orden de magnitud, y las características que hacen que las bases de datos relacionales sean tan atractivas reducirán rápidamente las posibilidades de utilizarlas como plataforma. para grandes sistemas distribuidos a cero.

Para seguir siendo competitivos, los proveedores de servicios en la nube tienen que lidiar de alguna manera con esta limitación, porque ¿qué tipo de plataforma en la nube es sin un almacenamiento de datos escalable? Esto deja a los proveedores con una sola opción si quieren proporcionar a los usuarios un espacio de almacenamiento escalable. Es necesario utilizar otro tipo de bases de datos que tengan una mayor escalabilidad, aunque a costa de otras características disponibles en las bases de datos relacionales.

Estos beneficios, así como la demanda existente de ellos, han dado lugar a una ola de nuevos sistemas de gestión de bases de datos.

Nueva ola

Este tipo de base de datos se denomina comúnmente almacén de valores-clave. De hecho, no existe un nombre oficial, por lo que puede verlo en el contexto de bases de datos distribuidas orientadas a documentos, orientadas a atributos (aunque también pueden ser relacionales), matrices ordenadas fragmentadas, tablas hash distribuidas y clave-valor de almacenamiento. tipo. Si bien cada uno de estos nombres se refiere a características específicas del sistema, todos son variaciones de un tema que llamaremos almacenamiento de valores-clave.

Sin embargo, como quiera que se llame, este “nuevo” tipo de base de datos no es tan nuevo y siempre se ha utilizado principalmente para aplicaciones para las que el uso de bases de datos relacionales no sería adecuado. Sin embargo, sin la necesidad de escalabilidad de la web y la nube, estos sistemas siguieron teniendo poca demanda. Ahora el desafío es determinar qué tipo de almacenamiento es el más adecuado para un sistema en particular.
Las bases de datos relacionales y los almacenes de valores clave son fundamentalmente diferentes y están diseñados para resolver problemas diferentes. Comparar las características sólo te permitirá entender la diferencia entre ellas, pero comencemos con esto:

Características de almacenamiento

Base de datos relacional	Tienda de valores clave
Una base de datos consta de tablas, las tablas contienen columnas y filas, y las filas constan de valores de columnas. Todas las filas de una tabla tienen la misma estructura.	Para los dominios, se puede establecer una analogía con las tablas, pero a diferencia de las tablas, la estructura de datos para los dominios no está definida. Un dominio es una caja en la que puedes poner lo que quieras. Los registros dentro del mismo dominio pueden tener estructuras diferentes.
El modelo de datos 1 está predefinido. Está fuertemente tipado y contiene restricciones y relaciones para garantizar la integridad de los datos.	Los registros se identifican mediante una clave y cada registro tiene un conjunto dinámico de atributos asociados.
El modelo de datos se basa en la representación natural de los datos contenidos más que en la funcionalidad de la aplicación.	En algunas implementaciones, los atributos sólo pueden ser cadenas. En otras implementaciones, los atributos tienen tipos de datos simples que reflejan los tipos utilizados en programación: enteros, matrices de cadenas y listas.
El modelo de datos está normalizado para evitar la duplicación de datos. La normalización crea relaciones entre tablas. Las relaciones conectan datos de diferentes tablas.	Entre dominios, así como dentro de un dominio, las relaciones no están definidas explícitamente.

Sin uniones

Las tiendas de valores clave están orientadas a registros. Esto significa que toda la información relacionada con un registro determinado se almacena con él. Un dominio (que podemos considerar como una tabla) puede contener innumerables entradas diferentes. Por ejemplo, un dominio puede contener información sobre clientes y pedidos. Esto significa que los datos tienden a duplicarse entre diferentes dominios. Este es un enfoque aceptable porque el espacio en disco es barato. Lo principal es que permite almacenar todos los datos relacionados en un solo lugar, lo que mejora la escalabilidad ya que no es necesario unir datos de diferentes tablas. Cuando se utiliza una base de datos relacional, sería necesario utilizar combinaciones para agrupar la información necesaria en un solo lugar.

Aunque la necesidad de relaciones para almacenar pares clave-valor disminuye drásticamente, las relaciones todavía son necesarias. Estas relaciones suelen existir entre entidades subyacentes. Por ejemplo, un sistema de pedidos tendría registros que contienen datos sobre clientes, productos y pedidos. No importa si estos datos están en un dominio o en varios. La conclusión es que cuando un cliente realiza un pedido, probablemente no desee almacenar la información del cliente y del pedido en el mismo registro.
En cambio, el registro de pedido debe contener claves que apunten a los registros de clientes y productos correspondientes. Dado que los registros pueden almacenar cualquier información y las relaciones no están definidas en el modelo de datos en sí, el sistema de gestión de la base de datos no podrá verificar la integridad de las relaciones. Esto significa que puede eliminar clientes y los productos que pidieron. Garantizar la integridad de los datos recae enteramente en la aplicación.

Acceso a datos

Base de datos relacional	Tienda de valores clave
Los datos se crean, actualizan, eliminan y consultan utilizando el lenguaje de consulta estructurado (SQL).	Los datos se crean, actualizan, eliminan y consultan mediante llamadas a métodos API.
Las consultas SQL pueden recuperar datos de una sola tabla o de varias tablas mediante combinaciones.	Algunas implementaciones proporcionan una sintaxis similar a SQL para especificar condiciones de filtro.
Las consultas SQL pueden incluir agregaciones y filtros complejos.	A menudo sólo puedes utilizar operadores de comparación básicos (=, !=,<, >, <= и =>).
Una base de datos relacional normalmente contiene lógica integrada, como activadores, procedimientos almacenados y funciones.	Toda la lógica de integridad empresarial y de datos está contenida en el código de la aplicación.

Interacción con aplicaciones

Tiendas de valor clave: beneficios

Hay dos ventajas claras de estos sistemas sobre las tiendas relacionales.

Adecuado para servicios en la nube

La primera ventaja de los almacenes clave-valor es que son más simples y, por tanto, más escalables que las bases de datos relacionales. Si está cohospedando su propio sistema y planea colocar una docena o cien servidores que necesitarán manejar cargas cada vez mayores detrás de su almacén de datos, entonces los almacenes de valores clave son su elección.

Dado que dicho almacenamiento se puede ampliar fácil y dinámicamente, también resulta útil para los proveedores que ofrecen una plataforma de almacenamiento basada en web multiinquilino. Una base de datos de este tipo representa un medio relativamente barato de almacenamiento de datos con un gran potencial de escalabilidad. Los usuarios normalmente sólo pagan por lo que usan, pero sus necesidades pueden crecer. El proveedor podrá aumentar de forma dinámica y prácticamente sin restricciones el tamaño de la plataforma en función de la carga.

Integración más natural con el código

El modelo de datos relacional y el modelo de objetos de código suelen construirse de forma diferente, lo que genera cierta incompatibilidad. Los desarrolladores resuelven este problema escribiendo código que asigna el modelo relacional al modelo de objetos. Este proceso no tiene un valor claro y alcanzable rápidamente y puede llevar una cantidad de tiempo bastante significativa que se podría haber dedicado al desarrollo de la aplicación en sí. Mientras tanto, muchos almacenes de valores-clave almacenan datos en una estructura que se asigna a objetos de forma más natural. Esto puede reducir significativamente el tiempo de desarrollo.

Otros argumentos a favor del uso de almacenes clave-valor, como “Las bases de datos relacionales pueden volverse torpes” (por cierto, no tengo idea de lo que eso significa), son menos convincentes. Pero antes de convertirse en un defensor de dicho almacenamiento, lea la siguiente sección.

Tiendas de valor clave: desventajas

Las restricciones en las bases de datos relacionales garantizan la integridad de los datos en el nivel más bajo. Los datos que no cumplan las restricciones no pueden ingresar físicamente a la base de datos. En los almacenes de valores clave no existen tales restricciones, por lo que monitorear la integridad de los datos recae completamente en las aplicaciones. Sin embargo, cualquier código tiene errores. Si bien los errores en una base de datos relacional bien diseñada no suelen provocar problemas de integridad de los datos, los errores en los almacenes clave-valor sí suelen provocar problemas.

Otra ventaja de las bases de datos relacionales es que te obligan a pasar por el proceso de desarrollo de un modelo de datos. Si ha diseñado bien el modelo, la base de datos contendrá una estructura lógica que refleja completamente la estructura de los datos almacenados, pero que no coincide con la estructura de la aplicación. Esto hace que los datos sean independientes de la aplicación. Esto significa que otra aplicación puede usar los mismos datos y la lógica de la aplicación se puede cambiar sin ningún cambio en el modelo de base de datos. Para hacer lo mismo con un almacén clave-valor, intente reemplazar el proceso de diseño del modelo relacional con el diseño de clases, que crea clases genéricas basadas en la estructura natural de los datos.

Y no te olvides de la compatibilidad. A diferencia de las bases de datos relacionales, el almacenamiento basado en la nube tiene muchos menos estándares comunes. Aunque no son conceptualmente diferentes, todos tienen diferentes API, interfaces de solicitud y sus propias especificaciones. Por lo tanto, es mejor que confíe en su proveedor porque, si sucede algo, no podrá cambiar fácilmente a otro proveedor de servicios. Y dado que casi todos los almacenes modernos de valores clave están en versión beta 2, la confianza se vuelve aún más riesgosa que en el caso del uso de bases de datos relacionales.

Análisis de datos limitados

Normalmente, todo el almacenamiento en la nube se basa en un sistema de arrendamiento múltiple, lo que significa que una gran cantidad de usuarios y aplicaciones utilizan el mismo sistema. Para evitar el secuestro del sistema compartido, los proveedores suelen restringir la ejecución de solicitudes de alguna manera. Por ejemplo, en SimpleDB, una consulta no puede tardar más de 5 segundos en completarse. En Google AppEngine Datastore, no puede obtener más de 1000 registros en una solicitud 3.

Estas restricciones no son terribles para la lógica simple (crear, actualizar, eliminar y recuperar una pequeña cantidad de registros). ¿Pero qué pasa si tu aplicación se vuelve popular? Tiene muchos usuarios nuevos y muchos datos nuevos, y ahora desea poner nuevas experiencias a disposición de los usuarios o beneficiarse de alguna manera de los datos. Aquí puede resultarle difícil ejecutar incluso consultas simples para el análisis de datos. Funciones como el seguimiento de los patrones de uso de las aplicaciones o un sistema de recomendación basado en el historial del usuario pueden ser, en el mejor de los casos, difíciles de implementar. Y en el peor de los casos, son simplemente imposibles.

En este caso, para el análisis es mejor crear una base de datos separada, que se completará con datos de su almacén clave-valor. Piense de antemano en cómo se puede hacer esto. ¿Alojará el servidor en la nube o internamente? ¿Habrá problemas por retrasos en la señal entre usted y su proveedor? ¿Su almacenamiento admite esta transferencia de datos? Si tiene 100 millones de registros y puede tomar 1000 registros a la vez, ¿cuánto se necesitará para migrar todos los datos?

Sin embargo, no priorice la escalabilidad por encima de todo. Será inútil si sus usuarios deciden utilizar los servicios de otro servicio porque proporciona más funciones y configuraciones.

Almacenamiento en la nube

Muchos proveedores de servicios web ofrecen almacenes de valores clave para múltiples inquilinos. La mayoría de ellos cumplen con los criterios enumerados anteriormente, pero cada uno tiene sus propias características distintivas y difiere de los estándares descritos anteriormente. Echemos un vistazo a ejemplos de almacenamiento específicos, como SimpleDB, Google AppEngine Datastore y SQL Data Services.

Amazonas: SimpleDB

SimpleDB es un almacén de valores clave orientado a atributos incluido con Amazon WebServices. SimpleDB está en versión beta; los usuarios pueden utilizarlo de forma gratuita, siempre que sus necesidades no excedan un límite determinado.

SimpleDB tiene varias limitaciones. Primero, el tiempo de ejecución de la consulta está limitado a 5 segundos. En segundo lugar, no existen tipos de datos distintos de las cadenas. Todo se almacena, recupera y compara como una cadena, por lo que para comparar fechas necesitarás convertirlas al formato ISO8601. En tercer lugar, el tamaño máximo de cualquier cadena es 1024 bytes, lo que limita el tamaño del texto (por ejemplo, una descripción de producto) que puede almacenar como atributo. Sin embargo, dado que la estructura de datos es flexible, puede solucionar esta limitación agregando atributos "Descripción del producto1", "Descripción del producto2", etc. Pero el número de atributos también es limitado: un máximo de 256 atributos. Mientras SimpleDB está en versión beta, el tamaño del dominio está limitado a 10 gigabytes y la base de datos completa no puede ocupar más de 1 terabyte.

Una de las características clave de SimpleDB es el uso de un modelo (modelo de consistencia eventual). Este modelo es adecuado para trabajos de subprocesos múltiples, pero tenga en cuenta que una vez que cambia el valor de un atributo en un registro, es posible que las lecturas posteriores no vean esos cambios. La probabilidad de que tal desarrollo de eventos sea bastante baja, sin embargo, hay que recordarlo. No querrás vender el último boleto a cinco compradores sólo porque tus datos no eran consistentes en el momento de la venta.

Almacén de datos de Google App Engine

AppEngine Datastore de Google está construido sobre BigTable, el sistema interno de almacenamiento de datos estructurados de Google, no proporciona acceso directo a BigTable, pero puede considerarse como una interfaz simplificada para interactuar con BigTable.

AppEngine Datastore admite más tipos de datos dentro de un solo registro que SimpleDB. Por ejemplo, listas que pueden contener colecciones dentro de un registro.

Este es el almacén de datos que probablemente utilizará al desarrollar con Google AppEngine. Sin embargo, a diferencia de SimpleDB, no podrá utilizar AppEngine Datastore (o BigTable) fuera de los servicios web de Google.

Microsoft: servicios de datos SQL

SQL Data Services es parte de la plataforma Microsoft Azure. SQL Data Services es gratuito, está en versión beta y tiene límites de tamaño de base de datos. SQL Data Services es una aplicación independiente, un complemento de muchos servidores SQL que almacenan datos. Estas tiendas pueden ser relacionales, pero para usted, SDS es una tienda de valor clave, al igual que los productos descritos anteriormente.

Almacenamiento fuera de la nube

También hay una serie de opciones de almacenamiento que puedes usar fuera de la nube instalándolas tú mismo. Casi todos estos proyectos son jóvenes, en alfa o beta, y de código abierto. Con el código abierto, es posible que esté más consciente de los posibles problemas y limitaciones que con los productos propietarios.

sofádb

CouchDB es una base de datos orientada a documentos, de código abierto y disponible gratuitamente. JSON se utiliza como formato de almacenamiento de datos. CouchDB tiene como objetivo cerrar la brecha entre las bases de datos relacionales y orientadas a documentos utilizando "vistas". Estas vistas contienen datos de documentos en forma de tabla y le permiten crear índices y ejecutar consultas.

Actualmente, CouchDB no es una base de datos verdaderamente distribuida. Tiene funciones de replicación que le permiten sincronizar datos entre servidores, pero esta no es la distribución que se necesita para construir un entorno altamente escalable. Sin embargo, los desarrolladores de CouchDB están trabajando en esto.

Proyecto Voldemort

El proyecto Voldemort es una base de datos distribuida de valores clave diseñada para escalar horizontalmente en una gran cantidad de servidores. Nació del proceso de desarrollo de LinkedIn y se ha utilizado para varios sistemas con altos requisitos de escalabilidad. El proyecto Voldemort también utiliza un modelo de consistencia finita.

mongo

Mongo es una base de datos desarrollada en 10gen por Geir Magnusson y Dwight Merriman (a quienes quizás conozcas por DoubleClick). Al igual que CouchDB, Mongo es una base de datos orientada a documentos que almacena datos en formato JSON. Sin embargo, Mongo es más una base de objetos que un puro almacén de valores-clave.

Llovizna

Drizzle representa un enfoque muy diferente para resolver los problemas que las tiendas de valores clave están diseñadas para combatir. Drizzle comenzó como una bifurcación de MySQL 6.0. Posteriormente, los desarrolladores eliminaron una serie de funciones (incluidas vistas, activadores, expresiones compiladas, procedimientos almacenados, caché de consultas, ACL y algunos tipos de datos) para crear un DBMS más simple y rápido. Sin embargo, Drizzle todavía se puede utilizar para almacenar datos relacionales. El objetivo de los desarrolladores es crear una plataforma semirelacional diseñada para aplicaciones web y en la nube que se ejecutan en sistemas con 16 o más núcleos.

Solución

En última instancia, existen cuatro razones por las que podría elegir un almacén de valores-clave no relacional para su aplicación:

Sus datos están altamente orientados a documentos y se adaptan más a un modelo de datos de valor clave que a un modelo relacional.
Su modelo de dominio está altamente orientado a objetos, por lo que el uso de un almacén de valores clave reducirá la cantidad de código adicional necesario para transformar los datos.
El almacén de datos es económico y se integra fácilmente con los servicios web de su proveedor.
Su principal problema es la alta escalabilidad bajo demanda.

Sin embargo, al tomar una decisión, tenga en cuenta las limitaciones de bases de datos específicas y los riesgos que encontrará si opta por utilizar bases de datos no relacionales.

Para todos los demás requisitos, es mejor elegir el viejo DBMS relacional. ¿Están entonces condenados? Por supuesto que no. Al menos por ahora.

1 - En mi opinión, el término "estructura de datos" es más apropiado aquí, pero dejé el modelo de datos original.
2: lo más probable es que el autor quisiera decir que, en términos de sus capacidades, las bases de datos no relacionales son inferiores a las relacionales.
3 - Es posible que los datos ya estén desactualizados; el artículo data de febrero de 2009.

voldemort

llovizna

Agregar etiquetas

El surgimiento de la tecnología informática en nuestros tiempos modernos ha marcado una revolución de la información en todas las esferas de la actividad humana. Pero para evitar que toda la información se convierta en basura innecesaria en Internet global, se inventó un sistema de base de datos en el que los materiales se clasifican, sistematizan, facilitando su búsqueda y envío para su posterior procesamiento. Hay tres tipos principales: bases de datos relacionales, jerárquicas y de red.

Modelos fundamentales

Volviendo al surgimiento de las bases de datos, cabe decir que este proceso fue bastante complejo y se originó con el desarrollo de equipos de procesamiento de información programables; Por tanto, no es de extrañar que el número de sus modelos llegue actualmente a más de 50, pero los principales son el jerárquico, relacional y de red, que todavía se utilizan mucho en la práctica. ¿Cuáles son?

Jerárquico tiene una estructura de árbol y se compone de datos de diferentes niveles, entre los cuales existen conexiones. El modelo de base de datos de red es un patrón más complejo. Su estructura se asemeja a una jerárquica y su esquema se amplía y mejora. La diferencia entre ellos es que los datos descendientes de un modelo jerárquico solo pueden tener conexión con un antepasado, mientras que un modelo de red puede tener varios de ellos. La estructura de una base de datos relacional es mucho más compleja. Por tanto, conviene analizarlo con más detalle.

Concepto básico de una base de datos relacional.

Este modelo fue desarrollado en la década de 1970 por el Dr. Edgar Codd. Es una tabla estructurada lógicamente con campos que describe los datos, sus relaciones entre sí, las operaciones realizadas sobre ellos y, lo más importante, las reglas que garantizan su integridad. ¿Por qué el modelo se llama relacional? Se basa en relaciones (del latín relatio) entre datos. Existen muchas definiciones para este tipo de base de datos. Las tablas relacionales de información son mucho más fáciles de sistematizar y procesar que en un modelo de red o jerárquico. ¿Cómo hacer esto? Basta conocer las características, estructura del modelo y propiedades de las tablas relacionales.

El proceso de modelado y compilación de elementos básicos.

Para crear su propio DBMS, debe utilizar una de las herramientas de modelado, pensar con qué información necesita trabajar, diseñar tablas y relaciones relacionales únicas y múltiples entre datos, completar celdas de entidad y establecer claves primarias y externas.

El modelado de tablas y el diseño de bases de datos relacionales se realizan utilizando herramientas gratuitas como Workbench, PhpMyAdmin, Case Studio, dbForge Studio. Después del diseño detallado, debe guardar el modelo relacional listo gráficamente y traducirlo a código SQL listo para usar. En esta etapa se puede comenzar a trabajar con la clasificación, procesamiento y sistematización de datos.

Características, estructura y términos asociados al modelo relacional.

Cada fuente describe sus elementos a su manera, así que para reducir la confusión me gustaría dar una pequeña pista:

tabla relacional = entidad;
diseño = atributos = nombres de campos = encabezados de columna de entidad;
instancia de entidad = tupla = registro = cadena de tabla;
valor del atributo = entidad celda = campo.

Para pasar a las propiedades de una base de datos relacional, conviene saber en qué componentes básicos se compone y para qué están destinados.

Esencia. En una base de datos relacional puede haber una tabla, o puede haber un conjunto completo de tablas que caracterizan los objetos descritos gracias a los datos almacenados en ellas. Tienen un número fijo de campos y un número variable de registros. Una tabla de modelo de base de datos relacional se compone de filas, atributos y diseño.
Un registro es un número variable de líneas que muestran datos que caracterizan el objeto que se describe. La numeración de registros la realiza el sistema de forma automática.
Los atributos son datos que describen las columnas de una entidad.
Campo. Representa una columna de entidad. Su número es un valor fijo, establecido durante la creación o modificación de la tabla.

Ahora, conociendo los elementos que componen la tabla, podemos pasar a las propiedades del modelo de base de datos relacional:

Las entidades de bases de datos relacionales son bidimensionales. Gracias a esta propiedad, es fácil realizar con ellos diversas operaciones lógicas y matemáticas.
El orden de los valores de atributos y registros en una tabla relacional puede ser arbitrario.
Una columna dentro de una tabla relacional debe tener su propio nombre individual.
Todos los datos de una columna de entidad tienen una longitud fija y el mismo tipo.
Cualquier registro se considera esencialmente un elemento de datos.
Los componentes de las cuerdas son únicos. No hay filas idénticas en una entidad relacional.

Según las propiedades, está claro que los valores de los atributos deben ser del mismo tipo y longitud. Veamos las características de los valores de los atributos.

Principales características de los campos de bases de datos relacionales

Los nombres de los campos deben ser únicos dentro de una entidad. Los atributos o tipos de campos de bases de datos relacionales describen qué categoría de datos se almacena en los campos de la entidad. Un campo de base de datos relacional debe tener un tamaño fijo, medido en caracteres. Los parámetros y el formato de los valores de los atributos determinan cómo se corrigen los datos que contienen. También existe algo llamado “máscara” o “plantilla de entrada”. Su objetivo es definir la configuración de entrada de datos para un valor de atributo. Se debe emitir un mensaje de error si ingresa algo incorrecto en un campo. Además, se imponen algunas restricciones a los elementos de campo: condiciones para verificar la precisión y la ausencia de errores de la entrada de datos. Hay algún valor de atributo requerido que definitivamente debe completarse con datos. Algunas cadenas de atributos pueden estar rellenas con valores NULL. Se permiten datos en blanco en los atributos de campo. Al igual que la notificación de error, hay valores que el sistema completa automáticamente; estos son los datos predeterminados. Un campo indexado está diseñado para acelerar la búsqueda de cualquier dato.

Diagrama de una tabla de base de datos relacional bidimensional.

Para comprender el modelo en detalle usando SQL, lo mejor es mirar el diagrama usando un ejemplo. Ya sabemos qué es una base de datos relacional. Un registro en cada tabla es un elemento de datos. Para evitar la redundancia de datos, se deben realizar operaciones de normalización.

Reglas básicas para normalizar una entidad relacional.

1. El valor del nombre de campo para una tabla relacional debe ser único, único en su tipo (primera forma normal: 1NF).

2. Para una tabla que ya está convertida a 1NF, el nombre de cualquier columna no identificable debe depender del identificador único de la tabla (2NF).

3. Para una tabla completa que ya está en 2NF, cada campo no identificable no puede depender de un elemento de otro valor no identificado (entidad 3NF).

Bases de datos: relaciones relacionales entre tablas.

Hay 2 tablas relacionales principales:

"Uno-muchos". Ocurre cuando un registro clave de la tabla No. 1 corresponde a varias instancias de la segunda entidad. Un icono de llave en un extremo de una línea dibujada indica que la entidad está en el lado "uno"; el otro extremo de la línea suele estar marcado con un símbolo de infinito.

Una relación "muchos-muchos" se forma cuando ocurre una interacción lógica explícita entre varias filas de una entidad con una cantidad de registros de otra tabla.
Si se produce una concatenación uno a uno entre dos entidades, esto significa que el identificador de clave de una tabla está presente en la otra entidad, entonces una de las tablas debe eliminarse, ya que es redundante. Pero a veces, puramente por razones de seguridad, los programadores separan deliberadamente las dos entidades. Por lo tanto, hipotéticamente, podría existir una relación uno a uno.

Existencia de claves en una base de datos relacional

Las claves primarias y secundarias definen las relaciones potenciales de la base de datos. Las relaciones relacionales en un modelo de datos solo pueden tener una clave potencial, y esta será la clave principal. ¿Cómo es él? Una clave principal es una columna de entidad o un conjunto de atributos a través del cual se puede acceder a los datos de una fila específica. Debe ser único, único y sus campos no pueden contener valores vacíos. Si la clave principal consta de un solo atributo, entonces se llama simple; de lo contrario, será un componente.

Además de la clave primaria, también existe una clave externa. Mucha gente no entiende la diferencia entre ellos. Veámoslos con más detalle usando un ejemplo. Entonces, hay 2 tablas: “Decano” y “Estudiantes”. La entidad “Decanato” contiene los siguientes campos: “Cédula de Estudiante”, “Nombre completo” y “Grupo”. La tabla “Estudiantes” tiene valores de atributos como “Nombre”, “Grupo” y “GPA”. Dado que una identificación de estudiante no puede ser la misma para varios estudiantes, este campo será la clave principal. “Nombre completo” y “Grupo” de la tabla “Estudiantes” pueden ser iguales para varias personas; se refieren al número de identificación del estudiante de la entidad “Decano”, por lo que pueden usarse como clave externa.

Ejemplo de modelo de base de datos relacional

Para mayor claridad, damos un ejemplo simple de un modelo de base de datos relacional que consta de dos entidades. Hay una mesa llamada "Oficina del Decano".

Es necesario realizar conexiones para crear una base de datos relacional completa. La entrada "IN-41", como "IN-72", puede aparecer más de una vez en el letrero "Oficina del Decano" y, en casos excepcionales, el apellido, el nombre y el patronímico de los estudiantes pueden coincidir, por lo que estos campos no se pueden completar. la clave primaria. Mostremos la entidad "Estudiantes".

Como podemos ver, los tipos de campos de las bases de datos relacionales son completamente diferentes. Hay registros tanto digitales como simbólicos. Por lo tanto, en la configuración de atributos debe especificar los valores entero, char, vachar, fecha y otros. En la tabla "Oficina del Decano", el único valor único es el ID del estudiante. Este campo se puede tomar como clave principal. El nombre completo, el grupo y el número de teléfono de la entidad "Estudiantes" se pueden tomar como una clave externa que hace referencia a la identificación del estudiante. La conexión ha sido establecida. Este es un ejemplo de un modelo de relación uno a uno. Hipotéticamente, una de las tablas es redundante; se pueden combinar fácilmente en una sola entidad. Para evitar que los números de identificación de los estudiantes se hagan públicos, es completamente posible tener dos tablas.

Nivel 1: El nivel de modelos externos es el nivel más alto donde cada modelo tiene su propia visión de los datos. Esta capa define el punto de vista de la base de datos de aplicaciones individuales.

Nivel conceptual: El enlace de control central, donde se presenta la base de datos en la forma más general, que combina los datos utilizados por todas las aplicaciones. De hecho, el nivel conceptual refleja un modelo generalizado del área temática.

Capa Física (Base de Datos): Estos son los datos en sí ubicados en archivos o en estructuras de páginas ubicadas en medios de almacenamiento externos.

Modelos de datos

Se distinguen los siguientes modelos de datos:

1. Infológico

2. Fecha lógica

3. Físico

El proceso de diseño de una base de datos comienza con el diseño de un modelo de información. Un modelo de datos infológico es una descripción informal generalizada de la base de datos que se está creando, realizada 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.

tupla de dominio

El modelo de información refleja el mundo real en algún concepto comprensible para los humanos, completamente independiente del entorno de almacenamiento de datos. Por lo tanto, el Modelo de Infología no debe cambiar hasta que algún cambio en el mundo real requiera un cambio fuera de la definición para que el modelo continúe representando el dominio.

Hay muchos enfoques para construir este modelo: modelos de gráficos, redes semánticas, conexión de entidades y otros.

modelo datalogico

El modelo infológico debe visualizarse en un modelo datalógico que sea comprensible para el DBMS. Un modelo datalógico es una descripción formal de un modelo de información en el lenguaje DBMS.

Modelo jerárquico

Este modelo es una colección de elementos relacionados que forman una estructura jerárquica. Los conceptos básicos de jerarquía incluyen nivel, nodo y relación.

nivel de comunicacion

Un nodo es una colección de atributos de datos que describen un objeto. Cada nodo está conectado a un nodo en un nivel superior y a cualquier número de nodos en un nivel inferior. La excepción es el nodo de nivel más alto. La cantidad de árboles en la base de datos está determinada por la cantidad de raíces de los árboles. Cada registro de la base de datos tiene una única ruta desde el registro raíz. Un ejemplo sencillo es el sistema\dirección de nombres de dominio de Internet. En el primer nivel (la raíz del árbol) se encuentra nuestro planeta Tierra, en el segundo el País, en el tercero la Región, en el cuarto el asentamiento, la calle, la casa, el apartamento. Un representante típico es un DBMS de IBM - IMS.

Todas las instancias de un tipo descendiente determinado con una instancia común de un tipo ancestro se denominan gemelos. Se define un orden transversal completo para la base de datos. De arriba a abajo y de derecha a izquierda.

modelo fisico

Se construye un modelo físico basado en el modelo datalógico. La organización física de los datos tiene un impacto importante en el rendimiento de la base de datos. Los desarrolladores de DBMS intentan crear los modelos de datos físicos más productivos, ofreciendo a los usuarios una u otra herramienta para personalizar el modelo para una base de datos específica.

Ejemplo: En particular para una base de datos relacional, ya se tiene en cuenta:

1. Aspectos físicos del almacenamiento de tablas en archivos específicos.

2. Crear índices que optimicen la velocidad de las operaciones de datos utilizando la aplicación.

3. Realizar diversas acciones sobre datos ante ciertos eventos definidos por los usuarios mediante activadores y procedimientos almacenados.

Modelos infológicos X

Modelos fisicos

Para todos los niveles y para cualquier método de representación de un área temática, existe una codificación de conceptos de relaciones entre conceptos. La etapa clave en el desarrollo de cualquier sistema de información es realizar un análisis del sistema:

Formalización del área temática y representación del sistema como un conjunto de componentes.

La composición como base del análisis del sistema puede ser funcional (construir una jerarquía).

Sin embargo, en la mayoría de los sistemas, cuando se trata de bases de datos, los tipos de datos son un elemento más estático que la forma en que se procesan. Por lo tanto, métodos de análisis de sistemas como el diagrama de flujo de datos se han desarrollado intensamente. Desarrollo de bases de datos relacionales. Estimuló el desarrollo de metodologías de desarrollo de datos, en particular diagramas ER ER. El modelo de datos relacionales utiliza directamente el concepto de relación como mapeo. Es el más cercano al modelo conceptual de representación de datos. Y a menudo se encuentra en el meollo de la cuestión.

A diferencia del teórico del modelo de grafos, en el modelo relacional las conexiones entre relaciones se implementan de forma inexplícita, para lo cual se utilizan claves de relación. Por ejemplo, las relaciones de tipo jerárquico se implementan mediante el mecanismo de claves primarias y externas, cuando el hecho de los atributos debe estar presente en la relación subordinada.

Tal atributo de las relaciones en la relación principal se denominará clave primaria y, en una relación subordinada, secundaria.

Los avances en el desarrollo de lenguajes de programación asociados principalmente a la tipificación de datos y la aparición de lenguajes orientados a objetos han permitido abordar el análisis de sistemas complejos desde el punto de vista de representaciones jerárquicas, es decir, utilizando clases de objetos con las propiedades de polimorfismo, herencia y encapsulación.

LA RELACIÓN ES UNA MESA.

Edición de tablas, registros...

Eliminar lo que creaste y

Edición.

Modelo de base de datos relacional

Los modelos de datos relacionales son actualmente los más populares precisamente por esta representación de datos.

El modelo relacional puede considerarse como un método especial de representación de datos que contiene sus propios datos (en forma de tablas) y formas de trabajarlos y manipularlos (en forma de relaciones). El modelo relacional asume tres elementos conceptuales: Estructura, Integridad y Procesamiento de Datos. Estos elementos tienen sus propios conceptos obligatorios que deben explicarse para su posterior presentación.

La tabla se considera un almacén de datos directo. Tradicionalmente en los sistemas relacionales una tabla se llama actitud. Una fila de la tabla se llama desfile de automóviles y la columna atributo. En este caso, los atributos tienen nombres únicos (dentro de la relación).

El número de tuplas en una tabla se llama número cardinal. Número de atributos grado. Se establece un identificador único para una relación, es decir, uno o más atributos cuyos valores no son los mismos al mismo tiempo - el identificador se llama clave primaria.Dominio este es el conjunto de valores homogéneos válidos para un atributo particular. Por lo tanto, un dominio puede considerarse como un conjunto de datos con nombre, y los componentes de este conjunto son unidades lógicamente indivisibles (por ejemplo, una lista de nombres de empleados de una institución puede actuar como un dominio, pero no todos los nombres pueden estar presentes en la tabla).

SUMA Kireeva 25.50 Motylev 17.05 … …. …

Actitud

atributos

Los campos KOD, NOMBRE, SUMM son atributos de tabla contenidos en el encabezado.

Los pares KOD 5216, NAME Kireeva, SUMM 25.50 son elementos del cuerpo de la relación.

En las bases de datos relacionales, a diferencia de otros modelos, el usuario especifica qué datos necesita y no cómo hacerlo. Por esta razón, el proceso de mover y navegar una base de datos en sistemas relacionales es automático, y esta tarea se realiza en un SGBD. optimizador. Su trabajo es recuperar datos de la base de datos a pedido de la manera más eficiente. Por lo tanto, el optimizador debe al menos poder determinar de qué tablas se seleccionan los datos, cuánta información hay en estas tablas y cuál es el orden físico de los registros en las tablas y cómo están agrupados.

Además, una base de datos relacional también realiza funciones de directorio. El directorio almacena una descripción de todos los objetos que componen la base de datos: tablas, índices, disparadores, etc. Evidentemente un componente como el optimizador es vital para el correcto funcionamiento de todo el sistema. El optimizador utiliza la información almacenada en el directorio. Un dato interesante es que el catálogo en sí es un conjunto de tablas, por lo que el DBMS puede manipularlo de forma tradicional, sin recurrir a técnicas o métodos especiales.

Dominios y Relaciones

Definiciones básicas: Dominios, tipos de relaciones, predicados.

Las relaciones tienen una serie de propiedades básicas:

1. En el caso más general, no hay tuplas comunes en las relaciones; esto se desprende de la definición misma de relaciones. Sin embargo, para algunos DBMS, en algunos casos se permiten desviaciones de esta propiedad. Mientras exista una clave primaria en la relación, se excluyen las tuplas idénticas.

2. Las tuplas no están ordenadas de arriba a abajo; simplemente no existe el concepto de número posicional en una relación. En las relaciones, puedes organizar con éxito tuplas en cualquier orden sin perder información.

3. Los atributos no están ordenados de izquierda a derecha. Los atributos del encabezado de la relación se pueden organizar en cualquier orden sin comprometer la integridad de los datos. Por tanto, el concepto de número posicional en relación con un atributo tampoco existe.

4. Los valores de los atributos constan de unidades lógicamente indivisibles; esto se desprende del hecho de que los valores se toman de dominios; de lo contrario, podemos decir que las relaciones no contienen grupos de repetición; Es decir, están normalizados.

Los sistemas relacionales admiten varios tipos de relaciones:

1. Las nombradas son variables de relación definidas en el DBMS por los operadores de creación y, por regla general, necesarias para una presentación más conveniente de la información para el usuario.

2. Las relaciones básicas son una parte directamente importante de la base de datos, por lo que durante el diseño se les da su propio nombre.

3. Una relación derivada es aquella que se definió a través de otras relaciones, generalmente básicas, utilizando herramientas DBMS.

4. Esta representación es en realidad una relación derivada con nombre y la representación se expresa exclusivamente a través de operadores DBMS aplicados a relaciones con nombre, por lo que no existen físicamente en la base de datos.

5. El resultado de las consultas es una relación derivada sin nombre que contiene datos (el resultado de una consulta específica). El resultado no se almacena en la base de datos sino que existe mientras el usuario lo necesite.

6. Una relación almacenada es aquella que se mantiene físicamente en la memoria de las relaciones; las relaciones almacenadas suelen incluir la base de las relaciones. Con base en lo anterior, podemos definir una base de datos relacional como un conjunto de relaciones interconectadas.

Una conexión en este caso es la asociación de dos o más relaciones.

KOD	DIRECCIONES

1 1 Una relación uno a muchos es que en un momento dado cada elemento (tupla A) corresponde a varios elementos de las tuplas B
∞ Conexión binaria

Estudiantes

Maestros

Horario de clases

∞

Estudiantes

Conexiones ternarias

Integridad de datos

En los modelos relacionales, la cuestión de la integridad de los datos ocupa un lugar especial. Recuerde que una clave o clave potencial es un conjunto mínimo de atributos cuyos valores se pueden usar para encontrar de forma única la tupla requerida, lo que significa que excluir cualquier atributo del conjunto no permite identificar la tupla por los atributos restantes.

Cada relación tiene al menos una clave posible. Uno de ellos se toma como clave principal.

Al elegir una clave primaria, se debe dar preferencia a claves no compuestas o claves formadas por un conjunto mínimo de atributos. Tampoco es deseable utilizar claves con valores de texto largos (es preferible utilizar atributos enteros como claves). Por lo tanto, para identificar a un empleado, puede utilizar un número de personal único, un número de pasaporte o un conjunto de apellidos, segundos nombres y números de departamento. No está permitido que la clave primaria de una relación, es decir, cualquier atributo que participe en la clave primaria, tome valores indefinidos. En este caso, surgirá una situación contradictoria ( colisión): Aparece un elemento de clave principal no único. Por lo tanto, esto debe controlarse cuidadosamente al diseñar una base de datos.

Acerca de las claves externas. Vale la pena señalar que dado que la relación C vincula las relaciones B y A, debe incluir claves foráneas correspondientes a las claves primarias de las relaciones A y B.

La clave externa de una tabla se forma utilizando varias claves primarias de otras tablas.

Por lo tanto, al considerar el problema de elegir un método para conectar una relación en una base de datos, surge la pregunta de cuáles deberían ser las claves externas. Al mismo tiempo, para cada clave externa es necesario resolver el problema asociado con la posibilidad (o imposibilidad) de que aparezcan valores indefinidos en las claves externas (NULL - valores - valor de atributo para información faltante). En otras palabras, ¿puede haber alguna tupla en una relación cuya tupla en sus relaciones asociadas no se conozca?

Por otro lado, es necesario pensar de antemano qué sucederá al eliminar tuplas de una relación referenciada por una clave externa. Existen las siguientes posibilidades posibles:

· Operación cascadas– es decir, eliminar tuplas en relaciones lleva a eliminar tuplas asociadas con la relación. Por ejemplo, eliminar información sobre apellido, nombre, etc. el empleado en un aspecto conduce a la eliminación de su salario en otro aspecto;

· Operación limitado - es decir, sólo se eliminan aquellas tuplas para las que no existe otra información asociada. No toda la información se elimina (no en todos los aspectos), ya que puede usarse en otro aspecto, cuya eliminación conduce a una violación de la integridad de los datos. Si dicha información está disponible, no se puede realizar la eliminación, por ejemplo, eliminar información sobre el nombre, apellido, etc. El empleado solo es posible si no hay información relacionada sobre su salario.

Es necesario proporcionar tecnología para lo que sucederá cuando se intente actualizar la clave primaria de una relación a la que hace referencia una clave externa. Aquí tienes las mismas opciones que al eliminar:

· La operación es en cascada, es decir, cuando se actualiza la clave primaria, se actualiza la clave externa en la relación relacionada. Por ejemplo, la actualización de la clave principal en una relación donde se almacena información de los empleados conduce a una actualización de la clave externa en una relación que contiene información salarial.

· La operación se limita a actualizar sólo aquellas claves primarias para las que no hay información asociada. Si dicha información está disponible, no se puede realizar la actualización. Por ejemplo, actualizar la clave principal en una relación donde se almacena información sobre un empleado solo es posible si falta información sobre su salario en la relación relacionada.1

Álgebra relacional

La base formal del modelo de base de datos relacional es el álgebra relacional, basada en la teoría de conjuntos y que considera un operador especial sobre las relaciones, y el cálculo relacional basado en la lógica matemática.

Trabajar

A A A B B C

Y Y D

A B C

Y Y D

F F W

Cabe señalar que el álgebra relacional es muy poderosa: las consultas complejas de bases de datos se pueden expresar utilizando una sola expresión. Es por ello que estos mecanismos se incluyen en el modelo de datos relacionales. Cualquier consulta expresada utilizando una expresión de álgebra relacional o una fórmula de cálculo relacional se puede expresar utilizando un operador en este lenguaje.

El álgebra relacional tiene una propiedad importante: es cerrada con respecto al concepto de relación. Esto significa que se realiza una expresión de álgebra relacional sobre las relaciones de bases de datos relacionales y los resultados de su cálculo también representan relaciones.

La idea principal del álgebra relacional es que los medios para manipular las relaciones consideradas como un conjunto se basan en operaciones múltiples tradicionales complementadas con algunas operaciones específicas de la base de datos.

Describamos la versión de álgebra propuesta por CODD. La operación consta de 8 operadores principales:

Búsqueda de relación (operación unaria)

Proyección de relación (operación unaria)

· Fusionar relaciones

· Intersección de relaciones (operación binaria)

· Resta de razones

Producto de las relaciones

· Conectando relaciones

· División de relaciones

Estas operaciones se pueden explicar de la siguiente manera:

· El resultado de seleccionar una relación basada en alguna condición es una relación que incluye sólo aquellas tuplas de la relación original que satisfacen esta condición.

· Al proyectar una relación sobre un determinado conjunto de sus atributos, se obtendrá una relación cuyas tuplas se toman de las tuplas correspondientes de la primera relación.

· Al realizar la operación de fusionar dos relaciones se obtendrá una relación que incluya todas las tuplas incluidas en al menos una de las relaciones participantes en la operación.

· Al realizar la operación de intersección de dos relaciones, se obtendrá una relación que incluye todas las tuplas incluidas en ambas relaciones iniciales.

· Al realizar la operación de restar dos relaciones se obtendrá una relación que incluye todas las tuplas incluidas en la primera relación, excepto aquellas que también están incluidas en la segunda relación.

· Al realizar el producto directo de dos relaciones, se obtiene una relación cuyas tuplas son una combinación de las tuplas de la primera y segunda relación.

· Cuando dos relaciones se conectan según alguna condición, se forma una relación resultante de tuplas cuyas tuplas son una combinación de tuplas de la primera y segunda relaciones que satisfacen esta condición.

· La operación de división relacional tiene dos operandos: una relación binaria (que consta de dos atributos) y una relación unaria (que consta de un atributo). El resultado de la operación es una relación formada por tuplas que incluyen la relación del primer atributo de tuplas de la primera relación, y tal que el conjunto de valores del segundo atributo coincide con el conjunto de valores de la segunda relación. .

Además de lo anterior, existen una serie de operaciones especiales específicas para trabajar con bases de datos:

· Como resultado de la operación de cambio de nombre, una relación es un conjunto de tuplas que coincide con el cuerpo de la relación original, pero los nombres de los atributos han sido cambiados.

De ello se deduce que el resultado de una operación relacional es una determinada relación; es posible formar expresiones relacionales en las que, en lugar de la relación original (operando), se utilizará una expresión relacional incorporada. Esto se debe al hecho de que las operaciones del álgebra relacional están verdaderamente cerradas al concepto de relación. Empecemos con la operación. unificación de relaciones, sin embargo, esto se aplica igualmente a las operaciones de intersección y combinación, es decir, en álgebra relacional, el resultado de la operación de unión es una relación. Si asumimos en álgebra relacional la posibilidad asociaciones Dos relaciones arbitrarias con diferentes conjuntos de atributos, entonces el resultado de tal operación será un conjunto, pero un conjunto de tuplas de diferentes tipos, es decir, en términos generales, no una relación. Si partimos del requisito de que el álgebra relacional sea cerrado con respecto al concepto de relación, entonces tal operación asociaciones no tiene sentido. Esto lleva al surgimiento del concepto compatibilidad de relaciones Por unificación: Dos relaciones son compatibles sólo si tienen los mismos encabezados, es decir, tienen el mismo conjunto de nombres de atributos y los atributos del mismo nombre están definidos en el mismo dominio.

Siempre que dos relaciones sean compatibles por unión, cuando normalmente se realiza sobre ellas una operación unión-intersección-resta, el resultado de la operación es una relación con un encabezado correctamente definido que coincide con el encabezado de cada una de las relaciones de operandos. Si dos relaciones no son totalmente compatibles con la unión, es decir, compatibles en todo excepto en los nombres de los atributos, antes de realizar una operación de tipo unión, estas relaciones pueden volverse totalmente compatibles mediante la aplicación de una operación de cambio de nombre.

La operación del producto directo de dos relaciones plantea nuevos problemas. En teoría de conjuntos, el producto directo se puede obtener para cualquier conjunto. Los elementos del conjunto resultante serán pares formados por elementos del primer y segundo conjunto. Como las relaciones son conjuntos, para dos relaciones cualesquiera es posible obtener un producto directo. Sin embargo, el resultado no será una relación. Los elementos del resultado no serán tuplas, sino pares de tuplas. Por lo tanto, en álgebra relacional se utiliza una forma especial de operación de producto directo: el producto directo extendido de relaciones. Cuando se toma el producto directo extendido de dos relaciones, el elemento de la relación resultante es una tupla formada al fusionar una tupla de la primera relación y una tupla de la segunda relación. Inmediatamente surge un segundo problema relacionado con la obtención de un encabezado correctamente formado de la relación resultante; esto lleva a la necesidad de introducir el concepto de compatibilidad de relaciones tomando un producto directo extendido.

Dos relaciones son compatibles tomando un producto directo sólo si el conjunto de nombres de atributos de estas relaciones no se cruzan. Dos relaciones cualesquiera se pueden convertir en una forma de producto directo compatible aplicando una operación de cambio de nombre a una de las relaciones.

La operación de búsqueda requiere dos relaciones: una relación inicial, el operando y una condición de restricción simple. Como resultado de la operación de selección, se produce una relación cuyo encabezado coincide con el encabezado de la relación de operando, y el cuerpo incluye aquellas tuplas de la relación de operando que satisfacen los valores de la condición de restricción.

Introduzcamos una serie de operadores.

Sea unión la operación de unión, intersección – la operación de intersección, menos – la operación de resta. Para denotar la operación de muestreo, usaremos la construcción A donde B, donde A es la relación del operando y B es una condición de comparación simple. Sean C1 y C2 dos condiciones de muestreo simples.

A donde C1 Y C2 son idénticos (A donde C1) se cruzan (A donde C2)

A donde C1 O C2 es idéntico a (A donde C1) unión (A donde C2)

A donde C1 no C2 es idéntico a (A donde C1) menos (A donde C2)

Usando estas definiciones, es posible implementar operaciones de muestreo en las que la condición de muestreo es una expresión lógica arbitraria compuesta de condiciones simples usando conexiones lógicas (y, o, no). La operación de tomar proyecciones de la relación A sobre la lista de atributos a1, a2,…,an será una relación cuyo encabezado es el conjunto de atributos, a1,a2,…,an. El cuerpo del resultado estará formado por tuplas para las cuales en la relación A hay una tupla, el atributo a1 tiene el valor b1, el atributo a2 tiene el valor b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.

La operación de unión, a veces denominada unión condicional, requiere dos operandos, las relaciones que se unen, y un tercer operando, la condición simple. Deje que la relación A y B estén conectadas. Como en el caso de la operación de selección, la condición de unión C tiene la forma (a comp –op b) o (a comp –op const) donde A y B son los nombres de las relaciones. atributos de las relaciones A y B, const se especifica literalmente constante. Comp-op es una operación de comparación válida en este contexto. Entonces, por definición, el resultado de la operación de conexión es la relación obtenida al realizar la operación de restricción, según la condición C, el producto directo de la relación A y B.

Hay un caso especial importante de conexión, la conexión natural. Una operación de unión se denomina operación de unión natural si las condiciones de unión tienen la forma (a=b), donde a y b son atributos de diferentes operandos de unión. Este caso es importante porque es particularmente común en la práctica y existen algoritmos de implementación efectivos para ello en un DBMS. La operación de unión natural se aplica a un par de relaciones A y B que tienen un atributo común P, es decir, un atributo con el mismo nombre y definido en el mismo dominio. Sea ab la unión de los encabezados de las relaciones A y B. Entonces una unión natural es el resultado de la unión de A y B proyectada sobre ab. Las operaciones de unión natural no están incluidas directamente en el conjunto de operaciones del álgebra relacional. pero tienen un significado práctico muy importante.

La operación de dividir relaciones necesita una explicación más detallada porque es difícil de entender. Sean dadas dos relaciones A (a1,a2,..,an,b1,b2,…,bm)

B (b1,b2,…,bn) Suponemos que el atributo b1 de la relación A y el atributo b1 de la relación B están definidos en el mismo dominio. Llamemos al conjunto de atributos (aj) un atributo compuesto a, y al conjunto (bj) c un atributo compuesto b. Después de esto, hablaremos de la división relacional de la relación binaria A (a,b) en la relación unaria B (b).

El resultado de dividir A por B es una relación unaria C (a), que consta de tuplas v tal que en la relación A hay tuplas que en el conjunto de valores (w) incluyen el conjunto de valores de b con relación a B.

Dado que la división es la operación más difícil, expliquemosla con un ejemplo. Sea dos relaciones en la base de datos de estudiantes: ESTUDIANTES (NOMBRE COMPLETO, NÚMERO) y NOMBRES (NOMBRE COMPLETO), y la relación unaria NOMBRES contiene todos los nombres que tienen los estudiantes del instituto. Luego, luego de realizar la operación de división relacional de la relación ESTUDIANTES en la relación NOMBRES, se obtendrá una relación unaria que contiene los números de tarjetas de estudiantes pertenecientes a estudiantes con todos los apellidos posibles en este instituto.

Notación relacional

Digamos que hay una base de datos con la estructura ESTUDIANTES (número, nombre, beca, código de grupo) y la relación GRUPOS (gr_nom, gr_col, gr antiguo). Supongamos que necesita averiguar los nombres y números de los estudiantes. entradas para estudiantes que son prefectos de grupos con más de 25 personas En álgebra relacional, es necesario realizar las siguientes acciones para dicha solicitud:

1. Conecte las relaciones ESTUDIANTES y GRUPOS, según la condición “número_estudiante = estrella_grupo”;

2. Limite la proporción resultante por la condición gr_col>25.

3. Proyectar el resultado de la operación anterior en el atributo nombre_estudiante, número_estudiante.

A continuación se presenta una formulación paso a paso de la secuencia de ejecución de consultas en la base de datos, cada una de las cuales corresponde a una operación relacional. Si formulamos la misma consulta usando cálculo relacional, obtendríamos una fórmula que se puede leer: Emita NOMBRE_ESTUDIO y NÚMERO_ESTUDIO para dichos estudiantes para que coexistan dicho grupo GR_STAR y el valor GR_NUM>25. En la segunda formulación, indicamos sólo las características de la relación resultante pero no dijimos nada sobre el método de su formación. En este caso, el propio SGBD debe decidir qué tipo de operaciones y en qué orden se deben realizar sobre las relaciones ESTUDIANTES y GRUPOS. Ambos métodos discutidos en el ejemplo son en realidad equivalentes y no existen conversiones muy complicadas de uno a otro.

Los conceptos básicos del cálculo relacional son los conceptos de una variable con un área determinada de su valor y los conceptos de una fórmula correctamente construida basada en variables y funciones especiales. Funciones. Cuál es el dominio de definición de una variable difiere entre el cálculo de tuplas y el cálculo de dominio, es decir, a lo largo o a lo ancho. En el cálculo de tuplas, el dominio de definición de variable es la relación de la base de datos, es decir, el valor válido de cada variable es una tupla de alguna relación. En el cálculo de dominios, los dominios de definición de variables son los dominios en los que se definen los atributos de las relaciones de la base de datos, es decir, el valor válido de cada variable es el valor de cada variable.

Byte

Entero

Cadena

Carbonizarse

METRO

norte

El comando RANGE se utiliza para definir tuplas. Por ejemplo, para definir la variable ESTUDIANTE cuyo alcance es ESTUDIANTES, debe utilizar la construcción RANGE ESTUDENT IS ESTUDIANTES. De esta definición se deduce que en cualquier momento la variable estudiante representa una determinada tupla de la relación ESTUDIANTES. Cuando utiliza variables de tupla en fórmulas, puede hacer referencia a valores de atributos de variables. Por ejemplo, para hacer referencia al valor del atributo STUDENT_NAME de la variable STUDENT, debe utilizar la construcción STUDENT.STUDENT_NAME.

Se utilizan fórmulas correctamente construidas para expresar condiciones impuestas a variables de tupla. Estas fórmulas se basan en comparaciones simples, que son operaciones que comparan los valores de los atributos de variables y constantes literales. Por ejemplo, la construcción STUDENT.STUD_NOM=123456. Es una comparación simple. Una versión más compleja de fórmulas compuestas utiliza conexiones lógicas Y, O, NO, SI... ENTONCES. Finalmente, es posible construir fórmulas bien formadas utilizando cuantificadores. Si F es una fórmula bien formada que involucra la variable var, entonces la construcción EXIST (cuantificador de existencia) var (F) y FORALL (para todas las tuplas) var (F) son correctas.

Las variables incluidas en fórmulas construidas correctamente pueden ser libres o vinculadas. Son libres todas las variables incluidas en su composición en cuya construcción no se utilizaron cuantificadores. Esto significa que si para algún conjunto de valores de variables de tupla libre se obtiene el valor "verdadero" al calcular las fórmulas, entonces estos valores se pueden incluir en la relación resultante. Si se utiliza un cuantificador al construir fórmulas, entonces las variables están relacionadas. Al calcular el valor de una fórmula tan correctamente construida, no se utiliza un solo valor de la variable asociada, sino todo su dominio de definición.

1)EXISTE STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

2)PARA TODO STUD2 (STUD.1STUD_STIP> STUD2.STUD_STIP)

Sean STUD1 y STUD2 dos variables de tupla definidas para la relación estudiantes, entonces la fórmula para la tupla actual de la variable STUD1 toma el valor verdadero solo si en toda la relación estudiantes existe una tupla asociada con la variable STUD2 tal que la El valor de su atributo STUD_STIP satisface la condición de comparación interna. La fórmula N° 2 correctamente construida para la tupla construida ESTUDIANTE 1 toma el valor verdadero si para todas las tuplas la relación ESTUDIANTES asociada a la variable ESTUDIANTE 2, el valor del atributo ESTUDIANTE.STIP satisface la condición interna.

Por tanto, las fórmulas bien formadas proporcionan un medio para expresar las condiciones de muestreo de una relación de base de datos. Para poder utilizar el cálculo relacional para trabajar realmente con una base de datos, se requiere otro componente que defina el conjunto y los nombres de las columnas de la relación resultante. Este componente se llama lista de objetivos.

lista de objetivos tiene la forma:

· Var.attr es el nombre de una variable libre, attr es el nombre del atributo de relación en el que se define la variable var.

· Var que es equivalente a la relación de la lista, Var.attr1, Var.attr1... Var.attr№ incluye los nombres de todos los atributos de la relación que define.

· Nuevo_nombre = var.attr; el nuevo nombre del atributo correspondiente de la relación resultante.

La última opción es obligatoria en los casos en que el código de la fórmula utiliza varias variables libres con el mismo alcance. En el cálculo de dominios, el dominio de definición de dominios no son las relaciones sino los dominios. En relación a la base de datos de GRUPO DE ESTUDIANTES, podemos hablar de variables de dominio NOMBRE (Los valores de dominio son nombres válidos o NOM STUD). (Los valores de dominio son números de estudiantes válidos).

La principal diferencia entre el cálculo de dominio y el cálculo de tuplas es la presencia de un conjunto adicional de predicados que permiten expresar las llamadas condiciones de membresía. Si R es una relación n-aria con atributos (a1, a2,… an), entonces la condición de membresía tiene la forma R(ai1:Vi1,ai2:Vi2,…aim:Vim) donde (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.

Un predicado es una función lógica que devuelve verdadero o falso para algún argumento. Una relación puede considerarse como un predicado con argumentos que son atributos de la relación en cuestión. Si un conjunto específico de tuplas está presente en la relación, entonces el predicado producirá un resultado verdadero; de lo contrario, producirá un resultado falso.

En todos los demás aspectos, las fórmulas y expresiones del cálculo de dominio son similares a las fórmulas y expresiones del cálculo de tuplas. El cálculo de dominio relacional es la base de la mayoría de las consultas de lenguaje basadas en formularios.

Información relacionada.

Base de datos (BD) - Se trata de un conjunto con nombre de datos estructurados relacionados con un área temática específica y destinados al almacenamiento, acumulación y procesamiento mediante una computadora.

Base de datos relacional (RDB) es un conjunto de relaciones cuyos nombres coinciden con los nombres de las relaciones de esquema en el esquema de la base de datos.

Conceptos básicos bases de datos relacionales:

· tipo de datos– tipo de valores de una columna específica.

· Dominio(dominio): el conjunto de todos los valores de atributos válidos.

· Atributo(atributo): encabezado de columna de la tabla que caracteriza una propiedad nombrada de un objeto, por ejemplo, apellido del estudiante, fecha del pedido, sexo del empleado, etc.

· Cortejo– una fila de la tabla que representa un conjunto de valores de atributos lógicamente relacionados.

· Actitud(relación): una tabla que refleja información sobre objetos del mundo real, por ejemplo, sobre estudiantes, pedidos, empleados, residentes, etc.

· clave primaria(clave principal): un campo (o conjunto de campos) de una tabla que identifica de forma única cada uno de sus registros.

· Clave alternativa es un campo (o conjunto de campos) que no coincide con la clave principal e identifica de forma única una instancia de un registro.

· clave externa es un campo (o conjunto de campos) cuyos valores coinciden con los valores existentes de la clave primaria de otra tabla. Cuando vincula dos tablas, la clave principal de la primera tabla se vincula a la clave externa de la segunda tabla.

· Modelo de datos relacionales (RDM)- organizar datos en forma de tablas bidimensionales.

Cada tabla relacional debe tener las siguientes propiedades:

1. Cada registro de la tabla es único, es decir. el conjunto de valores en los campos no se repite.

2. Cada valor escrito en la intersección de una fila y una columna es atómico (inseparable).

3. Los valores de cada campo deben ser del mismo tipo.

4. Cada campo tiene un nombre único.

5. El orden de las entradas no es significativo.

Elementos principales de la base de datos:

Campo- una unidad elemental de organización lógica de datos. Las siguientes características se utilizan para describir el campo:

· nombre, por ejemplo, apellido, nombre, patronímico, fecha de nacimiento;

· escriba, por ejemplo, cadena, carácter, numérico, fecha;

· longitud, por ejemplo, en bytes;

· precisión para datos numéricos, como dos decimales para mostrar la parte fraccionaria de un número.

Registro- un conjunto de valores de campos lógicamente relacionados.

Índice– un medio para acelerar la operación de búsqueda de registros, utilizado para establecer relaciones entre tablas. Una tabla para la que se utiliza un índice se llama indexada. Cuando trabaje con índices, debe prestar atención a la organización de los índices, que es la base de la clasificación. Un índice simple está representado por un único campo o una expresión booleana que procesa un único campo. Un índice compuesto está representado por varios campos con la capacidad de utilizar varias funciones. Los índices de las tablas se almacenan en un archivo de índice.

Integridad de datos– este es un medio para proteger los datos en los campos de comunicación, permitiéndole mantener tablas en un estado consistente (consistente) (es decir, no permitiendo la existencia de registros en una tabla subordinada que no tengan registros correspondientes en la tabla principal).

Pedido– una pregunta formulada para uno o más cuadros interconectados que contienen criterios de muestreo de datos. La consulta se realiza utilizando el lenguaje de consulta estructurado SQL (Structured Query Language). La recuperación de datos de una o más tablas puede generar un conjunto de registros denominado vista.

presentación de datos– una consulta con nombre almacenada en la base de datos para recuperar datos (de una o más tablas).

Una vista es esencialmente una tabla temporal creada como resultado de una consulta. La solicitud en sí se puede enviar a un archivo, informe, tabla temporal, tabla en disco, etc.

Informe– un componente del sistema cuyo objetivo principal es describir e imprimir documentos basados en información de la base de datos.

Características generales de trabajar con RDB:

La interpretación más común del modelo de datos relacionales parece ser la de Data, quien lo reproduce (con varios refinamientos) en casi todos sus libros. Según Date, el modelo relacional consta de tres partes que describen diferentes aspectos del enfoque relacional: la parte estructural, la parte de manipulación y la parte holística.

La parte estructural del modelo establece que la única estructura de datos utilizada en bases de datos relacionales es la relación n-aria normalizada.

La parte de manipulación del modelo afirma dos mecanismos fundamentales para manipular bases de datos relacionales: álgebra relacional y cálculo relacional. El primer mecanismo se basa principalmente en la teoría de conjuntos clásica (con algunos refinamientos), y el segundo se basa en el aparato lógico clásico del cálculo de predicados de primer orden. Tenga en cuenta que la función principal de la parte de manipulación del modelo relacional es proporcionar una medida de la relacionalidad de cualquier lenguaje de base de datos relacional específico: un lenguaje se llama relacional si no tiene menos expresividad y poder que el álgebra relacional o el cálculo relacional.

28. LENGUAJES ALGORITMICOS. TRADUCTORES (INTÉRPRETES Y COMPILADORES). LENGUAJE ALGORITMICO BÁSICO. ESTRUCTURA DEL PROGRAMA. IDENTIFICADORES. VARIABLES. OPERADORES. PROCESADO DE ARRAYS UNIDIMENSIONALES Y BIDIMENSIONALES. FUNCIONES DE USUARIO. SUBRUTINAS. TRABAJANDO CON ARCHIVOS DE DATOS.

lenguaje de alto nivel- un lenguaje de programación cuyos conceptos y estructura son convenientes para la percepción humana.

lenguaje algorítmico(Lenguaje algorítmico) - un lenguaje de programación - un lenguaje artificial (formal) diseñado para escribir algoritmos. Un lenguaje de programación se define por su descripción y se implementa en forma de un programa especial: un compilador o intérprete. Ejemplos de lenguajes algorítmicos son Borland Pascal, C++, Basic, etc.

Conceptos básicos del lenguaje algorítmico:

Composición del idioma:

El lenguaje hablado ordinario consta de cuatro elementos básicos: símbolos, palabras, frases y oraciones. Un lenguaje algorítmico contiene elementos similares, solo las palabras se llaman construcciones elementales, las frases se llaman expresiones y las oraciones se llaman operadores.

Símbolos, las construcciones elementales, expresiones y operadores forman una estructura jerárquica, ya que las construcciones elementales se forman a partir de una secuencia de símbolos.

Expresiones es una secuencia de estructuras y símbolos elementales,

Operador- una secuencia de expresiones, estructuras elementales y símbolos.

Descripción del idioma:

Una descripción de símbolo consiste en enumerar los símbolos válidos del idioma. La descripción de estructuras elementales implica las reglas de su formación. La descripción de expresiones son las reglas para la formación de cualquier expresión que tenga sentido en un idioma determinado. La descripción de operadores consiste en una discusión de todos los tipos de operadores permitidos en el idioma. La descripción de cada elemento del lenguaje viene dada por su SINTAXIS y SEMÁNTICA.

Sintáctico Las definiciones establecen reglas para construir elementos del lenguaje.

Semántica define el significado y las reglas de uso de aquellos elementos del lenguaje para los cuales se han dado definiciones sintácticas.

Símbolos del idioma- estos son los signos básicos e indivisibles en función de los cuales se escriben todos los textos de la lengua.

Estructuras elementales- estas son las unidades mínimas del lenguaje que tienen un significado independiente. Se forman a partir de los símbolos básicos del idioma.

Expresión en un lenguaje algorítmico consta de estructuras y símbolos elementales; especifica una regla para calcular un determinado valor;

Operador especifica una descripción completa de alguna acción que debe realizarse. Es posible que se requiera un grupo de declaraciones para describir una acción compleja.

En este caso, los operadores se combinan en operador compuesto o Bloquear. Comportamiento, especificados por los operadores, se ejecutan en los datos. Las declaraciones de un lenguaje algorítmico que proporcionan información sobre tipos de datos se denominan declaraciones o declaraciones no ejecutables. Un conjunto de descripciones y operadores unidos por un único algoritmo forma un programa en un lenguaje algorítmico. En el proceso de estudio de un lenguaje algorítmico, es necesario distinguir el lenguaje algorítmico del lenguaje con el que se realiza la descripción del lenguaje algorítmico en estudio. Por lo general, el idioma que se está estudiando se llama simplemente idioma, y el idioma en términos del cual se da la descripción del idioma que se está estudiando: Metalenguaje.

Traductores - (Traductor de inglés - traductor) es un programa de traducción. Convierte un programa escrito en uno de los lenguajes de alto nivel en un programa que consta de instrucciones de máquina.

Un programa escrito en cualquier lenguaje algorítmico de alto nivel no se puede ejecutar directamente en una computadora. La computadora entiende sólo el lenguaje de los comandos de la máquina. En consecuencia, un programa en un lenguaje algorítmico debe traducirse (traducirse) al lenguaje de comando de una computadora específica. Esta traducción se realiza automáticamente mediante programas de traducción especiales creados para cada lenguaje algorítmico y para cada tipo de computadora.

Hay dos métodos principales de transmisión: recopilación e interpretación.

1.Compilación: compilador(Compilador en inglés - compilador, recopilador) lee el programa completo, lo traduce y crea una versión completa del programa en lenguaje de máquina, que luego se ejecuta.

En compilación todo el programa original se convierte inmediatamente en una secuencia de instrucciones de máquina. Después de esto, el programa resultante se ejecuta en una computadora con los datos de origen disponibles. La ventaja de este método es que la traducción se realiza una vez y la ejecución (múltiples) del programa resultante se puede realizar a alta velocidad. Al mismo tiempo, el programa resultante puede ocupar mucho espacio en la memoria de la computadora, ya que un operador de idioma es reemplazado por cientos o incluso miles de comandos durante la traducción. Además, la depuración y modificación del programa emitido es muy difícil.

2. Interpretación: Intérprete(Intérprete de inglés - intérprete, intérprete) traduce y ejecuta el programa línea por línea.

En interpretaciones el programa fuente se almacena en la memoria de la computadora casi sin cambios. El programa intérprete decodifica las declaraciones del programa fuente una a la vez y asegura inmediatamente su ejecución con los datos disponibles. El programa interpretado ocupa poco espacio en la memoria de la computadora y es fácil de depurar y modificar. Pero la ejecución del programa es bastante lenta, ya que con cada ejecución se realiza de nuevo la interpretación de todos los operadores.

Los programas compilados se ejecutan más rápido, pero los interpretados son más fáciles de arreglar y cambiar.

Cada lenguaje específico está orientado a la compilación o a la interpretación, dependiendo del propósito para el cual fue creado. Por ejemplo, Pascal se suele utilizar para resolver problemas bastante complejos en los que la velocidad del programa es importante. Por tanto, este lenguaje suele implementarse mediante un compilador.

Por otro lado, BASIC fue creado como un lenguaje para programadores novatos, para quienes la ejecución línea por línea de un programa tiene innegables ventajas.

A veces hay un compilador y un intérprete para el mismo idioma. En este caso, puede utilizar un intérprete para desarrollar y probar el programa y luego compilar el programa depurado para mejorar su velocidad de ejecución.

Bases de datos relacionales

Una base de datos relacional consta de una o más tablas relacionadas, cuya estructura está formada por columnas y filas.

Se aceptan las siguientes notaciones en bases de datos relacionales:

Relación - tabla;

Campo: un conjunto de registros del mismo tipo para varios objetos (columna);

Tupla (registro): una fila de la tabla que contiene un conjunto de varios registros correspondientes a un objeto;

Un atributo es una entrada en una fila de un campo.

Una entidad es cualquier objeto distinguible sobre el cual se almacena información en una base de datos.

Campos clave

Cada relación de base de datos debe contener un campo (o un conjunto de varios campos) que identifique de forma única cada registro de relación. Estos campos le permiten vincular datos de varias relaciones y, en última instancia, formar una única base de datos. Estos campos se denominan campos clave.

Se distinguen los siguientes tipos de claves:

Clave potencial- un campo cuyos atributos garantizan la unicidad del registro (puede haber varios campos de este tipo).

clave primaria- una de las claves potenciales seleccionadas como principal (por regla general, tiene una longitud mínima de atributo).

Clave externa (secundaria)- uno o más campos de una relación que proporcionan un enlace a la clave primaria de otra relación.

Dependiendo del número de campos que forman la clave se distinguen los siguientes:

clave sencilla- consta de un único atributo que identifica de forma única el registro (número del libro de registro del estudiante).

Clave compuesta- consta de dos o más atributos, cuya combinación identifica de forma única el registro (serie y número del pasaporte de una persona).

Si una relación tiene un campo único que identifica de forma única cada registro de la relación, entonces se puede utilizar como clave principal, pero los valores de sus atributos deben ser diferentes para todos los registros. No se deben utilizar nombres o apellidos de personas como clave principal, ya que pueden estar repetidos y puede haber personas con el mismo nombre y apellido en la misma relación. Incluso si en este momento los apellidos de todas las personas registradas en la base de datos son diferentes, el campo de apellido no debe usarse como clave, ya que los registros en la relación pueden cambiar con el tiempo debido a cambios en la composición de las personas registradas en las bases de datos. .

Al elegir una clave principal, también debe tener en cuenta que los atributos del campo clave no pueden estar vacíos. Si un campo permite valores nulos, no debe usarse como clave principal.

Además, a la hora de elegir una clave primaria, debes tener en cuenta que sus valores no deben cambiar. Si cambia, entonces es necesario asegurarse de que la información sobre este cambio esté actualizada en todos los aspectos relacionados con este campo. El uso de una clave principal con un valor constante permite una sincronización más sencilla entre las relaciones en la base de datos.

A menudo, se elige como clave principal un campo creado artificialmente cuyos valores de atributos no tienen un significado real. Estos campos pueden ser Código o Número, estos campos contienen solo la designación numérica de la línea, y esta designación a menudo la establece la computadora mediante un contador. Estos códigos no están sujetos a cambios, a diferencia de los campos que contienen datos reales, porque Apellido, número de teléfono, dirección, etc. puede cambiar y se repetirá.

Si un campo no puede garantizar la unicidad de un registro, se utiliza una clave compuesta formada por dos o más campos. Un ejemplo de clave compuesta podrían ser los campos serie y número de pasaporte, por separado la serie y el número de pasaporte no pueden garantizar la unicidad del registro, porque Hay pasaportes con la misma serie, así como con el mismo número, pero es imposible que dos pasaportes tengan la misma serie y número al mismo tiempo.

Popular en la categoría: