Antologia PDF

Antología
Universidad Tecnológica de Puebla
Ingeniería en Tecnologías de la Información y Comunicación
Materia:
Bases de datos para aplicaciones

Octavo cuatrimestre

Enero – Abril 2010
1

Colaboradores:

1. Erika Rodallegas Ramos
2. Rosario Titla Flores
3. Guillermo Sánchez Flores
4. Gabriel Coronado García

2

ÍNDICE
Contenido
1. Manipulación avanzada de datos con SQL ...................................................................................... 5
1.1 Introducción .............................................................................................................................. 5
1.2 Consultas Sencillas (Primeras consultas)................................................................................... 5
1.3 Consideraciones importantes al hacer consultas en el lenguaje SQL ...................................... 9
1.3.1 Una forma de salvar las consultas (querys) ..................................................................... 10
1.3.2 Especificando condiciones para seleccionar renglones .................................................. 11
1.3.3 Trabajando con valores nulos .......................................................................................... 13
1.3.4 Manejo de Valores duplicados ......................................................................................... 13
1.3.5 Salida Ordenada ............................................................................................................... 15
1.3.6 Funciones de Agregación ................................................................................................. 15
1.3.7 Ejecutando conteo simple ............................................................................................... 16
1.4 Una vista rápida de los Joins .................................................................................................. 16
1.4.1 Joins dentro del Álgebra Relacional ................................................................................ 16
1.4.2 Otros tipos de Join ............................................................................................................ 23
2. Bases de Datos Distribuidas .......................................................................................................... 28
2.1 Bases de Datos Homogéneas y Heterogéneas ........................................................................ 28
2.2 Almacenamiento Distribuido de los Datos .............................................................................. 29
2.2.1. Réplica de datos .............................................................................................................. 29
2.2.2. Fragmentación de los datos ............................................................................................ 30
2.2.3. Transparencia .................................................................................................................. 32
3. Transacciones ................................................................................................................................ 34
3.1 Serialización ............................................................................................................................ 34
3.2 Atomicidad .............................................................................................................................. 35
3.3 Tipos de transacciones ............................................................................................................ 36
3.4 Nivel Repeatable Read ............................................................................................................ 40
3.5 Nivel Read Uncommited.......................................................................................................... 41
3.6 Lectura de datos no confirmados ............................................................................................ 42
3

3.7 Lectura de datos confirmados ................................................................................................. 42
3.8 Lectura repetible ..................................................................................................................... 42
3.9 Control de Concurrencia ......................................................................................................... 43
3.10 Transacciones Abortadas ...................................................................................................... 44
3.11. Gestión de bloqueos en SQL Server ..................................................................................... 44
3.11.1 Bloqueos y rendimiento ................................................................................................. 44
3.11.2 Recursos de los bloqueos. Granularidad del bloqueo .................................................... 45
3.11.3 Tipos de bloqueo en SQL Server..................................................................................... 45
Compatibilidad de bloqueos ..................................................................................................... 46
Bloqueos de índices ................................................................................................................... 47
3.12 Concepto de espacios de trabajo (tablespace) ..................................................................... 47
3.13Programación de transacciones ............................................................................................. 53
4. Bases de datos orientadas a objetos ......................................................................................... 69
5. Business Intelligence ................................................................................................................. 69
5.1 Introducción ............................................................................................................................ 69
5.2. Datawarehouse ...................................................................................................................... 69
5.3. Business Intelligence .............................................................................................................. 73
5.3.1. Datamarts ........................................................................................................................ 74
5.3.2. OLAP ................................................................................................................................ 77
5.3.3. Datamining ...................................................................................................................... 80
5.3.4. KPI’s ................................................................................................................................. 83

4

1. Manipulación avanzada de datos con SQL

1.1 Introducción
Para dar comienzo a este primer tema de la materia de Bases de datos para aplicaciones, se debe
de tener en cuenta que no es un curso introductorio al manejo de base de datos, sino más bien, es
la continuación de los cursos anteriores en donde se considera que el alumno ya tiene los
conocimientos previos de modelado de datos, características principales del modelo relacional, y
conceptos básicos del lenguaje SQL.
Aunque en algunos temas se dará una breve introducción a manera de recordatorio práctico, en
general se trata de ir más allá de lo básico y que el alumno se involucre en la resolución de
problemas prácticos orientados al manejo de datos de diversas aplicaciones, así como también
revisar las tendencias y estrategias que actualmente ofrecen los diferentes productos de
administración de bases de datos (DBMS’s) para hacer más ágil todo el manejo de una base de
datos.
1.2 Consultas Sencillas (Primeras consultas)
Si una base de datos se ha diseñado correctamente, los datos estarán distribuidos en varias tablas
diferentes. Recordando que una base de datos con una sola tabla no cumple muchas de las
características obligadas y necesarias en la normalización de una base de datos relacional, el
mejor diseño de una base de datos es aquel que involucra varias tablas relacionadas a través de
sus llaves primarias y foráneas, e incluso con tablas que solamente sirven para definir la relación
entre otras tablas (por ejemplo una relación muchos a muchos).
Por ejemplo si se quiere implementar una base de datos que permita almacenar la información de
un club de golf, tendrá tablas separadas con información de los miembros, equipos, y torneos, así
como también tablas para conectar esos valores, por ejemplo para relacionar que miembros
pertenecen a que equipos, que miembros están participando en cuales torneos, y más. Para hacer
el mejor uso de los datos, se necesitarán combinar valores de diferentes tablas. Así como trabajar
a través de combinaciones complicadas para obtener el resultado de una consulta, podemos
imaginar que el conjunto de renglones resultantes de cada paso se está colocando dentro de una
“tabla virtual”. Se puede pensar que una tabla virtual se construye para el orden que lleva la
consulta y solo es temporal. En cada paso de una consulta solo estamos interesados en algunos de
los datos dentro de la tabla virtual y de alguna manera se van filtrando dichos datos. A lo largo de
este capítulo se dará un repaso de las consultas sencillas y se dará una vista a consultas que
5

involucran un poco más de análisis. Los datos se tomarán de tablas permanentes que pertenecen a
una base de datos, o incluso de tablas virtuales que se han generado temporalmente como parte
de una consulta más complicada.
Por ejemplo, se podrá ver información acerca de los miembros que se encuentran contenidos en
una tabla de la base de datos del “club de golf”. En donde a lo mejor se quiere ver información
acerca de algunos de los miembros (un subconjunto de renglones), o se quieren ver solo algunos
valores de cada miembro (un subconjunto de las columnas). O quizá, se quiere una combinación
de ambos. Se puede pensar que una consulta consiste en obtener un subconjunto de información
que es “cortada” de un subconjunto de renglones y columnas de una tabla y entonces después es
“pegada” dentro de una tabla temporal o virtual, como se muestra de forma gráfica en la figura
1.1

Figura 1.1 Representación gráfica de los pasos de una consulta
Consultas sencillas pueden proporcionar información para reportes, para subconjuntos de datos
para análisis, y respuestas a preguntas específicas. La figura 1.2 muestra algunos ejemplos de la
tabla miembro (Member) de la base de datos Club de Golf.
6

Figura 1.2 ejecución de consultas sobrre la tabla mem
mbers
El recu
uperar renglo
ones y colum
mnas hace usso de las opeeraciones del algebra relaacional select y
proyeccción. Casi tod
das las consuultas en al meenos una de sus etapas in ncluyen operaaciones select y
de proyección.
La recu
uperación de un subconju unto de renglones es una de las operacciones más comunes que se
consideran para haacer una conssulta. En las siguientes seecciones, se analizará
a la recuperación de
7

renglones de varias tablas que se encuentran dentro de la base de datos. La misma idea se aplica
para la selección de renglones de tablas virtuales resultantes de otras manipulaciones de los datos
correspondientes.
Algebra Relacional para la recuperación de Renglones
La operación select del álgebra relacional permite la recuperación u obtención de renglones desde
una tabla. Para decidir cuales renglones debe de recuperar, se necesita especificar una condición
para la operación. Básicamente, una condición es una sentencia que puede dar como resultado
falso o verdadero al ser evaluada. Se aplica la condición a cada renglón de la tabla
independientemente, y se retienen los renglones para los cuales la condición es verdadera y se
descartan los demás. Por ejemplo, si se quiere obtener a todos los hombres del club de golf, dado
que dentro de la tabla miembro (Member) desde su construcción se contemplo una columna
Gender, solo hay que indicar que se quiere obtener el subconjunto de renglones donde el valor del
campo Gender es `M`, lo cual llega a ser la condición de la operación select.
La notación en álgebra para obtener a los hombres del club, se muestra a continuación

La letra griega Sigma () representa a la operación select, y en forma de subíndice se estable la
condición.
Traduciendo la consulta que recupera información acerca de los hombres dentro de la base de
datos del club de golf al lenguaje SQL, quedaría de la siguiente forma:
Esta consulta se compone de tres partes, o clausulas: la clausula SELECT dice que información se
va a recuperar. En este caso, * significa que va a recuperar la información de todas las columnas.
La clausula FROM dice las tablas o tabla en la cual la consulta se desarrolla, y la clausula WHERE
describe la condición para decidir cuando un renglón en particular deberá ser incluido en el
resultado, para este caso la condición verifica el valor del campo Gender para que sea igual a ‘M’
(Men).
En el caso de la recuperación de columnas, se utiliza la operación proyección del álgebra
relacional. Para recuperar nombres(Names) y números telefónicos (Phone Numbers) de la tabla
miembros (Member) a través de la sintaxis del algebra relacional quedaría expresado de la
siguiente forma:
8

La expresión anterior del algebra relacional al traducirse al lenguaje de consulta SQL, quedaría
representado mediante la siguiente consulta:
ç
Para este caso se van a mostrar las columnas indicadas para todos los renglones, porque no se
está definiendo una condición específica a través de la clausula WHERE.
1.3 Consideraciones importantes al hacer consultas en el lenguaje SQL
Después de haber elaborado y validado cuidadosamente un diseño de base de datos relacional, se
implementa en algún DBMS que permita la representación de las tablas, y el manejo de los datos a
través del lenguaje SQL.
Puede ser común que dada la relación que existe entre diversas tablas de la base de datos, en
algún momento campos de distintas tablas pueden llegar a contener el mismo nombre (aunque
algunos autores no lo recomiendan, ya en la práctica suele ser común) , y dejar ambiguo el
significado a la hora de definir las columnas que se quieren obtener dentro de una consulta. Por
eso es muy sano, desde el momento de definir las columnas a recuperar, poner como prefijo la
tabla a la que corresponden, y de esta forma aunque los campos se llamen iguales ya no existe
ambigüedad porque se define con el prefijo a que tabla corresponde. Las buenas prácticas
sugieren definir las consultas de la siguiente forma:
Aunque de la forma anterior se evitan ambigüedades, en la práctica puede llegar a ser muy largo,
cansado y hasta poco entendible definir consultas de la forma anterior, sobre todo si se está
usando bases de datos con muchas tablas que tengan nombre demasiado largos. Sin embargo
para facilitar las cosas, dentro del lenguaje SQL se puede hacer uso de alías sobre las tablas. La
consulta anterior utilizando alías quedaría así:
9

En la clausula FROM se ha definido un alías o nombre alternativo para referirse a la tabla Member,
que en este caso el alías es m, con lo cual se evita el nombre completo de la tabla y además se
siguen evitando las ambigüedades que pudieran llegar a ocurrir.
Hasta este momento las consultas han sido muy sencillas y se han incluido solo un subconjunto de
renglones, o en otra consulta independiente un subconjunto de columnas, sin embargo en la
práctica es común definir consultas que involucran una combinación de renglones y de columnas o
a la inversa, lo cual indica que se hará uso de las operaciones proyección y select del álgebra
relacional de forma combinada. Un caso explícito de este tipo de combinaciones es la que se
muestra en la Figura 1.2 c). La cual estaría representada en la siguiente expresión del álgebra
relacional.
Nuevamente recordemos que el álgebra relacional nos dice como obtener el resultado que se
quiere. Para este caso, primero obtiene el subconjunto de renglones, y después las columnas
requeridas. Traducida la expresión de álgebra relacional anterior al lenguaje SQL se haría de la
forma siguiente:
1.3.1 Una forma de salvar las consultas (querys)
Se ha estado hablando de que las consultas “devuelven” u “obtienen” información de las tablas
contenidas en una base de datos, sin embargo surge la pregunta obligada, ¿Qué pasa con los
renglones resultantes de una consulta? En realidad no solo se está obteniendo información y se
coloca en cualquier lugar; lo que se ve como el resultado de una consulta es un subconjunto de
información obtenido de las tablas que están en la base de datos. SI los datos de la base cambian,
entonces los resultados de las consultas también deben de cambiar, es aquí en donde entra el
concepto de “tabla virtual”, que es la tabla en donde se almacenan los resultados de una consulta
y es virtual porque solo es temporal para la ejecución de una consulta determinada, además la
tabla virtual será tan grande como lo sea el subconjunto de datos obtenidos.
10

Para mantener los resultados de una consulta en una nueva tabla permanente (algunas veces
llamada fotografía), que no es muy recomendable porque no mantendría los datos actualizados
sobre todo si la información de la base original cambia. Por ejemplo si se almacena en una tabla
permanente los datos de la lista de teléfonos de los miembros, y después de agregar nuevos
miembros, la tabla permanente que se había generado anteriormente ya no estaría actualizada
con los nuevos teléfonos. En todo caso sería más conveniente volver a ejecutar la consulta que
genera la lista de teléfonos , pero sería muy molesto tener que escribir cada rato la misma
consulta, en lugar de hacer esto, se pueden almacenar las instrucciones de la consulta dentro de lo
que se conoce como una vista (view),la cual al ser invocada re‐ejecuta las instrucciones de la
consulta sobre la que está construida la vista, y mantendrá los datos siempre actualizados, porque
en realidad es una consulta disfrazada de vista. El siguiente ejemplo muestra la creación de una
vista (view).
Para el ejemplo anterior PhoneList es una “tabla virtual“, que se puede utilizar como una de las

tablas reales de la base de datos, e incluso puede ser parte de otras consultas, solo se debe de
tener en cuenta que las vista es creada “al vuelo” .
1.3.2 Especificando condiciones para seleccionar renglones
Como ya se ha ilustrado en diferentes ejemplos, el “filtrado” o “selección” de renglones está
basado en una condición lógica o boleana, la cual se evalúa o ejecuta sobre cada uno de los
renglones de la tabla o tablas sobre las que se está trabajando. Para determinar la condición es
necesario hacer uso de diferentes operadores, dentro de los cuales se encuentran los siguientes:
Operadores de comparación

Operador Significado Ejemplo

= Igualdad
< Menor que
<= Menor o Igual que
> Mayor que

>= Mayor o igual que
<> Diferente
11

Ejemplos de expresiones booleanas que se pueden ejecutar sobre la tabla Member
Expresión Renglones recuperados
Todos los miembros Junior
Todos los miembros con hándicap de 12 o menor
Cualquiera que sea miembro desde antes del inicio
del 2000
Todas las mujeres

Operadores Lógicos

También se pueden combinar expresiones booleanas para crear condiciones más interesantes. Por
ejemplo, se pueden especificar que dos expresiones deben ser ambas verdaderas antes de
regresar un renglón en particular. Por ejemplo si queremos obtener a todos los miembros que son
mujer y que son tipo Junior, quedaría de la siguiente forma:
Algunos ejemplos de los operadores lógicos se muestran a continuación
Expresión Descripción de los datos Diagrama de datos

recuperados recuperados
Seniors que tienen un
hándicap menor a 12

Todos los miembros senior

o cualquiera que tenga un
hándicap menor a 12
12

Todos los miembros

excepto los que sean de
tipo social
1.3.3 Trabajando con valores nulos
Desde que se va construyendo la definición de cada tabla, se puede restringir a que un campo
pueda o no aceptar valores nulos, un valor nulo significa que para un campo de cualquier tipo de
los que se permiten definir (int, char, varchar, etc.) no se le asigne valor alguno (como si se
quedara vacio), aunque el campo no tenga valor asignado se puede tomar en cuenta para
búsquedas. Por ejemplo, considere la siguiente consulta
La cual va a devolver a todos los renglones que no se les haya asignado un valor en su campo
MemberType.
Para devolver a todos los renglones que si tengan definido un valor para su campo Handicap, se
ejecutaría una consulta como la siguiente
1.3.4 Manejo de Valores duplicados
En muchas ejecuciones que se ejecutan consultas que devuelven una sola columna, y dicha
columna puede contener un dato que se puede repetir para diferentes renglones, al generar el
resultado de la consulta, se van a obtener varios valores duplicados. Por ejemplo si se quiere
obtener solo la columna PrimerNombre (FirstName) de la tabla Member. El resultado obtenido
puede ser como el de la figura 1.3.
13

Como se puede ver, se obtienen valores duplicados debido a que varias personas pueden llamarse
igual, y no es un error de la consulta, de hecho para obtener el resultado de la Figiura 1.3 es
simplemente ejecutar la consulta SELECT FirstName FROM Member, si se quiere obtener el
resultado sin que aparezcan valores duplicados, se puede usar la palabra clave DISTINCT, como se
muestra a continuación.
SELECT DISTINCT m.FirstName
FROM Member m

14

Figura 1.3 Resultado de ejecutar la consulta que solo devuelve FirstName
1.3.5 Salida Ordenada
Es muy común que dentro del contexto de diferentes problemas sea necesario presentar los
resultados de una consulta de forma ordenada, de acuerdo al criterio definido por un campo
determinado. Para hacer esto, se puede utilizar la frase clave ORDER BY. Por ejemplo, la siguiente
consulta muestra cómo recuperar información de los miembros ordenada alfabéticamente por el
campo LastName
También se puede hacer la ordenación por dos o más valores. Por ejemplo, si se quiere ordenar los
miembros tipo Senior por su LastName y su FirstName, la consulta SQL sería como la siguiente:
1.3.6 Funciones de Agregación
Las funciones de agregación son funciones que toman una colección (un conjunto o
multiconjunto) de valores como entrada y producen u único valor como salida. SQL proporciona
cinco funciones de agregación primitivas:
• Promedio: avg
• Mínimo: min
• Máximo: max
• Total: sum
• Cuenta: Count
La entrada a sum y avg debe ser una colección de números, pero los otros operadores pueden
operar sobre colecciones de datos de tipo no numérico, tales como las cadenas.
15

1.3.7 Ejecutando conteo simple
Así como se puede recuperar un subconjunto de renglones y columnas de una tabla, también se
pueden usar consultas SQL para obtener algunas estadísticas. Existen funciones SQL que permiten
contar registros, valores totales o valores promedio, encontrar valores máximos y mínimos, y más.
El conteo más simple es el que devuelve el número total de renglones de una tabla. Por ejemplo

También se puede contar un subconjunto de renglones agregando una clausula WHERE para
especificar lo que deben de cumplir los renglones. Por ejemplo
Además la función COUNT se puede combinar con otras palabras claves como el DISTINCT, y
generar consultas como la siguiente
La cual va a devolver solo el número de renglones que tienen un valor definido en el campo
Handicap y no va a tomar en cuenta a los valores duplicados.
Para ejemplos de las demás funciones de agregación se sugiere consultar [2] en su tema 4.4
1.4 Una vista rápida de los Joins
1.4.1 Joins dentro del Álgebra Relacional
El join es una de las operaciones del álgebra relacional, que primero se definirá en términos de
álgebra. Recordando que el álgebra dice el cómo obtener los resultados de lo que se está viendo,
y un join consiste de dos pasos. El primer paso involucra una operación llamada Producto
Cartesiano.
Producto Cartesiano
16

Se define como la operación más versátil entre dos tablas, porque puede ser aplicado a
cualquieras dos tablas de cualquier forma.
Un producto cartesiano es “algo” como poner dos tablas espalda con espalda. Se puede echar un
vistazo a las dos tablas en la Figura 1.4: una abreviación de la tabla Member y la tabla Type.

Figura 1.4 Abreviación de la tabla Member y de la tabla Type

Figura 1.5 Algunos renglones resultantes del producto cartesiano
La tabla virtual resultante del producto cartesiano tendrá una columna para cada una de las
columnas de las dos tablas contribuyentes. Los renglones en la tabla resultante consisten de todas
las combinaciones de los renglones de las tablas originales. La figura 1.5 muestra unos cuantos
renglones del producto cartesiano.
En la figura 1.5 se puede notar que se encuentran las cuatro columnas de la tabla Member y las
dos columnas de la tabla Type, lo cual produce seis columnas en total. Y cada renglón es una
combinación de el renglón de una tabla con todos los renglones de la otra tabla. El producto
cartesiano puede producir tablas muy largas, por lo cual se dice que en realidad no nos
17

proporciona mucha información útil. La expresión del algebra relacional para el producto
cartesiano es la siguiente:
Inner Join
Si se observa detenidamente la tabla de la figura 1.5, la mayoría de los renglones carecen de
bastante sentido, porque de una persona se está diciendo que puede ser de varios tipos, sin
embargo, si tomamos solo el subconjunto de renglones donde el valor de la columna MemberType
empate con el valor de la columna Type de la otra tabla, entonces se obtendrá valiosa información
acerca de los honorarios para cada uno de nuestros miembros. Esta combinación de un producto
cartesiano seguida de una operación select es conocida como un inner join (comúnmente llamado
solamente join). La condición para los renglones que se quieren recuperar es conocida como la
condición join la expresión del álgebra que recupera a los miembros con su honorario (fee)
apropiado es la siguiente
Del lado izquierdo de la ecuación anterior la x entre barras (que parece a una pequeña corbata)
representa el join entre las dos tablas, y la expresión join se expresa como subíndices. En el lado
derecho de la ecuación, se ejecuta una operación select sobre el resultado del producto
cartesiano. La figura 1.6 describe el proceso del inner join de forma gráfica.
Las dos columnas que se están comparando para cumplir la igualdad (MemberType y Type) deben
cumplir lo que algunas veces se refiere como un join compatible. Dentro de la teoría relacional
pura, esto significa que ambas deben llegar a tener el mismo conjunto de posibles valores (lo que
formalmente se define como el dominio). En términos prácticos la compatibilidad del join
usualmente significa que las columnas en cada una de las tablas tengan el mismo tipo de datos.
Diferentes productos de bases de datos pueden interpretar la compatibilidad del join diferente.
Algunos pueden permitir ejecutar join sobre un número flotante dentro de una tabla y un entero
en otra tabla, esto puede llegar a ser confuso en algunos casos, como cuando se quiere hacer join
entre cadenas y valores carácter. Por todo esto se recomienda que no se intente hacer join sobre
campos de diferentes tipos de datos, a menos que se tenga muy claro lo que va a devolver tu
producto particular.
18

Figura 1.6 Un join es un producto cartesiano seguido por un select
Para ejecutar producto cartesiano y join dentro del lenguaje SQL, es importante resaltar que no
todas las versiones de SQL tienen las mismas palabras clave (keywords) para implementar dichas
operaciones. Desde 1992 palabras clave representaban algunas de las operaciones del álgebra
fueron agregadas al estándar de SQL, y desde entonces se han realizado muchas actualizaciones
desde entonces, sin embargo no todos los proveedores incorporan todas las partes del estándar, e
incluso muchos hacen sus propias versiones del lenguaje (como T‐SQL para Microsoft o P‐SQL
para Postgress). También puede ser probable que algunas versiones de SQL no implementen
todas las funciones del algebra que se están definiendo en estos temas.
La frase clave dentro del SQL para el producto cartesiano es CROSS JOIN, por ejemplo
La frase SQL para un join es INNER JOIN. LA forma de indicar la condición del join va después de la
palabra clave ON, como se muestra a continuación
Otra forma alternativa SQL para obtener un join que produzca la tabla de la figura 1.6 b), es de la
siguiente forma
19

Ahora que se han agregado joins a nuestro arsenal de operaciones relacionales se pueden ejecutar
numerosos tipos de consultas. Porque el resultado de un join (como el de cualquier otra
operación) es otra tabla, por lo que se puede juntar el resultado a una tercera tabla (y a otras
más) y después aplicar operaciones select o de proyección para algún resultado que se requiera.
Para mostrar un ejemplo completo, se van a utilizar las tablas de la figura 1.7. Las tablas Miembro
(Member), torneo (Tournament) proporcionan detalles acerca d elos miembros y los torneos, y la
tabla Entrada (Entry) tiene información acerca de los miembros que han participado en los
diferentes torneos. En la tabla Entry, se tienen los números de ID de los miembros y de los torneos
como claves foráneas, y si se quiere agregar información adicional (digamos el nombre del
miembro o tipo de torneo), se necesita encontrar esto de la tabla Member y de la tabla
Tournament respectivamente. Digamos que se quiere encontrar los nombres de l cualquiera que
ha participado en un torneo abierto en el 2006.

Figura 1.7 tres tablas a considerar
Podemos enfocarnos a la pregunta “¿Cuáles son los nombres de la gente que participo en un
torneo abierto en el 2006?”
20

Usando el enfoque de algebra , se puede comenzar con las tres tablas, así que se necesita alguna
operación relacional que combine datos de más de una tabla. Comenzando con Member y la
Entry, se puede realizar la siguiente operación
Lo cual va a producir lo de la figura 1.8

Figura 1.8 el join de Member y la Entry
Después se tendría que hacer el join de Tournament con el resultado de la figura 1.8, y eso se
puede lograr con la siguiente expresión algebraica
21

Lo que va a provocar el resultado de la figura 1.9

Figura 1.9 join de la tabla Torunament con la tabla de la figura 1.8
Obteniendo el resultado de la Figura 1.9, ya se puede contestar la pregunta planteada, sin
embargo, si queremos ejecutar varias veces la consulta, se tendría que estar escribiendo toda la
sentencia SQL cada vez que se quiera obtener el resultado. Sin embargo, en temas anteriores se
recomendó el uso de una vista para no tener que escribir todo y ya se menciono como funcionan
las vistas, por lo tanto la consulta ya en el lenguaje SQL sería de la siguiente forma:
22

Para este caso la vista que almacena todo el resultado de la figura 1.9, se va a llamar AllTourInfo,
sin embargo la tabla resultante que genera la vista, va a devolver más información que lo que
pregunta solicitaba, así que sobre lo que devuelve la vista se puede hacer select y proyección y
obtener solo lo que realmente pide la pregunta. La expresión en álgebra quedaría así
Y ya traducida a SQL sería así
Para este caso se construyo primero la vista, aunque no es necesario, eso fue solo para recordar
que si se va a requerir ejecutar varias veces una consulta es práctico definir una vista, pero si no se
quiere usar la vista, la consulta SQL completa sería como la que sigue
1.4.2 Otros tipos de Join
Los Join que se han visto en este tema son del tipo equi‐join. Un equi‐join es un join donde las
condiciones tienen una igualdad como en m.MemberID=e.MemerID. Este es el más común tipo de
condición, pero se pueden tener distintos operadores. Recordemos que por definición un join es
solo el producto cartesiano seguido por una operación select, y la condición del select puede
consistir de diferentes operadores de comparación, y también puede incluir operadores lógicos,.
Este tipo de join no devuelve comúnmente todo.
Así como existen los llamados inner join que se han utilizado para “filtrar” un producto cartesiano,
también existen los llamados outer joi. La mejor forma de entender un outer join es ver en donde
son utiles. De un vistazo a la figura 1.10 que muestra a las tablas Member (modificada) y la Type.
23

Figura 1.10 las tablas Member y Type
Supongas e que se quiere producir diferentes listas de la tabla Member, como son números y
nombres, nombres y tipos de membresia, y más. En estas listas se espera ver a todos los miembros
(usando las tablas de la figura 1.10 que podrían tener nueve renglones). Entonces probablemente
se puede pensar que también se pueden ver los números y nombres en tu lista de miembros, y se
podría llegar a incluir también el honorario (fee). Entonces se decide hace join de las dos tablas
(con la condición MembeType = Type) y se encuentra que se “perdio” una de los miembros que es
Barbara Olson, como lo muestra la figura 1.11
Figura 1.11 Inner Join en donde se perdió al miembro Barbara Olson
La razón es que Barbara Olson no tiene un valor para MemberType dentro de la tabla Member.
Supóngase que al ver el producto cartesiano que es el primer paso al ejecutar el join, se obtiene lo
de la figura 1.12.
24

Después del producto cartesiano, se tiene que realizar la parte final de la operación join, la cual es
aplicar la condición (MemberType = Type). Como se ve en la Figura 1.12, no existe renglón para
Barbara Olson que satisfaga la condición porque tiene un valor nulo (Null) o vacio en la columna
MemberType.

Figura 1.12 Parte del producto cartesiano entre las tablas Member y Type
Considere ahora las siguientes dos preguntas en ”lenguaje natural”. “Obtener los honorarios (fees)
de los miembros” y “Solo obtener los miembros que tienen honorarios”. La primera tiene una
implicación de “Solo obtener los miembros que tienen honorarios”, mientras que la segunda tiene
más de un sentido “Devolver todos los miembros e incluir los honorarios para aquellos que los
tengan”. Una de las más grandes dificultades acerca de escribir consultas es intentar decidir
exactamente qué es lo que se quiere. Supongamos que lo que se quiere es una lista de todos los
miembros, y luego de donde se encuentre la información de los honorarios agregársela. En este
caso se quiere ver a Barbara Olson incluida en el resultado aunque ella no despliegue sus
honorarios. Es aquí en donde se usa un outer join. Los outer join pueden venir en tres tipos:
izquierda (left), derecha (right), y outer join completo (full). Por ejemplo observe detalladamente
el siguiente left outer join entre la tabla Member y la tabla Type, que generan el resultado de la
figura 1.13
Lo que el left outer jooin hace es recuperar todos los renglones de la tabla izquierda, aun aquellos
que tengan un valor nulo en el campo del join (de la condición), así se puede ver que se obtuvieron
todos los renglones del inner join de la figura 1.11 para los cuales se cumplió la condición, más el
renglón de Barbara, pero además los campos del renglón que vinieron de la tabla derecha (Type)
tiene valores nulos.
A continuación se muestra ya en lenguaje SQL , el resultado que se obtuvo en la figura 1.13, que es
lo mismo que el join ordinario, solo que ahora se usa la frase clave INNER JOIN
25

Figura 1.13 Resultado del left outer join de Member y Type
Podría ser bastante razonable decir que no habría necesidad de tener un outer join si todos los
miembros tienen un valor para su campo MemberType, lo cual es cierto para ese caso, sin
embargo como ya se menciono anteriormente los valores nulos son una propiedad que se le
puede definir a cada campo desde que se construye la tabla, sin embargo puede ocurrir que para
un determinado problema se permitan valores nules y depues al hacer join se obtenga menos
información de la que debe de ser, y es ahí en donde se necesita su uso.
¿Y que hay acera del right y full outer join? El Left y Right son lo mismo y solo depende sobre cual
orden se pungan las tablas en la sentencia del join. La siguiente sentencia SQL devolverá la misma
información que la del left outer join, sin embargo las columnas se presentarán en un orden
diferente.
De la misma forma que el left outer join devolverá cualquier renglón que tenga un valor nulo en eñ
campo join d ela tabal derecha (Member). Un full outer join retendrá los renglones con un valor
nulo en el campo join de ambas tablas. El SQL es el mismo que el anterior solo se cambia la frase
clave FULL OUTER JOIN, y producirá el resultado de la figura 1.14
Nota importante. No todas las implementaciones de SQL tienen un full outer join implementado
explícitamente, sin embargo pueden contener equivalencias que realizan la misma operación y por
tanto dan el mismo resultado, tal es el caso de Access 2007 que no incluye el full outer join, sin
embargo en el capítulo 7 del [1] se muestra los equivalentes.
26

Figura 1.14 Resultado del Full Outer Join entre la tabla Member y Type.
En el capítulo 4 de [1] se muestran varios ejemplos con la ejecución de consultas anidadas.
También del capítulo 1 al 3 de la referencia [3] se muestran como ejecutar diferentes consultas
usando un enfoque un tanto diferente orientado al DBMS SQL Server 2008 y un poco más de
programación.
27

2. Bases de Datos Distribuidas

A diferencia de los sistemas paralelos, en los que los procesadores se hallan estrechamente
acoplados y constituyen un único sistema de bases de datos, los sistemas distribuidos de bases de
datos consisten en sitios débilmente acoplados que no comparten ningún componente físico.
Además, puede que los sistemas de bases de datos que se ejecutan en cada sitio tengan un grado
sustancial de independencia mutua.
Cada sitio puede participar en la ejecución de transacciones que tienen acceso a los datos de uno
o varios de los sitios. La diferencia principal entre los sistemas de bases de datos centralizados y
los distribuidos es que, en los primeros, los datos residen en una única ubicación, mientras que en
los segundos los datos residen en varias ubicaciones. La distribución de los datos es causa de
muchas dificultades en el procesamiento de las transacciones y de las consultas. En este capítulo
se comentan algunas de esas dificultades.
Se comienza por clasificar las bases de datos distribuidas en homogéneas y heterogéneas. Luego
se aborda el problema del almacenamiento de los datos en las bases de datos distribuidas.
Después se comenta un modelo de procesamiento de las transacciones en bases de datos
distribuidas.
2.1 Bases de Datos Homogéneas y Heterogéneas
En las bases de datos distribuidas homogéneas todos los sitios tienen idéntico software de
sistemas gestores de bases de datos, son conscientes de la existencia de los demás sitios y
acuerdan cooperar en el procesamiento de las solicitudes de los usuarios. En estos sistemas los
sitios locales renuncian a una parte de su autonomía en cuanto a su derecho a modificar los
esquemas o el software del sistema gestor de bases de datos. Ese software también debe
cooperar con los demás sitios en el intercambio de la información sobre las transacciones para
hacer posible el procesamiento de las transacciones entre varios sitios.
A diferencia de lo anterior, en las bases de datos distribuidas heterogéneas sitios diferentes
puede que utilicen esquemas diferentes y diferente software de gestión de sistemas de bases de
datos. Puede que unos sitios no sean conscientes de la existencia de los demás y puede que solo
28

proporcionen facilidades limitadas para la cooperación en el procesamiento de las transacciones.
Las diferencias en los esquemas suelen constituir un problema importante para el procesamiento
de las consultas, mientras que la divergencia del software supone un inconveniente para el
procesamiento de transacciones que tengan acceso a varios sitios.
En este tema la atención se centrará en las bases de datos distribuidas homogéneas. No obstante,
se discutirán brevemente los aspectos del procesamiento de las consultas en los sistemas de bases
de datos distribuidas heterogéneas.
2.2 Almacenamiento Distribuido de los Datos
Considérese una relación r que hay que almacenar en la base de datos. Hay dos enfoques del
almacenamiento de esta relación en la base de datos distribuida:
• Réplica. El sistema conserva replicas (copias) idénticas de la relación y guarda cada replica
en un sitio diferente. La alternativa a las replicas es almacenar solo una copia de la
relación r.
• Fragmentación. El sistema divide la relación en varios fragmentos y guarda cada
fragmento en un sitio diferente.
La fragmentación y la réplica pueden combinarse: Las relaciones pueden dividirse en varios
fragmentos y puede haber varias replicas de cada fragmento. En los subapartados siguientes se
profundizara en cada una de estas técnicas.
2.2.1. Réplica de datos
Si la relación r se réplica, se guarda una copia de dicha relación en dos o más sitios. En el caso más
extremo se tiene una réplica completa, en la que se guarda una copia en cada sitio del sistema.
Hay varias ventajas y desventajas en las réplicas.
• Disponibilidad. Si alguno de los sitios que contiene la relación r falla, la relación puede
hallarse en otro sitio distinto. Por tanto, el sistema puede seguir procesando las
consultas que impliquen a r, pese al fallo del sitio.

• Paralelismo incrementado. En caso de que la mayoría de los accesos a la relación r
solo resulten en la lectura de la relación, varios sitios pueden procesar en paralelo las
lecturas que impliquen a r. Cuantas más réplicas de r haya, mayor será la posibilidad
29

de que los datos necesarios se hallen en el sitio en que se ejecuta la transacción. Por
tanto, la réplica de los datos minimiza el movimiento de los datos entre los sitios.

• Sobrecarga incrementada durante la actualización. El sistema debe asegurar que
todas las réplicas de la relación r sean consistentes; en caso contrario pueden
producirse cómputos erróneos. Por eso, siempre que se actualiza r hay que propagar
la actualización a todos los sitios que contienen replicas. El resultado es una
sobrecarga incrementada. Por ejemplo, en un sistema bancario, en el que se replica en
varios sitios la información de las cuentas, es necesario asegurarse de que el saldo de
cada cuenta concuerde en todos los sitios.
En general, la réplica mejora el rendimiento de las operaciones leer y aumenta la disponibilidad de
los datos para las transacciones solo de lectura. No obstante, las transacciones de actualización
suponen una mayor sobrecarga. El control de las actualizaciones de actualización realizadas por
varias transacciones en los datos replicados resulta más complicado que en los sistemas
centralizados. Se puede simplificar la gestión de las réplicas de la relación r escogiendo una de
ellas como copia principal de r. Por ejemplo, en un sistema bancario, las cuentas pueden asociarse
con el sitio en que se abrieron. De manera parecida, en un sistema de reserva de boletos de avión,
los vuelos pueden asociarse con el sitio en que se origina el vuelo. Se examinará el esquema de
copias principales y otras opciones del control de la concurrencia distribuida.
2.2.2. Fragmentación de los datos
Si la relación r se fragmenta, r se divide en varios fragmentos r1, r2, . . . , rn. Estos fragmentos
contienen suficiente información como para permitir la reconstrucción de la relación original r.
Hay dos esquemas diferentes ce fragmentación de las relaciones: fragmentación horizontal y
fragmentación vertical. La fragmentación horizontal divide la relación asignando cada tupla de r en
uno o más fragmentos. La fragmentación vertical divide la relación descomponiendo el esquema R
de la relación r.
Estos enfoques se ilustrarán fragmentando la relación cuenta, con el esquema
esquema‐cuenta = (numero‐cuenta, nombre‐sucursal, saldo)
En la fragmentación horizontal la relación r se divide en varios subconjuntos, r1, r2, . . . , rn. Cada
tupla de la relación r debe pertenecer como mínimo a uno de los fragmentos, de modo que se
pueda reconstruir la relación original, si fuera necesario.
A modo de ejemplo, la relación cuenta puede dividirse en varios fragmentos, cada uno de los
cuales consiste en tuplas de cuentas que pertenecen a una sucursal concreta. Si el sistema
bancario solo tiene dos sucursales (Guadarrama y Cercedilla) habrá dos fragmentos diferentes:
30

Cuenta1 = σ nombre‐sucursal, = «Guadarrama» (cuenta)
Cuenta2 = σnombre‐sucursal = «Cercedilla» (cuenta)
La fragmentación horizontal suele utilizarse para conservar las tuplas en los sitios en que más se
utilizan, para minimizar la transferencia de datos.
En general, los fragmentos horizontales pueden definirse como una selección de la relación global
r. Es decir, se utiliza un predicado Pi, para construir fragmentos ri:
ri=σPi(r)
Se reconstruye la relación r tomando la unión de todos los fragmentos; es decir,
r = r1 U r1 U …. U r1
En el ejemplo los fragmentos son disjuntos. Al cambiar los predicados de selección empleados
para crear los fragmentos se puede hacer que una tupla concreta de r aparezca en más de uno de
los fragmentos ri.
En su forma más sencilla la fragmentación vertical es igual que la descomposición. La
fragmentación vertical de r(R) implica la definición de varios subconjuntos de atributos R1, R2,...,
Rn del esquema R de modo que
R=R1UR2U…URn
Cada fragmento ri, de r se define mediante
ri = U∏Ri(r)
La fragmentación debe hacerse de modo que se pueda reconstruir la relación r a partir de los
fragmentos tomando la reunión natural
Una manera de asegurar que la relación r pueda reconstruirse es incluir los atributos de la clave
principal de R en cada uno de los fragmentos Ri. De manera más general, se puede utilizar
cualquier superclave. Suele resultar conveniente añadir un atributo especial, denominado id‐tupla,
al esquema R. El valor id‐tupla de una tupla es un valor único que distingue cada tupla de todas las
demás. El atributo id‐tupla, por tanto, sirve como clave candidata para el esquema aumentado y
se incluye en cada uno de los fragmentos La dirección física o lógica de la tupla puede utilizarse
como id‐tupla, dado que cada tupla tiene una dirección única.
Para ilustrar la fragmentación vertical considérese una base de datos universitaria con una
relación info‐empleado que almacena, para cada empleado, id‐empleado, nombre, puesto y
salario. Por motivos de preservación de la intimidad puede que esta relación se fragmente en una
31

relación empleado‐infoprivada que contenga id‐empleado y salario, y en otra relación empleado‐
infopública que contenga los atributos id‐empleado, nombre y puesto. Puede que las dos
relaciones se almacenen en sitios diferentes, nuevamente, por motivos de seguridad.
Se pueden aplicar los dos tipos de fragmentación a un solo esquema; por ejemplo, los fragmentos
obtenidos de la fragmentación horizontal de una relación pueden dividirse nuevamente de
manera vertical. Los fragmentos también pueden replicarse. En general, los fragmentos pueden
replicarse, las replicas de los fragmentos pueden fragmentarse mas, etcétera, etcétera.

2.2.3. Transparencia
No se debe exigir a los usuarios de los sistemas distribuidos de bases de datos que conozcan la
ubicación física de los datos ni el modo en que se puede tener acceso a ellos en un sitio local
concreto. Esta característica, denominada transparencia de los datos, puede adoptar varias
formas:
• Transparencia de la fragmentación. No se exige a los usuarios que conozcan el modo en
que se ha fragmentado la relación.
• Transparencia de la réplica. Los usuarios ven cada objeto de datos como lógicamente
único. Puede que el sistema distribuido replique los objetos para incrementar el
rendimiento del sistema o la disponibilidad de los datos. Los usuarios no deben
preocuparse por los objetos que se hayan replicado ni por la ubicación de esas replicas.
• Transparencia de la ubicación. No se exige a los usuarios que conozcan la ubicación física
de los datos. El sistema distribuido de bases de datos debe poder hallar los datos siempre
que la transacción del usuario facilite el identificador de los datos.
Los elementos de datos (como las relaciones, los fragmentos y las replicas) deben tener nombres
únicos. Esta propiedad es fácil de asegurar en una base de datos centralizada. En las bases de
datos distribuidas, sin embargo, hay que tener cuidado para asegurarse de que dos sitios no
utilicen el mismo nombre para elementos de datos diferentes.
Una solución a este problema es exigir que todos los nombres se registren en un servidor de
nombres central. El servidor de nombres ayuda a asegurar que el mismo nombre no se utilice para
elementos de datos diferentes. También se puede utilizar el servidor de nombres para ubicar un
elemento de datos, dado el nombre del elemento. Este enfoque, sin embargo, presenta dos
inconvenientes principales. En primer lugar, puede que el servidor de nombres se transforme en
un cuello de botella para el rendimiento cuando los elementos de datos se ubican por sus
nombres, lo que da lugar a un bajo rendimiento. En segundo lugar, si el servidor de nombres que‐
da fuera de servicio, puede que no sea posible que siga funcionando ningún otro sitio del sistema
distribuido.
32

Un enfoque alternativo más utilizado exige que cada sitio anteponga su propio identificador de
sitio a cualquier nombre que genere. Este enfoque asegura que dos sitios no generen nunca el
mismo nombre (dado que cada sitio tiene un identificador único). Además, no se necesita ningún
control centralizado. Esta solución, no obstante, no logra conseguir la transparencia de la
ubicación, dado que se adjuntan a los nombres los identificadores de los sitios. Así, se puede hacer
referencia a la relación cuenta como sitio17.cuenta, o cuenta@sitio 17, en lugar de meramente
cuenta. Muchos sistemas de bases de datos utilizan la dirección de internet de los sitios para
identificarlos.
Para superar este problema el sistema de bases de datos puede crear un conjunto de nombres
alternativos o alias para los elementos de datos. Así, los usuarios se pueden referir a los artículos
de datos mediante nombres sencillos que el sistema traduce en los nombres completos. La
asignación de los alias a los nombres reales puede almacenarse en cada sitio. Con los alias el
usuario puede ignorar la ubicación física de los elementos de datos. Además, el usuario no se verá
afectado si el administrador de la base de datos decide trasladar un elemento de datos de un sitio
a otro.
Los usuarios no deben tener que hacer referencia a una réplica concreta de un elemento de datos.
En vez de eso, el sistema debe determinar la réplica a la que hay que hacer referencia en las
solicitudes leer, y actualizar todas las replicas en las solicitudes escribir. Se puede asegurar que Io
haga manteniendo una labia de catalogo que el sistema utiliza para determinar todas las replicas
del elemento de datos.

Para ver la replicación desde un punto de vista práctico para pensar en su implementación a través
de programación, se sugiere el capítulo 17 de la referencia [4]. Porque lo que vendría a
continuación es la parte de transacciones distribuidas, pero primero es conveniente cubrir el tema
de transacciones. Las transacciones distribuidas vienen documentadas en la sección 19.3 de la
referencia [2].
33

3. Transacciones

Hasta ahora el modelo de operación en las bases de datos ha sido o de consultas, o de
modificaciones a la Base de datos.
Hemos siempre supuesto que las acciones se ejecutan una a la vez y que cada una se lleva a cabo
completamente.
Hemos supuesto que ni el software ni el hardware pueden fallar en el intertanto de una operación.
La vida real es muchísimo más compleja.
No sólo el hardware o el software pueden fallar dejando a la BD en un estado inexplicable a partir
de operaciones.
El sistema de base de datos normalmente está siendo accedido simultáneamente por muchos
usuarios tanto para hacer consultas como actualizaciones.
Algunas ejecuciones paralelas pueden intercalarse de manera tal de dejar a la BD en un estado
inconsistente.
3.1 Serialización
Supongamos que en una aplicación de reserva de pasajes para un vuelo existe un procedimiento
que:
• busca un asiento libre
• lo marca como ocupado
• asigna el asiento al pasajero que ejecutó la llamada
Es totalmente posible que al mismo tiempo dos pasajeros ejecuten el procedimiento
simultáneamente y dejen la BD en un estado “indeseable”.
P1 P2
P1 llama al procedimiento P2 llama al procedimiento

Se encuentra asiento 10 libre Se encuentra asiento 10 libre
34

Se marca 10 ocupado Se marca 10 ocupado

Se asigna 10 a P1 Se asigna 10 a P2
Ambos pasajeros quedan con el mismo asiento asignado, la BD queda en un estado indeseable.
Nos gustaría que sea cual sea el orden de ejecución, el estado de la BD quedara “como si se
hubiese” ejecutado un procedimiento primero y luego el otro.
A esto se le llama una ejecución serializable.
Si cualquier ejecución de los procedimientos anteriores fuese serializable entonces nunca se le
asignaría a dos pasajeros el mismo asiento.
IMPORTANTE: NO queremos que los procedimientos siempre se ejecuten uno tras otro, sólo
necesitamos que el resultado sea “serializable”.
3.2 Atomicidad
Supongamos que tenemos una aplicación bancaria y un procedimiento para transferir fondos
entre las cuentas A1 y A2:
1. Se verifica que A1 tenga suficiente dinero.
2. Se aumenta el saldo de A2 en el monto especificado.
3. Se disminuye el saldo de A1 en el monto especificado.
Supongamos que el sistema falla justo antes de comenzar a ejecutar la línea 3.
La BD queda en un estado indeseable (al menos para el banco).
En el ejemplo anterior nos gustaría que las operaciones se ejecutaran todas o que ninguna de ellas
se ejecutara.
35

La ejecución de una operación es atómica si el estado de la BD luego de la operación es como si
todos sus componentes se hubiesen ejecutado o como si ninguno de ellos lo hubiese hecho.
Los problemas de serialización y atomicidad pueden ser resueltos usando transacciones.
Una transacción está compuesta por un grupo de instrucciones de SQL que se ejecutan
atómicamente (se ejecutan todas o ninguna).
Por defecto además, una transacción exige ejecuciones serializables.
En SQL2 se puede especificar más libertad en la ejecución que simplemente serializable, esto se
hace modificando los niveles de aislamiento que veremos más adelante.
Una transacción se comienza con una instrucción begin transaction (no es necesario en algunos
DBMS).
La instrucción commit termina la transacción en forma exitosa y hace permanente cualquier
cambio realizado a la BD durante la transacción.
Los cambios se hacen permanentes sólo después de un commit.
La instrucción rollback aborta la transacción y la hace terminar en forma no exitosa, cualquier
cambio que la transacción pudo hacer a la BD se deshace.
En general se puede hacer rollback para cualquier conjunto de instrucciones no necesariamente
dentro de una transacción.
Para el ejemplo de transferencia de fondos:
1. begin transaction
2. Si A1 no tiene suficiente dinero Æ rollback.
3. Se aumenta el saldo de A2 en el monto especificado.
4. Se disminuye el saldo de A1 en el monto especificado.
5. commit.
3.3 Tipos de transacciones
SQL permite definir distintos tipos de transacciones.
Cada uno de ellos define las posibilidades de accesos y enmallado de instrucciones que se pueden
dar durante la ejecución de transacciones en paralelo.
36

Se permiten los siguientes niveles de aislamiento:
• serializable (por defecto)
• repeatable read
• read commited
• read uncommitted
Para setearlos se usa set transaction, por ejemplo
set transaction repeatable read.
SQL Server realiza y mantiene una serie de bloqueos durante la transacción. Existen dos formas de
modificar el tratamiento de los bloqueos.
La primera de ellas consiste en introducir cláusulas en las sentencias “select”. Estas cláusulas
modificarán el tratamiento de los bloqueos de las unidades afectadas (filas, tablas, páginas; la
granularidad también es seleccionable y se tratará más adelante) por la sentencia y se mantendrán
hasta la finalización de la transacción.
La segunda, se mantiene durante toda la sesión. Para modificar la forma en que una sentencia
“select” gestiona una transacción y sus bloqueos se utiliza la sentencia “set transaction isolation
level” que tiene las siguientes opciones o niveles de aislamiento, mutuamente excluyentes:
“read committed”: Es el comportamiento predeterminado. La transacción mantiene
bloqueos compartidos durante el tiempo que dure la lectura. La transacción puede
encontrarse con lecturas no repetibles o datos fantasma dado que el bloqueo no impide a
otras transacciones modificar los datos que se han leído.
“read uncommitted”: Con este nivel de aislamiento una transacción puede leer datos sucios
de otras transacciones. Es el nivel de aislamiento menos restrictivo. Esta opción tiene el
mismo efecto que usar la opción “nolock” en una sentencia “select”.
“repeatable read”: A medida que se leen datos se establecen bloqueos de forma que otra
transacción no pueda modificar datos leídos. Este nivel de aislamiento es más restrictivo y
puede hacer que otras transacciones se bloqueen. No evita que se puedan añadir nuevas
filas.
“snapshot”: Con este nivel de aislamiento las consultas de la transacción en curso sólo
leerán los datos confirmados antes del comienzo de la misma. Dado que la transacción en
curso trabaja con una instantánea de los datos, capturada en el momento de inicio de la
transacción, las lecturas de datos de esta transacción no solicitan bloqueos y otras
transacciones que realicen operaciones de escritura no bloquearán a ésta.
“serializable”: Nivel de aislamiento más restrictivo ya que aplica un bloqueo al rango de
datos leídos. Proporciona, por tanto, protección ante lectura de filas fantasma.
37

Veremos un ejemplo para dejar claro cada uno de los niveles.
Supongamos una base de datos con una relación con esquema vende (bar, cerveza, precio) que
indica que cierta cerveza se vende a cierto precio en cierto bar.
Supongamos que el bar de Pepe vende sólo Cristal a $450 y Escudo a $400.
Juan quiere preguntar por la cerveza más cara y más barata del bar de Pepe.
Al mismo tiempo Pepe elimina a Cristal y Escudo y comienza a vender sólo Kunstmann en $500.
En SQL, Juan ejecuta las instrucciones
select max(precio) from vende where bar = ’Pepe’
select min(precio) from vende where bar = ’Pepe’
que llamaremos (max) y (min) respectivamente.
Por su parte Pepe ejecuta
delete from vende where bar = ’Pepe’
insert into vende values(’Pepe’,’Kunstmann’,500)
que llamaremos (del), e (ins) respectivamente.
Supongamos que se ejecutan simultáneamente en la base de datos los dos grupos de
instrucciones.
Lo único que podemos asegurar con certeza es que (max) se ejecuta antes de (min), y que (del) se
ejecuta antes de (ins), pero nada más.
Una posible ejecución podría ser la siguiente:
Juan: (max) (min)
Pepe: (del) (ins)
Juan lee como máximo el precio de Cristal que es $450 y finalmente lee como precio mínimo el
precio de Kunstmann que es $500... el máximo es menor que el mínimo!!!!
Si Juan ejecuta sus instrucciones en una transacción con nivel de aislamiento serializable entonces
verá la base de datos antes o después de la ejecución de las instrucciones de Pepe pero nunca en
el medio.
38

Depende del DBMS cómo asegura esto, lo único que interesa es que la vista de los datos por parte
de Juan es como si uno de los grupos de instrucciones (de Juan o de Pepe) se ejecute antes que el
otro.
La elección de nivel serializable afecta sólo a quien la elige... por ejemplo, si Pepe ejecuta con
nivel serializable pero Juan no, Juan perfectamente podría ver los datos como si ejecutara en la
mitad de la transacción de Pepe.
Supongamos que Pepe ejecuta (del) e (ins) pero luego lo piensa mejor, se arrepiente y hace
rollback para deshacer los cambios.
Si Juan ejecuta su transacción después del (ins) pero antes del rollback se tiene
Juan: (max) (min)
Pepe: (del) (ins) rollback
Entonces Juan leerá el dato $500 como precio máximo y mínimo, sin embargo $500 es un dato que
nunca existir´a realmente en la base de datos, a esto se le llama Lectura Sucia.
Lectura Sucia: transacción T1 actualiza datos que T2 lee, luego T1 se aborta) T2 ha leído datos
inexistentes.
El nivel read commited evita la lectura sucia ya que como su nombre lo dice la transacción solo
podrá leer datos que han sido reafirmados por el commit de otra transacción.
De alguna forma el DBMS se las debe arreglar para que Juan no pueda leer el valor $500 si es que
Pepe hace rollback.
El nivel read commited es más permisivo que el serializable de hecho en la ejecución
Juan: (max) (min)
Pepe: (del) (ins)
es totalmente factible en read commited siempre que Pepe haga commit, y Juan verá que el
máximo es $450 y que el mínimo es $500.
39

3.4 Nivel Repeatable Read
Este nivel evita lo que se conoce como lectura no repetible.
Lectura No Repetible: transacción T1 lee los mismos datos dos veces, entre ambas lecturas una
transacción T2 elimina algunos datos) en la segunda lectura de T1 se pierden datos con respecto a
la primera.
El nivel repateable read es similar a read commited adicionando la restricción de que en una
transacción, todo lo que se vio en una lectura inicial debe ser visto si se ejecuta la misma lectura
posteriormente.
La segunda y siguientes lecturas pueden tener más datos que la primera pero nunca se pueden
perder datos.
Suponga que Juan ejecuta con nivel repeatable read y el orden de las instrucciones es:
Juan: (max) (min)
Pepe: (del) (ins)
Dado que durante la lectura (max) Juan leyó los valores $400 y $450, el sistema debe asegurar que
durante (min) se vean adicionalmente a $500, los valores $400 y $450 ya que estos fueron vistos
en la lectura anterior en (max).
En este caso los datos serán consistentes en la lectura para Juan (comparados con read commited)
ya que verá que el máximo precio es $450 y el mínimo es $400, a pesar de que esto no refleje el
estado real de la base de datos luego de las transacciones.
Este nivel sigue siendo más permisivo que serializable.
Supongamos que Juan intenta leer dos veces el precio máximo de las cervezas y en el intertanto
Pepe actualiza los precios
Juan: (max) (max)
Pepe: (del) (ins)
Si ejecuta en repeatable read se asegura que todo lo que lee en el primer (max) lo lee también en
el segundo (max), sin embargo en un caso obtiene que el máximo es $450 y luego $500, esto se
conoce como valor fantasma.
Fantasmas: T1 lee datos que cumplen cierta condición, T2 inserta un dato que cumple la
condición, si T1 vuelve a leer encontrará una nueva tupla fantasma.
40

3.5 Nivel Read Uncommited
Es el nivel más permisivo.
Una transacción que se ejecuta con nivel read uncommited puede ver valores que otra transacción
ha escrito, o dejar de ver valores que otra transacción haya borrado, a pesar de que esta no haya
hecho commit y posiblemente nunca lo haga.
Por ejemplo Juan podría perfectamente ver el valor $500 como precio máximo o mínimo a pesar
que Pepe posteriormente a la inserción aborte los cambios (rollback).
read uncommited permite entonces lecturas sucias, lecturas no repetibles y lecturas fantasmas.
Utilización de los niveles de aislamiento de las transacciones
Los niveles de aislamiento determinan el grado en que los datos incoherentes de una transacción
están protegidos frente a otras transacciones. En teoría, toda transacción debe estar
completamente aislada de otras transacciones, pero en la realidad, por razones prácticas, esto
puede no ser cierto siempre. El uso de un nivel u otro estará condicionado por la naturaleza de los
procesos de tratamiento de datos de cada aplicación en particular.
Para establecer el grado de aislamiento de las transacciones durante toda una conexión, en SQL
Server se utiliza la sentencia “set transaction isolation level”.
En un entorno multiusuario, pueden darse cuatro situaciones: actualización perdida, lecturas
sucias, lecturas no repetibles, lecturas fantasma.
Actualización perdida: No proporciona ningún aislamiento. La última transacción en
modificar el conjunto de datos prevalecerá y los cambios realizados por otras transacciones
se perderán.
Lecturas sucias: Una transacción puede leer datos que están siendo modificados por otras
transacciones. Estos datos son incoherentes porque las otras transacciones pueden decidir
cancelar los cambios.
Lecturas no repetibles: En esta situación una transacción lee los mismos datos dos veces,
pero entre una lectura y otra, otra transacción ha modificado los datos. Así, los datos
obtenidos en la primera lectura serán distintos a los obtenidos en la segunda.
Lecturas fantasma: En esta situación, la transacción 1 lee los datos en un rango de claves del
1 al 8, existiendo las filas 1, 3 y 5. Una segunda transacción inserta en la misma tabla una
fila con la clave 2. Cuando la transacción 1 realice una nueva consulta sobre dicho rango de
claves se encontrará con una fila que antes no existía.

41

Idealmente, un SGBD debe proporcionar niveles de aislamiento para evitar todas estas
situaciones. A veces, por razones de rendimiento y siempre condicionado por la naturaleza de los
procesos que manejan la información, pueden permitirse algunas de estas situaciones.
ANSI define los siguientes cuatro estándares para el aislamiento de transacciones: lectura de datos
no confirmados (N0), lectura de datos confirmados (N1), lectura repetible (N2) y serializable (N4).
SQL Server proporciona soporte para todos estos niveles.
3.6 Lectura de datos no confirmados
Si se selecciona el modo de lecturas no confirmadas no se proporciona ningún aislamiento a las
transacciones.
Una transacción que se ejecute con este nivel de aislamiento no será inmune a las lecturas sucias,
lecturas no repetibles ni lecturas fantasma.
La instrucción T‐SQL que selecciona este nivel de aislamiento es:
SET transaction isolation level READ uncommitted
3.7 Lectura de datos confirmados
Es el comportamiento predeterminado de SQL Server.
En este modo no se ejecutan inicios de transacciones implícitas. Durante la ejecución de una
sentencia se establece un bloqueo de actualización sobre el recurso a modificar. En cuanto
termine esta sentencia, se liberará el bloqueo.
En este nivel de aislamiento se protege a la transacción contra lecturas sucias, pero las
transacciones no son inmunes a la pérdida de actualizaciones, las lecturas no repetibles ni a las
lecturas fantasma.
SET transaction isolation level READ committed
3.8 Lectura repetible
SQL Server da inicio a una transacción de manera implícita al ejecutar una sentencia de
modificación de datos, por lo que será necesaria una sentencia “commit” o “rollback” para
terminarla. Este modo permite a las transacciones establecer bloqueos compartidos y exclusivos
sobre los recursos a modificar.
Bajo este nivel de aislamiento, las transacciones están protegidas contra pérdida de atualizaciones,
las lectruras sucias y las lecturas no repetibles. Sin embargo, dichas transacciones sí pueden sufrir
problemas de lecturas fantasma.
42

SET transaction isolation level repeatable READ
Podemos finalmente definir los distintos niveles de aislamiento a partir de si cada uno de ellos
permite o no lecturas sucias, lecturas no repetibles, y/o lecturas fantasmas.
Nivel Sucia No Repetible Fantasma
Serializable NO NO NO

Repeatable read NO NO SI

Read commited NO SI SI

Read uncommited SI SI SI

Entonces podemos concluir de lo anterior que una transacción es una unidad lógica de trabajo que
tiene ciertas propiedades conocidas como propiedades ACID: atomicidad, coherencia, aislamiento
y permanencia.
Es responsabilidad del sistema gestor de bases de datos el asegurar que se cumplan estas
propiedades. Sin embargo, el programador dispone de un cierto grado de control sobre la forma
en que SQL Server gestiona algunas de estas propiedades.
3.9 Control de Concurrencia
Forma en que el DBMS maneja las ejecuciones paralelas en la BD.
Principalmente dos enfoques:
• Optimista: supone que los conflictos son escasos ) permitir acceso concurrente y deshacer las
acciones problemáticas.
• Pesimista: asume que es muy probable que ocurran problemas) actúa a la defensiva impidiendo
la aparición de conflictos usando locks.
43

Un lock es una estructura que sólo puede ser adquirida por una hebra de ejecución (thread) a la
vez.
Si dos ejecuciones tratan de obtener un lock para actualizar una tabla, la primera que trate de
obtenerlo tendrá acceso exclusivo a la tabla, la segunda debe esperar a que la primera lo suelte
para obtener el acceso.
Los locks pueden tener distintas granularidades: Base de Datos, Tabla, Tupla, Atributo.
Además de los locks exclusivos existen locks de solo lectura o locks compartidos que pueden estar
simultáneamente siendo utilizados por distintas ejecuciones.
3.10 Transacciones Abortadas
Una transacción puede no llegar a su término debido a muchas razones:
⇒ situación excepcional detectada que hace que el programa no pueda continuar.
⇒ falla del programa
⇒ falla del software de BD
⇒ falla del Sistema Operativo
⇒ falla del hardware
⇒ falla de energía eléctrica
⇒ control de concurrencia ha detectado un conflicto
⇒ control de concurrencia ha detectado un deadlock

3.11. Gestión de bloqueos en SQL Server
El correcto funcionamiento y la eficiencia de nuestra aplicación que maneja usuarios concurrentes
accediendo a nuestra base de datos dependen de la configuración de SQL Server y de la
programación de la aplicación, así que, tanto para una cosa como para la otra, debemos
comprender y manejar estos conceptos.
3.11.1 Bloqueos y rendimiento
Los bloqueos son los encargados de hacer que las transacciones tengan la propiedad de
aislamiento. La realización de bloqueos en un entorno concurrente proporciona aislamiento en los
siguientes casos:
Múltiples transacciones intentan modificar la misma fila.
Datos no confirmados por una transacción son leídos por otras transacciones. Esto se
conoce como lecturas sucias.
44

Los datos leídos con la misma cláusula “select” durante varias etapas de la transacción dan
lugar a valores diferentes con el mismo conjunto de datos. Conocido como lecturas no
repetibles.
Los datos leídos con la misma cláusula “select” durante varias etapas de la transacción dan
lugar a diferentes conjuntos de datos. Es lo que se conoce como “lecturas fantasma”.

El establecimiento de los bloqueos es automático en SQL Server, no teniéndose que preocupar,
por tanto, el programador directamente por ellos, aunque debe tener en cuenta qué tipo de
bloqueos establece cada operación atendiendo a las cláusulas incluidas, etc., para minimizar los
interbloqueos.
3.11.2 Recursos de los bloqueos. Granularidad del bloqueo
El establecimiento de bloqueos es automático en SQL Server. El gestor de bloqueos es el
encargado de decidir el tipo y la granularidad del bloqueo.
Los bloqueos se pueden producir tanto a nivel de página de datos como a nivel de página de
índice. El gestor de bloqueo puede decidir bloquear los recursos: tabla, extensión, página, fila y
rango de clave.
La granularidad del bloqueo incide de forma directa sobre la concurrencia y el rendimiento del
sistema. El optimizador de consultas decide la granularidad del bloqueo automáticamente. No
obstante, SQL Server proporciona extensiones de T‐SQL que proporcionan un mecanismo para
controlar la granuralidad de los bloqueos.
3.11.3 Tipos de bloqueo en SQL Server
El procedimiento almacenado “sp_lock” proporciona los bloqueos activos en el sistema gestor de
bases de datos. También ofrecen información sobre bloqueos el administrador corporativo, el
monitor de rendimiento, el administrador de memoria y el objeto de SQL Server bloqueos.
Dependiendo del tipo de transacción, el gestor de bloqueos establece distintos tipos de bloqueos.
Bloqueos compartidos
Se establecen para operaciones de sólo lectura, por ejemplo “select”.
Varias transacciones pueden mantener varios bloqueos compartidos simultáneamente sobre el
mismo recurso ya que dichas transacciones no interfieren entre sí.
Si una transacción intenta modificar un dato de un recurso sobre el que se ha establecido un
bloqueo compartido, se bloqueará hasta que todos los bloqueos compartidos se liberen.
Un bloqueo compartido se libera en cuanto se finaliza la operación de lectura de datos, es decir,
no permanece a lo largo de la transacción. Existen cláusulas de las que se hablará más adelante
para modificar este comportamiento.
45

Bloqueos de actualización
Los bloqueos de actualización se usan para instrucciones que modifican datos.
Cuando una transacción intenta actualizar una fila primero ha de leerla para asegurarse de que la
fila en cuestión es realmente la que se quiere modificar. En este momento establece un bloqueo
compartido. Una vez se ha asegurado que es la fila correcta procederá a modificarla, para lo que
necesita establecer un bloqueo exclusivo que será liberado al terminar la transacción. Los
bloqueos de actualización se emplean como bloqueo intermedio entre los dos anteriores para
evitar interbloqueos.
Bloqueos exclusivos
Se concede un bloqueo de este tipo a una transacción cuando ésta está lista para modificar los
datos. Un bloqueo exclusivo sobre un recurso asegura que ninguna otra transacción pueda
interferir las acciones llevadas a cabo por la primera transacción sobre los recursos bloqueados.
SQL Server libera el bloqueo al finalizar la transacción.
Bloqueos de intención
El bloqueo de intención es un mecanismo que utilizan las transacciones para declarar su intención
de obtener un bloqueo compartido, de actualización o exclusivo sobre un recurso.
No establece ningún bloqueo en si, excepto por el hecho de que otra transacción no podrá
adquirir un bloqueo de actualización sobre un recurso sobre el que se haya establecido un
bloqueo de intención.
Bloqueos de esquema
Se utilizan para mantener la integridad estructural de las tablas SQL Server. A diferencia de otros
bloqueos, que proporcionan aislamiento para los datos, los bloqueos de esquema proporcionan
aislamiento para el esquema de objetos de la base de datos.
Compatibilidad de bloqueos
En la siguiente lista se muestra la compatibilidad entre los distintos tipos de bloqueo. Para cada
bloqueo que puede llegar a estar activo sobre una conexión al sistema gestor de bases de datos
SQL Server se lista qué tipos de bloqueo pueden solicitarse concurrentemente (por ejemplo, si
existe un bloqueo de modificación de esquema no puede solicitarse ningún otro tipo de bloqueo,
tal y como muestra el último elemento de esta lista).
De intención compartido: de intención compartido, compartido, de actualización, de
intención exclusivo, compartido de intención exclusivo y de estabilidad de esquema.
Compartido: de intención compartido, compartido, de actualización y de estabilidad de
esquema.
De actualización: de intención compartido, compartido y de estabilidad de esquema.
De intención exclusivo: de intención compartido, de intención exclusivo y de estabilidad de
esquema.
46

Compartido de actualización exclusivo: de intención compartido y de estabilidad de
esquema.
Exclusivo: estabilidad de esquema.
Estabilidad de esquema: de intención compartido, compartido, de actualización, de
intención exclusivo, compartido de intención exclusivo, exclusivo y de estabilidad de
esquema.
Modificación de esquema: ningún bloqueo es compatible con el bloque de modificación de
esquema.
Bloqueos de índices
De forma similar a los bloqueos de páginas de datos, SQL Server gestiona los bloqueos de las
páginas de índices internamente.
Con el comando “sp_indexoption” se puede modificar el gestor permitiendo o no bloqueos a nivel
de filas.
Se recomienda no realizar modificaciones sobre el comportamiento por defecto del gestor de
bloqueos en lo referente a las páginas de índices ya que suele hacer buenas elecciones.
3.12 Concepto de espacios de trabajo (tablespace)
Un tablespace es el archivo donde se almacenarán las tablas y datos de usuario.
Es un puente entre el sistema de ficheros del sistema operativo y la base de datos.
Cada tablespace se compone de, al menos, un datafile y un datafile solo puede pertenecer a un
tablespace.
Cada tabla o índice de pertenece a un tablespace, es decir cuando se crea una tabla o índice se
crea en un tablespace determinado.
Sintaxis:
CREATE [UNDO] TABLESPACE tablespace_name
DATAFILE Datafile_Options Storage_Options ;
47

Características del Espacio de trabjajo
En los tablespaces se almacenan los objetos del esquema de la BD (tablas, índices,
etc.), pudiéndose repartir por varios ficheros.
Una BD tiene varios tablespaces.
Un tablespace tiene varios datafiles.
Un datafile sólo pertenece a un tablespace y un tablespace sólo pertenece a una BD.
Estructura de los tablespace

TABLESPACE

Índice Tabla Tabla
Tabla Índice
Índice
Tabla
Índice

Tabla Índice

Tabla

48

Tipos de tablespaces
o Tablespace SYSTEM
Se crea automáticamente al hacer la instalación de SQL Server, o al crear una BD.
Contiene el diccionario de datos.
o Tablespaces temporales
Es aquél en el que solamente puede haber objetos temporales. No se pueden crear
objetos permanentes como pueden ser los índices, las tablas, operaciones de
ordenación, segmentos de rollback etc.
o De tipo deshacer cambios
Se utilizan para gestionar poder deshacer las transacciones incompletas. En
Rollback◊versiones anteriores
o Con tamaño de bloque variable
De tipo BigFile
Estado del tablespace
o Un tablespace puede estar en dos estados: Online y Offline. .
o Existe una vista que nos da información sobre los tablespaces de nuestra base de datos.
select tablespace_name, status from dba_tablespaces;
‐Estado del tablespace. Modo offine.
o Para poder hacer una copia de seguridad del tablespace estando completamente seguros
de que nadie está modificando los objetos del tablespace.
o Para poder actualizar una aplicación que se basa en los objetos de este tablespace sin que
ningún usuario pueda modificar los datos en medio de la actualización.
‐Estado del tablespace. Modo online.
o Lo contrario a las tablespace en modo offline.
CREACCION DE ESPACIOS DE TABLAS Y ARCHIVOS DE DATOS
Como se trató anteriormente, el espacio virtual donde se distribuyen las tablas y demás objetos se
denomina TABLESPACE, un tablespace puede ocupar físicamente varios archivos distribuidos en
toda la red de ordenadores.
49

Un archivo físico solo puede pertenecer a un único tablespace.
Para crear un tablespace basta con:
CREATE TABLESPACE mi_clase
DATAFILE ‘oracle1.ora’ SIZE 1M;
Esta sentencia, crea un espacio para las tablas llamado mi_clase, que físicamente va ocupar el
archivo oracle1.ora de 1 Megabyte de espacio.
DATAFILE ‘oracle1.ora’ SIZE 1M, ‘oracle2.ora’ SIZE 100K;
Esta sentencia, crea un espacio para las tablas llamado mi_clase, que físcamente va ocupar dos
archivos, el archivo oracle1.ora de 1 Megabyte de espacio y el archivo oracle2.ora de 100
Kilobytes.
Los Datafiles por defecto se crean en la carpeta :
Si queremos crearlos en otra carpeta o máquina, basta con poner la ruta completa:
DATAFILE ‘c:\documents and setting\admin\mis documentos\oracle1.ora’ SIZE 1M,
‘\192.168.0.33\d:\datos\oracle2.ora’ SIZE 100K;
Obviamente si se crea un datafile en otra máquina debemos tener permisos de escritura en la
misma, otorgados por el sistema operativo en red.
La extensión del archivo no es relevante:
DATAFILE ‘oracle1.dat’ SIZE 1M, ‘oracle2.tab’ SIZE 100K;
La Cláusula REUSE sirve para crear el archivo si no existe y si no redefinirlo.
CREATE TABLESPACE mi_clase2
DATAFILE ‘oracle1.dat’ SIZE 2M REUSE;
El archivo oracle1.data si no existe se crea, si existe y era de otro tablespace o de otro tamaño se
redefine y pasa a ser del tablespace mi_clase2 y de 2 megabytes de tamaño.
50

Los archivos pueden crearse autoextendibles, es decir que si se ocupa todo el tamaño
especificado, se aumenta automáticamente, lo malo que tiene este sistema es que se particiona
mucho la información físicamente y el acceso a los datos puede ralentizarse.
DATAFILE ‘oracle1.dat’ SIZE 2M
AUTOEXTEND ON;
Si no ponemos nada más, se autoextiende en múltiplos de 4kb (tamaño del cluster de oracle) lo
necesario en el momento del uso. Se puede especificar otra unidad diferente, es decir que cada
vez que precise aumentar lo hará en como múltiplo de los que especifiquemos:
AUTOEXTEND ON NEXT 1M;
Si queremos que se extienda pero solo hasta un límite:
AUTOEXTEND ON NEXT 1M
MAXSIZE 20M;
De esta forma el tablespace tiene 2M de tamaño inicial, crecerá en multiplos de 1 M hasta llegar a
20M.
Por defecto los datafiles no son autoextendibles, pero si queremos podemos especificárselo:
AUTOEXTEND OFF;
Si hacemos un datafile autoextendible, pero no especificamos la cláusula MAXSIZE, se
autoextendería de forma ilimitada, pero si queremos asegurarnos de ello escribiremos:
AUTOEXTEND ON
51

MAXSIZE UNLIMITED;
Se puede crear un tablespace bloqueado, es decir en el que no se pueda escribir en él:
OFFLINE;
Por defecto se crea desbloqueado, pero si queremos asegurarnos:
ONLINE;
CAMBIOS DE LOS TABLESPACES
Se realiza mediante la sentencia ALTER TABLESPACE, más la clausula que queramos cambiar:
ALTER TABLESPACE Mi_clase
ADD DATAFILE ‘oracle_adicional.ora’ SIZE 3M
AUTOEXTEND UNLIMITED
ONLINE;
BORRAR TABLESPACES
La sentencia siguiente borraría el tablespace y los archivos y todo lo que contiene:
DROP TABLESPACE mi_clase
INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;
52

3.13Programación de transacciones
Definición y estructura de una transacción.
y Una de las herramientas muy útiles en el desarrollo de aplicaciones de negocios
(Bussines‐applications), son las transacciones.

y Una transacción es un conjunto de operaciones que se realizan en la base de datos, o es
un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en
forma indivisible o atómica.

y Para que una transacción tenga éxito en su ejecución todas la operaciones que la
conforman deben de finalizar adecuadamente, si de todo el conjunto de operaciones una
sola llega a fallar, se considera que toda la transacción ha fallado y es necesario regresar
la base de datos a un estado anterior al comienzo de la ejecución de la transacción, ya que
las operaciones que se han completado exitosamente pueden llegar a dañar la integridad
de la información.

y Un ejemplo tradicional de una transacción es el siguiente:

y Suponga que se necesita transferir $1000 de una cuenta A hacia una cuenta B. Esta
operación involucra dos pasos:
y $1000 se deben reducir de la cuenta A.
y $1000 se deben agregar a la cuenta B.

y Suponga que se cumple satisfactoriamente el paso 1, pero por alguna razón ocurre un
error en el paso 2 y falla esta parte, esto lograría no tener bien actualizada la
información.

y Una transacción ayuda a evitar esto.

y Ya que las operaciones en la misma transacción deben de completarse todas con éxito

para considerar que la transacción finalizó satisfactoriamente, en caso de que una sola
operación no halla tenido éxito, la transacción completa se considera como no completada
y se deja la base de datos justo como el estado anterior a la ejecución de la transacción.

53

y Así en el ejemplo anterior si falla el paso 2, los cambios realizados por el paso 1 no
afectarán a la base de datos.

y Las transacciones usualmente siguen ciertas guías conocidas como las propiedades ACID,
las cuales aseguran que siempre transacciones complejas sean confiables.

y En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability:
Atomicidad, Consistencia, Aislamiento y Durabilidad en español.

y Atomicidad: es la propiedad que asegura que la operación se ha realizado o no, y
por lo tanto ante un fallo del sistema no puede quedar a medias.
y Consistencia: es la propiedad que asegura que sólo se empieza aquello que se
puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper
la reglas y directrices de integridad de la base de datos.
y Aislamiento: es la propiedad que asegura que una operación no puede afectar a
otras. Esto asegura que la realización de dos transacciones sobre la misma
información nunca generará ningún tipo de error.
y Durabilidad: es la propiedad que asegura que una vez realizada la operación, ésta
persistirá y no se podrá deshacer aunque falle el sistema.

y A diferencia de otros elementos que se han definido (como los procedimientos
almacenados), las transacciones no forman parte de la base de datos como tal, ya que
como solo son un conjunto de operaciones, las operaciones pueden incluir a los
elementos de la base de datos pero la ejecución es independiente a las operaciones.

y Por ejemplo, en el caso anterior, el deducir de la cuenta A y la agregación a la cuenta B,
pueden ser procedimientos almacenados que forman parte de la base de datos, que se
consideran como operaciones independientes dentro de una transacción.

y Para obtener la estructura de una transacción, es necesario identificar las operaciones que
intervienen en todo el proceso que va a representar dicha transacción.

y Se debe de tener un enfoque procedural de las operaciones que van a formar la
transacción. Por ejemplo la transacción Retirar_Dinero_de_Cajero es un proceso que se
compone de las siguientes operaciones:

54

y Retirar_Dinero_de_Cajero
y Validar al usuario
y Consultar saldo actual del usuario
y Confirmar que el retiro es menor o igual al saldo
y Consultar si el dinero alcanza para el monto del retiro
y Deducir el retiro del saldo actual
y Entregar dinero
y Detectar que se ha entregado el dinero

y Fin de la transacción

y Si se cumplen todas las operaciones de la transacción, entonces se hacen los cambios de
todas las operaciones, si alguna de las operaciones no se cumple satisfactoriamente, se
considera como una transacción errónea y es necesario reestablecer los datos a su estado
anterior.

Utilidad sqlcmd
Las bases de datos de Microsoft SQL Server 2005 Express Edition (SQL Server Express) se pueden
administrar ejecutando la utilidad sqlcmd desde el símbolo del sistema. Con esta utilidad vamos a
ejecutar algunas consultas para ver como trabajan las transacciones.
Utilizaremos para los ejemplos la base de datos “Autores” manejada en el apartado de “El
lenguaje SQL a través de C#.Net” visto anteriormente. Recordemos la estructura:
Estos son los pasos para usar las transacciones:
• Iniciar una transacción con el uso de la sentencia BEGIN TRANSACTION.
• Actualizar, insertar o eliminar registros en la base de datos.
55

• Si se quieren los cambios a la base de datos, completar la transacción con el uso de la
sentencia COMMIT. Únicamente cuando se procesa un COMMIT los cambios hechos por
las consultas serán permanentes.
• Si sucede algún problema, podemos hacer uso de la sentencia ROLLBACK para cancelar
los cambios que han sido realizados por las consultas que han sido ejecutadas hasta el
momento.
Cuando se establece una conexión con un servidor SQL Server Express, es necesario especificar el
nombre del servidor y, si SQL Server Express se ha instalado en una instancia con nombre, también
el nombre de la instancia. De manera predeterminada, sqlcmd utiliza la autenticación de
Windows.
Ejecutar la consola “símbolo de sistema” de Windows para establecer la conexión con el servidor y
la base de datos “Autores”, como se muestra a continuación:
Para que veamos más claramente la secuencia de comandos “limpiemos” los comandos anteriores
con la sentencia :!! cls :
Mostremos ahora los campos Id y Nombre de la tabla:
56

Ahora, como usar transacciones, eliminemos un registro:
Se eliminó el registro con Id 678.
57

Ahora bien, si en este momento ejecutamos un ROLLBACK, la transacción no será completada, y
los cambios realizados sobre la tabla no tendrán efecto.
Ahora vamos a ver que sucede si perdemos la conexión al servidor (comando exit) antes
de que la transacción sea completada.
58

Cuando obtengamos de nuevo la conexión, podemos verificar que el registro no se eliminó, ya que
la transacción no fue completada.
Vamos a repetir la sentencia DELETE ejecutada anteriormente, pero haremos un COMMIT antes de
perder la conexión al servidor al salir de la utilería sqlcmd.
Una vez que hacemos un COMMIT, la transacción es completada, y todas las sentencias
SQL que han sido ejecutadas previamente afectan de manera permanente a las tablas de
la base de datos.
59

Creación de transacciones desde el código.
y Para crear un objeto de transacción. Se crea sobre un objeto de conexión, llamando al

método begin trasaction, esta sentencia marca el inicio de la transacción.

y Después se establece la propiedad transaction de un objeto Command para el objeto de
transacción. Así es como ADO sabe que acción se tiene que deshacer cuando se haga un
rollback (transacción errónea).

SqlTransaction myTrans;
myTrans = myConnection.BeginTransaction() ;
myCommand.Transaction = myTrans;
y Ya que se estableció el inicio de la transacción, se debe de crear un manejador de
excepciones para atrapar algún error que ocurra durante el procesamiento de la
transacción y de esta forma detectar el error de una operación de la transacción.

y Todas las sentencias presentadas deben de aparecer en la cláusula Try del manejador de
excepciones, se realiza un rollback llamando al método Rollback del objeto transacción en
caso de ocurrir un error. Si la transacción ocurre sin problemas, entonces se realiza un
commit con el método del mismo nombre.
60

y Para implementar una transacción, se debe de marcar el inicio de la misma.

y Si la transacción falla, la base de datos debe de restaurarse al estado anterior que se
encontraba, justo antes de iniciar la transacción.

y Se inserta el código para todas las acciones que involucran la transacción, y al final se
realiza un commit de la transacción. Una vez que la transacción ha sido ejecutada y
aceptada, otros usuarios pueden ver sus efectos.

y Hasta entonces, otros usuarios no pueden ver los efectos de alguno de los pasos.

y En otras palabras, no existen transacciones parciales.

y Si un error provoca que se complete la transacción, se debe de hacer un rollback , el
siguiente seudocódigo es el esqueleto de una transacción:

Begin Transaction
Try
{Sentencias que conforman la transacción}
Commit Transaction
Catch Exception
Rollback Transaction
End Try
y Los siguientes códigos en C# muestran la inserción de un registro, la eliminación de un
registro con un procedimiento almacenado y por último la devolución de un parámetro de
un procedimiento almacenado mediante el método ExecuteScalar del objeto command
con la estructura de una transacción.

61

private void Insertar_Click(object sender, EventArgs e)
{
SqlConnection cnn;
SqlCommand ocmd;
String sCnn = @"Data Source=ARIES\SQLEXPRESS;Initial Catalog=Autores;Integrated
Security=True";
cnn = new SqlConnection(sCnn);
cnn.Open();
//Iniciando transacción Local
SqlTransaction sqltran = cnn.BeginTransaction();
//Asociar el objeto command a la transacción
ocmd = cnn.CreateCommand();
ocmd.Transaction = sqltran;
try
{
//Ejecutar el comando
ocmd.CommandText = "Insert into Autores values('678','Luis Juarez
Artega','PHP','GTH678','Colombiana')";
ocmd.ExecuteNonQuery();
sqltran.Commit();
MessageBox.Show("Inserción exitosa", "Transacción");
}
catch (Exception ex)
{
//Manejador de excepcion si la transación falla en el commit
62

MessageBox.Show(ex.Message .ToString (), "Transacción");
try
{
//Se deshace la transacción
sqltran.Rollback();
}
catch(Exception rollback)
{
//Por ejemplo, lanzar un InvalidOperationException si la conexión
//con la base está cerrada
}
}
}
private void Eliminar_Click(object sender, EventArgs e)
{
SqlConnection cnn;
SqlCommand ocmd;
String sCnn = @"Data Source=ARIES\SQLEXPRESS;Initial Catalog=Autores;Integrated
Security=True";
cnn.Open();
ocmd = new SqlCommand();
63

ocmd.CommandType = CommandType.StoredProcedure;
ocmd.CommandText = "Eliminar";
SqlParameter para1 = new SqlParameter("@p1", SqlDbType.NVarChar);
//parametro generado en sql @p1
para1.Size = 7; //tamaño de caracteres ha recibir el parametro
para1.Value = "678"; //valor del parámetro
para1.Direction = ParameterDirection.Input;
ocmd.Parameters.Add(para1); //Agrega el parámetro al objeto command
//Iniciando transacción Local
SqlTransaction sqltran = cnn.BeginTransaction();
//Asociar el objeto command a la transacción
ocmd.Transaction = sqltran;
ocmd.Connection = cnn;
try
{
//Ejecutar el comando
ocmd.ExecuteNonQuery();
sqltran.Commit();
MessageBox.Show("Eliminación exitosa", "Transacción");
}
64

catch (Exception ex)
{
//Manejador de excepcion si la transación falla en el commit
MessageBox.Show(ex.Message.ToString(), "Transacción");
try
{
//Se deshace la transacción
sqltran.Rollback();
}
catch (Exception rollback)
{
//Por ejemplo, lanzar un InvalidOperationException si la conexión
//con la base está cerrada
}
}
}
private void button1_Click(object sender, EventArgs e)
{
SqlConnection cnn;
SqlCommand ocmd;
String sCnn = @"dataSource=PowerToolkit;initial catalog=Northwind;integrated
security=SSPI";
65

cnn.Open();
SqlCommand myCommand = new SqlCommand () ;
myCommand.Connection = myConnection ;
SqlTransaction myTrans ;
myTrans = myConnection.BeginTransaction() ;
myCommand.Transaction = myTrans ;
try
{
myCommand.CommandText = "NewOrder";
myCommand.CommandType = CommandType.StoredProcedure ;
SqlParameter p = new SqlParameter() ;
p.ParameterName = "@CustID";
p.Direction = ParameterDirection.Input ;
p.SqlDbType = SqlDbType.Char;
p.Value = "BLAUS"
myCommand.Parameters.Add(p) ;
p = new SqlParameter() ;
p.ParameterName = "RETURN" ;
p.Direction = ParameterDirection.ReturnValue ;
p.SqlDbType = SqlDbType.Int;
myCommand.Parameters.Add(p);
66

myCommand.ExecuteScalar();
int orderID = CType(myCommand.Parameters("RETURN").value);
// Set up parameters collection and add first item
myCommand.CommandText = "NewOrderLine";
myCommand.CommandType = CommandType.StoredProcedure ;
myCommand.Parameters.Clear();
p = new SqlParameter();
p.ParameterName = "@OrderID";
p.Direction = ParameterDirection.Input ;
p.Value = orderID;
p.ParameterName = "@ProductID";
p.Direction = ParameterDirection.Input;
p.Value = 15;
myCommand.Parameters.Add(p) ;
p.ParameterName = "@Quantity";
p.Direction = ParameterDirection.Input;
p.Value = 1;
67

myCommand.ExecuteNonQuery();
// Add second item
p = myCommand.Parameters("@ProductID");
p.Value = 25;
p = myCommand.Parameters("@Quantity");
p.Value = 2;
myCommand.ExecuteNonQuery();
// Add third item
p = myCommand.Parameters("@ProductID");
p.Value = 35;
p = myCommand.Parameters("@Quantity");
p.Value = 3;
myCommand.ExcuteNonQuery();
myTrans.Commit();
MessageBox .Show ("Order written to database", "Transacción");
}
catch(Exception exc)
{
myTrans.Rollback();
MessageBox .Show(exc.Message .ToString (),"Transacción");
}
finally
{
68

myConnection.Close() ;
}
}
4. Bases de datos orientadas a objetos

5. Business Intelligence

5.1 Introducción
Algo peor que no tener información disponible es tener mucha información y no saber qué
hacer con ella. La Inteligencia de Negocios o Business Intelligence (BI) es la solución a ese
problema, pues por medio de dicha información puede generar escenarios, pronósticos y
reportes que apoyen a la toma de decisiones, lo que se traduce en una ventaja competitiva. La
clave para BI es la información y uno de sus mayores beneficios es la posibilidad de utilizarla
en la toma de decisiones. En la actualidad hay una gran variedad de software de BI con
aplicaciones similares que pueden ser utilizados en las diferentes áreas de la empresa, tales
como, ventas, marketing, finanzas, etc. Son muchas las empresas que se han beneficiado por
la implementación de una sistema de BI, además se pronostica que con el tiempo se
convertirá en una necesidad de toda empresa.

En este nuevo mundo, la información reina afirma Geoffrey A. Moore, Director de Chasm
Group. Vivimos en una época en que la información es la clave para obtener una ventaja
competitiva en el mundo de los negocios. Para mantenerse competitiva una empresa, los
gerentes y tomadores de decisiones requieren de un acceso rápido y fácil a información útil y
valiosa de la empresa. Una forma de solucionar este problema es por medio del uso de
Business Intelligence o Inteligencia de Negocios.

5.2. Datawarehouse
La idea de la integración de múltiples bases de datos ha dado lugar a la tecnología de almacenes
de datos ( data‐warehousing ). Este término, tan popular actualmente, hace referencia a la
tendencia actual en las empresas e instituciones de coleccionar datos de las bases de datos
69

transaccionales y otras fuentes diversas para hacerlos accesibles para el análisis y la toma de
decisiones.

Fig. 5.1 Esquema para la creación de un datawarehouse
Los almacenes de datos se utilizan para poder agregar y cruzar eficientemente la información de
maneras sofisticadas. Por ello, los datos se modelan con una estructura de base de datos
multidimensional, donde cada dimensión corresponde a un atributo o conjunto de atributos en el
esquema en torno a unos “hechos” que almacenan el valor de alguna medida agregada, como por
ejemplo la cantidad vendida de un producto en un día concreto en una tienda. Esta visión
multidimensional hace a los almacenes de datos adecuados para el procesamiento analítico en
línea ( on‐line analytical processing OLAP )
La mayoría de sistemas comerciales de gestión de bases de datos incluyen herramientas de
“informes avanzados”, “inteligencia de negocios”, Sistemas de información ejecutivos ( EIS ) y
otras, que pese a sus nombres variados intentan realizar un procesamiento analítico de la
información, mas que el procesamiento transaccional habitual realizado por las aplicaciones del
día a día de la organización. Por lo tanto, cada día es mas necesario distinguir dos usos diferentes
del sistema de información: el procesamiento transaccional y el procesamiento analítico.
Con las siglas OLTP y OLAP se denominan dos tipos de procesamiento bien diferentes:
• OLTP ( On‐Line Transactional Processing ). El procesamiento transaccional en tiempo real
constituye el trabajo primario en un sistema de información. Este trabajo consiste en
70

realizar transacciones, es decir, actualizaciones y consultas a la base de datos con un
objetivo operacional: hacer funcionar las aplicaciones de la organización, proporcionar
información sobre el estado del sistema de información y permitir actualizarlo conforme
va variando la realidad del contexto de la organización. Es el trabajo diario y para el que
inicialmente se ha diseñado la base de datos.
• OLAP ( On‐Line Analytical Processing ). El procesamiento analítico en tiempo real engloba
un conjunto de operaciones, exclusivamente de consulta, en las que se requiere agregar y
cruzar gran cantidad de información. El objetivo de estas consultas es realizar informes y
resúmenes , generalmente para el apoyo en la toma de decisiones. Ese tipo de consultas
suelen emanarse de los departamentos de dirección, logística o prospectiva y requieren
muchos recursos.
Una característica de ambos procesamientos es que se pretende que sean “on‐line”, es decir que
sean relativamente “instantáneos” y se pueden realizar en cualquier momento ( en tiempo real ).
Esto parece evidente e imprescindible para el OLTP, pero no está tan claro que esto sea posible
para algunas consultas muy complejas realizadas por el OLAP.
La práctica general, hasta hace pocos años, y todavía existe en muchas organizaciones y empresas,
es que ambos tipos de procesamiento ( OLTP y OLAP ) se realizaran sobre la misma base de datos
transaccional. De hecho, una de las máximas de la tecnología de bases de datos era la eliminación
de redundancia, con lo que parecía lo mas lógico que ambos procesamientos trabajaran sobre una
única base de datos general.
Esta práctica plantea dos problemas fundamentales:
• Las consultas OLAP perturban el trabajo transaccional diario de los sistemas de
información originales al ser consultas complejas que agrupan muchas tablas y
agrupaciones, esto resiente a las transacciones normales ( OLPT ), haciéndolas mas lentas.
• La base de datos esta diseñada para el trabajo transaccional, no para el análisis de datos.
Ambos problemas implican que va a ser prácticamente imposible realizar un análisis complejo de
la información en tiempo real si ambos procesamientos se realizan sobre la misma base de datos.
Afortunadamente, debido a que los costos de almacenamiento masivo y conectividad se han
reducido drásticamente en los últimos años, parece razonable recoger ( copiar ) los datos en un
sistema unificado y diferenciado del sistema tradicional transaccional u operacional. Aunque esto
vaya contra la filosofía general de bases de datos, son muchas mas las ventajas que los
inconvenientes. Nacen los almacenes de datos.
A partir de ahora, por tanto, diferenciaremos claramente entre bases de datos transaccionales y
almacenes de datos.
Las diferencias mostradas en la tabla, distinguen claramente la manera de estructurar y diseñar
almacenes de datos respecto a la forma tradicional de hacerlo con bases de datos transaccionales.
71

Base de datos transaccional Almacén de datos
Propósito Operaciones diarias. Soporte a Recuperación de información,
las aplicaciones informes, análisis y minería de
datos
Tipo de datos Datos de funcionamiento de la Datos útiles para el análisis, la
organización sumarización, etc.
Características de los datos Datos de funcionamiento, Datos históricos, datos
cambiantes, internos, internos y externos, datos
incompletos descriptivos
Modelo de datos Datos normalizados Datos en estrella, en copo de
nieve, parcialmente
desnormalizados,
mutidimensionales
Número y tipo de usuarios Cientos/miles: aplicaciones, Decenas: directores,
operarios, administrador de la ejecutivos, analistas (
base de datos granjeros, mineros )
Acceso SQL. Lectura y escritura SQL y herramientas propias (
slice & dice, dril, roll, pivot )
Lectura

Aunque ambas fuentes de datos ( transaccional y almacén de datos ) están separadas, es
importante destacar que gran parte de los datos que se incorporan en un almacén de datos
provienen de la base de datos transaccional. Esto supone desarrollar una tecnología de volcado y
mantenimiento de datos desde la base de datos transaccional al almacén de datos. Además el
almacén de datos debe integrar datos externos, con lo que en realidad debe estar actualizándose
frecuentemente de diferentes fuentes. El almacén de datos pasa a ser un integrador o recopilador
de información de diferentes fuentes, como se observa en figura 5.1
La organización y el mantenimiento de esta información plantea cuestiones técnicas,
fundamentalmente sobre como diseñar el almacén de dato, cómo cargarlo inicialmente, como
mantenerlo y preservar su existencia. No obstante, son muchas más las ventajas de esta
separación que sus inconvenientes. Además esta separación facilita la incorporación de fuentes
externas, que, en otro caso, sería muy difícil de encajar en la base de datos transaccional.
La carga y mantenimiento de un almacén de datos es uno de los aspectos más delicados y que mas
esfuerzo requiere ( alrededor de la mitad del esfuerzo necesario para implementar un almacén de
datos ) y, de hecho, suele existir un sistema especializado para realizar estas tareas, denominado,
sistema ETL ( Extraction, Transformation, Load ) Dicho sistema no se compra en el supermercado
72

ni se descarga de internet, sino que es responsabilidad del equipo de desarrollo del almacén y se
realiza específicamente para cada almacén de datos.
El sistema ETL se encarga de realizar muchas tareas:
• Lectura de datos transaccionales: Se trata generalmente de obtener datos mediante
consultas SQL sobre la base de datos transaccional.
• Incorporación de datos externos: Generalmente aquí se deben de incorporar otro tipo de
herramientas como wrappers, para convertir texto, hojas de cálculo ó HTML en XML o en
tablas de base de datos que se puedan integrar al almacén de datos.
• Creación de claves
• Integración de datos
• Obtención de agregaciones
• Limpieza y transformación de datos: evita datos redundantes, inconsistentes, estandarizar
medidas, formatos, fechas, tratar valores nulos, etc.
• Creación y mantenimiento de metadatos
• Identificación de cambios
• Planificación de la carga y mantenimiento
• Indización
• Pruebas de calidad
5.3. Business Intelligence
La Inteligencia de Negocios o Business Intelligence (BI) se puede definir como el proceso de
analizar los bienes o datos acumulados en la empresa y extraer una cierta inteligencia o
conocimiento de ellos. Dentro de la categoría de bienes se incluyen las bases de datos de clientes,
información de la cadena de suministro, ventas personales y cualquier actividad de marketing o
fuente de información relevante para la empresa.

BI apoya a los tomadores de decisiones con la información correcta, en el momento y lugar
correcto, lo que les permite tomar mejores decisiones de negocios. La información adecuada en el
lugar y momento adecuado incrementa efectividad de cualquier empresa.

La tecnología de BI no es nueva, ha estado presente de varias formas por lo menos en los últimos
20 años, comenzando por generadores de reportes y sistemas de información ejecutiva en los 80’s
Afirma Candice Goodwin . Entiéndase como sinónimos de tecnología de BI los términos
aplicaciones, soluciones o software de inteligencia de negocios.

Para comprender mejor el concepto se sita el siguiente ejemplo. Una franquicia de hoteles a nivel
nacional que utiliza aplicaciones de BI para llevar un registro estadístico del porcentaje promedio
73

de ocupación del hotel, así como los días promedio de estancia de cada huésped, considerando las
diferencias entre temporadas. Con esta información ellos pueden:
• Calcular la rentabilidad de cada hotel en cada temporada del año.
• Determinar quién es su segmento de mercado.
• Calcular la participación de mercado de la franquicia y de cada hotel.
• Identificar oportunidades y amenazas.

Estas son sólo algunas de las formas en que una empresa u organización se puede beneficiar por la
implementación de software de BI, hay una gran variedad de aplicaciones o software que brindan
a la empresa la habilidad de analizar de una forma rápida por qué pasan las cosas y enfocarse a
patrones y amenazas.

5.3.1. Datamarts
La duplicación en otro entorno de datos es un término que suele ser mal interpretado e
incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los
datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data
Warehouse, el trmino duplicación se refiere a la creación de Data Marts locales o departamentales
basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.
Según define Meta Group, "un Data Mart es una aplicación de Data Warehouse, construida
rápidamente para soportar una línea de negocio simple". Los Data Marts, tienen las mismas
características de integración, no volatilidad, orientación temática y no volatilidad que el Data
Warehouse. Representan una estrategia de "divide y vencerás" para ámbitos muy genéricos de un
Data Warehouse.
Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy
rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos
contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los
datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.
La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir
originada de una situación como la descrita a continuación.
74

Fig. 5.2 Esquema de un datamart
El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una
solución departamental, creando el primer Data Mart de la empresa.
Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a
crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de
Riesgos y Financiero, y estos hacen lo propio.
Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data
Marts crecen conforme el tiempo avanza. Cuando esta situación evoluciona, el esquema general
de integración entre los Data Marts pasa a ser, la del gráfico anterior.
En esta situación, es fácil observar cómo este esquema de integración de información de los Data
Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta
convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha
fallado no es la integración de Data Marts, sino su forma de integración.
75

Fig. 5.3 DataWarehouse corporativo
En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos
los Data Marts en un Data Warehouse centralizado.
En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y
depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de
conocimientos a nivel de toda la empresa.
Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en
el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts
implicados.
Según un estudio de IDC (International Data Corporation) tras analizar 541 empresas, la
distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus
opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:
En la gráfica, observamos, cómo en la actualidad, de las empresas consultadas, un 80% de ellas
cuentan con implantaciones de Data Warehouse o Data Marts.
76

Fig. 5.4 Proporción de uso actual y futuro
La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart.
No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se
ve como más adecuado para el futuro este enfoque "divide y vencerás", previéndose una inversión
de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.
Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan
renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en
un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una
reorganización del mismo.
5.3.2. OLAP

Como se mencionó en el tema de almacenes de datos OLAP es el procesamiento analítico en
tiempo real en el que se engloban un conjunto de operaciones, exclusivamente de consulta, en las
que se requiere agregar y cruzar gran cantidad de información. El objetivo de estas consultas es
realizar informes y resúmenes , generalmente para el apoyo en la toma de decisiones. Ese tipo de
consultas suelen emanarse de los departamentos de dirección, logística o prospectiva y requieren
muchos recursos.

Como parte de los servicios de explotación de una arquitectura de análisis de información, los
datos tienen que ser modelados multidimensionalmente para satisfacer los requerimientos de
desempeño de este tipo de consultas en línea.
77

Fig. 5.5 Modelo Multidimensional

Cuando el número de dimensiones no excede de tres podemos representar cada combinación de
niveles de agregación como un cubo. El cubo esta formado por casillas, con una casilla para cada
valor entre los posibles para cada dimensión a su correspondiente nivel de agregación. Sobre esta
“vista”, cada casilla representa un “hecho”.

Fig. 5.6 Ejemplo de un modelo multidimensional
78

Por ejemplo, en la figura se representa un cubo tridimensional donde las dimensiones producto,
mercado y tiempo se han agregado por artículo, ciudad y años. La representación de un hecho
corresponde por lo tanto a una casilla de dicho cubo. El valor de la casilla es la medida observada (
en este caso, importe de las ventas ).

Esta visualización hace que, incluso, cuando tengamos mas de tres dimensiones, se hable de un
“cubo” ( o mas propiamente de “hipercubo” ) como un conjunto de niveles de agregación para
todas las dimensiones.
Esta estructura permite ver de una manera intuitiva la sumarización / agregación ( varias casillas se
fusionan en casillas mas grandes ), la disgregación ( las casillas se separan en casillas con mayor
detalle ) y la navegación según las dimensiones de la estrella.

Operadores

El modelo multidimensional se basa en un conjunto de datamarts, que, generalmente, son
estructuras de datos en estrella jerárquica. Para completar el modelo multidimensional debemos
definir una serie de operadores sobre la estructura. Los operadores1 más importantes asociados a
este modelo son:

• Drill: Se trata de disgregar los datos ( mayor nivel de detalle o desglose, menos
sumarización ) siguiendo los caminos de uno o más dimensiones .
• Roll: Se trata de agregar los datos ( menor nivel de detalle o desglose, más sumarización o
consolidación ) siguiendo los caminos de una o más dimensiones.
• Slice & Dice: Selecciona y se proyectan datos.
• Pivot: Se reorientan las dimensiones.

Normalmente, estos operadores se llaman operadores OLAP, operadores de análisis de datos u
operadores de almacenes de datos. Estos operadores básicos permiten realizar las mismas
consultas de proyección, selección y agrupamiento que se pueden hacer con SQL. En muchos
casos, de hecho, se puede editar la consulta SQL correspondiente. El primer paso para poder
utilizar los operadores propios del modelo multidimensional es definir una consulta. En realidad,
los operadores dril, roll, slice&dice y pivot son modificadores o refinadores de consulta y sólo
pueden aplicarse sobre una consulta realizada previamente.

1
Hernández Orallo José ( 2007 ). Introducción a la minería de datos, Pearson Prentice Hall. Ejemplos
operadores pag 53‐55

79

5.3.3. Datamini ng
La min o la extracciión no triviaal de informaación implícita,

nería de datos puede deefinirse como
previam mente desconocida y potencialmente útil, a partir de los datoss. Para conseguirlo hace u uso
de differentes tecnologías quee resuelven problemas típicos de agrupamientto automáticco,
clasificcación, asociación de atributos y deteccción de patrones secuenciales. La mineería de datos es,
en prin ncipio, una faase dentro dee un proceso global denom minado descu ubrimiento de conocimien nto
en bases de datos ( Knowledge D Discovery in D
Databases o K KDD ), aunque finalmente haya adquiriido
el signiificado de toddo el proceso en lugar de la fase de extracción de co onocimiento.

Fig. 5.7 Esquema del K
KDD
80

Es habitual que los expertos en estadística confundan la minería de datos con un análisis
estadístico de éstos ( afirmaciones de este tipo pueden encontrarse en documentación de
empresas dedicadas al procesamiento estadístico que venden sus productos como herramientas
de minería de datos ). La diferencia fundamental entre ambas técnicas es muy clara: para
conseguir una afirmación como esta: “ Mas del 60% de las personas que adquieren queso fresco
compran también algún tipo de mermelada “, utilizando un paquete estadístico, es necesario
conocer a priori que existe una relación entre el queso fresco y la mermelada, y lo que realizamos
con nuestro entorno estadístico es una cuantificación de dicha relación.
En el caso de la minería de datos el proceso es muy distinto: la consulta que se realiza a la base de
datos ( Data Warehouse ) busca relaciones entre parejas de productos que son adquiridos por una
misma persona en una misma compra. De esa información, el sistema deduce, junto a otras
muchas, la afirmación anterior. Como podemos ver, en este proceso se realiza un acto de
descubrimiento de conocimiento real, puesto que no es necesario ni siquiera sospechar la
existencia de una relación entre estos dos productos para encontrarla.
Los sistemas de ayuda a la decisión ( DSS ) son herramientas sobre las que se apoyan los
responsables de una empresa, directores y gestores, en la toma de decisiones. Para ello utilizan:
• Un datawarehouse, en el que se almacena la información de interés para la empresa, y
• Herramientas de análisis multidimensional ( OLAP )
Las herramientas OLAP permiten navegar a través de los datos almacenados en el datawarehouse
y analizarlos dinámicamente desde una perspectiva multidimensional, es decir, considerando unas
variables en relación con otras y no de forma independiente entre sí y permitiendo enfocar el
análisis desde distintos puntos de vista.
Los DSS permiten al responsable de la toma de decisiones consultar y utilizar de manera rápida y
económica las enormes cantidades de datos operacionales y de mercado que se generan en una
empresa.
El análisis OLAP depende de un usuario que plantee una consulta o hipótesis. Es el usuario el que
lo dirige y, por tanto, el análisis queda limitado por las ideas preconcebidas que aquel pueda
tener.
La minería de datos constituye un paso más en el análisis de los datos de la empresa para apoyar
la toma de decisiones. No se trata de una técnica que sustituya los DSS ni el análisis OLAP, sino que
los complementa, permitiendo realizar un análisis más avanzado de los datos y extraer más
información de ellos.
Como ya se ha comentado anteriormente, utilizando minería de datos es el propio sistema el que
descubre nuevas hipótesis y relaciones. De este modo, el conocimiento obtenido con estas
técnicas no queda limitado por la visión que el usuario tiene del problema.
81

Las diferencias entre minería de datos y OLAP radican esencialmente en que el enfoque desde el
que se aborda el análisis con cada una de ellas es completamente distinto. Fundamentalmente:
• El análisis que realizan las herramientas OLAP es dirigido por el usuario, deductivo, parte
de una hipótesis o de una pregunta del usuario y se analizan los datos para resolver esa
consulta concreta. Por el contrario, la minería de datos permite razonar de forma
inductiva a partir de los datos para llegar a una hipótesis general que modele el problema.
• Además, las aplicaciones OLAP trabajan generalmente con datos agregados, para obtener
una visión global del negocio. Por el contrario, la minería de datos trabaja con datos
individuales, concretos, descubriendo las regularidades y patrones que presentan entre sí
y generalizando a partir de ellos.2
OLAP MD
Razonamiento Deductivo Inductivo
Trabaja con datos Agregados Concretos/individuales

Fig. 5.8 Importancia y complejidad de los sistemas de información
El objetivo de la minería de datos es producir nuevo conocimiento que pueda ser utilizado por el
usuario. Esto se realiza construyendo un modelo basado en los datos recopilados para este efecto.
El modelo es una descripción de los patrones y relaciones entre los datos que pueden usarse para
hacer predicciones, para entender mejor los datos o para explicar situaciones pasadas. Para ello
es necesario tomar una serie de decisiones antes de empezar el proceso:

2
Daedalus White Paper, (2002), Minería de datos Documento Básico Daedalus, Pag. 10. Diferencias entre
OLAP y MD. Ejemplos
82

• Determinar que tipo de tarea de minería es el mas apropiado. ( clasificación, regresión,
agrupamiento, reglas de asociación, análisis correlacional )
• Elegir el tipo de modelo ( árboles de decisión, redes neuronales )
• Elegir el algoritmo de minería que resuelva la tarea y obtenga el tipo de modelo que
estamos buscando ( por ejemplo para árboles de decisión existen los algoritmos CART,
C4.5 )
5.3.4. KPI’s

¿Qué es un Dashboard?

El nombre Dashboard se refiere al tablero de un automóvil, el cual ofrece al conductor
información permanente sobre el estado del vehículo. El mundo de los negocios toma la palabra
con un sentido similar pero en lugar de aplicarlo a los automóviles lo refiere a la empresa.

Así Dashboard es una página desarrollada en base a tecnología web mediante la cual se despliega
en tiempo real información de la empresa extraída de varias fuentes o bases de datos. Su
característica de tiempo real otorga a los usuarios un conocimiento completo sobre la marcha de
la empresa y permite hacer análisis instantáneos e inteligencia de negocios.

Métricas y KPI: Las Métricas y los KPIs son la base para construir un Dashboard de gran despliegue
visual, ya que son las herramientas más eficaces para alertar a los usuarios en cuanto a donde se
encuentran parados en relación a los objetivos. Por ello es importante contar con una clara
definición de estos elementos que constituyen la base del diseño del Dashboard.

Métrica: Cuando utilizamos el término métrica nos referimos a una medida numérica directa, que
representa un conjunto de datos de negocios en la relación a una o más dimensiones. Un ejemplo
sería: "las ventas brutas por semana." En este caso, la medida sería de pesos (ventas brutas) y la
dimensión sería el tiempo (semana) Para una medida dada, es posible que también se quiera ver
los valores a través de diferentes jerarquías dentro de una dimensión. Por ejemplo, al ver las
ventas brutas por día, semana o mes se mostrará la medida de pesos (ventas brutas) por
diferentes jerarquías (día, semana y mes) dentro de la dimensión temporal. Hacer la apertura más
detallada de una medida dentro de un determinado nivel jerárquico de una dimensión es
perseguir un objetivo de gran detalle para la métrica estudiada.

Mirando una medida a través de más de una dimensión, como las ventas brutas por el territorio y
el tiempo se denomina análisis multidimensional. La mayoría de los Dashboards sólo hace análisis
83

multi dimensionales en una forma limitada dependiendo de la herramientas BI (Business
Intelligence) que utilice para ello. Esto es importante de tener en cuenta, porque si en su proceso
de definición de la información que quiere ingresar al Dashboard descubre una necesidad
multidimensional importante será necesario entonces que estudie la posibilidad de complementar
sus tableros con algún tipo de herramienta de análisis multidimensional.

Indicadores clave de rendimiento (KPI): Un KPI es simplemente un indicador que está vinculado a
un objetivo. En la mayoría de los casos, un KPI el estado del un indicador, es decir si está por
encima o por debajo de una meta pre determinada. Los KPI's generalmente se muestran como una
tasa o porcentaje y están diseñados para permitir que un usuario de negocios pueda saber
instantáneamente si están dentro o fuera de su plan sin que tenga que buscar información
adicional. Por ejemplo, podemos decidir que, a fin de lograr nuestro objetivo de ventas
trimestrales tenemos que vender 10000 dólares de dispositivos por semana. La métrica sería
“venta de dispositivos por semana”, la meta sería de $ 10000. Si se utiliza un porcentaje de
visualización para representar este KPI y se hubiera vendido 8000 dispositivos el día miércoles, el
usuario podría ver al instante que estarían en el 80% de su objetivo.

Tarjetas de puntajes, Dashboards e Informes: La diferencia entre una tarjeta de puntaje, el
Dashboard y el informe puede ser muy sutil. Cada una de estas herramientas puede combinar
elementos de las otras, pero a un nivel elevado todas apuntan a distintos objetivos y niveles
separados del proceso de toma de decisiones de la empresa.

Tarjetas de puntaje: A partir de la más alta, la mayoría de los espectros de los niveles estratégicos
de la toma de decisiones de la empresa utiliza tarjetas de puntaje. Se utilizan principalmente para
ayudar a alinear la ejecución operacional con la estrategia empresarial. El objetivo de una tarjeta
de puntaje es mantener el negocio focalizado en un plan estratégico común mediante el control
de la ejecución del mundo real y organizar los resultados de dicha ejecución para una estrategia
específica. Las tarjetas de puntaje son ideales para representar objetivos que se forman con
métricas de distinta magnitud y que por ello no se pueden sumar y obtener una medida común.
Un ejemplo de una tarjeta de puntaje KPI sería un indicador llamado "Crecimiento de Ventas
rentable", que combina varias métricas tales como: la captación de nuevos clientes (cantidad de
clientes), el volumen de ventas (dólares), y la rentabilidad bruta (porcentaje) en una puntuación
final. Como estas métricas no se pueden sumar se les asigna un puntaje según su cumplimiento
del objetivo y este puntaje se suma para otorgar una medida cuantitativa al KPI "Crecimiento de
Ventas rentable".

Paneles: El propósito de un tablero es proporcionar al usuario información de la empresa en un
formato que es a la vez intuitivo y perspicaz. Los paneles enfatizan datos operativos sobre todo en
forma de cifras y KPI. Los paneles permiten descomponer una meta estratégica general en
determinadas metas operacionales. Las metas operacionales aportan valor para el cumplimiento
de la meta estratégica general.

84

Informes: Probablemente la herramienta BI más vista en los negocios de hoy es el tradicional
informe. Los informes pueden ser muy simples y estáticos en su naturaleza, como una lista de
ventas por un determinado período de tiempo, o un informe mas avanzado con agrupación,
resúmenes, dinámica de exploración de datos o vinculación. Los informes son los más utilizados
cuando el usuario necesita ver datos en bruto en un formato fácil de leer. Cuando se combina con
tableros y tarjetas de puntaje, los informes ofrecen un medio ideal para permitir a los usuarios
analizar los datos concretos destacando su métrica y los indicadores clave de rendimiento.

Recolección de KPI y Requisitos de Métricas para un Dashboard: Proyectos BI tradicionales suelen
usar un enfoque de abajo hacia arriba en la determinación de necesidades, donde la atención se
centra en el dominio de los datos y las relaciones que existen dentro de esos datos. Al relacionar
las Métricas y los KPI para un proyecto de Dashboard es preferible tomar un enfoque de arriba
hacia abajo. Un enfoque de arriba hacia abajo comienza con las decisiones empresariales que
deben ser puestas en primer lugar y luego se desciende hacia los datos necesarios para apoyar
esas decisiones. Con el fin de adoptar un enfoque de arriba hacia abajo usted DEBE involucrar al
usuario actual quien utilizara estos paneles, ya que son los únicos que pueden determinar la
relevancia de los datos específicos de las empresas con respecto a sus procesos de toma de
decisiones.
BIBLIOGRAFÍA

Autor: Clare Churcher
Título: Beginning SQL Queries From Novice to Professional
Editorial: Apress
ISBN-13: 978-1-59059-943-3

Autor: Silberschatz−Korth−Sudarshan
Título: Database System Concepts, Fourth Edition

Autor: Tobias Thernstrom, Ann Weber, Mike Hotek
Título: Microsoft® SQL Server® 2008 Database Development Training kit

Autor: Rob Vieira, Published by Wiley Publishing
Título: Professional Microsoft® SQL Server® 2008 Programming
ISBN: 978‐0‐470‐25702‐9

Autor: Abraham Silberchatz, Henry F. Korth
Año: 2006
Título: Fundamentos de bases de datos
85

Ciudad: Madrid
País: España
Editorial: McGraw Hill/Iberoamericana

Autor: Adoración de Miguel Castaño, Mario Piattini
Año: 1999
Título: Fundamentos y modelos de bases de datos
Ciudad: Madrid
País: España
Editorial: RA-MA

Autor: Carlo Batini, Shamkant B Navathe, Stefano Ceri, Antonio Víctor Martín García, Diego
Romero Ibancos
Año: 2004
Título: Diseño conceptual de bases de datos
Ciudad: Massachussets / Madrid
País: USA / España
Editorial: Addison-Wesley / Díaz De Santos

Autor: Peter Rob, Carlos Coronel
Año: 2004
Título: Sistemas de bases de datos: diseño, implementación y administración
Ciudad: México, D.F.
País: México
Editorial: Cengage Learning Editores
Autor: Hernández Orallo José, Ramírez Quintana Ma. José, Ferri Ramírez César
Año: 2007
Título: Introducción a la minería de datos
Ciudad: Madrid
País: España
Editorial: Pearson Prentice Hall

Autor: Daedalus White Paper
Año: 2002
Título: Minería de datos
Ciudad: Madrid
País: España

86

Antologia PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Antologia PDF

Cargado por

Copyright:

Formatos disponibles

Bases de datos para aplicaciones

Para el ejemplo anterior PhoneList es una “tabla virtual“, que se puede utilizar como una de las

Operador Significado Ejemplo

Expresión Descripción de los datos Diagrama de datos

Todos los miembros senior

Nivel Sucia No Repetible Fantasma

Serializable NO NO NO

Repeatable read NO NO SI

Read commited NO SI SI

Read uncommited SI SI SI

CREATE [UNDO] TABLESPACE tablespace_name

DATAFILE Datafile_Options Storage_Options ;

Índice Tabla Tabla

y Ya que las operaciones en la misma transacción deben de completarse todas con éxito

y Para crear un objeto de transacción. Se crea sobre un objeto de conexión, llamando al

La min o la extracciión no triviaal de informaación implícita,

También podría gustarte