DBMS - Guía rápida

Database es una colección de datos y datos relacionados es una colección de hechos y cifras que se pueden procesar para producir información.

La mayoría de los datos representan hechos registrables. Los datos ayudan a producir información, que se basa en hechos. Por ejemplo, si tenemos datos sobre las calificaciones obtenidas por todos los estudiantes, podemos concluir sobre los primeros y las calificaciones promedio.

UN database management system almacena datos de tal manera que sea más fácil recuperar, manipular y producir información.

Caracteristicas

Tradicionalmente, los datos se organizaban en formatos de archivo. El DBMS era un concepto nuevo entonces, y toda la investigación se hizo para superar las deficiencias en el estilo tradicional de gestión de datos. Un DBMS moderno tiene las siguientes características:

Real-world entity- Un DBMS moderno es más realista y utiliza entidades del mundo real para diseñar su arquitectura. También usa el comportamiento y los atributos. Por ejemplo, una base de datos de una escuela puede usar a los estudiantes como una entidad y su edad como un atributo.
Relation-based tables- DBMS permite que las entidades y las relaciones entre ellas formen tablas. Un usuario puede comprender la arquitectura de una base de datos con solo mirar los nombres de las tablas.
Isolation of data and application- Un sistema de base de datos es completamente diferente a sus datos. Una base de datos es una entidad activa, mientras que se dice que los datos son pasivos, en los que la base de datos funciona y se organiza. DBMS también almacena metadatos, que son datos sobre datos, para facilitar su propio proceso.
Less redundancy- DBMS sigue las reglas de normalización, que divide una relación cuando cualquiera de sus atributos tiene redundancia en valores. La normalización es un proceso científico y matemáticamente rico que reduce la redundancia de datos.
Consistency- La coherencia es un estado en el que todas las relaciones de una base de datos se mantienen coherentes. Existen métodos y técnicas que pueden detectar el intento de dejar la base de datos en un estado inconsistente. Un DBMS puede proporcionar una mayor coherencia en comparación con las formas anteriores de aplicaciones de almacenamiento de datos como los sistemas de procesamiento de archivos.
Query Language- DBMS está equipado con lenguaje de consulta, lo que lo hace más eficiente para recuperar y manipular datos. Un usuario puede aplicar tantas opciones de filtrado como sea necesario para recuperar un conjunto de datos. Tradicionalmente no era posible donde se usaba el sistema de procesamiento de archivos.
ACID Properties - DBMS sigue los conceptos de Atomicidad Ccoherencia Isolación, y Durabilidad (normalmente abreviado como ACID). Estos conceptos se aplican a las transacciones, que manipulan datos en una base de datos. Las propiedades ACID ayudan a que la base de datos se mantenga saludable en entornos multitransacciones y en caso de falla.
Multiuser and Concurrent Access- DBMS admite entornos multiusuario y les permite acceder y manipular datos en paralelo. Aunque existen restricciones en las transacciones cuando los usuarios intentan manejar el mismo elemento de datos, los usuarios siempre las desconocen.
Multiple views- DBMS ofrece múltiples vistas para diferentes usuarios. Un usuario que está en el departamento de ventas tendrá una vista de la base de datos diferente a la de una persona que trabaja en el departamento de producción. Esta característica permite a los usuarios tener una vista concentrada de la base de datos de acuerdo con sus requisitos.
Security- Funciones como múltiples vistas ofrecen seguridad hasta cierto punto cuando los usuarios no pueden acceder a los datos de otros usuarios y departamentos. DBMS ofrece métodos para imponer restricciones al ingresar datos en la base de datos y recuperarlos en una etapa posterior. DBMS ofrece muchos niveles diferentes de características de seguridad, lo que permite que varios usuarios tengan diferentes vistas con diferentes características. Por ejemplo, un usuario del departamento de ventas no puede ver los datos que pertenecen al departamento de compras. Además, también se puede gestionar la cantidad de datos del departamento de ventas que se deben mostrar al usuario. Dado que un DBMS no se guarda en el disco como los sistemas de archivos tradicionales, es muy difícil para los malhechores descifrar el código.

Usuarios

Un DBMS típico tiene usuarios con diferentes derechos y permisos que lo utilizan para diferentes propósitos. Algunos usuarios recuperan datos y otros los respaldan. Los usuarios de un DBMS pueden clasificarse ampliamente de la siguiente manera:

Administrators- Los administradores mantienen el DBMS y son responsables de administrar la base de datos. Ellos son responsables de velar por su uso y por quién debe ser utilizado. Crean perfiles de acceso para los usuarios y aplican limitaciones para mantener el aislamiento y forzar la seguridad. Los administradores también se ocupan de los recursos del DBMS, como la licencia del sistema, las herramientas necesarias y otro mantenimiento relacionado con el software y el hardware.
Designers- Los diseñadores son el grupo de personas que realmente trabajan en la parte de diseño de la base de datos. Vigilan de cerca qué datos deben conservarse y en qué formato. Identifican y diseñan todo el conjunto de entidades, relaciones, restricciones y vistas.
End Users- Los usuarios finales son aquellos que realmente obtienen los beneficios de tener un DBMS. Los usuarios finales pueden variar desde simples espectadores que prestan atención a los registros o tasas de mercado hasta usuarios sofisticados como analistas comerciales.

El diseño de un DBMS depende de su arquitectura. Puede ser centralizado, descentralizado o jerárquico. La arquitectura de un DBMS puede verse como de un solo nivel o de varios niveles. Una arquitectura de n niveles divide todo el sistema en elementos relacionados pero independientesn módulos, que se pueden modificar, alterar, cambiar o reemplazar de forma independiente.

En la arquitectura de 1 nivel, el DBMS es la única entidad donde el usuario se sienta directamente en el DBMS y lo usa. Cualquier cambio realizado aquí se realizará directamente en el propio DBMS. No proporciona herramientas útiles para los usuarios finales. Los diseñadores y programadores de bases de datos normalmente prefieren utilizar una arquitectura de un solo nivel.

Si la arquitectura del DBMS es de 2 niveles, entonces debe tener una aplicación a través de la cual se pueda acceder al DBMS. Los programadores utilizan una arquitectura de 2 niveles donde acceden al DBMS por medio de una aplicación. Aquí, el nivel de aplicación es completamente independiente de la base de datos en términos de operación, diseño y programación.

Arquitectura de 3 niveles

Una arquitectura de 3 niveles separa sus niveles entre sí según la complejidad de los usuarios y cómo usan los datos presentes en la base de datos. Es la arquitectura más utilizada para diseñar un DBMS.

Database (Data) Tier- En este nivel, la base de datos reside junto con sus lenguajes de procesamiento de consultas. También tenemos las relaciones que definen los datos y sus restricciones en este nivel.
Application (Middle) Tier- En este nivel residen el servidor de aplicaciones y los programas que acceden a la base de datos. Para un usuario, este nivel de aplicación presenta una vista abstracta de la base de datos. Los usuarios finales desconocen la existencia de la base de datos más allá de la aplicación. En el otro extremo, el nivel de la base de datos no tiene conocimiento de ningún otro usuario más allá del nivel de la aplicación. Por lo tanto, la capa de aplicación se encuentra en el medio y actúa como mediador entre el usuario final y la base de datos.
User (Presentation) Tier- Los usuarios finales operan en este nivel y no saben nada sobre la existencia de la base de datos más allá de este nivel. En esta capa, la aplicación puede proporcionar múltiples vistas de la base de datos. Todas las vistas son generadas por aplicaciones que residen en el nivel de aplicación.

La arquitectura de la base de datos de varios niveles es altamente modificable, ya que casi todos sus componentes son independientes y se pueden cambiar de forma independiente.

Los modelos de datos definen cómo se modela la estructura lógica de una base de datos. Los modelos de datos son entidades fundamentales para introducir la abstracción en un DBMS. Los modelos de datos definen cómo se conectan los datos entre sí y cómo se procesan y almacenan dentro del sistema.

El primer modelo de datos podría ser modelos de datos planos, donde todos los datos utilizados deben mantenerse en el mismo plano. Los modelos de datos anteriores no eran tan científicos, por lo que eran propensos a introducir muchas anomalías de duplicación y actualización.

Modelo entidad-relación

El modelo Entidad-Relación (ER) se basa en la noción de entidades del mundo real y las relaciones entre ellas. Al formular escenarios del mundo real en el modelo de base de datos, el modelo ER crea un conjunto de entidades, un conjunto de relaciones, atributos generales y restricciones.

El modelo ER se utiliza mejor para el diseño conceptual de una base de datos.

El modelo ER se basa en:

Entitiesy sus atributos.
Relationships entre entidades.

Estos conceptos se explican a continuación.

Entity - Una entidad en un modelo ER es una entidad del mundo real que tiene propiedades llamadas attributes. Cadaattribute se define por su conjunto de valores llamado domain. Por ejemplo, en una base de datos de una escuela, un estudiante se considera una entidad. El estudiante tiene varios atributos como nombre, edad, clase, etc.
Relationship - La asociación lógica entre entidades se llama relationship. Las relaciones se asignan con entidades de varias formas. Las cardinalidades de mapeo definen el número de asociación entre dos entidades.

Mapeo de cardinalidades -
- doce y cincuenta y nueve de la noche
- uno a muchos
- muchos a uno
- muchos a muchos

Modelo relacional

El modelo de datos más popular en DBMS es el modelo relacional. Es un modelo más científico que otros. Este modelo se basa en la lógica de predicados de primer orden y define una tabla como unn-ary relation.

Los principales aspectos destacados de este modelo son:

Los datos se almacenan en tablas llamadas relations.
Las relaciones se pueden normalizar.
En relaciones normalizadas, los valores guardados son valores atómicos.
Cada fila de una relación contiene un valor único.
Cada columna de una relación contiene valores de un mismo dominio.

Esquema de base de datos

Un esquema de base de datos es la estructura básica que representa la vista lógica de toda la base de datos. Define cómo se organizan los datos y cómo se asocian las relaciones entre ellos. Formula todas las restricciones que se aplicarán a los datos.

Un esquema de base de datos define sus entidades y la relación entre ellas. Contiene un detalle descriptivo de la base de datos, que se puede representar mediante diagramas esquemáticos. Son los diseñadores de bases de datos quienes diseñan el esquema para ayudar a los programadores a comprender la base de datos y hacerla útil.

Un esquema de base de datos se puede dividir ampliamente en dos categorías:

Physical Database Schema - Este esquema se refiere al almacenamiento real de datos y su forma de almacenamiento, como archivos, índices, etc. Define cómo se almacenarán los datos en un almacenamiento secundario.
Logical Database Schema- Este esquema define todas las restricciones lógicas que deben aplicarse a los datos almacenados. Define tablas, vistas y restricciones de integridad.

Instancia de base de datos

Es importante que distingamos estos dos términos individualmente. El esquema de la base de datos es el esqueleto de la base de datos. Está diseñado cuando la base de datos no existe en absoluto. Una vez que la base de datos está operativa, es muy difícil realizar cambios en ella. Un esquema de base de datos no contiene datos ni información.

Una instancia de base de datos es un estado de una base de datos operativa con datos en un momento dado. Contiene una instantánea de la base de datos. Las instancias de bases de datos tienden a cambiar con el tiempo. Un DBMS asegura que cada instancia (estado) esté en un estado válido, siguiendo diligentemente todas las validaciones, restricciones y condiciones que los diseñadores de la base de datos han impuesto.

Si un sistema de base de datos no tiene varias capas, resulta difícil realizar cambios en el sistema de base de datos. Los sistemas de bases de datos están diseñados en múltiples capas como aprendimos anteriormente.

Independencia de datos

Un sistema de base de datos normalmente contiene muchos datos además de los datos de los usuarios. Por ejemplo, almacena datos sobre datos, conocidos como metadatos, para localizar y recuperar datos fácilmente. Es bastante difícil modificar o actualizar un conjunto de metadatos una vez que se almacena en la base de datos. Pero a medida que se expande un DBMS, necesita cambiar con el tiempo para satisfacer los requisitos de los usuarios. Si todos los datos son dependientes, se convertiría en un trabajo tedioso y muy complejo.

Los metadatos en sí siguen una arquitectura en capas, de modo que cuando cambiamos los datos en una capa, no afectan los datos en otro nivel. Estos datos son independientes pero están mapeados entre sí.

Independencia de datos lógicos

Los datos lógicos son datos sobre la base de datos, es decir, almacenan información sobre cómo se gestionan los datos en su interior. Por ejemplo, una tabla (relación) almacenada en la base de datos y todas sus restricciones, aplicadas a esa relación.

La independencia lógica de los datos es un tipo de mecanismo que se libera a partir de los datos reales almacenados en el disco. Si hacemos algunos cambios en el formato de la tabla, no debería cambiar los datos que residen en el disco.

Independencia de datos físicos

Todos los esquemas son lógicos y los datos reales se almacenan en formato de bits en el disco. La independencia de los datos físicos es el poder de cambiar los datos físicos sin afectar el esquema o los datos lógicos.

Por ejemplo, en caso de que queramos cambiar o actualizar el sistema de almacenamiento en sí, supongamos que queremos reemplazar los discos duros con SSD, no debería tener ningún impacto en los esquemas o datos lógicos.

El modelo ER define la vista conceptual de una base de datos. Funciona en torno a entidades del mundo real y las asociaciones entre ellas. A nivel de vista, el modelo ER se considera una buena opción para diseñar bases de datos.

Entidad

Una entidad puede ser un objeto del mundo real, animado o inanimado, que se puede identificar fácilmente. Por ejemplo, en la base de datos de una escuela, los estudiantes, profesores, clases y cursos ofrecidos pueden considerarse entidades. Todas estas entidades tienen algunos atributos o propiedades que les dan su identidad.

Un conjunto de entidades es una colección de tipos similares de entidades. Un conjunto de entidades puede contener entidades con atributos que comparten valores similares. Por ejemplo, un conjunto de Estudiantes puede contener a todos los estudiantes de una escuela; Asimismo, un conjunto de profesores puede contener a todos los profesores de una escuela de todas las facultades. No es necesario que los conjuntos de entidades estén separados.

Atributos

Las entidades se representan mediante sus propiedades, denominadas attributes. Todos los atributos tienen valores. Por ejemplo, una entidad de estudiante puede tener el nombre, la clase y la edad como atributos.

Existe un dominio o rango de valores que se pueden asignar a los atributos. Por ejemplo, el nombre de un estudiante no puede ser un valor numérico. Tiene que ser alfabético. La edad de un estudiante no puede ser negativa, etc.

Tipos de atributos

Simple attribute- Los atributos simples son valores atómicos, que no se pueden dividir más. Por ejemplo, el número de teléfono de un estudiante es un valor atómico de 10 dígitos.
Composite attribute- Los atributos compuestos están formados por más de un atributo simple. Por ejemplo, el nombre completo de un estudiante puede tener first_name y last_name.
Derived attribute- Los atributos derivados son los atributos que no existen en la base de datos física, pero sus valores se derivan de otros atributos presentes en la base de datos. Por ejemplo, average_salary en un departamento no debe guardarse directamente en la base de datos, sino que puede derivarse. Para otro ejemplo, la edad se puede derivar de data_of_birth.
Single-value attribute- Los atributos de valor único contienen un valor único. Por ejemplo, Social_Security_Number.
Multi-value attribute- Los atributos de varios valores pueden contener más de un valor. Por ejemplo, una persona puede tener más de un número de teléfono, email_address, etc.

Estos tipos de atributos pueden unirse de una manera como:

atributos simples de un solo valor
atributos simples de varios valores
atributos compuestos de un solo valor
atributos compuestos de varios valores

Conjunto de entidades y claves

La clave es un atributo o colección de atributos que identifica de forma única una entidad entre el conjunto de entidades.

Por ejemplo, el roll_number de un estudiante lo hace identificable entre los estudiantes.

Super Key - Un conjunto de atributos (uno o más) que identifica colectivamente a una entidad en un conjunto de entidades.
Candidate Key- Una superclave mínima se denomina clave candidata. Un conjunto de entidades puede tener más de una clave candidata.
Primary Key - Una clave primaria es una de las claves candidatas elegidas por el diseñador de la base de datos para identificar de forma única el conjunto de entidades.

Relación

La asociación entre entidades se llama relación. Por ejemplo, un empleadoworks_at un departamento, un estudiante enrollsen un curso. Aquí, Works_at y Enrolls se denominan relaciones.

Conjunto de relaciones

Un conjunto de relaciones de tipo similar se denomina conjunto de relaciones. Como las entidades, una relación también puede tener atributos. Estos atributos se llamandescriptive attributes.

Grado de relación

El número de entidades participantes en una relación define el grado de la relación.

Binario = grado 2
Ternario = grado 3
n-ary = grado

Mapeo de cardinalidades

Cardinality define el número de entidades en un conjunto de entidades, que se puede asociar con el número de entidades de otro conjunto mediante el conjunto de relaciones.

One-to-one - Una entidad del conjunto de entidades A puede asociarse como máximo con una entidad del conjunto de entidades B y viceversa.

One-to-many - Una entidad del conjunto de entidades A puede asociarse con más de una entidad del conjunto de entidades B, sin embargo, una entidad del conjunto de entidades B puede asociarse con como máximo una entidad.

Many-to-one - Más de una entidad del conjunto de entidades A se puede asociar con como máximo una entidad del conjunto de entidades B, sin embargo, una entidad del conjunto de entidades B puede asociarse con más de una entidad del conjunto de entidades A.

Many-to-many - Una entidad de A se puede asociar con más de una entidad de B y viceversa.

Aprendamos ahora cómo se representa el modelo ER mediante un diagrama ER. Cualquier objeto, por ejemplo, entidades, atributos de una entidad, conjuntos de relaciones y atributos de conjuntos de relaciones, se puede representar con la ayuda de un diagrama ER.

Entidad

Las entidades se representan mediante rectángulos. Los rectángulos se nombran con el conjunto de entidades que representan.

Atributos

Los atributos son las propiedades de las entidades. Los atributos se representan mediante elipses. Cada elipse representa un atributo y está directamente conectada a su entidad (rectángulo).

Si los atributos son composite, se dividen aún más en una estructura en forma de árbol. Luego, cada nodo se conecta a su atributo. Es decir, los atributos compuestos están representados por elipses que están conectados con una elipse.

Multivalued los atributos se representan mediante una elipse doble.

Derived los atributos se representan mediante elipse discontinua.

Relación

Las relaciones están representadas por una caja en forma de diamante. El nombre de la relación está escrito dentro del cuadro de diamantes. Todas las entidades (rectángulos) que participan en una relación, están conectadas a ella por una línea.

Relación binaria y cardinalidad

Una relación en la que participan dos entidades se denomina binary relationship. La cardinalidad es el número de instancias de una entidad de una relación que se puede asociar con la relación.

One-to-one- Cuando solo una instancia de una entidad está asociada con la relación, se marca como '1: 1'. La siguiente imagen refleja que solo una instancia de cada entidad debe estar asociada con la relación. Representa una relación uno a uno.

One-to-many- Cuando más de una instancia de una entidad está asociada con una relación, se marca como '1: N'. La siguiente imagen refleja que solo una instancia de entidad a la izquierda y más de una instancia de una entidad a la derecha se pueden asociar con la relación. Representa una relación de uno a varios.

Many-to-one- Cuando más de una instancia de entidad está asociada con la relación, se marca como 'N: 1'. La siguiente imagen refleja que más de una instancia de una entidad a la izquierda y solo una instancia de una entidad a la derecha pueden asociarse con la relación. Representa una relación de muchos a uno.

Many-to-many- La siguiente imagen refleja que más de una instancia de una entidad a la izquierda y más de una instancia de una entidad a la derecha pueden asociarse con la relación. Representa una relación de muchos a muchos.

Restricciones de participación

Total Participation- Cada entidad está involucrada en la relación. La participación total está representada por líneas dobles.
Partial participation- No todas las entidades están involucradas en la relación. La participación parcial está representada por líneas simples.

Entidad

Las entidades se representan mediante rectángulos. Los rectángulos se nombran con el conjunto de entidades que representan.

Atributos

Los atributos son las propiedades de las entidades. Los atributos se representan mediante elipses. Cada elipse representa un atributo y está directamente conectada a su entidad (rectángulo).

Multivalued los atributos se representan mediante una elipse doble.

Derived los atributos se representan mediante elipse discontinua.

Relación

Relación binaria y cardinalidad

One-to-one- Cuando solo una instancia de una entidad está asociada con la relación, se marca como '1: 1'. La siguiente imagen refleja que solo una instancia de cada entidad debe estar asociada con la relación. Representa una relación uno a uno.

One-to-many- Cuando más de una instancia de una entidad está asociada con una relación, se marca como '1: N'. La siguiente imagen refleja que solo una instancia de entidad a la izquierda y más de una instancia de una entidad a la derecha se pueden asociar con la relación. Representa una relación de uno a varios.

Many-to-one- Cuando más de una instancia de entidad está asociada con la relación, se marca como 'N: 1'. La siguiente imagen refleja que más de una instancia de una entidad a la izquierda y solo una instancia de una entidad a la derecha pueden asociarse con la relación. Representa una relación de muchos a uno.

Many-to-many- La siguiente imagen refleja que más de una instancia de una entidad a la izquierda y más de una instancia de una entidad a la derecha pueden asociarse con la relación. Representa una relación de muchos a muchos.

Restricciones de participación

Total Participation- Cada entidad está involucrada en la relación. La participación total está representada por líneas dobles.
Partial participation- No todas las entidades están involucradas en la relación. La participación parcial está representada por líneas simples.

El modelo ER tiene el poder de expresar entidades de base de datos de una manera conceptual jerárquica. A medida que aumenta la jerarquía, generaliza la vista de las entidades y, a medida que avanzamos en la jerarquía, nos da el detalle de cada entidad incluida.

Subir en esta estructura se llama generalization, donde las entidades se agrupan para representar una visión más generalizada. Por ejemplo, un estudiante en particular llamado Mira se puede generalizar junto con todos los estudiantes. La entidad será un estudiante y, además, el estudiante es una persona. El reverso se llamaspecialization donde una persona es un estudiante y ese estudiante es Mira.

Generalización

Como se mencionó anteriormente, el proceso de generalizar entidades, donde las entidades generalizadas contienen las propiedades de todas las entidades generalizadas, se llama generalización. En general, varias entidades se agrupan en una entidad generalizada en función de sus características similares. Por ejemplo, la paloma, el gorrión común, el cuervo y la paloma pueden generalizarse como aves.

Especialización

La especialización es lo opuesto a la generalización. En la especialización, un grupo de entidades se divide en subgrupos en función de sus características. Tome una "Persona" de grupo, por ejemplo. Una persona tiene nombre, fecha de nacimiento, género, etc. Estas propiedades son comunes a todas las personas, seres humanos. Pero en una empresa, las personas pueden identificarse como empleados, empleadores, clientes o proveedores, según el papel que desempeñen en la empresa.

De manera similar, en una base de datos escolar, las personas pueden especializarse como docentes, estudiantes o personal, según el papel que desempeñen en la escuela como entidades.

Herencia

Usamos todas las características anteriores de ER-Model para crear clases de objetos en la programación orientada a objetos. Los detalles de las entidades generalmente están ocultos al usuario; este proceso conocido comoabstraction.

La herencia es una característica importante de la generalización y la especialización. Permite que las entidades de nivel inferior hereden los atributos de las entidades de nivel superior.

Por ejemplo, los atributos de una clase Person, como el nombre, la edad y el sexo, pueden ser heredados por entidades de nivel inferior como Student o Teacher.

El Dr. Edgar F. Codd, después de su extensa investigación sobre el modelo relacional de los sistemas de bases de datos, ideó doce reglas propias, que según él, una base de datos debe obedecer para ser considerada como una verdadera base de datos relacional.

Estas reglas se pueden aplicar en cualquier sistema de base de datos que administre datos almacenados utilizando solo sus capacidades relacionales. Esta es una regla básica, que actúa como base para todas las demás reglas.

Regla 1: Regla de información

Los datos almacenados en una base de datos, ya sean datos de usuario o metadatos, deben ser un valor de alguna celda de la tabla. Todo en una base de datos debe almacenarse en formato de tabla.

Regla 2: Regla de acceso garantizado

Se garantiza que cada elemento de datos (valor) sea accesible lógicamente con una combinación de nombre de tabla, clave principal (valor de fila) y nombre de atributo (valor de columna). No se pueden utilizar otros medios, como los punteros, para acceder a los datos.

Regla 3: Tratamiento sistemático de valores NULL

Los valores NULL en una base de datos deben recibir un tratamiento sistemático y uniforme. Esta es una regla muy importante porque un NULL se puede interpretar como uno de los siguientes: faltan datos, no se conocen datos o no son aplicables.

Regla 4: Catálogo en línea activo

La descripción de la estructura de toda la base de datos debe almacenarse en un catálogo en línea, conocido como data dictionary, al que pueden acceder los usuarios autorizados. Los usuarios pueden utilizar el mismo lenguaje de consulta para acceder al catálogo que utilizan para acceder a la propia base de datos.

Regla 5: Regla de sub-idioma de datos completos

Solo se puede acceder a una base de datos utilizando un lenguaje que tenga una sintaxis lineal que admita la definición de datos, la manipulación de datos y las operaciones de gestión de transacciones. Este lenguaje se puede utilizar directamente o mediante alguna aplicación. Si la base de datos permite el acceso a los datos sin la ayuda de este idioma, se considera una infracción.

Regla 6: Ver regla de actualización

Todas las vistas de una base de datos, que en teoría pueden actualizarse, también deben ser actualizables por el sistema.

Regla 7: Regla de alto nivel para insertar, actualizar y eliminar

Una base de datos debe admitir la inserción, actualización y eliminación de alto nivel. Esto no debe limitarse a una sola fila, es decir, también debe admitir operaciones de unión, intersección y menos para producir conjuntos de registros de datos.

Regla 8: Independencia de datos físicos

Los datos almacenados en una base de datos deben ser independientes de las aplicaciones que acceden a la base de datos. Cualquier cambio en la estructura física de una base de datos no debe tener ningún impacto en cómo las aplicaciones externas acceden a los datos.

Regla 9: Independencia de datos lógicos

Los datos lógicos en una base de datos deben ser independientes de la vista de su usuario (aplicación). Cualquier cambio en los datos lógicos no debe afectar a las aplicaciones que los utilizan. Por ejemplo, si dos tablas se combinan o una se divide en dos tablas diferentes, no debería haber ningún impacto o cambio en la aplicación del usuario. Esta es una de las reglas más difíciles de aplicar.

Regla 10: Integridad Independencia

Una base de datos debe ser independiente de la aplicación que la utiliza. Todas sus restricciones de integridad se pueden modificar de forma independiente sin necesidad de ningún cambio en la aplicación. Esta regla hace que una base de datos sea independiente de la aplicación front-end y su interfaz.

Regla 11: Independencia de distribución

El usuario final no debe poder ver que los datos se distribuyen en varias ubicaciones. Los usuarios siempre deben tener la impresión de que los datos se encuentran en un solo sitio. Esta regla se ha considerado la base de los sistemas de bases de datos distribuidos.

Regla 12: Regla de no subversión

Si un sistema tiene una interfaz que proporciona acceso a registros de bajo nivel, entonces la interfaz no debe poder subvertir el sistema y eludir las restricciones de seguridad e integridad.

El modelo de datos relacionales es el modelo de datos principal, que se utiliza ampliamente en todo el mundo para el almacenamiento y procesamiento de datos. Este modelo es simple y tiene todas las propiedades y capacidades necesarias para procesar datos con eficiencia de almacenamiento.

Conceptos

Tables- En el modelo de datos relacionales, las relaciones se guardan en formato de Tablas. Este formato almacena la relación entre entidades. Una tabla tiene filas y columnas, donde las filas representan registros y las columnas representan los atributos.

Tuple - Una sola fila de una tabla, que contiene un solo registro para esa relación, se llama tupla.

Relation instance- Un conjunto finito de tuplas en el sistema de base de datos relacional representa una instancia de relación. Las instancias de relación no tienen tuplas duplicadas.

Relation schema - Un esquema de relación describe el nombre de la relación (nombre de la tabla), los atributos y sus nombres.

Relation key - Cada fila tiene uno o más atributos, conocidos como clave de relación, que pueden identificar la fila en la relación (tabla) de forma única.

Attribute domain - Cada atributo tiene un ámbito de valor predefinido, conocido como dominio de atributo.

Restricciones

Toda relación tiene algunas condiciones que deben cumplirse para que sea una relación válida. Estas condiciones se llamanRelational Integrity Constraints. Hay tres restricciones de integridad principales:

Limitaciones clave
Restricciones de dominio
Restricciones de integridad referencial

Restricciones clave

Debe haber al menos un subconjunto mínimo de atributos en la relación, que pueda identificar una tupla de forma única. Este subconjunto mínimo de atributos se llamakeypara esa relación. Si hay más de uno de estos subconjuntos mínimos, estos se denominancandidate keys.

Las limitaciones clave obligan a que:

en una relación con un atributo clave, dos tuplas no pueden tener valores idénticos para los atributos clave.
un atributo clave no puede tener valores NULL.

Las restricciones clave también se conocen como restricciones de entidad.

Restricciones de dominio

Los atributos tienen valores específicos en el escenario del mundo real. Por ejemplo, la edad solo puede ser un número entero positivo. Se ha intentado aplicar las mismas restricciones a los atributos de una relación. Cada atributo está obligado a tener un rango específico de valores. Por ejemplo, la edad no puede ser menor que cero y los números de teléfono no pueden contener un dígito fuera del 0 al 9.

Restricciones de integridad referencial

Las restricciones de integridad referencial funcionan con el concepto de claves externas. Una clave externa es un atributo clave de una relación al que se puede hacer referencia en otra relación.

La restricción de integridad referencial establece que si una relación se refiere a un atributo clave de una relación diferente o igual, entonces ese elemento clave debe existir.

Se espera que los sistemas de bases de datos relacionales estén equipados con un lenguaje de consulta que pueda ayudar a sus usuarios a consultar las instancias de la base de datos. Hay dos tipos de lenguajes de consulta: álgebra relacional y cálculo relacional.

Álgebra relacional

El álgebra relacional es un lenguaje de consulta procedimental, que toma instancias de relaciones como entrada y produce instancias de relaciones como salida. Utiliza operadores para realizar consultas. Un operador puede serunary o binary. Aceptan las relaciones como su entrada y producen relaciones como su salida. El álgebra relacional se realiza de forma recursiva en una relación y los resultados intermedios también se consideran relaciones.

Las operaciones fundamentales del álgebra relacional son las siguientes:

Select
Project
Union
Establecer diferente
producto cartesiano
Rename

Discutiremos todas estas operaciones en las siguientes secciones.

Seleccionar operación (σ)

Selecciona tuplas que satisfacen el predicado dado de una relación.

Notation- σ _p (r)

Dónde σ significa predicado de selección y rsignifica relación. p es una fórmula lógica preposicional que puede usar conectores comoand, or, y not. Estos términos pueden usar operadores relacionales como - =, ≠, ≥, <,>, ≤.

For example -

σ_{subject="database"}(Books)

Output - Selecciona tuplas de libros donde el tema es 'base de datos'.

σ_{subject="database" and price="450"}(Books)

Output - Selecciona tuplas de libros donde el tema es 'base de datos' y 'precio' es 450.

σ_{subject="database" and price < "450" or year > "2010"}(Books)

Output - Selecciona tuplas de libros donde el tema es 'base de datos' y 'precio' es 450 o aquellos libros publicados después de 2010.

Operación del proyecto (∏)

Proyecta columna (s) que satisfacen un predicado dado.

Notación - ∏ _{A ₁ , A ₂ , A _n} (r)

Donde A ₁ , A ₂ , A _n son nombres de atributos de relaciónr.

Las filas duplicadas se eliminan automáticamente, ya que la relación es un conjunto.

For example -

 ∏_{subject, author} (Books)

Selecciona y proyecta columnas nombradas como tema y autor de la relación Libros.

Operación Unión (∪)

Realiza la unión binaria entre dos relaciones dadas y se define como:

 r ∪ s = { t | t ∈ r or t ∈ s}

Notation - r U s

Dónde r y s son relaciones de base de datos o conjunto de resultados de relación (relación temporal).

Para que una operación sindical sea válida, se deben cumplir las siguientes condiciones:

ry s debe tener el mismo número de atributos.
Los dominios de atributo deben ser compatibles.
Las tuplas duplicadas se eliminan automáticamente.

 ∏ _author (Books) ∪ ∏ _author (Articles)

Output - Proyecta los nombres de los autores que han escrito un libro, un artículo o ambos.

Establecer diferencia (-)

El resultado de la operación de diferencia de conjuntos son tuplas, que están presentes en una relación pero no en la segunda relación.

Notation - r - s

Encuentra todas las tuplas que están presentes en r pero no en s.

 ∏ _author (Books) − ∏ _author (Articles)

Output - Proporciona el nombre de los autores que han escrito libros pero no artículos.

Producto cartesiano (Χ)

Combina información de dos relaciones diferentes en una.

Notation - r Χ s

Dónde r y s son relaciones y su salida se definirá como -

r Χ s = {qt | q ∈ r y t ∈ s}

 ∏ _{author = 'tutorialspoint'}(Books Χ Articles)

Output - Produce una relación, que muestra todos los libros y artículos escritos por tutorialspoint.

Cambiar el nombre de la operación (ρ)

Los resultados del álgebra relacional también son relaciones pero sin nombre. La operación de cambio de nombre nos permite cambiar el nombre de la relación de salida. La operación 'renombrar' se denota con letra griega pequeñarho ρ .

Notation- ρ _x (E)

Donde el resultado de la expresión E se guarda con el nombre de x.

Las operaciones adicionales son:

Establecer intersección
Assignment
Unión natural

Cálculo relacional

A diferencia del álgebra relacional, el cálculo relacional es un lenguaje de consulta no procedimental, es decir, dice qué hacer pero nunca explica cómo hacerlo.

El cálculo relacional existe en dos formas:

Cálculo relacional de tuplas (TRC)

Filtrar rangos de variables sobre tuplas

Notation- {T | Condición}

Devuelve todas las tuplas T que satisfacen una condición.

For example -

{ T.name |  Author(T) AND T.article = 'database' }

Output - Devuelve tuplas con 'nombre' del autor que ha escrito un artículo en 'base de datos'.

TRC se puede cuantificar. Podemos usar cuantificadores existenciales (∃) y universales (∀).

For example -

{ R| ∃T   ∈ Authors(T.article='database' AND R.name=T.name)}

Output - La consulta anterior arrojará el mismo resultado que la anterior.

Cálculo relacional de dominio (DRC)

En DRC, la variable de filtrado usa el dominio de atributos en lugar de valores de tupla completos (como se hizo en TRC, mencionado anteriormente).

Notation -

{a ₁ , a ₂ , a ₃ , ..., a _n | P (un ₁ , un ₂ , un ₃ , ..., un _n )}

Donde a1, a2 son atributos y P representa fórmulas creadas por atributos internos.

For example -

{< article, page, subject > | 
       
         ∈ TutorialsPoint ∧ subject = 'database'}

Output - Produce Artículo, Página y Asunto de la relación TutorialsPoint, donde Asunto es la base de datos.

Al igual que TRC, DRC también se puede escribir utilizando cuantificadores existenciales y universales. DRC también involucra operadores relacionales.

El poder de expresión del cálculo de relaciones de tuplas y el cálculo de relaciones de dominios es equivalente al álgebra relacional.

El modelo ER, cuando se conceptualiza en diagramas, ofrece una buena descripción general de la relación entidad, que es más fácil de entender. Los diagramas ER se pueden asignar a un esquema relacional, es decir, es posible crear un esquema relacional utilizando el diagrama ER. No podemos importar todas las restricciones de ER en un modelo relacional, pero se puede generar un esquema aproximado.

Hay varios procesos y algoritmos disponibles para convertir diagramas ER en esquemas relacionales. Algunos de ellos son automáticos y otros son manuales. Podemos centrarnos aquí en el mapeo de los contenidos del diagrama a los conceptos básicos relacionales.

Los diagramas ER se componen principalmente de:

Entidad y sus atributos
Relación, que es asociación entre entidades.

Entidad de mapeo

Una entidad es un objeto del mundo real con algunos atributos.

Proceso de mapeo (algoritmo)

Crea una tabla para cada entidad.
Los atributos de la entidad deben convertirse en campos de tablas con sus respectivos tipos de datos.
Declare la clave principal.

Relación de mapeo

Una relación es una asociación entre entidades.

Proceso de mapeo

Crea una mesa para una relación.
Agregue las claves primarias de todas las Entidades participantes como campos de tabla con sus respectivos tipos de datos.
Si la relación tiene algún atributo, agregue cada atributo como campo de la tabla.
Declare una clave principal que componga todas las claves principales de las entidades participantes.
Declare todas las restricciones de clave externa.

Asignación de conjuntos de entidades débiles

Un conjunto de entidades débiles es aquel que no tiene ninguna clave primaria asociada.

Proceso de mapeo

Cree una tabla para el conjunto de entidades débiles.
Agregue todos sus atributos a la tabla como campo.
Agregue la clave principal del conjunto de entidades de identificación.
Declare todas las restricciones de clave externa.

Asignación de entidades jerárquicas

La especialización o generalización de ER se presenta en forma de conjuntos de entidades jerárquicas.

Proceso de mapeo

Cree tablas para todas las entidades de nivel superior.
Cree tablas para entidades de nivel inferior.
Agregue claves primarias de entidades de nivel superior en la tabla de entidades de nivel inferior.
En las tablas de nivel inferior, agregue todos los demás atributos de las entidades de nivel inferior.
Declare la clave principal de la tabla de nivel superior y la clave principal de la tabla de nivel inferior.
Declare restricciones de clave externa.

SQL es un lenguaje de programación para bases de datos relacionales. Está diseñado sobre álgebra relacional y cálculo relacional de tuplas. SQL viene como un paquete con todas las distribuciones principales de RDBMS.

SQL comprende lenguajes de definición y manipulación de datos. Usando las propiedades de definición de datos de SQL, se puede diseñar y modificar el esquema de la base de datos, mientras que las propiedades de manipulación de datos permiten que SQL almacene y recupere datos de la base de datos.

Lenguaje de definición de datos

SQL utiliza el siguiente conjunto de comandos para definir el esquema de la base de datos:

CREAR

Crea nuevas bases de datos, tablas y vistas desde RDBMS.

For example -

Create database tutorialspoint;
Create table article;
Create view for_students;

SOLTAR

Elimina comandos, vistas, tablas y bases de datos de RDBMS.

For example-

Drop object_type object_name;
Drop database tutorialspoint;
Drop table article;
Drop view for_students;

ALTERAR

Modifica el esquema de la base de datos.

Alter object_type object_name parameters;

For example-

Alter table article add subject varchar;

Este comando agrega un atributo en la relación article con el nombre subject del tipo de cadena.

Lenguaje de manipulación de datos

SQL está equipado con lenguaje de manipulación de datos (DML). DML modifica la instancia de la base de datos insertando, actualizando y eliminando sus datos. DML es responsable de todas las modificaciones de datos de formularios en una base de datos. SQL contiene el siguiente conjunto de comandos en su sección DML:

SELECT/FROM/WHERE
INSERTAR EN / VALORES
UPDATE/SET/WHERE
BORRAR DE / DONDE

Estas construcciones básicas permiten a los programadores y usuarios de bases de datos ingresar datos e información en la base de datos y recuperarlos de manera eficiente utilizando una serie de opciones de filtro.

SELECCIONAR / DESDE / DONDE

SELECT- Este es uno de los comandos de consulta fundamentales de SQL. Es similar a la operación de proyección del álgebra relacional. Selecciona los atributos en función de la condición descrita por la cláusula WHERE.
FROM- Esta cláusula toma un nombre de relación como argumento a partir del cual se seleccionarán / proyectarán los atributos. En caso de que se den más de un nombre de relación, esta cláusula corresponde al producto cartesiano.
WHERE - Esta cláusula define predicado o condiciones, que deben coincidir para calificar los atributos a proyectar.

For example -

Select author_name
From book_author
Where age > 50;

Este comando producirá los nombres de los autores de la relación book_author cuya edad sea mayor de 50 años.

INSERTAR EN / VALORES

Este comando se usa para insertar valores en las filas de una tabla (relación).

Syntax-

INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ])

INSERT INTO table VALUES (value1, [value2, ... ])

For example -

INSERT INTO tutorialspoint (Author, Subject) VALUES ("anonymous", "computers");

ACTUALIZAR / CONFIGURAR / DONDE

Este comando se utiliza para actualizar o modificar los valores de las columnas en una tabla (relación).

Syntax -

UPDATE table_name SET column_name = value [, column_name = value ...] [WHERE condition]

For example -

UPDATE tutorialspoint SET Author="webmaster" WHERE Author="anonymous";

BORRAR / DESDE / DONDE

Este comando se utiliza para eliminar una o más filas de una tabla (relación).

Syntax -

DELETE FROM table_name [WHERE condition];

For example -

DELETE FROM tutorialspoints
   WHERE Author="unknown";

Dependencia funcional

La dependencia funcional (FD) es un conjunto de restricciones entre dos atributos en una relación. La dependencia funcional dice que si dos tuplas tienen los mismos valores para los atributos A1, A2, ..., An, entonces esas dos tuplas deben tener los mismos valores para los atributos B1, B2, ..., Bn.

La dependencia funcional está representada por un signo de flecha (→) es decir, X → Y, donde X determina funcionalmente Y. Los atributos del lado izquierdo determinan los valores de los atributos del lado derecho.

Axiomas de Armstrong

Si F es un conjunto de dependencias funcionales, entonces el cierre de F, denotado como F ⁺ , es el conjunto de todas las dependencias funcionales implícitas lógicamente en F. Los axiomas de Armstrong son un conjunto de reglas que, cuando se aplican repetidamente, generan un cierre de dependencias funcionales .

Reflexive rule - Si alfa es un conjunto de atributos y beta es_subconjunto_de alfa, entonces alfa tiene beta.
Augmentation rule- Si a → b se cumple e y es un conjunto de atributos, entonces ay → by también se cumple. Eso es agregar atributos en dependencias, no cambia las dependencias básicas.
Transitivity rule- Igual que la regla transitiva en álgebra, si a → b se cumple y b → c se cumple, entonces a → c también se cumple. a → b se llama funcionalmente a que determina b.

Dependencia funcional trivial

Trivial- Si se cumple una dependencia funcional (FD) X → Y, donde Y es un subconjunto de X, entonces se denomina FD trivial. Los FD triviales siempre se mantienen.
Non-trivial - Si se cumple un FD X → Y, donde Y no es un subconjunto de X, entonces se denomina FD no trivial.
Completely non-trivial - Si un FD X → Y se cumple, donde x se cruza con Y = Φ, se dice que es un FD completamente no trivial.

Normalización

Si el diseño de una base de datos no es perfecto, puede contener anomalías, que son como un mal sueño para cualquier administrador de bases de datos. Administrar una base de datos con anomalías es casi imposible.

Update anomalies- Si los elementos de datos están dispersos y no están vinculados entre sí de manera adecuada, podría dar lugar a situaciones extrañas. Por ejemplo, cuando intentamos actualizar un elemento de datos que tiene sus copias esparcidas en varios lugares, algunas instancias se actualizan correctamente mientras que algunas otras se quedan con valores antiguos. Tales instancias dejan la base de datos en un estado inconsistente.
Deletion anomalies - Intentamos eliminar un registro, pero partes del mismo se dejaron sin eliminar por desconocimiento, los datos también se guardan en otro lugar.
Insert anomalies - Intentamos insertar datos en un registro que no existe en absoluto.

La normalización es un método para eliminar todas estas anomalías y llevar la base de datos a un estado coherente.

Primera forma normal

La primera forma normal se define en la propia definición de relaciones (tablas). Esta regla define que todos los atributos en una relación deben tener dominios atómicos. Los valores en un dominio atómico son unidades indivisibles.

Reorganizamos la relación (tabla) como se muestra a continuación, para convertirla a Primera forma normal.

Cada atributo debe contener solo un valor de su dominio predefinido.

Segunda forma normal

Antes de aprender sobre la segunda forma normal, debemos comprender lo siguiente:

Prime attribute - Un atributo, que es parte de la clave candidata, se conoce como atributo principal.
Non-prime attribute - Se dice que un atributo que no es parte de la clave principal es un atributo no principal.

Si seguimos la segunda forma normal, entonces cada atributo no principal debería ser funcionalmente dependiente del atributo de clave principal. Es decir, si X → A se cumple, entonces no debería haber ningún subconjunto apropiado Y de X, para el cual Y → A también es válido.

Vemos aquí en la relación Student_Project que los atributos de la clave principal son Stu_ID y Proj_ID. Según la regla, los atributos que no son de clave, es decir, Stu_Name y Proj_Name, deben depender de ambos y no de ninguno de los atributos de clave principal individualmente. Pero encontramos que Stu_Name puede ser identificado por Stu_ID y Proj_Name puede ser identificado por Proj_ID de forma independiente. Se llamapartial dependency, que no está permitido en la Segunda Forma Normal.

Rompimos la relación en dos como se muestra en la imagen de arriba. Entonces no existe una dependencia parcial.

Tercera forma normal

Para que una relación esté en la tercera forma normal, debe estar en la segunda forma normal y lo siguiente debe satisfacer:

Ningún atributo no principal depende transitivamente del atributo de clave principal.

Para cualquier dependencia funcional no trivial, X → A, entonces -

A es el atributo principal.

Encontramos que en la relación Student_detail anterior, Stu_ID es la clave y el único atributo de clave principal. Descubrimos que la ciudad se puede identificar por Stu_ID y por Zip. Ni Zip es una superclave ni City es un atributo principal. Además, Stu_ID → Zip → Ciudad, por lo que existetransitive dependency.

Para llevar esta relación a la tercera forma normal, dividimos la relación en dos relaciones de la siguiente manera:

Forma normal de Boyce-Codd

La forma normal de Boyce-Codd (BCNF) es una extensión de la tercera forma normal en términos estrictos. BCNF afirma que:

Para cualquier dependencia funcional no trivial, X → A, X debe ser una superclave.

En la imagen de arriba, Stu_ID es la superclave en la relación Student_Detail y Zip es la superclave en la relación ZipCodes. Entonces,

Stu_ID → Stu_Name, Zip

Código postal → Ciudad

Lo que confirma que ambas relaciones están en BCNF.

Entendemos los beneficios de tomar un producto cartesiano de dos relaciones, lo que nos da todas las tuplas posibles que están emparejadas. Pero podría no ser factible para nosotros en ciertos casos tomar un producto cartesiano en el que encontramos relaciones enormes con miles de tuplas que tienen un número considerable de atributos.

Joines una combinación de un producto cartesiano seguido de un proceso de selección. Una operación de unión empareja dos tuplas de diferentes relaciones, si y solo si se cumple una condición de unión determinada.

Describiremos brevemente varios tipos de combinación en las siguientes secciones.

Theta (θ) Únete

Theta join combina tuplas de diferentes relaciones siempre que satisfagan la condición theta. La condición de unión se indica con el símboloθ.

Notación

R1 ⋈_θ R2

R1 y R2 son relaciones que tienen atributos (A1, A2, .., An) y (B1, B2, .., Bn) tales que los atributos no tienen nada en común, es decir R1 ∩ R2 = Φ.

Theta join puede usar todo tipo de operadores de comparación.

Estudiante
SID	Nombre	Std
101	Alex	10
102	Maria	11

Asignaturas
Clase	Tema
10	Matemáticas
10	Inglés
11	Música
11	Deportes

Student_Detail =

STUDENT ⋈_{Student.Std = Subject.Class} SUBJECT

Student_detail
SID	Nombre	Std	Clase	Tema
101	Alex	10	10	Matemáticas
101	Alex	10	10	Inglés
102	Maria	11	11	Música
102	Maria	11	11	Deportes

Equijoin

Cuando Theta join usa solo equalityoperador de comparación, se dice que es equijoin. El ejemplo anterior corresponde a equijoin.

Unión natural ( ⋈ )

La unión natural no utiliza ningún operador de comparación. No se concatena como lo hace un producto cartesiano. Podemos realizar una unión natural solo si existe al menos un atributo común entre dos relaciones. Además, los atributos deben tener el mismo nombre y dominio.

La unión natural actúa sobre los atributos coincidentes donde los valores de los atributos en ambas relaciones son iguales.

Cursos
CID	Curso	Departamento
CS01	Base de datos	CS
ME01	Mecánica	YO
EE01	Electrónica	EE

Capacho
Departamento	Cabeza
CS	Alex
YO	maya
EE	Mira

Cursos ⋈ HoD
Departamento	CID	Curso	Cabeza
CS	CS01	Base de datos	Alex
YO	ME01	Mecánica	maya
EE	EE01	Electrónica	Mira

Uniones externas

Theta Join, Equijoin y Natural Join se denominan uniones internas. Una combinación interna incluye solo aquellas tuplas con atributos coincidentes y el resto se descarta en la relación resultante. Por lo tanto, necesitamos usar combinaciones externas para incluir todas las tuplas de las relaciones de participación en la relación resultante. Hay tres tipos de combinaciones externas: combinación externa izquierda, combinación externa derecha y combinación externa completa.

Unión exterior izquierda (R

S)

Todas las tuplas de la relación izquierda, R, se incluyen en la relación resultante. Si hay tuplas en R sin ninguna tupla coincidente en la relación Derecha S, entonces los atributos S de la relación resultante se hacen NULL.

Izquierda
UN	segundo
100	Base de datos
101	Mecánica
102	Electrónica

Correcto
UN	segundo
100	Alex
102	maya
104	Mira

Cursos HoD
UN	segundo	C	re
100	Base de datos	100	Alex
101	Mecánica	---	---
102	Electrónica	102	maya

Unión exterior derecha: (R

S)

Todas las tuplas de la relación Derecha, S, se incluyen en la relación resultante. Si hay tuplas en S sin ninguna tupla coincidente en R, entonces los atributos R de la relación resultante se hacen NULL.

Cursos HoD
UN	segundo	C	re
100	Base de datos	100	Alex
102	Electrónica	102	maya
---	---	104	Mira

Unión externa completa: (R

S)

Todas las tuplas de ambas relaciones de participación se incluyen en la relación resultante. Si no hay tuplas coincidentes para ambas relaciones, sus respectivos atributos no coincidentes se convierten en NULL.

Cursos HoD
UN	segundo	C	re
100	Base de datos	100	Alex
101	Mecánica	---	---
102	Electrónica	102	maya
---	---	104	Mira

Las bases de datos se almacenan en formatos de archivo, que contienen registros. A nivel físico, los datos reales se almacenan en formato electromagnético en algún dispositivo. Estos dispositivos de almacenamiento pueden clasificarse ampliamente en tres tipos:

Primary Storage- El almacenamiento de memoria que es directamente accesible a la CPU se incluye en esta categoría. La memoria interna de la CPU (registros), la memoria rápida (caché) y la memoria principal (RAM) son directamente accesibles a la CPU, ya que todas están ubicadas en la placa base o en el chipset de la CPU. Este almacenamiento suele ser muy pequeño, ultrarrápido y volátil. El almacenamiento primario requiere un suministro de energía continuo para mantener su estado. En caso de un corte de energía, todos sus datos se pierden.
Secondary Storage- Los dispositivos de almacenamiento secundarios se utilizan para almacenar datos para uso futuro o como respaldo. El almacenamiento secundario incluye dispositivos de memoria que no forman parte del chipset de la CPU o la placa base, por ejemplo, discos magnéticos, discos ópticos (DVD, CD, etc.), discos duros, unidades flash y cintas magnéticas.
Tertiary Storage- El almacenamiento terciario se utiliza para almacenar grandes volúmenes de datos. Dado que tales dispositivos de almacenamiento son externos al sistema informático, son los más lentos en velocidad. Estos dispositivos de almacenamiento se utilizan principalmente para realizar copias de seguridad de un sistema completo. Los discos ópticos y las cintas magnéticas se utilizan ampliamente como almacenamiento terciario.

Jerarquía de memoria

Un sistema informático tiene una jerarquía de memoria bien definida. Una CPU tiene acceso directo a su memoria principal, así como a sus registros incorporados. El tiempo de acceso a la memoria principal es obviamente menor que la velocidad de la CPU. Para minimizar esta discrepancia de velocidad, se introduce la memoria caché. La memoria caché proporciona el tiempo de acceso más rápido y contiene datos a los que la CPU accede con mayor frecuencia.

La memoria con el acceso más rápido es la más costosa. Los dispositivos de almacenamiento más grandes ofrecen una velocidad lenta y son menos costosos, sin embargo, pueden almacenar grandes volúmenes de datos en comparación con los registros de la CPU o la memoria caché.

Discos magneticos

Las unidades de disco duro son los dispositivos de almacenamiento secundario más comunes en los sistemas informáticos actuales. Estos se denominan discos magnéticos porque utilizan el concepto de magnetización para almacenar información. Los discos duros consisten en discos de metal recubiertos con material magnetizable. Estos discos se colocan verticalmente en un eje. Un cabezal de lectura / escritura se mueve entre los discos y se usa para magnetizar o desmagnetizar el punto debajo de él. Un punto magnetizado se puede reconocer como 0 (cero) o 1 (uno).

Los discos duros están formateados en un orden bien definido para almacenar datos de manera eficiente. Una placa de disco duro tiene muchos círculos concéntricos, llamadostracks. Cada pista se divide a su vez ensectors. Un sector en un disco duro normalmente almacena 512 bytes de datos.

REDADA

RAID significa Rabundante Array de Iindependiente Disks, que es una tecnología para conectar varios dispositivos de almacenamiento secundarios y utilizarlos como un único medio de almacenamiento.

RAID consta de una serie de discos en los que se conectan varios discos entre sí para lograr diferentes objetivos. Los niveles de RAID definen el uso de matrices de discos.

RAID 0- En este nivel, se implementa una matriz seccionada de discos. Los datos se dividen en bloques y los bloques se distribuyen entre discos. Cada disco recibe un bloque de datos para escribir / leer en paralelo. Mejora la velocidad y el rendimiento del dispositivo de almacenamiento. No hay paridad ni respaldo en el nivel 0.

RAID 1- RAID 1 utiliza técnicas de duplicación. Cuando se envían datos a un controlador RAID, envía una copia de los datos a todos los discos de la matriz. El nivel RAID 1 también se denominamirroring y proporciona un 100% de redundancia en caso de fallo.

RAID 2- RAID 2 registra el código de corrección de errores utilizando la distancia de Hamming para sus datos, divididos en diferentes discos. Al igual que en el nivel 0, cada bit de datos de una palabra se registra en un disco separado y los códigos ECC de las palabras de datos se almacenan en un conjunto de discos diferente. Debido a su compleja estructura y alto costo, RAID 2 no está disponible comercialmente.

RAID 3- RAID 3 reparte los datos en varios discos. El bit de paridad generado para la palabra de datos se almacena en un disco diferente. Esta técnica hace que supere las fallas de un solo disco.

RAID 4- En este nivel, se escribe un bloque completo de datos en discos de datos y luego la paridad se genera y almacena en un disco diferente. Tenga en cuenta que el nivel 3 usa bandas a nivel de bytes, mientras que el nivel 4 usa bandas a nivel de bloque. Tanto el nivel 3 como el nivel 4 requieren al menos tres discos para implementar RAID.

RAID 5 - RAID 5 escribe bloques de datos completos en diferentes discos, pero los bits de paridad generados para la banda de bloques de datos se distribuyen entre todos los discos de datos en lugar de almacenarlos en un disco dedicado diferente.

RAID 6- RAID 6 es una extensión del nivel 5. En este nivel, se generan y almacenan dos paridades independientes de forma distribuida entre varios discos. Dos paridades proporcionan tolerancia a fallos adicional. Este nivel requiere al menos cuatro unidades de disco para implementar RAID.

La información y los datos relativos se almacenan colectivamente en formatos de archivo. Un archivo es una secuencia de registros almacenados en formato binario. Una unidad de disco se formatea en varios bloques que pueden almacenar registros. Los registros de archivos se asignan a esos bloques de disco.

Organización de archivos

La organización de archivos define cómo se asignan los registros de archivos a los bloques de disco. Tenemos cuatro tipos de organización de archivos para organizar registros de archivos:

Organización de archivos de montón

Cuando se crea un archivo con Organización de archivos de montón, el sistema operativo asigna un área de memoria a ese archivo sin más detalles contables. Los registros de archivos se pueden colocar en cualquier lugar de esa área de memoria. Es responsabilidad del software administrar los registros. Heap File no admite ningún orden, secuenciación o indexación por sí solo.

Organización secuencial de archivos

Cada registro de archivo contiene un campo de datos (atributo) para identificar de manera única ese registro. En la organización de archivos secuenciales, los registros se colocan en el archivo en algún orden secuencial según el campo de clave única o la clave de búsqueda. Prácticamente, no es posible almacenar todos los registros de forma secuencial en forma física.

Organización de archivos hash

Hash File Organization utiliza el cálculo de la función Hash en algunos campos de los registros. La salida de la función hash determina la ubicación del bloque de disco donde se colocarán los registros.

Organización de archivos agrupados

La organización de archivos agrupados no se considera buena para bases de datos grandes. En este mecanismo, los registros relacionados de una o más relaciones se mantienen en el mismo bloque de disco, es decir, el orden de los registros no se basa en la clave principal o la clave de búsqueda.

Operaciones de archivo

Las operaciones en archivos de base de datos se pueden clasificar en dos categorías:

Update Operations
Retrieval Operations

Las operaciones de actualización cambian los valores de los datos mediante inserción, eliminación o actualización. Las operaciones de recuperación, por otro lado, no alteran los datos, sino que los recuperan después de un filtrado condicional opcional. En ambos tipos de operaciones, la selección juega un papel importante. Además de la creación y eliminación de un archivo, puede haber varias operaciones que se pueden realizar en archivos.

Open - Un archivo se puede abrir en uno de los dos modos, read mode o write mode. En modo lectura, el sistema operativo no permite que nadie altere los datos. En otras palabras, los datos son de solo lectura. Los archivos abiertos en modo lectura se pueden compartir entre varias entidades. El modo de escritura permite la modificación de datos. Los archivos abiertos en modo de escritura se pueden leer pero no se pueden compartir.
Locate- Cada archivo tiene un puntero de archivo, que indica la posición actual donde se leerán o escribirán los datos. Este puntero se puede ajustar en consecuencia. Usando la operación de buscar (buscar), se puede mover hacia adelante o hacia atrás.
Read- De forma predeterminada, cuando los archivos se abren en modo de lectura, el puntero del archivo apunta al principio del archivo. Hay opciones en las que el usuario puede decirle al sistema operativo dónde ubicar el puntero de archivo en el momento de abrir un archivo. Se leen los siguientes datos del puntero de archivo.
Write- El usuario puede seleccionar abrir un archivo en modo de escritura, lo que le permite editar su contenido. Puede ser eliminación, inserción o modificación. El puntero del archivo se puede ubicar en el momento de la apertura o se puede cambiar dinámicamente si el sistema operativo lo permite.
Close- Esta es la operación más importante desde el punto de vista del sistema operativo. Cuando se genera una solicitud para cerrar un archivo, el sistema operativo
- elimina todos los bloqueos (si está en modo compartido),
- guarda los datos (si se modifican) en el medio de almacenamiento secundario, y
- libera todos los búferes y controladores de archivos asociados con el archivo.

La organización de los datos dentro de un archivo juega un papel importante aquí. El proceso para ubicar el puntero de archivo a un registro deseado dentro de un archivo varía según si los registros están organizados secuencialmente o agrupados.

Sabemos que los datos se almacenan en forma de registros. Cada registro tiene un campo clave, lo que ayuda a que sea reconocido de forma única.

La indexación es una técnica de estructura de datos para recuperar de manera eficiente registros de los archivos de la base de datos en función de algunos atributos en los que se realizó la indexación. La indexación en los sistemas de bases de datos es similar a lo que vemos en los libros.

La indexación se define en función de sus atributos de indexación. La indexación puede ser de los siguientes tipos:

Primary Index- El índice principal se define en un archivo de datos ordenado. El archivo de datos está ordenadokey field. El campo de clave es generalmente la clave principal de la relación.
Secondary Index - El índice secundario se puede generar a partir de un campo que es una clave candidata y tiene un valor único en cada registro, o una no clave con valores duplicados.
Clustering Index- El índice de agrupación se define en un archivo de datos ordenado. El archivo de datos está ordenado en un campo que no es clave.

La indexación ordenada es de dos tipos:

Índice denso
Índice disperso

Índice denso

En el índice denso, hay un registro de índice para cada valor de clave de búsqueda en la base de datos. Esto hace que la búsqueda sea más rápida pero requiere más espacio para almacenar los registros de índice. Los registros de índice contienen el valor de la clave de búsqueda y un puntero al registro real en el disco.

Índice disperso

En el índice disperso, los registros de índice no se crean para cada clave de búsqueda. Un registro de índice contiene aquí una clave de búsqueda y un puntero real a los datos en el disco. Para buscar un registro, primero procedemos por registro de índice y llegamos a la ubicación real de los datos. Si los datos que estamos buscando no están donde llegamos directamente siguiendo el índice, entonces el sistema inicia una búsqueda secuencial hasta que se encuentran los datos deseados.

Índice multinivel

Los registros de índice comprenden valores de clave de búsqueda e indicadores de datos. El índice multinivel se almacena en el disco junto con los archivos reales de la base de datos. A medida que aumenta el tamaño de la base de datos, también lo hace el tamaño de los índices. Existe una inmensa necesidad de mantener los registros de índice en la memoria principal para acelerar las operaciones de búsqueda. Si se utiliza un índice de un solo nivel, no se puede guardar un índice de gran tamaño en la memoria, lo que da lugar a múltiples accesos al disco.

El índice multinivel ayuda a dividir el índice en varios índices más pequeños para hacer que el nivel más externo sea tan pequeño que se pueda guardar en un solo bloque de disco, que se puede acomodar fácilmente en cualquier lugar de la memoria principal.

B ⁺ Árbol

El árbol AB ⁺ es un árbol de búsqueda binario equilibrado que sigue un formato de índice de varios niveles. Los nodos de hoja de un árbol B ⁺ denotan punteros de datos reales. El árbol B ⁺ asegura que todos los nudos de las hojas permanezcan a la misma altura, por lo tanto equilibrados. Además, los nodos hoja están vinculados mediante una lista de vínculos; por lo tanto, un árbol B ⁺ puede admitir tanto el acceso aleatorio como el secuencial.

Estructura del árbol B ⁺

Cada nodo hoja está a la misma distancia del nodo raíz. AB ⁺ árbol es del ordenn dónde nes fijo para cada árbol B ⁺ .

Internal nodes -

Los nodos internos (no hoja) contienen al menos ⌈n / 2⌉ punteros, excepto el nodo raíz.
Como máximo, un nodo interno puede contener n punteros.

Leaf nodes -

Los nodos hoja contienen al menos ⌈n / 2⌉ punteros de registro y valores de clave ⌈n / 2⌉.
Como máximo, un nodo hoja puede contener n grabar punteros y n valores clave.
Cada nodo hoja contiene un puntero de bloque P para apuntar al siguiente nodo hoja y forma una lista vinculada.

Inserción de árbol B ⁺

Los árboles B ⁺ se llenan desde la parte inferior y cada entrada se realiza en el nodo de la hoja.
Si un nodo hoja se desborda -
- Divida el nodo en dos partes.
- Partición en i = ⌊(m+1)_/2⌋.
- primero i las entradas se almacenan en un nodo.
- El resto de las entradas (i + 1 en adelante) se mueven a un nuevo nodo.
- i^th la clave está duplicada en el padre de la hoja.
Si un nodo no hoja se desborda -
- Divida el nodo en dos partes.
- Particione el nodo en i = ⌈(m+1)_/2⌉.
- Entradas hasta i se mantienen en un nodo.
- El resto de las entradas se mueven a un nuevo nodo.

B ⁺ Eliminación de árboles

Las entradas del árbol B ⁺ se eliminan en los nodos hoja.
La entrada de destino se busca y se elimina.
- Si es un nodo interno, elimínelo y reemplácelo con la entrada de la posición izquierda.
Después de la eliminación, se prueba el subdesbordamiento,
- Si se produce un desbordamiento, distribuya las entradas de los nodos que le quedan.
Si la distribución no es posible desde la izquierda, entonces
- Distribuya desde los nodos directamente.
Si la distribución no es posible desde la izquierda o desde la derecha, entonces
- Fusiona el nodo con la izquierda y la derecha.

Para una estructura de base de datos enorme, puede ser casi imposible buscar todos los valores de índice en todo su nivel y luego llegar al bloque de datos de destino para recuperar los datos deseados. El hash es una técnica eficaz para calcular la ubicación directa de un registro de datos en el disco sin utilizar la estructura de índice.

El hash utiliza funciones hash con claves de búsqueda como parámetros para generar la dirección de un registro de datos.

Organización hash

Bucket- Un archivo hash almacena datos en formato de cubo. El balde se considera una unidad de almacenamiento. Un depósito suele almacenar un bloque de disco completo, que a su vez puede almacenar uno o más registros.
Hash Function - Una función hash, h, es una función de mapeo que mapea todo el conjunto de claves de búsqueda Ka la dirección donde se colocan los registros reales. Es una función desde claves de búsqueda hasta direcciones de depósito.

Hash estático

En el hash estático, cuando se proporciona un valor de clave de búsqueda, la función hash siempre calcula la misma dirección. Por ejemplo, si se utiliza la función hash mod-4, generará solo 5 valores. La dirección de salida siempre será la misma para esa función. El número de depósitos proporcionados permanece sin cambios en todo momento.

Operación

Insertion - Cuando se requiere ingresar un registro usando hash estático, la función hash h calcula la dirección del depósito para la clave de búsqueda K, donde se almacenará el registro.

Dirección del depósito = h (K)
Search - Cuando es necesario recuperar un registro, se puede utilizar la misma función hash para recuperar la dirección del depósito donde se almacenan los datos.
Delete - Esto es simplemente una búsqueda seguida de una operación de eliminación.

Desbordamiento del cucharón

La condición de desbordamiento del cubo se conoce como collision. Este es un estado fatal para cualquier función hash estática. En este caso, se puede utilizar el encadenamiento de desbordamiento.

Overflow Chaining- Cuando los depósitos están llenos, se asigna un nuevo depósito para el mismo resultado de hash y se vincula después del anterior. Este mecanismo se llamaClosed Hashing.

Linear Probing- Cuando una función hash genera una dirección en la que los datos ya están almacenados, se le asigna el siguiente depósito libre. Este mecanismo se llamaOpen Hashing.

Hash dinámico

El problema con el hash estático es que no se expande ni se contrae dinámicamente a medida que el tamaño de la base de datos crece o se reduce. El hash dinámico proporciona un mecanismo en el que los depósitos de datos se agregan y eliminan de forma dinámica y bajo demanda. El hash dinámico también se conoce comoextended hashing.

La función hash, en hash dinámico, está hecha para producir una gran cantidad de valores y inicialmente solo se usan unos pocos.

Organización

El prefijo de un valor hash completo se toma como índice hash. Solo una parte del valor hash se usa para calcular direcciones de depósito. Cada índice hash tiene un valor de profundidad para indicar cuántos bits se utilizan para calcular una función hash. Estos bits pueden abordar 2n depósitos. Cuando se consumen todos estos bits, es decir, cuando todos los depósitos están llenos, el valor de profundidad aumenta linealmente y se asignan el doble de depósitos.

Operación

Querying - Mire el valor de profundidad del índice hash y use esos bits para calcular la dirección del depósito.
Update - Realice una consulta como la anterior y actualice los datos.
Deletion - Realizar una consulta para localizar los datos deseados y eliminarlos.
Insertion - Calcular la dirección del depósito
- Si el cubo ya está lleno.
  - Agrega más cubos.
  - Agregue bits adicionales al valor hash.
  - Vuelva a calcular la función hash.
- Más
  - Agrega datos al depósito,
- Si todos los depósitos están llenos, realice las soluciones del hash estático.

El hash no es favorable cuando los datos están organizados en algún orden y las consultas requieren un rango de datos. Cuando los datos son discretos y aleatorios, el hash funciona mejor.

Los algoritmos de hash tienen una mayor complejidad que la indexación. Todas las operaciones hash se realizan en tiempo constante.

Una transacción se puede definir como un grupo de tareas. Una sola tarea es la unidad mínima de procesamiento que no se puede dividir más.

Tomemos un ejemplo de una transacción simple. Suponga que un empleado del banco transfiere 500 rupias de la cuenta de A a la cuenta de B. Esta transacción muy simple y pequeña implica varias tareas de bajo nivel.

A’s Account

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Propiedades ACID

Una transacción es una unidad muy pequeña de un programa y puede contener varias tareas de bajo nivel. Una transacción en un sistema de base de datos debe mantenerAtomicidad Ccoherencia Isolación, y Ddurabilidad, comúnmente conocida como propiedades ACID, para garantizar la precisión, la integridad y la integridad de los datos.

Atomicity- Esta propiedad establece que una transacción debe tratarse como una unidad atómica, es decir, se ejecutan todas sus operaciones o ninguna. No debe haber ningún estado en una base de datos en el que una transacción se deje parcialmente completada. Los estados deben definirse antes de la ejecución de la transacción o después de la ejecución / aborto / falla de la transacción.
Consistency- La base de datos debe permanecer en un estado consistente después de cualquier transacción. Ninguna transacción debería tener un efecto adverso sobre los datos que residen en la base de datos. Si la base de datos estaba en un estado consistente antes de la ejecución de una transacción, también debe permanecer consistente después de la ejecución de la transacción.
Durability- La base de datos debe ser lo suficientemente duradera como para contener todas sus últimas actualizaciones incluso si el sistema falla o se reinicia. Si una transacción actualiza una parte de los datos en una base de datos y se confirma, la base de datos contendrá los datos modificados. Si una transacción se confirma pero el sistema falla antes de que los datos se puedan escribir en el disco, entonces esos datos se actualizarán una vez que el sistema vuelva a la acción.
Isolation- En un sistema de base de datos donde se está ejecutando más de una transacción simultáneamente y en paralelo, la propiedad de aislamiento establece que todas las transacciones se realizarán y ejecutarán como si fuera la única transacción en el sistema. Ninguna transacción afectará la existencia de cualquier otra transacción.

Serializabilidad

Cuando el sistema operativo está ejecutando varias transacciones en un entorno de multiprogramación, hay posibilidades de que las instrucciones de una transacción se intercalen con alguna otra transacción.

Schedule- Una secuencia de ejecución cronológica de una transacción se denomina programación. Una programación puede tener muchas transacciones, cada una de las cuales consta de una serie de instrucciones / tareas.
Serial Schedule- Es un cronograma en el que las transacciones se alinean de tal manera que una transacción se ejecuta primero. Cuando la primera transacción completa su ciclo, se ejecuta la siguiente. Las transacciones se ordenan una tras otra. Este tipo de programación se denomina programación en serie, ya que las transacciones se ejecutan en serie.

En un entorno de transacciones múltiples, los programas en serie se consideran un punto de referencia. La secuencia de ejecución de una instrucción en una transacción no se puede cambiar, pero dos transacciones pueden tener sus instrucciones ejecutadas de forma aleatoria. Esta ejecución no daña si dos transacciones son mutuamente independientes y funcionan en diferentes segmentos de datos; pero en caso de que estas dos transacciones estén trabajando con los mismos datos, los resultados pueden variar. Este resultado siempre variable puede llevar la base de datos a un estado inconsistente.

Para resolver este problema, permitimos la ejecución paralela de un programa de transacciones, si sus transacciones son serializables o tienen alguna relación de equivalencia entre ellas.

Horarios de equivalencia

Un esquema de equivalencia puede ser de los siguientes tipos:

Equivalencia de resultados

Si dos programas producen el mismo resultado después de la ejecución, se dice que son resultados equivalentes. Pueden producir el mismo resultado para algún valor y resultados diferentes para otro conjunto de valores. Es por eso que esta equivalencia generalmente no se considera significativa.

Ver equivalencia

Dos programas serían equivalentes de vista si las transacciones en ambos programas realizan acciones similares de manera similar.

Por ejemplo

Si T lee los datos iniciales en S1, entonces también lee los datos iniciales en S2.
Si T lee el valor escrito por J en S1, entonces también lee el valor escrito por J en S2.
Si T realiza la escritura final en el valor de datos en S1, entonces también realiza la escritura final en el valor de datos en S2.

Equivalencia de conflicto

Dos programas estarían en conflicto si tuvieran las siguientes propiedades:

Ambos pertenecen a transacciones separadas.
Ambos acceden al mismo elemento de datos.
Al menos uno de ellos es la operación de "escritura".

Se dice que dos programas que tienen múltiples transacciones con operaciones en conflicto son equivalentes en conflicto si y solo si:

Ambos programas contienen el mismo conjunto de transacciones.
El orden de los pares de operaciones en conflicto se mantiene en ambos programas.

Note- Ver programas equivalentes se puede ver en serie y los programas equivalentes en conflicto se pueden serializar en conflicto. Todas las programaciones serializables en conflicto también se pueden ver en serialización.

Estados de transacciones

Una transacción en una base de datos puede estar en uno de los siguientes estados:

Active- En este estado, la transacción se está ejecutando. Este es el estado inicial de cada transacción.
Partially Committed - Cuando una transacción ejecuta su operación final, se dice que está en un estado parcialmente comprometido.
Failed- Se dice que una transacción está en un estado fallido si falla alguna de las comprobaciones realizadas por el sistema de recuperación de la base de datos. Una transacción fallida ya no puede continuar.
Aborted- Si alguna de las comprobaciones falla y la transacción ha alcanzado un estado fallido, entonces el administrador de recuperación revierte todas sus operaciones de escritura en la base de datos para devolver la base de datos a su estado original donde estaba antes de la ejecución de la transacción. Las transacciones en este estado se denominan abortadas. El módulo de recuperación de la base de datos puede seleccionar una de las dos operaciones después de que se anula una transacción:
- Reiniciar la transacción
- Mata la transacción
Committed- Si una transacción ejecuta todas sus operaciones con éxito, se dice que está comprometida. Todos sus efectos están ahora establecidos de forma permanente en el sistema de base de datos.

En un entorno de multiprogramación donde se pueden ejecutar múltiples transacciones simultáneamente, es muy importante controlar la concurrencia de transacciones. Contamos con protocolos de control de concurrencia para garantizar la atomicidad, el aislamiento y la serialización de transacciones concurrentes. Los protocolos de control de simultaneidad se pueden dividir en dos categorías:

Protocolos basados en bloqueo
Protocolos basados en sellos de tiempo

Protocolos basados en bloqueos

Los sistemas de bases de datos equipados con protocolos basados en bloqueos utilizan un mecanismo mediante el cual ninguna transacción no puede leer o escribir datos hasta que adquiere un bloqueo adecuado. Las cerraduras son de dos tipos:

Binary Locks- Un bloqueo en un elemento de datos puede estar en dos estados; está bloqueado o desbloqueado.
Shared/exclusive- Este tipo de mecanismo de bloqueo diferencia las cerraduras en función de sus usos. Si se adquiere un bloqueo en un elemento de datos para realizar una operación de escritura, es un bloqueo exclusivo. Permitir que más de una transacción escriba en el mismo elemento de datos llevaría a la base de datos a un estado incoherente. Los bloqueos de lectura se comparten porque no se cambia ningún valor de datos.

Hay cuatro tipos de protocolos de bloqueo disponibles:

Protocolo de bloqueo simplista

Los protocolos simplistas basados en bloqueos permiten que las transacciones obtengan un bloqueo en cada objeto antes de que se realice una operación de "escritura". Las transacciones pueden desbloquear el elemento de datos después de completar la operación de "escritura".

Protocolo de bloqueo previo a la reclamación

Los protocolos de reclamación previa evalúan sus operaciones y crean una lista de elementos de datos en los que necesitan bloqueos. Antes de iniciar una ejecución, la transacción solicita al sistema todos los bloqueos que necesita de antemano. Si se otorgan todos los bloqueos, la transacción se ejecuta y libera todos los bloqueos cuando todas sus operaciones terminan. Si no se otorgan todos los bloqueos, la transacción se revierte y espera hasta que se otorguen todos los bloqueos.

Bloqueo de dos fases 2PL

Este protocolo de bloqueo divide la fase de ejecución de una transacción en tres partes. En la primera parte, cuando la transacción comienza a ejecutarse, busca permiso para los bloqueos que requiere. La segunda parte es donde la transacción adquiere todos los bloqueos. Tan pronto como la transacción libera su primer bloqueo, comienza la tercera fase. En esta fase, la transacción no puede exigir nuevos bloqueos; solo libera los bloqueos adquiridos.

El bloqueo de dos fases tiene dos fases, una es growing, donde todas las cerraduras están siendo adquiridas por la transacción; y la segunda fase se está reduciendo, donde se liberan los bloqueos mantenidos por la transacción.

Para reclamar un bloqueo exclusivo (escritura), una transacción primero debe adquirir un bloqueo compartido (lectura) y luego actualizarlo a un bloqueo exclusivo.

Bloqueo estricto de dos fases

La primera fase de Strict-2PL es la misma que 2PL. Después de adquirir todos los bloqueos en la primera fase, la transacción continúa ejecutándose normalmente. Pero a diferencia de 2PL, Strict-2PL no libera un bloqueo después de usarlo. Strict-2PL retiene todos los bloqueos hasta el punto de compromiso y libera todos los bloqueos a la vez.

Strict-2PL no tiene aborto en cascada como lo hace 2PL.

Protocolos basados en marcas de tiempo

El protocolo de concurrencia más utilizado es el protocolo basado en marcas de tiempo. Este protocolo utiliza la hora del sistema o un contador lógico como marca de tiempo.

Los protocolos basados en bloqueos administran el orden entre los pares en conflicto entre las transacciones en el momento de la ejecución, mientras que los protocolos basados en marcas de tiempo comienzan a funcionar tan pronto como se crea una transacción.

Cada transacción tiene una marca de tiempo asociada y el orden está determinado por la antigüedad de la transacción. Una transacción creada a la hora del reloj 0002 sería más antigua que todas las demás transacciones posteriores. Por ejemplo, cualquier transacción 'y' que ingrese al sistema en 0004 es dos segundos más temprana y se le daría prioridad a la anterior.

Además, cada elemento de datos recibe la última marca de tiempo de lectura y escritura. Esto le permite al sistema saber cuándo se realizó la última operación de "lectura y escritura" en el elemento de datos.

Protocolo de pedido de marca de tiempo

El protocolo de ordenación de marcas de tiempo garantiza la serialización entre transacciones en sus operaciones de lectura y escritura en conflicto. Es responsabilidad del sistema de protocolo que el par de tareas en conflicto se ejecuten de acuerdo con los valores de marca de tiempo de las transacciones.

La marca de tiempo de la transacción T _i se denota como TS (T _i ).
La marca de tiempo de lectura del elemento de datos X se indica mediante la marca de tiempo R (X).
La marca de tiempo de escritura del elemento de datos X se indica con la marca de tiempo W (X).

El protocolo de pedido de marca de tiempo funciona de la siguiente manera:

If a transaction Ti issues a read(X) operation −

Si TS (Ti) <W-marca de tiempo (X)
- Operación rechazada.
Si TS (Ti)> = W-marca de tiempo (X)
- Operación ejecutada.
Se actualizaron todas las marcas de tiempo de los elementos de datos.

If a transaction Ti issues a write(X) operation −

Si TS (Ti) <R-marca de tiempo (X)

Operación rechazada.

Si TS (Ti) <W-marca de tiempo (X)

Operación rechazada y Ti retrocedió.

De lo contrario, operación ejecutada.

Regla de escritura de Thomas

Esta regla establece si TS (Ti) <W-timestamp (X), entonces la operación se rechaza y T _i se revierte.

Las reglas de pedido de marca de tiempo se pueden modificar para que la vista de programación sea serializable.

En lugar de hacer que T _i retroceda, se ignora la operación de 'escritura' en sí.

En un sistema multiproceso, el interbloqueo es una situación no deseada que surge en un entorno de recursos compartidos, donde un proceso espera indefinidamente un recurso que está retenido por otro proceso.

Por ejemplo, suponga un conjunto de transacciones {T ₀ , T ₁ , T ₂ , ..., T _n }. T ₀ necesita un recurso X para completar su tarea. El recurso X está en manos de T ₁ , y T ₁ está esperando un recurso Y, que está en manos de T ₂ . T ₂ está esperando el recurso Z, que está retenido por T ₀ . Por lo tanto, todos los procesos se esperan unos a otros para liberar recursos. En esta situación, ninguno de los procesos puede finalizar su tarea. Esta situación se conoce como punto muerto.

Los interbloqueos no son saludables para un sistema. En caso de que un sistema se atasque en un punto muerto, las transacciones involucradas en el punto muerto se revierten o reinician.

Prevención de interbloqueo

Para evitar cualquier situación de punto muerto en el sistema, el DBMS inspecciona agresivamente todas las operaciones donde las transacciones están a punto de ejecutarse. El DBMS inspecciona las operaciones y analiza si pueden crear una situación de punto muerto. Si encuentra que puede ocurrir una situación de interbloqueo, nunca se permitirá que se ejecute esa transacción.

Existen esquemas de prevención de interbloqueo que utilizan un mecanismo de orden de marca de tiempo de las transacciones para predeterminar una situación de interbloqueo.

Esquema de esperar a morir

En este esquema, si una transacción solicita bloquear un recurso (elemento de datos), que ya está retenido con un bloqueo conflictivo por otra transacción, entonces puede ocurrir una de las dos posibilidades:

Si TS (T _i ) <TS (T _j ), es decir, T _i , que solicita un bloqueo en conflicto, es más antiguo que T _j , entonces T _i puede esperar hasta que el elemento de datos esté disponible.
Si TS (T _i )> TS (t _j ), es decir, T _i es más joven que T _j , entonces T _i muere. T _i se reinicia más tarde con un retraso aleatorio pero con la misma marca de tiempo.

Este esquema permite que la transacción anterior espere pero mata a la más joven.

Esquema de espera de heridas

En este esquema, si una transacción solicita bloquear un recurso (elemento de datos), que ya está retenido con un bloqueo conflictivo por otra transacción, puede ocurrir una de las dos posibilidades:

Si TS (T _i ) <TS (T _j ), entonces T _i fuerza a T _j a retroceder, es decir, T _i hiere a T _j . T _j se reinicia más tarde con un retraso aleatorio pero con la misma marca de tiempo.
Si TS (T _i )> TS (T _j ), entonces T _i se ve obligado a esperar hasta que el recurso esté disponible.

Este esquema permite que la transacción más joven espere; pero cuando una transacción más antigua solicita un artículo en poder de uno más joven, la transacción más antigua obliga al más joven a abortar y liberar el artículo.

En ambos casos, se aborta la transacción que ingresa al sistema en una etapa posterior.

Evitación del punto muerto

Abortar una transacción no siempre es un enfoque práctico. En su lugar, se pueden utilizar mecanismos de evitación de interbloqueo para detectar cualquier situación de interbloqueo por adelantado. Hay disponibles métodos como "gráfico de espera", pero son adecuados solo para aquellos sistemas donde las transacciones son ligeras y tienen menos instancias de recursos. En un sistema voluminoso, las técnicas de prevención de interbloqueos pueden funcionar bien.

Gráfico de espera

Este es un método simple disponible para rastrear si puede surgir una situación de interbloqueo. Por cada transacción que ingresa al sistema, se crea un nodo. Cuando una transacción T _i solicita un bloqueo en un artículo, digamos X, que está retenido por alguna otra transacción T _j , se crea un borde dirigido de T _i a T _j . Si T _j libera el elemento X, el borde entre ellos se elimina y T _i bloquea el elemento de datos.

El sistema mantiene este gráfico de espera para cada transacción en espera de algunos elementos de datos retenidos por otros. El sistema sigue comprobando si hay algún ciclo en el gráfico.

Aquí, podemos usar cualquiera de los dos enfoques siguientes:

Primero, no permita ninguna solicitud de un artículo que ya esté bloqueado por otra transacción. Esto no siempre es factible y puede causar inanición, donde una transacción espera indefinidamente un elemento de datos y nunca puede adquirirlo.
La segunda opción es revertir una de las transacciones. No siempre es factible revertir la transacción más reciente, ya que puede ser importante que la anterior. Con la ayuda de algún algoritmo relativo, se elige una transacción que debe abortarse. Esta transacción se conoce comovictim y el proceso se conoce como victim selection.

Pérdida de almacenamiento volátil

Un almacenamiento volátil como la RAM almacena todos los registros activos, búferes de disco y datos relacionados. Además, almacena todas las transacciones que se están ejecutando actualmente. ¿Qué sucede si un almacenamiento tan volátil se bloquea abruptamente? Obviamente eliminaría todos los registros y copias activas de la base de datos. Hace que la recuperación sea casi imposible, ya que se pierde todo lo necesario para recuperar los datos.

Se pueden adoptar las siguientes técnicas en caso de pérdida de almacenamiento de volátiles:

Podemos tener checkpoints en múltiples etapas para guardar el contenido de la base de datos periódicamente.
Un estado de base de datos activa en la memoria volátil puede ser periódicamente dumped en un almacenamiento estable, que también puede contener registros y transacciones activas y bloques de búfer.
<dump> se puede marcar en un archivo de registro, siempre que el contenido de la base de datos se descargue de una memoria no volátil a una estable.

Recuperación

Cuando el sistema se recupera de una falla, puede restaurar el último volcado.
Puede mantener una lista de rehacer y una lista de deshacer como puntos de control.
Puede recuperar el sistema consultando listas de deshacer-rehacer para restaurar el estado de todas las transacciones hasta el último punto de control.

Copia de seguridad y recuperación de la base de datos de fallas catastróficas

Una falla catastrófica es aquella en la que un dispositivo de almacenamiento secundario estable se daña. Con el dispositivo de almacenamiento, se pierden todos los datos valiosos que se almacenan en su interior. Tenemos dos estrategias diferentes para recuperar datos de una falla tan catastrófica:

Copia de seguridad remota y minu; Aquí se almacena una copia de seguridad de la base de datos en una ubicación remota desde donde se puede restaurar en caso de una catástrofe.
Alternativamente, las copias de seguridad de la base de datos se pueden realizar en cintas magnéticas y almacenar en un lugar más seguro. Esta copia de seguridad se puede transferir posteriormente a una base de datos recién instalada para llevarla al punto de copia de seguridad.

Las bases de datos adultas son demasiado voluminosas para realizar copias de seguridad con frecuencia. En tales casos, tenemos técnicas en las que podemos restaurar una base de datos con solo mirar sus registros. Entonces, todo lo que tenemos que hacer aquí es realizar una copia de seguridad de todos los registros a intervalos de tiempo frecuentes. Se puede realizar una copia de seguridad de la base de datos una vez a la semana, y los registros, que son muy pequeños, se pueden realizar todos los días o con la mayor frecuencia posible.

Copia de seguridad remota

La copia de seguridad remota proporciona una sensación de seguridad en caso de que se destruya la ubicación principal donde se encuentra la base de datos. La copia de seguridad remota puede estar fuera de línea, en tiempo real o en línea. En caso de que esté fuera de línea, se mantiene manualmente.

Los sistemas de respaldo en línea son más en tiempo real y son un salvavidas para los administradores e inversores de bases de datos. Un sistema de respaldo en línea es un mecanismo en el que cada bit de los datos en tiempo real se respalda simultáneamente en dos lugares distantes. Uno de ellos está conectado directamente al sistema y el otro se guarda en un lugar remoto como respaldo.

Tan pronto como falla el almacenamiento de la base de datos primaria, el sistema de respaldo detecta la falla y cambia el sistema del usuario al almacenamiento remoto. A veces, esto es tan instantáneo que los usuarios ni siquiera pueden darse cuenta de una falla.

Recuperación de accidentes

DBMS es un sistema muy complejo con cientos de transacciones que se ejecutan cada segundo. La durabilidad y solidez de un DBMS depende de su compleja arquitectura y su hardware y software de sistema subyacentes. Si falla o se bloquea en medio de transacciones, se espera que el sistema siga algún tipo de algoritmo o técnicas para recuperar los datos perdidos.

Clasificación de fallas

Para ver dónde ha ocurrido el problema, generalizamos una falla en varias categorías, de la siguiente manera:

Error de transacción

Una transacción tiene que abortar cuando no se ejecuta o cuando llega a un punto en el que no puede continuar. Esto se denomina error de transacción cuando solo se ven afectadas algunas transacciones o procesos.

Las razones de una transacción fallida podrían ser:

Logical errors - Cuando una transacción no se puede completar porque tiene algún error de código o alguna condición de error interno.
System errors- Donde el propio sistema de base de datos finaliza una transacción activa porque el DBMS no puede ejecutarla, o tiene que detenerse debido a alguna condición del sistema. Por ejemplo, en caso de punto muerto o falta de disponibilidad de recursos, el sistema aborta una transacción activa.

Fallo del sistema

Hay problemas, externos al sistema, que pueden hacer que el sistema se detenga abruptamente y provoque un bloqueo. Por ejemplo, las interrupciones en el suministro de energía pueden causar la falla del hardware o software subyacente.

Los ejemplos pueden incluir errores del sistema operativo.

Fallo de disco

En los primeros días de la evolución de la tecnología, era un problema común donde las unidades de disco duro o unidades de almacenamiento solían fallar con frecuencia.

Las fallas de disco incluyen la formación de sectores defectuosos, la imposibilidad de acceder al disco, el bloqueo del cabezal del disco o cualquier otra falla, que destruye todo o una parte del almacenamiento del disco.

Estructura de almacenamiento

Ya hemos descrito el sistema de almacenamiento. En resumen, la estructura de almacenamiento se puede dividir en dos categorías:

Volatile storage- Como sugiere el nombre, un almacenamiento volátil no puede sobrevivir a las fallas del sistema. Los dispositivos de almacenamiento volátiles se colocan muy cerca de la CPU; normalmente están incrustados en el propio chipset. Por ejemplo, la memoria principal y la memoria caché son ejemplos de almacenamiento volátil. Son rápidos pero solo pueden almacenar una pequeña cantidad de información.
Non-volatile storage- Estos recuerdos están hechos para sobrevivir a fallas del sistema. Son enormes en capacidad de almacenamiento de datos, pero más lentos en accesibilidad. Los ejemplos pueden incluir discos duros, cintas magnéticas, memoria flash y RAM no volátil (con respaldo de batería).

Recuperación y atomicidad

Cuando un sistema falla, es posible que se ejecuten varias transacciones y se abran varios archivos para modificar los elementos de datos. Las transacciones se realizan a partir de varias operaciones, que son de naturaleza atómica. Pero de acuerdo con las propiedades ACID del DBMS, se debe mantener la atomicidad de las transacciones en su conjunto, es decir, se ejecutan todas las operaciones o ninguna.

Cuando un DBMS se recupera de un accidente, debe mantener lo siguiente:

Debería comprobar el estado de todas las transacciones que se estaban ejecutando.
Una transacción puede estar en medio de alguna operación; el DBMS debe garantizar la atomicidad de la transacción en este caso.
Debe comprobar si la transacción se puede completar ahora o si debe revertirse.
No se permitiría ninguna transacción para dejar el DBMS en un estado inconsistente.

Hay dos tipos de técnicas que pueden ayudar a un DBMS a recuperar y a mantener la atomicidad de una transacción:

Mantener los registros de cada transacción y escribirlos en un almacenamiento estable antes de modificar la base de datos.
Mantener la paginación en la sombra, donde los cambios se realizan en una memoria volátil y, posteriormente, se actualiza la base de datos real.

Recuperación basada en registros

El registro es una secuencia de registros que mantiene los registros de las acciones realizadas por una transacción. Es importante que los registros se escriban antes de la modificación real y se almacenen en un medio de almacenamiento estable, que es seguro.

La recuperación basada en registros funciona de la siguiente manera:

El archivo de registro se guarda en un medio de almacenamiento estable.
Cuando una transacción ingresa al sistema y comienza la ejecución, escribe un registro sobre ella.

<T_n, Start>

Cuando la transacción modifica un artículo X, escribe registros de la siguiente manera:

<T_n, X, V₁, V₂>

Lee T _n ha cambiado el valor de X, de V ₁ a V ₂ .

Cuando finaliza la transacción, se registra:

<T_n, commit>

La base de datos se puede modificar utilizando dos enfoques:

Deferred database modification - Todos los registros se escriben en el almacenamiento estable y la base de datos se actualiza cuando se confirma una transacción.
Immediate database modification- Cada registro sigue una modificación real de la base de datos. Es decir, la base de datos se modifica inmediatamente después de cada operación.

Recuperación con transacciones concurrentes

Cuando se ejecuta más de una transacción en paralelo, los registros se intercalan. En el momento de la recuperación, sería difícil para el sistema de recuperación retroceder todos los registros y luego comenzar a recuperarse. Para aliviar esta situación, la mayoría de los DBMS modernos utilizan el concepto de "puntos de control".

Control

Mantener y mantener registros en tiempo real y en un entorno real puede llenar todo el espacio de memoria disponible en el sistema. A medida que pasa el tiempo, el archivo de registro puede crecer demasiado para poder manipularse. Checkpoint es un mecanismo en el que todos los registros anteriores se eliminan del sistema y se almacenan permanentemente en un disco de almacenamiento. Checkpoint declara un punto antes del cual el DBMS estaba en un estado consistente y todas las transacciones fueron confirmadas.

Recuperación

Cuando un sistema con transacciones concurrentes falla y se recupera, se comporta de la siguiente manera:

El sistema de recuperación lee los registros al revés desde el final hasta el último punto de control.
Mantiene dos listas, una lista para deshacer y una lista para rehacer.
Si el sistema de recuperación ve un registro con <T _n , Start> y <T _n , Commit> o simplemente <T _n , Commit>, coloca la transacción en la lista de rehacer.
Si el sistema de recuperación ve un registro con <T _n , Inicio> pero no se encuentra ningún registro de confirmación o aborto, coloca la transacción en la lista de deshacer.

Todas las transacciones de la lista de deshacer se deshacen y sus registros se eliminan. Todas las transacciones en la lista de rehacer y sus registros anteriores se eliminan y luego se rehacen antes de guardar sus registros.