Información en una base de datos relacional. Tipos de datos de MS Access. Tiendas de valor clave: beneficios

El concepto de relacional está asociado con los desarrollos de un famoso especialista estadounidense en el campo de los sistemas de bases de datos, empleado de IBM, el Dr. E. Codd (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6 , junio de 1970), quien utilizó por primera vez el término "modelo de datos relacionales".

Durante mucho tiempo, el enfoque relacional se consideró un aparato formal conveniente para el análisis de bases de datos, que no tenía perspectivas prácticas, ya que su implementación requería demasiados recursos de la máquina. Sólo con la llegada de las computadoras personales comenzaron a extenderse los sistemas relacionales y relacionados, sin dejar prácticamente espacio para otros modelos.

Estos modelos se caracterizan por la simplicidad de la estructura de datos, la representación tabular fácil de usar y la capacidad de utilizar el aparato formal de álgebra relacional y cálculo relacional para el procesamiento de datos.

El modelo relacional se centra en organizar datos en forma de tablas bidimensionales. Cada tabla relacional es una matriz bidimensional y tiene las siguientes propiedades:

• - cada elemento de la tabla es un elemento de datos; no hay grupos repetidos;
• - todas las columnas de la tabla son homogéneas, es decir todos los elementos de una columna tienen el mismo tipo (numérico, carácter, etc.) y longitud;
• - cada columna tiene un nombre único;
• - no hay filas idénticas en la tabla;
• - el orden de filas y columnas puede ser arbitrario. Este tipo de tabla se llama relación.

Una base de datos construida utilizando relaciones se llama base de datos relacional.

Las relaciones se presentan en forma de tablas, cuyas filas corresponden a tuplas o registros, y las columnas corresponden a atributos, dominios y campos de relación.

Un campo cuyo valor identifica de forma única el registro correspondiente se denomina clave simple (campo clave). Si los registros se identifican de forma única mediante los valores de varios campos, entonces dicha tabla de base de datos tiene una clave compuesta.

Para vincular dos tablas relacionales, debe incluir la clave de la primera tabla como parte de la clave de la segunda tabla (las claves pueden coincidir); de lo contrario, deberá ingresar una clave externa en la estructura de la primera tabla: la clave de la segunda tabla.

Habiendo propuesto un modelo de datos relacional, E.F. Codd también creó una herramienta para trabajar cómodamente con relaciones: el álgebra relacional. Cada operación de esta álgebra utiliza una o más tablas (relaciones) como operandos y produce una nueva tabla como resultado, es decir le permite “cortar” o “pegar” tablas.

En qué se diferencian fundamentalmente los modelos relacionales de los de red y jerárquicos se puede decir de la siguiente manera: los modelos de datos jerárquicos y de red están conectados por estructura, y los relacionales están conectados por significado.

El diseño de bases de datos se ha considerado tradicionalmente una tarea muy difícil. La tecnología relacional facilita mucho esta tarea.

Al separar las capas lógica y física de un sistema, se simplifica el proceso de mapear la "capa del mundo real" en una estructura que el sistema pueda soportar directamente. Debido a que la estructura relacional en sí es conceptualmente simple, permite la implementación de bases de datos pequeñas y/o simples (y por lo tanto fáciles de crear), como bases de datos personales, que nunca se habrían considerado posibles en sistemas más antiguos y complejos.

La teoría y la disciplina de la normalización pueden ayudar al mostrar lo que sucede cuando las relaciones no están estructuradas de forma natural.

El modelo de datos relacionales es especialmente conveniente para su uso en bases de datos de arquitectura distribuida: le permite acceder a cualquier elemento de información almacenado en los nodos de la red informática. Es necesario prestar especial atención al aspecto de alto nivel del enfoque relacional, que consiste en el procesamiento de múltiples registros. Gracias a esto, aumenta significativamente el potencial del enfoque relacional, lo que no se puede lograr procesando un registro a la vez y, sobre todo, se trata de optimización.

Este modelo le permite determinar:

• · operaciones para almacenar y recuperar datos;
• · restricciones relacionadas con garantizar la integridad de los datos.

Para aumentar la eficiencia operativa, muchos DBMS relacionales adoptan restricciones que corresponden a un modelo relacional estricto.

Muchos DBMS relacionales presentan archivos de bases de datos al usuario en formato tabular, con registros como filas y sus campos como columnas. En forma tabular, la información se percibe mucho más fácilmente. Sin embargo, en una base de datos a nivel físico, los datos generalmente se almacenan en archivos que contienen secuencias de registros.

La principal ventaja del DBMS relacional es la capacidad de vincular archivos de bases de datos en función de determinadas relaciones.

Desde un punto de vista estructural, los modelos relacionales son más simples y homogéneos que los modelos jerárquicos y de red. En el modelo relacional, cada objeto de dominio tiene una o más relaciones. Si es necesario definir explícitamente la relación entre objetos, se expresa en forma de relación en la que los identificadores de objetos interrelacionados están presentes como atributos. En el modelo relacional, los objetos del área temática y las conexiones entre ellos están representados por las mismas estructuras de información, lo que simplifica significativamente el modelo en sí.

Un DBMS se considera relacional si se cumplen las dos condiciones siguientes, propuestas por E. Codd:

• · soporta estructura de datos relacionales;
• · implementa al menos las operaciones de selección, proyección y conexión de relaciones.

Posteriormente, se crearon una serie de DBMS relacionales que cumplen más o menos con esta definición. Muchos DBMS son extensiones importantes del modelo relacional, mientras que otros son mixtos y admiten múltiples modelos de datos.

Hoy en día, las bases de datos relacionales siguen siendo las más comunes por su sencillez y claridad, tanto durante el proceso de creación como a nivel de usuario.

La principal ventaja de las bases de datos relacionales es su compatibilidad con el lenguaje de consulta más popular, SQL.

Con una sola consulta en este idioma, puede unir varias tablas en una tabla temporal y recortar de ella las filas y columnas necesarias (selección y proyección). Dado que la estructura tabular de una base de datos relacional es intuitiva para los usuarios, el lenguaje SQL es simple y fácil de aprender. El modelo relacional tiene una sólida base teórica sobre la cual se basó la evolución e implementación de las bases de datos relacionales. Aprovechando la ola de popularidad generada por el éxito del modelo relacional, SQL se convirtió en el lenguaje principal para las bases de datos relacionales.

Pero también se han identificado las desventajas del modelo de base de datos considerado:

• - dado que todos los campos de una tabla deben contener un número constante de campos de tipos predefinidos, es necesario crear tablas adicionales que tengan en cuenta las características individuales de los elementos que utilizan claves externas. Este enfoque hace que sea muy difícil crear relaciones complejas en la base de datos;
• - alta complejidad de manipular información y cambiar conexiones.

Base de datos relacional: conceptos básicos

A menudo, cuando se habla de una base de datos, simplemente se refieren a algún almacenamiento de datos automatizado. Esta idea no es del todo correcta. A continuación se mostrará por qué esto es así.

De hecho, en el sentido estricto de la palabra, una base de datos es un determinado conjunto de datos necesarios para el trabajo (datos actualizados). Sin embargo, los datos son una abstracción; nadie ha visto nunca “solo datos”; no surgen ni existen por sí solos. Los datos son un reflejo de los objetos del mundo real. Supongamos, por ejemplo, que desee almacenar información sobre las piezas recibidas en el almacén. ¿Cómo se mostrará un objeto del mundo real (una pieza) en la base de datos? Para responder a esta pregunta, necesita saber qué características o aspectos de la pieza serán relevantes y necesarios para el trabajo. Estos pueden incluir el nombre de la pieza, su peso, dimensiones, color, fecha de fabricación, material del que está hecha, etc. En la terminología tradicional, los objetos del mundo real, cuya información se almacena en una base de datos, se denominan entidades (no dejes que esta palabra asuste al lector, es un término generalmente aceptado), y sus características reales se denominan atributos.

Cada atributo de un objeto específico es un valor de atributo. Por lo tanto, la parte del motor tiene un valor de atributo de peso de 50, lo que refleja el hecho de que este motor pesa 50 kilogramos.

Sería un error pensar que en la base de datos sólo se reflejan objetos físicos. Es capaz de absorber información sobre abstracciones, procesos, fenómenos, es decir, sobre todo lo que una persona encuentra en sus actividades. Por ejemplo, en una base de datos se puede almacenar información sobre pedidos para el suministro de piezas a un almacén (aunque no es un objeto físico, sino un proceso). Los atributos de la entidad "pedido" serán el nombre de la pieza que se suministra, el número de piezas, el nombre del proveedor, tiempo de entrega, etc.

Los objetos del mundo real están conectados entre sí por muchas dependencias complejas que deben tenerse en cuenta en las actividades de información. Por ejemplo, los fabricantes suministran las piezas al almacén. Por lo tanto, es necesario incluir el atributo “nombre del fabricante” entre los atributos de la pieza. Sin embargo, esto no es suficiente, ya que puede ser necesaria información adicional sobre el fabricante de una determinada pieza: su dirección, número de teléfono, etc. Esto significa que la base de datos debe contener no sólo información sobre piezas y órdenes de compra, sino también información sobre sus fabricantes. Además, la base de datos debe reflejar las relaciones entre piezas y fabricantes (cada pieza es producida por un fabricante específico) y entre pedidos y piezas (cada pedido se emite para una pieza específica). Tenga en cuenta que sólo es necesario almacenar en la base de datos las conexiones relevantes y significativas.

Por tanto, en el sentido amplio de la palabra, una base de datos es un conjunto de descripciones de objetos del mundo real y conexiones entre ellos que son relevantes para un área de aplicación específica. A continuación partiremos de esta definición, aclarándola a medida que avancemos.

Modelo de datos relacionales

Ahora tenemos una idea de lo que se almacena en la base de datos. Ahora necesitamos comprender cómo las entidades, los atributos y las relaciones se asignan a las estructuras de datos. Esto está determinado por el modelo de datos.

Tradicionalmente, todos los DBMS se clasifican según el modelo de datos que los sustenta. Se acostumbra distinguir entre modelos de datos jerárquicos, de red y relacionales. En ocasiones se complementan con un modelo de datos basado en listas invertidas. En consecuencia, se habla de DBMS jerárquico, de red, relacional o DBMS basado en listas invertidas.

En términos de prevalencia y popularidad, los DBMS relacionales actuales no tienen rival. Se han convertido en un estándar industrial de facto y, por lo tanto, el usuario doméstico tendrá que lidiar con un DBMS relacional en su práctica. Veamos brevemente el modelo de datos relacionales sin profundizar en sus detalles.

Fue desarrollado por Codd en 1969-70 sobre la base de la teoría matemática de las relaciones y se basa en un sistema de conceptos, los más importantes de los cuales son tabla, relación, fila, columna, clave primaria y clave externa.

Una base de datos relacional es aquella en la que todos los datos se presentan al usuario en forma de tablas rectangulares de valores de datos y todas las operaciones en la base de datos se reducen a manipulaciones con tablas. Una tabla consta de filas y columnas y tiene un nombre único dentro de la base de datos. La tabla refleja el tipo de objeto (entidad) del mundo real y cada una de sus filas representa un objeto específico. Por lo tanto, la tabla de piezas contiene información sobre todas las piezas almacenadas en el almacén y sus filas son conjuntos de valores de atributos para piezas específicas. Cada columna de la tabla es una colección de valores para un atributo específico de un objeto. Entonces, la columna Material representa un conjunto de valores "Acero", "Estaño", "Zinc", "Níquel", etc. La columna Cantidad contiene números enteros no negativos. Los valores de la columna Peso son números reales iguales al peso de la pieza en kilogramos.

Estos valores no surgen de la nada. Se seleccionan del conjunto de todos los valores posibles para un atributo de objeto, que se denomina dominio. Por lo tanto, los valores en la columna de materiales se seleccionan de un conjunto de nombres de todos los materiales posibles: plástico, madera, metales, etc. Por lo tanto, es fundamentalmente imposible que aparezca en la columna Material un valor que no exista en el dominio correspondiente, por ejemplo, “agua” o “arena”.

Cada columna tiene un nombre, que normalmente se escribe en la parte superior de la tabla ( Arroz. 1). Debe ser único dentro de la tabla, pero diferentes tablas pueden tener columnas con el mismo nombre. Cualquier tabla debe tener al menos una columna; Las columnas están ordenadas en la tabla según el orden en que aparecieron sus nombres cuando se creó. A diferencia de las columnas, las filas no tienen nombres; su orden en la tabla no está definido y su número es lógicamente ilimitado.

Figura 1. Conceptos básicos de bases de datos.

Dado que las filas de la tabla no están ordenadas, es imposible seleccionar una fila por su posición; no hay "primero", "segundo" ni "último" entre ellas. Cualquier tabla tiene una o más columnas, cuyos valores identifican de forma única cada una de sus filas. Esta columna (o combinación de columnas) se denomina clave principal. En la tabla de piezas, la clave principal es la columna Número de pieza. En nuestro ejemplo, cada pieza del almacén tiene un único número, mediante el cual se recupera la información necesaria de la tabla de piezas. Por lo tanto, en esta tabla, la clave principal es la columna Número de pieza. No puede haber valores duplicados en esta columna; no debe haber filas en la tabla de piezas que tengan el mismo valor en la columna Número de pieza. Si una tabla satisface este requisito, se llama relación.

La relación de tablas es el elemento más importante del modelo de datos relacionales. Está respaldado por claves externas. Consideremos un ejemplo en el que una base de datos almacena información sobre empleados comunes (tabla de empleados) y gerentes (tabla de gerentes) en alguna organización ( Arroz. 2). La clave principal del encabezado de la tabla es la columna Número (por ejemplo, número de personal). La columna Apellido no puede servir como clave principal, ya que dos gerentes con el mismo apellido pueden trabajar en la misma organización. Cualquier empleado está subordinado a un único gerente, lo que debe reflejarse en la base de datos. La tabla Empleado contiene una columna Número de Gerente, y los valores en esta columna se seleccionan de la columna Número de la tabla Gerente (ver. Arroz. 2). La columna Número de gerente es una clave externa en la tabla Empleado.

Figura 2. Relación entre tablas de bases de datos.

Las tablas no se pueden almacenar ni procesar si no hay "datos sobre datos" en la base de datos, como identificadores de tablas, columnas, etc. Generalmente se les llama metadatos. Los metadatos también se presentan en forma tabular y se almacenan en un diccionario de datos.

Además de las tablas, la base de datos puede almacenar otros objetos, como visualizaciones, informes, vistas e incluso programas de aplicación que funcionan con la base de datos.

Para los usuarios de un sistema de información, no basta con que la base de datos refleje simplemente objetos del mundo real. Es importante que dicha reflexión sea inequívoca y coherente. En este caso, se dice que la base de datos satisface la condición de integridad.

Para garantizar la exactitud y la coherencia mutua de los datos, se imponen ciertas restricciones a la base de datos, que se denominan restricciones de integridad de los datos.

Hay varios tipos de restricciones de integridad. Se requiere, por ejemplo, que los valores de una columna de la tabla se seleccionen únicamente del dominio correspondiente. En la práctica, también se tienen en cuenta restricciones de integridad más complejas, por ejemplo, la integridad referencial. Su esencia es que una clave externa no puede ser un puntero a una fila inexistente en la tabla. Las restricciones de integridad se implementan utilizando medios especiales, que se discutirán en Segundo.Servidor de base de datos .

lenguaje SQL

Los datos en sí en formato informático no tienen ningún interés para el usuario si no hay medios para acceder a ellos. Se accede a los datos en forma de consultas a bases de datos que se formulan en un lenguaje de consulta estándar. Hoy en día, para la mayoría de los DBMS, este lenguaje es SQL.

El surgimiento y desarrollo de este lenguaje como medio para describir el acceso a bases de datos está asociado con la creación de la teoría de las bases de datos relacionales. El prototipo del lenguaje SQL surgió en 1970 como parte del proyecto de investigación System/R, cuyo trabajo se llevó a cabo en el laboratorio de IBM Santa Teresa. Hoy en día, SQL es la interfaz estándar con DBMS relacionales. Su popularidad es tan grande que los desarrolladores de DBMS no relacionales (por ejemplo, Adabas) suministran a sus sistemas una interfaz SQL.

El lenguaje SQL tiene un estándar oficial: ANSI/ISO. La mayoría de los desarrolladores de DBMS se adhieren a este estándar, pero a menudo lo amplían para implementar nuevas capacidades de procesamiento de datos. Nuevos mecanismos de gestión de datos que se describirán en Segundo.Servidor de base de datos , solo se puede utilizar mediante declaraciones SQL especiales, que generalmente no están incluidas en el estándar del lenguaje.

SQL no es un lenguaje de programación tradicional. En él no se escriben programas, sino consultas a la base de datos. Por eso SQL es un lenguaje declarativo. Esto significa que se puede utilizar para formular lo que se debe obtener, pero no puede indicar cómo se debe hacer. En particular, a diferencia de los lenguajes de programación procedimentales (C, Pascal, Ada), el lenguaje SQL no tiene operadores como if-then-else, for, while, etc.

No entraremos en detalles sobre la sintaxis del idioma. Lo abordaremos sólo en la medida necesaria para comprender ejemplos sencillos. Con su ayuda se ilustrarán los mecanismos de procesamiento de datos más interesantes.

Una consulta SQL consta de una o más declaraciones, una tras otra, separadas por un punto y coma. La Tabla 1 a continuación enumera los operadores más importantes que se incluyen en el estándar ANSI/ISO SQL.

Tabla 1. Operadores SQL básicos.

Las consultas SQL utilizan nombres que identifican de forma única los objetos de la base de datos. En particular, este es el nombre de la tabla (Detalle), el nombre de la columna (Título), así como los nombres de otros objetos en la base de datos que pertenecen a tipos adicionales (por ejemplo, nombres de procedimientos y reglas), que se discutirán en Segundo.Servidor de base de datos . Junto con los simples, también se utilizan nombres complejos; por ejemplo, un nombre de columna calificado determina el nombre de la columna y el nombre de la tabla a la que pertenece (Part.Weight). Para simplificar, en los ejemplos los nombres se escribirán en ruso, aunque en la práctica esto no se recomienda.

Cada columna de cualquier tabla almacena tipos específicos de datos. Hay tipos de datos básicos: cadenas de caracteres de longitud fija, números enteros y reales, y tipos de datos adicionales: cadenas de caracteres de longitud variable, unidades monetarias, fecha y hora, datos lógicos (dos valores: "VERDADERO" y "FALSO" ). En SQL, puede utilizar constantes numéricas, de cadena, de caracteres y de fecha y hora.

Veamos algunos ejemplos.

La consulta “determinar el número de piezas en stock para todo tipo de piezas” se implementa de la siguiente manera:

SELECCIONAR Nombre, Cantidad

DE Parte;

El resultado de la consulta será una tabla con dos columnas: Nombre y Cantidad, que se toman de la tabla de piezas original. Básicamente, esta consulta le permite obtener una proyección vertical de la tabla original (más estrictamente, un subconjunto vertical del conjunto de filas de la tabla). A partir de todas las filas de la tabla de piezas, se forman filas que incluyen valores tomados de dos columnas: Nombre y Cantidad.

La consulta "¿Qué piezas de acero hay en stock?" formulada en SQL tiene este aspecto:

DE parte

DONDE Material = "Acero";

El resultado de esta consulta también será una tabla que contiene solo aquellas filas de la tabla de origen que tienen el valor "Acero" en la columna Material. Esta consulta le permite obtener una proyección horizontal de la tabla de piezas (el asterisco en la instrucción SELECT significa seleccionar todas las columnas de la tabla).

La solicitud “para determinar el nombre y cantidad de piezas en stock que sean de plástico y pesen menos de cinco kilogramos” se redactará de la siguiente manera:

SELECCIONAR Nombre, Cantidad

DE parte

DONDE Material = "Plástico"

Y peso< 5;

El resultado de la consulta es una tabla con dos columnas: Nombre, Cantidad, que contiene el nombre y el número de piezas de plástico que pesan menos de 5 kg. En esencia, la operación de muestreo es la operación de formar primero una proyección horizontal (busque todas las filas de la tabla de piezas para las que Material = "Plástico" y Peso< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Una de las herramientas que proporciona acceso rápido a las tablas son los índices. Un índice es una estructura de base de datos que apunta a una fila específica de una tabla. Un índice de base de datos se utiliza de la misma manera que un índice de un libro. Contiene valores tomados de una o más columnas de una fila particular de la tabla y una referencia a esa fila. Los valores del índice están ordenados, lo que permite al DBMS buscar rápidamente en la tabla.

Supongamos que se formula una consulta a la base de datos de Warehouse:

SELECCIONAR Nombre Cantidad, Material

DE parte

DONDE Número = "T145-A8";

Si no hay índices para una tabla determinada, para ejecutar esta consulta el DBMS debe escanear toda la tabla de Partes, seleccionando secuencialmente filas de ella y verificando la condición de selección para cada una de ellas. Para tablas grandes, dicha consulta tardará mucho en completarse.

Si se creó previamente un índice en la columna Detalle del número de tabla, el tiempo de búsqueda en la tabla se reducirá al mínimo. El índice contendrá los valores de la columna Número y un enlace a la fila con este valor en la tabla Parte. Al ejecutar una consulta, el DBMS primero encontrará el valor "T145-A8" en el índice (y lo hará rápidamente, ya que el índice está ordenado y sus filas son pequeñas) y luego, utilizando el enlace en el índice, determinará el Ubicación física de la fila buscada.

Se crea un índice con la instrucción SQL CREATE INDEX. En este ejemplo, el operador

CREAR ÍNDICE ÚNICO Índice de piezas

ON Parte (Número);

creará un índice con el nombre "Índice de pieza" en la columna Número de la tabla Parte.

Para un usuario de DBMS, lo que le interesa no son las declaraciones SQL individuales, sino una determinada secuencia de ellas, diseñada como un todo y que tiene sentido desde su punto de vista. Cada una de estas secuencias de declaraciones SQL implementa una acción específica en la base de datos. Se lleva a cabo en varios pasos, en cada uno de los cuales se realizan determinadas operaciones en las tablas de la base de datos. Así, en el sistema bancario, la transferencia de una determinada cantidad de una cuenta de corto plazo a una cuenta de largo plazo se realiza en varias operaciones. Entre ellos se encuentran retirar una cantidad de una cuenta a corto plazo y acreditarla en una cuenta a largo plazo.

Si hay un fallo durante esta acción, por ejemplo, cuando se completa la primera operación pero no la segunda, entonces se perderá el dinero. Por lo tanto, cualquier acción en la base de datos debe realizarse por completo o no realizarse en absoluto. Esta acción se llama transacción.

El procesamiento de transacciones se basa en un registro, que se utiliza para revertir las transacciones y restaurar el estado de la base de datos. Se discutirán más detalles sobre las transacciones en Segundo.Procesamiento de transacciones .

Concluyendo nuestra discusión sobre el lenguaje SQL, enfaticemos una vez más que es un lenguaje de consulta. Es imposible escribir ningún programa de aplicación complejo que funcione con una base de datos. Para este propósito, los DBMS modernos utilizan el lenguaje de cuarta generación (lenguaje de cuarta generación - 4GL), que tiene tanto las capacidades básicas de los lenguajes procedimentales de tercera generación (3GL), como C, Pascal, Ada, como la capacidad de incrustar SQL. declaraciones en el texto del programa, así como controles de la interfaz de usuario (menús, formularios, entrada del usuario, etc.). Hoy en día, 4GL es uno de los estándares de facto para herramientas de desarrollo de aplicaciones de bases de datos.

Melnikova 620000 Rusia, región de Sverdlovsk, Ekaterimburgo.+7 953 039 559 1 info@sitio web

Base de datos relacional Es información relacionada presentada en forma de tablas bidimensionales. Imagine una libreta de direcciones. Contiene muchas líneas, cada una de las cuales corresponde a un individuo determinado. Para cada uno de ellos presenta algunos datos independientes, por ejemplo, nombre, número de teléfono, dirección. Imaginemos una libreta de direcciones como una tabla que contiene filas y columnas. Cada fila (también llamada registro) corresponde a un individuo específico, cada columna contiene los valores del tipo de datos correspondiente: nombre, número de teléfono y dirección representados en cada fila. La libreta de direcciones podría verse así:

Lo que hemos obtenido es la base de una base de datos relacional, definida al comienzo de nuestra discusión por una tabla de información bidimensional (filas y columnas). Sin embargo, una base de datos relacional rara vez consta de una sola tabla, que es demasiado pequeña en comparación con la base de datos. Al crear varias tablas con información relacionada, puede realizar operaciones más complejas y potentes con los datos. El poder de una base de datos reside más en las conexiones que se construyen entre piezas de información que en las piezas mismas.

Usemos el ejemplo de una libreta de direcciones para analizar una base de datos que realmente se puede utilizar en la vida empresarial. Supongamos que los individuos de la primera tabla son pacientes de un hospital. Se puede almacenar información adicional sobre ellos en otra tabla. Las columnas de la segunda tabla se pueden nombrar de la siguiente manera: Paciente, Médico, Aseguradora, Saldo.

Puede realizar muchas funciones potentes al extraer información de estas tablas según criterios específicos, especialmente si el criterio incluye información relacionada de diferentes tablas.

Digamos que el Dr. Halben quiere obtener los números de teléfono de todos sus pacientes. Para recuperar esta información, debe vincular la tabla de números de teléfono de los pacientes (libreta de direcciones) a la tabla que identifica a sus pacientes. En este sencillo ejemplo, puede realizar mentalmente esta operación y averiguar los números de teléfono de sus pacientes Grillet y Brock, pero en realidad estas tablas pueden ser más grandes y mucho más complejas.

Los programas de bases de datos relacionales se crearon para trabajar con conjuntos de datos grandes y complejos que son más comunes en la vida empresarial de la sociedad. Incluso si la base de datos de un hospital contiene decenas o miles de nombres (como probablemente sea el caso en la vida real), un único comando SQL proporcionará al Dr. Halben la información que necesita casi al instante.

El orden de las líneas es arbitrario.

Para garantizar la máxima flexibilidad al trabajar con datos, las filas de la tabla, por definición, no están ordenadas de ninguna manera. Este aspecto distingue una base de datos de una libreta de direcciones. Las entradas de la libreta de direcciones suelen estar ordenadas alfabéticamente. Una de las poderosas características que ofrecen los sistemas de bases de datos relacionales es que los usuarios pueden organizar la información como deseen.

Veamos la segunda tabla. La información que contiene a veces se ve convenientemente ordenada por nombre, a veces en orden ascendente o descendente de Balance y, a veces, agrupada por médico. La amplia gama de posibles órdenes de filas dificultaría que el usuario fuera flexible con los datos, por lo que se supone que las filas están desordenadas. Por eso no puedes decir simplemente: "Me interesa la quinta fila de la tabla". Independientemente del orden en que se incluyan los datos o cualquier otro criterio, esta quinta fila no existe por definición. Por lo tanto, se supone que las filas de la tabla están en orden aleatorio.

Identificación de fila (clave primaria)

Por esta y otras razones, es necesario tener una columna de tabla que identifique de forma única cada fila. Normalmente, esta columna contiene, por ejemplo, un número asignado a cada paciente. Por supuesto, podría usar el nombre del paciente para identificar las cadenas, pero podría ser que haya varios pacientes llamados Mary Smith. En un caso como este, no existe una manera fácil de diferenciarlos. Ésta es la razón por la que se suelen utilizar números. Esta columna única (o grupo de columnas) que se utiliza para identificar cada fila y garantizar que todas las filas sean distinguibles se denomina clave principal de la tabla.

Clave primaria de la tabla es un concepto vital de la estructura de la base de datos. Es el corazón del sistema de datos: para encontrar una fila específica en una tabla, especifique el valor de su clave principal. Además, garantiza la integridad de los datos. Si la clave principal se utiliza y mantiene correctamente, puede estar seguro de que ninguna fila de la tabla estará vacía y que cada fila será distinta del resto.

Las columnas están nombradas y numeradas.

A diferencia de las filas, las columnas de la tabla (también llamadas campos) están ordenadas y nombradas. Por lo tanto, en nuestra tabla de la libreta de direcciones, podemos referirnos a la columna "Dirección" como "columna número tres". La tabla debe tener un nombre que sea diferente de otros nombres para evitar confusiones. Es mejor tener nombres que definan el contenido del campo. En este libro, usaremos una abreviatura para nombrar columnas en tablas simples, por ejemplo: cname para. nombre del cliente. (nombre del cliente), odate - para la fecha de recepción (fecha del pedido). Supongamos también que la tabla contiene una única columna numérica utilizada como clave principal.

Las tablas 1.1, 1.2, 1.3 forman una base de datos relacional que es lo suficientemente pequeña como para tener sentido, pero lo suficientemente compleja como para ilustrar conceptos importantes y las implicaciones prácticas del uso de SQL.

Notará que la primera columna de cada tabla contiene números que no se repiten de una fila a otra dentro de la tabla. Como probablemente habrás adivinado, estas son las claves principales de la tabla. Algunos de estos números también aparecen en columnas de otras tablas (no hay nada de malo en eso), lo que indica una relación entre filas que usan un valor de clave principal particular y una fila que usa ese valor directamente en la clave principal.

Por ejemplo, el campo snum en la tabla Clientes determina qué vendedores atienden a un cliente en particular. El número de campo snum establece un vínculo a la tabla Vendedores, que proporciona información sobre esos vendedores. Evidentemente, el vendedor que sirve a este comprador existe, es decir. El valor del campo snum en la tabla Clientes también está presente en la tabla Vendedores. En este caso decimos que el sistema se encuentra en un estado de integridad referencial.

Las tablas en sí están diseñadas para describir situaciones reales de la vida empresarial en las que se puede utilizar SQL para realizar negocios que involucren a proveedores, sus clientes y pedidos. Registremos el estado de estas tres tablas en cualquier momento y aclaremos el propósito de cada uno de los campos de la tabla.

A continuación se muestra una explicación de las columnas de la tabla 1.1:

La tabla 1.2 contiene las siguientes columnas:

Y por último, las columnas del cuadro 1.3.

• 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 que, basándose en cosas como algoritmos de estimación de costos, se adapta mejor a 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 predominio 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 aumentar. 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 relacionales 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 de coherencia 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:

1. 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.
2. 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.
3. El almacén de datos es económico y se integra fácilmente con los servicios web de su proveedor.
4. 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.

Agregar etiquetas

Un modelo de datos es un conjunto de estructuras de datos y operaciones para su procesamiento. Utilizando un modelo de datos, puedes representar visualmente la estructura de los objetos y las relaciones establecidas entre ellos. La terminología del modelo de datos se caracteriza por los conceptos de "elemento de datos" y "reglas vinculantes". Un elemento de datos describe cualquier conjunto de datos y las reglas de asociación definen algoritmos para interconectar elementos de datos. Hasta la fecha se han desarrollado muchos modelos de datos diferentes, pero en la práctica se utilizan tres principales. Existen modelos de datos jerárquicos, de red y relacionales. En consecuencia, se habla de DBMS jerárquicos, de red y relacionales.

O Modelo de datos jerárquico. Los datos organizados jerárquicamente son muy comunes en la vida cotidiana. Por ejemplo, la estructura de una institución de educación superior es una estructura jerárquica de varios niveles. Una base de datos jerárquica (árbol) consta de un conjunto ordenado de elementos. En este modelo, los elementos iniciales dan lugar a otros elementos, y estos elementos a su vez dan lugar a elementos adicionales. Cada elemento hijo tiene solo un elemento padre.

Las estructuras organizativas, listas de materiales, índices de libros, planes de proyectos y muchos otros conjuntos de datos se pueden presentar en forma jerárquica. La integridad de los vínculos entre ascendientes y descendientes se mantiene automáticamente. Regla básica: ningún niño puede existir sin su padre.

La principal desventaja de este modelo es la necesidad de utilizar la jerarquía que fue la base de la base de datos durante el diseño. La necesidad de una reorganización constante de los datos (y, a menudo, la imposibilidad de esta reorganización) llevó a la creación de un modelo más general: un modelo de red.

O Modelo de datos de red. El enfoque de red para la organización de datos es una extensión del enfoque jerárquico. Este modelo se diferencia del jerárquico en que cada elemento generado puede tener más de un elemento generador. ■

Debido a que una base de datos de red puede representar directamente todo tipo de relaciones inherentes a los datos de la organización correspondiente, estos datos se pueden navegar, explorar y consultar de varias maneras, es decir, el modelo de red no está limitado por una sola jerarquía. Sin embargo, para realizar una solicitud a una base de datos en red, es necesario profundizar en su estructura (tener a mano el esquema de esta base de datos) y desarrollar un mecanismo para navegar por la base de datos, lo cual es un inconveniente importante de este modelo de base de datos. .

O Modelo de datos relacionales. La idea principal del modelo de datos relacionales es representar cualquier conjunto de datos como una tabla bidimensional. En su forma más simple, un modelo relacional describe una única tabla bidimensional, pero más a menudo el modelo describe la estructura y las relaciones entre varias tablas diferentes.

Modelo de datos relacionales

Entonces, el propósito del sistema de información es procesar datos acerca de objetos mundo real, teniendo en cuenta conexiones entre objetos. En la teoría de bases de datos, los datos a menudo se denominan atributos, y objetos - entidades. Objeto, atributo y conexión son conceptos fundamentales de I.S.

Objeto(o esencia) es algo que existe y distinguible, es decir, un objeto puede denominarse “algo” para el cual existe un nombre y una forma de distinguir un objeto similar de otro. Por ejemplo, cada escuela es un objeto. Los objetos también son una persona, una clase en la escuela, una empresa, una aleación, un compuesto químico, etc. Los objetos pueden ser no solo objetos materiales, sino también conceptos más abstractos que reflejan el mundo real. Por ejemplo, eventos, regiones, obras de arte; libros (no como productos impresos, sino como obras), representaciones teatrales, películas; normas jurídicas, teorías filosóficas, etc.

Atributo(o dado)- este es un determinado indicador que caracteriza un determinado objeto y toma un determinado valor numérico, de texto u otro valor para una instancia específica del objeto. El sistema de información opera con conjuntos de objetos diseñados en relación con un área temática determinada, utilizando valores de atributos(datos) de ciertos objetos. Por ejemplo, tomemos las clases de una escuela como un conjunto de objetos. El número de alumnos de una clase es un dato que toma un valor numérico (una clase tiene 28, otra tiene 32). El nombre de la clase es un nombre dado que toma un valor de texto (uno tiene 10A, otro tiene 9B, etc.).

El desarrollo de las bases de datos relacionales se inició a finales de los años 60, cuando aparecieron los primeros trabajos que discutían; la posibilidad de utilizar formas familiares y naturales de presentar datos (los llamados modelos datalógicos tabulares) al diseñar bases de datos.

Se considera que el fundador de la teoría de las bases de datos relacionales es un empleado de IBM, el Dr. E. Codd, que publicó un artículo el 6 de junio de 1970. Un modelo relacional de datos para grandes bancos de datos compartidos(Modelo de datos relacionales para grandes bancos de datos colectivos). Este artículo fue el primero en utilizar el término "modelo de datos relacionales". La teoría de las bases de datos relacionales, desarrollada en los años 70 en Estados Unidos por el Dr. E. Codd, tiene una poderosa base matemática que describe las reglas para organizar los datos de manera efectiva. El marco teórico desarrollado por E. Codd se convirtió en la base para el desarrollo de la teoría del diseño de bases de datos.

E. Codd, matemático de formación, propuso utilizar el aparato de la teoría de conjuntos (unión, intersección, diferencia, producto cartesiano) para el procesamiento de datos. Demostró que cualquier conjunto de datos se puede representar en forma de tablas bidimensionales de un tipo especial, conocido en matemáticas como "relaciones".

Relacional Se considera que una base de datos es aquella en la que todos los datos se presentan al usuario en forma de tablas rectangulares de valores de datos, y todas las operaciones en la base de datos se reducen a manipulaciones con las tablas.

La mesa consta de columnas (campos) Y líneas (registros); tiene un nombre que es único dentro de la base de datos. Mesa refleja tipo de objeto mundo real (entidad), y cada una de ella cadena es un objeto específico. Cada columna de la tabla es una colección de valores para un atributo específico de un objeto. Los valores se seleccionan del conjunto de todos los valores posibles para un atributo de objeto, que se llama dominio.

En su forma más general, un dominio se define especificando algún tipo de datos base al que pertenecen los elementos del dominio y una expresión booleana arbitraria aplicada a los elementos de datos. Si evalúa una condición booleana en un elemento de datos y el resultado es verdadero, entonces ese elemento pertenece al dominio. En el caso más simple, un dominio se define como un conjunto potencial válido de valores del mismo tipo. Por ejemplo, la recopilación de las fechas de nacimiento de todos los empleados constituye el "dominio de fechas de nacimiento" y los nombres de todos los empleados constituyen el "dominio de nombres de empleados". El dominio de fecha de nacimiento debe tener un tipo de datos de un momento determinado y el dominio de nombre de empleado debe tener un tipo de datos de caracteres.

Si dos valores provienen del mismo dominio, entonces se puede hacer una comparación entre los dos valores. Por ejemplo, si se toman dos valores del dominio de fechas de nacimiento, puede compararlos y determinar qué empleado es mayor. Si los valores se toman de diferentes dominios, entonces no se permite su comparación, ya que, con toda probabilidad, no tiene sentido. Por ejemplo, no se obtendrá nada definitivo al comparar el nombre de un empleado y su fecha de nacimiento.

Cada columna (campo) tiene un nombre, que normalmente se escribe en la parte superior de la tabla. Al diseñar tablas dentro de un DBMS específico, es posible seleccionar para cada campo su tipo, es decir, definir un conjunto de reglas para su visualización, así como determinar las operaciones que se pueden realizar sobre los datos almacenados en este campo. Los conjuntos de tipos pueden variar entre diferentes DBMS.

El nombre del campo debe ser único en la tabla, pero diferentes tablas pueden tener campos con el mismo nombre. Cualquier tabla debe tener al menos un campo; Los campos se ubican en la tabla de acuerdo con el orden en que aparecieron sus nombres cuando se creó. A diferencia de los campos, las cadenas no tienen nombres; su orden en la tabla no está definido y su número es lógicamente ilimitado.

Dado que las filas de la tabla no están ordenadas, es imposible seleccionar una fila por su posición; no hay "primero", "segundo" o "último" entre ellas. Cualquier tabla tiene una o más columnas, cuyos valores identifican de forma única cada una de sus filas. Esta columna (o combinación de columnas) se llama clave primaria. A menudo se introduce un campo artificial para los registros numéricos de una tabla. Un campo de este tipo, por ejemplo, podría ser su campo ordinal, que puede garantizar la unicidad de cada registro de la tabla. La clave debe tener las siguientes propiedades.

Unicidad. En un momento dado, no hay dos tuplas de relaciones diferentes que tengan el mismo valor para la combinación de atributos incluidos en la clave. Es decir, no puede haber dos filas en la tabla que tengan el mismo número de identificación o número de pasaporte.

Minimalismo. Ninguno de los atributos incluidos en la clave se puede excluir de la clave sin violar la unicidad. Esto significa que no debes crear una clave que incluya tanto el número de pasaporte como el número de identificación. Basta utilizar cualquiera de estos atributos para identificar de forma única una tupla. Tampoco debe incluir un atributo que no sea único en la clave, es decir, está prohibido utilizar una combinación de un número de identificación y el nombre de un empleado como clave. Al excluir el nombre del empleado de la clave, cada fila aún puede identificarse de forma única.

Cada relación tiene al menos una clave posible, ya que la totalidad de todos sus atributos satisface la condición de unicidad; esto se desprende de la definición misma de la relación.

Una de las claves posibles se selecciona aleatoriamente en como clave principal. El resto de claves posibles, si las hubiera, se toman como claves alternativas. Por ejemplo, si selecciona un número de identificación como clave principal, el número de pasaporte será la clave alternativa.

La relación de tablas es el elemento más importante del modelo de datos relacionales. es compatible claves foráneas.

Al describir un modelo de base de datos relacional, a menudo se utilizan diferentes términos para el mismo concepto, dependiendo del nivel de descripción (teoría o práctica) y del sistema (Access, SQL Server, dBase). en la mesa 2.3 proporciona un resumen de los términos utilizados.

Tabla 2.3. Terminología de bases de datos

Teoría de bases de datos____________ Bases de datos relacionales_________ SQL Server __________

Tabla de relaciones

Fila de registro de tupla

Campo de atributo_______________Columna

Bases de datos relacionales

Base de datos relacional Es un conjunto de relaciones que contienen toda la información que debe almacenarse en la base de datos. Es decir, la base de datos representa un conjunto de tablas necesarias para almacenar todos los datos. Las tablas de una base de datos relacional están relacionadas lógicamente entre sí. Los requisitos para diseñar una base de datos relacional en general se pueden reducir a varias reglas.

A Cada tabla tiene un nombre único en la base de datos y consta de filas del mismo tipo.

O Cada tabla consta de un número fijo de columnas y valores. No se puede almacenar más de un valor en una columna de una sola fila. Por ejemplo, si hay una tabla con información sobre el autor, fecha de publicación, circulación, etc., entonces la columna con el nombre del autor no puede almacenar más de un apellido. Si el libro está escrito por dos o más autores, tendrás que utilizar tablas adicionales.

O En ningún momento habrá dos filas en la tabla que se dupliquen entre sí. Las filas deben diferir en al menos un valor para poder identificar de forma única cualquier fila de la tabla.

О A cada columna se le asigna un nombre único dentro de la tabla; Se le establece un tipo de datos específico para que en esta columna se coloquen valores homogéneos (fechas, apellidos, números de teléfono, cantidades monetarias, etc.).

O El contenido informativo completo de una base de datos se representa como valores explícitos de los datos mismos, y este es el único método de representación. Por ejemplo, las relaciones entre tablas se basan en los datos almacenados en las columnas correspondientes y no en ningún puntero que defina artificialmente las relaciones.

О Al procesar datos, puede acceder libremente a cualquier fila o columna de la tabla. Los valores almacenados en la tabla no imponen ninguna restricción en el orden en que se accede a los datos. Descripción de las columnas,