diff --git a/fbd/apuntes.md b/fbd/apuntes.md index 40e4fd9..6bab8f0 100644 --- a/fbd/apuntes.md +++ b/fbd/apuntes.md @@ -50,18 +50,18 @@ operativos, se obtiene el **esquema lógico** de la base de datos. ## Ventajas de utilizar un SGBD -Para el usuario: +Para el **usuario**: - **Usuario final**: puede acceder a los datos. - **Programador de aplicaciones**: eliminar problemas de diseño lógico y físico, depuración de errores y mantenimiento general. - **Administrador de BD**: no existiría. -Para el sistema: +Para el **sistema**: -- **Control centralizado**: fiabilidad, consistencia, seguridad... -- **Criterios de uniformación**. -- **Generación de nuevas aplicaciones**. -- **Equilibrio entre requerimientos conflictivos**. +- Control centralizado (fiabilidad, consistencia, seguridad...) +- Criterios de uniformación +- Generación de nuevas aplicaciones +- Equilibrio entre requerimientos conflictivos. ## Concepto de independencia @@ -90,6 +90,7 @@ que le son necesarios y le conciernen. La independencia lógica persigue que los ## Una arquitectura con tres niveles **¿Por qué organizar en niveles?** + Los usuarios pueden acceder a los mismos datos desde distintas perspectivas. Si un usuario cambia la forma de ver los datos no influye al resto. @@ -102,6 +103,8 @@ representación física de los datos. El administrador de la base de datos puede cambiar la forma de representar los datos sin influir en los usuarios. +### Arquitectura ANSI/SPARC + La percepción de los datos en un SGBD puede hacerse siguiendo tres niveles de abstracción: @@ -116,6 +119,9 @@ una visión global de los datos pero ningún detalle de almacenamiento. particulares de la BD por parte de los usuarios. Cada usuario puede tener su propia visión de la BD. +

+![](./img/T2/D8.png) +

## Correspondencia entre niveles @@ -143,6 +149,12 @@ Esta transformación no siempre es posible - Cambia la correspondencia - No varía el esquema externo dependiente +En el siguiente dibujo, si quisiéramos hacer una correspondencia externa/externa pondríamos un esquema que sale del esquema N. + +

+![](./img/T2/D14.png) +

+ ## Lenguajes de una BD **Recomendación ANSI/SPARC**: disponer de un lenguaje específico orientado a los datos (definición, control, manipulación). Sublenguaje de datos (DSL) implementado en el propio SGBD. Tiene distintas partes: @@ -171,7 +183,9 @@ La industria ha seguido un camino diferente: lenguajes de datos estándares. El ejemplo más destacado es SQL: SQL89, SQL92 y SQL3. -**Lenguaje anfitrión o de aplicación**: desarrollo de aplicaciones en el SO que trabajen sobre la BD. El propósito general es C/C++, Java, C#. Las herramientas de desarrollo específicas son Developer de Oracle, Oracle Application Express (Oracle APEX), Sybase PowerBuilder, IBM Rational Application Developer... Además, proporciona procesamiento avanzado de datos y gestión de la interfaz de usuario. Hay que establecer un mecanismo para traducir: estructuras de datos y operaciones. Acoplamiento: +**Lenguaje anfitrión o de aplicación**: desarrollo de aplicaciones en el SO que trabajen sobre la BD. El propósito general es C/C++, Java, C#. Las herramientas de desarrollo específicas son Developer de Oracle, Oracle Application Express (Oracle APEX), Sybase PowerBuilder, IBM Rational Application Developer... Además, proporciona procesamiento avanzado de datos y gestión de la interfaz de usuario. + +Hay que establecer un mecanismo para traducir: estructuras de datos y operaciones. Acoplamiento: - **Débilmente acoplados** (si se pueden distinguir): - Lenguajes de propósito general @@ -231,15 +245,15 @@ Ejemplo de Gestión Docente Universitaria: ```txt Profesor = registro de -NRP -campo alfanumérico de 10 caracteres, -Apellidos campo alfanumérico de 30 caracteres, -Nombre -campo alfanumérico de 20 caracteres, -Sueldo -campo decimal de 8+2 dígitos, -Departamento -campo alfanumérico de 30 caracteres + NRP + campo alfanumérico de 10 caracteres, + Apellidos campo alfanumérico de 30 caracteres, + Nombre + campo alfanumérico de 20 caracteres, + Sueldo + campo decimal de 8+2 dígitos, + Departamento + campo alfanumérico de 30 caracteres fin Profesor. ``` @@ -280,6 +294,7 @@ Profesor_interno BYTES=74 Departamento TYPE=BYTES(10),OFFSET=64 ``` +>SQL: dcl, dml, ddl? ## El administrador de la BD @@ -322,6 +337,12 @@ centrales. El usuario accedía mediante terminales. En el ordenador principal se encontraban el SGBD y los programas de aplicación. +La **arquitectura centralizada** es la siguiente. + +

+![](./img/T2/D39.png) +

+ El principal problema de este sistema es el elevado coste de los ordenadores principales con la aparición del PC. La solución fue desplazar la ejecución de los programas de usuario y las interacciones hasta los PCs (reducción de costes en hardware). Surge la primera aproximación **cliente/servidor**. El servidor alojaba la base de datos y un servicio @@ -331,6 +352,12 @@ enlace cliente que interactúa con el servicio de escucha instalado en el servidor. Con el desarrollo de las comunicaciones este enfoque deriva en un enfoque distribuido. +La **arquitectura distribuida y cliente/servidor** es la siguiente. + +

+![](./img/T2/D42.png) +

+ El principal problema es el alto coste del mantenimiento de los PCs (instalación, configuración y actualización), que se soluciona separando en las aplicaciones: la parte que interactúa con el usuario (interfaz) de la parte de ejecución lógica del programa. Actualmente se utiliza una arquitectura articulada entre niveles de @@ -348,214 +375,243 @@ procesamiento. aplicaciones. Menos dependencia del hardware y SO a la hora de abordar la ejecución de las aplicaciones. +BD distribuida y programas de aplicación en arquitectura de 3 capas: -**Ventajas**: reducción significativa en cuanto al mantenimiento de los -clientes. Mayor facilidad y flexibilidad para el usuario. +

+![](./img/T2/D47.png) +

+ +**Ventajas**: reducción significativa en cuanto al mantenimiento de los clientes: instalación, +configuración y actualización de las aplicaciones realizada en el servidor, no en +cada cliente. Mayor facilidad y flexibilidad para el usuario. Puede acceder desde casi cualquier +puesto y desde distintos dispositivos: móviles, tablets, portátil, pc, etc. **Inconvenientes**: mayor complejidad en la configuración y administración de los servidores de aplicaciones. El desarrollo de las aplicaciones conforme a este modelo distribuido es más costoso. -\newpage +Ejemplo: + +Usuario del PC invoca desde el navegador la ejecución de una aplicación a través de una URL. La parte de interfaz de usuario de la aplicación se puede distribuir como: + +- Un applet Java que se ejecuta en la máquina virtual del navegador +- Una serie de paginas HTML generadas desde el servidor de aplicaciones: + - Servlets + - JSP + - ASP +La interacción del usuario a través de esta interfaz determina la interacción con la parte +lógica de la aplicación que se ejecuta en el servidor de aplicaciones: + +- Peticiones de procesamiento +- Acceso a datos de la BD +- Generación de nuevas páginas o evolución del applet que ofrecen la respuesta al usuario a través de la interfaz de usuario. + +\newpage # Tema 3. Modelos de datos -## Cocepto de modelo de datos +## Definición de modelo de datos -Modelo de datos es el mecanismo formal para representar y manipular -información de manera general y sistemática. Debe costar de: +Un **modelo de datos** es el mecanismo formal para representar y manipular +información de manera general y sistemática. Debe constar de: 1. Notación para describir datos. 2. Notación para describir operaciones. 3. Notación para describir reglas de integridad. -Objetivo: describir modelos que representen los datos y los describan -de una forma entendible y manipulable. En relación a la arquitectura -ANSI/SPARC: +Modelo lógico: trasladamos a un esquema lógico en función de una estructura implementable. -- Nivel externo: modelo de datos externo. -- Nivel conceptual: modelo de datos conceptual. -- Nivel interno: modelo de datos interno. +

+![](./img/T3/D6.png) +

-Clasificación: +Hay necesidad de modelo de datos, ya que cada esquema se describe utilizando un lenguaje de definición de datos. Este lenguaje es de muy bajo nivel, está muy ligado al SGBD. Hacen falta otros mecanismos de más alto nivel que permitan describir datos de una forma no ambigua y entendible por los usuarios en cada paso del proceso de implantación. -- Basados en registros. -- Basados en objetos. -- Físicos. +El **objetivo** es describir modelos que representen los datos y los describan de una forma entendible y manipulable. En relación con la arquitectura **ANSI/SPARC**: -Utilización: +- **Nivel externo**: modelo de datos externo. +- **Nivel conceptual**: modelo de datos conceptual. +- **Nivel interno**: modelo de datos interno. -- Basados en registros y objetos: nivel externo y conceptual. -- Físicos: nivel interno. +La **clasificación** es la siguiente: -## Modelos de datos basados en registros +- **Basados en registros**: se usan para el nivel externo y conceptual. +- **Basados en objetos**: se usan para el nivel externo y conceptual. +- **Físicos**: se usan para el nivel interno. -### Modelo jerárquico -Fue el primero en implementarse físicamente. Carecía de lenguaje de -consulta. La estructura de datos básica es el árbol. La base de datos -es una colección instanciada de árboles. Esta estructura plasma de -forma muy directa relaciones muchos a uno y relaciones uno a uno, pero -necesita duplicar información para las relaciones muchos a muchos. +Los **modelos de datos basados en registros** son: -Inconvenientes: +- Modelo de datos **jerárquico** +- Modelo de datos en **red** +- Modelo de datos **relacional** -- Almacenar árboles en un fichero es complejo. Varios tipos de - registros y punteros que hay que mantener. -- DML difícil de implementar y usar. -- Dependencia existencial obligatoria de los registros de tipo - secundario con respecto a los de tipo raíz. -- Redundancia necesaria para plasmar relaciones muchos a muchos. -### Modelo en red -La estructura de datos consiste en grafos cuya topología depende de -las conexiones existentes entre las entidades: +## Modelo de datos relacional -- Nodos: registros -- Arcos: enlaces entre registros (punteros) -- Relaciones entre conjuntos de entidades: conectores (registros - especiales). Cada ocurrencia de un conector representa una - asociación distinta. +### Estructura de datos -La base de datos es una colección de instancias de grafos. La -estructura es muy genérica. Permite plasmar todo tipo de relaciones e -implementar directamente las relaciones muchos a muchos. +El **modelo de datos** relacional organiza y representa los datos en forma +de tablas o relaciones. -Ventajas: +Una **base de datos relacional** es una colección de tablas cada una de las cuales tiene un nombre único. -- Estructura más homogénea. -- Permite insertar nuevas entidades en un conjunto de forma - independiente. +Un **esquema de una base de datos relacional** es una colección de esquemas de relaciones junto con restricciones de integridad. -Problemas: +Una **instancia o estado de una base de datos** es una colección de instancias de relaciones que verifican las restricciones de integridad. -- La existencia de enlaces entre los registros hace que las - operaciones DDL y el DML sigan siendo complejas de implementar y - utilizar. +Una **base de datos relacional** es una instancia de una base de datos junto con su esquema. -### Modelo relacional -El modelo de datos relacional organiza y representa los datos en forma -de tablas o relaciones. Una base de datos relacional es una colección -de tablas cada una de las cuales tiene un nombre único. +El modelo de datos relacional abarca tres ámbitos distintos: -**Definiciones**: +- **Las estructuras para almacenarlos**: el usuario recibe la información + de la base de datos estructurada en tablas. +- **La integridad**: las tablas deben satisfacer ciertas condiciones que + preservan la integridad y la coherencia de la información que + contienen. +- **Consulta y manipulación**: los operadores empleados por el modelo se + aplican sobre tablas y devuelven tablas. -Esquema de una base de datos relacional: colección de esquemas de -relaciones junto con restricciones de integridad. +Algunas definiciones: -Instancia o estado de una base de datos: colección de instancias de -relaciones que verifican las restricciones de integridad. +- **Tabla** es la estructura lógica de un sistema relacional. A nivel +físico, el sistema es libre de almacenar los datos en el formato más +adecuado (archivo secuencial, archivo indexado, lista con +apuntadores...). -Base de datos relacional: instancia de una base de datos junto con su -esquema. +- **Atributo**: cualquier elemento de información susceptible de tomar +valores. Notación: $A_i$, $i = 1, 2...$ + +- **Dominio**: rango de valores donde toma sus datos un atributo. Se considera finito. Notación: $D_i$, $i = 1, 2...$ + +- **Relación**: dados los atributos $A_i$, $i = 1, 2, ..., n$, con dominios +$Di$, $i = 1, 2, ..., n$ no necesariamente distintos, definimos la +relación asociada a $A_1, ..., A_n$, y lo notaremos como $R(A_1, ..., +A_n)$ a cualquier subconjunto de productos cartesianos $D_1 x ... x +D_n$. -**Claves**: +- **Tupla**: cada una de las filas de la relación. -- **Superclave**: cualquier conjunto de atributos que identifica - unívocamente a cada tupla de la relación. +- **Cardinalidad de una relación**: número de tuplas que contiene. Es +variable en el tiempo. -- **Clave candidata**: superclave minimal. +- **Grado de una relación**: número de atributos de su esquema. Invariable +en el tiempo (hasta que lo cambiamos nosotros). -- De entre las candidatas (si hubiera más de una) hay que elegir una - como principal que se denomina **clave primaria**. +- **Esquema de una relación R**: Atributos $A_1: D_1,..., A_n:D_n$ -Para describir una relación, se subrayan los atributos que forman su -clave primaria. +- **Instancia de una relación**: conjunto de tuplas {($x_1, ..., x_n$)} $\subset D_1 x ... x D_n$ que la componen en cada momento. -# Tema 4. El modelo de datos relacional -## La estructura de datos relacional +Las **propiedades** de la estructura de datos relacional son: -Introducido por E. F. Codd en 1970. El modelo de datos relacional -abarca tres ámbitos distintos: +- **Condición de normalización**: todos los valores de los atributos de una +relación son atómicos. El valor atómico es un valor no +estructurado. Cuando una relación cumple la primera condición de +normalización se dice que está en **Primera Forma Normal**. -- Las estructuras para almacenarlos. El usuario recibe la información - de la base de datos estructurada en tablas. -- La integridad: las tablas deben satisfacer ciertas condiciones que - preservan la integridad y la coherencia de la información que - contienen. -- Consulta y manipulación: los operadores empleados por el modelo se - aplican sobre tablas y devuelven tablas. +- **Consecuencias**: no hay valores tipo conjunto, tipo registro ni tipo tabla. -La tabla es la estructura lógica de un sistema relacional. A nivel -físico, el sistema es libre de almacenar los datos en el formato más -adecuado(archivo secuencial, archivo indexado, lista con -apuntadores...). +- **Problema**: todas las representaciones son extensivas, no se puede representar directamente información del tipo "el valor del atributo asignaturas de un alumno es: (FBD, ALG, LD)". -Atributo: cualquier elemento de información susceptible de tomar -valores -Dominio: rango de valores donde toma sus datos un atributo. -Relación: dados los atributos $A_i, i = 1, 2, ..., n$, con dominios -$Di, i = 1, 2, ..., n$ no necesariamente distintos, definimos la -relación asociada a $A_1, ..., A_n$, y lo notaremos como $R(A_1, ..., -A_n)$ a cualquier subconjunto de productos cartesianos $D_1 x ... x -D_n$. +Las **consecuencias de la definición** son: -Tupla: cada una de las filas de la relación. -Cardinalidad de una relación: número de tuplas que contiene. Es -variable en el tiempo. -Grado de una relación: número de atributos de su esquema. Invariable -en el tiempo. -Esquema de una relación R: Atributos A1: D1,..., A:Dn -Instancia de una relación: conjunto de tuplas que la componen en cada -momento. - -## Propiedades de la estructura de datos relacional: -Condición de normalización. Todos los valores de los atributos de una -relación son atómicos. Valor atómico es un valor no -estructurado. Cuando una relación cumple la primera condición de -normalización se dice que está en Primera Forma Normal. Consecuencias: -no hay valores tipo conjunto, tipo registro o tipo tabla. Problema: -todas las representaciones son extensivas. Consecuencias de la -definición: no hay tuplas duplicadas, no hay orden en las filas ni en -los atributos, varias instancias representan la misma relación. +- No hay tuplas duplicadas, por la definición conjuntista de relación (no hay tuplas con el mismo valor). + +- No hay orden en las filas ni en los atributos, al no estar ordenados ni los atributos ni las filas (conjuntos) el acceso es por Nombre de Atributo y Valor. +- Varias instancias representan la misma relación. + + +| Representación física | Representación intuitiva | Modelo matemático | +|---|---|---| +| Archivo secuencial | Tabla | Relación | +| Registros | Filas | Tuplas | +| Campos | Columnas | Valores atributos | -Esquema de una base de datos relacional: colección de esquemas de + +- **Esquema de una base de datos relacional**: colección de esquemas de relaciones junto con restricciones de integridad. -Instancia o estado de una base de datos: colección de instancias de +- **Instancia o estado de una base de datos**: colección de instancias de relaciones que verifican las restricciones de integridad. -Base de datos relacional: instancia de una base de datos junto con su +- **Base de datos relacional**: instancia de una base de datos junto con su esquema. +La notación que vamos a usar es: + +- Relación: $R,S, T...$ +- Atributos: $A,B,...$ +- Esquema de relación: $R[A_1 ,...,A_n ]$ +- Instancia de relación $R: r...$ +- Tuplas de una instancia: $x_1, x_2... \in r$ +- Valor de un atributo $A_i$ en una tupla $x_j : x_j [A_i ]$ ó $A_{ij}$ + Algunas veces no se conoce el valor de un atributo de determinada -tupla. En esos casos a ese atributo de esa tupla se le asigna un valor -nulo. Un valor nulo puede ser un valor desconocido o un atributo no +tupla. En esos casos a ese atributo de esa tupla se le asigna un **valor +nulo**. Un valor nulo puede ser un valor desconocido o un atributo no aplicable. En cualquier caso, ese valor es un valor común a todos los dominios de la base de datos. -## Restricciones de integridad -En una relación puede haber más de un conjunto de atributos que puedan +### Restricciones de integridad + +Restricciones o reglas de integridad son condiciones para preservar la semántica de una base de datos. Específicas del problema: 0 $\leq$ edad $\leq$ 100, créditos >0, carácter $\in$ ('troncal', 'obligatoria', 'optativa'...). + +Propias del papel de los atributos en el esquema: + +- imparte.NRP $\in$ profesor.NRP (un profesor inexistente no puede impartir una asignatura). +- cod_asig != nulo (siempre debe conocerse el código de una asignatura). + +Una **superclave** es cualquier conjunto de atributos que identifica unívocamente a cada tupla de una relación. En una relación puede haber más de un conjunto de atributos que puedan ser elegidos como clave. Estos conjuntos se llaman claves -candidatas. Una clave candidata es un atributo o conjunto de -atributos que identifican a cada tupla en la relación y que, además, +candidatas. Una **clave candidata** (superclave minimal) es un atributo o conjunto de atributos que identifican a cada tupla en la relación y que, además, no existe un subconjunto de ellos que también identifiquen a la tupla -en la relación. Una clave primaria es una clave candidata elegida por -el diseñador. Si se verifica la unicidad pero no la minimalidad se -denomina superclave. +en la relación. Es decir, sea R[$A_1,...,A_n$], PK $\cup${$A_1,...,$A_n$} se denomina clave candidata sii: + +- Unicidad: $\forall$r instancia de R y $\forall t_1, t_2 \in r \; t_1 \neq t_2 \rightarrow t_1[PK] \neq t_2[PK]$. +- Minimalidad: no existe PK' $\cup$ PK que verifique la unicidad. + -Condiciones de integridad: normas que mantienen la corrección -semántica de una base de datos. Son metarreglas (generan reglas de +Ejemplo: + +- Relación Trabajadores + - {id_trabajador, nombre} - superclave. + - No es minimal: no es clave de la relación. +- Por ejemplo, en la relación Asignaturas, el conjunto de atributos {Cod_Asig, Nombre} identifica unívocamente cada tupla. Sin embargo, no es minimal y no puede considerarse como una clave. Cod_Asig por sí solo, es una clave. + + +Una **clave primaria** es una clave candidata elegida por +el diseñador (criterio de selección: tamaño, significado, capacidad para recordarla, fusión con otras tablas...). Si PK verifica la unicidad pero no la minimalidad se denomina **superclave**. + +**Condiciones de integridad**: normas que mantienen la corrección +semántica de una base de datos. Nos centramos en la Integridad Genérica (depende del papel que juegue un atributo en el diseño de la tabla). Son metarreglas (generan reglas de integridad aplicadas a una base de datos concreta). Existen la integridad de entidad y la referencial. -Integridad de entidad: no se debe permitir que una entidad sea +**Integridad de entidad**: no se debe permitir que una entidad sea representada en la base de datos si no se tienen una información -completa de los atributos que son claves de la entidad. Clave primaria +completa de los atributos que son claves de la entidad. La clave primaria o parte de ella no puede ser valor nulo. -Clave externa: un conjunto de atributos en una relación que es una +Un atributo que forma parte de la clave primaria de una tupla en +una relación no puede tener un valor nulo. + +**Clave externa**: un conjunto de atributos en una relación que es una clave en otra (o en la misma) relación. Podemos ver una clave externa como un conjunto de atributos de una relación cuyos valores en las tuplas deben coincidir con los valores de la clave primaria de las -tuplas de otra relación. Si PK es la clave primaria de R y FK la clave -externa de S con respecto a R verifica que el dominio activo de FK -debe estar incluido en el dominio activo de PC para cualquier -instancia de la base de datos. +tuplas de otra relación. Es decir, sean R[$A_1,...,A_n$] y PK $\cup${$A_1,...,$A_n$} su clave primaria, sea S[B1,...,Bn] y FK $\cup${B1,...,Bn} de manera que card(PK)=card(FK). FK es clave externa de S con respecto a R si se verifica: + +$\forall$ r instancia de R y $\forall$ s instancia de S, $\forall$ x $\in x \Rightarrow \exists y \in r : x[FK]=y[PK]$ + +Es decir, que el dominio activo de FK debe estar incluido en el dominio activo de PK para cualquier instancia de la base de datos. + +

+![](./img/T3/D33.png) +

-Integridad referencial: una base de datos en la que todos los valores +**Integridad referencial**: una base de datos en la que todos los valores no nulos de una clave externa referencian valores reales de la clave referenciada en la otra relación cumple la regla de integridad referencial. Si una relación incluye una clave externa conectada a una @@ -564,433 +620,723 @@ valor ya existente en el dominio activo de la clave primaria o bien completamente nulo (si la semántica lo permite). La integridad referencial mantiene las conexiones entre las bases de datos relacionales. Puede haber más de una clave externa en una relación, y -más de una clave externa a la clave primaria de la propia relación. +más de una clave externa a la clave primaria de la propia relación. Ejemplo: -El SGBD debe encargarse de mantener las siguientes restricciones: +

+![](./img/T3/D35.png) +

-- La unicidad de la clave primaria y las claves candidatas. -- La restricción de integridad de identidad. -- La integridad referencial: - - En inserción: rechazar tuplas insertadas si el valor de la clave +El **SGBD** debe encargarse de mantener las siguientes restricciones: + +- **La unicidad de la clave primaria y las claves candidatas**: frente a operaciones de Inserción y Actualización, el SGBD debe rechazar los valores +introducidos que sean iguales a los presentes en la BD para los atributos que el diseñador ha definido como clave primaria y como claves candidatas. +- **La restricción de integridad de identidad**: frente a operaciones de Inserción y Actualización, el SGBD debe rechazar las modificaciones +que vulneren la unicidad en la clave primaria y/o que asignen un valor NULO a algún atributo de la clave primaria. +- **La integridad referencial**: + - En **inserción**: rechazar tuplas insertadas si el valor de la clave externa no concuerda en la relación referenciada para alguna tupla en el valor de su clave primaria. Si el valor para la clave externa es nulo y el diseño no lo permite habrá que rechazar también esa inserción. - - En actualización: si se actualiza la clave externa, rechazar la + - En **actualización**: si se actualiza la clave externa, rechazar la modificación si se producen alguna de las circunstancias descritas en el punto anterior. Si se actualiza la clave primaria de la relación referenciada se deben actualizar en cadena las claves externas que la referencian. - - En borrado: si se borran la clave primara de la relación + - En **borrado**: si se borran la clave primara de la relación referenciada, se debe borrar en cadena todas las tuplas que la referencian o poner valor nulo en la clave externa de todas esas tuplas. -# Tema 5. Nivel Interno + +## Otros modelos de datos + +### Modelo jerárquico + +Fue el primero en implementarse físicamente. En el nivel externo hay aplicaciones Cobol. No había interactividad ya que carecía de un lenguaje de consulta. + +La estructura de datos era básica usando un árbol con registros maestros y secundarios. + +La BD es una colección de instancias de árboles. + +

+![](./img/T3/D41.png) +

+ +Esta estructura plasma de forma muy directa relaciones muchos a uno y relaciones uno a uno. + +En las relaciones muchos a muchos hay que duplicar toda la información sobre las entidades involucradas. + +

+![](./img/T3/D43.png) +

+ +Inconvenientes: + +- Almacenar árboles en ficheros es complejo: hay varios tipos de registro y hay que mantener los punteros. +- DML difícil de implementar y usar. +- Dependencia existencial obligatoria de los registros de tipo secundario con respecto a los de tipo raíz: no se podrá insertar un registro de tipo secundario mientras no exista uno de tipo raíz con el que enlazarlo. +- Redundancia necesaria para plasmar relaciones muchos a muchos: la integridad de los datos es costosa de mantener. + +### Modelo en Red + +Estructura de datos: + +- Grafos cuya topología depende de las conexiones existentes entre las entidades. Tiene: + - Nodos: registros. + - Arcos: enlaces entre registros (punteros). + - Relaciones entre conjuntos de entidades: + - Conectores: registros especiales (atributos propios de la relación). + - Cada ocurrencia de un conector representa una asociación distinta. + - Cualquier registro puede relacionarse con cualquier registro +- Base de datos: colección de instancias de grafos +- La estructura es muy genérica: + - Permite plasmar todo tipo de relaciones + - Implementa directamente las relaciones muchos a muchos + +

+![](./img/T3/D46.png) +

+ + +Ventajas: + +- Estructura algo más homogénea. +- Permite insertar nuevas entidades en un conjunto de forma independiente. + +Problemas: + +- La existencia de enlaces entre los registros hace que las operaciones del DDL y el DML sigan siendo complejas de implementar y utilizar. + +### Comparativa + +- Con respecto a la representación: + - **Relacional**. + - Un solo elemento para la representación (esencialidad). + - Conexiones lógicas. + - Representación relaciones n:m simétrica. + - Identidad por valor. + - **Basado en grafos**. + - Dos elementos para la representación. + - Conexiones en el modelo físico subyacente. + - Representación conexiones n:m, imposible en modelos jerárquicos y difícil en modelos en red. + - Identidad por posición. +- Con respecto a la consulta: + - **Relacional**. + - Consultas simétricas en jerarquías. + - Obtención de la consulta como resultado global. + - Lenguajes declarativos. + - **Basados en grafos**. + - Consultad no simétricas en jerarquías. + - Mecanismo de navegación por punteros. + - Lenguajes procedimentales. + +### Orientación a objetos + +**Debilidades** de los SGDB relacionales: + +- **Pobre representación** de las entidades del mundo real. +- **Sobrecarga semántica** de la estructura básica: la relación. +- La estructura relacional es muy **estricta**: + - Todas las **tuplas** (filas) han de tener los mismos atributos. + - Los **valores** de un atributo (columna) pertenecen al mismo dominio. + - **Atributos** han de tener un valor atómico. +- SQL permite un conjunto de **operaciones limitado**. No permite modelar el comportamiento de muchos objetos del mundo real. +- Object-relational impedance mismatch. + +La filosofía del modelado orientado a objetos es abstraer un modelo de la realidad en forma de conjunto de objetos que interaccionan entre sí por medio de mensajes. + +Conceptos: + +- Estado / comportamiento. +- Propiedades / métodos. +- Encapsulamiento. +- Herencia. +- Polimorfismo. + +

+![](./img/T3/D51.png) +

+ +En el mundo de las Bases de datos, primero se hace **orientación a objetos** (gran capacidad de modelado y dificultades de implementación del SGBD). Después, se hace **objeto-relacional** (solidez de SGBD relacionales y capacidad de modelado de la orientación a objetos). + + +### Cubos de datos - sistemas multidimensionales + +Hay dos modelos de BD en la empresa: + +- **Bases de datos operacionales**: + - Modelos relacional o de objetos. + - OLTP. +- **Bases de datos analíticas**: + - Modelo multidimensional. + - OLAP. + +

+![](./img/T3/D54.png) +

+ +**Modelado Dimensional**: + +- Técnica para visualizar los datos como un conjunto de medidas que están descritas por aspectos comunes del negocio. +- Es muy adecuada para resumir y reordenar datos que van a ser utilizados para el +análisis. +- Está enfocado para trabajar sobre datos numéricos: valores, conteos, pesos, ratios +y ocurrencias. + +

+![](./img/T3/D56.png) +

+ +\newpage + +# Tema 4. Nivel Interno ## Introducción -Sabemos que una BD almacena grandes cantidades de datos y se pretende -gestionarlos de forma eficiente, tanto ellos como su -almacenamiento. Esto afecta a su organización lógica y física. +## Importancia de la organización de los datos + +Sabemos que una **BD** sirve para almacenar de forma permanente grandes cantidades de datos con el propósito principal de gestionar los datos y su almacenamiento de forma eficiente. Esto afecta a su **organización lógica** de los datos y a su **organización física**. + +### Nivel interno + +El **nivel interno** expresa en última instancia, las operaciones sobre los datos (creación, alteración y recuperación) en términos de actuación sobre unidades mínimas de almacenamiento denominadas **páginas o bloques** de base de datos. Está implementado en el **SGBD** y provee al administrador mecanismos para optimizar el acceso y almacenamiento de datos. + +### Nivel físico -El _nivel interno_ expresa las operaciones sobre los datos en términos -de actuación sobre unidades mínimas de almacenamiento, las páginas o -bloques de base de datos. Está implementado en el SGBD y provee al -administrador mecanismos para optimizar el acceso y almacenamiento de -datos. +El **nivel físico** está implementado en el SO y proporciona al SGBD una capa de abstracción sobre el hardware. Este nivel accede a los medios de almacenamiento mediante llamadas a los servicios del sistema de archivos proporcionado por el SO. -El _nivel físico_ está implementado en el SO y da al SGBD abstracción -sobre el hardware. Este nivel accede al almacenamiento mediante -llamadas a los servicios del sistema de archivos proporcionado por el -SO. +### Jerarquía de memoria -## Dispositivos de almacenamiento +

+![](./img/T4a/D8.png) +

-Existen diferentes dispositivos de almacenamiento con diferentes -características. En orden creciente de coste, capacidad y tiempo de -acceso los más importantes son: Registros, Caché, Memoria Principal, -Discos Magnéticos, Discos ópticos. +

+![](./img/T4a/D9.png) +

-* Memoria principal: Hace trabajos de caché de la porción de la BD que - ha sido usada más recientemente. Ubica de forma temporal los datos - afectados por las operaciones. El nivel interno debe optimizar su - uso y garantizar que haya respaldo de la información si cae el - sistema. +### Dispositivos de almacenamiento -* Disco duro: El más usado en BD. Son conjuntos de discos magnéticos - de dos caras donde cada cara tiene un conjunto de pistas - concéntricas que se dividen en sectores con la misma capacidad de - almacenamiento. +Existen diferentes dispositivos de almacenamiento con diferentes características. En orden creciente de coste, capacidad y tiempo de acceso los más importantes son: Registros, Caché, Memoria Principal, Discos Magnéticos, Discos ópticos. -Cada dispositivo tiene un tiempo medio de acceso ($ta$), tiempo medio -de búsqueda ($tb$) y tiempo de latencia rotacional ($tl$). También -tiene un tiempo medio entre fallos ($MTBF$). Así, se cumple que: +### Memoria principal -$$ta = tb+tl$$ +La **memoria principal** es el dispositivo de almacenamiento primario de los ordenadores. Hace trabajos de caché de la porción de la BD que ha sido usada más recientemente. Es el elemento de almacenamiento intermedio que ubica de forma temporal los datos afectados por las operaciones. + +El **nivel interno** debe optimizar su uso: + +- Es **rápida**: acelera el procesamiento. +- Es **cara**: hay que optimizar su uso. + +Es **volátil**, su información se pierde cuando se apaga el sistema (o se cae). El nivel interno debe garantizar que la información contenida tenga un respaldo en almacenamiento secundario para que no se pierda. + +Se utilizan distintos niveles de caché para acelerar el acceso a los datos. + +### Disco duro + +El **disco duro** es el dispositivo de almacenamiento más usado en BD. Son conjuntos de discos magnéticos de dos caras donde cada cara tiene un conjunto de pistas concéntricas (cilindro: la misma pista de todas las caras) que se dividen en sectores con la misma capacidad de almacenamiento (bloque). Un bloque se puede localizar en un cilindro, la superficie de disco o un sector. Los parámetros son: capacidad, tiempo medio de acceso, RPM y velocidad sostenida de lectura/escritura. + +Con respecto a las medidas de rendimiento, cada dispositivo tiene: + +- **Tiempo medio de acceso ($ta$)**: tiempo medio transcurrido entre una instrucción y la obtención de la información. +- **Tiempo medio de búsqueda ($tb$)**: tiempo medio de posicionamiento en pista. +- **Tiempo de latencia rotacional ($tl$)**: tiempo medio de posicionamiento en sector. +$$ta = tb + tl$$ +- **Tiempo medio entre fallos ($MTBF$)**. ## Método de acceso a la BD almacenada -Si tenemos un bloque de la BD en disco, para obtenerlo se siguen una -serie de pasos: +

+![](./img/T4a/D14.png) +

-1. El SGBD solicita la página al gestor de archivos. +Vamos a ver cómo se transforma un registro almacenado en una representación física en el almacenamiento secundario. Si tenemos un bloque de la BD en disco, para obtenerlo se siguen una serie de pasos: -2. El gestor de archivos solicita los bloques de SO al gestor de - disco. +1. El SGBD solicita la página almacenada al gestor de archivos. -3. El gestor de disco hace una operación de E/S a disco. +2. El gestor de archivos solicita los bloques de SO al gestor de disco. -4. El disco devuelve de la base de datos almacenada los sectores - solicitados. +3. El gestor de disco hace una operación de E/S al disco de la base de datos almacenada. -5. El gestor de disco devuelve al gestor de archivos los bloques - solicitados. +4. El disco devuelve de la base de datos almacenada los sectores solicitados al gestor de disco. -6. El gestor de archivos manda al SGBD la página almacenada - solicitada. +5. El gestor de disco devuelve los bloques solicitados al gestor de archivos. +6. El gestor de archivos manda la página almacenada solicitada al SGBD. -En este proceso, para que el gestor de almacenamiento pueda localizar -la página de BD, se utiliza el *Record Identifier*. Cada registro -tiene una cabecera y los datos. Los bloques de la BD tendrán un tamaño -que es múltiplo de las páginas del SO, de forma que para recuperar un -registro almacenado hay que ver en qué página de la BD está. Así, la -estructura de almacenamiento debe estar organizada y deben minimizarse -las operaciones de E/S a disco. +

+![](./img/T4a/D15.png) +

+ +En este proceso, para que el gestor de almacenamiento pueda localizar la página de BD adecuada, se utiliza el *Record IDentifier* (RID). + +

+![](./img/T4a/D16.png) +

+ +Cada registro almacenado tiene: + +- **Cabecera**: número y tipo de columnas que lo integran. +- **Datos**: contenido de las columnas. + +Las **páginas o bloques** de la BD deben tener un tamaño múltiplo de las páginas del SO (mínima unidad de E/S), de forma que para recuperar un registro almacenado hay que determinar en qué página de la BD está y entonces recuperar los bloques de disco que la integran. Así, hay que **organizar** la estructura de almacenamiento y los métodos de acceso, de forma que se optimice la interacción con los dispositivos de almacenamiento secundario. Además, deben **minimizarse** las operaciones de E/S al almacenamiento secundario. ### El gestor de disco del SO -Normalmente, el SGBD interactúa con la BD almacenada mediante el -_gestor de disco del SO_. Este, organiza los datos en conjuntos de -bloques o archivos de SO y gestiona el espacio libre en disco. Una BD -puede obtenerse de uno o varios de estos archivos. Sus funciones -fundamentales son: crear y eliminar archivos de SO, añadir y eliminar -nuevos bloques o reemplazar estos bloques. +Normalmente, el SGBD interactúa con la BD almacenada mediante el **gestor de disco** del SO. El gestor de disco organiza los datos en conjuntos de bloques o archivos de SO y gestiona el espacio libre en disco. Una BD puede valerse de uno o varios de estos archivos para almacenar su contenido. + +Sus **funciones** fundamentales son: + +- Crear un nuevo archivo de SO. +- Eliminar archivos de SO existentes. +- Añadir un bloque nuevo al conjunto de bloques c. +- Eliminar el bloque b del conjunto de bloques c. +- Devolver el bloque b del conjunto de bloques c. +- Reemplazar el bloque b dentro d el conjunto de bloques c. ### El gestor de archivos del SGBD -Es un componente encargado de: - -- Transformar entre campos, registros y archivos almacenados a bloques - y conjuntos de bloques para que el gestor de disco lo entienda. -- Organizar los datos para minimizar el tiempo de recuperación y las - E/S a disco. - -Puede crear archivos almacenados, eliminarlos, recuperar registros de -archivos almacenados (buscando en qué página está) o añadir registros -a archivos almacenados (buscando en qué pagina es más adecuado, y si -no se puede se solicita una nueva página). También puede eliminar -registros de archivos (marcando el espacio como disponible) y -actualizar registros en archivos almacenados. - -## Representación de la BD en el Nivel Interno -La BD se representa de formas distintas en los distintos niveles de -arquitectura del SGBD. Esta representación no tiene por qué coincidir -con la representación en el nivel conceptual, y un conjunto de -registros del mismo tipo no tiene por qué ser un fichero. El nivel -interno debe traducir las estructuras del nivel conceptual a otras -intermedias cercanas al almacenamiento real de los datos. - -Si la BD en el nivel interno tiene al conjunto de páginas en las que -se ubican los registros, tenemos: - -- Agrupamiento Intra-Archivo. Se ubican en la misma página registros - del mismo tipo. Es el más frecuente. -- Agrupamiento Inter-Archivo. Se ubican en la misma página registros - de distinto tipo. Debe existir relación entre ellos (entidades - fuerte-débil). - -En la vida real, cada SGBD comercial utiliza su organización -concreta. No existe una relación directa entre los ficheros -almacenados y los ficheros físicos pues los conjuntos de páginas están -almacenados en uno o varios ficheros. +El **gestor de archivos del SGBD** es un componente del SGBD que se encarga de: + +- Hacer la **transformación** entre: + - Campos, registros y archivos almacenados + - y + - bloques y conjuntos de bloques (que pueda entender el gestor de disco). +- **Organizar** los datos de manera que se minimice el tiempo de recuperación y las E/S a disco. + +Las **funciones** básicas son: + +- Crear un nuevo archivo almacenado: asociar al archivo un conjunto de páginas o bloques de la BD. +- Eliminar un archivo almacenado. +- Recuperar el registro almacenado `r` del archivo almacenado `a`. Normalmente, el SGBD proporciona el RID. Sólo hay que obtener en memoria la página que contiene el registro para extraerlo. +- Añadir un nuevo registro almacenado al archivo almacenado `a`. Hay que localizar la página de BD más apropiada de las pertenecientes al archivo almacenado. Si no se pudiera, se solicita una nueva página. Se devuelve al SGBD el RID nuevo. +- Eliminar el registro `r` del archivo almacenado `a`. Hay que recuperar la página de BD que contiene dicho registro y marcar el espacio ocupado por el registro en dicha página como disponible. +- Actualizar el registro r en el archivo almacenado `a`. Recupera la página de la BD que contiene el registro que se desea actualizar. Trata de sustituir la información. Si no puede, se intenta ubicar en otra página. + +## Representación de la BD en el nivel interno + +La BD se representa de formas diferentes en los distintos niveles de arquitectura del SGBD. Esta representación en el nivel interno no tiene por qué coincidir con la representación en el nivel conceptual, y un conjunto de registros del mismo tipo no tiene por qué ser un fichero. + +El nivel interno debe traducir las estructuras del nivel conceptual a otras estructuras intermedias cercanas al almacenamiento real de los datos (nivel físico). + +Si la BD en el nivel interno tiene al conjunto de páginas en las que se ubican los registros, tenemos: + +- **Agrupamiento Intra-Archivo**: se ubican en la misma página registros del mismo tipo. Es el más frecuente. +- **Agrupamiento Inter-Archivo**: se ubican en la misma página registros de distinto tipo. Debe existir relación entre ellos (por ejemplo, entidades fuerte-débil). + +*Ejemplo.* + +- Se inserta una nueva asignatura con código A6. + - Se localiza la primera página libre (la 24). + - Se inserta el registro correspondiente. + - Se añade esta página al conjunto de páginas de asignaturas. + +

+ ![](./img/T4a/D26.png) +

+ +- Se borra la asignatura con código A2. + - La página que contiene a esta asignatura pasa al conjunto de páginas libres. + - Se reorganiza la lista correspondiente a Asignaturas. + +

+ ![](./img/T4a/D27.png) +

+ +- Se introduce un nuevo profesor con código P7. + - Se ubica en la primera página libre disponible (la segunda). + - Se ajustan las cadenas de punteros. + +

+ ![](./img/T4a/D28.png) +

+ +- Se borra A4. + - Su página pasa al conjunto de páginas libres. + - Se reorganiza la cadena de punteros de las Asignaturas. + +

+ ![](./img/T4a/D29.png) +

+ + Punteros para el recorrido secuencial lógico: + +

+ ![](./img/T4a/D30.png) +

+ + +

+ ![](./img/T4a/D31.png) +

+ +

+ ![](./img/T4a/D32.png) +

+ + En realidad, las páginas contienen más de un registro + + +La organización descrita es un ejemplo general. Cada +SGBD comercial utiliza su variante concreta, aunque la idea subyacente es la misma. + +No existe una relación directa fichero-almacenado/fichero-físico, ya que todos los conjuntos de páginas irán almacenados, con toda probabilidad, en uno o varios ficheros físicos. ## Organización y métodos de acceso -Cuando queremos acceder a los datos de una BD, pretendemos minimizar -el número de acceso a disco. Por ello, necesitamos minimizar la -cantidad da páginas de una BD involucradas en una de estas -operaciones. Existen varias organizaciones usadas para las BD. La -calidad de estas se mide en el tiempo de acceso y el porcentaje de -memoria ocupada por los datos. - -### Organización secuencial +> ¿Son los índices mejores que los hash? Ninguna de las organizaciones presentadas es mejor en términos absolutos. + +Cuando queremos **acceder** a los datos de una BD, nuestro objetivo es minimizar el número de acceso a disco. Por ello, necesitamos minimizar la cantidad da páginas de una BD involucradas en una operación de BD. + +Ninguna de las organizaciones presentadas es mejor en términos absolutos. Existen varias organizaciones usadas para las BD. + +\newpage + +Los criterios básicos para medir la **calidad** de una organización son: + +- **Tiempo de acceso** a los datos requeridos. +- **Porcentaje de memoria ocupada** por los datos requeridos con respecto a las páginas de BD que los contienen. + +Trabajaremos a **dos niveles**: + +- **Organización** de registros de datos a nivel de almacenamiento +- **Adición** de estructuras complementarias para acelerar el acceso a dichos registros. + +## Organización secuencial -Existe un fichero de acceso secuencial donde los registros están -almacenados consecutivamente y ordenados por una clave y para acceder -a un registro debemos pasar por los registros que le preceden. +Existe un **fichero de acceso secuencial** donde los registros están almacenados consecutivamente y ordenados por una clave (**clave física**). Para acceder a un registro debemos pasar por los registros que le preceden. -* Insertar un registro: implica buscar el bloque que le corresponde, - colocarlo si hay sitio y si no o se crea uno nuevo o se crea uno se - crea un bloque de desbordamiento. (Es recomendable dejar espacio - entre bloques para evitar problemas de reorganización). +

+![](./img/T4b/D8.png) +

-* Borrar un registro: implica buscar el registro y borrarlo. Además, - puede implicar una reorganización local de los registros de un - bloque. +*Ejemplo. Mostrar la relación completa de departamentos. La consulta se resolvería rápidamente si los departamentos están almacenados conjuntamente en bloques contiguos de un fichero. Sin embargo, ¿qué pasa si queremos plantear consultas por valor de clave o por rango de valores?* -Ambas suponen escribir en el bloque de registro, crear o liberar -bloques de datos en el fichero secuencia, crear o liberar bloques de -desbordamiento y reorganizar registros entre bloques contiguos. +El primer caso implica: -Es por ello que esta forma tiene grandes inconvenientes que son -subsanables mediante el uso de estructuras adicionales que nos -permitan localizar los datos de manera más rápida y disminuir el -número de bloques de disco transferidos. Las técnicas más populares -son la indexación y el acceso directo. +- Recorrer uno tras otro cada uno de los registros. +- En el caso peor (no encontrarse dicho departamento o ser el último de la lista) supone recorrer de forma completa el fichero. +- Búsqueda es $O(N)$. -#### Indexación +El segundo caso tiene un tratamiento muy parecido: -Pretende disminuir el tiempo de acceso a los datos utilizando una -clave de búsqueda. +- Se realiza la búsqueda por valor de clave de la cota inferior del intervalo. +- Se continúa hasta alcanzar la cota superior. Si están ordenados por el valor de la clave. -#### Fichero secuencial indexado +Si queremos: -Partiendo de un fichero secuencial, añadimos una estructura llamada -fichero índice, cuyos ficheros tienen una clave de búsqueda y un campo -de referencia con los RID de los registros. Son registros más pequeños -que los del fichero de datos aunque hay el mismo número de registros -en ambos. +* **Insertar un registro**: implica buscar el bloque que le corresponde, insertarlo si hay sitio y si no o se crea un nuevo bloque o se crea uno se crea un bloque de desbordamiento. Es recomendable dejar espacio vacío entre bloques para evitar problemas de reorganización. -* Índice primario: la clave de búsqueda es el mismo campo clave por el - que se ordena el fichero secuencial de datos. +* **Borrar un registro**: implica buscar el registro y borrarlo. Además, puede implicar una reorganización local de los registros de un bloque. -* Índices secundarios: se construyen sobre otros campos que no sean la - clave física del fichero de datos. +En resumen, las dos operaciones suponen: -Para consultar un valor, podemos consultar: +- Escritura del bloque del registro que se inserta o borra. +- Creación o liberación de bloques de datos en el fichero secuencial. +- Creación o liberación de bloques de desbordamiento. +- Reorganización de registros entre bloques contiguos, lo que implica la escritura de los bloques implicados en el desplazamiento. -- Por valor de la clave: sobre el índice localizamos la clave, - obtenemos el RID del registro y vamos a disco para recuperar el - bloque donde está el registro señalado por el RID. -- Por rango de valores: se busca en el índice por valor de la clave de - la cota inferior y se recorren las entradas que están en el - intervalo recuperando los registros correspondientes gracias a su - RID. -Para insertar un registro se hace lo mismo que en el fichero -secuencial, y hay que actualizar el índice. +Es por ello que esta forma tiene grandes inconvenientes que son subsanables, al menos en parte, mediante el uso de estructuras adicionales que nos permitan acelerar la localización de los datos y disminuir el número de bloques de disco transferidos. Las técnicas más populares son la **indexación** (índices) y el **acceso directo**. -Para borrar un registro se borra en el fichero de datos y se borra una -entrada en el índice. +## Indexación -Como conclusión, estos índices aceleran el acceso pero hay que -mantener estos índices por lo que se ralentizan otras operaciones. +Pretende disminuir el tiempo de acceso a los datos utilizando una **clave de búsqueda**. Es similar a la idea de un índice en un libro. Existen muchas formas de llevar a cabo esta idea. -#### Índices no densos +## Fichero indexados -Los índices suelen ser muy grandes pues contienen todos los registros -del fichero que indexan. Por tanto, aparecen los índices no densos que -se componen por la clave de búsqueda y la dirección de comienzo del -bloque donde está el registro deseado. El número de registros se -reduce al número de bloques del fichero de datos. +Partiendo de un fichero secuencial sobre el que disponemos una estructura adicional (fichero índice), cuyos resgistros tienen una clave de búsqueda (campo clave) y un campo de referencia con los RIDs de los registros. Son registros más pequeños que los del fichero de datos, aunque hay el mismo número de registros en ambos. -La búsqueda ahora es diferente, pues una vez se encuentra el bloque -donde podría estar el registro hay que cargarlo en memoria y hacer -búsqueda secuencial en ese bloque. Además, no se garantiza encontrar -el registro hasta consultar el bloque completo. +

+![](./img/T4b/D18.png) +

-Los índices no densos sólo se pueden definir sobre la clave física. Su -mantenimiento es menos costoso: la inserción y borrado son menos -frecuentes pues solo ocurren cuando la operación afecta al valor que -representa al bloque completo. +* **Índice primario**: la clave de búsqueda es el mismo campo clave (clave física) por el que se ordena el fichero secuencial de datos. -#### Índices jerárquicos +* **Índices secundarios**: se construyen sobre otros campos que no sean la clave física del fichero de datos. -Estos índices quieren disminuir el tiempo necesario para encontrar un -registro. Para ello, crearán índices multinivel, formados por índices -construidos sucesivamente unos sobre otros. El tamaño de bloque se -establece para optimizar las operaciones de acceso al disco. Así se -reduce el acceso a disco para encontrar un registro pero es más -difícil mantener los índices. +

+![](./img/T4b/D20.png) +

-Los **Árboles B+** son una generalización de los árboles binarios -balanceados en la que los nodos pueden tener más de 2 hijos. Los -valores de la clave se encuentran almacenados en los nodos hoja. Un -árbol B+ de orden M (máximo número de hijos que puede tener cada nodo) -tiene en cada nodo como máximo M hijos y como mínimo (M+1)/2 hijos; -todos los nodos hoja están al mismo nivel y las claves contenidas en -cada nodo nos llevan al nodo del nivel inferior. +Para **consultar** un valor, podemos consultar: -Se pone como restricción que los valores de clave $C_i$ están -ordenados dentro del nodo y que los valores $x$ del subárbol apuntado -por $P_i$ cumplen: +- **Por valor de la clave**: sobre el índice localizamos la clave (recorrido secuencial), obtenemos el RID del registro y vamos a disco para recuperar el bloque donde está el registro señalado por el RID. La búsqueda en el índice es más rápida. +- **Por rango de valores**: se busca en el índice por valor de la clave de la cota inferior y se recorren las entradas del índice que están en el intervalo, recuperando los registros correspondientes gracias a su RID. + +Para **insertar un nuevo registro** se hace lo mismo que en el fichero secuencial, y hay que actualizar el índice (inserción en un fichero secuencial). + +Para **borrar un registro** se borra un registro en el fichero de datos y se borra una entrada en el índice. + +*Ejemplo. Borrado del registro de clave 13.* + +

+![](./img/T4b/D23.png) +

+ +Se puede montar un índice sobre más de un campo de un registro. La clave es la concatenación de los campos indicados. + +Hay que tener cuidado: si hay un índice sobre nombre-alumno y DNI. Es útil para consultas que involucran: Nombre; Nombre y DNI. No es útil para consultas sobre el DNI. + +Como conclusión, estos índices aceleran el acceso a los datos pero ralentizan las otras operaciones, por lo que hay que mantener estos índices. + +Por tanto, hay que considerar la conveniencia de crear cada índice: frecuencia de las consultas y frecuencia de las operaciones de mantenimiento de los datos. + +## Índices no densos + +Lo ideal es mantener el índice en memoria principal. Pero en realidad, los índices suelen ser muy grandes porque contienen todos los registros del fichero que indexan. Son densos. + +Por tanto, para reducir el tamaño aparecen los **índices no densos**, que son registros que se componen por la clave de búsqueda y la dirección de comienzo del bloque donde puede estar el registro deseado. El número de registros se reduce al número de bloques del fichero de datos. El acceso secuencial al índice no denso se acelera. + +

+![](./img/T4b/D28.png) +

+ +La búsqueda ahora es diferente, pues una vez se encuentra el bloque donde podría estar el registro hay que cargarlo en memoria y hacer búsqueda secuencial en ese bloque. No tiene costes en términos de acceso a disco. Además, no se garantiza encontrar el registro hasta consultar el bloque de datos leído. + +Los índices no densos sólo se pueden definir sobre la clave física. El mantenimiento de un índice no denso es menos costoso: la inserción y borrado son menos frecuentes pues solo ocurren cuando la operación afecta al valor que representa al bloque completo. + +

+![](./img/T4b/D31.png) +

+ +## Índices jerárquicos + +Estos índices quieren disminuir el tiempo necesario para recorrer el índice en busca de un registro. Para ello, crearán **índices multinivel**, formados por índices construidos sobre índices, luego hay varios niveles en el acceso a los datos. Un índice multinivel está formado por: + +- Un **índice de primer nivel** sobre el fichero de datos, puede ser denso o no dependiendo de la clave. +- **Otros índices**, no densos, construidos sucesivamente unos sobre otros. + +El **tamaño de bloque** se establece para optimizar las operaciones de acceso al disco físico. Así se reduce el número de accesos a disco para encontrar un registro pero es más difícil mantener los índices. En el peor caso, el número de accesos pueden ser tantos como niveles. + +

+![](./img/T4b/D34.png) +

+ +## Árboles B+ + +Fueron propuestos en 1972 por Bayer y McCreight. Los **Árboles B+** son una generalización de los árboles binarios balanceados en la que los nodos pueden tener más de 2 hijos. Los valores de la clave se encuentran almacenados en los nodos hoja. + +Un árbol B+ de orden $M$ (máximo número de hijos que puede tener cada nodo) es un árbol con la siguiente estructura: + +- Nodo de nivel superior: raíz del árbol +- Nodos del nivel inferior: hojas. +- Cada nodo distinto de las hojas tiene como máximo $M$ hijos y como mínimo $(M+1)/2$ hijos. +- Todos los nodos hoja aparecen al mismo nivel. +- Las claves contenidas en cada nodo nos guiarán hasta el siguiente nodo del nivel +inmediatamente inferior. +- Un nodo no hoja con $n$ hijos contiene: + - $n-1$ valores de clave almacenados. + - $n$ punteros $P_i$ que apuntan a un nodo hijo. + +

+![](./img/T4b/D37.png) +

+ +Se pone como restricción que los valores de clave $C_i$ están ordenados dentro del nodo y que los valores $x$ del subárbol apuntado por $P_i$ cumplen: $$ C_{i-1} \leq x < C_i$$ -Excepto para $i = 1$ ( $x < C_1$ ) e $i = n $ ( $x \geq C_n$). - -Los nodos hoja tienen punteros al siguiente nodo hoja. La lista -concatenada de nodos hoja es útil para hacer consultas por -intervalos. Las claves aparecerán ordenadas en cada nodo y todas deben -ser menores que las del siguiente nodo. Los nodos deberán estar -rellenos como mínimo hasta la mitad. - -* Consulta: Para localizar un registro, se bajan niveles desde la - raíz, buscando el registro en el nodo hoja y recuperando el registro - del fichero de datos por el RID. Para consultar en un rango se - localiza el nodo hoja con el valor inferior y se recorren los demás - nodos hoja hasta encontrar el superior. -* Inserción y borrado: Los algoritmos utilizados deben garantizar que - el árbol siga siendo equilibrado. - -Los árboles B+ en BD son variaciones del árbol B+ de orden elevado en -la que se procura que cada nodo tenga casi el mismo almacenamiento que -un bloque de datos, reduciendo los acceso a disco. En los nodos -_intermedios_ solo están los rangos de valores de la clave y los -punteros a los nodos hijo. En los nodos _hoja_ , que están enlazados, -están los valores de clave ordenados junto con los RIDs que apuntan a -las tuplas que contienen ese valor de clave. - -También existen las Tablas Organizadas por Índice. En este caso, las -hojas contienen las tuplas en lugar del RID. Así, una IOT solo puede -estar organizada de esta forma mediante una clave aunque se pueden -definir índices adicionales basados en otras claves. - -| Tabla normal | -IOT | -|:----------------------------------------------------------:|:--------------------------------------------------------------------:| -| Identificador único ROWID (RID) | -Identificado por clave primaria | -| ROWID implícito Soporta varios índices | No -ROWID Sólo un índice IOT, varios B-tree | -| Una recuperación completa devuelve las tuplas desordenadas | Una -recuperación completa devuelve las las tuplas ordenadas según CP | - -#### Índices Clave invertida -Los índices por clave invertida invierten los datos del valor de la -clave. Es adecuado para búsquedas basadas en predicados y mejora el -rendimiento de la inserción de tuplas si se insertan de forma -ascendente para valores de la clave. También mejora accesos -concurrentes. - -#### Índices BITMAP - -En los índices BITMAP, para cada valor que toma la clave almacena una -secuencia de bits (tantos como tuplas contenga la tabla), en los que -hay un 1 si el valor está presente en la tupla y un 0 si no lo está. - - -| B-tree | -BITMAP | -|:-------------------------------------------------:|:----------------------------------------------:| -| Adecuado para columnas que tomen muchos valores | Adecuado para -columnas que tomen pocos valores | -| Actualización de claves poco costosa | Actualización de -claves muy costosa | -| Ineficiente para consultas usando predicados OR | Eficiente para -consultas usando predicados OR | - - -### Acceso directo - -El acceso directo es una forma de acceder a un registro almacenado. En -este caso, no tenemos estructura adicional sino que usamos un -algoritmo para identificar la posición del registro deseado. Para -ello, debemos tener un campo que identifique unívocamente al -registro. - -Lo usual es que no se pueda establecer una clave física totalmente -correlativa y única, por lo que nuestro algoritmo deberá tener una -entrada de un campo clave y proporcionará una salida que será un valor -entero positivo transformable en RID. - -Estos algoritmos de direccionamiento no suelen mantener el orden de la -clave. Los registros no están almacenados según el orden de su clave -física. Es por ello por lo que tendremos problemas a la hora de -recuperar intervalos de datos. - -Los algoritmos usados son variados. Si la clave es alfanumérica, se -transforma a un valor numérico. Algunos comunes son los de los -cuadrados centrales, congruencias, desplazamiento o conversión de -base. - -Estos algoritmos tienen varios problemas: - -* Es muy difícil encontrar una transformación que dé un valor entero - positivo en un rango de valores limitado tal que dos claves - diferentes den siempre valores distintos. - -* Producen huecos , zonas vacías del rango de salida, no asignadas por - el algoritmo, que generan huecos en el fichero de datos. - -* Para gestionar colisiones y huecos tenemos que combinar acceso - directo y listas de colisión, que mantienen los registros con claves - que producen colisión en dichas lista. Si estas listas crecen el - acceso directo no resulta adecuado pues hay que mantener las listas - y la zona de desbordamiento es casi como el fichero original. - -#### Hashing básico - -Aparece para solucionar el problema del acceso directo. Ya que los -valores de las claves no estaban uniformemente distribuidos en un -intervalo, sino que se acumulan en una parte de él, lo que se hace es -asignar más espacio a esa parte. - -Así, se divide el fichero en _buckets_ (cubos) y el algoritmo asignará -cubos, no direcciones concretos. En cada bucket habrá más de un -registro y ciertos rangos de valores tendrán asignados más buckets que -otros. Complementamos esto con el uso de cubos de desbordamiento. - -Tendremos como parámetros por tanto: - -* Número de cubos -* Tamaño de los cubos -* La transformada clave/dirección, que tiene en cuenta la distribución - de la clave para que los cubos queden equitativamente rellenos. - - -Para _insertar_ un registro, transformamos la clave, localizamos su -cubo, se inserta si hay sitio y si no se sitúa en el cubo de -desbordamiento conectando el cubo a donde realmente le corresponde el -registro. - -Para _buscar_ un registro, transformamos la clave, localizamos su cubo -y dentro del cubo buscamos secuencialmente y luego en los cubos de -desbordamiento. - -#### Hashing dinámico +Excepto para $i = 1$ (donde $x < C_1$ ) e $i = n$ (donde $x \geq C_{n-1}$). + +

+![](./img/T4b/D38.png) +

+ +Los **nodos hoja** tienen una estructura diferente: + +- Parejas clave - RID. +- Punteros al siguiente nodo hoja. +- Algunas variantes también tienen punteros al nodo hoja anterior. + +La **lista concatenada de nodos hoja** (conjunto secuencia) es útil para hacer consultas por intervalos. + +

+![](./img/T4b/D39.png) +

+ +Las **claves** aparecerán ordenadas en cada nodo y todas deben ser menores que las del siguiente nodo en el conjunto secuencia. + +Los **nodos hoja** se encuentran en el mismo nivel: árbol equilibrado y todos los caminos desde la raíz a un ondo hoja tienen la misma longitud. + +> Los nodos deberán estar rellenos como mínimo hasta la mitad. ??? -El hashing básico tiene el problema de que hay que conocer la -distribución previa de las claves para asignar los buckets, de lo -contrario sigue habiendo huecos y colisiones. Además, al aumentar el -número de registro,s hay más registros en las páginas de -desbordamiento y a veces hay que reorganizar los datos. +| **Nodo** | **Restricción** | **Min** | **Max** | **Ejemplo $M=5$** | +|---|---|---|---|---| +| Raíz (cuando no es nodo único) | Número de hijos | 2 | M | 2-5 | +| Interno | Número de hijos | $\lceil M/2 \rceil$ | M | 3-5| +| Hoja | Número de claves | $\lfloor M/2 \rfloor$ | M-1 | 2-4 | -El Hashing dinámico trabaja partiendo de una configuración uniforme y -de pocos cubos y generando los restantes cuando los necesite, -asignando a los rangos conforme la afluencia de registros lo pide. +* **Consulta**: para **localizar** un registro, navegamos desde la raíz, bajando niveles y buscando el registro en el nodo hoja y recuperando el registro del fichero de datos gracias al RID. -¿Cómo se hace? + Para **consultar** en un rango se localiza el nodo hoja con el valor inferior y se recorren los demás nodos hoja hasta encontrar el superior, recuperando los registros pertinentes del fichero de datos. -El valor transformado del campo clave da una entrada de una tabla -índice que está en memoria. Allí está la dirección del cubo donde -están los registros que tienen asociado este valor transformado (puede -que varias entradas de la tabla lleven al mismo cubo). Cuando se -insertan más registros, se generan nuevos cubos y cambian las salidas -de la tabla índice. +* **Inserción y borrado**: los algoritmos utilizados deben garantizar que el árbol siga siendo equilibrado. -Partimos de: +

+![](./img/T4b/D43.png) +

+ +## Árboles B + +Los **árboles-B** (B-Tree) son una variante de B+Tree en la que no se almacenan todos los valores de la clave en los nodos hoja, sino que algunos valores se van almacenando en los nodos intermedios conforme se crea el árbol. + + +## Árboles B+ en BD + +Los **árboles B+ en BD** son variaciones del árbol B+ de orden elevado en la que se procura que cada nodo tenga casi el mismo almacenamiento que un bloque de datos. Esto reduce los acceso a disco que suelen ser los que determinan el rendimiento de las búsquedas en BD. + +En los nodos **intermedios** solo están los rangos de valores de la clave y los punteros a los nodos hijo correspondientes. + +En los nodos **hoja**, que están enlazados, están los valores de clave ordenados junto con los RIDs (*rowid*) que apuntan a las tuplas que contienen ese valor de clave. Los nodos hoja, que forman el conjunto secuencia, se encuentran enlazados para poder recuperar por búsquedas secuenciales, a veces se encuentran doblemente enlazados, para facilitar búsquedas ascendentes y descendentes por el valor de la clave. + +

+![](./img/T4b/D48.png) +

+ +También existen las **Tablas Organizadas por Índice** (*IOT*). En este caso, las hojas contienen las tuplas en lugar del RID. Así, una IOT solo puede estar organizada de esta forma mediante una clave, aunque se pueden definir índices adicionales basados en otras claves. + +

+![](./img/T4b/D49.png) +

+ +

+![](./img/T4b/D50.png) +

+ +| **Tabla normal** | **IOT** | +|:-------------------------------------------------------------------:|:--------------------------------------------------------:| +| Identificador único ROWID (RID) | Identificado por clave primaria | +| ROWID implícito Soporta varios índices | No ROWID Sólo un índice IOT, varios B-tree | +| Una recuperación completa devuelve las tuplas desordenadas | Una recuperación completa devuelve las tuplas ordenadas según CP | + + +## Índices por clave invertida + +Los **índices por clave invertida** (*reverse index*) invierten los datos del valor de la clave. Es adecuado para búsquedas basadas en predicados = y mejora el rendimiento de la inserción de tuplas si se insertan de forma ascendente para valores de la clave. También mejora accesos concurrentes. + +Para el empleado 7698 almacena 8967. + +Con este índice se reducen los embotellamientos (retención de bloques de BD) en el índice cuando se están introduciendo los datos de forma ascendente para los valores de la clave, puesto que todos irían a la misma entrada de índice. + +

+![](./img/T4b/D53.png) +

+ +## Índices BITMAP + +En los **índices BITMAP** (*índices de mapa de bit*), para cada valor que toma la clave almacena una secuencia de bits (tantos como tuplas contenga la tabla), en los que hay un 1 si el valor está presente en la tupla y un 0 si no lo está. + + +| **B-tree** | **BITMAP** | +|:----------------------------------------------------------------------:|:---------------------------------------------------------------------------:| +| Adecuado para columnas que tomen muchos valores | Adecuado para columnas que tomen pocos valores | +| Actualización de claves | Actualización de claves | +| poco costosa | muy costosa | +| Ineficiente para consultas usando predicados OR | Eficiente para consultas usando predicados OR | + +

+![](./img/T4b/D56.png) +

+ +En la anterior imagen, el índice tiene 4 entradas, una por cada color. Nos dice qué tuplas tiene cada color. Si queremos ver las tuplas del color verde o azul, haremos el OR entre los mapa de bits correspondientes. + +Una **ventaja** es acelerar consultas tipo OR, las del tipo AND no porque no hay. + +Un **inconveniente** es cuando hay muchos valores porque hay que montar un mapa de bits. + +\newpage + +# Tema 5. El nivel interno. Métodos de organización y acceso a los datos + +## Acceso directo + +El **acceso directo** es una forma de acceder a un registro almacenado. En este caso, no tenemos estructura adicional sino que usamos un algoritmo o función sobre un campo determinado del mismo para identificar la posición del registro deseado. Para ello, debemos tener un campo que identifique unívocamente al registro. + +Con respecto al **funcionamiento**, lo usual es que no se pueda establecer una **clave física** totalmente correlativa y única para cada registro, por lo que nuestro algoritmo tiene que transformar los valores de un cierto campo en una dirección. Además, deberá tener una entrada de un **campo clave** y proporcionará una salida que será un valor entero positivo transformable en **RID**. + +

+![](./img/T4c/D6.png) +

+ +Estos algoritmos de direccionamiento no suelen mantener el orden de la clave. Los registros no están almacenados según el orden de su clave física. Es por ello por lo que tendremos problemas a la hora de recuperar intervalos de datos. + +Los **algoritmos** usados son variados: + +- **Dependen del tipo de clave**: si la clave es alfanumérica, se transforma a un valor numérico. + +\newpage + +- Suelen estar basados en un mecanismo de **generación de números pseudoaleatorios**: + - **Cuadrados centrales**: se eleva la clave al cuadrado y se eligen tantos digitos centrales como sea enecesario. + - **Congruencias**: se divide la clave por $M$ y se toma el resto ($M$ suele ser primo). + - **Desplazamiento**: se superponen adecuadamente los digitos binarios de la clave y luego se suman + - **Conversión de base**: se cambia la base de numeración y se suprimen algunos dígitos resultantes. + +Estos algoritmos tienen varios **problemas**: + +* Salvo que el campo clave se diseñe para ello, es prácticamente imposible encontrar una transformación que dé un valor entero positivo en un rango de valores limitado tal que dos claves diferentes den siempre valores distintos. Se producen **colisiones**. + +* Producen **huecos**, zonas vacías del rango de salida, no asignadas por el algoritmo, que generan huecos en el fichero de datos. + +Para **gestionar colisiones y huecos** tenemos que combinar acceso directo con una gestión mediante **listas de colisión**, que mantienen los registros con claves que producen colisión en dichas lista. Si estas listas crecen el acceso directo no resulta adecuado pues hay que mantener las listas y la zona de desbordamiento es casi como el fichero original. Puede haber colisión: + +- El **registro problemático** se almacena en la zona de desbordamiento. +- Los **sinónimos** (registros con claves que producen colisión) se conectan mediante una lista. + +

+![](./img/T4c/D11.png) +

+ +Si crecen las listas de sinónimos, el acceso directo puro no resulta adecuado. Hay que mantener listas y la zona de desbordamiento es casi como el fichero original. + +Han aparecido técnicas más sofisticadas: **hashing**. + +## Hashing básico + +Aparece para solucionar el problema del acceso directo. Ya que los valores de las claves no estaban uniformemente distribuidos en el intervalo [$0,M$], sino que se acumulan en una parte de él. La solución es asignar más espacio a esa parte del intervalo. + +La técnica consiste en dividir el fichero en **buckets** (cubos) y el algoritmo de direccionamiento asignará cubos, no direcciones concretas. En cada *bucket* habrá más de un registro y ciertos rangos de valores tendrán asignados más buckets que otros. Complementamos esto con el uso de **cubos de desbordamiento**. + +\newpage + +Tendremos como **parámetros**: + +* **Número** de cubos. +* **Tamaño** de los cubos (relación con bloques físicos): *slots*. +* La **transformada** clave/dirección, que tiene en cuenta la distribución de la clave según rangos para que los cubos queden equitativamente rellenos. + + +Para **insertar** un registro, transformamos la clave, localizamos su cubo, se inserta si hay sitio y si no se sitúa en el cubo de desbordamiento conectándolo con el cubo a donde realmente le corresponde el registro mediante punteros. + +Para **buscar** un registro, transformamos la clave, localizamos su cubo y dentro del cubo buscamos secuencialmente: si hemos encontrado el registro, el proceso termina; en caso contrario, se impone un barrido por punteros a través de los cubos de desbordamiento. + +## Hashing dinámico + +El hashing básico tiene el problema de que hay que conocer la distribución previa de las claves para asignar adecuadamente los buckets, de lo contrario sigue habiendo huecos y colisiones. Además, al aumentar el número de registros, aumentan los registros en las páginas de desbordamiento y a veces hay que reorganizar los datos. + +La solución es trabajar de forma dinámica. El **Hashing dinámico** trabaja partiendo de una configuración uniforme y de pocos cubos y los restantes, se van generando cuando los necesite, asignando a los rangos conforme la afluencia de registros lo pide. Es un hashing dinámico o extensible. + +La **técnica** es la siguiente: + +El valor transformado del campo clave da una entrada de una tabla índice que está en memoria. Allí está la dirección del cubo donde están los registros que tienen asociado este valor transformado (puede que varias entradas de la tabla lleven al mismo cubo). Inicialmente, todas las entradas apuntan al mismo cubo. Cuando se insertan más registros, se generan nuevos cubos y cambian las salidas de la tabla índice. + +En el **algoritmo de Hashing Dinámico**, partimos de: * $k$ una clave física para direccionar. -* $k' = h(k)$ un entero en un intervalo. +* $k' = h(k)$ un entero entre $0$ y $M$ * $n$ un número de bits que tiene $k'$ en binario. -* $d$, los primeros d dígitos de $k'$, que seleccionan el cubo donde - está el registro(pseudoclave). -* $b < d <= n$, pues inicialmente el archivo tiene $2^b$ cubos - distintos y como máximo tendrá $2^d$. - -Entonces, si tenemos una tabla índice con $2^d$ filas, en la primera -columna se sitúan las posibles soluciones de $d$ dígitos binarios (d -es llamada la profundidad global de la tabla). Entonces, las entradas -cuyos $b$ primeros dígitos son iguales apuntan al mismo cubo. Todos -los cubos suelen tener profundidad local igual a b. Por último, al -llenar un cubo se divide en dos, poniendo en uno los registros con el -dígito $b+1$ de k' a 0 y en otro los que tienen el dígito $b+1$ igual -a 1. Aumenta entonces la profundidad local en uno. - -De este modo, solventamos los problemas del acceso directo, aunque -tenemos inconvenientes pues tenemos que usar una tabla índice -adicional( y por tanto acceder más a disco si no cabe en memoria) , y -el tamaño de la tabla depende de $d$ (primeros dígitos de $k' = h(k)$. +* $d \leq n$, los primeros $d$ dígitos de $k'$, que seleccionan el cubo donde está el registro(pseudoclave). +* $b < d <= n$, inicialmente el archivo tiene $2^b$ cubos + distintos y como máximo tendrá $2^d$. Si son necesarios más, hay que aumentar $d$. + +Entonces, si tenemos una tabla índice con $2^d$ filas, en la primera columna de esta tabla (valores de campo clave) se sitúan las posibles soluciones de $d$ dígitos binarios ($d$ es la profundidad global de la tabla). En principio, las entradas cuyos $b$ primeros dígitos son iguales apuntan al mismo cubo. Allí se almacenan los registros cuyo valor de $k'$ tiene esos $b$ primeros dígitos. Todos los cubos suelen tener profundidad local igual a $b$. Por último, al llenar un cubo se divide en 2, poniendo en uno los registros con el dígito $b+1$ de $k'$ a $0$ y en otro los que lo tienen igual a 1. Aumenta entonces la profundidad local de estos cubos en uno. + +

+![](./img/T4c/D24.png) +

+ +De este modo, solventamos los problemas del acceso directo, aunque tenemos inconvenientes pues tenemos que usar una tabla índice adicional (y por tanto acceder más a disco si no cabe en memoria), y el tamaño de la tabla depende de $d$. + +\newpage \ No newline at end of file diff --git a/fbd/img/T2/D14.png b/fbd/img/T2/D14.png new file mode 100644 index 0000000..1cfbf6f Binary files /dev/null and b/fbd/img/T2/D14.png differ diff --git a/fbd/img/T2/D39.png b/fbd/img/T2/D39.png new file mode 100644 index 0000000..f7ba6ba Binary files /dev/null and b/fbd/img/T2/D39.png differ diff --git a/fbd/img/T2/D42.png b/fbd/img/T2/D42.png new file mode 100644 index 0000000..8b9ee84 Binary files /dev/null and b/fbd/img/T2/D42.png differ diff --git a/fbd/img/T2/D47.png b/fbd/img/T2/D47.png new file mode 100644 index 0000000..a0b9c09 Binary files /dev/null and b/fbd/img/T2/D47.png differ diff --git a/fbd/img/T2/D8.png b/fbd/img/T2/D8.png new file mode 100644 index 0000000..afac56d Binary files /dev/null and b/fbd/img/T2/D8.png differ diff --git a/fbd/img/T3/D33.png b/fbd/img/T3/D33.png new file mode 100644 index 0000000..129f0d1 Binary files /dev/null and b/fbd/img/T3/D33.png differ diff --git a/fbd/img/T3/D35.png b/fbd/img/T3/D35.png new file mode 100644 index 0000000..b99b50d Binary files /dev/null and b/fbd/img/T3/D35.png differ diff --git a/fbd/img/T3/D41.png b/fbd/img/T3/D41.png new file mode 100644 index 0000000..7bd073f Binary files /dev/null and b/fbd/img/T3/D41.png differ diff --git a/fbd/img/T3/D43.png b/fbd/img/T3/D43.png new file mode 100644 index 0000000..104a6b6 Binary files /dev/null and b/fbd/img/T3/D43.png differ diff --git a/fbd/img/T3/D46.png b/fbd/img/T3/D46.png new file mode 100644 index 0000000..c15cc0c Binary files /dev/null and b/fbd/img/T3/D46.png differ diff --git a/fbd/img/T3/D51.png b/fbd/img/T3/D51.png new file mode 100644 index 0000000..566c4f8 Binary files /dev/null and b/fbd/img/T3/D51.png differ diff --git a/fbd/img/T3/D54.png b/fbd/img/T3/D54.png new file mode 100644 index 0000000..18035de Binary files /dev/null and b/fbd/img/T3/D54.png differ diff --git a/fbd/img/T3/D56.png b/fbd/img/T3/D56.png new file mode 100644 index 0000000..3561c69 Binary files /dev/null and b/fbd/img/T3/D56.png differ diff --git a/fbd/img/T3/D6.png b/fbd/img/T3/D6.png new file mode 100644 index 0000000..fc82813 Binary files /dev/null and b/fbd/img/T3/D6.png differ diff --git a/fbd/img/T4a/D11.png b/fbd/img/T4a/D11.png new file mode 100644 index 0000000..c0703bd Binary files /dev/null and b/fbd/img/T4a/D11.png differ diff --git a/fbd/img/T4a/D14.png b/fbd/img/T4a/D14.png new file mode 100644 index 0000000..b2a76e0 Binary files /dev/null and b/fbd/img/T4a/D14.png differ diff --git a/fbd/img/T4a/D15.png b/fbd/img/T4a/D15.png new file mode 100644 index 0000000..67aac55 Binary files /dev/null and b/fbd/img/T4a/D15.png differ diff --git a/fbd/img/T4a/D16.png b/fbd/img/T4a/D16.png new file mode 100644 index 0000000..410bed2 Binary files /dev/null and b/fbd/img/T4a/D16.png differ diff --git a/fbd/img/T4a/D26.png b/fbd/img/T4a/D26.png new file mode 100644 index 0000000..33ee530 Binary files /dev/null and b/fbd/img/T4a/D26.png differ diff --git a/fbd/img/T4a/D27.png b/fbd/img/T4a/D27.png new file mode 100644 index 0000000..1f66c42 Binary files /dev/null and b/fbd/img/T4a/D27.png differ diff --git a/fbd/img/T4a/D28.png b/fbd/img/T4a/D28.png new file mode 100644 index 0000000..d1c0ecd Binary files /dev/null and b/fbd/img/T4a/D28.png differ diff --git a/fbd/img/T4a/D29.png b/fbd/img/T4a/D29.png new file mode 100644 index 0000000..194bd51 Binary files /dev/null and b/fbd/img/T4a/D29.png differ diff --git a/fbd/img/T4a/D30.png b/fbd/img/T4a/D30.png new file mode 100644 index 0000000..2b861cf Binary files /dev/null and b/fbd/img/T4a/D30.png differ diff --git a/fbd/img/T4a/D31.png b/fbd/img/T4a/D31.png new file mode 100644 index 0000000..4cb5dd4 Binary files /dev/null and b/fbd/img/T4a/D31.png differ diff --git a/fbd/img/T4a/D32.png b/fbd/img/T4a/D32.png new file mode 100644 index 0000000..e2a5e9b Binary files /dev/null and b/fbd/img/T4a/D32.png differ diff --git a/fbd/img/T4a/D8.png b/fbd/img/T4a/D8.png new file mode 100644 index 0000000..c9f8e05 Binary files /dev/null and b/fbd/img/T4a/D8.png differ diff --git a/fbd/img/T4a/D9.png b/fbd/img/T4a/D9.png new file mode 100644 index 0000000..8edf627 Binary files /dev/null and b/fbd/img/T4a/D9.png differ diff --git a/fbd/img/T4b/D18.png b/fbd/img/T4b/D18.png new file mode 100644 index 0000000..c386205 Binary files /dev/null and b/fbd/img/T4b/D18.png differ diff --git a/fbd/img/T4b/D20.png b/fbd/img/T4b/D20.png new file mode 100644 index 0000000..404ee9d Binary files /dev/null and b/fbd/img/T4b/D20.png differ diff --git a/fbd/img/T4b/D23.png b/fbd/img/T4b/D23.png new file mode 100644 index 0000000..2b55b4b Binary files /dev/null and b/fbd/img/T4b/D23.png differ diff --git a/fbd/img/T4b/D28.png b/fbd/img/T4b/D28.png new file mode 100644 index 0000000..65b4f5e Binary files /dev/null and b/fbd/img/T4b/D28.png differ diff --git a/fbd/img/T4b/D31.png b/fbd/img/T4b/D31.png new file mode 100644 index 0000000..474d038 Binary files /dev/null and b/fbd/img/T4b/D31.png differ diff --git a/fbd/img/T4b/D34.png b/fbd/img/T4b/D34.png new file mode 100644 index 0000000..f6ade39 Binary files /dev/null and b/fbd/img/T4b/D34.png differ diff --git a/fbd/img/T4b/D37.png b/fbd/img/T4b/D37.png new file mode 100644 index 0000000..680e919 Binary files /dev/null and b/fbd/img/T4b/D37.png differ diff --git a/fbd/img/T4b/D38.png b/fbd/img/T4b/D38.png new file mode 100644 index 0000000..586f23c Binary files /dev/null and b/fbd/img/T4b/D38.png differ diff --git a/fbd/img/T4b/D39.png b/fbd/img/T4b/D39.png new file mode 100644 index 0000000..d9833e7 Binary files /dev/null and b/fbd/img/T4b/D39.png differ diff --git a/fbd/img/T4b/D43.png b/fbd/img/T4b/D43.png new file mode 100644 index 0000000..75a625c Binary files /dev/null and b/fbd/img/T4b/D43.png differ diff --git a/fbd/img/T4b/D48.png b/fbd/img/T4b/D48.png new file mode 100644 index 0000000..1c91c01 Binary files /dev/null and b/fbd/img/T4b/D48.png differ diff --git a/fbd/img/T4b/D49.png b/fbd/img/T4b/D49.png new file mode 100644 index 0000000..fa0e49f Binary files /dev/null and b/fbd/img/T4b/D49.png differ diff --git a/fbd/img/T4b/D50.png b/fbd/img/T4b/D50.png new file mode 100644 index 0000000..ac7d98f Binary files /dev/null and b/fbd/img/T4b/D50.png differ diff --git a/fbd/img/T4b/D53.png b/fbd/img/T4b/D53.png new file mode 100644 index 0000000..9888265 Binary files /dev/null and b/fbd/img/T4b/D53.png differ diff --git a/fbd/img/T4b/D56.png b/fbd/img/T4b/D56.png new file mode 100644 index 0000000..6da6690 Binary files /dev/null and b/fbd/img/T4b/D56.png differ diff --git a/fbd/img/T4b/D8.png b/fbd/img/T4b/D8.png new file mode 100644 index 0000000..c483ada Binary files /dev/null and b/fbd/img/T4b/D8.png differ diff --git a/fbd/img/T4c/D11.png b/fbd/img/T4c/D11.png new file mode 100644 index 0000000..2206093 Binary files /dev/null and b/fbd/img/T4c/D11.png differ diff --git a/fbd/img/T4c/D24.png b/fbd/img/T4c/D24.png new file mode 100644 index 0000000..dcfd266 Binary files /dev/null and b/fbd/img/T4c/D24.png differ diff --git a/fbd/img/T4c/D6.png b/fbd/img/T4c/D6.png new file mode 100644 index 0000000..5d78da7 Binary files /dev/null and b/fbd/img/T4c/D6.png differ