Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
bases de datos
Blai Cabré i Segarra
Jordi Casas Roma
Dolors Costal Costa
Pere Juanola Juanola
Àngels Rius Gavidia
Ramon Segret i Sala
PID_00223667
CC-BY-NC-ND • PID_00223667 Diseño físico de bases de datos
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos
y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya),
no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/
licenses/by-nc-nd/3.0/es/legalcode.es
CC-BY-NC-ND • PID_00223667 Diseño físico de bases de datos
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Conceptos previos.............................................................................. 7
2. El nivel lógico..................................................................................... 9
2.1. Componentes lógicos .................................................................. 9
3. El nivel físico...................................................................................... 10
3.1. La página ..................................................................................... 10
3.1.1. Estructura de una página ............................................... 11
3.1.2. Estructura de una fila .................................................... 12
3.1.3. Estructura de un campo ................................................ 13
3.1.4. Gestión de la página ..................................................... 14
3.1.5. Otros tipos de páginas ................................................... 16
3.2. La extensión ................................................................................ 17
3.3. El fichero ..................................................................................... 17
3.4. Visión general de las E/S en un SGBD ........................................ 18
4. El nivel virtual................................................................................... 21
4.1. Justificación de la existencia del nivel virtual ............................ 21
4.2. El espacio virtual y sus asociaciones ........................................... 22
4.3. Estructura del espacio virtual ...................................................... 23
4.3.1. Direccionamiento en un SGBD ..................................... 25
Resumen....................................................................................................... 74
Glosario........................................................................................................ 75
Bibliografía................................................................................................. 77
CC-BY-NC-ND • PID_00223667 5 Diseño físico de bases de datos
Introducción
Antes de iniciar esta etapa, hay que seleccionar el SGBD concreto sobre el
cual se quiere implementar la base de datos. En este módulo nos centraremos
en las bases de datos relacionales; por lo tanto, el objetivo es ver el proceso
de transformación de un modelo lógico relacional hacia un modelo físico y
concretar un SGBD relacional.
Objetivos
1. Conocer la estructura física que utiliza la base de datos para almacenar los
datos de manera no volátil.
4. Definir los índices necesarios y convenientes en cada tabla para que las
aplicaciones tengan un buen rendimiento cuando accedan a la base de
datos.
1. Conceptos previos
La manera más sencilla de explicar una base de datos (BD) es decir que se trata
de un conjunto de datos persistentes relacionados entre sí. La característica
de persistencia implica que los datos no han de desaparecer entre ejecuciones
sucesivas de programas, aunque entre estas ejecuciones transcurra un intervalo
de tiempo largo. Este requisito obliga a su vez a tener los datos entre ejecución
y ejecución almacenados en un medio no volátil, normalmente en un disco
magnético.
Para comprender qué relación hay entre los datos tal como los ve el programa- ¿Qué es una arquitectura?
dor o el usuario final y tal y como están almacenados en el soporte no volátil,
Una arquitectura, como cual-
utilizaremos una arquitectura de tres niveles, que denominaremos arquitectura quier otra manera de esque-
de los componentes de almacenamiento, representada en la figura 1. matizar la realidad, es una he-
rramienta sencilla y potente
ideada para abstraer y enten-
Figura 1. Arquitectura de los componentes de almacenamiento der los rasgos fundamentales
de los sistemas más complejos.
2) Las tablas deben ser persistentes; por este motivo se almacenan en un so-
porte no volátil y utilizan unas estructuras determinadas, que son los compo-
nentes que constituyen el nivel�físico.
(1)
3) Entre los niveles físico y lógico existe un tercero que denominaremos nivel Abreviamos sistema gestor de ba-
1 ses de datos con la sigla SGBD.
virtual. Este nivel proporciona al SGBD una visión simplificada del nivel fí-
sico, como ya veremos.
Terminología
Ya conocéis los componentes del nivel lógico. En este módulo presentamos En este módulo denominamos
programador a la persona que
los componentes de los otros dos niveles, el virtual y el físico, que denomina- confecciona programas que
interaccionan con la base de
mos conjuntamente componentes de almacenamiento porque controlan la dis- datos, normalmente median-
posición física de los datos en el soporte no volátil. te sentencias de SQL, y usua-
rio final, a la persona que inter-
acciona con los datos directa-
mente por medio de una inter-
faz gráfica.
CC-BY-NC-ND • PID_00223667 9 Diseño físico de bases de datos
2. El nivel lógico
Aunque los componentes del nivel lógico ya se estudian en otro módulo di- Ved también
dáctico, recordaremos brevemente los conceptos más importantes para poder
Podéis ver los componentes
relacionar los componentes lógicos con los de los niveles físico y virtual. del nivel lógico en el módulo
“Diseño lógico de bases de da-
tos” de esta asignatura.
2.1. Componentes lógicos
El usuario puede acceder directamente a las tablas o bien puede acceder a estas
de manera indirecta por medio de las vistas; por este motivo, tablas y vistas
están agrupadas como el conjunto de componentes de datos.
(2)
Una base de datos tiene, aun así, otros componentes que no son las tablas y En inglés, constraints.
las vistas, pero que están estrechamente relacionados con éstas. Se trata, entre
(3)
otros, de las restricciones2, que definen ciertas reglas que tienen que cumplir En inglés, triggers.
los datos, o los disparadores3, los cuales indican acciones que se tienen que
ejecutar si se cumplen ciertas condiciones. Denominamos todos estos otros
componentes conjunto de componentes de control, puesto que en cierto modo
permiten controlar los datos dinámicamente.
3. El nivel físico
(4)
Los sistemas operativos gestionan los datos en los discos magnéticos a partir de En inglés, files.
4
unas unidades globales denominadas ficheros . Normalmente, el sistema ope-
(5)
rativo no reserva una gran cantidad de espacio de disco para cada fichero, sino En inglés, extent.
3.1. La página
(7)
Para entender qué es una página de una BD7 o de un SGBD, no partiremos de Abreviamos base de datos con la
sigla BD.
una definición, sino de una descripción de lo que es una página en una BD
desde dos puntos de vista diferentes, aunque complementarios:
(8)
• Los datos se almacenan en dispositivos externos pero, por otro lado, sabe- Abreviamos sistema operativo
con la sigla SO.
mos que para efectuar cualquier operación tienen que estar presentes en
la memoria principal del ordenador. Debe haber, pues, un transporte de
datos entre la memoria externa (que normalmente es un disco) y la me-
moria interna (o memoria principal). Este transporte se hace empleando
una unidad discreta de transporte de datos que en los SO8 se denomina
bloque y en los SGBD recibe el nombre de página.
(9)
Que la página sea la unidad de organización del nivel físico no significa que Abreviamos la expresión entra-
da/salida con la sigla E/S.
no tenga su propia estructura interna. De hecho, en una página hay diferentes
componentes. A estos componentes que hay en el interior de la página sólo
Un símil artístico
pueden acceder las rutinas del SGBD, una vez la página ya está en la memoria
principal del ordenador. En cambio, a la página como unidad accede (para leer Imaginad que la página es un
9 cuadro. El SGBD sería entonces
y escribir) el subsistema de E/S del SO de la máquina. el pintor; es quien ve el interior
del cuadro y lo llena (lo pinta).
Una vez listo, lo envuelve y lla-
3.1.1. Estructura de una página ma a su mozo (el sistema ope-
rativo), que toma el cuadro y,
sin verlo, lo transporta al alma-
cén.
Para facilitar la explicación, ahora nos centraremos en las páginas que almace-
nan tablas. Estas páginas se suelen denominar páginas de datos. Más adelante,
ampliaremos algunos detalles para generalizar la estructura de la página. El tamaño de una página
los SGBD.
c) Un espacio�libre.
(10)
d) Un vector�de�direcciones�de�fila (VDF), que tiene tantos elementos como Abreviamos la expresión vec-
10 tor de direcciones de fila con la sigla
filas hay en la página. Cada elemento del VDF contiene la dirección de una VDF.
fila dentro de la página (apunta a la fila). El elemento que ocupa la posición de
dirección más alta en el VDF apunta a la fila que ocupa la dirección más baja en
la página, tal y como podéis ver en la figura 2. La fila siguiente (a continuación
de la primera) está apuntada por el elemento del VDF a la izquierda del primer
elemento.
Así pues, las filas se van colocando de izquierda a derecha en el orden creciente
de las direcciones dentro de la página, mientras que los elementos del VDF se
van colocando de derecha a izquierda desde la posición más alta y siguiendo en
el orden decreciente de las direcciones. De este modo, el espacio libre siempre
queda hacia la mitad de la página.
Hemos visto que una página está formada por filas y que una fila está formada
por campos. Un campo de una fila de una tabla (nivel lógico) se almacena
como uno de los campos de la fila dentro de la página (nivel físico).
La cabecera del campo permite guardar ciertas características del campo, como
por ejemplo:
b) La longitud del campo, también en un momento concreto. Esta informa- CHARACTER VARYING
ción es necesaria cuando el campo se ha definido con un tipo de dato de lon-
CHARACTER VARYING es
gitud variable, como por ejemplo el tipo CHARACTER VARYING. el nombre del estándar
SQL:1999 para el tipo de dato
“cadena de caracteres de lon-
gitud variable”, que en varios
SGBD comerciales se denomi-
na VARCHAR.
CC-BY-NC-ND • PID_00223667 14 Diseño físico de bases de datos
(11)
• Tipo CHARACTER(n) o, de manera abreviada, CHAR(n): cadena de n by- Bytes codificados en código AS-
11 CII o bien en el código que utili-
tes , donde n es la longitud definida en el tipo de dato. ce la máquina donde funciona el
SGBD.
• Tipo DATE: aunque externamente es una cadena de 8 dígitos (4 para el Ahorrar espacio en disco
año, 2 para el mes y 2 para el día), internamente se puede almacenar de
Los SGBD intentan ahorrar es-
manera que ocupe mucho menos espacio, por ejemplo 4 bytes, siguiendo pacio en el disco y tiempo de
un patrón de codificación propio de cada SGBD. proceso siempre que sea po-
sible. Por esto, si el campo no
admite nulos y es de longitud
fija (por ejemplo, CHAR(3)),
entonces esta información no
es necesaria y podemos pres-
3.1.4. Gestión de la página cindir de la cabecera. En este
caso, el campo ocupa solo el
espacio necesario para almace-
Después de ver cómo se organiza el espacio de una página y cuáles son sus con- nar su valor.
tenidos, describiremos brevemente las principales operaciones que un SGBD
hace de este espacio y estos contenidos. Son las siguientes:
(12)
De este modo el espacio libre va disminuyendo, pero siempre ocupa un lugar Abreviamos administrador de la
12 base de datos con la sigla DBA, de
en torno al centro de la página. El administrador de la base de datos (DBA ) la expresión inglesa database admi-
normalmente habrá fijado un tanto por ciento de espacio libre mínimo que el nistrator.
SGBD tiene que respetar en una carga masiva de filas. Esto significa que, cuan-
do el proceso de carga detecta que el espacio que queda libre en una página Administrador de la BD
es precisamente este espacio libre mínimo, ya no coloca más filas y empieza El administrador de la BD (da-
a hacerlo en la página siguiente. tabase administrator, DBA) es
la persona -o equipo de perso-
nas- encargada, entre otras co-
sas, de la gestión de los com-
La finalidad de esta limitación es dejar un cierto espacio libre en todas las pá- ponentes de almacenamiento.
ginas para que sea aprovechado para las operaciones que veremos a continua-
ción.
Añadir una fila
3)�Alta�posterior�de�una�nueva�fila. Para añadir una fila a una tabla de la BD, Las filas se añaden con la sen-
tencia INSERT.
el SGBD en el nivel físico localiza primero la página donde tiene que añadir la
fila. Esta página se denomina página candidata. Una vez el SGBD sabe cuál es la
página candidata, utiliza el espacio libre disponible en la página para colocar
la fila y dejarla apuntada por un nuevo elemento del VDF. La fila y el elemento
del VDF se colocan según el criterio explicado anteriormente.
Como en el caso de las filas que ocupan más de una página, no os preocupéis
tampoco si no acabáis de entender, a partir de la figura, la manera como se
apunta a la fila que se ha trasladado de la página original a la nueva. Lo veréis
más adelante.
Hasta ahora nos hemos centrado en las páginas que contienen filas de tablas,
las páginas de datos. Cómo sabéis muy bien, en el nivel lógico hay otros com-
ponentes. De todos modos, la estructura de página que acabáis de ver sirve de
base para entender los otros tipos de páginas.
En efecto, dejando los índices aparte, todos los demás componentes (vistas,
restricciones, disparadores, etc.) son definiciones que alguien ha proporciona-
do al SGBD mediante el lenguaje SQL. Estas definiciones, como explicamos
más adelante, se guardan en unas tablas diseñadas especialmente para conte-
nerlas, pero que a todos los efectos que aquí nos interesan son tablas como
las que contienen los otros datos. Así pues, una vez en el nivel físico, todo
lo que hemos visto hasta ahora es válido para las tablas que contienen estos
componentes.
Los índices son un caso ligeramente distinto, y también lo son las tablas con Reflexión
datos del tipo objeto grande. La estructura del bloque que utilizan es similar,
Queda fuera del alcance de es-
pero varía su contenido. te módulo el estudio en pro-
fundidad de los diferentes ti-
pos de páginas.
CC-BY-NC-ND • PID_00223667 17 Diseño físico de bases de datos
3.2. La extensión
Es importante notar que cuando a petición del SGBD, el SO gestiona los datos Algunas estrategias del SO
en el soporte no volátil de los periféricos, lo hace siempre dentro del marco de
Algunas de las estrategias que
un fichero. Así, la adquisición de una extensión también tiene lugar dentro de utiliza el SO cuando no pue-
este marco. Esto significa que cuando se detecta que falta espacio en un fichero, de asignar páginas físicamente
consecutivas son, por ejemplo,
se adquiere una extensión para este fichero. La extensión está, pues, asociada partir la extensión en trozos o
devolver un aviso que indique
a un fichero, es parte de él. Y el fichero es, entre otras cosas, un conjunto de que no hay suficiente espacio.
extensiones.
La razón principal por la cual las páginas en una extensión deben ser contiguas es que, de
este modo, los componentes que son lógicamente consecutivos (por ejemplo, las filas de
una tabla) se pueden almacenar de manera consecutiva y se pueden recuperar del mismo
modo, y así se favorecen los tratamientos que impliquen la recuperación consecutiva de
todos los componentes (tratamientos que son frecuentes en las BD relacionales).
Por otro lado, los mecanismos más avanzados de mejora de rendimiento que encontraréis
esbozados en el subapartado que nos da una visión general de la E/S en un SGBD, tienen
sentido sólo si las páginas sobre las que actúan son consecutivas.
3.3. El fichero
Extensiones de un fichero
Normalmente, los SGBD permiten definir dos tipos de extensiones. Una se denomina
extensión�primaria y la otra, extensión�secundaria. Estas dos extensiones pueden ser –
y normalmente lo son– de longitud diferente, pero ambas son un múltiplo de la página.
Cuando un fichero necesita espacio por primera vez, se adquiere el número de páginas
correspondientes a la extensión primaria. A partir de este momento, las extensiones su-
cesivas que se vayan necesitando en este fichero adquirirán el número de páginas de la
extensión secundaria. Para un fichero solo hay una extensión primaria (la primera), pero
hay varias secundarias (las siguientes). El número máximo de extensiones secundarias lo
fija el sistema operativo o el SGBD, y suele ser una potencia de dos (16, 128, 256, etc.).
1)�Entrada/salida�de�ficheros�clásicos
Para leer datos, por ejemplo, el SO desencadena una operación de E/S para
llevar hacia la memoria principal el bloque que contiene los datos que se ne-
cesitan. Este bloque es una unidad físicamente delimitada y direccionable en
el conjunto de los datos grabados en el soporte no volátil (el disco magnético).
CC-BY-NC-ND • PID_00223667 19 Diseño físico de bases de datos
Después, el bloque viaja por el canal que une el periférico con la unidad cen-
tral del ordenador y, finalmente, el bloque se coloca en la memoria principal
y puede ser tratado por los programas.
2)�Entrada/salida�en�las�bases�de�datos
intermedia14.
(14)
En inglés, buffers.
Finalmente, para ilustrar las funciones propias de el SGBD y las del sistema
operativo a la entrada/salida, pasamos a comentar la figura 9.
4. El nivel virtual
a) Hay tablas muy grandes que nos interesará fragmentar y almacenar cada
fragmento en un dispositivo diferente con el fin de mejorar el acceso a los
mismos.
c) Cada vez más se usan tablas que, además de campos con datos de tipo tradi-
cional (cantidades numéricas, cadenas de caracteres que representan nombres
y direcciones, fechas, etc.), tienen otros que almacenan tipos de datos diferen-
tes, como por ejemplo gráficos, imágenes o algunos minutos de audio o de
vídeo. Estos datos, que necesitan muchos más bytes para ser almacenados, son
los objetos grandes y que interesa almacenar en ficheros diferentes de los que
se emplean para los datos tradicionales, para mejorar los tiempos de acceso.
d) A pesar de que hasta ahora sólo hemos mencionado las tablas, todos sabéis Recursos limitados
que hay otros componentes, como por ejemplo índices, definiciones de dis-
El interés por no querer con-
paradores, etc. Al igual que en el punto anterior, seguramente interesará al- sumir más recursos de los im-
macenar cada componente en ficheros estructurados de manera distinta, para prescindibles reside en el he-
cho de que hay algunos SGBD
obtener el máximo rendimiento de ellos. que soportan sólo un número
determinado de ficheros.
Todos estos ejemplos tienen que advertirnos de que resulta bastante útil dis-
poner de un nivel intermedio. Nos proporciona un grado elevado de flexibili-
dad (o independencia) para asignar componentes lógicos a los componentes
físicos, puesto que no hay que hacerlo de una manera estrictamente biunívoca
CC-BY-NC-ND • PID_00223667 22 Diseño físico de bases de datos
(15)
Abreviamos espacio virtual con
Hemos visto que la función del nivel virtual es proporcionar un grado la sigla EV.
elevado de independencia entre los niveles lógico y físico. Denomina-
mos espacio�virtual (EV15) al componente que implementa esta fun-
cionalidad.
Normalmente, en todos los SGBD una tabla se asocia a un único EV. Por el
contrario, un EV puede estar asociado a una o más tablas. Por otro lado, la
asociación entre EV y fichero suele ser de muchos a muchos: un EV se asocia
a uno o más ficheros y un fichero se corresponde uno o más EV.
El EV es una visión diferente de las páginas del nivel físico. Al igual que una
vista en el modelo relacional es otra manera de ver los datos de una tabla sin
que esto represente duplicar físicamente los datos de la tabla, el espacio virtual
es una manera distinta de organizar las páginas que hemos visto en el nivel
físico, pero sin duplicarlas materialmente.
Las únicas páginas que realmente existen son las del nivel físico, agrupadas
en extensiones y almacenadas en ficheros. Ahora bien, estas páginas no de-
ben estar necesariamente ordenadas en el soporte físico. Incluso páginas que
contienen elementos que en el nivel lógico son consecutivos (por ejemplo, las
filas de una tabla) pueden estar separadas unas de otras en el nivel físico (por
ejemplo, ocupando extensiones diferentes); en algunos casos, el resultado de
la combinación de varias tablas se puede almacenar en un espacio virtual, si
conviene tenerlo precalculado.
b) Las vistas del modelo relacional. Los datos de una vista son los que realmente existen
en una o más tablas, pero dispuestos de otro modo, sin que esto represente una duplica-
ción de estos datos.
El espacio virtual está constituido por las imágenes de las páginas reales (imá-
genes que denominaremos páginas virtuales) ordenadas secuencialmente y si-
tuadas de manera contingua (sin saltos en medio).
CC-BY-NC-ND • PID_00223667 24 Diseño físico de bases de datos
Observad que las distintas páginas que contienen, por ejemplo, las filas de
una tabla, están distribuidas entre extensiones diferentes de ficheros distintos.
El EV es una ficción para ver y tratar todas estas páginas como si estuvieran
ordenadas de manera consecutiva.
En el nivel lógico, tenemos la tabla Student con sus filas. Esta tabla se almacena
en páginas de datos en el nivel físico. Por la manera como se ha ido creando
la tabla y por la disponibilidad de espacio libre en el disco, puede haber suce-
dido que no todas las filas de la tabla hayan quedado en páginas consecutivas.
Observamos que las páginas que contienen estas filas pertenecen a dos exten-
siones diferentes, separadas por otra extensión que puede ser de otro fichero
y, evidentemente, puede contener otros datos.
CC-BY-NC-ND • PID_00223667 25 Diseño físico de bases de datos
No podemos asegurar la contigüidad de las filas del nivel lógico en las páginas
del nivel físico. Entonces, el EV nos permite ver todas las páginas que contie-
nen las filas de esta tabla de manera consecutiva y sin saltos.
1)�Primer�paso:�del�nivel�lógico�al�virtual
Puesto que la unidad más pequeña que dirige de manera explícita un SGBD es Tratamiento de los
la fila, lo que hace realmente el SGBD es encontrar las filas dentro del espacio campos
virtual. El direccionamiento del SGBD es, pues, del nivel lógico al nivel virtual. Una vez la fila está en la me-
moria, el SGBD, dado que co-
noce su estructura, puede lo-
Para localizar las filas en el EV, los SGBD utilizan una dirección que denomi- calizar todos sus campos y tra-
tarlos individualmente.
naremos identificador�de�fila (RID). El RID, como podemos ver en la figura
14, tiene dos partes diferenciadas:
El identificador de fila
(RID)
• el número de la página que contiene la fila dentro del espacio virtual aso-
ciado a la tabla a la cual pertenece la fila, RID es un acrónimo del tér-
mino inglés row identifier. Este
• el número de elemento del VDF de esta página que apunta a la fila. identificador recibe diferentes
nombres según las implemen-
taciones de cada SGBD. Por
Tal como indicamos en la figura 14, el RID normalmente es una dirección de ejemplo, en el caso de Oracle
recibe el nombre de ROWID.
4 bytes, 3 para el número de página y 1 para el número de elemento del VDF.
a) Una fila, una vez dada de alta en una página, no puede cambiar de página
mientras esté viva, puesto que su dirección también cambiaría. Dado que esta
dirección puede estar guardada en más de un lugar de la base de datos, interesa
no hacer este cambio para evitar el mantenimiento inútil y costoso de otras
estructuras de datos (por ejemplo, en los índices que se hayan construido sobre
esta tabla).
2)�Segundo�paso:�del�nivel�virtual�al�físico
De este modo, el SGBD pide al SO que le lea/guarde una página concreta y este
lo hace empleando una dirección muy diferente del RID. Por lo tanto, en este
paso hay una transformación de direcciones: del RID a una dirección física
que depende de la arquitectura del dispositivo.
A partir del diseño lógico de una base de datos debemos llegar a su diseño
físico, pasando por el nivel virtual. La forma de implementar un diseño lógico
en un SGBD concreto depende de las características propias de cada uno de los
SGBD. Y las características propias de cada SGBD son un reflejo del entorno:
1) Transformar las tablas con las correspondientes claves primarias, claves fo-
ráneas y claves alternativas, a partir del diseño lógico de la base de datos que
hemos obtenido en el paso anterior.
3) Para terminar, relacionamos cada espacio virtual con un fichero físico y de-
finimos sus características. Esto constituye el diseño físico de la base de datos.
CC-BY-NC-ND • PID_00223667 30 Diseño físico de bases de datos
De manera adicional es preciso completar esta definición con los índices ne-
cesarios para garantizar un acceso correcto a los datos, además de las restric-
ciones necesarias sobre los datos (valores nulos, valores únicos de los campos,
etc.).
5.1. Tabla
La sentencia CREATE TABLE de todos los SGBD incorpora las cláusulas del
estándar SQL y, además, el enlace con los elementos físicos propios de cada
uno.
A continuación, veremos con más detalle las definiciones relativas a clave pri-
maria y clave alternativa, índice y algunas de las restricciones más relevantes.
Como ya sabemos, la clave primaria tiene que ser obligatoriamente una clave
única y que no admita valores nulos. La teoría del modelo de bases de datos
relacionales sugiere que cada tabla debería tener una clave primaria que iden-
tificara de manera unívoca la entidad que describe. A pesar de esto, el estándar
SQL no obliga a la existencia de una clave primaria en cada tabla, sino que
es opcional. Lógicamente, sin embargo, cada tabla puede tener como máximo
una clave primaria.
El resto de las claves únicas y que no admiten valores nulos son claves alter-
nativas a la clave primaria. Esto tampoco está legislado en el estándar SQL.
5.1.2. Índice
Los índices son unos elementos del diseño físico de la base de datos que tienen
como finalidad mejorar el rendimiento de las aplicaciones cuando acceden a
las tablas. Los índices no forman parte del diseño lógico de la base de datos y,
por lo tanto, no están incluidos en el estándar SQL.
Aun así, la sentencia CREATE INDEX está presente en todos los SGBD con
opciones muy similares. A continuación, veremos el detalle de esta sentencia
sobre el SGBD Oracle. Además, incorpora cláusulas para definir el espacio para
índices y cláusulas de enlace con los elementos físicos propios (los ficheros de
índices).
Donde:
5.1.3. Restricciones
Estas restricciones nos permiten definir una lógica que nos ayude a validar los
datos de nuestro modelo, de manera que cumplan determinadas condiciones.
a)�Check
Esta restricción permite indicar ciertas condiciones que el valor del registro
debe cumplir para ser admitido en la tabla.
Por ejemplo, podemos definir una tabla con información sobre trabajadores,
que contenga como atributos el nombre y el sueldo. Evidentemente, el suel-
do debe ser positivo. Para indicarlo, en la creación de la tabla utilizamos la
restricción CHECK.
) TABLESPACE data_employees;
b)�Not�null
c)�Unique
Continuando con el ejemplo anterior, esta restricción nos permite definir que
cada trabajador debe tener un identificador único (por ejemplo, el DNI en el
caso de España), el cual debe ser único para cada persona.
d)�Foreign�key�/�References
Esta restricción permite crear claves foráneas que referencian atributos de otras
tablas.
Por ejemplo, si queremos crear una tabla que contenga los departamentos de
la empresa (Department) e indicar a qué departamento pertenece cada traba-
jador (Employees), será preciso crear la nueva tabla y añadir un atributo que
referencie la nueva tabla para cada registro de la tabla Employees.
departId number(6),
CONSTRAINT fkDep FOREIGN KEY (departId) REFERENCES Department (id)
) TABLESPACE data_employees;
Donde:
• Cada espacio para tablas se asocia a uno o más ficheros físicos <filespec>.
En el ejemplo siguiente crearemos un espacio para tablas con el nombre users_data for-
mado por el fichero ‘/db/users/users_data1.dbf’ y con un tamaño total de 100 MB.
Como en el caso del espacio para tablas, la base de datos no pertenece al diseño
lógico de la base de datos y, por lo tanto, tampoco está incluida en el estándar
SQL.
Donde:
• Los ficheros físicos que contienen los espacios para tablas se relacionan en
la cláusula DATAFILE < filespec >.
CC-BY-NC-ND • PID_00223667 37 Diseño físico de bases de datos
En el siguiente ejemplo crearemos una base de datos para una universidad, con unos
diarios (logfiles) de 10 MB cada uno y con unos límites de 5 logfiles y 100 datafiles.
En una base de datos hay datos almacenados a los que se debe acceder para
hacer consultas y actualizaciones. Por este motivo, una de las funciones de los
SGBD es la de proporcionar el acceso a los datos que gestionan. La problemá-
tica de cómo ofrecer este acceso es el objeto de estudio de este apartado.
Una de las funciones de los SGBD es proporcionar el acceso a los datos que Reflexión
gestionan. El acceso a los datos debe permitir consultar y actualizar los datos
Debemos entender “actuali-
almacenados. Siempre que se lee o se graba algún dato en una BD se hace zaciones de datos” en sentido
mediante alguno de los métodos de acceso de los que dispone el SGBD. amplio; es decir, su inserción,
eliminación y modificación.
En este subapartado, para presentar los métodos de acceso a los datos de ma-
nera comprensible, supondremos siempre que los datos a los que hay que ac-
ceder se perciben según la visión que proporciona el nivel virtual, y no según
la del nivel físico. Así pues, casi siempre que en este módulo se emplea la pa-
labra página tenemos que interpretar que nos referimos a páginas virtuales; si
nos referimos a páginas reales, lo mencionaremos de manera explícita.
Con objeto de simplificar, también supondremos que todos los accesos se ha-
cen a datos almacenados en una sola tabla, situada en un único EV. Así pues,
no consideramos los casos en que es necesario combinar datos de tablas (y
espacios) diferentes para obtener los datos a los que queremos acceder.
En este subapartado, veremos los tipos de acceso más simples que utilizan los
SGBD.
CC-BY-NC-ND • PID_00223667 39 Diseño físico de bases de datos
Estos tipos de acceso simples son suficientes para casos en los que solo haya
que efectuar consultas y actualizaciones muy sencillas en la BD.
En la base de datos anterior podríamos realizar una consulta para recuperar los datos de
todos los empleados, como por ejemplo la siguiente:
Para resolver esta consulta, el SGBD puede utilizar el acceso secuencial por posición, me-
diante el cual el SGBD va obteniendo todas las páginas que contienen las filas de los
empleados. De este modo, puede proporcionar los empleados en el mismo orden en que
los obtiene. Observad que la consulta no requiere ninguna ordenación particular de los
empleados y, entonces, el SGBD los puede proporcionar en el mismo orden en el que
están almacenados.
• Sentencia 1:
• Sentencia 2:
• Sentencia 3:
Observad que en los tres ejemplos hay que buscar las filas de los empleados que tienen un
número de despacho (officeNum) determinado, para mostrarlos, modificarlos o borrarlos,
respectivamente. Es decir, en los tres casos hay que hacer búsquedas de un valor por un
atributo determinado.
De estos ejemplos, se deduce que el acceso directo por valor es necesario para ejecutar
consultas y actualizaciones sobre filas que contienen un determinado valor de un atri-
buto.
• Sentencia 1:
• Sentencia 2:
• Sentencia 3:
• Sentencia 4:
En la primera de las sentencias hay que obtener los empleados ordenados por el número
de despacho, debido a la cláusula ORDER BY officeNum. Para ejecutar las tres sentencias
restantes también debe disponer del acceso secuencial por valor, aunque la causa es quizá
menos evidente. La cláusula WHERE officeNum >= 100 AND officeNum <= 300 implica
que sea necesario localizar todos los empleados que tienen un número de despacho entre
el 100 y el 300 para consultar los datos, modificarlos o borrarlos, respectivamente. Una
manera de localizar todos los empleados es disponer de algún mecanismo de acceso a
cada uno de ellos por orden de número de despacho a partir del valor 100 y hasta el 300.
Este mecanismo es el acceso secuencial por valor.
De los ejemplos anteriores, se desprende que el acceso secuencial por valor se utiliza para
ejecutar consultas en las que el resultado debe estar ordenado por un atributo y para
consultas o actualizaciones que afecten a un conjunto de filas que contienen el valor de
un atributo que se encuentra dentro de un rango determinado de valores.
Hemos considerado accesos por valor de un solo atributo. Nos falta considerar Los accesos por varios
los casos en los que se quiere acceder según los valores de varios atributos: los valores
accesos por varios valores. Los accesos por varios valores pueden ser, como los Los accesos por varios valores
accesos por un solo valor, directos o secuenciales. no tienen su correspondiente
en tecnología de los ficheros,
a diferencia de lo que sucedía
Ejemplos de acceso por varios valores con los otros accesos que he-
mos explicado.
Consideremos los ejemplos siguientes de acceso por varios valores:
• Sentencia 1:
SELECT *
FROM Employees
WHERE officeNum = 150 AND salary = 2000;
• Sentencia 2:
SELECT *
FROM Employees
ORDER BY officeNum, salary;
• Sentencia 3:
DELETE *
FROM Employees
WHERE officeNum >= 100 AND salary >= 1800;
En estos ejemplos, se accede a los datos según los valores de dos atributos: el atributo
officeNum y el atributo salary. La primera sentencia corresponde a un acceso directo por
varios valores y las dos siguientes, a un acceso secuencial por varios valores.
También puede ocurrir, sin embargo, que los accesos por varios valores sean
mixtos.
CC-BY-NC-ND • PID_00223667 42 Diseño físico de bases de datos
Los accesos�mixtos por varios valores son accesos en los que se combina
el acceso directo por valores de algunos atributos y el acceso secuencial
por valores de otros atributos.
• Sentencia 1:
SELECT *
FROM Employees
WHERE officeNum = 150 AND salary >= 2000;
• Sentencia 2:
SELECT *
FROM Employees
WHERE salary = 2000
ORDER BY officeNum;
• Sentencia 3:
DELETE *
FROM Employees
WHERE officeNum >= 100 AND officeNum <= 300 AND salary = 2000;
La primera de las sentencias combina un acceso directo por valor del atributo officeNum
con un acceso secuencial por valor del atributo salary. Las dos siguientes combinan un
acceso secuencial por valor del atributo officeNum con un acceso directo por valor del
atributo salary.
Para la implementación de los accesos por posición, los SGBD se basan casi
completamente en el SO. Las rutinas de gestión de E/S del SO permiten obtener
una página real si tenemos su dirección y también permiten grabar en el disco
una página real concreta. Podríamos decir que el SO implementa el acceso por
posición en páginas reales.
Empezaremos explicando por qué los índices son necesarios si se desea obtener
un buen rendimiento al realizar accesos por valor. Para ello, presentaremos
algunas implementaciones que no los utilizan y veremos los problemas que
comportan.
Hay que tener en cuenta que las filas de la tabla EMPLEADOS se encuentran en
un espacio virtual. Por lo tanto, ya que disponemos del acceso secuencial por
posición a las páginas del espacio virtual, el SGBD puede emplear este acceso
para obtener todas las páginas una a una, comprobando para cada una, qué
filas contienen el valor buscado.
Ahora analizamos otro ejemplo que requiere un acceso secuencial por valor;
podéis observar la sentencia siguiente:
Las soluciones que hemos analizado para implementar los accesos por valor
no nos permiten conseguir un rendimiento lo suficientemente aceptable en
muchos casos. A continuación, analizaremos la manera como los índices nos
permitirán mejorar esta situación.
Existen índices de muchos tipos diferentes, pero todos tienen algunas carac-
terísticas generales comunes como implementaciones adecuadas de los acce-
sos por valor. Los índices de los SGBD tienen una utilidad parecida a la de
los índices que contienen los libros para localizar rápidamente un apartado
determinado.
El índice de un libro
Este módulo tiene un índice al principio. Si queremos localizar con rapidez el subapartado
dedicado a los árboles B+, lo que debemos hacer es consultar el índice. Allí encontraremos
fácilmente el número de página donde está situado el subapartado de los árboles B+,
porque el índice no es muy largo y no tardaremos en leerlo. Una vez conocido el número
de página, solo debemos localizar la página que lleva aquel número.
Los índices que emplean los SGBD son unas estructuras de datos auxi-
liares que, como los índices de los libros, facilitan las búsquedas sobre
unos determinados datos.
Uno de los motivos por los cuales las búsquedas pueden ser más rápidas si se
realizan mediante un índice en lugar de acceder directamente a los datos, es
que los índices suelen ocupar menos espacio que los datos.
CC-BY-NC-ND • PID_00223667 45 Diseño físico de bases de datos
Las filas que contienen los datos generalmente son voluminosas porque al-
macenan muchos atributos. Los índices, en cambio, normalmente contienen
sólo una colección de parejas, denominadas entradas, formadas por un valor
y un RID.
Las filas de una tabla de empleados podrían registrar el número de empleado, su nombre,
DNI, dirección, teléfono, sueldo, número de despacho, departamento donde está asigna-
do, etc. En cambio, si queremos tener un índice para acceder a los empleados según su
número de empleado, las entradas del índice tendrán que estar formadas sólo por un
número de empleado y un RID.
De los párrafos anteriores, podemos deducir que los SGBD utilizan el acceso
por posición para implementar los accesos por valor.
Un índice tiene que estar organizado de alguna manera que facilite las bús- Ejemplo
quedas de los valores que contiene. Hay varias maneras de organizar los ín-
Sobre una tabla que contiene
dices: los árboles B+, las funciones de dispersión, etc. Algunos de estos tipos datos de empleados podemos
tener un índice que facilite el
de índice sólo facilitan el acceso directo por valor (por ejemplo, las funciones acceso por número de emplea-
de dispersión); otros sirven tanto para el acceso directo como para el acceso do, otro que facilite el acceso
por nombre, otro que facilite
secuencial por valor (por ejemplo, los árboles B+). el acceso por número de des-
pacho, etc.
Una característica muy útil de la mayoría de los tipos de índice es que permiten
la posibilidad de tener varios índices sobre unos mismos datos.
CC-BY-NC-ND • PID_00223667 46 Diseño físico de bases de datos
Más adelante, estudiamos los tipos de índices que utilizan más a menudo los Observación
SGBD para implementar los accesos por valor: los estructurados como árboles
Observad que los índices tam-
B+ y los estructurados según funciones de dispersión. Cada SGBD tiene sus par- bién se pueden usar para im-
plementar los accesos que re-
ticularidades propias en la implementación de un tipo de índice determinado. quieren los ficheros por valor.
Dado que sería impracticable intentar explicar exhaustivamente y con todos
los detalles las implementaciones que hay, solo estudiamos los principios co-
munes a la mayoría de las implementaciones de índices estructurados como
árboles B+ y los de los índices estructurados mediante funciones de dispersión.
Estos principios nos facilitan la comprensión de las implementaciones parti-
culares que proporcionan los SGBD del mercado.
El cálculo del coste de ejecución de los accesos a los datos mediante la utiliza-
ción de índices es un aspecto que deberemos considerar de ahora en adelante
para evaluar la bondad de los diferentes tipos de índice. Para este cálculo, to-
mamos las convenciones siguientes:
(16)
1) Consideramos sólo el coste de las E/S y no otros componentes del coste, UCP es la sigla del término uni-
16 dad central de procesamiento.
como por ejemplo el que corresponde a los cálculos de la UCP . El motivo es
que el coste de las E/S es normalmente el componente dominante en el coste
de las operaciones que se llevan a cabo en las BD y nos proporciona una buena
aproximación a los costes reales.
6.3.3. Árboles B+
Es importante tener en cuenta que, a diferencia otros tipos de árboles, los ár-
boles B+ que estudiamos aquí están orientados a realizar búsquedas en el disco.
+
El estudio de los árboles B es muy interesante porque la mayoría de los siste-
mas comerciales (como por ejemplo Oracle, PostgreSQL, Informix, DB2, etc.)
los implementan.
Ejemplo
En primer lugar, hay que considerar que todo árbol B+ tiene un número
de orden d que indica la capacidad de sus nodos. Más concretamente, si
un árbol B+ tiene orden d, entonces sus nodos contienen como máximo
2d valores.
+
En un árbol B , los nodos internos y los nodos hoja tienen una estructura
diferente. Las causas de esta diferencia estructural son tres:
1) Los nodos hoja son los que contienen todas las entradas del índice (es decir,
las parejas de valor y RID).
2) Los nodos internos tienen como objetivo dirigir la búsqueda de la hoja que
tiene la entrada correspondiente a un valor determinado. El acceso directo por
valor consistirá, pues, en hacer un recorrido del árbol que empezará en la raíz
e irá bajando por los nodos del árbol hasta llegar a la hoja adecuada (la que
contiene, si existe, la entrada correspondiente al valor buscado).
3) Los nodos hoja están conectados por apuntadores, que sirven para facilitar
el acceso secuencial por valor (el recorrido de las hojas siguiendo los apunta-
dores proporciona las entradas ordenadas por valor).
+
Figura 18. Índice del árbol B
La figura 18 muestra un índice de árbol B+ de orden d = 1 que sirve para acceder a datos
de empleados según el valor del atributo “número de empleado”. Observad que los RID
que apuntan a los datos están sólo en los nodos hoja, que los nodos internos sirven para
buscar los valores de las hojas y que el hecho de que las hojas estén conectadas entre sí
facilita el acceso secuencial por valor.
1)�Estructura�de�un�nodo�interno
Cada vi indica un valor y cada fi indica un apuntador a un nodo hijo del árbol.
Si un nodo contiene n valores, entonces tiene n + 1 apuntadores a otros nodos
del índice.
Tal como indica la figura 19, se cumple que el subárbol del nodo apuntado
por fi contiene valores v tales que:
• v < v1, si i = 0.
• v ≥ vn, si i = n.
+
Figura 20. Ejemplo de árbol B de orden 2
Considerad el nodo raíz: tiene tres apuntadores que apuntan a sus nodos hijos. Observad
que el subárbol apuntado por el primero de estos apuntadores contiene valores menores
que 10. El subárbol apuntado por el segundo contiene valores mayores o iguales que
10 y menores que 45. Finalmente, el subárbol apuntado por el tercero contiene valores
mayores o iguales que 45.
2)�Estructura�de�un�nodo�hoja
De manera adicional, es preciso que los nodos hoja cumplan las condiciones
siguientes:
• Todos los valores de un nodo hoja son menores que los valores del nodo
hoja siguiente.
• Todos los valores de algún nodo interno del árbol están repetidos en alguna
hoja del árbol (así, las hojas contienen todos los valores del árbol).
Considerad, por ejemplo, el nodo hoja que está situado más a la izquierda. Contiene las
entradas del empleado número 2 y del empleado número 3. También tiene los apunta-
dores en la hoja anterior y en la siguiente del árbol (en este caso concreto, no existe hoja
anterior). Observad que todos los valores del nodo considerado (los valores 2 y 3) son
menores que los valores de la hoja siguiente (6 y 8). Finalmente, observad que el valor
6 de la segunda hoja está repetido en un nodo interno. El motivo es que en un árbol B+
las hojas deben contener todos los valores del árbol.
Accedemos primero al nodo raíz. Después, seguimos el primer apuntador porque 8 < 20.
A continuación, seguimos el segundo apuntador, dado que 6 ≤ 8 < 12, y localizamos el
nodo hoja que contiene la entrada del valor deseado.
+
Para realizar un acceso secuencial por valor con un índice del tipo árbol B es
necesario primero localizar ordenadamente todas las entradas de los valores
a los cuales se quiere acceder y, para cada una, usar el RID que apunta a los
datos para encontrar el valor.
La localización ordenada de las entradas del árbol es sencilla. Conviene recor- Observación
dar que las hojas contienen todos los valores del árbol, que cada hoja tiene
Si seguimos el procedimiento
un apuntador a la hoja siguiente y que los valores de un nodo hoja son me- de acceso secuencial por valor
nores que los valores del nodo hoja siguiente. Entonces, solo hay que acceder explicado en este subaparta-
do con el árbol de la figura 21,
primero a la hoja situada más a la izquierda y, después, ir accediendo cada vez iremos obteniendo todas las
entradas del árbol de manera
a la hoja siguiente hasta que se acabe la cadena de hojas. ordenada.
+
Consideremos un acceso directo por valor que se implementa con un árbol B .
Para localizar la hoja que contiene la entrada del valor, el número de nodos que
hay que recorrer es igual al del nivel de la hoja mencionada. En consecuencia,
si reducimos el nivel de las hojas de un árbol B+, conseguiremos reducir el
número de nodos que hay que recorrer cuando se hace un acceso directo por
valor.
+
Esta norma evita tener árboles B donde muchos de los nodos estén práctica-
mente vacíos. Si conseguimos que los nodos de un árbol no estén demasiado
vacíos, el árbol tendrá menos nodos y también menos niveles.
CC-BY-NC-ND • PID_00223667 53 Diseño físico de bases de datos
Tal y como ya hemos visto, por las peculiaridades de los índices es aconsejable
gestionarlos de manera separada de los datos de las tablas. Por este motivo,
existe un tipo de espacio virtual para contener los índices denominado espacio
de índices.
El hecho de que los nodos sean del tamaño de una página (que almacena
normalmente 4 kB) permite tener típicamente árboles de órdenes entre 50 y
100.
CC-BY-NC-ND • PID_00223667 54 Diseño físico de bases de datos
b) Consideremos ahora un árbol de orden d = 50, de altura h = 3 y donde todos los nodos
tienen una ocupación del 69%. Si d = 50, la capacidad máxima de los nodos es de 100 y
una ocupación del 69% supone tener 69 valores en cada nodo. En este árbol, tendremos
el número de valores siguiente en cada nivel:
Es decir, 338.100 entradas en total. Según esto, el árbol B+ anterior, que tiene una altura
de solo 3 niveles, nos permite indexar un volumen de datos de 338.100 filas.
Inserciones y supresiones
Las inserciones y supresiones se tienen que hacer de manera que el árbol resul-
tante satisfaga todas las propiedades de los árboles B+. Esto implica en algunos
casos realizar una reestructuración del árbol.
A)�Inserciones
Describimos un algoritmo que, dada una entrada, localiza el nodo hoja que le
corresponde y, si este nodo tiene espacio libre, se la inserta. En el supuesto de
que este nodo hoja no tenga espacio libre para la nueva entrada, reestructura
el árbol para encontrarle un lugar.
Comentaremos algunos ejemplos que nos ayudarán a entender con más exac-
titud qué debe hacer este algoritmo de inserción, cuya descripción detallada
queda fuera del alcance de este módulo.
+
Consideremos el árbol B de orden 2 de la figura 23.
Observad las diferencias que hay entre esta división y la división de un nodo
hoja.
Puesto que acabamos de dividir el nodo raíz del árbol, hay que crear un nue-
vo nodo raíz en el que se colocan el valor 27, el apuntador al nuevo nodo y
también un apuntador a la raíz antigua. El árbol que se obtiene finalmente es
el que podéis ver en la figura 27.
B)�Supresiones
a) Supongamos que queremos borrar el valor 45 del árbol. La hoja que contiene
la entrada del valor 45 es la que está situada más a la derecha. Después de borrar
45*, la hoja todavía contiene dos valores y, por lo tanto, no hay que hacer
ninguna reestructuración. El árbol obtenido es el que muestra la figura 28.
CC-BY-NC-ND • PID_00223667 57 Diseño físico de bases de datos
b) Ahora supondremos que queremos borrar el valor 8 del árbol que acabamos Nodos hermanos
de obtener. Su entrada está situada en la segunda hoja del árbol. Después de
Dos nodos son hermanos si
borrarla, la hoja se queda con menos de dos entradas, por lo que hay que comparten el mismo nodo pa-
corregirlo. Para garantizar que la ocupación de un nodo sea correcta, es decir, dre.
En nuestro ejemplo, puesto que el nodo hermano de la derecha tiene tres en-
tradas, se hace una redistribución de entradas entre los dos nodos hoja. La
figura 29 ilustra esta redistribución.
Observad que la redistribución afecta al contenido del nodo padre de los dos
nodos participantes. El valor 12 del nodo padre se cambia por el 15. El árbol
que se obtiene finalmente es el que se muestra en la figura 30.
c) Consideremos ahora el caso del borrado del 35 del árbol que acabamos de
obtener. La entrada del 35 está situada en la penúltima hoja. Después de bo-
rrarla, la hoja se queda con menos de dos entradas, de modo que hay que lle-
CC-BY-NC-ND • PID_00223667 58 Diseño físico de bases de datos
Observad que cuando se fusionan dos nodos, su nodo padre pierde un valor.
Debido a esta pérdida, el nodo padre de nuestro ejemplo nos ha quedado con
menos de dos valores. En este caso, será preciso hacer todavía otra reestructu-
ración del árbol para corregirlo. El nodo padre no tiene ningún hermano a la
derecha; por lo tanto, usaremos el de la izquierda para reestructurar el árbol.
El hermano de la izquierda tiene solo dos valores, por lo que se hará una fusión
de ambos nodos. La figura 32 nos ilustra esta fusión de dos nodos no-hoja.
Después de esta última fusión, nos ha quedado un árbol con la raíz vacía. En
estos casos hay que descartar la raíz antigua y construir la raíz nueva con el
nodo resultante de la fusión. Finalmente, se obtiene el árbol que muestra la
figura 33.
CC-BY-NC-ND • PID_00223667 59 Diseño físico de bases de datos
+
d) Para el último ejemplo de supresión, elegimos el árbol B de partida que
muestra la figura 34.
+
Entonces, el árbol B que se obtiene finalmente es el que muestra la figura 37.
C)�Supresiones�de�valores�que�tienen�una�copia�en�nodos�internos
+
Hemos analizado un procedimiento de borrado de los valores de un árbol B
que sólo aparecen en un nodo hoja del árbol. Como ya sabemos, un árbol B+
puede tener valores que figuran en dos lugares: en un nodo hoja y en un nodo
no-hoja (nodo interno). Para borrar los valores que tienen una copia en nodos
internos, podemos utilizar el mismo procedimiento si hacemos previamente
una sustitución del valor copiado en el nodo interno por el valor del árbol que
le sigue según el orden de los valores. Una vez hecho esto, podremos emplear
el procedimiento de supresión anterior para eliminar el valor de la hoja.
Figura 38. Supresión de valores que tienen una copia en nodos internos
Valores repetidos
+
En las búsquedas, inserciones y supresiones de los árboles B que acabamos
de explicar no hemos considerado la posibilidad de que pudiera haber valores
repetidos en los datos; hemos considerado que indexábamos los valores de
atributos identificadores.
CC-BY-NC-ND • PID_00223667 61 Diseño físico de bases de datos
2) Otra posibilidad es tener una sola entrada que contenga varios RID (uno
para cada aparición del valor). Esta posibilidad provoca que el tamaño de las
entradas sea variable y que su gestión resulte más compleja. Por el contrario,
se ahorra espacio porque el valor en entradas diferentes no se repite, y, en
consecuencia, se ahorran operaciones de E/S.
6.3.4. Dispersión
(17)
Otros tipos de índices sirven para facilitar el acceso directo por valor, pero no En inglés, hashing.
17
el acceso secuencial por valor: son los índices basados en la dispersión .
Introducción a la dispersión
Queremos indexar unos datos por el valor de un atributo que representa nombres de pila.
Supongamos que h(Juan) = 3, h(Marta) = 1 y h(Rosa) = 4. Entonces, las entradas de estos
valores quedarán colocadas en las páginas del índice tal y como se muestra en la figura 39.
Para localizar la entrada del valor Rosa en el índice anterior, calcularemos h(Rosa). Este
cálculo nos dará el número de página 4. Luego, accederemos a la página 4, donde encon-
traremos la entrada correspondiente a Rosa.
Observad que el número de valores posibles puede ser muy grande, mientras Ejemplo
que el número de páginas que puede ocupar el índice en el disco suele ser
Pensad en valores de un atri-
mucho más limitado. Esto hace que el número de valores v posibles sea mu- buto que representa un DNI.
cho mayor que el número N de páginas posibles. La función de dispersión h Los valores posibles del atri-
buto se encuentran entre 0 y
transforma valores de un intervalo muy grande en posiciones de un intervalo 99.999.999. En cambio, el nú-
mero de páginas que puede
menor (el intervalo [1, ..., N]). ocupar el índice en el disco di-
fícilmente llegará a los cien mi-
llones.
Por este motivo, es posible que para dos valores diferentes, vi y vj, suceda que
h(vi) = h(vj), es decir, que la función devuelva la misma página para los dos
valores, como se aprecia en la figura 40.
Si al índice por el atributo “nombre de pila” anterior añadimos el valor Jorge y h(Jorge) =
4, entonces tendremos la situación que se muestra en la figura 41.
CC-BY-NC-ND • PID_00223667 64 Diseño físico de bases de datos
A veces, una página puede ser insuficiente para contener todos los sinónimos
que deberían colocarse. Esto sucederá cuando a una página le correspondan
más de L sinónimos.
Gestión de excedentes
Cuando una página primaria p se llena y se le inserta un nuevo valor que según
la función de dispersión debería ir en la misma página p, la entrada del valor
se coloca en una página de excedentes e y se añade a la página primaria p un
apuntador hacia la página e.
CC-BY-NC-ND • PID_00223667 65 Diseño físico de bases de datos
Esta página de excedentes e se utilizará solo para contener los posibles exce-
dentes de la página primaria p que se inserten posteriormente. Si la página e
también se llena, se le encadenará una nueva página de excedentes e’ donde se
podrán colocar más excedentes de la página primaria p, y así sucesivamente.
De este modo, para cada página primaria con excedentes, se construye una
cadena de páginas de excedentes. El primer apuntador de la cadena está situa-
do en la página primaria que lo ha originado.
(18)
Puesto que hay una cadena separada de páginas de excedentes para cada pá- En inglés, separate chaining.
gina primaria, esta política de gestión de excedentes a veces se denomina en-
cadenamiento�separado18.
Las supresiones de los valores del índice pueden hacerse de varias maneras.
Una posibilidad es marcar el valor con una señal especial que indique que está
borrado, sin reorganizar nada. Otra posibilidad es aprovechar estas supresiones
de valores para reducir la longitud de las cadenas de excedentes.
Supongamos que tenemos un índice con cinco páginas primarias (N = 5), que todas las
páginas tienen una capacidad de tres entradas (L = 3) y que la función de dispersión es
h(x) = (x mod 5) + 1. Si insertamos los valores: 22, 23, 12, 57, 33, 38, 32, 67, 62, 43, 2,
3, el índice quedará como muestra la figura 42.
Es fácil darse cuenta de que el coste de localizar una entrada en el índice al-
macenado en las páginas de un espacio de índices varía bastante según si esa
entrada es excedente o no:
C = M / (N × L)
Cuanto más bajo sea el factor de carga, menos excedentes habrá y me-
nos E/S serán necesarias. En contrapartida, si el factor de carga es muy
bajo, se utiliza más espacio.
Ejemplo de cálculo de L
Si disponemos de páginas de 4 kB, los valores indexados ocupan 40 bytes, los RID, 4 y los
apuntadores a páginas, 3. Entonces, el número L de entradas será 93, dado que se tiene
que cumplir que 4 kB = (40 + 4)L + 3 (la página debe contener hasta L entradas formadas
por el valor y un RID cada una, así como el apuntador a la primera página de excedentes).
Algunas técnicas de dispersión dinámica permiten modificar la función de dis- Lectura complementaria
persión de manera dinámica para acomodarse al aumento o la disminución
Encontraréis la explicación
de los datos indexados. En este módulo, sin embargo, no describimos las téc- detallada de la dispersión ex-
nicas de dispersión dinámica, dos de las cuales, la dispersión extensible y la tensible y la lineal en la obra
siguiente:
dispersión lineal, las podéis encontrar explicadas con todos los detalles en la R.�Ramakrishnan;�J.�Gehr-
obra de Ramakrishnan (2002). ke (2002). Database mana-
gement systems. Boston: Mc-
Graw-Hill.
6.3.5. Índices agrupados
(19)
En inglés, clustered.
Los índices que permiten implementar los accesos secuenciales por valor (co-
mo por ejemplo los árboles B+) pueden ser índices agrupados19 o índices no (20)
En inglés, unclustered.
20
agrupados .
La figura 43 ilustra las diferencias entre los índices agrupados y los no agru-
pados.
CC-BY-NC-ND • PID_00223667 68 Diseño físico de bases de datos
Reflexión
Aunque podemos tener varios índices sobre unos datos, solo uno puede ser agrupado,
porque los datos pueden tener una única ordenación física.
Un aspecto que hay que tener en cuenta en los índices agrupados es que la
ordenación física de sus datos es difícil de mantener cuando se producen in-
serciones y supresiones. En la práctica, esta dificultad se resuelve de la manera
siguiente:
1) Inicialmente, se deja espacio libre en las páginas que contienen los datos
para absorber inserciones futuras.
SELECT *
FROM Employees
WHERE officeNum = 150 AND salary = 1200;
1) Usar el índice del atributo officeNum para obtener todos los RID de las filas
de empleados que tiene el despacho 150.
CC-BY-NC-ND • PID_00223667 70 Diseño físico de bases de datos
2) Usar el índice del atributo salary para encontrar todos los RID de filas de
empleados que tienen el sueldo 1.200.
3) Realizar la intersección entre los dos conjuntos de RID. Los RID de la inter-
sección corresponden a los empleados que tienen al mismo tiempo el despa-
cho 150 y un sueldo de 1.200.
Esta es una buena estrategia porque aprovecha el hecho de tener dos índices
para los datos de los empleados. Aun así, en algunos casos concretos puede
tener un mal rendimiento.
Un índice�de�valores�compuestos�por�los�atributos�[A1,�...,�Ai,�...,�An]
tiene la misma estructura que los otros índices. La única diferencia es
que los valores del índice serán, de hecho, listas de elementos [v1, ...,
vi, ..., vn] donde vi es un valor del atributo Ai.
El índice de valores compuestos por los atributos [officeNum, salary] tiene valores como
por ejemplo [150, 1.200], [150, 1.500], etc.
Para establecer una relación de orden entre los valores compuestos del índice hay que
deducir para los dos valores anteriores [150, 1.200], [150, 1.500] cuál es el más grande.
Aquí, puesto que el primer elemento de la lista coincide, se utiliza el segundo para orde-
nar. Se obtiene que [150, 1.200] < [150, 1.500].
En general, el orden entre dos valores compuestos v = [v1, ..., vi, ..., vn] y w =
[w1, ..., wi, ..., wn] se establece de la manera siguiente:
• Si v1 = w1, ..., vi–1 = wi–1 y vi > wi, entonces v > w; y si v1 = w1, ..., vi–1 = wi–
1 y vi < wi, entonces v < w.
CC-BY-NC-ND • PID_00223667 71 Diseño físico de bases de datos
Hemos visto que los índices de valores compuestos por los atributos [A1, ...,
Ai, ..., An] constituyen una buena implementación de los accesos directos por
varios valores. En este subapartado comentaremos su aplicación para imple-
mentar accesos secuenciales y mixtos por varios valores y veremos que pre-
senta algunas deficiencias.
• Sentencia 1:
SELECT *
FROM Employees
ORDER BY officeNum, salary;
• Sentencia 2:
SELECT *
FROM Employees
WHERE officeNum = 100 AND salary > 960;
Esta sentencia corresponde a un acceso mixto por varios valores. Observad que
el orden de los valores compuestos del índice por [officeNum, salary] concuerda
con el orden en el que nos interesa obtener los empleados para procesar la
consulta. De este modo, el índice nos permite también procesar la consulta
de manera eficiente.
• Sentencia 3:
SELECT *
FROM Employees
ORDER BY salary, officeNum;
• Sentencia 4:
SELECT *
FROM Employees
WHERE salary = 1200 AND officeNum > 100;
Con un solo índice multidimensional por los atributos salary y officeNum podríamos pro-
cesar todas las sentencias de consulta 1, 2, 3 y 4 presentadas en este subapartado.
Se han propuesto varios tipos de índices multidimensionales: los árboles R, los Lectura complementaria
archivos en retícula, etc. Se utilizan sobre todo en SGBD destinados a almace-
Podéis encontrar la descrip-
nar información geográfica, pero pocos sistemas relacionales los incorporan. ción de los árboles R y de
los archivos en retícula en la
obra siguiente:
6.5. Índices del sistema Oracle A.�Silberschatz;�H.�F.�Korth;
S.�Sudarshan (2010). Funda-
mentos de bases de datos (3.ª
El sistema Oracle pone al alcance del diseñador algunos de los índices que ed.). Madrid: McGraw-Hill.
hemos estudiado en este módulo.
Documentación Oracle
6.5.1. Accesos por valor
Para obtener los detalles de la
implementación, así como una
Para implementar accesos por valor directos o secuenciales el sistema Oracle guía de la sintaxis y ejemplos
de uso, se puede consultar la
proporciona índices de árbol B+ por un atributo, que pueden ser agrupados documentación en línea del
o no. SGBD Oracle.
Si se desea que el acceso secuencial sea por orden descendente, debe declararse
de manera explícita (porque, por defecto, el orden se considera ascendente):
Si queremos que el acceso secuencial por alguno de los atributos sea descen-
dente, hay que declararlo de manera explícita. Por ejemplo, si deseamos que
la ordenación de los sueldos sea descendente:
Resumen
Hemos descrito algunas de las estructuras que los SGBD utilizan para imple-
mentar los accesos por uno o varios valores: índices del tipo árbol B+, índices
estructurados según funciones de dispersión, índices agrupados e índices de
valores compuestos. Hemos mostrado el impacto que pueden tener estas es-
tructuras en el número de E/S necesario para implementar los accesos a los
datos.
CC-BY-NC-ND • PID_00223667 75 Diseño físico de bases de datos
Glosario
acceso directo por posición m Método de acceso que consiste en obtener una página
que tiene un número de página determinado dentro de un espacio.
acceso directo por valor m Método de acceso que consiste en obtener todas las filas que
contienen un determinado valor por un atributo.
acceso por varios valores m Método de acceso que consiste en obtener varias filas según
los valores de varios atributos. Puede ser directo, secuencial o mixto.
acceso secuencial por posición m Método de acceso que consiste en ir obteniendo las
páginas de un espacio siguiendo el orden definido por sus números de página.
acceso secuencial por valor m Método de acceso que consiste en obtener varias filas
por orden de los valores de un atributo.
árbol B+ m Estructura de datos que se emplea para organizar índices que permiten imple-
mentar el acceso directo y el acceso secuencial por valor.
bloque m Unidad de transferencia de datos entre la memoria del ordenador y los disposi-
tivos o ficheros externos. El sistema operativo de la máquina, concretamente la parte espe-
cializada en la E/S, es quien lleva a cabo esta transferencia.
dispersión f Manera de organizar valores que se puede utilizar en índices que implementan
el acceso directo por valor.
entrada f Elemento de un índice que consiste en una pareja formada por un valor y un RID.
espacio virtual m Secuencia de páginas virtuales. Proporciona una visión ordenada y con-
tigua de las páginas físicas. Según su funcionalidad específica tiene características ligeramen-
te diferentes, en función de las cuales puede ser un espacio para tablas, fragmentado, de
agrupación, de objetos grandes, de índices, temporal, etc.
sigla EV
identificador de fila m Dirección uniforme que utilizan los SGBD para grabar las refe-
rencias internas de sus estructuras de datos. Otros nombres equivalentes son ROWID y, últi-
mamente, OID (en la medida en que los SGBD relacionales se convierten en los denomina-
dos object-relational).
sigla RID
índice m Estructura de datos auxiliar que los SGBD usan para facilitar las búsquedas nece-
sarias para implementar los accesos por uno o varios valores.
índice agrupado m Índice que proporciona el acceso secuencial por valor (y también el
acceso directo por valor) y que indexa datos que están ordenados físicamente según el orden
del acceso secuencial por valor proporcionado.
índice de valores compuestos m Índice de valores compuestos por los atributos [A1, ...,
Ai, ..., An]. Tiene la misma estructura que los otros índices, pero con la diferencia de que los
valores del índice son, de hecho, listas de valores [v1, ..., vi, ..., vn] en las que cada vi es un
valor del atributo Ai.
CC-BY-NC-ND • PID_00223667 76 Diseño físico de bases de datos
nivel físico m Nivel que engloba los componentes físicos (fichero, extensión y página)
dentro de la arquitectura de componentes de almacenamiento.
nivel lógico m Nivel que engloba los componentes lógicos (base de datos, tablas, vistas,
restricciones, etc.) dentro de la arquitectura de componentes de almacenamiento.
nivel virtual m Nivel que engloba el componente virtual (el espacio virtual) dentro de la
arquitectura de componentes de almacenamiento.
página f Unidad de transferencia de datos entre la memoria del ordenador y los ficheros
de una BD. El SO de la máquina es lo que lleva a cabo esta transferencia y pasa la página
al SGBD para que este le gestione la información que contiene, puesto que el SGBD es lo
que entiende la estructura interior de la página. La página también es la unidad principal de
grabación de los datos de una base de datos en los dispositivos periféricos. En este módulo,
a veces la denominamos página física o página real para distinguirla de la página virtual.
página virtual f Imagen de la página real o visión que desde el nivel virtual se tiene de
la página real sin materializarla físicamente. Hay una relación biunívoca entre página real
y página virtual.
vector de direcciones de fila m Estructura que ocupa las posiciones más altas dentro de
una página. Es un vector con tantos elementos como filas hay en la página. Cada elemento
apunta a una de estas filas. El último elemento apunta a la primera fila, el penúltimo a la
segunda, y así sucesivamente.
sigla VDF
Bibliografía
Elmasri, Ramez; Navathe, Shamkant, B. (2007). Fundamentos de sistemas de bases de
datos (5.ª ed.). Madrid: Pearson Educación.
Hansen, G. W.; Hansen, J. V. (1997). Diseño y administración de bases de datos (2.ª ed.).
Prentice Hall.
Silberschatz, A.; Korth, H. F.; Sudarshan, S. (2006). Fundamentos de bases de datos (5.ª
ed.). Madrid: McGraw-Hill. Edición de 2011 en eBook.
Teorey, T. J. (2011). Database Modeling & Design (5.ª ed.). San Francisco: Morgan Kaufmann
Publishers, Inc.