Ticb2 - Diseño de BBDD II

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.
Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968
B2G2T05 - DISEO DE BASE DE DATOS II.
1. INTRODUCCIN............................................................................................................................................................... 2
2. DISEO LGICO .............................................................................................................................................................. 2

2.1. DISEO LGICO ESTNDAR.................................................................................................................................. 2
2.1.1. TRANSFORMACIN DE DOMINIOS................................................................................................................. 3
2.1.2. TRANSFORMACIN DE ENTIDADES............................................................................................................... 3
2.1.3. TRANSFORMACIN DE ATRIBUTOS ............................................................................................................... 3
2.1.4. TRANSFORMACIN DE INTERRELACIONES.................................................................................................. 3
2.1.5. TRANSFORMACIN DE INTERRELACIONES DE DEPENDENCIA Y EXISTENCIA ..................................... 5
2.1.6. TRANSFORMACIN DE RESTRICCIONES DE ENTIDADES O ATRIBUTOS................................................. 5
2.1.7. TRANSFORMACIN DE DEPENDENCIAS DE IDENTIFICACIN Y EXISTENCIA....................................... 6
2.1.8. TRANSFORMACIN DE RESTRICCIONES EN LAS INTERRELACIONES...................................................... 6
2.1.9. TRANSFORMACIN DE GENERALIZACIONES (RELACIONES ISA) ............................................................. 6
2.1.10. TRANSFORMACIN DE LA DIMENSIN TEMPORAL.................................................................................... 7
2.1.11. TRANSFORMACIN DE ATRIBUTOS DERIVADOS......................................................................................... 7
2.1.12. NORMALIZACIN DEL ESQUEMA OBTENIDO .............................................................................................. 7
2.2. DISEO LGICO ESPECFICO ................................................................................................................................ 8
3. DISEO FSICO................................................................................................................................................................. 9
3.1. METODOLOGA DE TRABAJO PARA LA OBTENCIN DEL DISEO FSICO ............................................... 10
3.1.1. ANLISIS DE LAS TRANSACCIONES .............................................................................................................. 10
3.1.2. SELECCIN DE LA ORGANIZACIN DEL ALMACENAMIENTO EN MEMORIA SECUNDARIA .............. 11
3.1.3. CREACIN DE LOS NDICES SECUNDARIOS............................................................................................... 13
3.1.4. REALIZACIN DE AGRUPAMIENTOS DE TABLAS (CLUSTERING) ........................................................... 13
3.1.5. REALIZACIN DE PROCESOS DE DESNORMALIZACIN .......................................................................... 13
3.1.6. DETERMINACIN DEL ESPACIO DE ALMACENAMIENTO NECESARIO .................................................. 14
3.2. DISEO DE LOS MECANISMOS DE SEGURIDAD DE LOS DATOS ................................................................. 14
3.2.1. CREACIN DE LAS VISTAS DE LOS USUARIOS ........................................................................................... 14
3.2.2. FIJAR LAS REGLAS DE ACCESO DE LOS USUARIO .................................................................................... 14
3.3. MONITORIZACIN Y AJUSTE DEL SISTEMA .................................................................................................... 14
4. LA GESTIN DE LA CONCURRENCIA ..................................................................................................................... 15
4.1. NECESIDAD DE GESTIN DE LA CONCURRENCIA ......................................................................................... 15
4.2. MANEJO DE TRANSACCIONES EN EL SGBD..................................................................................................... 16
4.3. PROBLEMAS DE LA CONCURRENCIA................................................................................................................ 17
4.3.1. EL PROBLEMA DE LA ACTUALIZACIN PERDIDA ..................................................................................... 17
4.3.2. EL PROBLEMA DE LA LECTURA SUCIA........................................................................................................ 18
4.3.3. EL PROBLEMA DE LA LECTURA FANTASMA O LECTURA NO REPETIBLE ............................................. 18
4.4. MECANISMOS DE RESOLUCIN DE CONFLICTOS .......................................................................................... 19
4.4.1. MTODOS PESIMISTAS ................................................................................................................................... 20
4.4.2. MTODOS OPTIMISTAS .................................................................................................................................. 23
4.4.3. MTODOS DE CONTROL DE CONCURRENCIA BASADOS EN LA SEMNTICA ....................................... 24
5. CONCLUSIN.................................................................................................................................................................. 24
6. BIBLIOGRAFA............................................................................................................................................................... 24
7. ESQUEMA RESUMEN................................................................................................................................................. 25
TEMARIO-TICB-feb04 B2G2T05
Actualizado en febrero de 2004 Pgina 1 de 27
1. INTRODUCCIN
El diseo lgico es la etapa del proceso de diseo de una Base de Datos en la que se obtiene la representacin
de la estructura de la base de datos en trminos de almacenamiento (tablas). La obtencin de esta estructura
implica la aplicacin de unas reglas de transformacin de los elementos previamente existentes en el modelo
conceptual de la BD, reglas que se van a describir en este tema.
Por su parte, el diseo fsico es la etapa que incluye las acciones de configuracin y ajuste del almacenamiento
fsico y de la seguridad de la BD. El diseo fsico es una tarea compleja y dependiente del SGBD utilizados y del
uso concreto que se pretenda hacer de la BD diseada, por lo que en este tema se van a describir la problemtica
general que se aborda en esta etapa y los criterios de toma de decisiones en esas etapas para resolver un
problema.
Finalmente, el tema describir la necesidad del uso concurrente de las BD y los conflictos que ese uso plantea,
as como los mecanismos que los SGBD utilizan para resolverlos.
2. DISEO LGICO
El diseo lgico es la etapa de creacin de la base de datos en la que se va a traducir el modelo conceptual
obtenido en la etapa de diseo conceptual en modelo lgico y un esquema lgico expresado de un modo
comprensible para un SGBD. Si consideramos que el SGBD es relacional, el esquema lgico estar expresado en
tablas y columnas (o relaciones y atributos).
El diseo lgico se puede dividir en dos etapas:
Diseo lgico estndar: En esta etapa se obtiene un modelo lgico estndar y un esquema lgico
estndar, independientes del SGBD comercial en el que se vaya a implementar la base de datos. El
modelo lgico estndar puede expresarse empleando varias tcnicas, entre las que cabe citar el
Diagrama de Estructura de Datos (DED) y el modelo relacional. El esquema lgico estndar se obtiene
utilizando un Lenguaje de Definicin de Datos (DDL) estndar, habitualmente el SQL-92 (que es el
estndar ISO).
Diseo lgico especfico: Utilizando el esquema lgico estndar que se ha obtenido, se estudia su
implementacin en un SGBD comercial (Oracle, DB2, Sybase, etc.). Para ello, habr de analizarse la
compatibilidad del modelo lgico estndar con el modelo lgico especfico del SGBD elegido, y proponer
un modo de solucionar aquellos aspectos del modelo lgico estndar que no recoge el modelo lgico
especfico. Una vez realizada esa tarea, se obtiene un esquema lgico especfico usando el Lenguaje de
Definicin Datos propio del SGBD (normalmente, ser un lenguaje SQL con algunas peculiaridades
propias de cada SGBD). A la etapa del diseo lgico especfico tambin se la conoce como etapa de
implementacin de la BD.
2.1. DISEO LGICO ESTNDAR
Tal y como se ha comentado en el punto anterior, el diseo lgico estndar consiste en convertir el modelo
conceptual de BD en un esquema lgico estndar, independiente del SGBD que se vaya a utilizar. El esquema
lgico estndar ser la expresin del modelo lgico estndar utilizando un Lenguaje de Definicin de Datos
independiente del SGBD (SQL-2 o SQL.-3 habitualmente).
Las tcnicas de modelado conceptual son diferentes de las tcnicas de modelado lgico, por lo que habr que
convertir cada elemento presente en el modelo conceptual en elementos expresables en la tcnica de modelado
lgico que hayamos seleccionado.
En las BD relacionales, es habitual usar el modelo E/R para el modelado conceptual y el modelo relacional para el
modelado lgico. En este apartado vamos a estudiar la conversin de los elementos del E/R al modelo relacional
2.1.1. TRANSFORMACIN DE DOMINIOS
Un dominio del modelo E/R se transforma en un dominio en el modelo relacional utilizando la sentencia SQL-92
CREATE DOMAIN.
2.1.2. TRANSFORMACIN DE ENTIDADES
Cada entidad el modelo E/R se transformar en una tabla (relacin) en el modelo relacional. La tabla tendr el
mismo nombre que la entidad de la que proviene. Vemos un ejemplo a continuacin:
Figura 1: Entidad de un modelo E/R (conceptual)
Transformando la entidad al modelo relacional, obtendremos lo siguiente:
EMPRESA (CIF, Nombre, Direccin)
Para obtener el esquema lgico estndar, la tabla se definir usando la sentencia SQL-92 CREATE TABLE.
CREATE TABLE EMPRESA (

CIF Cdigo_CIF,
Nombre Nombres,
Direccion Direcciones,
PRIMARY KEY (CIF))
2.1.3. TRANSFORMACIN DE ATRIBUTOS
Cada atributo de una entidad se transformar en una columna de la tabla (relacin) del modelo relacional. Los
atributos de las entidades pueden ser de cuatro tipos:
Identificadores: Se transforman en una columna que es la clave primaria de la tabla. En SQL-92, la

condicin de clave primaria se representar colocando la clusula PRIMARY KEY al lado del nombre de
la columna en la que se ha convertido el atributo (dentro de la sentencia CREATE TABLE con la que se
crea la tabla en la que est incluida la columna).
Identificadores alternativos: Se transforman en una columna a la que se le aade la restriccin
UNIQUE, lo cual significa que no puede haber valores repetidos en esa columna.
Atributos no identificadores: Se transforman en una columna de la tabla.
Atributos multivaluados: En el modelo relacional una instancia de una relacin slo toma un valor para
cada atributo. Por ello, ser obligatorio crear una nueva tabla que contenga a la clave primaria de la tabla
anterior y al atributo multivaluado, siendo la clave primaria de la nueva tabla la concatenacin de los dos
atributos y marcndose la clave primaria de la tabla anterior como clave fornea en la nueva tabla.
2.1.4. TRANSFORMACIN DE INTERRELACIONES
En el modelo relacional, la nica unidad de modelado son las tablas, por lo que las interrelaciones del modelo E/R
deben transformarse en tablas del modelo relacional (se produce una cierta prdida de semntica).
El modo de transformar las interrelaciones en tablas depende del tipo de interrelacin considerada. Los tipos de
transformaciones existentes son:
2.1.4.1. TRANSFORMACIN DE INTERRELACIONES N:M
Una interrelacin N:M se va a convertir en una tabla del modelo relacional. La nueva tabla tendr como columnas
a la concatenacin de los atributos identificadores de las entidades que estaban unidas por la interrelacin.
Figura 2: Una interrelacin en el modelo E/R
EMPRESA(CIF , Direccion,)
VENDE(CIF,Codigo_Producto)
PRODUCTO(Codigo_Producto,)
Si la interrelacin tiene atributos en el modelo E/R, cada atributo de la interrelacin pasar a ser una columna de
la nueva tabla.
Los atributos identificadores de las entidades unidas mediante la interrelacin sern claves primarias en las tablas
del modelo relacional que representen a sus entidades. Por tanto, esos mismos atributos sern considerados
claves forneas en la tabla que representa a la interrelacin.
La condicin de clave ajena de una columna se expresar mediante la clusula FOREIGN KEY en SQL-92.
CREATE TABLE VENDE

(CIF Codigo_CIF,Producto Codigo_Producto,
,
PRIMARY KEY (Codigo_CIF, Codigo_Producto),
FOREIGN KEY (Codigo_CIF) REFERENCES Empresa,
FOREIGN KEY (Codigo_Producto) REFERENCES Producto)
Las cardinalidades mnimas de cada entidad participante en la interrelacin se van a expresar en el esquema
lgico estndar usando la sentencia de SQL-92 CREATE ASSERTION.
2.1.4.2. TRANSFORMACIN DE INTERRELACIONES
Las relaciones 1:N se pueden transformar de dos maneras:
No crear ninguna tabla que represente a la interrelacin y aadir a la tabla que representa a la entidad
con cardinalidad n el conjunto de atributos que son clave primaria de la entidad con cardinalidad 1. Este
es el modo habitual de realizar la transformacin.
Convirtiendo la interrelacin en una tabla, siendo la clave primaria de la tabla el conjunto de atributos
identificadores del lado n de la relacin. Esta opcin se utiliza en los siguientes casos:
Cuando se cree que en el futuro la relacin se va a transformar en una de tipo N:M (y por tanto, ser
necesario tener una tabla que represente a esa relacin).
Cuando la interrelacin tiene atributos en el modelo relacional.
Cuando la interrelacin es optativa para las ocurrencias de las entidades situadas en el lado 1 de la
relacin (cardinalidad 0:1) y el porcentaje de ocurrencias interrelacionadas es bajo, lo cual va a
significar que en las columnas absorbidas en la tabla n van a existir muchos valores nulos.
2.1.4.3. TRANSFORMACIN DE INTERRELACIONES 1:1
Se realizan del mismo modo que las interrelaciones 1:N, pero teniendo en cuenta que si se decide no crear una
tabla que represente a la interrelacin, la eleccin de la tabla a la que se le aaden los atributos del otro extremo
es optativa, si bien se suele seguir el siguiente criterio:
Si una de las dos entidades de la interrelacin tiene cardinalidad (0,1) y la otra entidad tiene cardinalidad
(1,1), entonces se propagan los atributos identificadores de la tabla (1,1) a la tabla (0,1), evitndose los
valores nulos.
Si las dos tablas tienen cardinalidad (1,1), se puede escoger cualquiera de los dos extremos para
propagar la clave. En este caso, la eleccin puede depender de criterios como las frecuencias de acceso
a las tablas
Si los dos extremos participan con una cardinalidad (0,1), crear una tabla que represente a la
interrelacin. El identificador de la tabla podr ser el identificador de cualquiera de los dos extremos, y los
atributos que sean clave primaria en uno de los dos extremos, sern clave fornea en la nueva tabla.
2.1.4.4. TRANSFORMACIN DE INTERRELACIONES CON UN GRADO SUPERIOR A 2
El mecanismo de transformacin es igual al de las tablas N:M, se crea una tabla que representa a la relacin, y su
clave primaria ser la concatenacin de los atributos identificadores de todas las entidades a las que
interrelaciona (lgicamente, tres o ms).
2.1.5. TRANSFORMACIN DE INTERRELACIONES DE DEPENDENCIA Y EXISTENCIA
El modelo relacional no distingue tipos de relaciones, por lo que las interrelaciones de dependencia y existencia
se han de convertir en relaciones del mismo modo que las interrelaciones 1:M. Habitualmente, se propaga la
clave de la tabla que representa a la entidad dbil a la tabla que representa la entidad fuerte.
2.1.6. TRANSFORMACIN DE RESTRICCIONES DE ENTIDADES O ATRIBUTOS
En el modelo E/R pueden estar expresadas restricciones de usuario. Estas restricciones se recogen en el
esquema lgico estndar del siguiente modo:
Si la restriccin indica un rango de valores, se usa la clusula BETWEEN de SQL-92.
Si la restriccin implica que un determinado atributo o conjunto de atributos slo puede tomar un valor de
entre los pertenecientes a una lista, se emplea la clusula IN.
Si la restriccin es de otro tipo, se puede utilizar la sentencia CHECK para comprobar el cumplimiento de
la condicin fijada, o la sentencia CREATE ASSERTION si la restriccin afecta a ms de una tabla.
CREATE TABLE Decreto
Num_Decreto Numeros_Decreto,
Fecha_Aprobacion Fecha,
Fecha_Publicacin Fecha,
,
CHECK (Fecha_Aprobacion < Fecha_Publicacion))
2.1.7. TRANSFORMACIN DE DEPENDENCIAS DE IDENTIFICACIN Y EXISTENCIA
La transformacin de estas dependencias se realizarn del mismo modo que el de las relaciones 1:M, es decir, no
escribiendo ninguna relacin que las represente y propagando la clave de la tabla que representa a la entidad
fuerte a la tabla que representa a la entidad dbil, en la cual ser jugar el papel de clave fornea.
Para dicha clave fornea, no se admitirn los valores nulos, y se aadir la condicin de borrado y modificacin
en cascada (la eliminacin o modificacin de una ocurrencia de la entidad fuerte obligar a la eliminacin o
modificacin de las ocurrencias de las entidades dbiles que tiene asociadas).
Si la dependencia es en identificacin, entonces la clave primaria de la tabla que representa a la entidad dbil se
formar mediante la concatenacin de la clave primaria de la entidad dbil y de la clave propagada que proviene
de la entidad fuerte.
2.1.8. TRANSFORMACIN DE RESTRICCIONES EN LAS INTERRELACIONES
Se utilizarn los mismos mecanismos que se han comentado para la transformacin de restricciones de las
entidades o de sus atributos (usando las condiciones CHECK o CREATE ASSERTION si la restriccin afecta a
una interrelacin o a varias).
2.1.9. TRANSFORMACIN DE GENERALIZACIONES (RELACIONES ISA)
Hay tres estrategias para llevar a cabo esta transformacin:
Transformar la entidad y sus subtipos en una sola tabla, la cual tendr como atributos la concatenacin
de los atributos de la entidad y de los subtipos. En el ejemplo:
EMPLEADO_PUBLICO (DNI , Nombre, Relacin_laboral, Inicio_contrato, Toma_posesion)
Crear una tabla para la entidad generalizadora y una tabla por cada subtipo. Cada tabla tendr como
atributos los de su entidad o subtipo correspondiente. sta es la opcin que mejor mantiene la semntica
del modelo E/R. En el ejemplo:
EMPLEADO_PUBLICO (DNI , Nombre)
INTERINO (DNI, Inicio_Contrato)
FUNCIONARIO (DNI, Toma_Posesion)
Crear una tabla para cada subtipo. Cada tabla tendr como columnas los atributos del subtipo al que
representa y los atributos comunes (los que posee la entidad generalizadora). En el ejemplo:
INTERINO (DNI, Nombre, Inicio_Contrato)

FUNCIONARIO (DNI, Nombre, Toma_Posesion)
Figura 3: Una relacin ISA en el modelo E/R
2.1.10. TRANSFORMACIN DE LA DIMENSIN TEMPORAL
Se distinguen dos casos:
Si la dimensin temporal aparece en el modelo E/R como una entidad, se transformar del mismo modo
que el resto de las entidades.
Si la dimensin temporal aparece en forma de atributos de una interrelacin, estos atributos se ubicarn
en la tabla que les corresponda al transformar la interrelacin (bien en la tabla de la interrelacin o bien
en la tabla hacia la que se hayan propagado claves). Ahora bien, debe considerarse que estos atributos
de tipo fecha pueden tener que formar parte de la clave primaria de la tabla en la que se ubiquen en
funcin de la semntica de la situacin que se representa.
2.1.11. TRANSFORMACIN DE ATRIBUTOS DERIVADOS
Los atributos derivados se transformarn en columnas de la entidad a la que pertenezcan (como el resto de los
atributos). Adems, se establecer un disparador o un procedimiento almacenado que calcule el valor del atributo
cada vez que se inserta una nueva fila en la tabla o cada vez que se modifique en una fila el valor de alguno de
los atributos a partir de los cuales se calcula el atributo derivado.
2.1.12. NORMALIZACIN DEL ESQUEMA OBTENIDO
Finalizada la transformacin de el esquema conceptual en un esquema lgico, debe aplicarse a dicho esquema
lgico un proceso de normalizacin, evitndose as las anomalas de insercin, modificacin y borrado que
provoca la redundancia. El proceso de normalizacin puede encontrarse comentado en el tema anterior de este
mismo temario.
2.2. DISEO LGICO ESPECFICO
Partiendo del esquema lgico obtenido en el apartado anterior, se elabora un esquema adaptado al sistema
gestor de bases datos que se va a utilizar, crendose las tablas del esquema utilizando el Lenguaje de Definicin
de Datos propio de cada sistema. En las bases de datos relacionales, el Lenguaje de Definicin de Datos
habitual es el SQL, si bien existen pequeas variaciones entre el SQL usado en cada sistema, que normalmente
incluye pequeas modificaciones o extensiones del lenguaje SQL-92 (que es el estndar ISO).
En el paso del modelo lgico estndar al modelo lgico especfico de cada SGBD puede encontrarse que el
modelo lgico especfico soporta todos los conceptos del modelo lgico estndar (del modelo relacional) o, por el
contrario, que existen determinados aspectos del modelo lgico estndar que el modelo lgico especfico no
soporta. En este ltimo caso, habr que realizar un trabajo complementario de adaptacin (bien aadiendo
programacin complementaria en el diccionario de datos del SGBD o bien haciendo que la puesta en prctica de
esas restricciones no soportadas por el modelo lgico del SGBD, la lleve a cabo el cdigo de los programas que
utilicen los datos de la BD).
Algunos de los aspectos del modelo lgico estndar que pueden tener que adaptarse son los siguientes:
Dominios: El DDL del SGBD puede no incluir ninguna sentencia que nos permita crear dominios (los nicos
dominios que reconoce automticamente son los asociados a los tipos de datos predefinidos en el propio SGBD).
En este caso, habr que elegir una de las dos opciones siguientes:
Cuando se especifique la columna (dentro de la sentencia CREATE TABLE), escoger el tipo de datos
predefinido que mejor se ajuste, fijar la longitud y aadir alguna restriccin CHECK.
Crear una tabla de dominio, que contendr una sola columna, y en la que cada fila ser uno de los
valores posibles del dominio. Una vez creada esta tabla, crear un procedimiento almacenado que
compruebe que los valores que se intentan insertar en la columna son compatibles con el dominio que
queremos establecer. La tabla de dominio ser esttica, es decir, slo podr ser modificada por el
administrador de la base de datos. Lgicamente, la opcin de construir una tabla de dominio slo ser
valida si el dominio a construir es finito.
Clave Primaria: Si el SGBD no incluye una clusula PRIMARY KEY, debe conservarse la semntica dando los
siguientes pasos:
1. Aadir la restriccin NOT NULL en los atributos que formen parte de la clave primaria (debe recordarse
que una clave primaria no admite valores nulos).
2. Aadir la restriccin UNIQUE al conjunto de atributos de la clave primaria (ya que una clave primaria no
admite valores repetidos).
3. Aadir a la tabla un ndice construido sobre las columnas que forman parte de la clave primaria. Este
ndice se debe crear al crear la tabla y se debe destruir cuando la tabla sea eliminada.
4. Documentar el esquema con un comentario que indique cul es la clave primaria.
Clave ajena: Si el SGBD no incluye una clusula FOREIGN KEY, debe conservarse la semntica dando los
siguientes pasos:
1. Aadir la restriccin NOT NULL en los atributos de la clave ajena que no admitan nulos (cuando la
cardinalidad mnima de la interrelacin original fuera de al menos uno).
2. Hacer que los programas que trabajen con la Base de Datos implementen las restricciones de clave ajena
(integridad referencial).
3. Documentar el esquema con un comentario que indique que una columna o conjunto de columnas son
clave ajena.
El resto de los aspectos del modelo lgico estndar no recogidos por el modelo lgico especfico del SGBD
suelen modelarse empleando procedimientos almacenados o triggers.
Finalizada la etapa del diseo lgico especfico, habremos creado un esquema lgico especfico en el SGBD.
Esto quiere decir que ya tendremos una BD operativa en la que se podrn insertar, eliminar o modificar datos y
sobre la cual podremos realizar consultas.
3. DISEO FSICO
El diseo fsico es la ltima etapa del proceso de creacin de una BD. El objetivo de esta fase es obtener un
esquema interno de la Base de Datos que cumpla lo mejor posible los objetivos de funcionamiento de la BD que
los usuarios esperan. Ms concretamente, se trata de:
Disminuir el tiempo de respuesta de la BD (tanto el tiempo medio como la respuesta ante los picos de
carga)
Disminuir el espacio de almacenamiento utilizado
Incrementar la Seguridad de la BD
Estos objetivos del diseo fsico no siempre son compatibles entre s. Por ejemplo, para reducir el tiempo de
respuesta de las consultas a una BD, puede ser necesario incrementar la redundancia de los datos (tener los
mismos datos almacenados en varias tablas a la vez). Obviamente, esto incrementar el espacio de
almacenamiento utilizado. Un buen diseo fsico debe tener en cuenta para cada BD las necesidades de uso,
establecer unos objetivos concretos, y, cuando estos objetivos sean contradictorios, priorizarlos y alcanzar un
nivel de compromiso aceptable entre ellos.
Para llevar a cabo esta etapa, es preciso contar con informacin precisa sobre muchos aspectos de la BD que se
va a crear y de la plataforma en la que se va a trabajar. El diseo fsico comienza a realizarse cuando se ha
recopilado informacin suficiente sobre:
Los recursos software de los que se dispone

Los recursos hardware de los que se dispone
El esquema lgico especfico de la Base de Datos
Polticas de seguridad de los datos
Estudio detallado de las aplicaciones que van a utilizar la Base de Datos y de las transacciones que van a
generar.
El nivel fsico de las BD no est estandarizado, por lo que la realizacin del diseo fsico es dependiente del
SGBD que se est utilizando. Cada SGBD relacional definir su propia estructura de archivos, ndices, buffers de
memoria, roles de seguridad y objetos de gestin del nivel fsico, manipulndose este nivel a travs de una
extensin del lenguaje SQL estndar especfica de cada sistema gestor.
De lo dicho en los prrafos anteriores se pueden extraer las siguientes conclusiones:
Al contrario que en el diseo lgico general, el enfoque del diseo fsico no puede ser formal, sino casustico,
adaptado a cada SGBD y a cada BD utilizados. No hay recetas universalmente vlidas, sino buenas ideas
(heursticas) asentadas en conceptos de almacenamiento, arquitectura de computadores, redes o algoritmia.
Al no haber una estandarizacin del nivel fsico, esas ideas deben ser puestas en prctica en cada caso concreto,
probadas, evaluadas y, si es necesario, refinadas hasta alcanzar la situacin final deseada. A este proceso de
mejora del diseo fsico se le conoce como ajuste de la BD o tunning.
Por ltimo, es preciso comentar que no todos los SGBD tienen el mismo grado de flexibilidad en su nivel fsico. En
funcin del grado de manejo que permitan para el diseo fsico, podemos distinguir tres tipos de SGBD:
Rgidos: El SGBD fija una estructura interna que apenas admite configuracin. Esto asegura la
independencia fsico/lgica de la BD, pero es poco adaptable a cada situacin concreta, lo que puede
suponer una prdida de eficiencia.
Flexibles: El SGBD permite que sea el Administrador de Bases de Datos el que disee toda la estructura
interna. El diseo de toda la estructura interna es un trabajo extenso y complejo, y la toma de decisiones
del administrador puede afectar a la independencia fsico/lgica de los datos. Sin embargo, tambin es el
enfoque ms adaptable a cada necesidad concreta, con lo que es la alternativa con la que se podra
obtener un mayor grado de eficiencia en el uso de la BD.
Semiflexibles: El SGBD proporciona una estructura inicial configurable a travs de un conjunto de
parmetros. La modificacin de estos parmetros por parte del Administrador de Bases de Datos permite
ir mejorando esa estructura interna, y por ende, el rendimiento de la Base de Datos. ste opcin ofrece
un buen compromiso entre eficiencia e independencia fsico/lgica, siendo habitual en los SGBD.
3.1. METODOLOGA DE TRABAJO PARA LA OBTENCIN DEL DISEO FSICO
Podemos dividir a la etapa del diseo fsico en tres fases:
Diseo de la representacin fsica.
Anlisis de las transacciones.

Seleccin del modo de almacenamiento en memoria secundaria
Creacin de ndices secundarios
Realizacin de Agrupamientos de tablas
Realizacin de procesos de desnormalizacin
Estimacin de la necesidad de espacio en disco.
Disear los mecanismos de seguridad.
Disear las vistas de los usuarios.

Disear las reglas de acceso.
Monitorizar y ajustar del sistema.
3.1.1. ANLISIS DE LAS TRANSACCIONES
Para realizar un buen diseo fsico es necesario conocer las consultas y las transacciones que se van a ejecutar
sobre la base de datos. Esto incluye tanto informacin cualitativa, como cuantitativa. Para cada transaccin, hay
que especificar:
La frecuencia con que se va a ejecutar.

Las relaciones y los atributos a los que accede la transaccin, y el tipo de acceso: consulta, insercin,
modificacin o eliminacin. Los atributos que se modifican no son buenos candidatos para construir
estructuras de acceso.
Los atributos que se utilizan en los predicados del WHERE de las sentencias SQL. Estos atributos
pueden ser candidatos para construir estructuras de acceso dependiendo del tipo de predicado que se
utilice.
Si es una consulta, los atributos involucrados en el join de dos o ms relaciones. Estos atributos pueden
ser candidatos para construir estructuras de acceso.
Las restricciones temporales impuestas sobre la transaccin. Los atributos utilizados en los predicados de
la transaccin pueden ser candidatos para construir estructuras de acceso.
3.1.2. SELECCIN DE LA ORGANIZACIN DEL ALMACENAMIENTO EN MEMORIA SECUNDARIA
Las BD van a almacenar la informacin en dispositivos de almacenamiento secundarios (discos o cintas), los
cuales se caracterizan por tener mayor capacidad que la memoria principal y por la no volatilidad de los datos. Sin
embargo, son mucho ms lentos que la memoria principal a la hora de recuperar informacin, por lo que es
preciso realizar un estudio detallado sobre el modo de organizar la informacin en ellos, de modo que consigamos
un rendimiento en tiempo de acceso ajustado a cada necesidad de uso de la BD.
Las alternativas de organizacin consisten bsicamente en la eleccin del tipo de fichero o estructura de datos
ms adecuado para cada caso. En este apartado nos limitaremos a estudiar las ventajas y las desventajas de las
ms habituales, pero sin entrar en una descripcin detallada de esas estructuras (esa descripcin puede
encontrarse en el tema 3, grupo II de este mismo temario).
3.1.2.1. FICHEROS SECUENCIALES
Organizados de tal manera que cada registro es adyacente al siguiente registro. Esta relacin de adyacencia
puede ser fsica (direcciones fsicas consecutivas) o lgica (haciendo que cada registro contenga un puntero al
siguiente registro).
Los ficheros secuenciales no permiten el acceso directo a los datos, por lo que el acceso a los registros se realiza
en el mismo orden en el que fueron introducidos en el fichero.
3.1.2.2. FICHEROS SECUENCIALES INDEXADOS ISAM
Es una estructura de fichero indexado en el que los registros se agrupan en bloques, y en el interior de dichos
bloques estn organizados secuencialmente.
El ndice que se crea sobre el fichero contiene apuntadores a las direcciones de inicio de cada bloque, y el
acceso a datos a travs del ndice se realiza de la siguiente manera:
1. Se localiza el ndice de la clave que cumpla la condicin de bsqueda.

2. Se accede al bloque apuntado por el nodo que contena a la clave anterior
3. Una vez dentro del bloque, el registro deseado se busca secuencialmente.
La organizacin de ficheros ISAM mantiene el equilibrio entre el tamao de los ndices y el tiempo de acceso de
los registros.
Como el tamao de los bloques est limitado, en estos ficheros hay una zona de desbordamiento en que se van a
almacenar los registros que no se pueden guardar en el bloque que les corresponde cuando ste ya est lleno.
El uso de la zona de desbordamiento disminuye el rendimiento del sistema, puesto que se accede a ella tras
buscar al registro en el bloque en el que le correspondera estar, y porque la bsqueda en la zona de
desbordamiento es secuencial. Cuando el rea de desbordamiento es muy grande, se reorganiza el fichero,
realizndose una nueva divisin de bloques, ubicando a todos los registros en los bloques y reorganizando el
ndice de apuntadores a bloques.
3.1.2.3. RBOLES-B
Estructura de indexacin en forma de rbol equilibrado. El hecho de ser equilibrados (misma altura en todas sus
ramas) permite minimizar el nmero de accesos a disco cuando se realiza una bsqueda: las bsquedas rpidas
son una caracterstica que distingue a los rboles-B.
En cuanto al almacenamiento, los rboles-B consiguen una gestin del espacio razonablemente buena, ya que si
el rbol es de orden n, cada nodo debe tener al menos n/2 claves (es decir, como mucho se desaprovecha la
mitad del espacio de almacenamiento del ndice, lo cual es fcilmente asumible con los recursos de
almacenamiento de que se dispone hoy en da).
3.1.2.4. FICHEROS DE ACCESO ALEATORIO EMPLEANDO TCNICAS DE HASHING
En estos ficheros se accede directamente a los registros mediante el valor de su clave (siendo la clave uno o ms
de los campos del registro). Para ello, se dispone de una funcin hash o de mapeado que permite calcular la
direccin del registro a partir del valor de la clave. Este sistema es el que ms rpido permite realizar una
bsqueda de un registro concreto, pero slo funciona para resolver consultas exactas (con todo el valor de la
clave). Si la bsqueda es por rango o por patrn (por ejemplo, LIKE %a), no se puede aplicar la funcin hash.
3.1.2.5. CRITERIOS DE ELECCIN ENTRE LAS ESTRUCTURAS
La eleccin de una estructura de organizacin depender del uso que se realice de los datos almacenados. La
siguiente tabla recoge las situaciones en las que se suele preferir cada estructura:
Estructura Situacin
Archivos pequeos (es ms costoso gestionar el ndice

que realizar las bsquedas secuenciales)
Recuperaciones masivas de los datos (habr que

recorrer todos los datos).
Ficheros secuenciales
Acceso muy infrecuente a los datos y existencia una
sobrecarga de almacenamiento en el sistema
(Manteniendo el fichero secuencial se ahorra el
espacio de almacenamiento del ndice. Como el
acceso a los datos es muy infrecuente, el rendimiento
de la BD no se ve muy afectado).
HASH Bsquedas exactas (con todo el valor de la clave)
En todos aquellos casos en los que no convenga

Ficheros indexados (ISAM, rboles-B o variantes)
utilizar ficheros secuenciales ni tcnicas de HASH)
Tabla 1: Situaciones apropiadas de aplicacin de los criterios de organizacin de la memoria secundaria.
La eleccin entre un fichero ISAM y un rbol-B se realiza considerando los siguientes factores:
Frecuencia de las actualizaciones de los datos: Si la frecuencia de las actualizaciones es alta, debe
elegirse un rbol-B, ya que los ficheros ISAM se irn degradando al irse aadiendo registros a la zona de
desbordamiento.
Elevado nmero de consultas concurrentes: Si se realizan muchas consultas simultneas sobre los datos
indexados, el fichero ISAM debe ser la estructura elegida, ya que al ser su ndice esttico, no se bloquea
(facilita el acceso concurrente).
Si se deben tener en cuenta los dos factores o no se conoce bien el entorno de explotacin de la Base de
Datos (existen dudas sobre el nmero de usuarios, la frecuencia de acceso a datos, etc.), la estructura
elegida ser el rbol-B, ya que es la ms adaptable de las dos y sus aspectos desfavorables respecto a
los ficheros ISAM tienen poca repercusin en el funcionamiento del sistema.
3.1.3. CREACIN DE LOS NDICES SECUNDARIOS
Las BD relacionales indexan a cada tabla por su clave primaria, crendose automticamente el ndice de clave
primaria en el mismo momento en el que se crea la tabla. Sin embargo, es frecuente aadir ndices adicionales a
las tablas, para que hagan ms rpidas las consultas que se realizan sobre determinados campos de esas tablas.
La introduccin de un ndice secundario en una tabla repercute negativamente en los tiempos de ejecucin de la
insercin o eliminacin de registros, y supone un incremento del espacio de almacenamiento necesario para la
tabla. El administrador de bases de datos debe ponderar en cada caso las prdidas y ganancias de introduccin
de un nuevo ndice, para as determinar si su creacin es interesante. Algunas situaciones que hacen interesante
la indexacin son:
Atributos de la relacin a los que se accede con mucha frecuencia.

Claves forneas de la relacin sobre las que es habitual realizar joins.
Algunas situaciones que desaconsejan la introduccin de ndices secundarios son:
Tablas con pocas filas: el recorrido secuencial de las tablas sera muy breve, y la reduccin del tiempo de
acceso obtenida de la introduccin del ndice es muy escasa.
Atributos cuyo valor se modifica muy a menudo: Los ndices utilizan como clave de bsqueda los valores
de los atributos indexados. Si la modificacin de esos valores es muy frecuente, habr que reconstruir el
ndice cada poco tiempo, lo cual puede suponer un coste elevado si la tabla tiene muchas filas.
Atributos con valores poco selectivos: Los atributos en los que es muy habitual la repeticin de su valor
en distintas filas de la tabla no son buenos candidatos para la indexacin. Despus de recorrer el ndice y
localizar su clave de bsqueda, tendramos todava muchos registros con el mismo valor de clave, y
habra que recorrer secuencialmente esos registros para encontrar el que se busca; en este caso, la
introduccin del ndice no supondra ningn beneficio importante desde el punto de vista del tiempo de
acceso. Por ejemplo, si tenemos una tabla de personas y deseamos buscar una persona en concreto, no
tiene sentido indexar por un campo Sexo, ya que aproximadamente la mitad de los registros de la tabla
tendran el valor hombre y la otra mitad el valor mujer.
3.1.4. REALIZACIN DE AGRUPAMIENTOS DE TABLAS (CLUSTERING)
El clustering o agrupacin de tablas es una tcnica consistente en almacenar un grupo de tablas en una misma
rea de memoria secundaria. De este modo, los accesos simultneos a las tablas agrupadas no obligan al SGBD
a la bsqueda de los datos en zonas lejanas del almacenamiento secundario, lo que reduce el tiempo de
resolucin de esos accesos.
El clustering ser una tcnica a considerar si esos accesos simultneos son frecuentes.
3.1.5. REALIZACIN DE PROCESOS DE DESNORMALIZACIN
El proceso de desnormalizacin consiste en introducir redundancias en un esquema lgico previamente

normalizado (tpicamente en 3FN o en FN de Boyce-Codd). Aunque sta es una decisin de nivel lgico, se suele
tomar por motivos de eficiencia de la BD (repetir datos en varias tablas evita navegar entre ellas para
encontrarlos), es decir, la decisin viene motivada por cuestiones de implementacin.
La desnormalizacin ralentiza las actualizaciones de datos, hace perder flexibilidad al esquema lgico (puede
afectarnos si decidimos aadir nuevas tablas, por ejemplo) y complica la implementacin de la BD y su
documentacin. Por tanto, es una alternativa que slo se debe utilizar cuando el resto de las tcnicas de diseo
fsico no nos proporcionan un rendimiento de las consultas de la BD que sea aceptable.
Entre las acciones de desnormalizacin que se pueden realizar, se pueden destacar:
Introducir atributos derivados: Los atributos derivados son aquellos cuyo valor se puede obtener
realizando un conjunto de operaciones sobre atributos ya existentes en la BD. La introduccin de un
atributo derivado ayuda a obtener ese valor rpidamente en una consulta, puesto que no hay que realizar
las acciones de clculo del mismo, pero incrementa los costes de almacenamiento y de actualizacin de
las tuplas de la BD (cada vez que se modifique el valor de un atributo que interviene en su clculo, habr
que recalcular el valor del atributo derivado).
Fusionar tablas involucradas en relaciones uno a uno: Si el acceso conjunto a ambas tablas es muy
habitual, puede ser interesante crear una nueva tabla cuyos atributos sean la concatenacin de los
atributos de las dos tablas, lo cual puede reducir su tiempo de acceso. Sin embargo, este cambio
perjudicar a los operaciones join que se realicen entre cualquiera de esas dos tablas y una tercera, ya
que las filas de la nueva tabla que se han de leer ocuparn ms en memoria (la tabla fusionada tiene ms
campos), por lo que se recuperarn menos registros en cada lectura, lo cual obligar a un nmero de
accesos a disco superior.
Introducir atributos duplicados en relaciones 1:N: Consiste en aadir atributos no clave de las tabla con
cardinalidad 1 en la tabla con cardinalidad N. As, cuando se realiza una operacin de join entre las dos
tablas que slo involucra a los atributos duplicados, no ser necesario recorrer la tabla con cardinalidad 1.
3.1.6. DETERMINACIN DEL ESPACIO DE ALMACENAMIENTO NECESARIO
Una vez obtenido el esquema de implementacin definitivo, el administrador de la BD debe determinar el espacio
de almacenamiento necesario para la BD. La cantidad de espacio que se determine ser una estimacin basada
en el estudio de la cantidad de datos ya existente y que hay que cargar en la BD y en las estimaciones de
crecimiento futuro de la BD.
La estimacin del espacio puede verse afectada tambin por el nivel de seguridad que se desee para el
almacenamiento de datos y por el grado de disponibilidad de la Base de Datos. Por ejemplo, si uno de los
requisitos de la Base de Datos es que su disponibilidad sea 24x7 (24 horas al da, 7 das a la semana), es posible
que se necesite usar una estructura de almacenamiento secundario en forma de RAID 1+0 o 0+1, lo que
duplicara el espacio de almacenamiento necesario para la BD.
3.2. DISEO DE LOS MECANISMOS DE SEGURIDAD DE LOS DATOS
3.2.1. CREACIN DE LAS VISTAS DE LOS USUARIOS
Las vistas son un elemento de la BD que permiten a los usuarios ver los datos de una determinada forma
(corresponden al nivel externo en la arquitectura ANSI/SPARC). EL uso de las vistas permite:
Reducir la complejidad el esquema lgico global, manteniendo un esquema nico para todos los usuarios y
adaptando ese esquema a las necesidades que tenga cada tipo de usuario.
Mejorar el nivel de seguridad de la BD, ya que los usuarios no vern ms datos de las tablas que aquellos que
estn incluidos en la vista.
3.2.2. FIJAR LAS REGLAS DE ACCESO DE LOS USUARIO
En esta fase, se establecen los perfiles de usuario, donde cada perfil es el conjunto de acciones que cada tipo de
usuario va a poder hacer sobre cada elemento o conjunto de elementos de la BD (tablas, filas, unidades lgicas
de almacenamiento, etc.).
3.3. MONITORIZACIN Y AJUSTE DEL SISTEMA
El diseo fsico no se debe concebir como un proceso secuencial que finaliza cuando se ha encontrado una
configuracin vlida. Las BD pueden sufrir variaciones a lo largo del tiempo, tanto en su tamao, como en su
esquema lgico global o en el uso que se desee hacer de ellas, lo que obligar a una monitorizacin continua de
su rendimiento (para comprobar si se va degradando) y a la introduccin de ajustes que permitan adaptarse a los
cambios sufridos por la BD o solventar las prdidas de eficiencia que se hayan producido.
Cada proceso de ajuste supone en cierta medida una reconstruccin del diseo fsico que se haya realizado, por
lo cual esta etapa de diseo volvera a comenzar de nuevo.
4. LA GESTIN DE LA CONCURRENCIA
Veamos la gestin de la concurrencia en los SGBD. Para ello, empezaremos introduciendo la necesidad de dicha
gestin y el concepto de transaccin, pasando posteriormente a abordar los problemas que plantea la
concurrencia (Lectura Fantasma, Lectura Sucia, etc.) y los mecanismos de resolucin existentes.
4.1. NECESIDAD DE GESTIN DE LA CONCURRENCIA
Los SGBD deben poder mantener la integridad de los datos que almacenan. Durante la vida de una BD, existen
secuencias de acciones de escritura y lectura que pueden originar que la BD quede en un estado inconsistente si
no se ejecutan todas las acciones de esa secuencia.
Para evitar este tipo de problemas, los SGBD utilizan las transacciones, que son unidades lgicas de proceso que
se componen de una secuencia de acciones cuya ejecucin es atmica, o se ejecutan todas o no se ejecuta
ninguna. En un punto intermedio de una transaccin, el estado de la Base de Datos puede ser inconsistente,
siendo siempre consistente al principio y al final de la transaccin.
El elemento del SGBD encargado de conseguir este objetivo es el Gestor de transacciones (transaction
manager), el cual gestiona las peticiones de los usuarios en forma de transacciones.
Adems, los Sistemas Gestores de Bases de Datos que existen en la actualidad ofrecen la posibilidad de ser
usados en modo multiusuario, lo que implica que mltiples usuarios pueden trabajar a la vez con el sistema como
si fuera un recurso dedicado, sin apercibirse de la presencia de otros usuarios. Para lograr este efecto, los
tiempos de respuesta del SGBD a todos los usuarios deben ser reducidos, lo que obliga a realizar una ejecucin
concurrente (simultnea) de las transacciones de cada usuario.
La ejecucin atmica que caracteriza a las transacciones no garantiza que las pertenecientes a un programa de
un usuario no puedan interferir en las transacciones que pertenecen a otros programas y que se estn ejecutando
al mismo tiempo. Conseguir que las transacciones no interfieran con el funcionamiento de otras transacciones se
conoce como aislamiento de la transaccin (isolation), y el conjunto de problemas que plantea conseguir ese
aislamiento en un entorno multiusuario es conocido como el problema de la gestin de la concurrencia.
Adems, durante el transcurso de una transaccin, pueden producirse problemas en el SGBD que no permitan
que la transaccin concluya con xito, lo que, en virtud del principio de todo o nada que acompaa a las
transacciones, obliga al SGBD a estar preparado para deshacer las acciones que una transaccin no concluida
ha realizado sobre una base de datos. Es el problema de la recuperacin y se gestiona aadiendo una nueva
propiedad a las transacciones, que es la persistencia, y que consiste en que las modificaciones de datos que se
realizan durante una transaccin no se almacenan en la BD hasta que la transaccin ha finalizado con xito.
Resumiendo, una transaccin ha de tener las siguientes propiedades:
Atomicidad: Las acciones de una transaccin se ejecutan todas o ninguna.

Consistencia: la base de datos se encuentra en un estado consistente antes de la ejecucin de la
transaccin y debe estar en un estado consistente cuando la transaccin termine.
Aislamiento: La ejecucin de una transaccin no debe interferir en la ejecucin de otras transacciones, la
transaccin debe ejecutarse como si estuviera aislada.
Persistencia: Los efectos de una transaccin no son permanentes en la BD hasta que la transaccin ha
finalizado con xito.
4.2. MANEJO DE TRANSACCIONES EN EL SGBD
El gestor de transacciones es el componente funcional del SGBD que planifica y controla la ejecucin de
transacciones concurrentes en una BD.
Un gestor de transacciones se puede dividir conceptualmente en los siguientes elementos:
Un contenedor de entrada: Al que llegan las transacciones que se deben ejecutar.

Un planificador (scheduler): Que determina el orden en el que las transacciones de la cola van a ser
ejecutadas. Cuando el planificador da paso a una transaccin, est es enviada al gestor de datos, desde
el cual se realizarn las operaciones de la transaccin sobre la base de datos.
Un contenedor de salida: Al que llega la transaccin cuando ha terminado de ejecutarse. Si la transaccin
ha finalizado correctamente, el gestor de transacciones realizar una operacin commit, haciendo las
modificaciones de la transaccin persistentes en la base de datos.
Si la transaccin no ha finalizado correctamente debido a algn problema, el gestor de transacciones ejecuta una
operacin abort y enva la transaccin a un gestor de recuperacin, el cual deshace las operaciones de la
transaccin y devuelve los datos al estado en que estaban antes de iniciarse la transaccin. La transaccin
abortada ser devuelta al contenedor de salida para volver a ser ejecutada
Con el fin de incrementar el rendimiento de las BD en un entorno multiusuario, las transacciones no se ejecutan
secuencialmente una detrs de otra. El modelo de ejecucin secuencial de las transacciones podra originar una
situacin en la que un programa corto se quedase bloqueado a la espera de la finalizacin de un programa largo.
En este caso, el usuario del programa debera sufrir un gran tiempo de espera para la realizacin de un conjunto
reducido de operaciones, con lo que no percibira a la BD como un recurso dedicado.
Para evitar estas situaciones, las transacciones se despachan concurrentemente, es decir sus acciones se van a
llevar a cabo de forma entrelazada. Sin embargo, el entrelazado de acciones de las transacciones puede originar
conflictos, algunos de los cuales van a ser comentados en el punto siguiente.
La siguiente figura representa a un gestor de transacciones:
Figura 4: Estructura modular y entorno de un gestor de transacciones
4.3. PROBLEMAS DE LA CONCURRENCIA
4.3.1. EL PROBLEMA DE LA ACTUALIZACIN PERDIDA
Problema de concurrencia que ocurre cuando:
Dos transacciones T1 y T2 trabajan en paralelo e intentan modificar el valor del mismo objeto de la BD.
Ambas transacciones leen el valor del objeto antes de que la otra lo actualice
En este caso, cada una de las transacciones modificar el valor del objeto en memoria y tratar posteriormente de
escribirlo en la BD. El valor que se almacenar en la BD ser el que tiene el objeto en la transaccin que escriba
ms tarde, ya que el valor que ha escrito la primera transaccin se sobrescribir. As, la actualizacin realizada
por la transaccin que ha escrito primero quedar sin efecto.
Transaccin 1 Tiempo Transaccin 2
Inicio 1
r(x) 2
3 Inicio
4 r(x)
u(x) 5
6 u(x)
w(x) 7
Fin 8
9 w(x)
10 Fin
NOTA: u(x) significa UPDATE, actualizacin de x.
4.3.2. EL PROBLEMA DE LA LECTURA SUCIA
Se produce cuando:
Una transaccin T1 lee un valor de un objeto que ha sido modificado por otra transaccin T2 y que todava no se
ha hecho persistente en la BD.
La transaccin T2, que haba modificado los datos no termina correctamente. En este caso, la transaccin T1 est
trabajando con un valor que es inconsistente.
Debe recordarse que los datos pueden encontrarse en un estado inconsistente en el transcurso de una
transaccin, por lo que la transaccin primera puede haber ledo dichos datos inconsistentes, utilizndolos para
completar su secuencia de acciones.
Inicio 1
r(x) 2
u(x) 3
w(x) 4
5 Inicio
6 r(x)
7 u(x)
Abort 8
9 w(x)
4.3.3. EL PROBLEMA DE LA LECTURA FANTASMA O LECTURA NO REPETIBLE
Puede aparecer cuando:
Una transaccin T1 est leyendo un conjunto de datos al tiempo que una transaccin T2 los est modificando.
La transaccin T1 lee algunos de los datos antes de que sean modificados por T2 y otros despus de ser
modificados por T2.
El resultado de la operacin que realiza T1 se ve afectado por el hecho de combinar datos no actualizados por T2
con datos actualizados por T2.

Inicio 1
s:=0 2
r(x) 3
r(y) 4
s:= s + x 5
s:= s+y 6
7 Inicio
8 r(z)
9 z:= z-10
10 w(z)
11 r(x)
12 x:= x + 10
13 w(x)
14 commit
15 Fin
r(z) 16
s:=s + z 17
Fin 18
En este caso, el valor s es la agregacin de los valores x, y, z. La accin de la transaccin T2 no modifica el

valor de esa agregacin, sin embargo, la lectura de valores con diferentes versiones ha provocado que T1 ofrezca
un valor de s que es equivalente a x+y+z-10.
4.4. MECANISMOS DE RESOLUCIN DE CONFLICTOS
Como ya hemos comentado en el punto anterior, la labor fundamental de un gestor de transacciones es manejar
las transacciones que generan los programas de los usuarios de tal modo que se mantenga la consistencia de la
BD. En un entorno multiusuario, el gestor de transacciones deber conseguir mantener la consistencia cuando se
ejecutan entrelazadamente las acciones que componen las transacciones de los distintos programas.
Este orden de ejecucin lo establece el planificador (scheduler) del gestor de transacciones, llamndose plan de
ejecucin a cada posible secuencia de ejecucin de un conjunto de acciones. Lgicamente, existen mltiples
planes de ejecucin posibles, siendo interesantes los planes que cumplen la condicin de serializabilidad; un plan
de ejecucin A es serializable para un conjunto de transacciones T si existe un plan de ejecucin secuencial A
que es equivalente a A.
O dicho de un modo menos formal, un plan es serializable si el resultado de la ejecucin entrelazada de las
acciones de esas transacciones es equivalente al resultado de ejecutar las transacciones en serie.
Sin embargo, la comprobacin a priori de la serializabilidad de un plan es muy costosa (problema NP-completo),
por lo que el gestor de transaccin no trata de determinar si un plan de ejecucin es serializable; en lugar de eso,
el gestor de transacciones emplea diversas mecanismos de ejecucin de las acciones que o eliminan los
conflictos debidos a la concurrencia o permiten recuperar el estado consistente de la BD cuando se producen.
Podemos considerar los mtodos de resolucin de conflictos divididos en dos tipos:
Mtodos pesimistas: Basados en la suposicin de que los conflictos entre transacciones concurrentes
ocurren con alta frecuencia, lo que obliga a realizar una serie de acciones para manejar esos conflictos.
Mtodos optimistas: Basados en la suposicin de que los conflictos entre transacciones se producen
con escasa frecuencia.
4.4.1. MTODOS PESIMISTAS
4.4.1.1. CONCEPTO DE BLOQUEO Y TCNICAS BASADAS EN BLOQUEOS
Este mecanismo de resolucin de conflictos se basa en el concepto de bloqueo, que consiste en que cuando una
transaccin T1 necesita realizar alguna accin sobre un objeto de la BD, debe solicitar al SGBD una reserva de
ese objeto, no pudiendo ejecutar la accin hasta que la reserva no se ha producido. El SGBD slo conceder esa
reserva si otra transaccin T2 no mantiene el mismo objeto reservado (en otras palabras, mientras una
transaccin tenga a un objeto de la BD reservado, el acceso del resto de las transacciones puede considerarse
bloqueado).
En un momento dado, bien durante su transcurso o bien a su finalizacin, la transaccin terminar las acciones
que necesite hacer sobre el objeto de la BD, deshaciendo la reserva y quedando el objeto disponible para otras
transacciones.
Las acciones de bloqueo o desbloqueo no tienen porqu ejecutarse inmediatamente antes y despus de la accin
durante la cual queremos que el objeto est bloqueado. En el transcurso de una transaccin se hacen mltiples
lecturas y escrituras, pudiendo realizarse varias de ellas sobre el mismo objeto. Si se bloquease y desbloquease
antes y despus de cada accin, se incurrir en un coste de gestin de los bloqueos muy alto, lo que repercutir
en el rendimiento de la BD (en sus tiempos de respuesta). Por tanto, una poltica de gestin de bloqueos debe
llegar a un buen compromiso entre dos aspectos de signo contrario:
Tiempo que el objeto (los datos) est bloqueado: Cuanto mayor sea, ms largo es el tiempo durante el
cual otras transacciones no pueden realizar sus acciones sobre el conjunto de datos, lo que supone que
han de estar a la espera del desbloqueo, retardndose su finalizacin.
Tiempo empleado en gestionar los bloqueos: Realizar muchas operaciones de bloqueo/desbloqueo
repercute en el rendimiento de la BD, ya que hay que almacenar esos bloqueos, comprobar su
compatibilidad, etc.
As pues, la solucin consiste en encontrar la manera de ejecutar un nmero elevado nmero elevado de
acciones entre dos bloqueos, consiguiendo a la vez que la distancia entre bloqueos sea razonablemente
pequea.
Considerando el tipo de accin que se impide, podemos distinguir dos clases de bloqueo:
Bloqueo de escritura (write-lock o wlock): Impide que otras transacciones modifiquen un dato.
Bloqueo de lectura (read-lock o rlock): Impide que otras transacciones lean un dato.
La distincin entre bloqueos de escritura y bloqueos de lectura se establece porque interesa que el gestor de
transacciones pueda hacer un manejo diferenciado de cada tipo:
Un bloqueo de lectura realizado por una transaccin es compatible con un bloqueo de lectura de otra transaccin.
Dicho de otro modo, no existe ningn problema porque dos transacciones lean un objeto a la vez (y evitar esperas
innecesarias supone incrementar el rendimiento de la BD).
Un bloqueo de escritura es incompatible con cualquier otro tipo de bloqueo, ya que no se puede permitir que una
transaccin lea un dato cuando otra transaccin lo est modificando (como ya vimos en los problemas de la
concurrencia) y, desde luego, y un objeto no puede ser sobrescrito a la vez.
As pues, se puede establecer la siguiente tabla de compatibilidades entre bloqueos de lectura y escritura:
read_lock write_lock
read_lock SI NO
write_lock NO NO
Los SGBD tambin permiten manejar diferentes granularidades de los bloqueos: Un bloqueo sobre distintas
clases de objetos de la BD, como por ejemplo, una fila, un conjunto de filas o una tabla. De este modo las
transacciones pueden efectuar reservas del tamao estrictamente necesario, no bloqueando innecesariamente
partes de los objetos que pueden ser utilizadas simultneamente por otras transacciones (ejemplo, una
transaccin puede necesitar hacer un bloqueo de escritura sobre las primeras n filas de una tabla, lo cual no debe
impedir que otras transacciones realicen acciones de lectura o escritura sobre las n+1 restantes).
Cuanto menor sea el tamao de los objeto bloqueados (granularidad ms fina), menor ser el nmero de esperas
que los bloqueos originarn. Sin embargo, una granularidad fina genera ms situaciones de interbloqueo que una
granularidad gruesa, por lo que ser necesario hacer una seleccin cuidadosa del nivel de granularidad
empleado.
EL PROBLEMA DEL INTERBLOQUEO
EL uso de tcnicas basadas en bloqueo para la gestin de transacciones concurrentes puede conducir al
problema denominado interbloqueo (o deadlock o abrazo mortal). El interbloqueo es una situacin que se produce
cuando dos transacciones se quedan esperando indefinidamente por un recurso que la otra transaccin tiene
bloqueada, de tal manera que ninguna de las dos accede nunca al recurso que la otra ha reservado.
Por tanto, el gestor de transacciones deber implantar mecanismos que le permitan detectar esas situaciones de
interbloqueo y resolverlas, existiendo tres tipos de estrategias de resolucin:
La prediccin: Consiste en la no generacin de transacciones que puedan producir interbloqueo. Esto

obligara a analizar todas las transacciones a priori, lo cual producira una gran sobrecarga en el sistema
(todos los algoritmos de prediccin son exponenciales, y por tanto no utilizables en un sistema con altas
exigencias de rendimiento como es una base de datos).
La prevencin: Basada en que las transacciones puedan renunciar a un bloqueo que hayan realizado
previamente. Para ello, se detectan los casos en los que una transaccin T1 tenga reservado un tem y
una transaccin T2 intenta hacer un tipo de bloqueo sobre ese tem que es incompatible con el bloqueo
de T1, aplicando tcnicas de prevencin, de entre las que se pueden destacar:
Wait-die: Si T2 es ms antigua, se le hace esperar. En caso contrario, T2 se cancela.
Kill-Wait: Si T2 es ms antigua, se cancela. En caso contrario, se hace esperar a T2.
La eliminacin: Es el modo ms sencillo de los tres. Consiste en eliminar una de las transacciones
bloqueadas, continuando la otra transaccin su camino. El gestor de transacciones volvera entonces a
generar la transaccin eliminada y la reintroducira en la cola de transacciones, siendo lo ms probable
que la otra transaccin haya terminado o haya avanzado hasta un punto en el que no se repita la
situacin de interbloqueo.
EL PROTOCOLO DE BLOQUEO EN DOS FASES
Es una implementacin muy extendida de un los principios de la resolucin de conflictos basada en bloqueos
(tcnica pesimista). El protocolo de bloqueo en dos fases define un conjunto de reglas sobre la aplicacin de
bloqueos que pueden ser utilizadas por el gestor de transacciones para gestionar las transacciones concurrentes.
Estas reglas son:
1. En una transaccin slo se va a escribir sobre un objeto una vez.

2. Si una transaccin necesita leer y escribir, realizar en primer lugar el bloqueo de escritura. De esta
manera, basta con realizar una nica operacin de desbloqueo en la transaccin (un desbloqueo genrico
que termina con el bloqueo de lectura y escritura).
3. Antes de realizarse las acciones de lectura o escritura, deben hacerse los bloqueos correspondientes, los
cuales deben permanecer hasta que las acciones hayan finalizado.
4. Los bloqueos del mismo tipo slo se realizan una vez por transaccin
5. En una transaccin, una vez que se hace el primer desbloqueo, no se vuelve a hacer ningn bloqueo
sobre ningn objeto. Esta norma caracteriza al bloqueo en dos fases, en la que se distingue una fase de
crecimiento, donde van apareciendo nuevos bloqueos, y una fase de decrecimiento, que se inicia a partir
del primer desbloqueo y dura hasta al final de la transaccin, y en cuyo transcurso el nmero de bloqueos
siempre decrece. Grficamente, el comportamiento de este protocolo puede representarse as:
Figura 5: Evolucin del nmero de bloqueos de una transaccin con el algoritmo 2PL
Entre las ventajas del protocolo de bloqueo en dos fases o 2PL, podemos citar dos:
Es un protocolo seguro, es decir, nunca se van a producir las situaciones anmalas de concurrencia
estudiadas en el punto anterior.
Es un protocolo sencillo, fcil de implantar.
Entre sus desventajas, podemos citar:
Los bloqueos tienden a ser grandes, lo que va a provocar incompatibilidades habituales con otras
transacciones, derivndose de ello una prdida de rendimiento.
Este protocolo permite la aparicin de interbloqueo.
4.4.1.2. TIME-STAMPING
El time-stamping trata de conseguir la serializabilidad de los planes de ejecucin haciendo que, cuando varias
transacciones tengan que acceder a objetos comunes, lo hagan en distintos momentos. Este objetivo se consigue
asignando una marca temporal distinta (time-stamp) a cada transaccin.
Cuando una transaccin intenta acceder a un objeto para leerlo o modificarlo, se comprueba previamente si ya ha
sido accedido por otra transaccin ms joven. Existen tres modalidades de time-stamping:
TIME-STAMPING BSICO
1. Se almacena en cada objeto el time-stamp de la ltima transaccin que lo ha ledo (TSR) y el de la ltima
que lo ha grabado (TSW).
2. Cuando una transaccin T intenta leer un objeto, si su time-stamp es mayor o igual que el TSR del objeto,
podr leerlo, debiendo ser cancelada en caso contrario.
3. Si una transaccin T intenta escribir un objeto, se pueden producir las siguientes situaciones:
TS (T) >= TSW(Objeto):

Si TS(T)>=TSR(Objeto), podr escribir. Si no, T tendr que ser cancelada.
Si TS(T)<=TSW(Objeto) :
Si TS(T)>=TSR(Objeto), T puede seguir adelante saltndose la grabacin, ya que la versin
que habra grabado no sera la ltima y no habr sido leda por ninguna transaccin (regla de
escritura de Thomas). En caso contrario, T deber ser cancelada.
El time-stamping bsico no asegura que se eviten las anomalas de concurrencia, pero si que impide los efectos
de las anomalas de la Actualizacin Perdida y los la Lectura Sucia (ya que si la transaccin no puede hacer un
commit, tampoco podrn hacerlo las que hayan ledo o escrito los objetos que ella ha actualizado).
TIME-STAMPING DINMICO
Consiste en asignar un time-stamp a las transacciones cuando tratan de acceder a un objeto que ha sido ledo o
actualizado por otra transaccin que no ha terminado todava. De este modo, se evitan algunas de las
cancelaciones de transacciones que se producen en el time-stamp bsico. Su funcionamiento es el siguiente:
Cuando T1 intenta leer o actualizar un objeto actualizado por T2 o intenta actualizar un objeto que T2 ya ha ledo:
1. Si T1 y T2 no tienen todava time-stamp, se les asigna a cada una un time-stamp, cumplindose que
TS(T1)>TS(T2).
2. Si una de las dos no tiene time-stamp, se le asigna, respetndose de nuevo que TS(T1)>TS(T2).
3. Si T1 y T2 tiene ya time-stamp y TS(T1)>TS(T2), entonces contina normalmente la ejecucin de las dos
transacciones. En caso contrario, se cancelar la transaccin T1.
Al igual que El time-stamping bsico, el time-stamping dinmico no asegura que se eviten las anomalas de
concurrencia, pero si que impide los efectos de las anomalas de la Actualizacin Perdida y la Lectura Sucia.
Adems, es ms eficiente que el time-stamping estatico, ya que el nmero de cancelaciones que produce es
menor.
TIME-STAMPING MULTIVERSIN
Basada en almacenar versiones de los tems de la BD, permite el acceso simultneo a un tem por parte de
transacciones diferentes, de forma que los accesos de cada transaccin a los tems que necesita se hace siempre
usando versiones consistentes de esos tems.
4.4.2. MTODOS OPTIMISTAS
Basados en la suposicin de que los conflictos entre transacciones se producen con escasa frecuencia. Por tanto,
se acepta como vlido cualquier plan de ejecucin de transacciones, y es tras finalizar la ejecucin del plan y
antes de realizar el commit (los datos todava no son persistentes en la BD) cuando se comprueba si se ha
producido algn conflicto entre transacciones o se ha incumplido alguna condicin de consistencia. Si estos
problemas han aparecido, la transacciones afectadas se deshacen (abort) y vuelven a situarse en la entrada del
gestor de transacciones para su ejecucin.
En los mtodos optimistas se puede considerar la ejecucin de una transaccin dividida en tres fases:
La fase de lectura: En ella se produce la ejecucin de las acciones de la transaccin. Todos los objetos
de la BD que se necesitan son ledos y escritos de un buffer de memoria local al programa, y por tanto las
acciones no afectan al resto de las transacciones en ejecucin.
La fase de validacin: Se comprueba si las modificaciones introducidas por la transaccin pueden ser
hechas persistentes en la BD sin incumplir la condicin de serializabilidad de la transaccin.
La fase de escritura: Si la comprobacin realizada durante la fase de validacin es positiva, las acciones
de la transaccin se ejecutan sobre la BD. Si la comprobacin es negativa, la transaccin es abortada.
TCNICA OPTIMISTA BSICA
La tcnica optimista bsica determina el conjunto de transacciones que se han validado utilizando una tcnica de
time-stamping. Durante la fase de validacin se analiza si hay algn tem comn y del mismo nivel de
granularidad entre el conjunto de tems ledos por una transaccin T1 y el conjunto de tems que han escrito las
transacciones cuyo time-stamp se ha asignado entre el instante de inicio de y el instante de finalizacin de la fase
de lectura de la transaccin. Si no existe esa coincidencia, se aade un time-stamp a la transaccin T1.
Esta tcnica exige que haya como mucho una transaccin en la fase de validacin en cada instante de tiempo,
por lo que la fase de validacin acta como cuello de botella del sistema de gestin de transacciones.
4.4.3. MTODOS DE CONTROL DE CONCURRENCIA BASADOS EN LA SEMNTICA
Son mtodos que, adems de la sintaxis, utilizan la semntica de las acciones a realizar para determinar si un
plan de ejecucin es o no serializable. Es decir, no se limitan a comprobar si los accesos de las transacciones son
de lectura o escritura, sino que analizan qu van a escribir concretamente las acciones de las transacciones y
determinan si esas acciones pueden generar un conflicto o no.
5. CONCLUSIN
La creacin de una Base de Datos que sea capaz de responder a las exigencias de los usuarios es una tarea
extensa y compleja. Con el objetivo de obtener unos resultados con un alto nivel de calidad, el proceso de
construccin de una Base de Datos se divide en etapas, siendo el criterio de divisin el grado de abstraccin de
los productos construidos.
Las metodologas existentes proponen una divisin en diferentes nmeros de etapas, en las cuales se desarrollan
actividades y se emplean tcnicas diferentes. En este tema hemos presentado una metodologa de modelado
estructurado ampliamente aceptada, tanto por la estandarizacin de sus tcnicas (modelado relacional) como por
las etapas que incluyen, que suelen aparecer con ligeras variaciones en los manuales de BD existentes.
Finalmente, en este tema se ha hecho una exposicin somera de los motivos del uso de la concurrencia en las
BD, as como de las anomalas de funcionamiento que puede introducir esa concurrencia y de las tcnicas y
estrategias que los SGBD pueden utilizar para afrontar dichos problemas.
6. BIBLIOGRAFA
Diseo de Bases de Datos Relacionales, De Miguel, Piattini, et alter.
Data Models, Database Languages and Database Management Systems, Gottfried Vossen.
Tcnicas de Bases de Datos, Benet, Campderrich, Captulo X, 2 Edicin.
7. ESQUEMA RESUMEN
DISEO LGICO
El diseo lgico es la etapa del proceso de construccin de una BD que nos permite obtener un esquema lgico
de los datos representable en un SGBD comercial. La etapa de diseo lgico transforma las entidades e
interrelaciones conceptuales con las que hemos modelado el dominio del problema en tablas de la BD.
El modelo relacional es la tcnica de modelado lgico que se utiliza en la construccin de BD relacionales. La

obtencin de un modelo relacional a partir de un esquema conceptual exige seguir las siguientes reglas:
Un dominio del modelo E/R se transforma en un dominio en el modelo relacional

Una entidad en modelo E/R se transformar en una tabla (relacin) en el modelo relacional
Un atributo de una entidad se transformar en una columna de la tabla del modelo relacional.
Si el atributo es un identificador, la columna ser la clave primaria de la tabla.
Si es un identificador alternativo, habr que aadir a la columna la restriccin UNIQUE.
Si es un atributo multivaluado, habr que crear una nueva tabla con el atributo como columna y con la
misma clave primaria que la tabla que representa a la relacin.
La transformacin de una interrelacin se realiza siguiendo estas reglas:
Interrelaciones N:M: Se convierten en una tabla, sus columnas sern la concatenacin de los atributos
identificadores de las entidades relacionadas, siendo esas columnas su clave primaria.
Interrelaciones 1:N: Existen dos alternativas:
Se transforman igual que las interrelaciones N:M, pero el identificador de la tabla ser el mismo que el
de la tabla del lado M de la relacin.
No se transforma en tabla, incluyndose en la tabla del lado M de la relacin el conjunto de atributos
identificadores de la tabla del lado 1. Ese conjunto de atributos formarn una clave fornea en la tabla
del lado M.
Las interrelaciones 1:1 se transformarn igual que las interrelaciones 1:N, escogiendo el diseador a qu
tabla se quiere propagar la clave si hay propagacin y qu atributo es clave primaria si la interrelacin se
representa como una tabla.
Las interrelaciones con grado superior a 2 se transformarn de la misma manera que las interrelaciones
N:M, siendo su clave primaria la concatenacin de los atributos identificadores de todas las entidades
relacionadas.
Las interrelaciones de dependencia y existencia se transforman igual que las interrelaciones 1:M, propagndose
la clave que representa a la entidad fuerte dentro de la tabla que representa a la entidad dbil.
Las restricciones de entidades, atributos o relaciones no se escriben en el modelo relacional, pero se representan
en el esquema de BD utilizando el Lenguaje de Definicin de Datos.
Las generalizaciones se pueden transformar siguiendo tres estrategias:
Transformar la entidad y sus subtipos en una sola tabla, la cual tendr como atributos la concatenacin
de los atributos de la entidad y de los subtipos
Crear una tabla para la entidad generalizadora y una tabla por cada subtipo. Cada tabla tendr como
atributos los de su entidad o subtipo correspondiente.
Crear una tabla para cada subtipo. Cada tabla tendr como columnas los atributos del subtipo al que
representa y los atributos comunes (los que posee la entidad generalizadora).
La traduccin de la dimensin temporal sigue dos reglas:
Si aparece en el modelo E/R como una entidad, se transformar del mismo modo que el resto de las
entidades.
Si la dimensin temporal aparece en forma de atributos de una interrelacin, estos atributos se ubicarn
en la tabla que les corresponda al transformar la interrelacin.
Los atributos derivados se transformarn en columnas de la entidad a la que pertenezcan (como el resto de los
atributos). Adems, se establecer un disparador o un procedimiento almacenado que calcule el valor del atributo
cada vez que se modifique el valor de alguno de los atributos que se utilizan para su clculo.
DISEO LGICO ESPECFICO
En el diseo lgico especfico, se adapta el esquema estndar obtenido por este procedimiento a un esquema
especfico adaptado al SGBD que se utilice. Si el SGBD soporta el modelo lgico estndar, la transformacin ser
directa (usando el Lenguaje de Definicin de Datos del SGBD). Si no da soporte a algn aspecto (Dominio, Clave
primaria, Clave Fornea, etc.), debe utilizarse el Lenguaje de Definicin de Datos del propio SGBD para obtener
una representacin lo ms fidedigna posible a la representacin estndar, o hacer que sean los programas que
interactan con el SGBD los que controlen los aspectos no soportados.
Finalizado el diseo lgico estndar, tendremos una BD operativa en la que se podrn insertar, eliminar o
modificar datos y sobre la cual podremos realizar consultas.
CONCURRENCIA
Los SGBD utilizan transacciones con el fin de poder asegurar la consistencia de la informacin que tienen
almacenada.
Una transaccin es una unidad lgica de proceso que se compone de una secuencia de acciones cuya ejecucin
es atmica. En un punto intermedio de una transaccin, el estado de la Base de Datos puede ser inconsistente,
siendo siempre consistente al principio y al final de la transaccin.
Una transaccin ha de tener las siguientes propiedades:
Atomicidad: Las acciones de una transaccin se ejecutan todas o ninguna.

Consistencia: la base de datos se encuentra en un estado consistente antes de la ejecucin de la
transaccin y debe cuando la transaccin termine.
Aislamiento: La ejecucin de una transaccin no debe interferir en la ejecucin de otras transacciones, la
transaccin debe ejecutarse como si estuviera aislada.
Persistencia: Los efectos de una transaccin no son permanentes en la BD hasta que la transaccin ha
finalizado con xito.
El gestor de transacciones es el componente funcional del SGBD que planifica y controla la ejecucin de
transacciones concurrentes en una BD. El gestor de transacciones se compone de:
Un contenedor de entrada
Un planificador (scheduler)
Un contenedor de salida
Las BD se suelen utilizar en un entorno multiusuario, lo que obliga al SGBD a manejar las transacciones de
mltiples usuarios de forma concurrente. Los entornos multiusuario son muy exigentes en cuanto a rendimiento,
por lo que las transacciones no se ejecutan en serie, sino que sus acciones se ejecutan entrelazadamente, lo cual
puede provocar los siguientes problemas de concurrencia:
El problema de la actualizacin perdida: Ocurre cuando dos transacciones T1 y T2 trabajan en paralelo

e intentan modificar el valor del mismo objeto de la BD, leyendo ambas transacciones el valor antes de
que la otra lo actualice.
El problema de la Lectura Sucia : Se produce cuando una transaccin T1 lee un valor de un objeto que
ha sido modificado por otra transaccin T2 y que todava no se ha hecho persistente en la BD y la
transaccin T2, que haba modificado los datos no termina correctamente.
El problema de la lectura fantasma o lectura no repetible: Puede aparecer cuando una transaccin T1
est leyendo un conjunto de datos al tiempo que una transaccin T2 los est modificando y la transaccin
T1 lee algunos de los datos antes de que sean modificados por T2 y otros despus de ser modificados
por T2.
Para tratar de evitar estos problemas, el planificador del gestor de transacciones establece planes de ejecucin,
siendo un plan de ejecucin una secuencia de ejecucin de acciones de las transacciones.
Un plan de ejecucin debe cumplir la propiedad de ser serializable, es decir, que el resultado final de la ejecucin
del plan debe ser equivalente al resultado de ejecutar las transacciones una detrs de otra.
La comprobacin a priori de la serializabilidad de un plan es muy costosa, por lo que no se realiza. En lugar de
ello, el gestor de transacciones utiliza mecanismos de resolucin de los conflictos que se pueden presentar
cuando se ejecuta un plan. Estos mecanismos se pueden dividir en:
Mtodos pesimistas: Basados en la suposicin de que los conflictos entre transacciones concurrentes ocurren
con una alta frecuencia. Distinguimos los siguientes mtodos:
Basados en bloqueo: Un bloqueo es una reserva de un tem de datos para su uso por parte de una
transaccin. Los bloqueos se pueden clasificar segn su tipo (escritura o lectura) y segn su granularidad
(tamao del tem reservado), teniendo cada uno de los tipos sus propias reglas de compatibilidad con
otros bloqueos. El representante ms tpico de los mtodos basados en bloqueo es el Protocolo de
Bloqueo en dos fases o 2PL. Las tcnicas de bloqueo pueden conducir a situaciones de interbloqueo, en
el que dos transacciones se quedan esperando infinitamente por un recurso que ha bloqueado la otra
transaccin (y ninguna de las dos puede seguir avanzando). El gestor de transacciones debe detectar y
resolver estas situaciones.
Basados en marcas de tiempo: Basado en asignar marcas de tiempo o time-stamps a las
transacciones, estableciendo reglas de acceso a los recursos en funcin del valor de sus marcas de
tiempo. Distinguimos tres tipos de protocolos basados en marcas de tiempo:
Time-stamping bsico
Time-stamping dinmico
Time-stamping multiversin
Mtodos optimistas: Basados en la suposicin de que los conflictos entre transacciones se producen con
escasa frecuencia.

Ticb2 - Diseño de BBDD II

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ticb2 - Diseño de BBDD II

Transféré par

Droits d'auteur :

Formats disponibles

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

B2G2T05 - DISEO DE BASE DE DATOS II.

2. DISEO LGICO .............................................................................................................................................................. 2

El diseo lgico se puede dividir en dos etapas:

2.1. DISEO LGICO ESTNDAR

2.1.1. TRANSFORMACIN DE DOMINIOS

2.1.2. TRANSFORMACIN DE ENTIDADES

Figura 1: Entidad de un modelo E/R (conceptual)

Transformando la entidad al modelo relacional, obtendremos lo siguiente:

EMPRESA (CIF, Nombre, Direccin)

CREATE TABLE EMPRESA (

2.1.3. TRANSFORMACIN DE ATRIBUTOS

Identificadores: Se transforman en una columna que es la clave primaria de la tabla. En SQL-92, la

2.1.4. TRANSFORMACIN DE INTERRELACIONES

2.1.4.1. TRANSFORMACIN DE INTERRELACIONES N:M

Figura 2: Una interrelacin en el modelo E/R

CREATE TABLE VENDE

2.1.4.2. TRANSFORMACIN DE INTERRELACIONES

Las relaciones 1:N se pueden transformar de dos maneras:

2.1.4.3. TRANSFORMACIN DE INTERRELACIONES 1:1

2.1.4.4. TRANSFORMACIN DE INTERRELACIONES CON UN GRADO SUPERIOR A 2

2.1.5. TRANSFORMACIN DE INTERRELACIONES DE DEPENDENCIA Y EXISTENCIA

2.1.6. TRANSFORMACIN DE RESTRICCIONES DE ENTIDADES O ATRIBUTOS

Si la restriccin indica un rango de valores, se usa la clusula BETWEEN de SQL-92.

2.1.7. TRANSFORMACIN DE DEPENDENCIAS DE IDENTIFICACIN Y EXISTENCIA

2.1.8. TRANSFORMACIN DE RESTRICCIONES EN LAS INTERRELACIONES

2.1.9. TRANSFORMACIN DE GENERALIZACIONES (RELACIONES ISA)

Hay tres estrategias para llevar a cabo esta transformacin:

INTERINO (DNI, Nombre, Inicio_Contrato)

Figura 3: Una relacin ISA en el modelo E/R

2.1.10. TRANSFORMACIN DE LA DIMENSIN TEMPORAL

Se distinguen dos casos:

2.1.11. TRANSFORMACIN DE ATRIBUTOS DERIVADOS

2.1.12. NORMALIZACIN DEL ESQUEMA OBTENIDO

2.2. DISEO LGICO ESPECFICO

Los recursos software de los que se dispone

De lo dicho en los prrafos anteriores se pueden extraer las siguientes conclusiones:

3.1. METODOLOGA DE TRABAJO PARA LA OBTENCIN DEL DISEO FSICO

Podemos dividir a la etapa del diseo fsico en tres fases:

Diseo de la representacin fsica.

Anlisis de las transacciones.

Disear los mecanismos de seguridad.

Disear las vistas de los usuarios.

Monitorizar y ajustar del sistema.

3.1.1. ANLISIS DE LAS TRANSACCIONES

La frecuencia con que se va a ejecutar.

3.1.2. SELECCIN DE LA ORGANIZACIN DEL ALMACENAMIENTO EN MEMORIA SECUNDARIA

3.1.2.1. FICHEROS SECUENCIALES

3.1.2.2. FICHEROS SECUENCIALES INDEXADOS ISAM

1. Se localiza el ndice de la clave que cumpla la condicin de bsqueda.

3.1.2.4. FICHEROS DE ACCESO ALEATORIO EMPLEANDO TCNICAS DE HASHING

3.1.2.5. CRITERIOS DE ELECCIN ENTRE LAS ESTRUCTURAS

Archivos pequeos (es ms costoso gestionar el ndice

Recuperaciones masivas de los datos (habr que

HASH Bsquedas exactas (con todo el valor de la clave)

En todos aquellos casos en los que no convenga

Tabla 1: Situaciones apropiadas de aplicacin de los criterios de organizacin de la memoria secundaria.

3.1.3. CREACIN DE LOS NDICES SECUNDARIOS

Atributos de la relacin a los que se accede con mucha frecuencia.

Algunas situaciones que desaconsejan la introduccin de ndices secundarios son:

3.1.4. REALIZACIN DE AGRUPAMIENTOS DE TABLAS (CLUSTERING)

3.1.5. REALIZACIN DE PROCESOS DE DESNORMALIZACIN

El proceso de desnormalizacin consiste en introducir redundancias en un esquema lgico previamente