Manual Base de Datos II TIC Completo

UNIVERSIDAD TECNOLÓGICA DE LA HUASTECA
HIDALGUENSE
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
Manual de la asignatura del profesor:
BASE DE DATOS II
Elaborado por:
ISC LEODEGARIO REDONDO MARTÍNEZ
Revisado por Director de Carrera
M en C FELIPE DE JESÚS NÚÑEZ CARDENAS
AGOSTO 2005
ÍNDICE
FIRMAS DE AUTORIZACIÓN ...................................................................................................... 3

INTRODUCCIÓN........................................................................................................................... 4
UNIDAD TEMATICA 1. LENGUAJE DE CONSULTA ESTRUCTURADO ....................... 5
1.1. LA VENTAJA DEL SQL ......................................................................................................... 5
1.2. CONSULTA DE UNA SOLA TABLA .................................................................................... 9
1.3. CONSULTA DE TABLAS MULTIPLES .............................................................................. 25
1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O SUBCONSULTAS .......... 55
1.5. PROCEDIMIENTOS ALMACENADOS ............................................................................... 61
1.6. TRIGGERS ............................................................................................................................. 71
1.7. VISTAS ................................................................................................................................... 85
UNIDAD TEMATICA 2. INTEGRIDAD DE DATOS y MANEJO DE INDICES ............... 88
2.1. TIPOS DE INTEGRIDAD DE DATOS ................................................................................. 90
2.2. USANDO RESTRICCIONES (CONSTRAINTS)................................................................ 101
2.3. USANDO VALORES POR OMISIÓN Y REGLAS ............................................................ 102
2.4. INTRODUCCIÓN A INDICES ............................................................................................ 107
2.5. ARQUITECTURA y CREACIÓN DE INDICES ................................................................. 111
UNIDAD TEMATICA 3. TRANSACCIONES EN LA BASE DE DATOS ....................... 115
3.1. PROCESAMIENTO DE TRANSACCIONES ..................................................................... 116
3.2. CONCEPTOS DE TRANSACCIONES ............................................................................... 118
3.3. PROPIEDADES DE LAS TRANSACCIONES ................................................................... 118
3.4. PLANES Y RECUPERABILIDAD ...................................................................................... 121
3.5. SERIABILIDAD DE PLANES ............................................................................................. 122
3.6. TRANSACCIONES SQL ..................................................................................................... 125
UNIDAD TEMATICA 4. SEGURIDAD ........................................................................... 136
4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS .............................................. 136
4.2. TIPOS DE SEGURIDAD ..................................................................................................... 145
4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN / RENOVACION
DE PRIVILEGIOS. ............................................................................................................................. 154
4.4. SEGUIMIENTO DE AUDITORIA ...................................................................................... 159
UNIDAD TEMATICA 5. BASES DE DATOS DISTRIBUIDAS ...................................... 165
5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES ................................. 165
5.2. MODELO GENERAL DE UN SGBD .................................................................................. 171
5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y RECUPERACIÓN EN
BASES DE DATOS DISTRIBUIDAS. ............................................................................................... 177
UNIDAD TEMATICA 6. TECNOLOGÍAS DE ACCESO A DATOS .............................. 203
6.1. ARQUITECTURAS MULTICAPA y XML ......................................................................... 203
6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y ASP. ....................... 218
6.3. JDBC, PAGINAS DEL SERVIDOR JAVA. ........................................................................ 243
UNIDAD TEMATICA 7. PROYECTO FINAL ................................................................. 246
FIRMAS DE AUTORIZACIÓN
Elaboró Revisó
ISC LEODEGARIO REDONDO M en C FELIPE DE JESÚS NÚÑEZ

MARTÍNEZ CARDENAS
Directora de la Carrera
Vo. Bo. Autorizó
MAD. Marisol Flores Contreras Dra. Miriam Yta

Directora de Enlace Académico Rectora
INTRODUCCIÓN
Elevar la calidad académica de esta universidad se ha convertido en el objetivo

a corto plazo, es de reconocer el esfuerzo aquí vertido para proporcionar a los
estudiantes una formación de calidad, sin embargo, la participación global de
una institución educativa obliga a una actualización permanente
Dentro de este marco los materiales didácticos se convierten en instrumentos

indispensable para ayudar a elevar la calidad educativa en las instituciones.
Esta guía pretende proporcionar una visión de conjunto de la asignatura, así

como señalar los conceptos fundamentales tratados en cada uno de los temas
del programa. El objetivo principal que se persigue es el de ayudar al alumno a
estructurar y organizar la información recogida en el manual para facilitar así la
compresión de sus contenidos. Por tanto, el equipo docente recomienda a
todos los alumnos de la carrera de Administración y Evaluación de Proyectos
en que lean detenidamente la primera parte de esta Guía para tener una
orientación general de la asignatura y que la consulten cuando estudien cada
uno de los temas tratados en el texto, ya que en ella se proporcionarán las
orientaciones didácticas precisas para su estudio.
Creemos que esta Guía puede facilitar al alumno de la Universidad Tecnológica

de la Huasteca Hidalguense un material didáctico adicional que contribuya al
aprendizaje de los contenidos de la asignatura. Se indican igualmente en esta
Guía, otra serie de medios con los que cuenta el alumno para el estudio. Todos
ellos obedecen a un interés fundamental, reducir la distancia alumno-profesor.
El presente manual representa ser un instrumento de apoyo para que el

profesor lleve acabo una planeación por sesión y una revisión minuciosa de los
contenidos para cumplir con el saber y saber hacer de una manera
evidenciable, el curso se divide en 6 Unidades temáticas, las cuales incluyen
las actividades de aprendizaje y los criterios de evaluación de cada actividad, el
manual cuenta además con 2 anexos, a) Resumen de actividades de
aprendizaje, b) Resumen de sesiones.
UNIDAD TEMATICA 1. LENGUAJE DE CONSULTA ESTRUCTURADO
El lenguaje SQL es usado para comunicarse con una base de datos según el
ANSI (American National Standards Institute). Es el lenguaje clásico para
sistemas manejadores de bases de datos relaciónales. Las declaraciones SQL
son usadas para ejecutar tareas tales como: actualizar datos en una base de
datos o recuperarlos, algunos sistemas manejadores de bases de datos
relacionales que usan SQL son: Oracle, Sybase, Microsoft SQL Server,
Access, Ingres, etc. Aunque más sistemas usan SQL tienen sus propias
extensiones adicionales que usualmente son usadas sólo en sus propios
sistemas. Las instrucciones normales tales como: “seleccionar”. “Insertar”,
“actualizar”, “suprimir”, “crear”, y “borrar” pueden ser usadas para realizar casi
todo lo que necesite hacer con una base de datos.
1.1. LA VENTAJA DEL SQL

1.1.1. OBJETIVO DE APRENDIZAJE
Conocer los operadores del lenguaje SQL, para adquirir la habilidad de realizar
consultas simples y complejas a una base de datos, asi como conocer las
bases de SQL.
1.1.2. RECURSO TIEMPO DEL TEMA 1 hora
1.1.3. DESARROLLO
Las aplicaciones en red son cada día más numerosas y versátiles. En muchos
casos, el esquema básico de operación es una serie de scripts que rigen el
comportamiento de una base de datos.
Debido a la diversidad de lenguajes y de bases de datos existentes, la manera

de comunicar entre unos y otras sería realmente complicada a gestionar de no
ser por la existencia de estándares que nos permiten el realizar las operaciones
básicas de una forma universal.
Es de eso de lo que trata el Structured Query Language que no es mas que un

lenguaje estándar de comunicación con bases de datos. Hablamos por tanto de
un lenguaje normalizado que nos permite trabajar con cualquier tipo de
lenguaje (ASP o PHP) en combinación con cualquier tipo de base de datos (MS
Access, SQL Server, MySQL...).
El hecho de que sea estándar no quiere decir que sea idéntico para cada base
de datos. En efecto, determinadas bases de datos implementan funciones
específicas que no tienen necesariamente que funcionar en otras.
Aparte de esta universalidad, el SQL posee otras dos características muy

apreciadas. Por una parte, presenta una potencia y versatilidad notables que
contrasta, por otra, con su accesibilidad de aprendizaje.
LENGUAJE DE CONSULTA ESTRUCTURADO SQL
El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos

normalizado, utilizado por los diferentes motores de bases de datos para
realizar determinadas operaciones sobre los datos o sobre la estructura de los
mismos. Pero como sucede con cualquier sistema de normalización hay
excepciones para casi todo; de hecho, cada motor de bases de datos tiene sus
peculiaridades y lo hace diferente de otro motor, por lo tanto, el lenguaje SQL
normalizado (ANSI) no nos servirá para resolver todos los problemas, aunque
si se puede asegurar que cualquier sentencia escrita en ANSI será
interpretable por cualquier motor de datos.
TRANSACT-SQL
Transact-SQL (T-SQL) es el lenguaje de programación del SQL Sever, a través

de el podemos realizar muchas operaciones relacionadas con el SQL sin tener
que volver a pasar por código VB, esto simplificará vuestro código y ganará en
rapidez dado que el T-SQL se ejecuta dentro del SQL Server y es código
compilado, se compila la primera vez que se ejecuta el Stored PROCEDURE.
EL T-SQL se puede utilizar desde multitud de aplicaciones y desde diferentes

lenguajes de programación :
 Desde Visual Basic
 Desde Visual C++
 Desde Active Server Pages (ASP)
 ...
No se utiliza dentro de estos lenguajes sino en desde los llamados

Stored Procedures (SP)
Sistema administrador para bases de datos relacionales (RDBMS)
El RDBMS es responsable de:
 Mantener las relaciones entre la información y la Base de Datos.

 Asegurarse de que la información es almacenada correctamente, es
decir, que las reglas que definen las relaciones ente los datos no sean
violadas.
 Recuperar toda la información en un punto conocido en caso de que el
sistema falle.
PLATAFORMAS PARA SQL
Los componentes Cliente y Servidor de SQL Server corren en los Sistemas

Operativos mostrados en la siguiente tabla:
COMPONENTE COMPONENTE
PLATAFORMA
SERVER CLIENTE
Microsoft W in 95/98 Si Si
Microsoft W indows NT Si Si
Workstation 4.0 y posteriores
Microsoft W indows NT Server Si Si
4.0 y posteriores
Microsoft W indows NT Server Si Si
Enterprise Edition 4.0 y
posteriores
Windows 3.X No Si
MS-DOS No Si
Third party No Si (Unix,
apple
Macintosh)
Internet browsers No Si
1.1.3.1. TÉCNICA DIDÁCTICA Exposición del profesor.

1.1.3.2. MATERIAL DE APOYO
1.1.4. ACTIVIDADES DE APRENDIZAJE
1.1.4.1. ACTIVIDAD DE APRENDIZAJE 1
A1-T1 Cuestionario.
1.1.4.1.1. INSTRUCCIONES
Realizar un cuestionario de 5 preguntas del tema visto.
a) Valor actividad: 5 Puntos
b) Producto esperado: Contestar preguntas de manera escrita
c) Fecha inicio:
d) Fecha entrega:
e) Forma de entrega: Documento
f) Tipo de Actividad: Individual
1.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1

ACTIVIDAD DESARROLLO PONDERACIÓN
Formular preguntas y
responderlas, estas se deben
Cuestionario del tema 5 puntos
de transmitir hacia sus
compañeros
Total 5 Puntos
1.1.5. RESULTADO DE APRENDIZAJE

Que el alumno sepa de las ventajas que tiene el utilizar SQL en este caso
TRANSACT-SQL de SQL Server 2000.
1.1.6. BIBLIOGRAFÍA
Ayuda SQL Server 2000
1.1.7. DOCUMENTOS
Manual SQL Server 2000 Standard final
1.2. CONSULTA DE UNA SOLA TABLA

Crear la habilidad en los alumnos de poder aprovechar las ventajas de SQL,
haciendo consultas sencillas a una sola tabla.
1.2.2. RECURSO TIEMPO DEL TEMA 2 horas
1.2.3. DESARROLLO
TIPOS DE CAMPO
Como sabemos una base de datos esta compuesta de tablas donde

almacenamos registros catalogados en función de distintos campos
(características).
Un aspecto previo a considerar es la naturaleza de los valores que

introducimos en esos campos. Dado que una base de datos trabaja con todo
tipo de informaciones, es importante especificarle qué tipo de valor le estamos
introduciendo de manera a, por un lado, facilitar la búsqueda posteriormente y
por otro, optimizar los recursos de memoria.
Cada base de datos introduce tipos de valores de campo que no

necesariamente están presentes en otras. Sin embargo, existe un conjunto de
tipos que están representados en la totalidad de estas bases. Estos tipos
comunes son los siguientes:
Alfanuméricos Contienen cifras y letras. Presentan una longitud

limitada (255 caracteres)
Existen de varios tipos, principalmente, enteros (sin
Numéricos
decimales) y reales (con decimales).
Booleanos Poseen dos formas: Verdadero y falso (Sí o No)
Almacenan fechas facilitando posteriormente su

Fechas explotación. Almacenar fechas de esta forma posibilita
ordenar los registros por fechas o calcular los días entre
una fecha y otra...
Son campos alfanuméricos de longitud ilimitada.

Memos Presentan el inconveniente de no poder ser indexados
(veremos más adelante lo que esto quiere decir).
Son campos numéricos enteros que incrementan en una

unidad su valor para cada registro incorporado. Su
Autoincrementables
utilidad resulta más que evidente: Servir de identificador
ya que resultan exclusivos de un registro.
COMPONENTES DE SQL
El lenguaje SQL está compuesto por comandos, cláusulas, operadores y

funciones de agregado. Estos elementos se combinan en las instrucciones para
crear, actualizar y manipular las bases de datos.
Existen dos tipos de comandos SQL:

 los DLL que permiten crear y definir nuevas bases de datos, campos e
índices.
 los DML que permiten generar consultas para ordenar, filtrar y extraer
datos de la base de datos.
COMANDOS DDL
Comando Descripción
CREATE Utilizado para crear nuevas tablas, campos e índices
DROP Empleado para eliminar tablas e índices
Utilizado para modificar las tablas agregando campos o
ALTER
cambiando la definición de los campos.
COMANDOS DML
Comando Descripción
Utilizado para consultar registros de la base de datos que
SELECT
satisfagan un criterio determinado
Utilizado para cargar lotes de datos en la base de datos en una
INSERT
única operación.
Utilizado para modificar los valores de los campos y registros
UPDATE
especificados
Utilizado para eliminar registros de una tabla de una base de
DELETE
datos
CLAUSULAS
Las cláusulas son condiciones de modificación utilizadas para definir los datos
que desea seleccionar o manipular.
Cláusula Descripción
Utilizada para especificar la tabla de la cual se van a seleccionar
FROM
los registros
Utilizada para especificar las condiciones que deben reunir los
WHERE
registros que se van a seleccionar
Utilizada para separar los registros seleccionados en grupos
GROUP BY
específicos
Utilizada para expresar la condición que debe satisfacer cada
HAVING
grupo
Utilizada para ordenar los registros seleccionados de acuerdo
ORDER BY
con un orden específico
OPERADORES LÓGICOS
Operador Uso
Es el "y" lógico. Evalua dos condiciones y devuelve un valor de
AND
verdad sólo si ambas son ciertas.
Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de
OR
verdar si alguna de las dos es cierta.
NOT Negación lógica. Devuelve el valor contrario de la expresión.
OPERADORES DE COMPARACIÓN
Operador Uso
< Menor que
> Mayor que
<> Distinto de
<= Menor ó Igual que
>= Mayor ó Igual que
= Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparación de un modelo
Utilizado para especificar registros de una base de datos
IN
FUNCIONES DE AGREGADO
Las funciones de agregado se usan dentro de una cláusula SELECT en grupos

de registros para devolver un único.
Valor que se aplica a un grupo de registros.
Función Descripción
Utilizada para calcular el promedio de los valores de un campo
AVG
determinado
COUNT Utilizada para devolver el número de registros de la selección
Utilizada para devolver la suma de todos los valores de un
SUM
campo determinado
Utilizada para devolver el valor más alto de un campo
MAX
especificado
Utilizada para devolver el valor más bajo de un campo
MIN
especificado
ORDEN DE EJECUCIÓN DE LOS COMANDOS
Dada una sentencia SQL de selección que incluye todas las posibles
cláusulas, el orden de ejecución de las mismas es el siguiente:
1. Cláusula FROM
2. Cláusula WHERE
3. Cláusula GROUP BY
4. Cláusula HAVING
5. Cláusula SELECT
6. Cláusula ORDER BY
CONSULTAS DE SELECCIÓN
Bases de datos-SQL-Sentencias SQL-Consultas de Selección

Las consultas de selección se utilizan para indicar al motor de datos que
devuelva información de las bases de datos, esta información es devuelta en
forma de conjunto de registros que se pueden almacenar en un objeto
recordset. Este conjunto de registros puede ser modificable.
Consultas básicas
La sintaxis básica de una consulta de selección es la siguiente:
SELECT Campos FROM Tabla
En donde campos es la lista de campos que se deseen recuperar y tabla es

el origen de los mismos, por ejemplo:
SELECT Nombre, Teléfono FROM Clientes
Esta sentencia devuelve un conjunto de resultados con el campo nombre y

teléfono de la tabla clientes.
DEVOLVER LITERALES
En determinadas ocasiones nos puede interesar incluir una columna con un
texto fijo en una consulta de selección, por ejemplo, supongamos que
tenemos una tabla de empleados y deseamos recuperar las tarifas
semanales de los electricistas, podríamos realizar la siguiente consulta:
SELECT Empleados.Nombre, 'Tarifa semanal: ', Empleados.TarifaHora * 40

FROM Empleados WHERE Empleados.Cargo = 'Electricista'
ORDENAR LOS REGISTROS
Adicionalmente se puede especificar el orden en que se desean recuperar los

registros de las tablas mediante la cláusula ORDER y Lista de Campos. En
donde Lista de campos representa los campos a ordenar. Ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER y Nombre
Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la

tabla Clientes ordenados por el campo Nombre.
Se pueden ordenar los registros por mas de un campo, como por ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes

ORDER y CodigoPostal, Nombre
Incluso se puede especificar el orden de los registros: ascendente mediante la

cláusula (ASC - se toma este valor por defecto) ó descendente (DESC)
SELECT CodigoPostal, Nombre, Telefono FROM Clientes

ORDER y CodigoPostal DESC , Nombre ASC
USO DE ÍNDICES DE LAS TABLAS

Si deseamos que la sentencia SQL utilice un índice para mostrar los resultados
se puede utilizar la palabra reservada INDEX de la siguiente forma:
SELECT ... FROM Tabla (INDEX=Indice) ...
Normalmente los motores de las bases de datos deciden que indice se debe
utilizar para la consulta, para ello utilizan criterios de rendimiento y sobre todo
los campos de búsqueda especificados en la cláusula WHERE. Si se desea
forzar a no utilizar ningún índice utilizaremos la siguiente sintaxis:
SELECT ... FROM Tabla (INDEX=0) ...
CONSULTAS CON PREDICADO
El predicado se incluye entre la cláusula y el primer nombre del campo a

recuperar, los posibles predicados son:
PREDICADO DESCRIPCIÓN
ALL Devuelve todos los campos de la tabla
TOP Devuelve un determinado número de registros de la tabla
Omite los registros cuyos campos seleccionados

DISTINCT
coincidan totalmente
Omite los registros duplicados basandose en la totalidad

DISTINCTROW
del registro y no sólo en los campos seleccionados.
ALL
Si no se incluye ninguno de los predicados se asume ALL. El Motor de base

de datos selecciona todos los registros que cumplen las condiciones de la
instrucción SQL y devuelve todos y cada uno de sus campos. No es
conveniente abusar de este predicado ya que obligamos al motor de la base de
datos a analizar la estructura de la tabla para averiguar los campos que
contiene, es mucho más rápido indicar el listado de campos deseados.
SELECT ALL FROM Empleados SELECT * FROM Empleados
TOP
Devuelve un cierto número de registros que entran entre al principio o al final

de un rango especificado por una cláusula ORDER y. Supongamos que
queremos recuperar los nombres de los 25 primeros estudiantes del curso
1994:
SELECT TOP 25 Nombre, Apellido FROM Estudiantes

ORDER y Nota DESC
Si no se incluye la cláusula ORDER y, la consulta devolverá un conjunto

arbitrario de 25 registros de la tabla de Estudiantes. El predicado TOP no elige
entre valores iguales. En el ejemplo anterior, si la nota media número 25 y la
26 son iguales, la consulta devolverá 26 registros. Se puede utilizar la palabra
reservada PERCENT para devolver un cierto porcentaje de registros que caen
al principio o al final de un rango especificado por la cláusula ORDER y.
Supongamos que en lugar de los 25 primeros estudiantes deseamos el 10 por
ciento del curso:
SELECT TOP 10 PERCENT Nombre, Apellido FROM Estudiantes

ORDER y Nota DESC
El valor que va a continuación de TOP debe ser un entero sin signo. TOP no
afecta a la posible actualización de la consulta.
DISTINCT
Omite los registros que contienen datos duplicados en los campos

seleccionados. Para que los valores de cada campo listado en la instrucción
SELECT se incluyan en la consulta deben ser únicos. Por ejemplo, varios
empleados listados en la tabla Empleados pueden tener el mismo apellido. Si
dos registros contienen López en el campo Apellido, la siguiente instrucción
SQL devuelve un único registro:
SELECT DISTINCT Apellido FROM Empleados
Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos

campos indicados en la cláusula SELECT posean un contenido diferente. El
resultado de una consulta que utiliza DISTINCT no es actualizable y no refleja
los cambios subsiguientes realizados por otros usuarios.
DISTINCTROW
Este predicado no es compatible con ANSI. Que yo sepa a día de hoy sólo
funciona con ACCESS.
Devuelve los registros diferentes de una tabla; a diferencia del predicado
anterior que sólo se fijaba en el contenido de los campos seleccionados, éste
lo hace en el contenido del registro completo independientemente de los
campos indicados en la cláusula SELECT.
SELECT DISTINCTROW Apellido FROM Empleados
Si la tabla empleados contiene dos registros: Antonio López y Marta López el

ejemplo del predicado DISTINCT devuelve un único registro con el valor López
en el campo Apellido ya que busca no duplicados en dicho campo. Este último
ejemplo devuelve dos registros con el valor López en el apellido ya que se
buscan no duplicados en el registro completo.
ALIAS
En determinadas circunstancias es necesario asignar un nombre a alguna

columna determinada de un conjunto devuelto, otras veces por simple capricho
o porque estamos recuperando datos de diferentes tablas y resultan tener un
campo con igual nombre. Para resolver todas ellas tenemos la palabra
reservada AS que se encarga de asignar el nombre que deseamos a la
columna deseada. Tomado como referencia el ejemplo anterior podemos hacer
que la columna devuelta por la consulta, en lugar de llamarse apellido (igual
que el campo devuelto) se llame Empleado. En este caso procederíamos de la
siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados
AS no es una palabra reservada de ANSI, existen diferentes sistemas de

asignar los alias en función del motor de bases de datos. En ORACLE para
asignar un alias a un campo hay que hacerlo de la siguiente forma:
SELECT Apellido AS "Empleado" FROM Empleados
También podemos asignar alias a las tablas dentro de la consulta de selección,

en esta caso hay que tener en cuenta que en todas las referencias que
deseemos hacer a dicha tabla se ha de utilizar el alias en lugar del nombre.
Esta técnica será de gran utilidad más adelante cuando se estudien las
vinculaciones entre tablas. Por ejemplo:
SELECT Apellido AS Empleado FROM Empleados AS Trabajadores
Para asignar alias a las tablas en ORACLE y SQL-SERVER los alias se

asignan escribiendo el nombre de la tabla, dejando un espacio en blanco y
escribiendo el Alias (se asignan dentro de la cláusula FROM).
SELECT Trabajadores.Apellido (1) AS Empleado

FROM Empleados Trabajadores
(1)
Esta nomenclatura [Tabla].[Campo] se debe utilizar cuando se está
recuperando un campo cuyo nombre se repite en varias de las tablas que se
utilizan en la sentencia. No obstante cuando en la sentencia se emplean varias
tablas es aconsejable utilizar esta nomenclatura para evitar el trabajo que
supone al motor de datos averiguar en que tabla está cada uno de los campos
indicados en la cláusua SELECT.
RECUPERAR INFORMACIÓN DE UNA BASE DE DATOS EXTERNA
Para concluir este capítulo se debe hacer referencia a la recuperación de

registros de bases de datos externas. Es ocasiones es necesario la
recuperación de información que se encuentra contenida en una tabla que no
se encuentra en la base de datos que ejecutará la consulta o que en ese
momento no se encuentra abierta, esta situación la podemos salvar con la
palabra reservada IN de la siguiente forma:
SELECT Apellido AS Empleado

FROM Empleados IN 'c: \databases\gestion.mdb'
En donde c: \databases\gestion.mdb es la base de datos que contiene la tabla

Empleados. Esta técnica es muy sencilla y común en bases de datos de tipo
ACCESS en otros sistemas como SQL-SERVER u ORACLE, la cosa es más
complicada la tener que existir relaciones de confianza entre los servidores o al
ser necesaria la vinculación entre las bases de datos. Este ejemplo recupera la
información de una base de datos de SQL-SERVER ubicada en otro servidor
(se da por supuesto que los servidores están lincados):
SELECT Apellido FROM Servidor1.BaseDatos1.dbo.Empleados
CONSULTAS DE ACCIÓN
Bases de datos-SQL-Sentencias SQL-Consultas de Acción
Las consultas de acción son aquellas que no devuelven ningún registro, son
las encargadas de acciones como añadir y borrar y modificar registros. Tanto
las sentencias de actualización como las de borrado desencaderán (según el
motor de datos) las actualizaciones en cascada, borrados en cascada,
restricciones y valores por defecto definidos para los diferentes campos o
tablas afectadas por la consulta.
DELETE
Crea una consulta de eliminación que elimina los registros de una o más de las
tablas listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta
consulta elimina los registros completos, no es posible eliminar el contenido de
algún campo en concreto. Su sintaxis es:
DELETE FROM Tabla WHERE criterio
Una vez que se han eliminado los registros utilizando una consulta de borrado,
no puede deshacer la operación. Si desea saber qué registros se eliminarán,
primero examine los resultados de una consulta de selección que utilice el
mismo criterio y después ejecute la consulta de borrado. Mantenga copias de
seguridad de sus datos en todo momento. Si elimina los registros equivocados
podrá recuperarlos desde las copias de seguridad.
DELETE FROM Empleados WHERE Cargo = 'Vendedor'
INSERT INTO
Agrega un registro en una tabla. Se la conoce como una consulta de datos

añadidos. Esta consulta puede ser de dos tipo: Insertar un único registro ó
Insertar en una tabla los registros contenidos en otra tabla.
Para insertar un único Registro:
En este caso la sintaxis es la siguiente:
INSERT INTO Tabla (campo1, campo2, ..., campoN)

VALUES (valor1, valor2, ..., valorN)
Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así

sucesivamente.
Para seleccionar registros e insertarlos en una tabla nueva
En este caso la sintaxis es la siguiente:
SELECT campo1, campo2, ..., campoN INTO nuevatabla
FROM tablaorigen [WHERE criterios]
Se pueden utilizar las consultas de creación de tabla para archivar registros,

hacer copias de seguridad de las tablas o hacer copias para exportar a otra
base de datos o utilizar en informes que muestren los datos de un periodo de
tiempo concreto. Por ejemplo, se podría crear un informe de Ventas mensuales
por región ejecutando la misma consulta de creación de tabla cada mes.
Para insertar Registros de otra Tabla:
En este caso la sintaxis es:
INSERT INTO Tabla [IN base_externa] (campo1, campo2,..., campoN)

SELECT TablaOrigen.campo1, TablaOrigen.campo2,...,TablaOrigen.campoN
FROM Tabla Origen
En este caso se seleccionarán los campos 1,2,..., n de la tabla origen y se

grabarán en los campos 1,2,.., n de la Tabla. La condición SELECT puede
incluir la cláusula WHERE para filtrar los registros a copiar. Si Tabla y Tabla
Origen poseen la misma estructura podemos simplificar la sintaxis a:
INSERT INTO Tabla SELECT Tabla Origen.* FROM Tabla Origen
De esta forma los campos de Tabla Origen se grabarán en Tabla, para realizar
esta operación es necesario que todos los campos de Tabla Origen estén
contenidos con igual nombre en Tabla. Con otras palabras que Tabla posea
todos los campos de Tabla Origen (igual nombre e igual tipo).
En este tipo de consulta hay que tener especial atención con los campos
contadores o autonuméricos puesto que al insertar un valor en un campo de
este tipo se escribe el valor que contenga su campo homólogo en la tabla
origen, no incrementándose como le corresponde.
Se puede utilizar la instrucción INSERT INTO para agregar un registro único a
una tabla, utilizando la sintaxis de la consulta de adición de registro único tal y
como se mostró anteriormente. En este caso, su código especifica el nombre y
el valor de cada campo del registro. Debe especificar cada uno de los campos
del registro al que se le va a asignar un valor así como el valor para dicho
campo. Cuando no se especifica dicho campo, se inserta el valor
predeterminado o NULL. Los registros se agregan al final de la tabla.
También se puede utilizar INSERT INTO para agregar un conjunto de registros
pertenecientes a otra tabla o consulta utilizando la cláusula SELECT... FROM
como se mostró anteriormente en la sintaxis de la consulta de adición de
múltiples registros. En este caso la cláusula SELECT especifica los campos
que se van a agregar en la tabla destino especificada.
La tabla destino u origen puede especificar una tabla o una consulta. Si la tabla
destino contiene una clave principal, hay que asegurarse que es única, y con
valores no nulos; si no es así, no se agregarán los registros. Si se agregan
registros a una tabla con un campo Contador, no se debe incluir el campo
Contador en la consulta. Se puede emplear la cláusula IN para agregar
registros a una tabla en otra base de datos.
Se pueden averiguar los registros que se agregarán en la consulta ejecutando
primero una consulta de selección que utilice el mismo criterio de selección y
ver el resultado. Una consulta de adición copia los registros de una o más
tablas en otra. Las tablas que contienen los registros que se van a agregar no
se verán afectadas por la consulta de adición. En lugar de agregar registros
existentes en otra tabla, se puede especificar los valores de cada campo en un
nuevo registro utilizando la cláusula VALUES. Si se omite la lista de campos,
la cláusula VALUES debe incluir un valor para cada campo de la tabla, de otra
forma fallará INSERT.
EJEMPLOS
INSERT INTO Clientes SELECT ClientesViejos.* FROM ClientesNuevos

SELECT Empleados.* INTO Programadores FROM Empleados
WHERE Categoria = 'Programador'
Esta consulta crea una tabla nueva llamada programadores con igual
estructura que la tabla empleado y copia aquellos registros cuyo campo
categoría se programador
INSERT INTO Empleados (Nombre, Apellido, Cargo)

VALUES ( 'Luis', 'Sánchez', 'Becario' )
INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores

WHERE Provincia = 'Madrid'
UPDATE
Crea una consulta de actualización que cambia los valores de los campos de
una tabla especificada basándose en un criterio específico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, CampoN=ValorN

WHERE Criterio
UPDATE es especialmente útil cuando se desea cambiar un gran número de

registros o cuando éstos se encuentran en múltiples tablas. Puede cambiar
varios campos a la vez. El ejemplo siguiente incrementa los valores Cantidad
pedidos en un 10 por ciento y los valores Transporte en un 3 por ciento para
aquellos que se hayan enviado al Reino Unido.:
UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03

WHERE PaisEnvío = 'ES'
UPDATE no genera ningún resultado. Para saber qué registros se van a

cambiar, hay que examinar primero el resultado de una consulta de selección
que utilice el mismo criterio y después ejecutar la consulta de actualización.
UPDATE Empleados SET Grado = 5

WHERE Grado = 2
UPDATE Productos SET Precio = Precio * 1.1
WHERE Proveedor = 8 AND Familia = 3
Si en una consulta de actualización suprimimos la cláusula WHERE todos los

registros de la tabla señalada serán actualizados.
UPDATE Empleados SET Salario = Salario * 1.1
A2-T2 Realizar Base de Datos
Traducir el siguiente esquema Entidad Relación a una base de datos en SQL
Server 2000 y colocarle el nombre de “ESQUINITA”.
ABARROTES “LA ESQUINITA”

b) Producto esperado: Base de datos.
c) Fecha inicio:
d) Fecha entrega:
e) Forma de entrega: Archivo
f) Tipo de Actividad: Equipo (3 gentes)

Traducir el esquema entidad
Realizar Base de Datos relacion a una base de datos 5 puntos
en SQL Server 2000
Total 5 Puntos

Aprender a crear bases de datos en SQL Server 2000.
SQL Server 7.0
1.2.7. DOCUMENTOS
1.3. CONSULTA DE TABLAS MULTIPLES

Que el alumno aprenda a manejar consultas un tanto mas complejas,
solucionando las necesidades mas comunes de una BD.
1.3.2. RECURSO TIEMPO DEL TEMA 3 horas.
1.3.3. DESARROLLO
CONSULTAS DE UNIÓN INTERNAS
Bases de datos-SQL-Sentencias SQL-Consultas de Unión Internas
CONSULTAS DE COMBINACIÓN ENTRE TABLAS
Las vinculaciones entre tablas se realizan mediante la cláusula INNER que

combina registros de dos tablas siempre que haya concordancia de valores en
un campo común. Su sintaxis es:
SELECT campos FROM tb1 INNER JOIN tb2 ON

tb1.campo1 comp tb2.campo2
En donde:
Son los nombres de las tablas desde las que se combinan los
tb1, tb2
registros.
Son los nombres de los campos que se combinan. Si no son

campo1, numéricos, los campos deben ser del mismo tipo de datos y
campo2 contener el mismo tipo de datos, pero no tienen que tener el
mismo nombre.
Es cualquier operador de comparación relacional: =, <,<>, <=,
comp
=>, ó >.
Se puede utilizar una operación INNER JOIN en cualquier cláusula FROM.

Esto crea una combinación por equivalencia, conocida también como unión
interna. Las combinaciones equivalentes son las más comunes; éstas
combinan los registros de dos tablas siempre que haya concordancia de
valores en un campo común a ambas tablas. Se puede utilizar INNER JOIN
con las tablas Departamentos y Empleados para seleccionar todos los
empleados de cada departamento. Por el contrario, para seleccionar todos los
departamentos (incluso si alguno de ellos no tiene ningún empleado asignado)
se emplea LEFT JOIN o todos los empleados (incluso si alguno no está
asignado a ningún departamento), en este caso RIGHT JOIN.
Si se intenta combinar campos que contengan datos Memo u Objeto OLE, se
produce un ERROR. Se pueden combinar dos campos numéricos
cualesquiera, incluso si son de diferente tipo de datos. Por ejemplo, puede
combinar un campo Numérico para el que la propiedad Size de su objeto Field
está establecida como Entero, y un campo Contador.
El ejemplo siguiente muestra cómo podría combinar las tablas Categorías y
Productos basándose en el campo IDCategoria:
SELECT NombreCategoria, NombreProducto

FROM Categorias INNER JOIN Productos ON
Categorias.IDCategoria = Productos.IDCategoria
En el ejemplo anterior, IDCategoria es el campo combinado, pero no está

incluido en la salida de la consulta ya que no está incluido en la instrucción
SELECT. Para incluir el campo combinado, incluir el nombre del campo en la
instrucción SELECT, en este caso, Categorias.IDCategoria.
También se pueden enlazar varias cláusulas ON en una instrucción JOIN,
utilizando la sintaxis siguiente:
SELECT campos FROM tabla1 INNER JOIN tabla2

ON (tb1.campo1 comp tb2.campo1 AND ON tb1.campo2 comp tb2.campo2)
OR ON (tb1.campo3 comp tb2.campo3)
También puede anidar instrucciones JOIN utilizando la siguiente sintaxis:
SELECT campos FROM tb1 INNER JOIN (tb2 INNER JOIN [( ]tb3
[INNER JOIN [( ]tablax [INNER JOIN ...)]
ON tb3.campo3 comp tbx.campox)]
ON tb2.campo2 comp tb3.campo3)
ON tb1.campo1 comp tb2.campo2
Un LEFT JOIN o un RIGHT JOIN puede anidarse dentro de un INNER JOIN,

pero un INNER JOIN no puede anidarse dentro de un LEFT JOIN o un RIGHT
JOIN.
Ejemplo:
SELECT DISTINCT SUM(PrecioUnitario * Cantidad) AS Sales,

(Nombre + ' ' + Apellido) AS Name
FROM Empleados INNER JOIN( Pedidos INNER JOIN DetallesPedidos ON
Pedidos.IdPedido = DetallesPedidos.IdPedido) ON
Empleados.IdEmpleado = Pedidos.IdEmpleado
GROUP y Nombre + ' ' + Apellido
(Crea dos combinaciones equivalentes: una entre las tablas Detalles de

pedidos y Pedidos, y la otra entre las tablas Pedidos y Empleados. Esto es
necesario ya que la tabla Empleados no contiene datos de ventas y la tabla
Detalles de pedidos no contiene datos de los empleados. La consulta produce
una lista de empleados y sus ventas totales.)
Si empleamos la cláusula INNER en la consulta se seleccionarán sólo aquellos

registros de la tabla de la que hayamos escrito a la izquierda de INNER JOIN
que contengan al menos un registro de la tabla que hayamos escrito a la
derecha. Para solucionar esto tenemos dos cláusulas que sustituyen a la
palabra clave INNER, estas cláusulas son LEFT y RIGHT. LEFT toma todos
los registros de la tabla de la izquierda aunque no tengan ningún registro en la
tabla de la izquierda. RIGHT realiza la misma operación pero al contrario, toma
todos los registros de la tabla de la derecha aunque no tenga ningún registro
en la tabla de la izquierda.
La sintaxis expuesta anteriormente pertenece a ACCESS, en donde todas las
sentencias con la sintaxis funcionan correctamente. Los manuales de SQL-
SERVER dicen que esta sintaxis es incorrecta y que hay que añadir la palabra
reservada OUTER: LEFT OUTER JOIN y RIGHT OUTER JOIN. En la práctica
funciona correctamente de una u otra forma.
No obstante, los INNER JOIN ORACLE no es capaz de interpretarlos, pero
existe una sintaxis en formato ANSI para los INNER JOIN que funcionan en
todos los sistemas. Tomando como referencia la siguiente sentencia:
SELECT Facturas.*, Albaranes.*

FROM Facturas INNER JOINAlbaranes ON
Facturas.IdAlbaran = Albaranes.IdAlbaran
WHERE Facturas.IdCliente = 325
La transformación de esta sentencia a formato ANSI sería la siguiente:
SELECT Facturas.*, Albaranes.* FROM Facturas, Albaranes

WHERE Facturas.IdAlbaran = Albaranes.IdAlbaran
AND Facturas.IdCliente = 325
Como se puede observar los cambios realizados han sido los siguientes:
1. Todas las tablas que intervienen en la consulta se especifican en la

cláusula FROM.
2. Las condiciones que vinculan a las tablas se especifican en la cláusula
WHERE y se vinculan mediante el operador lógico AND.
Referente a los OUTER JOIN, no funcionan en ORACLE y además conozco

una sintaxis que funcione en los tres sistemas. La sintaxis en ORACLE es igual
a la sentencia anterior pero añadiendo los caracteres (+) detrás del nombre de
la tabla en la que deseamos aceptar valores nulos, esto equivale a un LEFT
JOIN:

FROM Facturas, Albaranes
WHERE Facturas.IdAlbaran = Albaranes.IdAlbaran (+)
Y esto a un RIGHT JOIN:

FROM Facturas, Albaranes
WHERE Facturas.IdAlbaran (+) = Albaranes.IdAlbaran
En SQL-SERVER se puede utilizar una sintaxis parecida, en este caso no se

utiliza los caracteres (+) sino los caracteres =* para el LEFT JOIN y *= para el
RIGHT JOIN.
CONSULTAS DE AUTOCOMBINACIÓN
La autocombinación se utiliza para unir una tabla consigo misma, comparando

valores de dos columnas con el mismo tipo de datos. La sintaxis en la
siguiente:
SELECT alias1.columna, alias2.columna, ...

FROM tabla1 AS alias1, tabla2 AS alias2
WHERE alias1.columna = alias2.columna
AND otras condiciones
Por ejemplo, para visualizar el número, nombre y puesto de cada empleado,

junto con el número, nombre y puesto del supervisor de cada uno de ellos se
utilizaría la siguiente sentencia:
SELECT t.num_emp, t.nombre, t.puesto, t.num_sup,s.nombre, s.puesto
FROM empleados AS t, empleados AS s
WHERE t.num_sup = s.num_emp
CONSULTAS DE COMBINACIONES NO COMUNES
La mayoría de las combinaciones están basadas en la igualdad de valores de

las columnas que son el criterio de la combinación. Las no comunes se basan
en otros operadores de combinación, tales como NOT, BETWEEN, <>, etc.
Por ejemplo, para listar el grado salarial, nombre, salario y puesto de cada
empleado ordenando el resultado por grado y salario habría que ejecutar la
siguiente sentencia:
SELECT grados.grado,empleados.nombre, empleados.salario, empleados.puesto
FROM empleados, grados
WHERE empleados.salario BETWEEN grados.salarioinferior
AND grados.salariosuperior
ORDER y grados.grado, empleados.salario
Para listar el salario medio dentro de cada grado salarial habría que lanzar esta
otra sentencia:
SELECT grados.grado, AVG(empleados.salario)

FROM empleados, grados
WHERE empleados.salario BETWEEN grados.salarioinferior
AND grados.salariosuperior
GROUP y grados.grado
CROSS JOIN (SQL-SERVER)
Se utiliza en SQL-SERVER para realizar consultas de unión. Supongamos que

tenemos una tabla con todos los autores y otra con todos los libros. Si
deseáramos obtener un listado combinar ambas tablas de tal forma que cada
autor apareciera junto a cada título, utilizaríamos la siguiente sintaxis:
SELECT Autores.Nombre, Libros.Titulo

FROM Autores CROSS JOIN Libros
SELF JOIN
SELF JOIN es una técnica empleada para conseguir el producto cartesiano de

una tabla consigo misma. Su utilización no es muy frecuente, pero pongamos
algún ejemplo de su utilización.
Supongamos la siguiente tabla (El campo autor es numérico, aunque para
ilustrar el ejemplo utilice el nombre):
Autores
Código (Código del libro) Autor (Nombre del Autor)
B0012 1. Francisco López
B0012 2. Javier Alonso
B0012 3. Marta Rebolledo
C0014 1. Francisco López
C0014 2. Javier Alonso
D0120 2. Javier Alonso
D0120 3. Marta Rebolledo
Queremos obtener, para cada libro, parejas de autores:
SELECT A.Codigo, A.Autor, B.Autor

FROM Autores A, Autores B
WHERE A.Codigo = B.Codigo
El resultado es el siguiente:
Código Autor Autor
B0012 1. Francisco López 1. Francisco López
B0012 1. Francisco López 2. Javier Alonso
B0012 1. Francisco López 3. Marta Rebolledo
B0012 2. Javier Alonso 2. Javier Alonso
B0012 2. Javier Alonso 1. Francisco López
B0012 2. Javier Alonso 3. Marta Rebolledo
B0012 3. Marta Rebolledo 3. Marta Rebolledo
B0012 3. Marta Rebolledo 2. Javier Alonso
B0012 3. Marta Rebolledo 1. Francisco López
C0014 1. Francisco López 1. Francisco López
C0014 1. Francisco López 2. Javier Alonso
C0014 2. Javier Alonso 2. Javier Alonso
C0014 2. Javier Alonso 1. Francisco López
D0120 2. Javier Alonso 2. Javier Alonso
D0120 2. Javier Alonso 3. Marta Rebolledo
D0120 3. Marta Rebolledo 3. Marta Rebolledo
D0120 3. Marta Rebolledo 2. Javier Alonso
Como podemos observar, las parejas de autores se repiten en cada uno de los
libros, podemos omitir estas repeticiones de la siguiente forma
SELECT A.Codigo, A.Autor, B.Autor

FROM Autores A, Autores B
WHERE A.Codigo = B.Codigo AND A.Autor < B.Autor
El resultado ahora es el siguiente:
Código Autor Autor
B0012 1. Francisco López 2. Javier Alonso
B0012 1. Francisco López 3. Marta Rebolledo
C0014 1. Francisco López 2. Javier Alonso
D0120 2. Javier Alonso 3. Marta Rebolledo
Ahora tenemos un conjunto de resultados en formato Autor - CoAutor.

Si en la tabla de empleados quisiéramos extraer todas las posibles parejas que
podemos realizar, utilizaríamos la siguiente sentencia:
SELECT Hombres.Nombre, Mujeres.Nombre

FROM Empleados Hombre, Empleados Mujeres
WHERE Hombre.Sexo = 'Hombre' AND
Mujeres.Sexo = 'Mujer' AND Hombres.Id <>Mujeres.Id
Para concluir supongamos la tabla siguiente:
Empleados
Id Nombre SuJefe
1 Marcos 6
2 Lucas 1
3 Ana 2
4 Eva 1
5 Juan 6
6 Antonio
Queremos obtener un conjunto de resultados con el nombre del empleado y el

nombre de su jefe:
SELECT Emple.Nombre, Jefes.Nombre
FROM Empleados Emple, Empleados Jefe
WHERE Emple.SuJefe = Jefes.Id
FULL JOIN
Este tipo de operador se utiliza para devolver todas las filas de una
combinación tengan o no correspondencia. Es el equivalente a la utilización de
LEFT JOIN y RIGHT JOIN a la misma vez. Mediante este operador se
obtendrán por un lado las filas que tengan correspondencia en ambas tablas y
también aquellas que no tengan correspondencia sean de la tabla que sean.
Si desearamos obtener un listado que incluyera todos los autores con sus
libros correspondientes, pero además todos los autores que no han escrito
ningún libro y todos aquellos libros sin autor (devemos suponer que no existe
un autor llamado anónimo):
SELECT Autores.*, Libros.* FROM Autores FULL Libros

ON Autores.IdAutor = Libros.IdAutor
CONSULTAS DE UNIÓN EXTERNAS
Bases de datos-SQL-Sentencias SQL-Consultas de Unión Externas
Se utiliza la operación UNION para crear una consulta de unión, combinando

los resultados de dos o más consultas o tablas independientes.
Su sintaxis es:
[TABLE] consulta1 UNION [ALL] [TABLE]

consulta2 [UNION [ALL] [TABLE] consultan [ ... ]]
En donde:
consulta Son instrucciones SELECT, el nombre de una

1,consulta 2, consulta almacenada o el nombre de una tabla
consulta n almacenada precedido por la palabra clave TABLE.
Puede combinar los resultados de dos o más consultas, tablas e instrucciones

SELECT, en cualquier orden, en una única operación UNION. El ejemplo
siguiente combina una tabla existente llamada Nuevas Cuentas y una
instrucción SELECT:
TABLE NuevasCuentas UNION ALL SELECT *

FROM Clientes WHERE CantidadPedidos > 1000
Si no se indica lo contrario, no se devuelven registros duplicados cuando se

utiliza la operación UNION, no obstante puede incluir el predicado ALL para
asegurar que se devuelven todos los registros. Esto hace que la consulta se
ejecute más rápidamente. Todas las consultas en una operación UNION deben
pedir el mismo número de campos, no obstante los campos no tienen porqué
tener el mismo tamaño o el mismo tipo de datos.
Se puede utilizar una cláusula GROUP y y/o HAVING en cada argumento
consulta para agrupar los datos devueltos. Puede utilizar una cláusula ORDER
y al final del último argumento consulta para visualizar los datos devueltos en
un orden específico.
SELECT NombreCompania, Ciudad

FROM Proveedores
WHERE Pais = 'Brasil' UNION SELECT NombreCompania, Ciudad
FROM Clientes WHERE Pais = 'Brasil'
Recupera los nombres y las ciudades de todos proveedores y clientes de Brasil

FROM Proveedores
FROM Clientes WHERE Pais = 'Brasil' ORDER y Ciudad
Recupera los nombres ylas ciudades de todos proveedores yclientes radicados
en Brasil, ordenados por el nombre de la ciudad

FROM Proveedores
FROM Clientes WHERE Pais = 'Brasil' UNION SELECT Apellidos, Ciudad
FROM Empleados WHERE Region = 'América del Sur'
Recupera los nombres y las ciudades de todos los proveedores y clientes de

brasil y los apellidos y las ciudades de todos los empleados de América del Sur
TABLE Lista_Clientes
UNION TABLE ListaProveedores
Recupera los nombres y códigos de todos los proveedores y clientes
REFERENCIAS CRUZADAS
Bases de datos-SQL-Sentencias SQL-Referencias Cruzadas
ACCESS
Una consulta de referencias cruzadas es aquella que nos permite visualizar los
datos en filas y en columnas, estilo tabla, por ejemplo:
Producto / Año 1996 1997
Pantalones 1.250 3.000
Camisas 8.560 1.253
Zapatos 4.369 2.563
Si tenemos una tabla de productos y otra tabla de pedidos, podemos visualizar

en total de productos pedidos por año para un artículo determinado, tal y como
se visualiza en la tabla anterior. La sintaxis para este tipo de consulta es la
siguiente:
TRANSFORM función agregada instrucción SELECT PIVOT campo PIVOT

[IN (valor1[, valor2[, ...]])]
En donde:
Función Es una función SQL agregada que opera sobre los datos
agregada seleccionados.
instrucción
Es una instrucción SELECT.
SELECT
Es el campo o expresión que desea utilizar para crear

campo PIVOT las cabeceras de la columna en el resultado de la
consulta.
Son valores fijos utilizados para crear las cabeceras de

valor1, valor2
la columna.
Para resumir datos utilizando una consulta de referencia cruzada, se

seleccionan los valores de los campos o expresiones especificadas como
cabeceras de columnas de tal forma que pueden verse los datos en un formato
más compacto que con una consulta de selección.
TRANSFORM es opcional pero si se incluye es la primera instrucción de una
cadena SQL. Precede a la instrucción SELECT que especifica los campos
utilizados como encabezados de fila y una cláusula GROUP y que especifica
el agrupamiento de las filas. Opcionalmente puede incluir otras cláusulas como
por ejemplo WHERE, que especifica una selección adicional o un criterio de
ordenación.
Los valores devueltos en campo PIVOT se utilizan como encabezados de
columna en el resultado de la consulta. Por ejemplo, al utilizar las cifras de
ventas en el mes de la venta como PIVOT en una consulta de referencia
cruzada se crearían 12 columnas. Puede restringir el campo PIVOT para crear
encabezados a partir de los valores fijos (valor1, valor2) listados en la cláusula
opcional IN.
También puede incluir valores fijos, para los que no existen datos, para crear
columnas adicionales.
Ejemplos
TRANSFORM SUM(Cantidad) AS Ventas

SELECT Producto, Cantidad
FROM Pedidos
WHERE Fecha BETWEEN #01-01-1998# AND #12-31-1998#
GROUP y Producto
ORDER y Producto
PIVOT DatePart("m", Fecha)
Crea una consulta de tabla de referencias cruzadas que muestra las ventas de
productos por mes para un año específico. Los meses aparecen de izquierda a
derecha como columnas y los nombres de los productos aparecen de arriba
hacia abajo como filas.
TRANSFORM SUM(Cantidad) AS Ventas

SELECT Compania
FROM Pedidos
WHERE Fecha BETWEEN #01-01-1998# AND #12-31-1998#
GROUP y Compania
ORDER y Compania
PIVOT "Trimestre " & DatePart("q", Fecha)
IN ('Trimestre1', 'Trimestre2', 'Trimestre 3', 'Trimestre 4')
Crea una consulta de tabla de referencias cruzadas que muestra las ventas de
productos por trimestre de cada proveedor en el año indicado. Los trimestres
aparecen de izquierda a derecha como columnas y los nombres de los
proveedores aparecen de arriba hacia abajo como filas.
Un caso práctico:
Se trata de resolver el siguiente problema: tenemos una tabla de productos con
dos campos, el código y el nombre del producto, tenemos otra tabla de pedidos
en la que anotamos el código del producto, la fecha del pedido y la cantidad
pedida. Deseamos consultar los totales de producto por año, calculando la
media anual de ventas.
Estructura y datos de las tablas:
ARTICULOS PEDIDOS
ID Nombre ID Fecha Cantidad
1 Zapatos 1 11/11/1996 250
2 Pantalones 2 11/11/1996 125
3 Blusas 3 11/11/1996 520
1 12/10/1996 50
2 04/10/1996 250
3 05/08/1996 100
1 01/01/1997 40
2 02/08/1997 60
3 05/10/1997 70
1 12/12/1997 8
2 15/12/1997 520
3 17/10/1997 1.250
Para resolver la consulta planteamos la siguiente consulta:
TRANSFORM SUM(Pedidos.Cantidad) AS Resultado

SELECT Nombre AS Producto, Pedidos.Id AS Código,
SUM(Pedidos.Cantidad) AS TOTAL, AVG(Pedidos.Cantidad) AS Media
FROM Pedidos, Artículos
WHERE Pedidos.Id = Artículos.Id
GROUP y Pedidos.Id, Artículos.Nombre
PIVOT year(Fecha)
Y Obtenemos el siguiente resultado:
Producto Código Total Media 1996 1997
Zapatos 1 348 87 300 48
Pantalones 2 955 238,75 375 580
Blusas 3 1940 485 620 1320
Comentarios a la consulta:
La cláusula TRANSFORM indica el valor que deseamos visualizar en las

columnas que realmente pertenecen a la consulta, en este caso 1996 y 1997,
puesto que las demás columnas son opcionales. SELECT especifica el nombre
de las columnas opcionales que deseamos visualizar, en este caso Producto,
Código, Total y Media, indicando el nombre del campo que deseamos mostrar
en cada columna o el valor de la misma. Si incluimos una función de cálculo el
resultado se hará basándose en los datos de la fila actual y no al total de los
datos.
FROM especifica el origen de los datos. La primera tabla que debe figurar es
aquella de donde deseamos extraer los datos, esta tabla debe contener al
menos tres campos, uno para los títulos de la fila, otros para los títulos de la
columna y otro para calcular el valor de las celdas.
En este caso en concreto se deseaba visualizar el nombre del producto, como
en la tabla de pedidos sólo figuraba el código del mismo se añadió una nueva
columna en la cláusula SELECT llamada Producto que se corresponda con el
campo Nombre de la tabla de artículos. Para vincular el código del artículo de
la tabla de pedidos con el nombre del mismo de la tabla artículos se insertó la
cláusula INNER JOIN.
La cláusula GROUP y especifica el agrupamiento de los registros,
contrariamente a los manuales de instrucción esta cláusula no es opcional ya
que debe figurar siempre y debemos agrupar los registros por el campo del
cual extraemos la información. En este caso existen dos campos de los que
extraemos la información: pedidos.cantidad y artículos.nombre, por ello
agrupamos por los campos.
Para finalizar la cláusula PIVOT indica el nombre de las columnas no
opcionales, en este caso 1996 y 1997 y como vemos a el dato que aparecerá
en las columnas, en este caso empleamos el año en que se produjo el pedido,
extrayéndolo del campo pedidos.fecha.
Otras posibilidades de fecha de la cláusula PIVOT son las siguientes:
1. Para agrupamiento por Trimestres:
PIVOT "Tri " & DatePart("q",[Fecha]);
2. Para agrupamiento por meses (sin tener en cuenta el año)
PIVOT Format([Fecha],"mmm") IN ("Ene", "Feb", "Mar", "Abr", "May", "Jun",

"Jul", "Ago", "Sep", "Oct", "Nov", "Dic");
3. Para agrupar por días
PIVOT Format([Fecha],"Short Date");
CRITERIOS DE SELECCIÓN
Bases de datos-SQL-Sentencias SQL-Criterios de Selección
En el apartado anterior se vio la forma de recuperar los registros de las tablas,

las formas empleadas devolvían todos los registros de la mencionada tabla. A
lo largo de este apartado se estudiarán las posibilidades de filtrar los registros
con el fin de recuperar solamente aquellos que cumplan unas condiciones
preestablecidas.
Antes de comenzar el desarrollo de este apartado hay que recalcar tres
detalles de vital importancia. El primero de ellos es que cada vez que se desee
establecer una condición referida a un campo de texto la condición de
búsqueda debe ir encerrada entre comillas simples; la segunda es que no es
posible establecer condiciones de búsqueda en los campos memo y; la tercera
y última hace referencia a las fechas. A día de hoy no he sido capaz de
encontrar una sintaxis que funcione en todos los sistemas, por lo que se hace
necesario particularizarlas según el banco de datos:
Banco de Datos Sintaxis
SQL-SERVER Fecha = #mm-dd-aaaa#
ORACLE Fecha = to_date('yyyyDDMM','aaaammdd',)
ACCESS Fecha = #mm-dd-aaaa#
EJEMPLO
Banco de Datos Ejemplo (para grabar la fecha 18 de mayo de 1969)
Fecha = #05-18-1969# ó
SQL-SERVER
Fecha = 19690518
ORACLE Fecha = to_date('yyyyDDMM', '19690518')
ACCESS Fecha = #05-18-1969#
Referente a los valores lógicos TRUE o FALSE cabe destacar que no son
reconocidos en ORACLE, ni en este sistema de bases de datos ni en SQL-
SERVER existen los campos de tipo "SI/NO" de ACCESS; en estos sistemas
se utilizan los campos BIT que permiten almacenar valores de 0 ó 1.
Internamente, ACCESS, almacena en estos campos valores de 0 ó -1, así que
todo se complica bastante, pero aprovechando la coincidencia del 0 para los
valores FALSE, se puede utilizar la sintaxis siguiente que funciona en todos los
casos: si se desea saber si el campo es falso "... CAMPO = 0" y para saber los
verdaderos "CAMPO <> 0".
OPERADORES LÓGICOS
Los operadores lógicos soportados por SQL son: AND, OR, XOR, EQV, IMP,
IS y NOT. A excepción de los dos últimos todos poseen la siguiente sintaxis:
<expresión1> operador <expresión2>
En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado
de la operación varía en función del operador lógico. La tabla adjunta muestra
los diferentes posibles resultados:
<expresión1> Operador <expresión2> Resultado
Verdad AND Falso Falso
Verdad AND Verdad Verdad
Falso AND Verdad Falso
Falso AND Falso Falso
Verdad OR Falso Verdad
Verdad OR Verdad Verdad
Falso OR Verdad Verdad
Falso OR Falso Falso
Verdad XOR Verdad Falso
Verdad XOR Falso Verdad
Falso XOR Verdad Verdad
Falso XOR Falso Falso
Verdad EQV Verdad Verdad
Verdad EQV Falso Falso
Falso EQV Verdad Falso
Falso EQV Falso Verdad
Verdad IMP Verdad Verdad
Verdad IMP Falso Falso
Verdad IMP NULL NULL

Falso IMP Verdad Verdad
Falso IMP Falso Verdad
Falso IMP NULL Verdad
NULL IMP Verdad Verdad
NULL IMP Falso NULL
NULL IMP NULL NULL
Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT

el resultado de la operación será el contrario al devuelto sin el operador NOT.
El último operador denominado IS se emplea para comparar dos variables de

tipo objeto <Objeto1> IS <Objeto2>. este operador devuelve verdad si los dos
objetos son iguales.
SELECT * FROM Empleados

WHERE Edad > 25 AND Edad < 50

WHERE (Edad > 25 AND Edad < 50) OR Sueldo = 100
SELECT * FROM Empleados WHERE NOT Estado = 'Soltero'
SELECT * FROM Empleados WHERE (Sueldo > 100 AND Sueldo < 500)
OR (Provincia = 'Madrid' AND Estado = 'Casado')
Valores Nulos
En muchas ocasiones es necesario emplear como criterio de seleccion valores

nulos en los campos. Podemos emplear el operacion IS NULL para realizar
esta operación. Por ejemplo:
WHERE DNI IS NULL
Este operador no está reconocido en ACCESS y por ello hay que utilizar la
siguiente sintaxis:

WHERE ISNULL(DNI)=TRUE
Intervalos de Valores
Para indicar que deseamos recuperar los registros según el intervalo de

valores de un campo emplearemos el operador BETWEEN cuya sintaxis es:
campo [NOT] BETWEEN valor1 AND valor2 (la condición NOT es opcional)
En este caso la consulta devolvería los registros que contengan en "campo" un
valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos
la condición NOT devolverá aquellos valores no incluidos en el intervalo.
SELECT * FROM Pedidos

WHERE CodPostal BETWEEN 28000 AND 28999
Devuelve los pedidos realizados en la provincia de Madrid
El Operador LIKE
Se utiliza para comparar una expresión de cadena con un modelo en una

expresión SQL. Su sintaxis es:
Expresión LIKE modelo
En donde expresión es una cadena modelo o campo contra el que se compara

expresión. Se puede utilizar el operador LIKE para encontrar valores en los
campos que coincidan con el modelo especificado. Por modelo puede
especificar un valor completo (Ana María), o se puede utilizar una cadena de
caracteres comodín como los reconocidos por el sistema operativo para
encontrar un rango de valores (LIKE An*).
El operador LIKE se puede utilizar en una expresión para comparar un valor de
un campo con una expresión de cadena. Por ejemplo, si introduce LIKE C* en
una consulta SQL, la consulta devuelve todos los valores de campo que
comiencen por la letra C. En una consulta con parámetros, puede hacer que el
usuario escriba el modelo que se va a utilizar.
El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido
de cualquier letra entre A y F y de tres dígitos:
LIKE 'P[A-F]###'
Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la
A a la D seguidas de cualquier cadena.
LIKE '[A-D]*'
En la tabla siguiente se muestra cómo utilizar el operador LIKE para

comprobar expresiones con diferentes modelos.
ACCESS
Tipo de Modelo No
Coincide
coincidencia Planteado coincide
'aa', 'aBa',
Varios caracteres 'a*a' 'aBC'
'aBBBa'
Carácter especial 'a[*]a' 'a*a' 'aaa'
Varios caracteres 'ab*' 'abcdefg', 'abc' 'cab', 'aab'
Un solo carácter 'a?a' 'aaa', 'a3a', 'aBa' 'aBBBa'
Un solo dígito 'a#a' 'a0a', 'a1a', 'a2a' 'aaa', 'a10a'

Rango de caracteres '[a-z]' 'f', 'p', 'j' '2', '&'
Fuera de un rango '[!a-z]' '9', '&', '%' 'b', 'a'
Distinto de un dígito '[!0-9]' 'A', 'a', '&', '~' '0', '1', '9'
Combinada 'a[!b-m]#' 'An9', 'az0', 'a99' 'abc', 'aj0'
SQL-SERVER
Ejemplo Descripción
LIKE 'A%' Todo lo que comience por A
Todo lo que comience por cualquier carácter y luego siga

LIKE '_NG'
NG
LIKE '[AF]%' Todo lo que comience por A ó F
LIKE '[A- Todo lo que comience por cualquier letra comprendida entre
F]%' la A y la F
LIKE Todo lo que comience por A y la segunda letra no sea una

'[A^B]%' B
En determinado motores de bases de datos, esta cláusula, no reconoce el

asterisco como carácter comodín y hay que sustituirlo por el carácter tanto por
ciento (%).
El Operador IN
Este operador devuelve aquellos registros cuyo campo indicado coincide con
alguno de los en una lista. Su sintaxis es:
expresión [NOT] IN(valor1, valor2, . . .)

WHERE Provincia IN ('Madrid', 'Barcelona', 'Sevilla')
LA CLÁUSULA WHERE
La cláusula WHERE puede usarse para determinar qué registros de las tablas
enumeradas en la cláusula FROM aparecerán en los resultados de la
instrucción SELECT. Después de escribir esta cláusula se deben especificar
las condiciones expuestas en los apartados anteriores. Si no se emplea esta
cláusula, la consulta devolverá todas las filas de la tabla. WHERE es opcional,
pero cuando aparece debe ir a continuación de FROM.
SELECT Apellidos, Salario

FROM Empleados WHERE Salario = 21000
SELECT IdProducto, Existencias

FROM Productos WHERE Existencias <= NuevoPedido

WHERE FechaEnvio = #05-30-1994#
SELECT Apellidos, Nombre FROM Empleados

WHERE Apellidos = 'King'
SELECT Apellidos, Nombre FROM Empleados

WHERE Apellidos LIKE 'S*'
SELECT Apellidos, Salario FROM Empleados

WHERE Salario BETWEEN 200 AND 300
SELECT Apellidos, Salario FROM Empleados

WHERE Apellidos BETWEEN 'Lon' AND 'Tol'
SELECT IdPedido, FechaPedido FROM Pedidos

WHERE FechaPedido BETWEEN #01-01-1994# AND #12-31-1994#
SELECT Apellidos, Nombre, Ciudad FROM Empleados

WHERE Ciudad IN ('Sevilla', 'Los Angeles', 'Barcelona')
AGRUPAMIENTO DE REGISTROS
Bases de datos-SQL-Sentencias SQL-Agrupamiento de Registros
GROUP BY
Combina los registros con valores idénticos, en la lista de campos

especificados, en un único registro. Para cada registro se crea un valor
sumario si se incluye una función SQL agregada, como por ejemplo SUM o
COUNT, en la instrucción SELECT. Su sintaxis es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo
GROUP BY es opcional. Los valores de resumen se omiten si no existe una
función SQL agregada en la instrucción SELECT. Los valores NULL en los
campos GROUP BY se agrupan y no se omiten. No obstante, los valores
NULL no se evalúan en ninguna de las funciones SQL agregadas.
Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar,
y la cláusula HAVING para filtrar los registros una vez agrupados.
A menos que contenga un dato Memo u Objeto OLE, un campo de la lista de
campos GROUP BY puede referirse a cualquier campo de las tablas que
aparecen en la cláusula FROM, incluso si el campo no esta incluido en la
instrucción SELECT, siempre y cuando la instrucción SELECT incluya al
menos una función SQL agregada.
Todos los campos de la lista de campos de SELECT deben o bien incluirse en
la cláusula GROUP BY o como argumentos de una función SQL agregada.
SELECT IdFamilia, SUM(Stock) AS StockActual

FROM Productos GROUP y IdFamilia
Una vez que GROUP BY ha combinado los registros, HAVING muestra

cualquier registro agrupado por la cláusula GROUP BY que satisfaga las
condiciones de la cláusula HAVING.
HAVING es similar a WHERE, determina qué registros se seleccionan. Una
vez que los registros se han agrupado utilizando GROUP BY, HAVING
determina cuales de ellos se van a mostrar.
SELECT IdFamilia, SUM(Stock) AS StockActual
FROM Productos GROUP y IdFamilia
HAVING StockActual > 100 AND NombreProducto LIKE BOS*
AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo

especificado de una consulta. Su sintaxis es la siguiente
AVG(expr)
En donde expr representa el campo que contiene los datos numéricos para los
que se desea calcular la media o una expresión que realiza un cálculo
utilizando los datos de dicho campo. La media calculada por AVG es la media
aritmética (la suma de los valores dividido por el número de valores). La
función AVG no incluye ningún campo NULL en el cálculo.
SELECT AVG(Gastos) AS Promedio

FROM Pedidos WHERE Gastos > 100
COUNT
Calcula el número de registros devueltos por una consulta. Su sintaxis es la

siguiente:
COUNT(expr)
En donde expr contiene el nombre del campo que desea contar. Los
operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una función (la cual puede ser intrínseca o definida por el usuario
pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo
de datos incluso texto.
Aunque expr puede realizar un cálculo sobre un campo, COUNT simplemente
cuenta el número de registros sin tener en cuenta qué valores se almacenan
en los registros. La función COUNT no cuenta los registros que tienen campos
NULL a menos que expr sea el carácter comodín asterisco (*). Si utiliza un
asterisco, COUNT calcula el número total de registros, incluyendo aquellos que
contienen campos NULL. COUNT(*) es considerablemente más rápida que
COUNT(Campo). No se debe poner el asterisco entre dobles comillas ('*').
SELECT COUNT(*) AS Total

FROM Pedidos
Si expr identifica a múltiples campos, la función COUNT cuenta un registro sólo
si al menos uno de los campos no es NULL. Si todos los campos especificados
son NULL, no se cuenta el registro. Hay que separar los nombres de los
campos con ampersand (&).
SELECT COUNT(FechaEnvío & Transporte) AS Total

FROM Pedidos
Podemos hacer que el gestor cuente los datos diferentes de un determinado

campo
SELECT COUNT(DISTINCT Localidad) AS Total

FROM Pedidos
MAX, MIN
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un

campo especifico de una consulta. Su sintaxis es:
MIN(expr)
MAX(expr)
En donde expr es el campo sobre el que se desea realizar el cálculo. Expr

pueden incluir el nombre de un campo de una tabla, una constante o una
función (la cual puede ser intrínseca o definida por el usuario pero no otras de
las funciones agregadas de SQL).
SELECT MIN(Gastos) AS ElMin

FROM Pedidos WHERE Pais = 'España'
SELECT MAX(Gastos) AS ElMax

FROM Pedidos WHERE Pais = 'España'
STDEV, STDEVP
Devuelve estimaciones de la desviación estándar para la población (el total de

los registros de la tabla) o una muestra de la población representada (muestra
aleatoria). Su sintaxis es:
STDEV(expr)
STDEVP(expr)
En donde expr representa el nombre del campo que contiene los datos que
desean evaluarse o una expresión que realiza un cálculo utilizando los datos
de dichos campos. Los operandos de expr pueden incluir el nombre de un
campo de una tabla, una constante o una función (la cual puede ser intrínseca
o definida por el usuario pero no otras de las funciones agregadas de SQL).
STDEVP evalúa una población, y STDEV evalúa una muestra de la población.
Si la consulta contiene menos de dos registros (o ningún registro para
STDEVP), estas funciones devuelven un valor NULL (el cual indica que la
desviación estándar no puede calcularse).
SELECT STDEV(Gastos) AS Desviación

FROM Pedidos WHERE País = 'España'
SELECT STDEVP(Gastos) AS Desviación

SUM
Devuelve la suma del conjunto de valores contenido en un campo especifico

de una consulta. Su sintaxis es:
SUM(expr)
En donde expr representa el nombre del campo que contiene los datos que
desean sumarse o una expresión que realiza un cálculo utilizando los datos de
dichos campos. Los operandos de expr pueden incluir el nombre de un campo
de una tabla, una constante o una función (la cual puede ser intrínseca o
definida por el usuario pero no otras de las funciones agregadas de SQL).
SELECT SUM(PrecioUnidad * Cantidad) AS Total

FROM DetallePedido
VAR, VARP
Devuelve una estimación de la varianza de una población (sobre el total de los

registros) o una muestra de la población (muestra aleatoria de registros) sobre
los valores de un campo. Su sintaxis es:
VAR(expr)
VARP(expr)
VARP evalúa una población, y VAR evalúa una muestra de la población. Expr
el nombre del campo que contiene los datos que desean evaluarse o una
expresión que realiza un cálculo utilizando los datos de dichos campos. Los
operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una función (la cual puede ser intrínseca o definida por el usuario
pero no otras de las funciones agregadas de SQL)
Si la consulta contiene menos de dos registros, VAR y VARP devuelven NULL
(esto indica que la varianza no puede calcularse). Puede utilizar VAR y VARP
en una expresión de consulta o en una Instrucción SQL.
SELECT VAR(Gastos) AS Varianza
SELECT VARP(Gastos) AS Varianza

COMPUTE de SQL-SERVER
Esta cláusula añade una fila en el conjunto de datos que se está recuperando,
se utiliza para realizar cálculos en campos numéricos. COMPUTE actúa
siempre sobre un campo o expresión del conjunto de resultados y esta
expresión debe figurar exactamente igual en la cláusula SELECT y siempre se
debe ordenar el resultado por la misma o al memos agrupar el resultado. Esta
expresión no puede utilizar ningún ALIAS.
SELECT IdCliente, COUNT(IdPedido)

FROM Pedidos GROUP y IdPedido
HAVING COUNT(IdPedido) > 20 COMPUTE SUM(COUNT(IdPedido))
SELECT IdPedido, (PrecioUnidad * Cantidad - Descuento)

FROM [Detalles de Pedidos]
ORDER y IdPedido COMPUTE
SUM((PrecioUnidad * Cantidad - Descuento)) // Calcula el Total
y IdPedido // Calcula el Subtotal
A3-EC1 Sentencias SQL “Tablas Multiples”
Encontrar la solucion SQL para los siguientes planteamientos:
1. Mostrar todas las compras del cliente “Germán Goméz Lizalde”
2. Mostrar todos los pagos que ha realizado el cliente “Jazmín Perez
Perez”.
3. Mostrar todos los pagos que ha realizado el cliente “Jazmín Perez
Perez” pero solo en su ultimo credito.
4. Mostrar todos los productos en los cuales solo haya 5 piezas o menos.
5. Mostrar el total de ventas del día de hoy.

b) Producto esperado: 5 sentencias SQL validas para SQL Server 2000
c) Fecha inicio:
d) Fecha entrega:

Realizar las sentencias SQL, y
validarlas con el manejador
Sentencias SQL “Tablas
SQL Server 2000, para 10 puntos
Multiples”
cerciorarse de que la
respuesta es correcta.
Total 10 puntos

Comprobar que la sintaxis principalmente de las sentencias SQL es correcta y
además de verificar las ventajas que el lenguaje SQL ofrece.
Este manual
1.3.7. DOCUMENTOS
1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O

SUBCONSULTAS
Aprender a crear consultas anidadas, para poder realizar tareas mas complajas
requeridas para la administración de una base de datos.
1.4.2. RECURSOTIEMPO DEL TEMA 5 horas.
1.4.3. DESARROLLO
Bases de datos-SQL-Sentencias SQL-Subconsultas
Una subconsulta es una instrucción SELECT anidada dentro de una

instrucción SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o
dentro de otra subconsulta. Puede utilizar tres formas de sintaxis para crear
una subconsulta:
Comparación [ANY | ALL | SOME] (instrucción sql)

Expresión [NOT] IN (instrucción sql)
[NOT] EXISTS (instrucción sql)
En donde:
Es una expresión y un operador de comparación que

comparación
compara la expresión con el resultado de la subconsulta.
Es una expresión por la que se busca el conjunto

expresión
resultante de la subconsulta.
Es una instrucción SELECT, que sigue el mismo formato

instrucción
y reglas que cualquier otra instrucción SELECT. Debe ir
SQL
entre paréntesis.
Se puede utilizar una subconsulta en lugar de una expresión en la lista de

campos de una instrucción SELECT o en una cláusula WHERE o HAVING. En
una subconsulta, se utiliza una instrucción SELECT para proporcionar un
conjunto de uno o más valores especificados para evaluar en la expresión de
la cláusula WHERE o HAVING.
Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para
recuperar registros de la consulta principal, que satisfagan la comparación con
cualquier otro registro recuperado en la subconsulta. El ejemplo siguiente
devuelve todos los productos cuyo precio unitario es mayor que el de cualquier
producto vendido con un descuento igual o mayor al 25 por ciento:
SELECT * FROM Productos
WHERE PrecioUnidad ANY ( SELECT PrecioUnidad
FROM DetallePedido WHERE Descuento = 0 .25 )
El predicado ALL se utiliza para recuperar únicamente aquellos registros de la

consulta principal que satisfacen la comparación con todos los registros
recuperados en la subconsulta. Si se cambia ANY por ALL en el ejemplo
anterior, la consulta devolverá únicamente aquellos productos cuyo precio
unitario sea mayor que el de todos los productos vendidos con un descuento
igual o mayor al 25 por ciento. Esto es mucho más restrictivo.
El predicado IN se emplea para recuperar únicamente aquellos registros de la
consulta principal para los que algunos registros de la subconsulta contienen
un valor igual. El ejemplo siguiente devuelve todos los productos vendidos con
un descuento igual o mayor al 25 por ciento:
SELECT * FROM Productos WHERE IDProducto

IN ( SELECT IDProducto FROM DetallePedido WHERE Descuento = 0.25 )
Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos

registros de la consulta principal para los que no hay ningún registro de la
subconsulta que contenga un valor igual.
El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en
comparaciones de verdad/falso para determinar si la subconsulta devuelve
algún registro. Supongamos que deseamos recuperar todos aquellos clientes
que hayan realizado al menos un pedido:
SELECT Clientes.Compañía, Clientes.Teléfono FROM Clientes

WHERE EXISTS ( SELECT FROM Pedidos
WHERE Pedidos.IdPedido = Clientes.IdCliente )
Esta consulta es equivalente a esta otra:
SELECT Clientes.Compañía, Clientes.Teléfono FROM Clientes

WHERE IdClientes IN ( SELECT Pedidos.IdCliente FROM Pedidos )
Se puede utilizar también alias del nombre de la tabla en una subconsulta para
referirse a tablas listadas en la cláusula FROM fuera de la subconsulta. El
ejemplo siguiente devuelve los nombres de los empleados cuyo salario es igual
o mayor que el salario medio de todos los empleados con el mismo título. A la
tabla Empleados se le ha dado el alias T1:
SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS T1

WHERE Salario = ( SELECT AVG(Salario) FROM Empleados
WHERE T1.Titulo = Empleados.Titulo ) ORDER y Titulo
En el ejemplo anterior, la palabra reservada AS es opcional.
SELECT Apellidos, Nombre, Cargo, Salario FROM Empleados

WHERE Cargo LIKE 'Agente Ven*' AND Salario
ALL ( SELECT Salario FROM Empleados
WHERE Cargo LIKE '*Jefe*' OR Cargo LIKE '*Director*' )
Obtiene una lista con el nombre, cargo y salario de todos los agentes de
ventas cuyo salario es mayor que el de todos los jefes y directores.
SELECT DISTINCT NombreProducto, Precio_Unidad FROM Productos

WHERE PrecioUnidad = ( SELECT PrecioUnidad FROM Productos
WHERE NombreProducto = 'Almíbar anisado' )
Obtiene una lista con el nombre y el precio unitario de todos los productos con
el mismo precio que el almíbar anisado.
SELECT DISTINCT NombreContacto, NombreCompania, CargoContacto,

Telefono FROM Clientes WHERE IdCliente
IN ( SELECT DISTINCT IdCliente FROM Pedidos
WHERE FechaPedido <#07/01/1993# )
Obtiene una lista de las compañías y los contactos de todos los clientes que
han realizado un pedido en el segundo trimestre de 1993.
SELECT Nombre, Apellidos FROM Empleados AS E

WHERE EXISTS ( SELECT * FROM Pedidos AS O
WHERE O.IdEmpleado = E.IdEmpleado )
Selecciona el nombre de todos los empleados que han reservado al menos un

pedido.
SELECT DISTINCT Pedidos.Id_Producto, Pedidos.Cantidad,

( SELECT Productos.Nombre FROM Productos
WHERE Productos.IdProducto = Pedidos.IdProducto ) AS ElProducto
FROM Pedidos WHERE Pedidos.Cantidad = 150
ORDER y Pedidos.Id_Producto
Recupera el Código del Producto y la Cantidad pedida de la tabla pedidos,

extrayendo el nombre del producto de la tabla de productos.
SELECT NumVuelo, Plazas FROM Vuelos

WHERE Origen = 'Madrid' AND
EXISTS ( SELECT T1.NumVuelo FROM Vuelos AS T1
WHERE T1.PlazasLibres > 0 AND T1.NumVuelo=Vuelos.NumVuelo)
Recupera números de vuelo y capacidades de aquellos vuelos con destino

Madrid y plazas libres
Supongamos ahora que tenemos una tabla con los identificadores de todos
nuestros productos y el stock de cada uno de ellos. En otra tabla se
encuentran todos los pedidos que tenemos pendientes de servir. Se trata de
averiguar que productos no se podemos servir por falta de stock.
SELECT PedidosPendientes.Nombre FROM PedidosPendientes

GROUP y PedidosPendientes.Nombre
HAVING SUM(PedidosPendientes.Cantidad < (SELECT Productos.Stock
FROM Productos
WHERE Productos.IdProducto = PedidosPendientes.IdProducto ) )
Supongamos que en nuestra tabla de empleados deseamos buscar todas las

mujeres cuya edad sea mayor a la de cualquier hombre:
SELECT Empleados.Nombre FROM Empleados

WHERE Sexo = 'M' AND Edad > ANY
(SELECT Empleados.Edad FROM Empleados WHERE Sexo ='H')
ó lo que sería lo mismo:
SELECT Empleados.Nombre FROM Empleados

WHERE Sexo = 'M' AND Edad >
(SELECT MAX( Empleados.Edad )FROM Empleados WHERE Sexo ='H')
La siguiente tabla muestra algún ejemplo del operador ANY y ALL
Valor 1 Operador Valor 2 Resultado
3 > ANY (2,5,7) Cierto
3 = ANY (2,5,7) Falso
3 = ANY (2,3,5,7) Cierto
3 > ALL (2,5,7) Falso
3 < ALL (5,6,7) Falso
El operación =ANY es equivalente al operador IN, ambos devuelven el mismo

resultado.
Para concluir este apartado comentar que: la cláusula EXISTS se puede
emplear para generar la intersección entre dos consultas y, por tanto, la
cláusula NOT EXISTS para generar la diferencia entre consultas
A4-ER1 Examen Rápido.
Formular 5 preguntas acerca de subconsultas y dictárselas a los alumnos(as)
para que se contesten.
c) Fecha inicio:
d) Fecha entrega:

Formular las 5 preguntas de
Examen Rápido de subconsultas y dictárselas a
10 puntos
subconsultas los alumnos para proceder a
contestarlas.
Total 10 Puntos

Verificar que el tema se este entendiendo, para medir el nivel de aprendizaje y
tomar acciones en base a los resultados.
Ayuda de SQL Server 2000
1.4.7. DOCUMENTOS
1.5. PROCEDIMIENTOS ALMACENADOS

Manejar procedimientos para reducir errores en las acciones provocadas en
muchas ocaciones por los usuarios de Bases de Datos.
1.5.2. RECURSOTIEMPO DEL TEMA 6 horas
1.5.3. DESARROLLO
La característica primordial de los procedimientos almacenados es que se
optimizan en el momento de su creación. Esto supone que, a diferencia de lo
que sucede con las sentencias SQL que se envían el gestor de manera
interactiva, los procedimientos almacenados pasan previamente por un proceso
de normalización.
Cuando se crea un procedimiento almacenado el procesador de consultas del

gestor crea una versión del mismo con una cierta estructura normalizada, y la
almacena en una de las tablas de sistema. Las siguientes ejecuciones de dicho
procedimiento, no necesitarán consumir el tiempo necesario para llevar a cabo
este proceso de normalización, con lo que su ejecución será más rápida.
Por otra parte, cuando el procedimiento se ejecuta por vez primera, se produce
su compilación y la optimización del acceso del procedimiento a los datos. Este
proceso optimizado se mantiene en memoria para posteriores ejecuciones con
el consiguiente ahorro adicional de tiempo y recursos.
Existen dos maneras de crear procedimientos almacenados: utilizando la

sentencia CREATE PROCEDURE y mediante Enterprise Manager
La sentencia CREATE PROCEDURE
La sentencia Transact-SQL que permite crear procedimientos almacenados es

CREATE PROCEDURE. Permite crear un procedimiento almacenado a partir
de una determinada colección de sentencias SQL ligadas por sentencias
adicionales de control de flujo
La sintaxis de esta sentencia es la siguiente:
Sintaxis CREATE PROCEDURE

CREATE PROCEDURE [propietario.] nombre de procedimiento[;número]
[(lista de parámetros) ]
[{FOR REPLICATION} | {WITH RECOMPILE}
[{[WITH] | [,]} ENCRYPTION]]
AS sentencias SQL
PARAMETROS
Como hemos comentado anteriormente, los procedimientos almacenados

permiten que su ejecución pueda ser adaptada a la situación y ámbito en el que
sean llamados. Para ello, al igual que las funciones y procedimientos en
lenguajes de programación estructurada, pueden recibir parámetros. Así el
procedimiento recibir datos diversos en función de la situación en la que la
llamada se realice.
La definición de parámetros se lleva a cabo en el momento de la creación del

procedimiento almacenado. Cuando el usuario solicite la ejecución de un
procedimiento definido con parámetros deberá suministrar valores para ellos
La sintaxis de definición de un parámetro es la siguiente:
 Sintaxis de definición de parámetros
@nombre_de _parámetro tipo_de_datos [= valor por defecto] [OUTPUT]
Puede especificarse un valor por defecto para cada parámetro. La manera de

especificar un valor por defecto es colocar después del nombre de parámetro el
signo = seguido por la constante que se utilizará como valor.
De igual modo, también es posible definir ciertos parámetros como de retorno.
Este tipo de parámetros se especifican como cualquier otro, con la salvedad de
que sus nombres aparecen seguidos por la palabra clave OUTPUT. Cuando el
procedimiento se ejecute devolverá en esos parámetros los valores que hayan
tomado en el interior del mismo. Estos valores podrán ser almacenados en
variables y utilizados posteriormente.
RECOMPILE: Procedimientos de recompilación forzosa
Imaginemos que generamos un procedimiento almacenado cuyos parámetros

puedan ser de tipos muy diversos. Esto supondrá que sea común que la
optimización que se ha llevado a cabo en primera instancia, no sea válida para
otras ejecuciones del procedimiento. Por otra parte, es común que
frecuentemente se añadan nuevos índices que hagan que la optimización de la
consulta deje también de ser válida.
El rendimiento en este tipo de situaciones no es el más adecuado, pues se
ralentizan las operaciones. Es en estos casos necesario que el procedimiento
almacenado se recompila cada vez que se ejecuta, desoyendo o
deshabilitando la característica de optimización única que antes hemos
presentado. La cláusula que permite indicar que el procedimiento debe ser
recompilado en cada ejecución es WITH RECOMPILE
Sentencias SQL del procedimiento almacenado
El cuerpo del procedimiento estará integrado por un conjunto de sentencias

SQL que realizarán las tareas que esperamos del mismo y que se
especificarán en la definición del procedimiento siguiendo a la cláusula AS
En general podemos decir que en un procedimiento almacenado pueden
incluirse cualquier número y tipo de sentencias Transact SQL. Sin embargo, es
necesario comentar algunas restricciones respecto a la creación de objetos No
pueden incluirse las siguientes sentencias CREATE
 CREATE VIEW
 CREATE TRIGGER
 CREATE DEFAULT
 CREATE PROCEDURE
 CREATE RULE
Creación de procedimientos almacenados mediante Enterprise Manager
Hasta este momento hemos presentado la sintaxis de la sentencia Transact
SQL que permite crear procedimientos almacenados. A continuación
recordaremos el procedimiento necesario para crear un procedimiento
almacenado mediante Enterprise Manager
Para ello deberán seguirse los siguientes pasos:
 Acceder a la ventana Server Manager y al nodo Stored Procedures

 Una vez accedido pulsar el botón derecho del ratón y elegir la orden de
menú New Stored PROCEDURE.
 Especificar la misma sentencia de creación de procedimiento
almacenado que pusimos antes como ejemplo.
 Pulsar el botón SAVE Object.
 En la ventana Server Manager aparecerá el nuevo procedimiento
almacenado.
Una vez creado el procedimiento, esto es, una vez definido, SQL Server
generará el siguiente código.
 Código generado tras la creación del procedimiento
IF EXISTS (SELECT * FROM sysobjects WHERE id =

object_id('dbo.infousuarios') AND sysstat & 0xf = 4)
DROP PROCEDURE dbo.infousuarios
GO
CREATE PROCEDURE infousuarios AS
SELECT * FROM sysusers
GO
Las líneas adicionales evitarán que se intenten crear dos procedimientos con el
mismo nombre.
ELIMINACIÓN DE PROCEDIMIENTOS ALMACENADOS
La sentencia DROP PROCEDURE sirve para eliminar del catálogo un

procedimiento almacenado y su sintaxis y uso resulta totalmente análogo a las
que se utilizan para eliminar cualquier otro objeto de una base de datos
EJECUCIÓN DE PROCEDIMIENTOS ALMACENADOS
Una vez se ha creado un procedimiento almacenado, se encontrará en

disposición de ser ejecutado. Si en la primera línea de una secuencia de
sentencias Transact_SQL aparece el nombre de un procedimiento
almacenado, SQL Server lo ejecutará. En el resto de situaciones deberemos
utilizar la sentencia EXECUTE
Esta sentencia se utiliza para la ejecución de todo tipo de procedimientos
almacenados, tanto de sistema, como de usuario. Por otra parte también
permite la ejecución de una cadena de caracteres que contiene una cierta
sentencia Transact_SQL
Su sintaxis es la siguiente:
SINTAXIS EXECUTE PARA PROCEDIMIENTOS ALMACENADOS
EXEC[ute] {[@valor de retorno =]{[[[nombreproc[;num]|@variablenombre}
[[@parámetro =] {valor | @variable [OUTPUT]]
[, [@parámetro =] {valor | @variable [OUTPUT]}]...]
[WITH RECOMPILE]]
El procedimiento que se ejecutará es el especificado en nombreproc. El

nombre del procedimiento puede estar contenido en una variable como aquí
@variablenombre.
VALOR DE RETORNO
Como hemos comentado anteriormente, los procedimientos almacenados
pueden, opcionalmente devolver un valor. Si esto es así, este valor retornado
deberá ser almacenado en una variable que en la sintaxis hemos presentado
como @valor de retorno.
INFORMACIÓN RETORNADA POR UN PROCEDIMIENTO ALMACENADO
Los procedimientos almacenados pueden retornar información al procedimiento

que los llamó o al usuario que solicita su ejecución básicamente de dos modos:
 Mediante el retorno de un valor de estado.

 Mediante parámetros de retorno.
VALOR DE ESTADO (STATUS VALUE)
Es una práctica común la mayoría de lenguajes de programación el hacer que

los procedimientos o funciones retornen un valor que permita testear cual ha
sido el modo o resultado con el que la ejecución de dicha función ha concluido.
Generalmente dichos valores son definidos de antemano de manera que un
mero análisis del valor de estado permita conocer qué ha sucedido.
Los procedimientos almacenados SQL Server devuelven también un valor de
estado o status value. Este valor puede ser almacenado en una variable de
manera que pueda examinarse posteriormente para valorar el éxito de su
ejecución o el motivo de su fracaso.
Veamos un ejemplo tomando como base la base de datos ESCUELA, con las
siguientes tablas:
 Devolución de valor de estado definido por el usuario
Este procedimiento devuelve 100 si la calificación del alumno es menor

que 70 y 200 en caso contrario
CREATE PROCEDURE APROBADO AS
IF (SELECT Cal FROM Calificacion WHERE Matricula = 2004001 AND CvMat = 100) > 70
RETURN 100
ELSE
RETURN 200
GO
Podríamos definir un nuevo procedimiento almacenado que utilice a este

primero
 Utilización del procedimiento almacenado
Este procedimiento presenta un mensaje indicando si un determinado

alumno está aprobado o no, utilizando el procedimiento aprobado
CREATE PROCEDURE MOSTRARMENSAJE AS
DECLARE @ValorDeRetorno INT
EXECUTE @ValorDeRetorno = APROBADO
IF (@ValorDeRetorno = 100)
PRINT 'APROBADO'
ELSE
PRINT 'REPROBADO'
GO
RETORNO DE PARÁMETROS
En el momento de la creación y definición de un procedimiento almacenado

puede especificarse que alguno, o todos, los parámetros que dicho
procedimiento aceptará sean considerados parámetros de retorno.
Veamos un ejemplo de uso de procedimiento almacenado con paso de
parámetros
PASO DE PARÁMETROS
Este procedimiento realiza la suma de dos variables enteras y devuelve una

variable entera como un parámetro de salida.
Este ejemplo solo suma dos numeros enteros y regresa el resultado.
CREATE PROCEDURE suma @sum1 int, @sum2 int, @res int OUTPUT
AS
SELECT @res = @ sum1 + @sum2
RETURN 0
Veamos un ejemplo de utilización
 Uso de procedimiento almacenado con parámetros
DECLARE @resultado int
DECLARE @retorno int

EXECUTE @retorno = suma 2, 2, @resultado OUTPUT
En este punto @retorno valdrá 0 y @resultado tendrá como valor 4.
Este es otro ejemplo con la tabla de Calificación.
CREATE PROCEDURE PROMEDIO @Matric INT, @Prom FLOAT OUTPUT AS
SELECT @Prom = AVG(Cal) FROM Calificacion WHERE Matricula = @Matric
RETURN 0
GO
Y esta seria la Consulta a realizar
DECLARE @Matric FLOAT
DECLARE @Prom int
EXECUTE @Matric = PROMEDIO 2004001, @Prom OUTPUT
PRINT @Prom

A5-EC2 Procedimientos Almacenados.
Realizar los siguientes procedimientos almacenados:
1. Cacular las ventas del día de hoy
2. Calcular cuantos pagos ha hecho un cliente.
3. Calcular el total de las compras en un mes.

b) Producto esperado: Mostrar la sentencia SQL de los procedimientos
almacenados anteriores
c) Fecha inicio:
d) Fecha entrega:

Los alumnos deben de checar
la solucion para cada
Procedimientos almacenados planteamiento, en SQL Server 10 puntos
2000. y entregar la solución en
papel.
Total 10 puntos

Conocer de cerca la utilidad que tienen los procedimientos almacenados.
1.5.7. DOCUMENTOS
1.6. TRIGGERS
Entender la ventaja de manejar ciertas acciones dentro de una base de datos
con procedimientos de disparo (autoejecutables).
1.6.3. DESARROLLO
Un TRIGGER no es más que un tipo especial de procedimiento almacenado.

En lugar de ejecutarse como respuesta a una llamada, se ponen en
funcionamiento automáticamente como respuesta a ciertas modificaciones de
los datos, cuya naturaleza se especifica en el momento de la creación del
TRIGGER.
La utilidad de los TRIGGERS es múltiple. Quizá la más ampliamente utilizada
es la de establecer reglas de consistencia entre los datos presentes en las
diferentes tablas de nuestra base de datos. Los TRIGGERS son una
herramienta poderosa para centralizar en la base de datos la toma de las
decisiones de negocio que se asocian a los datos de la misma. De esta manera
se descarga en gran medida a las aplicaciones cliente de la tarea de revisar las
acciones de actualización de datos.
Como hemos dicho, las acciones que motivarán que un TRIGGER se ponga en
ejecución, es decir aquellas acciones que disparan el TRIGGER, son
modificaciones que puedan llevarse a cabo en los datos, tanto la adición de
datos nuevos como la eliminación de datos existentes. Dichas modificaciones
se llevan a cabo, evidentemente, mediante la ejecución de las sentencias
UPDATE, DELETE o INSERT.
Supongamos el caso en el que existan dos tablas Existencias y Ventas de

manera que cada vez que se produce una nueva venta deben actualizarse las
unidades que aún quedan en existencias. La solución a este problema, si se
sigue la filosofía de toma de decisiones mediante TRIGGERS que Microsoft
recomienda utilizar con SQL Server, es dejar que sea la propia base de datos
la que se encargue de realizar las actualizaciones de manera automática. Es
posible definir un TRIGGER que realice las tareas descritas y que se ponga en
ejecución inmediatamente después a la operación de borrado o inserción.
Así, cuando dicha acción de modificación se complete, el TRIGGER adecuado

se disparará. Pueden definirse TRIGGERS que respondan a una o varias de
estas acciones, es decir, puede definirse un TRIGGER que responda tanto a
una operación INSERT, como a una DELETE.
De este modo, los TRIGGERS pueden utilizarse para resolver, entre otras, las
siguientes situaciones:
 Preservar la integridad referencial. En el caso en que dos o más

tablas en una base de datos se hallen ligadas por claves ajenas no será
posible modificar datos en la tabla primaria sin modificar aquellos que se
hallen vinculados a él en la tabla subordinada. Utilizando TRIGGERS
podemos controlar este proceso forzando a que los registros
dependientes sean eliminados cuando llevamos a cabo un DELETE en
la tabla principal.
 Establecimiento de condiciones complejas: Los TRIGGERS
permiten, como veremos más adelante, especificar condiciones para que
los datos de una o varias columnas sean considerados válidos.
 Respuesta a cambios de estado de la tabla: Los TRIGGERS permiten
examinar el estado de la tabla antes y después de que una determinada
tarea de modificación haya sido llevada a cabo y obrar en consecuencia.
La sentencia Transact-SQL que permite crear TRIGGERS es CREATE

TRIGGER.
SINTAXIS CREATE TRIGGER
CREATE TRIGGER [propiet.] nombretrigger ON [propiet.]nombretabla
FOR {INSERT, UPDATE, DELETE}
[WITH ENCRyPTION]
AS sentenciasSQL
Acciones que desatan la ejecución del TRIGGER

El TRIGGER se ejecuta como respuesta a la aplicación de ciertas sentencias
de modificación sobre la tabla asociada al mismo. Estas sentencias se
especifican en la cláusula FOR UPDATE/INSERTDELETE Cuando se lleven a
cabo la o las acciones que se especifiquen en la definición del TRIGGER sobre
la tabla, las sentencias que lo conforman se ejecutarán.
De esta manera, pueden definirse hasta tres TRIGGERS diferentes para cada
tabla, uno por cada acción INSERT, UPDATE o DELETE. En cualquier caso,
es posible especificar en un sólo TRIGGER, cualquier combinación de las tres
acciones disponibles.
SENTENCIAS SQL DEL TRIGGER
El cuerpo del TRIGGER constará de una serie de sentencias SQL que

realizarán las tareas que esperamos del mismo y una serie de condiciones que
determinarán de manera adicional si las acciones del TRIGGER deben ser
llevadas o no cabo.
En general podemos decir que en un TRIGGER, como en cualquier
procedimiento almacenado, pueden incluirse cualquier número y tipo de
sentencias Transact SQL. Sin embargo, y por su propia naturaleza, la de
responder a una acción ejecutando otras, no es posible incluir en las
sentencias del TRIGGER la sentencia SELECT.
No son estas las únicas restricciones aplicables a las sentencias ejecutables en
un TRIGGER. Concretamente las siguientes sentencias no pueden utilizarse.
 Sentencias de creación: No puede incluirse ninguna sentencia

CREATE.
 Sentencias de eliminación de objetos: No pueden eliminarse objetos,
por lo que no está permitido utilizar ninguna de las sentencias de la
familia DROP
 Sentencias de modificación de objetos: No puede alterarse la
estructura de tablas ni bases de datos mediante las sentencias ALTER
DATABASE, ALTER TABLE
 Sentencias de borrado de filas: No puede utilizarse la sentencia
TRUNCATE TABLE para borrar todas las filas de una tabla.
 Permisos: No pueden otorgarse ni retirarse permisos, por lo que no son
utilizables GRANT y REVOKE
Veamos un ejemplo de un sencillo TRIGGER que presenta un mensaje cada

vez que se añade un nuevo autor a la tabla authors de la base de datos pubs
CREACIÓN DE TRIGGERS MEDIANTE ENTERPRISE MANAGER
También es posible crear TRIGGERS mediante Enterprise Manager. A pesar

de ser un objeto más de la base de datos, los TRIGGERS no aparecen en la
ventana Server Manager, por lo que deberán ser creados utilizando opciones
de menú. Concreatamente deberán seguirse los siguientes pasos:
 Pulsar el menú Manage TRIGGERS, una vez seleccionada en la

ventana Server Manager una base de datos.
 Seleccionar la tabla a la que se desee asociar un TRIGGER, de la lista
desplegable adjunta.
 Escoger New
 Escribir las sentencias de creación del TRIGGER
ELIMINACIÓN DE TRIGGERS
Para eliminar un TRIGGER puede utilizarse la sentencia DROP TRIGGER,

análogamente al resto de objetos. Puede eliminarse más de un TRIGGER de
manera simultánea pasando a la sentencia sus nombres separados por comas.
SINTAXIS DROP TRIGGER
DROP TRIGGER [prop.]nombretrigger1 [, [prop.]nombretrigger2...]
Utilización de TRIGGERS para validar actualizaciones de tablas
Una de las principales utilidades de los TRIGGERS es la de controlar que las

operaciones de actualización que se llevan a cabo sobre una tabla sean
coherentes. De este modo podemos centralizar en la base de datos los
procesos de validación de datos, tanto al añadir nuevos registros como en su
eliminación.
Las tablas Inserted y Deleted
En multitud de ocasiones las operaciones de actualización de la tabla que

suponen inserción y borrado de filas se llevan a cabo en cadena, normalmente
por la propia naturaleza de las sentencias implicadas.
En este tipo de situaciones el TRIGGER que deba responder a estas acciones
puede necesitar valorar qué cambios se han producido sobre la tabla de
manera que se pueda obrar en consecuencia. Para ello se necesitaría disponer
de algún modo de información del estado de la tabla antes y después de las
modificaciones efectuadas. Para ello SQL Server proporciona dos tablas
temporales denominadas
Para conocer el número de filas modificadas por una sentencia de actualización

determinada es posible acudir a la variable global @@rowcount. Esta variable
contiene el número de filas modificadas.
INSERCIÓN MÚLTIPLE
La tabla inserted almacena una copia de las filas que se han añadido durante la
ejecución de una sentencia INSERT o UPDATE sobre una tabla que tiene
asociado un TRIGGER.
BORRADO MÚLTIPLE
La tabla deleted almacena una copia de las filas eliminadas durante una
sentencia DELETE o UPDATE. Evidentemente, una vez realizada la loperación
de borrado, las filas desaparecerán de la tabla asociada al TRIGGER y sólo
aparecerán en la tabla deleted
TRIGGERS y TRANSACCIONES
Los TRIGGERS pueden descartar las transacciones en el marco de las cuales

se ejecutan. Es decir, los TRIGGERS pueden ser ejecutados en respuesta a
una acción que se haya inmersa en una transacción. Si uno de estos
TRIGGERS contiene la sentencia ROLLBACK TRANSACTION, que
recordemos tiene como resultado el descartar las operaciones realizadas en la
transacción en curso, la transacción completa en la que dicho TRIGGER se
ejecuta será descartada.
Veamos un ejemplo en que la operación UPDATE tiene asociado un TRIGGER

que, por cualquier circunstancia que no nos detendremos a concretar, provoca
que la transacción en curso sea descartada mediante ROLLBACK. En el
ejemplo que sigue la operación INSERT no se ejecutará, pues la transacción se
dará por finalizada después de la sentencia UPDATE.
 TRANSACCIONES y TRIGGERS
BEGIN TRANSACTION
UPDATE alumnos SET nota = nota + 1 WHERE notapracticas = 10
INSERT alumnos VALUES ('Javier Márquez', „Grupo3‟, 5.5, 6.3, '6/11/96')
END TRANSACTION
UN EJEMPLO COMPLETO
Para ilustrar los conceptos expuestos en este artículo vamos a presentar un

pequeño ejemplo en el que se utilizan tanto procedimientos almacenados como
TRIGGERS.
Nos proponemos informatizar una biblioteca creando una base de datos que
mantenga información de los volúmenes existentes en su fondo, de los socios
inscritos y de los préstamos efectuados. Evidentemente, nuestro objetivo es
simplemente ilustrar el sentido y necesidad de procedimientos almacenados y
TRIGGERS por lo que el diseño se ha simplificado al máximo evitando
cualquier tipo de consideración sobre el modelo de datos.
CREACIÓN DE LA BASE DE DATOS
El primer paso será definir siquiera burdamente las tablas necesarias. Del más
sencillo análisis resulta que es necesario, al menos, definir una tabla libros, una
segunda autores, una tercera socios, y una cuarta prestamos, que servirá para
almacenar cada acción de préstamo que se lleve a cabo.
La definición de las tablas podemos realizarla mediante Enterprise Manager o
utilizando sentencias Transact SQL. Por simplicidad haremos uso de las
herramientas visuales de Enterprise Manager, tal y como podemos ver en la
figura A.6. Las sentencias Transact_Sql mínimas equivalentes serían
 Tabla libros:
CREATE TABLE libros
(registro smallint
signatura char(20),
titulo varchar(50),
nombreautor varchar(50)
editorial varchar(20),
fechaentrada datetime)
 Tabla autores:
CREATE TABLE autores
(idautor smallint
nombreautor varchar(50),
nacionalidad varchar(20))
 Tabla socios:
CREATE TABLE socios

(idsocio smallint
nombresocio varchar(50),
edad smallint,
direccion varchar(20),
teléfono varchar(10))
 Tabla prestamos:
CREATE TABLE prestamos
(idprestamo smallint
idautor smallint,
idsocio smallint,
fechaprestamo datetime)
DEFINICIÓN DE PROCEDIMIENTOS ALMACENADOS
Se supone que la base de datos estará disponible al público que visite la

biblioteca para que puedan consultar por su cuenta, por ejemplo, los libros de
un determinado autor. La manera de hacer posibles estas consultas
generalmente será mediante la programación de una pequeña aplicación
cliente que enviará a SQL Server las peticiones de datos.
Parece evidente que la consulta Libros de un autor será muy frecuente, de
manera que será adecuado y adecuado definir en la base de datos un
procedimiento almacenado que reciba como argumento el nombre del autor del
que se desea conocer su obra completa. Este procedimiento se almacenará en
SQL Server y su ejecución será solicitada por las aplicaciones cliente,
obteniendo un rendimiento mejor al que puede obtenerse con la simple
realización de la consulta. Veamos una posible implementación de este
procedimiento.
 Procedimiento ObraPorAutor
CREATE PROCEDURE ObraPorAutor @nautor varchar(50)
AS SELECT titulo, editorial, cantidad
FROM libros
WHERE nombreautor = @nautor
DEFINICIÓN DE TRIGGERS
Existen múltiples situaciones en las que en este ejemplo sería interesante

definir un TRIGGER.
Una primera muestra sería la del control de préstamo. Imaginemos que
deseamos evitar que cada socio pueda tener más de un libro simultáneamente
en su poder. Cada vez que se realiza un préstamo nuevo la aplicación cliente
solicitará la inserción de una nueva fila en la tabla de préstamos. Podríamos
escribir un TRIGGER que tras cada inserción en esta tabla, buscase si existe
alguna otra fila en la misma que corresponda a un préstamo al mismo socio, y
que eliminase el nuevo préstamo si ya existía uno aún no terminado. La
aplicación cliente podría recibir información en la que examinase si la inserción
se había realizado correctamente y presentar, si así se desea un mensaje
explicativo. Pero, lo que es más importante, los datos de la base de datos
serían coherentes. Veamos este ejemplo:
 Inserción condicional de un préstamo

CREATE TRIGGER prestamocondicional
ON prestamos
FOR INSERT AS
IF
(SELECT COUNT(*) FROM prestamos, inserted
WHERE prestamos.idsocio = inserted. idsocio ) <> @@rowcount
BEGIN
DELETE * FROM prestamos
WHERE prestamos. idprestamo = inserted. idprestamo
END
Otra posibilidad es la de gestionar la correspondencia entre la tabla libros y la

tabla autores cuando se da de baja un ejemplar por pérdida, sustracción o
cualquier otra circunstancia. En este caso el TRIGGER deberá examinar, tras
la eliminación de un libro, si existe el autor del libro eliminado tiene aún algún
volumen en el fondo de la biblioteca, eliminando su entrada en la tabla autores
si no es así. El TRIGGER sería similar al siguiente:
 Eliminación condicional de un autor
CREATE TRIGGER comprobarautor
ON libros
FOR DELETE AS
IF
(SELECT COUNT(*) FROM libros
WHERE libros.idautor = deleted. idautor ) > 0
BEGIN
DELETE * FROM autores
WHERE autores. idautor = deleted. idautor
END
Otro ejemplo con la base de datos ESCUELA, que se activa cada vez que
deseo ingresar una calificación nueva.
Lo que que hace es checar si no hay alguna calificación para ese alumno
y esa misma matricula.
CREATE TRIGGER ACTUALIZACAL ON Calificacion FOR INSERT AS
IF (SELECT COUNT(Calificacion.Cal)
FROM Calificacion, inserted
WHERE Calificacion.Matricula = inserted.Matricula
AND Calificacion.CvMat = inserted.CvMat) > 0
BEGIN
DELETE FROM Calificacion
WHERE Calificacion.Matricula = inserted.Matricula
AND Calificacion.CvMat = inserted.CvMAt
END
Cómo crear un desencadenador (Administrador corporativo)

Para crear un desencadenador
1. Expanda un grupo de servidores y, a continuación, un servidor.
2. Expanda Bases de datos, expanda la base de datos a la que pertenece

la tabla que va a contener el desencadenador y, a continuación, haga
clic en Tablas.
3. En el panel de detalles, haga clic con el botón secundario del mouse en

la tabla en la que va a crear el desencadenador, seleccione Todas las
tareas y haga clic en Administrar desencadenadores.
4. En el cuadro Nombre, haga clic en <nuevo>.
5. En el cuadro Texto, escriba el texto del desencadenador. Utilice

Ctrl+Tab para aplicar una sangría al texto de un desencadenador.
6. Para comprobar la sintaxis, haga clic en Comprobar la sintaxis.
EJEMPLO: tomando como base el siguiente esquema
El siguiente TRIGGER lo que hace es disminuir las existencias en base a la

cantidad de producto vendido.
CREATE TRIGGER Inventario ON VentaProducto

FOR INSERT
AS
DECLARE @Cant INTEGER
DECLARE @Exis INTEGER
DECLARE @ClaveP INTEGER
SELECT @Cant = Cantidad, @ClaveP = CvProd FROM VentaProducto
SELECT @Exis = Existencias FROM Producto WHERE CvProd = @ClaveP
BEGIN
UPDATE Producto SET Existencias = @Exis- @cant WHERE CvProd = @ClaveP
END
A6-EC3 Procedimientos de disparo
Indicar la instrucción de los siguientes TRIGGERS:
1. Un disparo que actualice las Existencias de Producto con le realización
de una venta.
2. Un disparo que actualice las Existencias de Producto con le realización
de una compra.
b) Producto esperado: Sentencias SQL de los dos plateamientos
propuestos
c) Fecha inicio:
d) Fecha entrega:

Entregar en papel la solucion
Procedimientos de disparo y corroborar que funcionen 10 puntos
con SQL Server 2000.
Total 10 puntos

Validar cuestiones de integridad de datos y aprender a validar ciertas reglas de
negocio que se pueden presentar.
1.6.7. DOCUMENTOS
1.7. VISTAS
Aprender a crear Tablas Virtuales, las cuales son de mucha ayuda para ciertas
necesidades.
1.7.3. DESARROLLO
La definición más simple de una vista es la que nos dice que una vista es una
consulta a la que se da un nombre. Una vista es una tabla virtual que nos
permite alcanzar tres objetivos:
 La confidencialidad de la información
 La transparencia de la estructura interna de la BD
 El control de las restricciones de integridad
Se denomina virtual porque no tiene existencia propia; ella parece y se
comporta como una tabla para el usuario, pero consiste a nivel interno en una
sentencia SQL, que esta catalogada en el diccionario de datos.
Una vez que la vista se ha detenido, se puede acceder a ella exactamente igual
que si fuese una tabla para ver su estructura o para seleccionar los datos que
contiene.
El mayor problema asociado a las vistas es determinar cuando los datos de
una vista se pueden actualizar (insertar, borrar o modificar filas).
Las tablas indicadas en la consulta que define una vista se denominan tablas
base, y pueden a su vez ser vistas.
Puede utilizar las vistas para simplificar las consultas. Un modelo de datos
normalizado puede estar formado por muchas tablas. Si los usuarios finales
están autorizados a consultar los datos de forma interactiva, probablemente
desee simplificar el modelo de datos, incluso si los usuarios utilizan potentes
herramientas de análisis.
Una simplificación habitual consiste en realizar una combinación en la
definición de la vista. En lugar de que el usuario realice la combinación cada
vez que escriba una consulta, trabajara utilizando una vista.
La sentencia utilizada para crear una vista es CREATE VIEW, cuya sintaxis
general se muestra a continuación.
CREATE VIEW nombre vista AS sentencia SELECT
Como ejemplo creamos una vista que encuentre todos los alumnos que cursan
una materia de Ingles.
CREATE VIEW dbo.vista1 AS

SELECT Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación
FROM Alumno INNER JOIN Calificacion
ON Alumno.Matricula = Calificacion.Matricula
INNER JOIN Materia ON Calificacion.CvMat = Materia.CvMat
WHERE Materia.Nombre = 'Ingles'
CONSULTA A TRAVÉS DE UNA VISTA
SELECT * FROM vista1 WHERE Alumno = 'xxxx'
La consulta anterior toma a la vista como una tabla propia de la Base de Datos,
aunque en realidad no lo es, lo que paso fue que al momento de ejecutar la
vista se creo una tabla virtual.
La sentencia utilizada para eliminar una vista es DROP VIEW, cuya sintaxis
general se muestra a continuación.
DROP VIEW nommbre_vista
La sentencia utilizada para modificar una vista es ALTER VIEW, cuya sintaxis
es idéntica a la sintaxis de la instrucción CREATE VIEW.
Ejemplo para modificar la vista1 creada arriba.
ALTER VIEW vista1 AS

SELECT Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación
FROM Alumno INNER JOIN Calificacion
ON Alumno.Matricula = Calificacion.Matricula
INNER JOIN Materia ON Calificacion.CvMat = Materia.CvMat
WHERE Materia.Nombre = 'Fisica'

A7-EC4 Vistas
Elaborar las siguientes vistas:
1. Crear una vista de los productos que surte un poroveedor.
2. Una vista para los pagos de los clientes por cada venta a credito

b) Producto esperado: Dos tablas virtuales
c) Fecha inicio:
d) Fecha entrega:

Las sentencias deben de ser
entregadas en papel y deben
Vista 10 puntos
de ser corroboradas en SQL
Server 2000
Total 10 Puntos
Hay ocasiones en que tenemos que crear una consulta y después con los
valores obtenidos de esta consulta se realizan otras acciones, este problema
se puede solucionar con subconsultas, pero el que se utilicen Vistas nos da la
posibilidad de poder manejar los resultados de esa consulta como una tabla
virtual, precisamente esto se espera de este tema.
1.7.7. DOCUMENTOS
UNIDAD TEMATICA 2. INTEGRIDAD DE DATOS y MANEJO DE INDICES
INTEGRIDAD: consistencia o corrección de datos en la base de datos. Las

reglas de integridad (RI) no son específicas para cada usuario.
1. Nos interesan las reglas de integridad específicas de una BD (reglas

del negocio), además de RI Entidad, RI Referencial...
2. Veremos las RI definidas sobre relaciones base, por estar restringidas
a contener datos correctos (reflejar la realidad).
Veremos las RI definidas sobre relaciones base, por estar restringidas a

contener datos correctos (reflejar la realidad).
La regla “los títulos de las películas son únicos” se aplica a la tabla base
PELICULA, y a cualquier vista definida sobre ésta ¿Podemos definir RI sobre
relaciones derivadas (sobre vistas)?
 Sería deseable
 La vista heredaría toda RI de sus relaciones base y podría añadir
nuevas (clave candidata nueva para la vista, p.ej.)
Solo consideraremos RI sobre relaciones base (por simplicidad)

3. Nos interesa soporte de RI declarativo
No hablaremos de...
 Procedimientos almacenados (stored procedures), ni de
 Procedimientos disparados (triggered procedures)
4. Una BD en un estado de integridad es correcta si:

 No viola ninguna RI conocida por el SGBD, es decir, satisface AND
lógico de todas las RI definidas en su esquema.
5. La integridad es importante en...
 DISEÑO (estructuras de datos y reglas de integridad adecuadas)

 EJECUCIÓN (corrección de la información)
6. RI son mantenidas en el Catálogo del Sistema
El Subsistema de Integridad del SGBD:

 Controla operaciones de usuario (INSERT,UPDATE,DELETE...) para
asegurar que NO violan las reglas de integridad
COMPONENTES DE UNA REGLA DE INTEGRIDAD
A. Nombre
 Regla almacenada en el Catálogo del Sistema bajo ese nombre.
 Aparecerá en diagnósticos, producidos por el sistema como
respuesta a intentos de violación de la regla (mensajes de error al
usuario)
B. Restricción NOT EXISTS (SELECT * FROM ACTOR WHERE cache <= 0)

 Expresión booleana.
 La regla
o Se satisface, la restricción es TRUE
o Es violada, la restricción es FALSE
C. Respuesta a un intento de violación de la regla

 Indica al SGBD qué hacer si se intenta una operación que viola la RI
 Por defecto RECHAZAR (o rehusar) que implica...
o Deshacer los posibles daños causados por la operación
o Mostrar información de diagnóstico (mensaje)
 Podría ser un procedimiento de complejidad arbitraria: tratarErr(...)
CREACIÓN, DESTRUCCIÓN Y TIPOS DE REGLAS DE INTEGRIDAD
A. Creación de una regla de integridad... (en cualquier momento)

El SGBD comprueba: ¿el estado actual de la BD satisface RI?
 Sí RI aceptada
o El sistema la almacena en el catálogo
o La regla es activada (entra en vigor)
 SGBD controlará todo INSERT y UPDATE de caché
en ACTOR
 No RI rechazada
B. Destrucción de reglas de integridad
 El sistema elimina su definición del catálogo
Las RIs pueden restringir los valores legales de...

 Dominio
 Atributo
 Relación
 Base de Datos
2.1. TIPOS DE INTEGRIDAD DE DATOS

Conocer las diferentes formas de integridad de datos que existen, para evitar
por ejemplo redundancia de información o ausencia de la misma.
2.1.3. DESARROLLO
RESTRICCIONES, REGLAS, VALORES PREDETERMINADOS Y

DESENCADENADORES
Las columnas de tablas tienen otras propiedades además del tipo y el tamaño
de los datos. Estas propiedades forman una parte importante en la garantía de
la integridad de los datos de una base de datos.
 La integridad de los datos significa que todas las apariciones de una

columna tienen un valor de datos correcto.
Los valores de los datos tienen que ser del tipo de datos correcto y se
tienen que encontrar en el dominio definido.
 La integridad referencial indica que las relaciones entre las tablas se

tienen que mantener de la forma adecuada.
Los datos de una tabla sólo tienen que apuntar a filas existentes de otra
tabla; no pueden apuntar a filas inexistentes.
Los objetos que se utilizan para mantener ambos tipos de integridad son:
 Restricciones
 Reglas
 Valores predeterminados
 Desencadenadores
La integridad de los datos garantiza la calidad de los datos de la base de

datos. Por ejemplo, si se especifica para un empleado el valor de Clave de
Empleado = 123, la base de datos no debe permitir que ningún otro empleado
tenga el mismo valor de identificador. Si tiene una columna Sueldo para la que
se prevea valores entre el $1,500.00 y el $5,00.00 la base de datos no debe
aceptar el valor $6,000.00. Si en la tabla hay una columna NumDep en la que
se almacene el número de departamento del empleado, la base de datos sólo
debe permitir valores que correspondan a los números de departamento de la
compañía.
Dos pasos importantes en el diseño de las tablas son la identificación de

valores válidos para una columna y la determinación de cómo forzar la
integridad de los datos en la columna. Estas son las categorías de integridad
de datos:
 Integridad de entidad
 Integridad de dominio
 Integridad referencial
 Integridad definida por el usuario
Integridad de entidad
La integridad de entidad define una fila como entidad única para una tabla
determinada. La integridad de entidad fuerza la integridad de la columna o
columnas de los identificadores o la clave principal de una tabla (mediante
índices, restricciones UNIQUE, restricciones PRIMARY KEY o propiedades
IDENTITY).
Integridad de dominio
La integridad de dominio viene dada por la validez de las entradas para una
columna determinada. Puede forzar la integridad de dominio si restringe el tipo
(mediante tipos de datos), el formato (mediante las reglas y las restricciones
CHECK), o el intervalo de valores posibles (mediante restricciones FOREIGN
KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y
reglas).
Integridad referencial
La integridad referencial protege las relaciones definidas entre las tablas
cuando se crean o se eliminan registros. En Microsoft® SQL Server™, 2000 la
integridad referencial se basa en las relaciones entre claves externas y claves
principales o entre claves externas y claves exclusivas (mediante restricciones
FOREIGN KEY, restricciones CHECK). La integridad referencial garantiza que
los valores clave sean coherentes en las distintas tablas. Para conseguir esa
coherencia, es preciso que no haya referencias a valores inexistentes y que, si
cambia el valor de una clave, todas las referencias a ella se cambien en
consecuencia en toda la base de datos.
Cuando se fuerza la integridad referencial, SQL Server impide a los usuarios:
 Agregar registros a una tabla relacionada si no hay ningún registro

asociado en la tabla principal.
 Cambiar valores en una tabla principal de manera que queden registros

huérfanos en una tabla relacionada.
 Eliminar registros de una tabla principal cuando hay registros

relacionados coincidentes.
Por ejemplo, con las tablas Calificación y Alumno de la base de datos

ESCUELA, la integridad referencial se basa en la relación entre la clave
externa (Matricula) de la tabla Calificación y la clave principal (Matricula) de
la tabla Alumno.
Integridad definida por el usuario

La integridad definida por el usuario le permite definir reglas de la compañía
específicas que no pertenecen a ninguna otra categoría de integridad. Todas
las categorías de integridad son compatibles con la integridad definida por el
usuario (todas las restricciones en columnas y tablas de CREATE TABLE,
procedimientos almacenados y desencadenadores).
Ejemplo de una restricción CHECK
El sueldo de un Docente debe ser mayor que 1000 y menor a 5000.
CREATE TABLE Docente

(
Folio SMALLINT
IDENTITY(1,1)
PRIMARY KEY CLUSTERED,
Nombre VARCHAR(50) NOT NULL
DEFAULT 'xxx',
Sueldo FLOAT NOT NULL
CHECK (Sueldo >= 1000 AND Sueldo <=5000)
)
//explicacion de la restriccion
CREATE TABLE Docente
Crea la tabla Docente
Folio SMALLINT
IDENTITY(1,1)
PRIMARY KEY CLUSTERED,
Crea el campo Folio de tipo SMALLINT, IDENTITY crea una columna de
identidad en una tabla. Esta propiedad se utiliza con las instrucciones CREATE
TABLE y ALTER TABLE de Transact-SQL.
Sintaxis
IDENTITY [ ( seed , increment ) ]
Argumentos
seed
Es el valor que se utiliza para la primera fila cargada en la tabla.
Increment.
Se trata del valor incremental que se agrega al valor de identidad de la anterior
fila cargada.
Es necesario especificar la inicialización y el incremento, o no especificar
ninguno de los dos. Si no se especifica ninguno, el valor predeterminado es
(1,1).
PRIMARY KEY CLUSTERED es una restricción que exige la integridad de

entidad para una o varias columnas dadas a través de un índice único. Sólo se
puede crear una restricción PRIMARY KEY por cada tabla y CLUSTERED
indica que se ha creado un indice agrupo (En temas posteriores se vera el
tema de indices).
Nombre VARCHAR(50) NOT NULL

DEFAULT 'xxx',
Crea otro campo mas a la tabla que se llama Nombre el cual es de tipo
VARCHAR con 50 espacios, NOT NULL indica que el valor de este campo no
puede ser nulo, DEFAULT ‘xxx’ El valor por default que se le da al campo.
Sueldo FLOAT NOT NULL

CHECK (Sueldo >= 1000 AND Sueldo <=5000)
Crea otro campo que se llama Sueldo de tipo FLOTA no nulo,
CHECK(Sueldo >= 1000 AND Sueldo <=5000) indica que el valor de este
campo tendra que ser mayor o igual que 1000 y menor o igual que 5000, lo que
significa que esta institución no paga menos de 1000 y no paga mas de 5000.
INTEGRIDAD DE ENTIDAD
Restricciones UNIQUE
 Si no se especifica CLUSTERED o NONCLUSTERED para una restricción

UNIQUE, de forma predeterminada se utiliza NONCLUSTERED.
 Cada restricción UNIQUE genera un índice. El número de restricciones
UNIQUE no puede hacer que el número de índices de la tabla exceda de
249 índices no agrupados y 1 índice agrupado.
Utilizando la restricción UNIQUE (Me limitare en los siguientes ejemplos a solo

explicar el significado de las instrucciones nuevas...)
CREATE TABLE Empleado

(
Clave SMALLINT PRIMARY KEY,
Nombre VARCHAR(50) NOT NULL,
Puesto VARCHAR(15) NOT NULL UNIQUE
)
Puesto VARCHAR(15) NOT NULL UNIQUE, esta linea lo que provoca es que
el valor del campo Puesto no se repita. En este ejemplo tambien se realiza la
restricción PRIMARY KEY, la cual indica que el campo Clave es la llave de la
tabla Empleado.
INTEGRIDAD DE DOMINIO
Las definiciones DEFAULT se pueden:
 Crear cuando se crea la tabla, durante el proceso de definición de la

misma.
 Agregar a una tabla ya existente. Cada columna de una tabla puede

contener una sola definición DEFAULT.
 Modificar o eliminar, si ya existen definiciones DEFAULT. Por ejemplo,

puede modificar el valor que se inserta en una columna cuando no se
escribe ningún valor.
Nota Para modificar una definición DEFAULT mediante Transact-
SQL o SQL-DMO, antes deberá eliminar la definición DEFAULT
existente y, a continuación, volver a crearla con la nueva definición.
No se puede crear definiciones DEFAULT para columnas definidas con:
 Un tipo de datos timestamp.
 Una propiedad IDENTITY o ROWGUIDCOL.
 Una definición DEFAULT o un objeto DEFAULT ya existentes.
Nota El valor predeterminado debe ser compatible con el tipo de datos de la
columna a la que se aplica la definición DEFAULT. Por ejemplo, el valor
predeterminado para una columna int debe ser un número entero, no una
cadena de caracteres.
Cuando se agrega una definición DEFAULT a una columna existente en una
tabla, Microsoft® SQL Server™ 2000 aplica de forma predeterminada el nuevo
valor predeterminado sólo a las nuevas filas de datos que se agregan a la
tabla; los datos existentes que se insertan mediante la definición DEFAULT
anterior no se ven afectados. No obstante, cuando agregue una nueva columna
a una tabla ya existente, puede especificar que SQL Server inserte en la nueva
columna el valor predeterminado (especificado mediante la definición
DEFAULT) en vez de un valor NULL para las filas existentes en la tabla.
Cuando elimine una definición DEFAULT, SQL Server insertará un valor NULL
en vez del valor predeterminado si no se inserta ningún valor para las nuevas
filas de la columna. No obstante, no se realizan cambios en los datos
existentes en la tabla.
ALTER TABLE Secretaria

ADD ESTUDIO VARCHAR(20) DEFAULT 'Superior'
La instrucción anterior modifica la tebla Secretaria agregándole un campo mas

ESTUDIO de 20 caracteres, además por DEFAULT le coloca el valor de
„Superior‟.
INTEGRIDAD REFERENCIAL
La integridad referencial entre tablas se exige de forma predeterminada cuando

se crea una relación en el diagrama de base de datos. Una relación exigida
garantiza que cada valor especificado en una columna de clave externa
coincida con un valor existente en la columna de clave principal relacionada.
Restricciones FOREIGN KEY
 Cuando en la columna de una restricción FOREIGN KEY se introduce un

valor distinto de NULL, el valor debe existir en la columna a la que se hace
referencia; de lo contrario, se devuelve un mensaje de error de infracción de
clave externa.
 Las restricciones FOREIGN KEY se aplican a la columna anterior a menos

que se especifiquen columnas de origen.
 Las restricciones FOREIGN KEY sólo pueden hacer referencia a las tablas
de la misma base de datos en el mismo servidor. La integridad referencial
de las bases de datos cruzadas debe implementarse a través de
desencadenadores. Para obtener más información, consulte CREATE
TRIGGER.
 Las restricciones FOREIGN KEY pueden hacer referencia a otras columnas

de la misma tabla (una auto-referencia).
 La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de
columna puede enumerar sólo una columna de referencia, que debe tener
el mismo tipo de datos que la columna en la que se define la restricción.
 La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de

tabla debe tener el mismo número de columnas de referencia que el número
de columnas de la lista de columnas de restricción. El tipo de datos de cada
columna de referencia debe ser también el mismo que la columna
correspondiente de la lista de columnas.
 Es posible que no se pueda especificar CASCADE si una columna del tipo

timestamp forma parte de la clave externa o de la clave a la que se hace
referencia.
 Se puede combinar CASCADE y NO ACTION en tablas que tengan

relaciones referenciales entre sí. Si SQL Server encuentra NO ACTION,
termina y deshace las acciones CASCADE relacionadas. Cuando una
instrucción DELETE hace que se combinen acciones CASCADE y NO
ACTION, todas las acciones CASCADE se aplican antes de que SQL
Server compruebe si hay cláusulas NO ACTION.
 Una tabla puede contener un máximo de 253 restricciones FOREIGN KEY.
 Las restricciones FOREIGN KEY no se exigen en tablas temporales.
 Una tabla puede hacer referencia a un máximo de 253 tablas distintas en

sus restricciones FOREIGN KEY.
 Las restricciones FOREIGN KEY sólo pueden hacer referencia a las

columnas de las restricciones PRIMARY KEY o UNIQUE de la tabla de
referencia o a las columnas en UNIQUE INDEX de la tabla de referencia.
CREATE TABLE Secretaria

(
CvSecre SMALLINT PRIMARY KEY,
CvJefe SMALLINT
FOREIGN KEY (CvJefe) REFERENCES Empleado(Clave)
)
Este ejemplo, crea una tabla nueva la cual se llama Secretaria y tiene su
propia llave primaria, pero además crea el campo CvJefe el cual hace
referencia al campo Clave de la tabla Empleado creada en el ejemplo anterior.

A8-ER2 Examen Rápido
Formular 5 preguntas del tema de Tipos de Integridad de Datos y dictárselas a
los alumnos para que procedan a contestarlas.
c) Fecha inicio:
d) Fecha entrega:

Examen Rápido dictárselas a los alumnos para 5 puntos
que se respondan.
Total 5 Puntos

Repaso Rápido de los conceptos aprendidos.
2.1.7. DOCUMENTOS
2.2. USANDO RESTRICCIONES (CONSTRAINTS)
Entender algunas restricciones de SQL Server para declarar llaves, o
características especificas del campo de una tabla.
2.2.3. DESARROLLO
Es una palabra clave opcional que indica el principio de la definición de una

restricción PRIMARY KEY, NOT NULL, UNIQUE, FOREIGN KEY o CHECK.
Las restricciones son propiedades especiales que exigen la integridad de los
datos y pueden crear índices para la tabla y sus columnas.
constraint_name
Es el nombre de una restricción. Los nombres de restricción deben ser únicos

en una base de datos.
Ejemplo:
CREATE TABLE Departamento
CvDepto SMALLINT,
CONSTRAINT PK PRIMARY KEY (CvDepto)

A9-EC5 Restricciones CONSTRAINTS
Crear la tabla USUARIO con instrucciones SQL, a la cual se le colocan los
siguientes campos: NomUsuario(llave primaria), Contraseña(no nula), Nivel.

b) Producto esperado: Una tabla mas a la base de datos “ESQUINITA”
c) Fecha inicio:
d) Fecha entrega:

La tabla creada en la base de
Restricciones CONSTRAINTS 5 puntos
datos.
Total 5 puntos

Crear una tabla con instrucciones SQL y además agregarle ciertas restricciones
que van a darle mayor seguridad y evitar duplicaciones de información.
2.2.7. DOCUMENTOS
2.3. USANDO VALORES POR OMISIÓN Y REGLAS

Aplicar ciertas reglas de negocio desde el momento de creación de las tablas
de la base de datos.
2.3.3. DESARROLLO
CREATE RULE
Crea un objeto denominado regla. Cuando se enlaza una regla a una columna
o un tipo de datos definido por el usuario, la regla especifica los valores
aceptables que se pueden insertar en esa columna. Las reglas, que son una
característica de compatibilidad con versiones anteriores, realizan algunas de
las mismas funciones que las restricciones CHECK. Las restricciones CHECK,
creadas mediante la palabra clave CHECK de ALTER o CREATE TABLE, son
la forma preferida y estándar de restringir los valores de una columna (se
pueden definir restricciones múltiples en una o múltiples columnas). Una
columna o tipo de datos definido por el usuario sólo puede tener una regla
enlazada. Sin embargo, una columna puede tener una regla y una o más
restricciones CHECK asociadas a ella. Cuando esto es así, se evalúan todas
las restricciones.
Sintaxis
CREATE RULE rule
AS condition_expression
Argumentos
rule
Es el nombre de la nueva regla. Los nombres de reglas deben seguir las reglas
de los identificadores. Especificar el propietario de la regla es opcional.
condition_expression
Son las condiciones que definen la regla. Una regla puede ser cualquier
expresión válida en una cláusula WHERE y puede incluir elementos como
operadores aritméticos, operadores relacionales y predicados (por ejemplo, IN,
LIKE, BETWEEN). Una regla no puede hacer referencia a columnas u otros
objetos de base de datos. Se pueden incluir funciones integradas que no hagan
referencia a objetos de base de datos.
condition_expresión
Incluye una variable. El signo (@) precede a cada variable local. La expresión
hace referencia al valor que se introduce con la instrucción UPDATE o
INSERT. Se puede utilizar cualquier nombre o símbolo para representar el
valor cuando se crea la regla, pero el primer carácter debe ser @.
Observaciones
La instrucción CREATE RULE no puede combinarse con otras instrucciones
Transact-SQL en un único proceso por lotes. Las reglas no se aplican a los
datos ya existentes en la base de datos en el momento en que se crearon las
reglas y no se pueden enlazar a los tipos de datos del sistema. Una regla sólo
se puede crear en la base de datos actual. Una vez creada la regla, ejecute
sp_bindrule para enlazarla a una columna o a un tipo de datos definido por el
usuario.
La regla debe ser compatible con el tipo de datos de la columna. Una regla no
se puede enlazar a una columna text, image o timestamp. Asegúrese de
incluir las constantes de fecha y de caracteres entre comillas simples (') y de
preceder las constantes binarias con 0x. Por ejemplo, "@valor LIKE A%" no
se puede utilizar como regla para una columna numérica. Si la regla no es
compatible con la columna a la que se ha enlazado, Microsoft® SQL Server™
devuelve un mensaje de error cuando se inserta un valor, pero no cuando se
enlaza la regla.
Una regla enlazada a un tipo de datos definido por el usuario sólo se activa
cuando se intenta insertar un valor o actualizar una columna de la base de
datos del tipo de datos definido por el usuario. Como las reglas no prueban las
variables, no debe asignar un valor a una variable de tipo de datos definido por
el usuario que sería rechazada por una regla enlazada a una columna del
mismo tipo de datos.
Para obtener un informe de una regla, utilice sp_help. Para que se muestre el
texto de una regla, ejecute sp_helptext con el nombre de la regla como
parámetro. Para cambiar el nombre de una regla, utilice sp_rename.
Una regla debe quitarse (mediante DROP RULE) antes de crear otra con el
mismo nombre y debe cancelarse el enlace (mediante sp_unbindrule) antes
de quitarla. Utilice sp_unbindrule para cancelar el enlace de una regla a una
columna.
Una nueva regla se puede enlazar a una columna o tipo de datos sin cancelar
el enlace de la anterior; la nueva regla anula la anterior. Las reglas enlazadas a
columnas tienen siempre preferencia sobre las reglas enlazadas a tipos de
datos definidos por el usuario. Enlazar una regla a una columna substituye una
regla ya enlazada al tipo de datos definido por el usuario de esa columna. Pero
el enlace de una regla a un tipo de datos no substituye una regla enlazada a
una columna de ese tipo de datos definido por el usuario. La tabla muestra el
efecto que tiene precedencia cuando se enlazan reglas a columnas y a tipos de
datos definidos por el usuario en los que ya existen reglas.
Regla antigua del enlace
Nueva regla del enlace tipo de datos definido por Columna

el usuario
Tipo de datos definido por Regla antigua substituida Sin cambio
el usuario
Columna Regla antigua substituida Regla antigua

substituida
Si una columna tiene un valor predeterminado y una regla asociada a ella, el

valor predeterminado debe encontrarse en el dominio definido por la regla. Un
valor predeterminado que esté en conflicto con una regla no se inserta nunca.
SQL Server genera un mensaje de error cada vez que intenta insertar tal valor
predeterminado.
Nota El que SQL Server interprete una cadena vacía como un espacio simple
o como una verdadera cadena vacía se controla mediante el valor de
sp_dbcmptlevel. Si el nivel de compatibilidad es menor o igual que 65, SQL
Server interpreta las cadenas vacías como espacios simples. Si el nivel de
compatibilidad es igual a 70, SQL Server interpreta las cadenas vacías como
tales. Para obtener más información, consulte sp_dbcmptlevel.
Permisos
De forma predeterminada, los permisos CREATE RULE se conceden a los
miembros de la función fija de servidor sysadmin y a las funciones fijas de
base de datos db_ddladmin y db_owner. Los miembros de las funciones
sysadmin, db_owner y db_securityadmin pueden transferir los permisos a
otros usuarios.
Ejemplos
A. Regla con un intervalo
Este ejemplo crea una regla que restringe el intervalo de enteros que se
insertan en las columnas a las que la regla está enlazada.
CREATE RULE Valor AS

@Rango >=0 AND @Rango<=100
Se crea una regla que se llama Valor la cual evalua un rango de 0 a 100, esta
regla se le puede asignar al campo Cal de la tabla Calificación.
B. Regla con una lista
Este ejemplo crea una regla que restringe los valores reales que se escriben en
la columna o columnas a las que la regla está enlazada, a sólo aquéllos
enumerados en la regla.
CREATE RULE Puesto

AS
@Descripcion IN ('Director', 'Secretaria', 'Subdirector')
C. Regla con un patrón
Este ejemplo crea una regla que sigue un patrón de dos caracteres cualquiera
con un guión a continuación, cualquier número de caracteres (o no caracteres)
y un entero entre 0 y 9 al final.
CREATE RULE pattern_rule

AS
@value LIKE '_ _-%[0-9]'
A10-EC6 Valores por omision.
Crear una regla o utilizar una restricción CHECK para validar ciertas cuestiones
en los campos de la tabla.
1. De la tabla Cliente el campo RFCC validar que solo reciba 4 letras
seguido de 6 numeros y alfinal solo tres letras de la omoclave.
2. La misma regla para el campo RFCP de la tabla Proveedor

b) Producto esperado: Dos tablas con ciertas reglas o restricciones de
negocio aplicadas directamente a las tablas.
c) Fecha inicio:
d) Fecha entrega:
Checar en la base de datos
Valores por omision “ESQUINITA”, las 5 puntos
restricciones propuestas.
Total 5 Puntos

Entender que es una regla de negocio y como validarla desde la creación de la
base de datos.
2.3.7. DOCUMENTOS
2.4. INTRODUCCIÓN A INDICES

Aprender a manejar indices en las tablas de la base de datos.
2.4.2. RECURSOTIEMPO DEL TEMA 1 hora
2.4.3. DESARROLLO
CREAR UN ÍNDICE
Después de determinar el diseño, puede crear índices en las tablas de la base
de datos.
Microsoft® SQL Server™ 2000 crea automáticamente índices únicos para
exigir los requisitos de exclusividad de las restricciones PRIMARY KEY y
UNIQUE. A menos que ya exista un índice agrupado en la tabla o que se haya
especificado explícitamente un índice no agrupado, se creará un índice único,
agrupado, para exigir la restricción PRIMARY KEY. A menos que se
especifique explícitamente un índice agrupado, se creará de forma
predeterminada un índice único, no agrupado, para exigir la restricción
UNIQUE.
Si necesita crear un índice independiente de una restricción, puede utilizar la
instrucción CREATE INDEX. De forma predeterminada, se crea un índice no
agrupado si no se especifica la opción de agrupación.
Otras consideraciones que hay que tener en cuenta en el momento de crear un
índice incluyen:
 Sólo el propietario de la tabla puede crear índices en la misma tabla.
 Sólo se puede crear un índice agrupado por tabla.
 El número máximo de índices no agrupados que pueden crearse por

tabla es de 249 (incluidos los índices creados por restricciones
PRIMARY KEY o UNIQUE).
 El tamaño máximo de todas las columnas de longitud no variable que

abarca el índice es de 900 bytes. Por ejemplo, no se puede crear un solo
índice para las tres columnas definidas como char(300), char(300) y
char (301), ya que la suma total supera los 900 bytes.
 El número de columnas que puede abarcar el mismo índice es de 16,

como máximo.
Cuando cree índices con la instrucción CREATE INDEX, deberá especificar el

nombre del índice, de la tabla y de las columnas a las que se aplica el índice.
Los nuevos índices creados como parte de una restricción PRIMARY KEY o
UNIQUE, o bien mediante el Administrador corporativo de SQL Server, reciben
automáticamente nombres definidos por el sistema que se basan en el nombre
de la tabla de la base de datos. Si crea varios índices en una tabla, se adjuntan
los sufijos _1, _2, etc. a los nombres de los índices. Si es necesario, puede
cambiar el nombre del índice.
Nota No puede crear un índice en la base de datos actual si se está realizando

una copia de seguridad de la base de datos.
Si se crea un índice agrupado en una tabla con varios índices secundarios, se
deben volver a generar todos los índices secundarios de manera que
contengan el valor de clave de agrupación en lugar del identificador de fila
(RID). Asimismo, si se elimina un índice agrupado de una tabla con varios
índices no agrupados, se vuelven a generar todos los índices no agrupados
como parte de la operación DROP. Si las tablas son de gran tamaño, la
operación puede prolongarse significativamente.
La mejor manera de generar índices en tablas de gran tamaño es empezar con
el índice agrupado y, a continuación, generar los índices no agrupados. Al
quitar todos los índices, quite primero los índices no agrupados y después los
agrupados. De esta forma no es necesario volver a generar los índices.
Índices agrupados
Cuando cree un índice agrupado, se copiará la tabla, se ordenarán los datos de
la tabla y se eliminará la tabla original. Por lo tanto, debe haber suficiente
espacio vacío en la base de datos para que pueda realizarse una copia de los
datos.
De forma predeterminada, los datos de la tabla se ordenan cuando se crea el
índice. Sin embargo, si los datos están ordenados porque ya había un índice
agrupado y se vuelve a crear con el mismo nombre y las mismas columnas, la
operación de ordenación puede omitirse automáticamente si se vuelve a
generar el índice, en vez de crearlo de nuevo. Cuando se vuelve a generar el
índice, se comprueba que las filas estén ordenadas mientras se genera el
índice. Si las filas no están correctamente ordenadas, se cancelan las
operaciones y no se crea el índice.
Índices únicos
La creación de un índice único asegura que fracase cualquier intento de
duplicar valores clave. Si se crea una sola consulta que provoque la agregación
de valores de clave duplicados y no duplicados, SQL Server rechaza todas las
filas, incluidas las que tengan valores de clave no duplicados. Por ejemplo, si
una sola instrucción de inserción recupera 20 filas de la tabla A y las inserta en
la tabla B, pero 10 de esas filas contienen valores de clave duplicados, se
rechazarán las 20 filas de forma predeterminada. Sin embargo, se puede
especificar la cláusula IGNORE_DUP_KEY cuando se crea el índice; así, sólo
se rechazarán los valores de clave duplicados; los no duplicados se agregarán.
En el ejemplo anterior, sólo se rechazarían los 10 valores de clave duplicados;
los 10 valores no duplicados se insertarían en la tabla B.
No se puede crear un índice único si hay valores de la clave duplicados. Por
ejemplo, si desea crear un índice compuesto y único en las columnas a y b,
pero hay dos filas en la tabla que contienen los valores 1 y 2 para a y b
respectivamente, no se puede crear el índice único.
Nota No se puede crear un índice único en una sola columna si esa columna
contiene valores NULL en más de una fila. Tampoco se puede crear un índice
único en varias columnas si la combinación de columnas contiene valores
NULL en más de una fila. Estos valores se tratan como duplicados a efectos de
indización.
A11-I1 Investigacion de Indices
Realizar un trabajo de investigación que complemente el tema de indices.
b) Producto esperado: documento que avale la investigación.
c) Fecha inicio:
d) Fecha entrega:

Contenido de la investigación 4 puntos
Investigacion de Indices
Presentación del trabajo 1 punto
Total 5 puntos

Entender la importancia del manejo de indices en la optimizacion del tiempo en
las consultas a las tablas indexadas.
2.4.7. DOCUMENTOS
2.5. ARQUITECTURA y CREACIÓN DE INDICES

Aprender a crear indices en las tablas.
2.5.3. DESARROLLO
ARQUITECTURA DE TABLAS E ÍNDICES

Los objetos de una base de datos de Microsoft® SQL Server™ 2000 se
almacenan como una colección de páginas de 8 KB. Este tema describe el
modo en que se organizan las páginas de tablas e índices.
SQL Server 2000 admite índices en las vistas. El primer índice permitido en
una vista es un índice agrupado. En el momento en que se ejecuta una
instrucción CREATE INDEX en una vista, el conjunto de resultados para la
vista se materializa y almacena en la base de datos con la misma estructura
que una tabla que tiene un índice agrupado. El conjunto de resultados que se
almacena es el mismo que produce esta instrucción.
SELECT * FROM Nombre_Vista
Las filas de datos para cada tabla o vista indizada se almacenan en una
colección de páginas de datos de 8 KB. Cada página de datos dispone de una
cabecera de 96 bytes que contiene información del sistema como el
identificador (Id.) de la tabla que es propietaria de la página. La cabecera de
página también incluye punteros a las páginas anteriores y siguientes que se
utilizan si las páginas se vinculan a una lista. Al final de la página se encuentra
una tabla de desplazamiento de filas. Las filas de datos ocupan el resto de la
página.
Organización de páginas de datos
Las tablas de SQL Server 2000 utilizan uno de estos dos métodos para
organizar sus páginas de datos:
 Las tablas agrupadas son tablas que tienen un índice agrupado.
Las filas de datos están almacenadas en un orden basado en la clave

del índice agrupado. El índice se implementa como una estructura de
árbol B que admite la rápida recuperación de las filas a partir de los
valores de claves del índice agrupado. Las páginas de cada nivel del
índice, incluidas las páginas de datos del nivel de hoja, se vinculan en
una lista con vínculos dobles, pero la navegación de uno a otro nivel se
produce mediante valores de clave.
 Los montones son tablas que no tienen un índice agrupado.
Las filas de datos no están almacenadas en ningún orden particular ni

tampoco hay un orden particular en la secuencia de las páginas de
datos. Las páginas de datos no están vinculadas en una lista vinculada.
Las vistas indizadas tienen la misma estructura de almacenamiento que las

tablas agrupadas.
SQL Server admite también hasta 249 índices no agrupados en cada vista de
tabla o índice. Los índices no agrupados tienen una estructura de árbol B
similar a la de los índices agrupados. La diferencia está en que los índices no
agrupados no tienen ningún efecto en el orden de las filas de datos. Las tablas
agrupadas y las vistas indizadas mantienen sus filas de datos en orden de
acuerdo con la clave del índice agrupado. La colección de páginas de datos de
un montón no se ve afectada cuando se definen índices no agrupados en la
tabla. Las páginas de datos permanecen en un montón a menos que se defina
un índice agrupado.
Las páginas que almacenan datos text, ntext e image se administran como
una única unidad por cada tabla. Todos los datos text, ntext e image de una
tabla están almacenados en una colección de páginas.
Todas las colecciones de páginas para tablas, índices y vistas indizadas están
delimitadas por punteros de página en la tabla sysindexes. Cada tabla y vista
indizada tiene una colección de páginas de datos, además de colecciones
adicionales de páginas para implementar cada índice definido para la tabla o
vista.
Cada tabla, índice y vista indizada tiene una fila en sysindexes identificada de
manera exclusiva por la combinación de la columna del identificador del objeto
(id) y la columna del identificador del índice (indid). La asignación de páginas a
tablas, índices y vistas indizadas se administra mediante una cadena de
páginas IAM. La columna sysindexes.FirstIAM apunta a la primera página
IAM de la cadena de páginas IAM que administran el espacio asignado a la
tabla, índice o vista indizada.
Cada tabla tiene un conjunto de filas en sysindexes:
 Un montón tiene una fila en sysindexes con indid = 0.
La columna FirstIAM apunta a la cadena IAM de la colección de páginas

de datos de la tabla. El servidor utiliza las páginas IAM para buscar las
páginas en la colección de páginas de datos, puesto que no están
vinculadas.
 Un índice agrupado en una tabla o vista tiene una fila en sysindexes

con indid = 1.
La columna root apunta a la parte superior del árbol B del índice

agrupado. El servidor utiliza el árbol B del índice para buscar las páginas
de datos.
 Cada índice no agrupado creado para una tabla o una vista tiene una fila
en sysindexes.
Los valores de indid de las filas de los índices no agrupados se
encuentran entre 2 y 250. La columna root apunta al nodo superior del
árbol B del índice no agrupado.
 Todas las tablas que tengan al menos una columna text, ntext o image
también tienen una fila en sysindexes, con indid = 255.
La columna FirstIAM apunta a la cadena de páginas IAM que administra

las páginas text, ntext e image.
En SQL Server 6.5 y anterior, sysindexes.first apunta siempre al inicio de un

montón, al inicio del nivel de hoja de un índice, o al inicio de una cadena de
páginas text e image. En SQL Server 7.0 y posterior, no se suele utilizar
sysindexes.first. En SQL Server 6.5 y anterior, sysindexes.root en una fila
con indid = 0 apunta a la última página de un montón. En SQL Server 7.0 y
posterior, no se utiliza sysindexes.root en una fila con indid = 0.
Por ejemplo:
CREACIÓN DE INDICE
Estas instrucciones crean un indice a la tabla Calificacion, para el campo de
Cal.
USE ESCUELA
CREATE INDEX IndCal
ON Calificacion (Cal)
ELIMINACIÓN DE INDICE
USE ESCUELA
DROP INDEX Calificacion.IndCal

A12-EC7 Crear Indices
Crear indices compuestos en las tablas de VtaProd(Clave Venta y Clave
Producto) y CpaProd(Clave Compra y Clave Producto)

b) Producto esperado: Tablas indexadas
c) Fecha inicio:
d) Fecha entrega:
f) Tipo de Actividad: Equipo(3 gentes)

Checar las tablas que
Crear Indices efectivamente tengan los 5 puntos
indices indicados.
Total 5 Puntos

Manejo de indices
2.5.7. DOCUMENTOS
UNIDAD TEMATICA 3. TRANSACCIONES EN LA BASE DE DATOS
Entre las habilidades de todo Sistema Gestor de Bases de Datos Relaciones

tiene que estar la de permitir al programador crear transacciones. El SQL
Server nos permite trabajar con transacciones de manera sencilla y eficaz.
Una transacción es una unidad lógica de trabajo o procesamiento: ejecución de
un programa que incluye operaciones de acceso a la base de datos (en
adelante, BD).
Una transacción es una secuencia de operaciones que llevan la base de datos
desde un estado de consistencia1 a otro estado de consistencia, por esto suele
decirse también que la transacción es una unidad lógica de integridad.
Cuando múltiples transacciones son introducidas en el sistema por varios
usuarios, es necesario evitar que interfieran entre ellas de forma tal que
provoquen que la BD quede en un estado no consistente; desde este punto de
vista, podemos ver una transacción como una unidad lógica de concurrencia.
Si ocurre un fallo que provoca la caída del sistema de bases de datos, cuando
había varias transacciones en curso de ejecución, muy probablemente los
datos en la BD quedarán erróneos (estado inconsistente debido a un fallo); en
estas circunstancias, se debe garantizar que la BD pueda ser recuperada a un
estado en el cual su contenido sea consistente, observando las transacciones
que terminaron su ejecución y las que quedaron a medio; por esto una
transacción es considerada también una unidad lógica de recuperación.
3.1. PROCESAMIENTO DE TRANSACCIONES

Entender la finalidad de las Transacciones
3.1.2. RECURSOTIEMPO DEL TEMA ½ horas
3.1.3. DESARROLLO
La idea clave es que una transacción debe ser atómica, es decir, las
operaciones que la componen deben ser ejecutadas en su totalidad o no ser
ejecutadas en absoluto.
Una sentencia de definición o manipulación de datos ejecutada de forma
interactiva (por ejemplo utilizar el SQL * Plus de Oracle para realizar una
consulta) puede suponer el inicio de una transacción.
Asimismo, la ejecución de una sentencia SQL por parte de un programa que no
tiene ya una transacción en progreso, supone la iniciación de una transacción.
Toda transacción finaliza con una operación de COMMIT (confirmar) o bien con
una operación de ROLLBACK (anular, abortar o revertir).
1
El conjunto de valores almacenados en la base de datos cumple toda restricción de integridad especificada en el
esquema, así como cualesquiera otras restricciones que deban cumplirse en la base de datos.
Tanto una operación como la otra puede ser de tipo explícito (si la propia
transacción (su código) contiene una sentencia COMMIT o ROLLBACK) o
implícito (si dicha operación es realizada por el sistema de forma automática,
por ejemplo tras detectar una terminación normal (éxito) o anormal (fallo) de la
transacción).
Por defecto, una vez finalizada una transacción, si todas sus operaciones se
han realizado con éxito, se realiza un COMMIT implícito de dicha transacción; y
si alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implícito de
la transacción (es decir, se deshacen todas las operaciones que había
realizado hasta el momento del fallo).
A13-T3 Cuestionario transacciones.
a) Valor actividad: 2.5 Puntos
c) Fecha inicio:
d) Fecha entrega:

Cuestionario transacciones 2.5 puntos
de transmitir hacia asu
compañeros
Total 2.5 Puntos

Entender la funcion y ventajas de las transacciones en una base de datos
3.1.7. DOCUMENTOS
3.2. CONCEPTOS DE TRANSACCIONES
Saber que es una transacción y en que casos se pueden utilizar
3.2.2. RECURSO TIEMPO DEL TEMA ½ hora
3.2.3. DESARROLLO
Una transacción es un conjunto de operaciones que van a ser tratadas como

una única unidad. Estas transacciones deben cumplir 4 propiedades
fundamentales comúnmente conocidas como ACID (atomicidad, coherencia,
asilamiento y durabilidad).
La transacción más simple en SQL Server es una única sentencia SQL. Por
ejemplo una sentencia como esta:
UPDATE Products SET UnitPrice=20 WHERE ProductName =‟Chai‟

Es una transacción.
Esta es una transacción „AUTOCOMMIT‟, una transacción autocompletada.

Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de
transacciones lo que va a ocurrir y a continuación realiza los cambios
necesarios en la base de datos. Si hay algún tipo de problema al hacer esta
operación el SQL Server puede leer en el fichero de transacciones lo que se
estaba haciendo y si es necesario puede devolver la base de datos al estado
en el que se encontraba antes de recibir la sentencia.
Por supuesto este tipo de transacciones no requieren de nuestra intervención
puesto que el sistema se encarga de todo. Sin embargo si hay que realizar
varias operaciones y queremos que sean tratadas como una unidad tenemos
que crear esas transacciones de manera explícita.
3.3. PROPIEDADES DE LAS TRANSACCIONES

Conocer cuales son las características especificas de las transacciones.
3.3.3. DESARROLLO
Se suele hacer referencia a estas como las propiedades ACID (por sus iniciales
en inglés).
1. Atomicidad
Todas las operaciones de la transacción son ejecutadas por completo, o no se

ejecuta ninguna de ellas (si se ejecuta la transacción, se hace hasta el final).
2. Consistencia
Una transacción T transforma un estado consistente de la base de datos en

otro estado consistente, aunque T no tiene por qué preservar la consistencia en
todos los puntos intermedios de su ejecución. Un ejemplo es el de la
transferencia de una cantidad de dinero entre dos cuentas bancarias.
3. Aislamiento (Isolation)
Una transacción está aislada del resto de transacciones.

Aunque existan muchas transacciones ejecutándose a la vez, cualquier
modificación de datos que realice T está oculta para el resto de transacciones
hasta que T sea confirmada (realiza COMMIT).
Es decir, para cualesquiera T1 y T2, se cumple que:
- T1 ve las actualizaciones de T2 después de que T2 realice COMMIT, o bien

- T2 ve las modificaciones de T1, después de que T1 haga un COMMIT
Pero nunca se cumplen ambas cosas al mismo tiempo.

Nota: esta propiedad puede no imponerse de forma estricta 2; de hecho, suelen
definirse niveles de aislamiento de las transacciones.
4. Durabilidad
Una vez que se confirma una transacción, sus actualizaciones sobreviven

cualquier fallo del sistema.
Las modificaciones ya no se pierden, aunque el sistema falle justo después de
realizar dicha confirmación.
A14-ER3 Examen Rápido.
Formular 5 preguntas de los dos temas anteriores y dictárselas a los alumnos
para que ñas contesten.
c) Fecha inicio:
d) Fecha entrega:

Examen Rápido Constestar las preguntas 5 puntos
Total 5 Puntos

Comprobar que los alumnos están captando la importancia de las
transacciones en una base de datos.
2
Aunque lo estudiaremos en el tema de Recuperación de Caídas en Sistemas de Base de Datos, si se impone de
forma estricta el aislamiento de las transacciones, se resuelve el problema de la actualización temporal y no es
necesario realizar reversiones en cascada.
3.3.7. DOCUMENTOS
3.4. PLANES Y RECUPERABILIDAD

Proponer la forma mas adecuada de
3.4.2. RECURSOTIEMPO DEL TEMA
3.4.3. DESARROLLO
El Subsistema de Recuperación del SGBD es el encargado de conseguir el

cumplimiento de las propiedades de atomicidad y durabilidad de las
transacciones.
La conservación de la consistencia es una propiedad cuyo cumplimiento han de
asegurar, por un lado los programadores de base de datos, y por otro el
Subsistema de Integridad del SGBD.
El Subsistema de Control de Concurrencia es el encargado de conseguir el
aislamiento de las transacciones.
Para hacer posible el control de la concurrencia de las transacciones, así como
la recuperación del sistema tras fallos o caídas del mismo, es necesario
almacenar cuándo se inicia, termina, se confirma o se aborta cada transacción,
y además qué modificaciones de qué elementos de BD realiza cada una.
 INICIO DE TRANSACCIÓN
Operación que marca el momento en el que una transacción comienza a
ejecutarse. En un entorno SQL, esta operación «es implicada» de forma
implícita por la primera sentencia SQL que se ejecuta dentro de una
transacción.
 LEER o ESCRIBIR
Operaciones de lectura/escritura de elementos de la base de datos, que se
realizan como parte de una transacción.
 FIN DE TRANSACCIÓN
Las operaciones de LEER y ESCRIBIR han terminado. En este punto se
verifica si la transacción debe abortarse por alguna razón (si viola el control de
concurrencia, por ejemplo), o bien si los cambios realizados por la transacción
(hasta ahora en búfers de memoria volátil) pueden aplicarse permanentemente
a la base de datos en disco (es decir, si puede realizarse una operación de
CONFIRMAR).
 CONFIRMAR (COMMIT)
La transacción terminó con éxito, todos los cambios que ha realizado se
pueden confirmar sin peligro en la BD y ya no serán cancelados.
 ABORTAR (ROLLBACK)
La transacción terminó sin éxito y toda actualización que ha realizado se debe
cancelar.
Algunas técnicas de recuperación necesitan operaciones adicionales como las
siguientes:
 DESHACER
Similar a ABORTAR, pero se aplica a una sola operación y no a una
transacción completa.
 REHACER
Especifica que algunas de las operaciones realizadas por una transacción
deben repetirse, para asegurar que todas las operaciones realizadas por una
transacción que ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es
decir, los cambios hayan quedado grabados físicamente en disco).
3.5. SERIABILIDAD DE PLANES

Proponer un plan de recuperación de información a traves te transacciones.
3.5.3. DESARROLLO
ESTADOS DE UNA TRANSACCIÓN

El siguiente es el diagrama de transición de estados para la ejecución de
transacciones:
Una transacción entra en el estado ACTIVA justo después de iniciar su

ejecución y, en este estado, puede realizar operaciones LEER y ESCRIBIR.
Cuando la transacción finaliza, pasa al estado PARCIALMENTE
CONFIRMADA. En este punto, el Subsistema de Control de Concurrencia
puede efectuar verificaciones para asegurar que la transacción no interfiera con
otras transacciones en ejecución. Además, el Subsistema de Recuperación
puede anotar, en un fichero del sistema (bitácora), qué operaciones (qué
cambios) ha realizado la transacción, con el objetivo de garantizar que los
cambios realizados por la transacción terminada queden permanentes, a pesar
de fallos del sistema.
Una vez realizadas con éxito ambas verificaciones, la transacción ha llegado a
su punto de confirmación y pasa al estado CONFIRMADA (ha concluido su
ejecución con éxito).
Si una de las verificaciones falla o la transacción se aborta mientras está en
estado ACTIVA, pasa al estado FALLIDA. En este caso, es posible que la
transacción deba ser cancelada (anulada, revertida, abortada) para anular los
efectos de sus operaciones ESCRIBIR sobre la BD.
El estado TERMINADA indica que la transacción ha abandonado el sistema.
Las transacciones fallidas (abortadas) pueden ser reiniciadas posteriormente,
ya sea de forma automática por parte del sistema, o bien sea el usuario el que
las reintroduzca como si fueran nuevas transacciones.
Protocolos de bloqueo en dos fases
 Transacción dos fases: bloquea primero todos los gránulos, ejecuta
operaciones y luego desbloquea todos.
 Toda ejecución completa de un conjunto de transacciones con protocolo de
bloqueo en dos fases es serializable.
 En bloqueo en dos fases limita la cantidad de concurrencia al realizar
bloqueos tempranos y liberaciones tardías de recursos.
 Variaciones del bloqueo en dos fases
o Bloqueo básico
o Bloqueo conservativo o estático --> bloquea antes de comenzar
o Bloqueo estricto --> desbloquea después de terminar totalmente
Problemas derivados del uso de bloqueos

 Interbloqueo (deadlock)
o Imposibilidad de realizar simultáneamente dos operaciones no
compatibles sobre el mismo gránulo
o Dos o más transacciones quedan en espera de un recurso
 Esperada indefinida (livelock)
o Una transacción no entra mientras exista otra
 Inanición (starvation)
o El módulo controlador siempre mata a la misma
o Transacción para resolver un interbloqueo

A15-T4 Cuestionario planes.
a) Valor actividad: 2.5 Puntos
c) Fecha inicio:
d) Fecha entrega:

Cuestionario planes 2.5 puntos
compañeros
Total 2.5 Puntos

Repasar ciertas características de las transacciones
3.5.7. DOCUMENTOS
3.6. TRANSACCIONES SQL

Aprender a crear transacciones en una base de datos.
3.6.3. DESARROLLO
Como decíamos una transacción es un conjunto de operaciones tratadas como

una sola. Este conjunto de operaciones debe marcarse como transacción para
que todas las operaciones que la conforman tengan éxito o todas fracasen.
La sentencia que se utiliza para indicar el comienzo de una transacción es
„BEGIN TRAN‟.
Si alguna de las operaciones de una transacción falla hay que deshacer la
transacción en su totalidad para volver al estado inicial en el que estaba la base
de datos antes de empezar. Esto se consigue con la sentencia „ROLLBACK
TRAN‟.
Si todas las operaciones de una transacción se completan con éxito hay que
marcar el fin de una transacción para que la base de datos vuelva a estar en un
estado consistente con la sentencia „COMMIT TRAN‟.
Un ejemplo
Trabajaremos con la base de datos ESCUELA en nuestros ejemplos.
Vamos a realizar una transacción que modifica las calificaciones de dos

alumnos de la base de datos.
USE ESCUELA
DECLARE @ERROR int
BEGIN TRAN
UPDATE Calificacion SET Cal = 90 WHERE Matricula= 2004001 AND CvMat = 100
SET @ERROR=@@ERROR
IF (@ERROR<>0) GOTO TratarError
SET @ERROR=@@ERROR
COMMIT TRAN
TratarError:
IF @@ERROR<>0
BEGIN
PRINT „Ha recorrido un ERROR. Abortamos la transacción‟
ROLLBACK TRAN
END
USE ESCUELA
DECLARE @ERROR int
Declaramos una variable que utilizaremos para almacenar un posible código de

ERROR.
BEGIN TRAN
Iniciamos la transacción
Ejecutamos la primera sentencia
SET @ERROR=@@ERROR
Si ocurre un ERROR almacenamos su código en @ERROR y saltamos al trozo

de código que deshará la transacción. Si, eso de ahí es un GOTO, el demonio
de los programadores, pero no pasa nada por usarlo cuando es necesario
Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
SET @ERROR=@@ERROR
Y si hay un ERROR hacemos como antes
Si llegamos hasta aquí es que los dos UPDATE se han completado con éxito y
podemos "guardar" la transacción en la base de datos.
COMMIT TRAN
TratarError:
Si ha ocurrido algún ERROR llegamos hasta aquí

IF @@ERROR<>0
BEGIN
PRINT „Ha recorrido un ERROR. Abortamos la transacción‟
Se lo comunicamos al usuario y deshacemos la transacción

todo volverá a estar como si nada hubiera ocurrido
ROLLBACK TRAN
END
Como se puede ver para cada sentencia que se ejecuta miramos si se ha

producido o no un ERROR, y si detectamos un ERROR ejecutamos el bloque
de código que deshace la transacción.
Hay una interpretación incorrecta en cuanto al funcionamiento de las
transacciones que esta bastante extendida. Mucha gente cree que si tenemos
varias sentencias dentro de una transacción y una de ellas falla, la transacción
se aborta en su totalidad.
¡Nada más lejos de la realidad!
Si tenemos dos sentencias dentro de una transacción.
USE ESCUELA
BEGIN TRAN
UPDATE Calificacion SET Cal=85 WHERE Matricula=2004001 AND CvMat= 100
UPDATE Calificacion SET Cal=85 WHERE Matricula=2004001 AND CvMat= 100
COMMIT TRAN
Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de
la transacción (después del primer UPDATE y antes del segundo) hay un corte
de electricidad, cuando el SQL Server se recupere se encontrará en medio de
una transacción y, o bien la termina o bien la deshace, pero no se quedará a
medias.
El ERROR está en pensar que si la ejecución de la primera sentencia da un
ERROR se cancelará la transacción. El SQL Server sólo se preocupa de
ejecutar las sentencias, no de averiguar si lo hacen correctamente o si la lógica
de la transacción es correcta. Eso es cosa nuestra.
Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro
conjunto averiguamos si se ha producido un ERROR y si es así actuamos en
consecuencia cancelando toda la operación.
TRANSACCIONES ANIDADAS
Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones
anidadas.
Esto quiere decir que podemos tener transacciones dentro de transacciones, es

decir, podemos empezar una nueva transacción sin haber terminado la
anterior.
Asociada a esta idea de anidamiento existe una variable global
@@TRANCOUNT que tiene valor 0 si no existe ningún nivel de anidamiento, 1
si hay una transacción anidada, 2 si estamos en el segundo nivel de

anidamiento… y así sucesivamente.
La dificultad de trabajar con transacciones anidadas está en el comportamiento
que tienen ahora las sentencias „COMMIT TRAN‟ y „ROLLBACK TRAN‟
ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia

deshace todas las transacciones internas hasta la instrucción BEGIN
TRANSACTION más externa.
COMMIT TRAN: Dentro de una transacción anidada esta sentencia únicamente
reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza" ninguna
transacción ni "guarda" los cambios. En el caso en el que @@TRANCOUNT=1

(cuando estamos en la última transacción) COMMIT TRAN hace que todas las
modificaciones efectuadas sobre los datos desde el inicio de la transacción
sean parte permanente de la base de datos, libera los recursos mantenidos por
la conexión y reduce @@TRANCOUNT a 0.

Como siempre un ejemplo es lo mejor para entender como funciona.
BEGIN TRAN TranExterna
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Calificacion VALUES (2004001, 300, 90)
BEGIN TRAN TranInterna1
COMMIT TRAN TranInterna2
COMMIT TRAN TranExterna
SELECT * FROM Calificacion
@@TRANCOUNT ahora es 1
@@TRANCOUNT ahora es 2.
Reduce @@TRANCOUNT a 2.
Pero no se guarda nada en la base de datos.
Pero no se guarda nada en la base de datos.
COMMIT TRAN TranExterna
Se lleva a cabo la transacción externa y todo lo que conlleva.

Por cierto que lo de usar nombre para las transacciones es por claridad, puesto
que COMMIT TRAN como ya hemos dicho solamente reduce en 1 el valor de
@@TRANCOUNT.
Veamos ahora un ejemplo de transacción anidada con ROLLBACK TRAN
@@TRANCOUNT ahora es 1

ROLLBACK TRAN
@@TRANCOUNT es 0 y se deshace la transacción externa y todas las

internas.
En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace

todas las transacciones dentro de nuestro anidamiento hasta la transacción
más externa y además hace @@TRANCOUNT=0
¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un

problema?
Pues la verdad es que no. La manera de tratar las transacciones por el SQL
Server es la que nos permite programar de manera natural los anidamientos.
De todos modos, si queremos ir un poco más lejos hay una cuarta sentencia
para trabajar con transacciones: SAVE TRAN
SAVE TRAN
Esta sentencia crea un punto de almacenamiento dentro de una transacción.
Esta marca sirve para deshacer una transacción en curso sólo hasta ese punto.
Por supuesto nuestra transacción debe continuar y terminar con un COMMIN

TRAN (o los que hagan falta) para que todo se guarde o con un ROLLBACK
TRAN para volver al estado previo al primer BEGIN TRAN.
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1

INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SAVE TRAN Guardada
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.
--Ahora podemos decidir si la transacción se lleva a cabo
--o se deshace completamente
--Para deshacerla un ROLLBACK bastará como hemos visto
--Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 2.
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
-- Pero no se guarda nada en la base de datos.
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
-- Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT * FROM Test
Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un

ROLLBACK TRAN se deshace la transacción más externa y
@@TRANCOUNT se pone a 0.
Como podemos ver el uso de transacciones no es complicado, e incluso las

transacciones anidadas si se tratan con cuidado son fáciles de manejar. Como
siempre si hay alguna duda la mejor fuente de ejemplos y soluciones son los
BOL del SQL Server.

A16-EC8 Transacciones.
Realizar las siguientes transacciones en la base de datos “ESQUINITA”:
1. No permitir vender si no hay suficientes productos en existencias.
2. al momento de comprar productos aumentar las existencias de
productos.
3. Realizar un pago de un cliente, se debe insertar un pago nuevo mas
aparte actualizar el campo de Resto de la tabla VentaC
4. Eliminar producto (no se permite mientras haya alguna venta a credito
para este producto)
b) Producto esperado: Cuatro operaciones basicas para las base de
datos hechas almacenadas.
c) Fecha inicio:
d) Fecha entrega:

Verificar que todas las
transacciones funcionen
Transacciones dentro de la base de datos. 10 puntos
Deben de ser entregadas en
papel.
Total 10 Puntos

Validar ciertas reglas de integridad, para evitar inconsistencia de la
información.
3.6.7. DOCUMENTOS
UNIDAD TEMATICA 4. SEGURIDAD

Una base de datos debe tener un sistema de seguridad sólido para controlar
qué actividades se pueden realizar y qué información se puede ver y modificar.
Un sistema de seguridad sólido garantiza la protección de los datos,
independientemente de la manera en que los usuarios tienen acceso a la base
de datos.
4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS

Saber controlar algunos aspectos mas importantes de la seguridad que SQL
Server 2000 ofrece.
4.1.3. DESARROLLO
Las Bases de Datos (BDs) incluidas hoy en día en los sistemas de información
de cualquier organización, nacen con el fin de resolver las limitaciones que en
algunos casos presentan los ficheros para el almacenamiento de información.
En los entornos de Bases de Datos, las diferentes aplicaciones y usuarios
utilizan un único conjunto de datos integrado a través de un Sistema de Gestión
de Bases de Datos (SGBD). De esta forma se pueden resolver problemas
como duplicación de información, inconsistencia de los datos y dependencia
entre programa y estructura de datos. Por otra parte, la agrupación de datos
pertenecientes a distintos usuarios y catalogados en niveles de seguridad
diferentes aumenta los riesgos en cuanto a la seguridad de los datos. El
sistema de BD debe controlar si está autorizada cada operación sobre la BD.
Para conseguir un entorno de BD seguro se han de identificar las amenazas
reales, elegir las políticas de seguridad adecuadas que establezcan
mecanismos de prevención así como métodos que comprueben que no se han
producido accesos ilícitos.
Las BDs que contienen información sobre datos financieros son un blanco
tentador para los ladrones. Asímismo, las BDs que contienen información
referentes a las operaciones de una compañía pueden ser de interés para sus
competidores sin escrúpulos. También existen BD que por su contenido
personal deben ser mantenidas en estricto secreto. Por otra parte, la pérdida
de operatividad del SGBD o de información de sus BDs es un problema que
afecta muy seriamente al funcionamiento de una compañía.
Una amenaza contra la seguridad de las BDs es un agente hostil que puede
difundir o modificar información gestionada por el SGBD sin la debida
autorización. Las amenazas contra la seguridad se clasifican en accidentales y
fraudulentas. Las primeras son consecuencia de accidentes, errores de
hardware o software y fallos humanos, mientras que las segundas son
realizadas intencionadamente por usuarios no autorizados o agentes hostiles.
Las violaciones que puede sufrir un entorno de BD consisten en lecturas,
modificaciones y borrado de datos. Las consecuencias de estas violaciones
son: difusión de información confidencial, modificación no autorizada de datos e
incluso denegación de servicio a usuarios.
A continuación se estudian dos aspectos de seguridad que afectan
particularmente a las BDs como son la deducción ilícita de información
confidencial a partir de información accesible y vulneraciones de la integridad
de sus datos. También se enumeran otros aspectos de seguridad importantes a
tener en cuenta en un SGBD.3
Inferencia
Las vulneraciones en un SGBD debidas a la inferencia permiten deducir
información confidencial de la BD. Por ejemplo, cuando en una BD tenemos
dos campos relacionados por una función matemática siendo uno accesible y el
otro secreto, si el atacante conoce la relación podrá hacerse fácilmente con los
datos secretos. También se considera inferencia cuando se reduce el nivel de
incertidumbre sobre ciertos datos. Por ejemplo, si se pretende mantener en
secreto donde va el jet privado del presidente y en la BD que gestiona los
vuelos gubernamentales aparece el número de litros de combustible que se
han cargado en el avión podremos, con un sencillo cálculo, acotar los lugares a
3
http://www.sc.ehu.es/jiwibmaj/ApuntesCastellano/TEMA_9-bd.pdf (02/08/05)
los que puede ir. La inferencia de información secreta se puede realizar
aplicando únicamente el sentido común, o utilizando información auxiliar.
Agregación
Agregación consiste en el proceso de combinar múltiples objetos de una BD en
un objeto con un nivel de seguridad mayor que sus partes. Si se toman objetos
de tipos diferentes se llama agregación inferencial, si se combinan objetos del
mismo tipo se denomina agregación cardinal. Los dos tipos precisan de
diferente forma de prevención.
Integridad de la BD
La integridad de las BDs es un tema ampliamente tratado en la literatura de
BDs. Las vulneraciones de la integridad de la BD permiten la modificación,
adición o borrado de información de la BD. La integridad se debe garantizar
también frente a errores del sistema, virus y sabotajes que puedan dañar los
datos almacenados. Este tipo de protección se consigue mediante controles del
sistema apropiados, procedimientos de respaldo y recuperación y también
mediante procedimientos de seguridad ad hoc4.
En general podemos diferenciar dos peligros que requieren tratamientos
diferentes. Por una parte tenemos el problema de la consistencia de los datos
debido a errores en el sistema y por otra los usuarios que pretenden realizar
modificaciones no autorizadas en la BD.
EL SGBD debe mantener la consistencia de los datos incluidos en la BD frente
a peligros como la caída del sistema, bloqueo mutuo entre procesos que
realizan accesos concurrentes, etc. Los accesos para realizar modificaciones
en la BD son tareas delicadas que la puede dejar inconsistente. Por ejemplo, si
mientras se está modificando un registro de la BD hay un corte de fluido
eléctrico, no podremos estar seguros de que se habrá quedado grabado en la
BD. Para mantener la consistencia, la SGBD trabaja con transacciones, que
son unidades de programa que realizan una única función lógica en una
aplicación de la BD.
4
Procedimientos almacenados del sistema que permiten la supervisión
Las transacciones deben cumplir dos requisitos: (1) ser atómicas, esto es,
todos las operaciones asociadas a una transacción deben ejecutarse por
completo o ninguna de ellas, y (2) ser correctas, es decir, cada transacción
debe ser un programa que conserve la consistencia de la BD.
Si se produce algún incidente durante la ejecución de una transacción que deje
la BD inconsistente el SGBD debe recuperar el estado previo a dicha
transacción. Los procedimientos de respaldo y recuperación tienen como
objetivo poder recuperar un estado anterior de la BD. Para ello, mantienen en
un fichero (fichero LOG o Bitácora de la BD) información sobre las
transacciones que se realizan. Si por cualquier razón se detecta que se pierde
la consistencia en la BD el sistema de recuperación deshace las modificaciones
realizadas por las últimas transacciones hasta dejar la BD consistente.
Para asegurar la integridad operativa de la BD se ha de controlar la
consistencia lógica de los datos cuando se producen transacciones
concurrentes. Por ejemplo, cuando un agente desea modificar un registro
mientras otro lo esta leyendo. Cuando se pueden producir accesos simultáneos
a un mismo objeto de la BD la práctica común consiste en bloquear el objeto
accedido el tiempo que dure la operación y liberarlo una vez completada. Esta
técnica, sin embargo, tiene que verificar que no se produzcan bloqueos mutuos
entre varias aplicaciones.
En cuanto a los intentos de acceso indebido con el fin de modificar la BD, en
general las políticas de integridad se basan en limitar los privilegios a los
usuarios en cada momento de tal forma que cada usuario sólo puede acceder a
los datos que precisa para su trabajo y utilizando únicamente las operaciones
estrictamente necesarias. Las restricciones de privilegios no sólo se aplican a
departamentos dentro de una organización sino también a grupos de usuarios
con tareas comunes. Una mejora para realizar esto de forma ordenada consiste
en utilizar los roles que permiten agrupar usuarios que comparten los mismos
privilegios. Así, el SGBD puede controlar más fácilmente las actividades de los
usuarios y detectar cambios en los privilegios otorgados a cada role (ver figura
4.1). Además, el administrador de la BD puede fácilmente modificar los
privilegios a grupos de usuarios cambiando un único role.
Fig. 4.1 : Ejemplo de control de acceso basado en roles.
El SGBD también puede garantizar la integridad semántica de los datos

manteniendo los valores en los rangos que se les hayan asignado. Las
restricciones de integridad representan este tipo de controles. Esto debe ser
cuidado cuando se hace el diseño de la BD.
En general para anular los efectos de operaciones que han alterado

inadecuadamente la BD se emplean los mecanismos de respaldo y
recuperación.
Seguridad en sql server
SQL Server valida a los usuarios con 2 niveles de seguridad; autentificación del
login y validación de permisos en la Base de Datos de cuentas de usuarios y de
roles. La autentificación identifica al usuario que está usando una cuenta y
verifica sólo la habilidad de conectarse con SQL Server. El usuario debe tener
permiso para accesar a las Bases de Datos en el Servidor. Esto se cumple
para asignar permisos específicos para la Base de Datos, para las cuentas de
usuario y los roles. Los permisos controlan las actividades que el usuario tiene
permitido realizar en la Base de Datos del SQL Server.
Autentificación del login:
Un usuario debe tener una cuenta para conectarse al SQL Server. Este
reconoce 2 mecanismos de autentificación: Autentificación de SQL Server y de
Windows NT. Cada uno tiene un diferente tipo de cuenta.
Autentificación de sql server
Cuando se usa, un administrador del Sistema de SQL Server, define una

cuenta y un password WQL Server. Los usuarios deben suministrar tanto el
login como el password cuando se conectan al SQL Server.
Autentificación de windows nt
Cuando se usa, el usuario no necesita de una cuenta de SQL Server, para

conectarse. Un administrador del sistema debe definir, ya sea cuentas de
Windows NT o grupos de Windows NT como cuentas válidas de SQL Server.
Modo de autentificación
Cuando SQL Server está corriendo en Windows NT, un sistema

administrador puede especificar que está corriendo en uno de 2 modos de
autentificación:
 Modo de autentificación de Windows NT: Sólo está autorizada la
autentificación de Windows NT. Los usuarios no pueden usar cuentas
de SQL Server.
 Modo mixto: Cuando se usa este modo de autentificación, los usuarios
se pueden conectar a SQL Server con la autentificación de Windows
NT o con la de SQL Server.
Cuentas de usuario y roles en una base de datos
Después de que los usuarios han sido autentificados, y se les ha permitido

conectarse al SQL Server, deben tener cuentas en la Base de Datos. Las
cuentas de usuario y los roles, identifican permisos para ejecutar tareas.
Cuentas de usuarios de la base de datos
Las cuentas de usuario utilizadas para aplicar permisos de seguridad son las
de usuarios, o grupos de Windows NT o las de SQL Server. Las cuentas de
usuario son específicas para cada Base de Datos.
Roles
Permiten reunir a los usuarios en una sola unidad a la cual se le pueden aplicar
permisos. SQL Server contiene roles de servidor y de Base de Datos
predefinidos, para tareas administrativas comunes, de manera que pueden
asignársele determinados permisos administrativos a un usuario en particular.
También se pueden crear roles de Base de Datos definidos por el usuario. En
SQL Server, los usuarios pueden pertenecer a varios roles:
 Roles fijos del Servidor: Proveen agrupamientos con privilegios

administrativos a nivel del Servidor. Son administrados
independientemente de las Bases de Datos de usuarios a nivel servidor.
 Roles fijos de la Base de Datos: Proveen agrupamientos con privilegios
administrativos a nivel de Base de Datos.
 Roles de usuarios definidos en la Base de Datos: También se pueden
crear roles para Base de Datos, para representar un trabajo desarrollado
por un grupo de empleados dentro de una organización. No es necesario
asignar y quitar permisos a cada persona. En función de que cambia un
rol, se pueden cambiar fácilmente los permisos del rol y hacer que los
cambios se apliquen automáticamente a todos los miembros del rol.
Validación de permisos
Dentro de cada Base de Datos, se asignan permisos a las cuentas de usuarios

y a los roles para permitir o limitar ciertas acciones. SQL Server acepta
comandos después de que un usuario ha accesado a la Base de datos.
SQL Server realiza los siguientes pasos cuando valida permisos:

1. Cuando el usuario realiza una acción, tal como ejecutar un comando de
Transact-SQL o elegir una opción de un menú, los comandos de
Transact SQL son enviadas al SQL Server.
2. Cuando SQL Server recibe un comando de Transact –SQL, checa que el
usuario tenga permiso de ejecutar dicha instrucción.
3. Después, SQL realiza cualquiera de las siguientes acciones:
a) Si el usuario no tiene los permisos adecuados, SQL Server
devuelve un error.
b) Si el usuario tiene los permisos adecuados, SQL Server realiza la
acción.
Crear cuentas de seguridad

Cada usuario debe obtener acceso a una instancia de Microsoft® SQL
Server™ a través de una cuenta de inicio de sesión que establece su
capacidad para conectarse (autenticación). A continuación, esta cuenta de
inicio de sesión se asigna a una cuenta de usuario de SQL Server que se utiliza
para controlar las actividades realizadas en la base de datos (validación de
permisos). Por tanto, se asigna un único inicio de sesión a cada cuenta de
usuario creada en cada base de datos a la que el inicio de sesión tiene acceso.
Si en una base de datos no hay ninguna cuenta de usuario, el usuario no podrá
tener acceso a ella, aunque pueda conectarse a una instancia de SQL Server.
El inicio de sesión se crea en Microsoft Windows NT® 4.0 o Windows® 2000, y
no en SQL Server. A continuación, se concede permiso a este inicio de sesión
para conectarse a una instancia de SQL Server. Se concede acceso al inicio de
sesión en SQL Server.
Cómo agregar una cuenta de inicio de sesión de SQL Server (Administrador
corporativo)
Para agregar una cuenta de inicio de sesión de SQL Server
1. Expanda un grupo de servidores y, a continuación, un servidor.
2. Expanda Seguridad, haga clic con el botón secundario del mouse

(ratón) en Inicios de sesión y, a continuación, haga clic en Nuevo
inicio de sesión.
3. En Nombre, escriba un nombre para el inicio de sesión de Microsoft®

SQL Server™.
4. En Autenticación, seleccione Autenticación de SQL Server.
5. Opcionalmente, en Contraseña, escriba una contraseña.
6. Opcionalmente:
 En Base de datos, haga clic en la base de datos predeterminada
a la que se conecta la cuenta de inicio de sesión después de
iniciar una sesión en una instancia de SQL Server.
 En Idioma, haga clic en el idioma predeterminado en el que se
mostrarán los mensajes al usuario.

A17-EC9 Crear usuarios.
Crear 2 tipos de usuario, uno administrador (todos los derechos) y uno general
(solo puede consultar y agregar información).

b) Producto esperado: Dos usuarios dentro de la base de datos
c) Fecha inicio:
d) Fecha entrega:

Verificar que los dos usuario
Crear usuarios este creados en la base de 5 puntos
datos.
Total 5 Puntos

Concesión y renovación de privilegios a los usuarios.
4.1.7. DOCUMENTOS
4.2. TIPOS DE SEGURIDAD

Aplicar los mecanismos de seguridad que SQL Server 2000 ofrece para
aprovecharlos al máximo.
4.2.3. DESARROLLO
Mecanismos de seguridad en SGBD

Análogamente a lo que sucede en los sistemas operativos, los SGBDs han de
ser diseñados teniendo en cuenta la seguridad desde las primeras etapas del
desarrollo. El SGBD juega un papel crucial en cuanto a la seguridad en una
organización. Obviamente, el sistema operativo debe proporcionar ciertos
mecanismos de protección básicos. Por ejemplo, el sistema operativo ha de
garantizar la identidad del usuario y la protección de los ficheros físicos sobre
los que está soportada la BD. Por otra parte, el SGBD debe hacerse cargo de
restricciones de seguridad dependientes de las aplicaciones. Los
requerimientos de seguridad principales deben hacer frente a los siguientes
aspectos:
Acceso a diferentes niveles de granularidad. En un entorno de BD se puede
acceder a los datos a diferentes niveles (BD, colección de relaciones, una
relación, conjunto de columnas de una relación, algunas filas de una relación
etc.). El SGBD debe establecer controles de acceso a cada nivel de
granularidad.
Varios modos de acceso. Los controles de acceso deben ser distintos según
la operación a realizar. Por ejemplo Select, Insert, UPDATE, DELETE en SQL.
Diferentes tipos de control de acceso. El acceso se puede regular mediante
diferentes tipos de controles: control basado en el nombre del objeto a acceder,
control basado en el contenido del objeto a acceder, control dependiente del
contexto (ej.: permitir o denegar el acceso dependiendo de ciertas variables de
entorno como el día, hora o terminal), control dependiente de la secuencia de
acciones del usuario y finalmente control dependiente del procedimientos
auxiliares.
Autorización dinámica. El SGDB debe ser capaz de modificar las
autorizaciones de los usuarios dinámicamente mientras la BD sea operativa.
Protección multinivel. Las BD pueden beneficiarse del mecanismo de
protección multinivel explicado en el capítulo anterior. Con este método se
etiqueta cada objeto de la BD con un nivel de seguridad. Teniendo en cuenta
los diferentes niveles de granularidad dentro de una BD, podemos tener una
relación etiquetada con un nivel de seguridad y los atributos de dicha relación
tienen su propio nivel de seguridad.
Auditoría. Los eventos importantes o sospechosos que se produzcan durante
operaciones con la BD deben ser almacenados para su posterior análisis en
busca de acciones no autorizadas. Las secuencias de acciones realizadas por
un mismo usuario puede ser utilizadas para detectar posibles inferencias. Esta
práctica puede ser un agente disuasor contra los usuarios que tengan malas
intenciones. El problema de la auditoria estriba en la cantidad de información
que se ha de almacenar si deseamos controlar operaciones a un bajo nivel de
granularidad.
Además de estos requerimientos, el SGBD debe asegurarse de que no existan
canales encubiertos a través de los cuales de pueda divulgar información
confidencial, puertas traseras que permitan acceder a usuarios no autorizados.
Asímismo se ha de controlar el flujo de la información.
Normalmente, el recurso que se utiliza para restringir el acceso a las BD son
las vistas.
Las vistas son una forma de proporcionar a cada usuario un modelo
personalizado de la BD.
Una vista puede ocultar al usuario los datos que no necesita ver, y de la misma
forma, los datos a los que tiene negado el acceso. El objetivo de seguridad se
logra si se dispone de un mecanismo que limite a los usuarios a utilizar sus
vistas personales.
Otros mecanismos sencillos y evidentes que mejoran la seguridad en las BDs
son contrastar periódicamente los datos informáticos con los reales e
implementar las aplicaciones que operen con el sistema de BD de forma que
sean fáciles de utilizar para evitar en los posible los errores.
Otra medida de seguridad interesante es guardar las tablas de la BD y no
dejarlas disponibles a terceros que puedan extraer información de su estructura
que luego les sirva para realizar deducciones de la BD. La mejor forma de
ocultarlas será mediante cifrado.
Finalmente, una cuestión a tener en cuenta en los sistemas de información es
la eficiencia. Los controles de seguridad entrañan un costo computacional
adicional por lo que se ha de lograr un compromiso entre mantener el tiempo
de respuesta de la BD en límites razonables y la BD segura.
USUARIOS
Un identificador (Id.) de usuario identifica a un usuario dentro de una base de
datos. Todos los permisos y la propiedad de los objetos de la base de datos
están controlados por la cuenta del usuario. Las cuentas de usuario son
específicas de una base de datos; la cuenta de usuario xyz de la base de datos
sales es diferente de la cuenta de usuario xyz de la base de datos inventory,
aunque ambas cuentas tengan el mismo Id. Los Id. de los usuarios son
definidos por los miembros de la función fija db_owner de la base de datos.
Por sí mismo, el Id. de inicio de sesión no concede al usuario los permisos para
tener acceso a los objetos de las bases de datos. El Id. de inicio de sesión tiene
que estar asociado a un Id. de usuario en cada base de datos para que quien
se conecte con dicho Id. de inicio de sesión pueda tener acceso a los objetos
de la base de datos. Si en una base de datos no se ha asociado explícitamente
un Id. de inicio de sesión a un Id. de usuario, se asocia al Id. del usuario guest.
Si una base de datos no tiene la cuenta de usuario guest, el inicio de sesión no
puede tener acceso a la base de datos a menos que se asocie a una cuenta de
usuario válida.
Cuando se define un Id. de usuario, se asocia a un Id. de inicio de sesión. Por
ejemplo, un miembro de la función db_owner puede asociar el inicio de sesión
NETDOMAIN\Joe de Microsoft® Windows® 2000 al Id. de usuario abc en la
base de datos sales y el Id. de usuario def en la base de datos employee. La
asociación predeterminada es que el Id. de inicio de sesión y el Id. de usuario
sean iguales.
Este ejemplo muestra la concesión de acceso a una base de datos de una
cuenta de Windows 2000 y la asociación del inicio de sesión a un usuario de la
base de datos:
USE master
GO
sp_grantlogin 'NETDOMAIN\Sue'
GO
sp_defaultdb @loginame = 'NETDOMAIN\Sue', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue'
GO
En la instrucción sp_grantlogin, al usuario NETDOMAIN\Sue de Windows

2000 se le concede acceso a Microsoft SQL Server™ 2000. La instrucción
sp_defaultdb establece que la base de datos sales sea su base de datos
predeterminada. La instrucción sp_grantdbaccess concede al inicio de sesión
NETDOMAIN\Sue acceso a la base de datos sales y establece que Sue es su
Id. de usuario dentro de sales.
Este ejemplo muestra la definición de un inicio de sesión en SQL Server,
asignando una base de datos predeterminada y asociando el inicio de sesión a
un usuario de la base de datos:
USE master
GO
sp_addlogin @loginame = 'TempWorker', @password = 'fff', defdb = 'sales'
GO
USE sales
GO
sp_grantdbaccess 'TempWorker'
GO
La instrucción sp_addlogin define un inicio de sesión en SQL Server que va a

ser utilizado por varios empleados temporales. La instrucción especifica
también la base de datos sales como base de datos predeterminada para el
inicio de sesión. La instrucción sp_grantdbaccess concede al inicio de sesión
TempWorker acceso a la base de datos sales; como no se especifica el
nombre del usuario, el valor predeterminado es TempWorker.
Un usuario de una base de datos se identifica por su Id. de usuario, no por su
Id. de inicio de sesión. Por ejemplo, sa es una cuenta de inicio de sesión que
se asigna a la cuenta de usuario especial dbo (propietario de la base de datos)
en todas las bases de datos. Todas las instrucciones Transact-SQL
relacionadas con la seguridad utilizan el Id. de usuario como el parámetro
security_name. La administración y la compresión de los permisos son menos
confusas si los miembros de la función fija sysadmin del servidor y de la
función fija db_owner de la base de datos configuran el sistema de tal manera
que el Id. de inicio de sesión y el Id. de usuario sean iguales en cada usuario,
pero no es obligatorio.
La cuenta guest es una cuenta de usuario especial en las bases de datos SQL
Server. Si un usuario utiliza una instrucción USE base de datos para tener
acceso a una base de datos en la que no tiene asociada una cuenta de
usuario, se le asociará al
INTERFAZ DE SEGURIDAD DE SQL SERVER
PROPIEDADES DE SQL SERVER: FICHA SEGURIDAD

Utilice esta ficha para ver o especificar las siguientes opciones.
Opciones
SQL Server y Windows
Especifica que los usuarios pueden conectarse a la instancia de Microsoft®
SQL Server™ mediante la autenticación de SQL Server y la autenticación de
Windows. Esto se considera una autenticación en Modo mixto. Los usuarios
que se conectan a través de una cuenta de usuario de Microsoft Windows NT
4.0 o Windows 2000 pueden utilizar las conexiones en las que se confía, ya
sea en el Modo de autenticación de Windows o en el Modo mixto. Cuando un
usuario se conecta a través de una cuenta de usuario de Windows NT 4.0 o
Windows 2000, SQL Server vuelve a validar el nombre y la contraseña de la
cuenta solicitando a Windows NT 4.0 o Windows 2000 la información.
Sólo Windows
Especifica que los usuarios pueden conectarse a la instancia de SQL Server
utilizando sólo la autenticación de Windows.
Ninguna
Deshabilita la auditoría. Éste es el valor predeterminado para esta
configuración.
Correcto
Audita en los intentos de inicio de sesión que sean correctos. Es posible
registrar los accesos de usuario que se intente, así como información de
registro de SQL Server de otro tipo; también puede habilitar la auditoría para
ambos modos de seguridad y registrar información sobre conexiones, tanto en
las que se confía como en las que no. Las entradas de registro para estos
sucesos aparecen en el registro de aplicación de Microsoft Windows®, en el
registro de errores de SQL Server o en ambos, según cómo se haya
configurado la opción de registro para la instancia de SQL Server.
Si selecciona esta opción, debe detener y reiniciar el servidor para habilitar la
auditoría.
Error
Audita en los intentos de inicio de sesión que no sean correctos. Es posible
registrar los accesos de usuario que se intente, así como información de
registro de SQL Server de otro tipo; también puede habilitar la auditoría para
sucesos aparecen en el registro de aplicación de Windows, en el registro de
errores de SQL Server o en ambos, según cómo se haya configurado la opción
de registro para la instancia de SQL Server.
auditoría.
Todas
Audita tanto los intentos de inicio de sesión correctos como los erróneos. Es
posible registrar los accesos de usuario que se intente, así como información
de registro de SQL Server de otro tipo; también puede habilitar la auditoría para
sucesos aparecen en el registro de aplicación de Windows, en el registro de
errores de SQL Server o en ambos, según cómo se haya configurado la opción
de registro para la instancia de SQL Server.
auditoría.
Cuenta del sistema
Especifica que la cuenta de servicio de la instancia de SQL Server es la cuenta
integrada del administrador del sistema local.
Esta cuenta
Especificar que la cuenta de servicio de SQL Server es una cuenta de dominio
de Microsoft Windows NT® o de Windows 2000. Este campo está habilitado
sólo si utiliza una cuenta de administrador válida de Windows NT 4.0 o
Windows 2000 en el equipo en donde se está ejecutando la instancia registrada
de SQL Server.
Contraseña
Especifica la contraseña para la cuenta de dominio de Windows NT 4.0 o
Windows 2000. Este campo sólo se habilita si utiliza una cuenta de
administrador de Windows NT 4.0 o Windows 2000 en el equipo donde se
ejecuta la instancia registrada de SQL Server.
PROPIEDADES DEL USUARIO DE LA BASE DE DATOS: FICHA GENERAL
Utilice esta ficha para ver o especificar las siguientes opciones.
Opciones
Nombre de inicio de sesión
Especifica el nombre de inicio de sesión del usuario de la base de datos.
Nombre de usuario
Especifica el nombre del usuario de la base de datos.
Permisos
Muestra el cuadro de diálogo de propiedades Propiedades del usuario de la
base de datos, donde puede especificar los permisos del usuario para la base
de datos.
Permitir en la función de base de datos
Especifica la función de base de datos a la que pertenece el usuario.
Propiedades
Muestra el cuadro de diálogo Propiedades de la función de la base de datos,
donde puede agregar o quitar usuarios de la función.
A18-EC10 Seguridad de SQL.
Crear un usuario de Windows nuevo. Después con el usuario que estas firmado
(checar cual es la contraseña) agregarlo a SQL Server 2000 como la cuenta
de inicio de servicio. Posterior a todo esto cerrar la sesion y abrir sesion con
el usuario nuevo, verifiacar que la base de datos “ESQUINITA” no se puede
acceder desde este usuario.
b) Producto esperado:Ralacionar el usuario de Windows con SQL Server
2000
c) Fecha inicio:
d) Fecha entrega:
e) Forma de entrega:Base de datos con seguridad Windows

Checar que la base de datos
efectivamente no pueda se
Seguridad de SQL accesada por ningun otro 5 puntos
usuario salvo el que esta
agregado.
Total 5 Puntos

Brindarle mayor seguridad a nuestra base de datos.
4.2.7. DOCUMENTOS
Ayuda SQL Server 2000, SQL Server 7.0
4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN

/ RENOVACION DE PRIVILEGIOS.
Poder administrar los derechos y restricciones de los usuarios respecto de las
bases de datos.
4.3.3. DESARROLLO
PROPIEDADES DEL USUARIO DE LA BASE DE DATOS: FICHA

PERMISOS
Utilice esta ficha para ver o especificar las siguientes opciones. Una marca
negra indica que el permiso se ha concedido. Una X roja indica que el permiso
se ha denegado.
Opciones
Usuario de la base de datos
Especifica el usuario para el que se muestran los permisos.
Enumerar todos los objetos
Enumera todos los objetos de la base de datos seleccionada. Haga clic en el
cuadro correspondiente para modificar los permisos del usuario para la base de
datos.
Enumerar sólo los objetos con permisos para este usuario
Enumera sólo los objetos para los que el usuario tiene permiso. Haga clic en el
cuadro correspondiente para modificar los permisos del usuario para la base de
datos.
Columnas
Muestra el cuadro de diálogo Permisos de columna, donde puede administrar
los permisos para cada columna.
ADMINISTRAR PERMISOS
Cuando los usuarios se conectan a una instancia de Microsoft® SQL Server™,
las actividades que pueden realizar se determinan mediante los permisos que
se conceden a:
 Sus cuentas de seguridad.
 Los grupos o jerarquías de funciones de Microsoft Windows NT® 4.0 o

Windows® 2000 a los que pertenecen sus cuentas de seguridad.
El usuario debe tener los permisos adecuados para realizar cualquier actividad
que implique cambiar la definición de una base de datos o el acceso a su
contenido.
La administración de permisos incluye la concesión o revocación de los
derechos de usuario para:
 Trabajar con datos y ejecutar procedimientos (permisos de objeto).
 Crear una base de datos o un elemento en la base de datos (permisos

de instrucción).
 Utilizar los permisos concedidos a las funciones predefinidas (permisos

implícitos).
Permisos de objeto
Al trabajar con datos o ejecutar un procedimiento, es necesario disponer de
una clase de permisos conocida como permisos de objeto.
 Permisos para las instrucciones SELECT, INSERT, UPDATE y

DELETE, que pueden aplicarse a toda la tabla o vista.
 Permisos para las instrucciones SELECT y UPDATE, que pueden
aplicarse selectivamente a columnas individuales de una tabla o vista.
 Permisos para la instrucción SELECT, que se puede aplicar a funciones

definidas por el usuario.
 Permisos para las instrucciones INSERT y DELETE, que afectan a toda

una fila y, por ello, sólo pueden aplicarse a la tabla o vista, y no a
columnas individuales.
 Permisos para la instrucción EXECUTE, que afecta a funciones y

procedimientos almacenados.
Permisos de instrucción
Las actividades que implica la creación de una base de datos o de uno de sus
elementos, como una tabla o un procedimiento almacenado, necesitan una
clase diferente de permisos, llamados permisos de instrucción. Por ejemplo, si
un usuario necesita crear una tabla en una base de datos, será necesario
otorgarle el permiso de instrucción CREATE TABLE. Los permisos de
instrucción como, por ejemplo, CREATE DATABASE, se aplican a la
instrucción en sí y no a un objeto específico definido en la base de datos.
Los permisos de instrucción son:
 BACKUP DATABASE
 BACKUP LOG
 CREATE DATABASE
 CREATE DEFAULT
 CREATE FUNCTION
 CREATE PROCEDURE
 CREATE RULE
 CREATE TABLE
 CREATE VIEW
Permisos implícitos
Los permisos implícitos controlan las actividades que sólo pueden realizar los
miembros de las funciones de sistema predefinidas o los propietarios de
objetos de base de datos. Por ejemplo, un miembro de la función fija de
servidor sysadmin hereda automáticamente todos los permisos para realizar
cualquier actividad o ver cualquier elemento de la instalación de SQL Server.
Los propietarios de objetos de base de datos también tienen permisos
implícitos que les permiten realizar todas las actividades con los objetos que les
pertenecen. Por ejemplo, si un usuario es propietario de una tabla, puede ver,
agregar o eliminar datos en ella, modificar la definición de la tabla o controlar
sus permisos para permitir que otros usuarios trabajen con ella.
A19-T5 Concesion y Renovación de privilegios.
El usuario general creado anteriormente (el cual solo podia consultar e insertar
información), le agregamos el privilegio de ppoder modificar información.
Creamos un tercer usuario el cual se llama supervisor el cual solo puede
observar la información.
b) Producto esperado: Tres usuarios en la base de datos
c) Fecha inicio:
d) Fecha entrega:

Checar que efectivamente los
Concesion y Renovación de
derechos o privilegios de los 5 puntos
privilegios.
usuarios hayan sido alterados
Total 5 Puntos

Saber crear usuarios y poder renovar privilegios asi como quitarlos y agregar
nuevos.
Ayuda de sQL Server 2000
4.3.7. DOCUMENTOS
SQL Server 7.0
4.4. SEGUIMIENTO DE AUDITORIA

Saber cuales son los mecanismos de suguridad que ofracen los manejadores
de basas de datos en este caso SQL Server 2000
4.4.3. DESARROLLO
AUDITORÍA DE LA ACTIVIDAD DE SQL SERVER

Microsoft® SQL Server™ 2000 proporciona la auditoría como una forma de
trazar y registrar la actividad que ha tenido lugar en cada instancia de SQL
Server, por ejemplo, inicios de sesión correctos o incorrectos. SQL Server 2000
también dispone de una interfaz, Analizador de SQL, para administrar los
registros de auditoría. Sólo los miembros de la función fija de seguridad
sysadmin pueden habilitar o modificar la auditoría, y toda modificación es un
suceso auditable.
Existen dos tipos de auditoría:
 la auditoría, que proporciona cierto nivel de auditoría, pero no requiere el

mismo número de directivas que la auditoría C2.
 la auditoría C25, que requiere que se sigan directivas de seguridad muy

específicas
Ambos tipos de auditoría se pueden realizar utilizando el Analizador de SQL.
5
La auditoría C2 es necesaria si se está ejecutando un sistema certificado C2. Un sistema certificado C2 cumple con
un estándar gubernamental que define el nivel de seguridad. Para que Microsoft® SQL Server™ tenga la certificación
C2, debe configurarlo en la configuración C2 evaluada.
USAR EL ANALIZADOR DE SQL
El Analizador de SQL proporciona la interfaz de usuario para la auditoría de
sucesos. Existen varias categorías de sucesos que se pueden auditar con el
Analizador de SQL, por ejemplo:
 la actividad del usuario final (todos los comandos de SQL, cierres e

inicios de sesión, habilitación de las funciones de aplicación)
 la actividad de DBA (DDL distintos de conceder, revocar, denegar y los

sucesos de seguridad, y la configuración (base de datos o servidor)
 los sucesos de seguridad (conceder, revocar o denegar, agregar, quitar

o configurar función o usuario de inicio de sesión)
 los sucesos de herramientas (comandos de copia de seguridad,

restaurar, inserción masiva, BCP, DBCC)
 los sucesos del servidor (cerrar, pausa, inicio)
 los sucesos de auditoría (agregar, modificar o detener auditoría)
 Categoría de sucesos Auditoría de seguridad
Utilice la categoría de sucesos Auditoría de seguridad para supervisar la

actividad de auditoría.
Se puede auditar los siguientes aspectos de SQL Server mediante el
Analizador de SQL:
 fecha y hora del suceso
 usuario responsable de que ocurriera el suceso
 tipo de suceso
 éxito o fracaso del suceso
 el origen de la solicitud (por ejemplo, el nombre del equipo con Microsoft

Windows NT® 4.0)
 el nombre del objeto al que se obtuvo acceso
 el texto de la instrucción SQL (contraseñas sustituidas por ****)
 Si es un miembro de la función fija de servidor sysadmin o

securityadmin y restablece su propia contraseña mediante
sp_password con los tres argumentos especificados ('old_password',
'new_password', 'login'), el registro de auditoría reflejará que se ha
cambiado alguna contraseña.
La auditoría puede tener consecuencias importantes para el rendimiento. Si

todos los contadores de auditoría están activados, las repercusiones sobre el
rendimiento pueden ser importantes. Es necesario evaluar cuántos sucesos es
necesario auditar en comparación con las consecuencias que habrá sobre el
rendimiento. El análisis de la auditoría puede llevar tiempo, por lo que se
recomienda ejecutar la actividad de auditoría en un servidor distinto del servidor
de producción.
Nota Si se inicia SQL Server con el indicador –f, no se podrá ejecutar la

auditoría.
SUPERVISAR CON EL ANALIZADOR DE SQL
El Analizador de SQL es una herramienta gráfica que permite a los
administradores del sistema supervisar sucesos de una instancia de Microsoft®
SQL Server™. Puede capturar y guardar datos acerca de cada suceso en un
archivo o en una tabla de SQL Server para analizarlos posteriormente. Por
ejemplo, puede supervisar un entorno de producción para ver qué
procedimientos empeoran el rendimiento al ejecutarse demasiado lentamente.
Utilice el Analizador de SQL para supervisar únicamente los sucesos en los
que está interesado. Si las trazas son demasiado grandes, puede filtrarlas a
partir de la información que desea, de forma que sólo se recopile un
subconjunto de los datos del suceso. Si se supervisan demasiados sucesos,
aumentará la sobrecarga del servidor y el proceso de supervisión, y podría
hacer que el archivo o la tabla de traza crezcan demasiado, especialmente
cuando el proceso de supervisión se realiza durante un período prolongado de
tiempo.
Cuando haya trazado los sucesos, el Analizador de SQL permite reproducir los
sucesos capturados en una instancia de SQL Server, volviendo a ejecutar así
los sucesos guardados tal y como se produjeron originalmente.
Utilice el Analizador de SQL para:
 Supervisar el rendimiento de una instancia de SQL Server.
 Depurar procedimientos almacenados e instrucciones Transact-SQL.
 Identificar consultas de ejecución lenta.
 Probar procedimientos almacenados e instrucciones SQL en la fase de

desarrollo de un proyecto mediante la ejecución paso a paso de las
instrucciones para confirmar que el código funciona como se esperaba.
 Solucionar problemas de SQL Server mediante la captura de sucesos en

un sistema de producción y su reproducción en un sistema de prueba.
Esto es útil para propósitos de pruebas o depuración, y permite a los
usuarios seguir utilizando el sistema de producción sin interferencias.
 Auditar y revisar la actividad producida en una instancia de SQL Server.

Esto permite a los administradores de seguridad revisar los sucesos de
auditoría, incluidos el éxito o el error de un intento de inicio de sesión y
problemas de permisos al tener acceso a instrucciones u objetos.
El Analizador de SQL proporciona una interfaz gráfica de usuario a un conjunto
de procedimientos almacenados, que se puede utilizar para supervisar una
instancia de SQL Server. Por ejemplo, puede crear su propia aplicación que
utilice procedimientos almacenados del Analizador de SQL para supervisar
SQL Server.
Debe tener al menos 10 megabytes (MB) de espacio libre para ejecutar el
Analizador de SQL. Si se redujera la cantidad de espacio libre a menos de 10
MB mientras se utiliza el Analizador de SQL, se detendrán todas las funciones
del Analizador de SQL.
INICIAR EL ANALIZADOR DE SQL
El Analizador de SQL se inicia desde el menú Inicio de Microsoft® Windows
NT® 4.0, Microsoft Windows® 2000 o Microsoft Windows 98, o desde el
Administrador corporativo de SQL Server.
En el modo de Autenticación de Windows, la cuenta de usuario que se ejecuta
en el Analizador de SQL debe conceder permiso para conectar a una instancia
de SQL Server. También se debe conceder permisos a la cuenta de inicio de
sesión para ejecutar procedimientos almacenados del Analizador de SQL
PARA INICIAR EL ANALIZADOR DE SQL

Cómo iniciar el Analizador de SQL (Administrador corporativo)
Para iniciar el Analizador de SQL
1. En el menú Inicio, seleccione Programas, Microsoft SQL Server y, a

continuación, haga clic en Administrador corporativo.
2. En el menú Herramientas, haga clic en Analizador de SQL.

A20-T6 Configurar SQL Server para poder supervisar los sucesos.
Configurar SQL Server para que pueda llevar un registro de todos los
movimientos que los usuarios realicen.
b) Producto esperado: Reporte de eventos en SQL Server 2000
c) Fecha inicio:
d) Fecha entrega:
e) Forma de entrega: Documento impreso del reporte

Checar el reporte impreso que
se entrega para verificar que
Configurar SQL Server para
efectivamente este 5 puntos
poder supervisar los sucesos.
configurado el manejador de
base de datos.
Total 5 Puntos

A21-ER4 Examen Rápido de los temas 4.3 y 4.4
Formaular 5 preguntas de los temas mencionados y dictárselas a los alumnos.
g) Valor actividad: Requisito
h) Producto esperado: Preguntas contestadas
i) Fecha inicio:
j) Fecha entrega:
k) Forma de entrega: Documento
l) Tipo de Actividad: Individual

Examen Rápido Preguntas contestadas Requisito
Total Requisito

Poder auditar los mivimientos y operacines que los usuarios realicen, para
poder determinar la razon en muchos casos de fallas en el sistema.
4.4.7. DOCUMENTOS
UNIDAD TEMATICA 5. BASES DE DATOS DISTRIBUIDAS
En un sistema de base distribuido, los datos almacenan en varios

computadores. Los computadores de un sistema distribuido se comunican
entre si a través de diversos medios de comunicación, tales como cables de
alta velocidad a líneas telefónicas. No comparten la memoria principal ni el
reloj.
Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño

y función. Pueden incluir microcomputadoras y sistemas de computadores
grandes de aplicación general. Estos procesadores reciben diferentes nombres,
tales como localidades, nodos, computadores, dependiendo en el contexto
donde se mencionen. Nosotros utilizamos normalmente el termino localidad
para hacer hincapié en el distribución física de estos sistemas.
Un sistema distribuido de bases de datos consiste en un conjunto de

localidades, cada una de las cuales puede participar en la ejecución de
transacciones que accedan a datos de una o varias localidades. La diferencia
principal entre los sistemas de base de datos centralizados y distribuidos es
que, en los primeros, los datos residen en una sola localidad, mientras que, en
los últimos, se encuentran en varias localidades.6
5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES

Identificar las características de un sistema de base de datos dentro de una
organización específicamente funciones y ventajas.
5.1.3. DESARROLLO
ESTRUCTURA DE BASES DE DATOS DISTRIBUIDAS
6
FUNDAMENTOS DE BASES DE DATOS, Segunda Edición, Henry F. Korth, Abraham Silberschatz Pag. 507
un sistema distribuido de base de datos consiste en un conjunto de localidades,
cada una de las cuales mantienen un sistema de base de datos local. Cada
localidad puede procesar transacciones locales, es decir, aquellas que solo
acceden a datos que residen en esa localidad. Además, una localidad puede
participar en la ejecución de transacciones globales, es decir, aquellas que
acceden a datos de varias localidades. La ejecución de transacciones globales
requiere comunicación entre las localidades.
Las localidades en el sistema conectarse físicamente de diversas formas. Las
distintas configuraciones se representan por medio de grafos cuyos nodos
corresponden a las localides. Una arista del modo A al nodo B corresponde a
una conexión directa entre las dos localidades. En la figura 5.1.1 se ilustra
algunas de las configuraciones más comunes. Las diferencias principales entre
estas configuraciones son:
 Coste de instalación. El coste conecta físicamente las localidades del

sistema.
 Coste de comunicación. El coste en tiempo y dinero que implica enviar
un mensaje desde la localidad A a la B.
 Fiabilidad. La frecuencia con que falla una línea de comunicación o una
localidad.
 Disponibilidad. La posibilidad de acceder a información a pesas de
fallos en algunos localidades o líneas de comunicación .
Como se verá, estas diferencias juegan un papel importante en la elección del
mecanismo adecuado para manejar la distribución de los datos.
Las localidades de un sistema distribuido de bases de datos pueden estar
dispersas de forma física, ya sea por un área geográfica extensa (como los
Estados Unidos) o en un atea reducida (por ejemplo, un solo edificio ó varios
edificios adyacentes). Una red de primer tipo se denomina red de larga
distancia, mientras que las ultimas se conocen como redes de área local.
Figura 5.1.1: Configuración de Red
CONSIDERACIONES AL DISTRIBUIR LA BASE DE DATOS.
Existen varias razones para construir sistemas distribuidos de bases de datos

que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el
procesamiento de las consultas. Sin embargo, estas ventajas vienen
acompañadas de varias desventajas, como son mayores costes de desarrollo
del software, mayor posibilidad de errores y el aumento en el coste extra del
procesamiento. En esta sección se comentaran brevemente cada una de ellas.
VENTAJAS DE LA DISTRIBUCIÓN DE DATOS

la principal ventaja de los sistemas distribuidos de base de datos es la
capacidad de compartir y acceder a la información de una forma fiable y eficaz.
Utilización compartida de los datos y distribución del control
Si varias localidades diferentes están conectadas entre si, entonces un usuario

de una localidad pueden acceder a datos disponibles en otra localidad. Por
ejemplo, en el sistema bancario distribuido que se describió en la sección 15.1,
un usuario de una sucursal puede acceder a datos de otra. Si no se contara
con esta facilidad, un usuario que quisiera transferir fondos de una sucursal a
otra tendr8ia que recurrir a un mecanismo externo para realizar la
transferencia. Este mecanismo externo seria, de hecho, una base de datos
única centralizada.
La ventaja principal de compartir los datos por medio de la distribución es que
cada localidad pueda controlar hasta cierto punto las datos almacenados
localmente. En un sistema centralizado, el administrador de base de datos de
la localidad central controla la base de datos. En un sistema distribuido existe
un administrador global de la base de datos que se encarga de todo el sistema.
Parte de estas responsabilidades se delega al administrador de base de datos
de cada localidad. Dependiendo del diseño del sistema distribuido, cada
administrador local podrá tener un grado de autonomía diferente, que se
conoce como autonomía local. La posibilidad de contar con autonomía local es
en muchos casos una ventaja importante de las bases de datos distribuidas.
Fiabilidad y disponibilidad
Si se produce un fallo en una localidad en un sistema distribuido, es posible
que las demás localidades puedan seguir trabajando. En particular, si los datos
se repiten en varias localidades, una transacción que requiere un dato
especifico puede encontrarlo en más de una localidad. Así, el fallo de una
localidad no implica necesariamente la desactivación del sistema.
El sistema debe detectar cuando falla una localidad y tomar las medidas
necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la
localidad que falló. Por ultimo, cuando se recupere o repare esta localidad,
debe contarse con mecanismos para reintegrarla al sistema con el mínimo de
complicaciones.
Aunque la recuperación de fallos es más compleja en sistemas distribuidos que
en los centralizados, la capacidad que tiene el sistema para seguir trabajando,
a pesar del fallo de una localidad, da como resultado una mayor disponibilidad.
La disponibilidad es fundamental para los sistemas de base de datos que se
utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no
puede tener acceso a la información, es posible que pierda clientes a favor de
la competencia.
Agilización del procesamiento de consultas

Si una consulta comprende datos de varias localidades, pueden ser posible
dividir la consulta en varias subconsultas que se ejecuten en paralelo en
distintas localidades. Se podrían usar algunas de las estrategias de
computación de intersección en paralelo de la sección 9.6. sin embargo, en un
sistema distribuido no se comparte la memoria principal, así que no todas las
estrategias de intersección para procesadores paralelos su pueden aplicar
directamente a los sistemas distribuidos. En los casos en que hay repetición de
los datos, el sistema puede pasar la consulta a las localidades más ligeras de
carga.
DESVENTAJAS DE LA DISTRIBUCIÓN DE LOS DATOS
La desventaja principal de los sistemas distribuidos de base de datos es la

mayor complejidad que se requiere para garantizar una coordinación adecuada
entre localidades.
El aumento de la complejidad se refleja en:
 Coste de desarrollo de software. Es más difícil estructurar un sistema
de base de datos distribuidos y, por tanto, su coste es mayor.
 Mayor posibilidad de errores. Puesto que las localidades del sistema
distribuido operan en paralelo, es más difícil garantizar que los
algoritmos sean correctos. Existe la posibilidad de errores
extremadamente sutiles.
 Mayor tiempo extra de procesamiento. El intercambio de mensajes y
los cálculos adicionales que se requieren para coordinar las localidades
son una forma de tiempo extra que no existe en los sistemas
centralizados.
Al escoger el diseño de una base de datos, el diseñador debe hacer un balance
entre las ventajas y las desventajas de la distribución de los datos. Se verá que
existen varios enfoques del diseño de bases de datos distribuidas que van
desde diseños totalmente distribuidos hasta diseños que incluyen un alto grado
de centralización.
DISEÑO DE BASES DE DATOS DISTRIBUIDAS
Los principios del diseño de base de datos que se explicaron en capítulos

anteriores también se aplican a las bases de datos distribuidas. Esta sección
se dedicara a los factores del diseño que se aplican específicamente a las
bases de datos distribuidas.
Considérese una relación r que se va a almacenar en la base de datos. Hay
varios factores que deben tomarse en cuenta al almacenar esta relación en la
base de datos distribuida. Tres de ellos son:
 Repetición. El sistema mantiene varias copias idénticas de la relación.
Cada copia se almacena en una localidad diferente, lo que resulta en
una repetición de la información. La alternativa a la repetición es
almacenar una sola copia de la relación r.
 Fragmento. La relación se divide en varios fragmentos. Cada
fragmento se almacena en una localidad diferente.
Repetición y fragmentación. Esta es una combinación de los dos conceptos
antes mencionados. La relación se divide en varios fragmentos. El sistema
mantiene varias copias idénticas de cada uno de los fragmentos.
A22-I2 Sistemas en organizaciones.
b) Producto esperado: Reporte de la investigación
c) Fecha inicio:
d) Fecha entrega:

Revisar documento que avale
Sistemas en organizaciones la investigación en los 5 puntos
negocios de la region
Total 5 Puntos

Saber realmente cuales son los beneficios que los sistemas de información
ofrecen a las empresas.
FUNDAMENTOS DE BASES DE DATOS, Segunda Edición, Henry F. Korth,
Abraham Silberschatz
5.1.7. DOCUMENTOS
5.2. MODELO GENERAL DE UN SGBD

Conocer de manera concreta cuales son las funciones y ventajas de Sistema
de Gestion de Base de Datos (SGBD)
5.2.3. DESARROLLO
SGBD: Software que permite la creación y manipulación de bases de datos.7
Los SGBD permiten:

Descripción unificada de los datos e independiente de las aplicaciones
 Independencia de las aplicaciones respecto a la representación física de
los datos
 Definición de vistas parciales de los datos para distintos usuarios
 Gestión de la información
 Integridad y seguridad de los datos
Objetivos de técnicas BD Funciones SGBD Componentes SGBD

 Descripción unificada e Definición de datos a Lenguajes de definición de
independiente de los datos varios niveles: esquemas y traductores
 Independencia de las  Esquema lógico asociados.
aplicaciones  Esquema interno
7
http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf (03/Ago/05)
 Definición de vistas  Esquemas externos
parciales
Gestión de la información Manipulación de los datos: Lenguajes de manipulación y

 Consulta traductores asociados.
 Actualización
Gestión y administración Herramientas para:

de la base de datos  Reestructuración
 Simulación
 Estadísticas
 Impresión
Control de:
Integridad y seguridad de  Integridad semántica Herramientas para:
los datos  Accesos concurrentes  Control integridad
 Reconstrucción en caso  Reconstrucción
 de fallo  Control seguridad
 Seguridad (privacidad)
ESQUEMA DE ACCESO DEL SGBD A LOS DATOS
Esquema externo aplicación 1:

CREATE VIEW Administrativo (dni, nombre, salario_men)
AS SELECT dni, nombre, salario/14
FROM Empleado
WHERE tipo=„AD‟
Esquema lógico:
Empleado(dni, nombre, dirección, salario, tipo)
CP: {dni}
Esquema Interno:
Fichero ordenado Empleado con índice primario sobre el campo dni en el
camino h:/disco1/gerencia
Aplicación 1: accede a la información a través del esquema externo 1
SELECT nombre, salario_men

FROM Administrativo
WHERE dni = parámetro
SGBD: control del acceso y resolución de la operación pedida
SO: Manipulación de los controladores de los dispositivos de memoria

secundaria
EJEMPLO
Especificación
Una pequeña inmobiliaria desea mantener información sobre los edificios cuya
venta gestiona. Se quiere saber:
– De cada edificio, el código, la ubicación, el distrito, el propietario, el precio
solicitado por éste y el agente encargado de la venta si ya está asignado.
– De cada propietario, el código, nombre y teléfono.
– De cada agente el DNI, el nombre, la comisión por cada venta, los años de
antigüedad y el teléfono.
Las restricciones que deben cumplirse son las siguientes:

– La comisión de un agente no puede exceder el 3% si su antigüedad es menor
de 3 años.
– No se quiere tener información de propietarios si no se tiene al menos un
edificio para la venta.
Grupos de trabajo:
– El personal de administración tiene acceso a toda la información comentada.
– El jefe de la inmobiliaria sólo desea tener información referente a los edificios
con precio solicitado superior a 5 millones. De cada uno desea el código, la
ubicación, y el distrito.
– El jefe es el único que puede modificar la información de los agentes.
Esquema Lógico (SQL)

CREATE SCHEMA Inmobiliaria
CREATE TABLE Edificios
(Código d_cod PRIMARY KEY,
Ubicación d_ubi NOT NULL,
Distrito d_dis NOT NULL,
Precio d_pre NOT NULL,
Dni_age d_dni FOREIGN KEY REFERENCES Agente
ON UPDATE CASCADE,
ON DELETE NO ACTION Dueño d_cod NOT NULL,
FOREIGN KEY(Dueño) REFERENCES Propietario (cod)
ON UPDATE CASCADE ON DELETE CASCADE)
CREATE TABLE Propietarios

(Cod d_cod PRIMARY KEY,
Nombre d_nom NOT NULL,
Teléfono d_tel NOT NULL)
CREATE TABLE Agentes

(Dni_age d_dni PRIMARY KEY,
Comisión d_com,
Años d_años NOT NULL,
Tel d_tel NOT NULL,
CHECK NOT (años < 3 AND comisión > 3))
CREATE ASSERTION no_propet_sin_edificios CHECK NOT EXISTS

(SELECT * FROM Propietarios WHERE cod NOT IN (SELECT Dueño FROM
Edificio))
Esquemas Externos (SQL)

GRANT ALL ON Edificios TO PUBLIC;
GRANT ALL ON Propietarios TO PUBLIC;
GRANT SELECT ON Agentes TO PUBLIC;
ESQUEMA EXTERNO DEL JEFE:
CREATE VIEW más_de_5 AS
SELECT código, ubicación, distrito
FROM Edificios
WHERE E.precio >= 5000000;
GRANT ALL ON más_de_5 TO Jefe;
GRANT ALL ON Agentes TO Jefe;
+ El resto de tablas del esquema lógico (excepto edificios)
ESQUEMA EXTERNO DEL PERSONAL ADMINISTRACIÓN :
Todas las tablas del esquema lógico
Esquema Físico
Edificios :
Fichero disperso por dni_age
Índice B+ sobre (distrito + precio)
Propietarios
Fichero disperso por cod
Índice B+ sobre nombre
Agentes
Fichero desordenado (se suponen pocos agentes).
Proceso de Acceso

A23-ER5 Examen Rápido de SGBD.
Realizar un cuestionario de 5 preguntas del tema 5.2 y dictárselas a los
alumnos para que las contesten.
b) Producto esperado: Preguntas contestadas
c) Fecha inicio:
d) Fecha entrega:

Examen Rápido de SGBD 5 puntos
compañeros
Total 5 Puntos

Reafirmar los conceptos básicos de un SGBD
http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf
5.2.7. DOCUMENTOS
5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y

RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS.
Entender el mecanismo de las consultas distribuidas.
5.3.3. DESARROLLO
PROCESAMIENTO DISTRIBUIDO DE CONSULTAS

En el caso de sistemas centralizados, el criterio principal para determinar el
coste de una estrategia especifica en el numero de accesos al disco. En un
sistema distribuido es preciso tener en cuenta otros factores, como son:
 El coste de transición de datos en la red.
 El beneficio potencial que supondría en la ejecución el que varias
localidades procesaran en paralelo partes de la consulta.
El coste relativo de la transferencia de datos de la red y la transferencia de
datos entre la memoria y el disco varia en forma considerable, dependiendo
del tipo de red y de la velocidad de los discos. Por tanto, en un caso general,
no podemos tener en cuenta sólo los costes del disco o los de la red. Es
necesario llegar a un equilibrio adecuado entre los dos.
Repetición y fragmentación
Consideramos una consulta muy sencilla: “encontrar todas las tuplas de la
relación deposito”. Aunque la consulta es muy simple, de hecho es trivial; su
procesamiento no es trivial, ya que es posible que la relación deposito esté
fragmentada, repetida o las dos cosas. Si la relación deposito está repetida, es
preciso decidir que copia se va a utilizar. Si ninguna de las copias esta
fragmentada, se elige la copia que implica coste de transmisión más reducidos.
Pero si una copia esta fragmentada, la elección no es tan sencilla, ya que es
preciso calcular varios productos o uniones para reconstruir la relación
deposito. En tal caso, el numero de estrategias para este ejemplo sencillo
puede ser grande. De hecho, la elección de una estrategias puede ser una
tarea tan compleja como hacer una consulta arbitraria.
La transparencia de la fragmentación implica que el usuario puede escribir una
consulta como esta:
σ nombre – sucursal = “Hillside” (deposito)
Puesto que deposito está definido como

deposito1 deposito2 la expresión que resulta del esquema de traducción
de nombre es:
σ nombre – sucursal = “Hillside” deposito1 deposito2
La expresión que resulta es
σ nombre – sucursal = “Hillside” (deposito1) σ nombre – sucursal = “Hillside” (deposito2)
la cual incluye dos subexpresiones. La primera incluye solo deposito 1 y, por
tanto, puede ser calculado en la localidad Valleyview.
Existe aun una optimización que se puede hacer calculando
σ nombre – sucursal = “Hillside” (deposito1)
pues que deposito1 tiene solamente tuplas pertenecientes a la sucursal de

Hillside, podemos eliminar la operación de selección. Calculando
σ nombre – sucursal = “Hillside” (deposito2)
podemos aplicar la definición del fragmento deposito2 para obtener

σ nombre – sucursal = “Hillside” (σ nombre – sucursal = “Hillside” (deposito))
Esta expresión es el conjunto vació, independientemente del contenido de la

relación deposito.
Así, nuestra estrategia final para la localidad Hillside consistirá en devolver
deposito1 como resultado de la consulta.
Procesamiento de intersección simple
Considerar la expresión en álgebra relacional:
cliente |X| deposito |X| sucursal
Suponemos que ninguna de las tres relaciones estan repetidas o fragmentada

y que cliente esta almacenada en la localidad Lc, deposito en la Ld y sucursal
en la Lb. Sea LI la localidad donde se origino la consulta. El sistema debe
producir el resultado en la localidad LI. Entre las posibles estrategias para
procesar esta consulta se encuentra las siguientes:
 Enviar copias de las tres relaciones a la localidad LI.

 Enviar una copia de la relación cliente a la localidad L d y calcular cliente
|X| deposito de Lb. Enviar cliente |X| deposito de Ld a Lb, donde se
calcula (cliente |X| deposito) |X| sucursal. El resultado de esta operación
es enviado a LI.
 Pueden elaborarse estrategias similares a la anterior al intercambiar los
papeles de Lc, Ld, y Lb.
No puede garantizarse que una estrategia sea la mejor en todos los casos.
Entre los factores que deben tomarse en cuenta están la cantidad de datos que
debe transmitirse, el coste de transmitir un bloque de datos entre dos
localidades determinadas y la velocidad de procesamiento relativa en cada
localidad. Considerar las dos primeras estrategias arriba mencionadas. Si se
envía las tres relaciones a LI y existen índices para ellas, pueden ser necesario
volver a crear estos índices en LI. Esto requiere tiempo extra de procesamiento
y mas accesos al disco. Sin embargo, la segunda estrategia tiene la desventaja
de que una relación potencialmente grande (cliente |X| deposito) debe
transmitirse desde Ld a Lb. Esta relación repite los datos de domicilio de un
cliente una vez por cada cuenta que tenga el cliente. Así, la segunda estrategia
puede requerir la transmisión de un volumen de datos mayor que la primera
estrategia.
Estrategias de intersección utilizando el paralelismo

Consideramos un producto de cuatro relaciones:
r1 |X| r2 |X| r3 |X| r4
donde la relación ri esta almacenada en la localidad Li. Suponemos que el

resultado ha de presentarse en la localidad L1. existen, por supuesto, muchas
estrategias que se pueden considerar. Por ejemplo, se puede enviar r 1 a L2 y
calcular r1 |X| r2 en L2. Al mismo tiempo se puede enviar r3 a L4 y calcular r3 |X|
r4 en L4.
La localidad L2 puede enviar tuplas de (r1 |X| r2) a L1 conforme se vayan
produciendo, en vez de esperar a que se calcule el producto completo. De
forma similar, L4 puede enviar tuplas de (r3 |X| r4) a L1. Una vez que las tuplas
de (r1 |X| r2) y (r3 |X| r4) lleguen a L1, esta localidad podrá empezar el calculo de
(r1 |X| r2) |X| (r3 |X| r4) en paralelo con el calculo de (r1 |X| r2) en L2 y de (r3 |X| r4)
en L4.
Estrategia de semiinterseccion
Suponer que deseamos calcular la expresión r1 |X| r2, donde r1 y r2 están
almacenados en las localidades L1 y L2 respectivamente. Sean R1 y R2 los
esquemas de r1 y r2. Suponer que queremos obtener el resultado en L 1. Si hay
muchas tuplas de r2 que no interseccionan con ninguna de r1, entonces el envió
de r2 a S1 requiere el envió de tuplas que no contribuyen al resultado. Es
conveniente borrar tales tuplas antes de enviar los datos a L 1, particularmente
si los costes de la red son muy elevados.
Para hacerlo vemos la siguiente estrategia:
1. Calcular temp1 II R1 ∩ R2 (r1) en L1.

2. Enviar temp1 de L1 a L2.
3. Calcular temp2 de L2 a L1.
4. Calcular r1 |X| temp2 en L1. Este es el resultado de r1 |X| r2.
Antes de considerar que esta estrategia es eficiente, verificamos que

obtenemos la respuesta correcta. En el paso 3, temp2 tiene el resultado de r2
|X| II R1 ∩ R2 (r1). En el paso 5, calculamos:
r1 |X| r2 |X| II R1 ∩ R2 (r1)
Puesto que el producto es conmutativo y asociativo, podemos volver a

escribirlo como:
(r1 |X| II R1 ∩ R2 (r1))|X| r2
como r1 |X| II (R1 ∩ R2) (r1)= r1, la expresión anterior es, hecho, igual a r1 |X| r2.
La estrategia anterior es ventajosa particularmente cuando en el producto
participan relativamente pocas tuplas de r2. Es probable que suceda esta
situación si r1 es el resultado de una expresión de álgebra relacionan que
contenga la selección. En tal caso, temp2 puede tener de una considerable,
menos tuplas que r2. El ahorro de costes viene de tener que enviar solo temp2,
en vez de todas las de r2, a L1. Al enviar temp1 a L2, se produce un coste
adicional. Si una pequeña fracción de tuplas de r2 contribuye suficientemente al
producto, el tiempo extra de enviar temp1será contrarrestado por el ahorro que
se produce al enviar solo una fracción de tuplas en r2.
Esta estrategia es conocida como una estrategia de semiproducto, después del
operador de semiproducto, indicado por |X, de álgebra relacional. El
semiproducto de r1 con r2, indicado por r1 |X| r2, es:
IIR (r1 |X| r2)
Así, r1 |X r2 selecciona las tuplas de r1 que contribuyeron a r1 |X| r2. en el paso

3 anterior, temp2 = r2 |X r1.
La estrategia anterior puede ser ampliada a unas series de pasos de
semiinterseción, para la intersección de varias relaciones. Se ha desarrollado
una teoría muy amplia referente al uso de semiproductos para optimizar a las
consultas. Las notas bibliograficas hacen referencia a partes de esa teoría.
RECUPERACIÓN EN SISTEMAS DISTRIBUIDOS

Hemos definido una transacción como una unidad de programa cuya ejecución
conserva la consistencia de una base de datos. Una transacción debe
ejecutarse de forma atómica. Es decir, se ejecutan completamente todas las
instrucciones de la transacción, o no se ejecuta ninguna. Además, en el caso
de ejecución concurrente, el efecto de ejecutar una transacción debe ser el
mismo que si se ejecutara sola en el sistema.
Estructura del sistema

Cuando se tiene un sistema de base de datos distribuidos, es cuando mas
difícil garantizar la propiedad de atomicidad de una transacción. Esto se debe a
que es posible que participen varias localidades en la ejecución de una
transacción. El fallo de una de estas localidades o el fallo de la linea de
comunicación entre ellas, puede dar como resultado un calculo erróneo.
La función del gestor de transacción de un sistema de base de datos distribuido
es asegurar que la ejecución de las distintas transacciones de un sistema
distribuido conserve la atomicidad. Cada localidad cuenta con su propio gestor
de transacciones local. Los distintos gestores de transacciones cooperan para
ejecutar las transacciones globales. Para comprender como puede
estructurarse un gestor de este tipo, definiremos un modelo abstracto para un
sistema de transacciones. Cada localidad del sistema contiene dos
subsistemas:
 Gestor de transacciones, cuya funcion es gestionar la ejecución de
aquellas transacciones (o subtransacciones) que accedan a datos
almacenados en esa localidad. Observamos que cada transacción
puede ser bien una transacción local (es decir, que se ejecuta sólo en
esa localidad), parte de una transacción global (es decir, que se ejecuta
en varias localidades).
 Coordinador de transacciones, cuya función es la de coordinar la
ejecución de varias transacciones (tanto local como global) iniciadas en
esa localidad.
La arquitectura general del sistema se ilustra en la siguiente Figura.

La estructura de un gestor de transaciones es similar en muchos aspectos a la
que se utiliza en el caso de un sistema centralizado. Cada gestor de
transacciones se encarga de:
 Mantener una bitácora por la recuperación.
 Participar en un esquema de control de concurrencia apropiado para
coordinar la ejecución en paralelo de las transacciones que se ejecuten
en esa localidad.
Como veremos, los esquemas, tanto de recuperación como de concurrencia,
deben modificarse para tomar en cuenta la distribuciones de transacciones.
El subsistema coordinador de transacciones no se necesita en el sistema
centralizado, ya que las transacciones tienen acceso a datos de una sola
localidad. Como su nombre indica, un coordinador de transacciones se encarga
de coordinar todas las transacciones que se inicien en esa localidad. Para cada
una de estas transacciones, el coordinador debe:
 Iniciar la ejecución de la transacción.
 Dividir la transacción en varias subtransacciones, las cueles ha de
distribuir en las localidades apropiadas para su ejecución.
 Coordinar la terminación de la transacción, ya sea que quede ejecutada
o abortada en todas las localidades.
Robustez
Un sistema distribuido puede sufrir el mismo tipo de fallos que un sistema
centralizado (por ejemplo, fallo de memoria, fallo del disco). Sin embargo, en
una configuración distribuida es necesario prever otro tipo de fallos, como
pueden ser:
 El fallo total de una localidad.
 La interrupción de una línea de comunicación.
 Perdida de mensajes.
 Fragmentación de la red.
Por tanto, para que el sistema sea robusto, es necesario que detecte
cualquiera de estos fallos, que reconfigure el sistema de manera que pueda
reanudarse el proceso y que se recupere una vez que haya sido reparado el
procesador o ola línea de comunicación afectados.
En general, no es posible distinguir entre la interrupción de una línea de
comunicación, el fallo total de una localidad, la perdida de mensajes o la
fragmentación de la red. Por lo general, es posible detectar que existe un fallo,
pero resulta difícil identificar el tipo del que se trata. Por ejemplo, suponemos
que la localidad L1 no se puede comunicar con la L2. Una posibilidad es que la
L2 se encuentre fuera de servicio, pero también es factible que se haya
interrumpido la línea de comunicación entre L1 y L2.
Suponemos que la localidad L1 se da cuenta de que existe un fallo. En ese
momento debe iniciar un procesamiento de reconfiguración del sistema que le
permita continuar con sus operaciones normales.
 Sin en la localidad que esta fuera de servicio se almacena información
repetida, debe actualizarse el catalogo de manera que las consultas no
hagan referencia a la copia que se encuentra en dicha localidad.
 Si, en el momento de presentarse el fallo existían transacciones activas
en la localidad que quedo fuera de servicio, deben abortarse. Es
conveniente abortar estas transacciones tan pronto como sea posible, ya
que puede darse el caso de que hayan puesto bloqueos a información
que se encuentra el localidades que siguen activas.
 Si la localidad que quedo fuera de servicio en el distribuidor central de
algún subsistema, es preciso “elegir” un nuevo distribuidor. Los
distribuidores centrales pueden ser, por ejemplo, asignadores de
nombres, coordinadores de concurrencia o detectores de bloqueo
globales.
En general, no es posible distinguir entre los fallos en las líneas de

comunicación de la red y de las localidades. Por tanto, el esquema de
reconfiguracion que se adopte debe estar diseñado para que funcione
correctamente aun cuando la red quede fragmentada. En particular es preciso
evitar que se presenten las siguientes situaciones:
 Elección de dos o más distribuidores centrales en distintos fragmentos.

 Actualización de un dato repetido en más de un fragmento de la red.
También es necesario tener cuidado al reintegrar al sistema una localidad o

línea de comunicación separada. Cuando una localidad que quedo fuera de
servicio se recupera, debe iniciar un procesamiento de actualización de sus
tablas de sistema para que reflejen los cambios que tuvieron lugar mientras
estaba inactiva. Si la localidad tenia copias de datos, debe obtener los valores
actuales de todos ellos y asegurarse de recibir las actualizaciones futuras. Esto
es más complicado de lo que parece, ya que es posible que se actualicen los
datos que se están procesando mientras que el sistema se recupera.
Una solución sencilla es suspender temporalmente todas las operaciones del
sistema mientras la localidad que quedo fuera de servicio se reintegre a el. Los
problemas que acarrea esta suspensión es la mayor parte de las aplicaciones
no pueden aceptarse. Es preferible representar a las tareas de recuperación
como una serie de transacciones. En este caso, el subsistema de control de
concurrencia y el manejo de transacciones puede encargarse de realizar de
manera fiable la reintegración de la localidad.
Si se recupera una línea de comunicación interrumpida, es posible que se unan
de nuevo dos fragmentos de la red. Dado que la fragmentación de una red
limita las operaciones que pueden permitirse en algunas localidades, o en
todas ellas, es conveniente enviar un mensaje a todas ellas informando sin
dilatación que la línea se recuperó. En las redes en que no se permitá el envió
de este tipo de mensaje puede utilizarse otros esquemas
PROTOCOLO DE COMPROMISO
Para garantizar la atomicidad, es preciso que todas las localidades en las que
haya ejecutado la transacción T coincidan en el resultado final de la ejecución.
T debe quedar ejecutada o abortada en todas las localidades. Para garantizar
esta propiedad, el coordinador de transacciones encargado de T debe ejecutar
un protocolo den compromiso.
Entre los mas comunes y mas ampliamente usados esta el compromiso de
dos–fases. Otra alternativa es el protocolo de compromiso de tres–fases, el
cual impide ciertas desventajas del compromiso de dos fases, pero añade
complejidad y tiempo extra.
Compromiso de dos – fases
sea T una transacción que se inicio en la localidad L i, y sea Ci el coordinador de
transacciones de esa localidad.
El protocolo de compromiso
Cuando T una termina de ejecutarse, es decir, cuando todas las localidades en
las que se ejecuto T informan a C1 que T llego a su termino, Ci inicia el
protocolo de compromiso de dos – fases.
 Fase 1. C1 añade el registro <preparar T> a la bitácora y la graba en
memoria estable. Una vez hecho esto envía un mensaje de preparar T a
todas las localidades en las que se ejecuto T, al recibir el mensaje, el
gestor de transacciones de cada una de esas localidades determina si
esta dispuesto a ejecutar la parte de T que le correspondió. Si no esta
dispuesto, este añade un registro <no T> la bitácora y a continuación
enviará un mensaje abortar T a C1. Si la respuesta es afirmativa
agregara un registro < T lista > a la bitácora y grabara todos los
registros de bitácora que corresponden a T en memoria estable. Una vez
hecho esto, responderá a C1 con el mensaje T lista.
 Fase 2. Una vez que todas las localidades hayan respondido al menaje
preparar T en enviado a Ci, o después de un intervalo de tiempo,
previamente especificado, Ci puede determinar si la transacción T puede
ejecutarse o abortarse. Si Ci recibió el mensaje T lista de todas las
localidades que participan, la transacción T puede ejecutarse. En caso
contrario, la transacción T debe abortarse. Según haya sido el veredicto,
se agregara un registro <ejecutar T> o <abortar T> a la bitácora y se
grabara en memoria estable. En este punto, el destino de la transacción
se habrá sallado. A continuación, el coordinador enviara un mensaje
<ejecutar T> o <abortar T> a todas las localidades participantes. Al
recibir este mensaje, cada una de las localidades lo registra en la
bitácora.
Una de las localidades en las que se ejecuto T puede abortar T
incondicionalmente en cualquier momento antes de enviar el mensaje T lista al
coordinador. De hecho, el mensaje T lista es una promesa que hace la
localidad de cumplir con la orden del coordinador de ejecutar T o abortar T.
Una localidad solo puede hacer tal promesa si la información requerida esta ya
en almacenamiento estable. En caso contrario, si la localidad se cayera
después de enviar el mensaje T lista, no seria capaz de cumplir su promesa.
El destino de una transacción esta sellado en el momento en que por lo menos
una de las localidades responde aborto T, ya que se requiere unanimidad para
ejecutar una transacción. Dado que la localidad coordinadora L i es una de las
localidades en las que se ejecuta T, el coordinador puede decidir de forma
unilateral abortar T. El veredicto final en lo que registra (ejecutar o abortar) en
la bitácora y graba esta en la memoria estable. En algunas implementaciones
del protocolo de compromiso de dos – fases, una localidad envía un mensaje
de reconocimiento a T al coordinador al final de la segunda fase del protocolo.
Una vez que el coordinador recibe este mensaje de todas las localidades,
añade el registro <T completo> en la bitácora.
Manejo de fallos
A continuación veremos de manera detallada la forma en que el compromiso

de dos – fases responde a los distintos tipos de fallos.
 Fallo de una localidad participante. En el momento en que una
localidad participante Lk se recupera de un fallo, debe examinar su
bitácora para determinar el destino de aquellas transacciones que se
estaban ejecutado cuando se produjo el fallo. Sea T una de esas
transacciones. Consideramos los siguientes casos:
o La bitácora contiene un registro <ejecutar T>. En este caso, la localidad
ejecuta rehacer (T).
o La bitácora contiene un registro <abortar T>. En este caso, la localidad
ejecuta deshacer (T).
o La localidad contiene un registro < T lista >. En este caso, la localidad
debe consultar con Ci, para determinar el destino de T. Si Ci esta activo,
notificara a Lk ejecutara o aborto de T. A continuación, Lk ejecutara
rehacer (T) o deshacer (T), según sea el caso. Si Ci esta inactivo, Lk
debe interrogar a las demás localidades para intentar determinar el
destino de T. Esto lo hará enviando un mensaje de consulta de estado
de T a todas las demás localidades del sistema. Al recibir uno de estos
mensajes una localidad, deberá consultar su bitácora para ver si T se
realizo allí y en caso de que así haya sido , si se ejecuto o se aborto. A
continuación notificara dicho resultado a Lk. Si ninguna de las
localidades cuenta con la información apropiada (es decir, si T se
ejecuto o aborto), entonces Lk no podrá ejecutar ni abortar T. La decisión
con respecto a T se pospondrá hasta que L k pueda obtener la
información necesaria. De esta forma, Lk deberá seguir mandando el
mensaje de consulta a las otras localidades de forma periódica hasta
que alguna de las localidades que contienen la información requerida se
recupere. Se puede hacer mención de que la localidad en la que reside
Ci siempre tendrá la información requerida.
o La bitácora no contiene registro de control (abortar, ejecutar, lista)
referentes a T. Esto implica que Lk tuvo un fallo antes de responder al
mensaje preparar T de Ci. Puesto que el fallo de Lk excluye el envió de
esa respuesta, de acuerdo a nuestro algoritmo, Ci debe abortar T. En
consecuencia, Lk debe ejecutar deshacer (T).
 Fallo del coordinador. Si el coordinador falla en la mitad de la ejecución
del protocolo de compromiso de la transacción T, entonces las localidades
participantes deben decidir de T. Veremos que en algunos casos las
localidades participantes no pueden decidir si ejecutar o abortar T, y, por
tanto, será necesario que estas localidades esperen a que se recupere el
coordinador que fallo.
o Si una localidad activa contiene un registro < ejecutar T > en su
bitácora, entonces T debe ser ejecutada.
o Si una localidad activa contiene un registro < abortar T > en su bitácora,
entonces T debe ser abortada.
o Si alguna localidad activa no contiene un registro < T lista> en su
bitácora, entonces el coordinador que fallo Ci no puede haber decidido
ejecutar T. Esto se debe a que una localidad que no tiene un registro < T
lista > en su bitácora no puede haber enviado un mensaje de T lista a
Ci. Sin embargo, el coordinador puede haber decidido abortar T, y no
ejecutar T. Es preferible abortar T antes que esperar que Ci se recupere.
o Si no ocurre ninguno de los casos anteriores, entonces todas las
localidades activas deben tener en sus bitácoras un registro < T lista >,
y ningún registro de control adicional (tales como < abortar T > o <
ejecutar t >). Puesto que el coordinador ha fallado, es imposible
determinar hasta que el coordinador se recupere si se produjo una
decisión, y si la hubo, cual fue. De esta forma, la localidad activa debe
esperar a que Ci se recupere. Debido a que el destino de T continua en
duda, T puede continuar reteniendo recursos del sistema. Por ejemplo,
si se utiliza bloqueos, T puede mantener bloqueos sobre los datos en las
localidades activas. Esta situación no es deseable puesto que puede
pasar horas o días hasta que Ci este activo de nuevo. Durante este
tiempo, otras transacciones pueden haber sido forzadas a esperar a T.
Como resultado tenemos que los datos no estén disponibles no solo en
la localidad del fallo (Ci), sino también en localidades activas. Cuando
mayor es el tiempo que Ci este caído, mayor será el numero de datos
que no estén disponibles. A esta situación se la denomina el problema
de bloqueo debido a que T esta bloqueada, dependiendo de la
recuperación del Ci de la localidad.
 Fallo de un alinea de comunicación. Cuando una línea de comunicación
falla, todos los mensajes que estaban siendo enrutados a través de la línea
no llegan a sus destinos intactos. Desde el punto de vista de las localidades
conectadas a través de esa línea, parece que el fallo corresponde a las
otras localidades. Por tanto, nuestro anterior esquema también se puede
aplicar aquí.
 Fragmentación de la red. Cuando se fragmenta la red, caben dos
posibilidades.
o El coordinador y todos sus participantes queden en un fragmento. En
este caso el fallo no tendrá efecto sobre el protocolo de compromiso.
o El coordinador y sus participantes quedan distribuidos en varios
fragmentos. En este caso se perderán los mensajes entre la
participación y el coordinador, situación que es equivalente a la
interrupción de líneas de comunicación mencionadas anteriormente.
Compromiso de tres – fases
El protocolo de compromiso de tres–fases están diseñado para impedir la
posibilidad de bloqueo en un caso restringido de los fallos posibles. El protocolo
requiere que:
 No puede ocurrir una fragmentación de la red.
 Debe haber al menos una localidad funcionando en cualquier punto.
 En cualquier punto, como máximo un numero K de participantes pueden
caer simultáneamente (siendo K un parámetro que indica la resistencia
del protocolo a fallos en localidades).
El protocolo alcanza esta propiedad de no – bloqueo añadiendo una fase extra,
en la cual se toma una decisión preliminar sobre el destino de T. Como
resultado de esta decisión, se pone en conocimiento de las localidades
participantes cierta información que permite tomar una decisión a pesar del
fallo del coordinador.
El protocolo de compromiso
De la misma forma, sea T una transacción iniciada en la localidad L i y Ci el

coordinador de transacciones en Li.
 Fase 1. esta fase es idéntica a las fase 1 del protocolo de compromiso
de dos – fases.
 Fase 2. si Ci recibe un mensaje abortar T de una localidad participante,
o si Ci no recibe respuesta dentro de un intervalo previamente
especificado de una localidad participante, entonces Ci decide abortar T.
La decisión de abortar esta implementada de la misma forma que en el
protocolo de compromiso de dos – fases. Si Ci recibe un mensaje T lista
de cada localidad participante, tomara la decisión preliminar
“preejecutar” T. La diferencia entre preejecutar y ejecutar radica en que
T puede ser todavía abordar eventualmente. La decisión de preejecutar
permite al coordinador informar a cada localidad participante que todas
las localidades participantes están “listas”. Ci añade un registro <
preejecutar T > a la bitácora y lo graba en un almacenamiento estable.
De acuerdo a esto, Ci envía un mensaje preejecutar T a todas las
localidades participantes. Cuando una localidad recibe un mensaje del
coordinador (ya sea abortar T o preejecutar T), lo registra en su
bitácora, grabando esta información en almacenamiento estable, y envía
un mensaje de reconocimiento a T al coordinador.
 Fase 3. Esta fase se ejecuta solo si la decisión tomada en la fase 2 fue
de preejecutar. Después de que los mensajes preejecutar T se han
enviado a todas las localidades participantes, el coordinador debe
esperar hasta que reciba al menos un numero K de mensajes de
reconocimiento a T. Siguiendo este proceso, el coordinador toma una
decisión de compromiso. Añade un registro < ejecutar T > en su
bitácora y la graba en un almacenamiento estable. De acuerdo a esto, C i
envía un mensaje ejecutar T a todas las localidades participantes.
Cuando una localidad recibe el mensaje, lo registra en su bitácora.
Tal y como en el protocolo de compromiso de dos – fases, una localidad en la
que se haya ejecutado T puede abordar T incondicionalmente en cualquier
momento, antes de enviar el mensaje T lista al coordinador. El mensaje T lista
es, de hecho, una promesa hecha por la localidad para seguir la orden del
coordinador de ejecutar T abortar T. En contraste con el protocolo de
compromiso de dos – fases, en el que el coordinador puede incondicionalmente
abortar T en cualquier momento antes de enviar el mensaje ejecutar T, el
mensaje preejecutar T en el protocolo de compromiso de tres – fases, es una
promesa hecha por el coordinador para seguir la orden del participante de
ejecutar T.
Puesto que la fase 3 siempre induce a una decisión de compromiso, parece

que no es muy útil. El papel de la tercera fase toma importancia por la forma en
que el protocolo de tres – fases maneja los fallos.
En algunas implementaciones del protocolo de compromiso de tres – fases, al
recibir una localidad el mensaje ejecutar T, esta envía un mensaje de recibo t
al coordinador. (Observamos el uso de recibo para destituirlo de los mensajes
de reconocimiento usados en la fase2.) Cuando el coordinador recibe el
mensaje de recibo T de todas las localidades, añade el registro < T completo
> a la bitácora.
Transacciones distribuidas
Dados el creciente interés y creciente utilización de los sistemas distribuidos,
existe la necesidad de acceder y modificar datos distribuidos. Considere un
sistema en el que se almacena la información de clientes en un servidor y la de
productos en otro. Cuando un cliente adquiere un artículo, es necesario iniciar
una transacción que registre el pedido en el servidor incluyendo la información
de cliente y que, asimismo, decremente el nivel de stock en el servidor que
almacene los datos de productos. Esta transacción debe ser una única
transacción desde el punto de vista lógico, pero está físicamente distribuida
entre dos servidores. Necesitamos una forma de asegurar que la transacción
distribuida opere de la misma manera en que lo haría una transacción local y
que respete las propiedades ACID (Propiedades de las transacciones)de
cualquier transacción.
El enfoque que utilizaremos estará basado sobre lo que se denomina protocolo
de confirmación en dos fases.
PROTOCOLO DE CONFIRMACIÓN EN DOS FASES

La implementación de transacciones distribuidas requiere un esfuerzo adicional
de planificación y control. El servicio que proporciona la funcionalidad de
confirmación en dos fases se basa en un servidor SQL Server conocido con el
nombre de servidor de confirmación. Este servidor está a cargo de mantener el
estado actual de la transacción y los otros servidores lo emplean para
determinar el éxito o fracaso global de la misma.
La transacción atraviesa los siguientes pasos:
1. La transacción da comienzo y se identifica a sí misma ante el servidor de
confirmación.
2. Se emiten las instrucciones de modificación de datos en los servidores
implicados.
3. El servidor de confirmación recopila información acerca de cada servidor y
agrega a todos ellos a la transacción.
4. La transacción indica que desea fmalizar, emitiendo una instrucción
PREPARE TRANSACTION.
5. Fase 1: durante la primera fase de la confirmación, todos los servidores
comunican al servidor de confirmación que están listos para confirmar.
6. Fase 2: se emite una instrucción COMMIT TRANSACTION a todos los
servidores, después de haber llegado a la conclusión de que todos ellos
están preparados.
Si ocurre un error entre las dos fases, todos los servidores se comunican con el
servidor de confirmación para ver si la transacción va a ser confiimada o
cancelada. He aquí una lista de alguno de los errores que pueden tener lugar
entre las fases 1 y 2:
 Uno de los servidores registrados se para. La solicitud de confirmación

en dicho servidor falla, porque no se puede establecer comunicación con
el servidor. Sin embargo, es posible que la solicitud para efectuar la
confirmación haya tenido éxito. El servidor detenido utiliza probe para
identificar qué acción debe tomar.
 El servidor de confirmación deja de estar disponible. Es necesario
deshacer la transacción. La aplicación ejecuta una instrucción
ROLLBACK TRANSACTION para cada servidor registrado.
 Se produce una detención tanto de un servidor registrado como del
servidor de confirmación. La aplicación ejecuta una instrucción
ROLLBACK TRANSACTION en todos los servidores que estén todavía
activos. El servidor registrado que sufrió la detención se comunica con el
servidor de confirmación, que no está al tanto de que la transacción se
ha comRJetadq, Y que ordena al servidor registrado que deshaga la
transacción.
Si uno de los servidores SQL registrados no puede comunicarse con el servidor

de confirmación, se marca como sospechosa la base de datos correspondiente.
Cuando el servidor de confirmación vuelve a estar «visible», el servidor
afectado debe ser reiniciado para poder recuperar la base de datos y la
transacción dudosa.
Sólo se contacta una vez con el servidor de confirmación cuando tienen lugar
dichos fallos; el servidor de confirmación devuelve el estado de la transacción,
según la última actualización que la aplicación de control haya efectuado.
Afortunadamente, la parte dura de la tarea ha sido realizada por Microsoft, que
ha implementado el servicio de confirmación en dos fases. Lo único que
necesitamos es entender cómo interactuar con él para conseguir los resultados
deseados. Podemos, para ello, hacer uso de las funciones de confirmación en
dos fases disponibles en la biblioteca de e9lace dinámico DB-Library o en el
servicio DTC de Microsoft.
EL COORDINADOR DE TRANSACCIONES DISTRIBUIDAS (MS DTC)
El Coordinador de transacciones distribuidas de Microsoft (DTC, Distributed

Transaction Coordinator) se instala junto con SQL Server y el Agente SQL.
Pueden ejecutar" se varios servicios DTC dentro de una red; si se desea,
puede ejecutarse uno por cada servidor SQL Server. Se puede controlar qué
servidor DTC emplear desde el Panel de control del cliente. Haciendo uso de
múltiples servidores DTC, puede distribuirse la carga de trabajo.
El servidor MS DTC es el servidor de confmnación para las transacciones

distribuidas y hace uso de un archivo de registro para-almacenar el resultado
de todas las transacciones que hayan utilizado sus servicios.
LA IMPORTANCIA DE MSDTC.lOG
No debe, bajo ninguna circunstancia, modifi¿arse o borrarse el archivo

IMSDTC.lOG. Si se borra el archivo, el sistema no funcionará.
INSTALACIÓN
Durante la instalación del servicio (que tiene lugar como parte de la instalación
del servidor), las DLL y los archivos ejecutables del servidor DTC se copian al
subdirectorio \BIRM del directorio raíz de SQL. El archivo de registro de DTC se
instala en el directorio \DATA, bajo la raíz de SQL.
PRECAUCIÓN
Antes de instalar un pJiquete de servicio o actualización, asegúrese de que se
hayan resuelto todas las transacciones dudosas. Microsoft se reserva el
derecho de cambiar el formato del archivo de registro DTC entre una versión y
otra.
Una vez iniciado el servicio DTC, puede realizarse una prueba simple para
verificar que todo está funcionando como debe.
Abra la ventana Estadísticas de la consola de administración MS DTC y
observe el contador Actual/Activas mientras abre una ventana de consulta y
ejecuta BEGIN DISTRIBUTED TRAN. Cada vez que el contador se incremente,
emita una instrucción ROLLBACK; el contador debería volver a 0.
UTILIZACIÓN
Afortunadamente, no necesitamos preocuparnos de los protocolos subyacentes
ni de las funciones que se invocan para que tenga lugar una transacción
distribuida. Como desarrolladores, basta con cambiar muy sutilmente nuestra
forma de programar, utilizando BEGIN DISTRIBUTED TRAN en lugar de la
instrucción más usual BEGIN TRAN.
Al ejecutar BEGIN DISTRIBUTED TRAN, la transacción se registra ante el
servidor MS DTC. Esta acción nos convierte en el origen de la transacción y
nos asigna la responsabilidad de enviar las instrucciones COMMIT o
ROLLBACK al DTC, que entonces se encargará de gestionar la terminación de
la transacción en todos los servidores implicados.
Los servidores SQL pueden registrarse en nuestra transacción de una de las
siguientes maneras:
 Un procedimiento almacenado remoto se ejecuta sobre un servidor.

 Proporcionamos un testigo de acoplamiento a nuestra transacción
distribuida.
 Se ejecuta una consulta distribuida.
En las versiones anteriores de SQL Server, la única forma de llevar a cabo

transacciones distribuidas era utilizar procedimientos almacenados :remotos
como éste:
USE pubs
GO
BEGIN DISTRIBUTED TRANSACTION
UPDATE sales
SET qty = qty + 10000
WHERE au_id = 'GAL-06-1269'
EXECUTE remotesrv.pubs.update_sales_qty 'GAL-06-1269', 10000
COMMIT TRAN
GO
NOTA
Para que los procedimientos almacenados remotos se ejecuten siempre dentro
del contexto de una transacción distribuida. Puede utilizarse la opción SET
REMOTE ROC TRANSACTlONS ON. que se establece por separado para
cada conexión, o puede configurarse esta opción globalmente para todo un
servidor utilizando sp_configure 'remote proc trans', ´1´.
Cuando el origen de datos OLE DB de destino de una consulta distribuida

admite ItransactionLocal, la transacción se eleva automáticamente a
transacción distribuida. Sin embargo, si el origen de datos no admite
ItransactionLocal, sólo pueden efectuarse consultas; el origen de datos se
considera como de sólo lectura.
NOTA
Después de haber configurado servidores enlazados, pueden realizarse
transacciones distribuidas sin estar restringidos a ejecutar solamente
procedimientos almacenados remotos.
Solución de problemas
Obviamente, como hemos complicado nuestra transacción y hemos
involucrado más componentes (servidores, red, etc.), tarde o temprano se
producirán problemas (confiamos en que más tarde que temprano).
La forma más sencilla de determinar si un servidor puede comunicarse con un

servidor de confirmación consiste en abrir una ventana de consulta y ejecutar
BEGIN DISTRIBUTED TRANSACTION. Si no puede encontrarse el servicio,
se obtendrá un error, que informará de que el servicio no está disponible.
Si un servidor de confirmación está resultando ser poco fiable para ciertos
clientes, quizás debido a problemas de red transitorios, puede instalarse la
Herramienta de cliente de red DTC en dichos clientes e instalar el servicio DTC
en un servidor más próximo. La Herramienta de cliente de red permite
especifIcar un servicio DTC y un protocolo de red concretos para utilizarlos en
las transacciones distribuidas.
La consola de administración del DTC proporciona un completo conjunto de
estadísticas e información sobre el servicio DTC que se está ejecutando en el
servidor. Esta herramienta proporciona acceso a cinco áreas:
 General. Información de versión, nombre del coordinador y funciones

para arrancar y detener el servicio DTC.
 Transacciones. Las transacciones actualmente activas, junto con su
estado. Desde esta ventana, puede también resolverse una
transacción, forzando su confirmación, abortándola o eliminandola.
 Rastreo. Esta área tiene información de registro del servicio DTC. La
profundidad de la traza se fIja en la ficha Avanzado.
 Estadísticas. Esta área muestra el número actual de transacciones
activas y dudosas, junto con información histórica sobre el número total
de transacciones confirmadas, anuladas, etc.
 Avanzado. Desde esta fIcha, puede controlarse la profundidad de traza,
la velocidad de actualización para la presentación de datos y el tamaño y
ubicación del archivo de registro DTC.
La consola de administración del DTC es la herramienta básica de depuración

de transacciones distribuidas.8
TRANSACCIONES DISTRIBUIDAS CON SQLSERVER (Ejemplo)
En algunas ocasiones es necesario realizar operaciones que afectan a más de

un servidor. Hay casos en los que esto puede ser muy conveniente o
simplemente ser necesario. Llegados a esta necesidad, no podemos dejar de
8
Microsoft SQL Server /, Sharon Bjeletich, Greg Mable, et al., PRENTICE HALL
plantearnos un montón de cuestiones, todas ellas complejas. Si tengo dos
conexiones a mi base de datos y abro una transacción en la primera, ¿puedo
compartirla con la segunda?, y si no puedo, ¿hay posibilidades de garantizar
que o se realicen las dos o no se realice ninguna?.
Esto nos lleva, simplificando bastante el problema, a que tendría mi
aplicación que garantizar que va a poder validar la segunda transacción, antes
de validar la primera. Esto resumido y simplificado es lo que podríamos
denominar confirmación en dos pasos.
No obstante no es nada sencillo desde el punto de vista técnico responder
a esa pregunta.
Microsoft Transaction Server, precisamente resuelve este problema, lo
resuelve no ya a nivel de base de datos, sino a nivel de objetos, pero en
nuestro caso no vamos a tratar (de momento) de MTS, sino que nos vamos a
centrar en como Sql-Server resuelve el problema. En otro artículo, espero que
a no mucho tardar, podremos hablar de COM+ y Visual Studio .NET, y como
crear componentes transaccionales que nos permitan olvidarnos más de
nuestra base de datos.
Pasos previos.
Antes de garantizar que vamos a poder realizar transacciones distribuidas,
incluso antes de siquiera intentarlo necesitaremos dos servidores. Nos servirán
también dos instancias (aunque el ejemplo está hecho y probado con dos
servidores).
En el caso del ejemplo, los dos servidores se llaman 'A8B8O2' Y
'Maricarmen' respectivamente. Sí , lo sé, ¿que nombre es A8xde?, pues la
verdad es que no sé, metí el cd de Windows-Xp, le dí siguiente-siguiente, y no
leí ni un mensaje, tampoco podía esperar mucho más. Podría cambiarlo, de
hecho no se vería afectado mi Sql, ya que tengo Sql-server 2000, pero no lo
voy a hacer, :-).
Los dos servidores están físicamente conectados en red, en una red local.
Para comunicarlos he usado los procedimientos almacenados
sp_addlinkedserver y sp_addlinkedsrvlogin, con el código que podéis ver a
continuación :
sp_addlinkedserver @server = 'maricarmen'

, @srvproduct= 'SQLServer'
, @provider = 'SQLOLEDB'
, @datasrc = 'maricarmen'
, @catalog = 'pruebas'
Con esto añado el servidor vinculado maricarmen, que es un Sql-server, y el

catálogo inicial será pruebas, no es necesario ya que de todas formas voy a
usar el nombre en formato completo 'Servidor.BaseDeDatos.Propietario.Tabla',
pero bueno, todo sea por que el ejemplo quede más claro.
Con el servidor vinculado, tengo que añadir un login, podría pedir que fuese
con las mismas credenciales o no, en nuestro caso no. Así que añadimos un
login a ese servidor vinculado mediante el siguiente código :
sp_addlinkedsrvlogin @rmtsrvname='maricarmen'
, @useself ='False'
, @rmtuser='sa'
, @rmtpassword='javier'
Inmediatamente después, comprobamos que efectivamente estamos

conectados y que la conexión funciona, para ello, nada mejor que ejecutar una
consulta.
Select * From maricarmen.pruebas.dbo.pruebas
Además de esto hay que tener en cuenta:
Para que se puedan ejecutar transacciones distribuidas debemos tener
activados los servicios de MS DTC de ambos servidores, o el servidor remoto
debe implementar la interfaz ItransacionLocal. Consulte los books on line para
mayor y más detallada información.
Podemos explicitar Begin Distributed Trans o simplemente anidarla dentro de
una transacción local, el sistema abre una transacción distribuida en cualquier
caso siempre que el parámetro de sp_configure 'remote proc trans' esté
habilitado.
Es conveniente que SET XACT_ABORT esté a ON. Este parámetro en mi
opinión está mejor a off siempre, si no el sistema rechaza transacciones de
forma implícita y eso no me gusta, pero en este caso no tiene más remedio que
ser así, ya que -entiendo yo- que si se hace un commit, y por ejemplo, se ha
perdido la conexión con el servidor remoto, este commit no puede tener efecto,
y lamentablemente habrá que rechazar toda la transacción.
El coordinador de transacciones distribuidas es un servicio más de Sql-Server.
Para activarlo basta con pulsar play ..
Manos a la obra por fín.

Pues eso, ya estamos en disposición de probar que efectivamente funciona,
que hay transacciones distribuidas y que se anulan tanto si hay rollback manual
como si hay commit y éste no puede ser validado.
USE pruebas
GO
SET xact_abort on
GO
BEGIN TRAN
INSERT INTO maricarmen.pruebas.dbo.pruebas (texto) VALUES('hola')
INSERT INTO pruebas (texto) VALUES ('adiós')
EXEC sp_lock
El resultado de sp_lock es :
51 1 0 0 DB S GRANT
51 8 0 0 DB S GRANT
51 8 0 0 DB S GRANT
51 8 21575115 1 PAG 1:30 IX GRANT
51 8 21575115 1 KEY (03000d8f0ecc) X GRANT
51 8 21575115 0 TAB IX GRANT
51 1 85575343 0 TAB IS GRANT
select object_name(21575115) dá naturalmente pruebas - Ojo, en vuestro

sistema el identificador será seguramente distinto-
En el ordenador remoto, sp_who2 dice lo siguiente...
53 sleeping sa A8B8O2 . pruebas AWAITING COMMAND 1092 0 10/05
01:10:33 Microsoft SQL Server 53
54 RUNNABLE sa A8B8O2 . pruebas SELECT INTO 1432 9 10/05 01:13:12
Analizador de consultas SQL 54
sp_lock en maricarmen nos dice que es el id 53 el que tiene bloqueado el

registro (el que acabamos de insertar), el 54, es la conexión desde el servidor
principal para poder ejecutar sp_lock ... :-D
Por último nuestra prueba consistió en desenchufar físicamente el cable y

hacer commit y el resultado fue :
Servidor: mensaje 8522, nivel 18, estado 1, línea 1

Transacción distribuida anulada por MSDTC.
Es decir que se comportó de acuerdo a lo esperado9.

A24-EC11 Realizacion de una Base de Datos Distribuida.
Diseñar una Base de datos de 5 tablas cuando mucho y color en dos
servidores un numero equitativo de tablas, enlazar los servidores e intentar
9
http://www.configuracionesintegrales.com/miguele/trdissqlserver.asp?articulo=149 (09-08-05)
hacer una consulta a una tabla que este en el servidor donde yo no este
trabajando.
b) Producto esperado: Base da tos distribuida
c) Fecha inicio:
d) Fecha entrega:
e) Forma de entrega: Base de datos.

Estructura de la base de datos 5 puntos
Configuración de los 5 puntos

Realizacion de una Base de servidores
Datos Distribuida 10 puntos
Conexion de los servidores
Pruebas a la base de datos 10 puntos

Total 30 Puntos

Verificar las ventajas que ofrece una Base de Datos Distribuida a diferencia de
una Base de datos Relacional.
http://www.configuracionesintegrales.com/miguele/trdissqlserver.asp?articulo=149
5.3.7. DOCUMENTOS
UNIDAD TEMATICA 6. TECNOLOGÍAS DE ACCESO A DATOS
6.1. ARQUITECTURAS MULTICAPA y XML

Entender el funcionamiento del lenguaje XML
6.1.3. DESARROLLO
QUE ES XML
Introduccion
XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que

juega un papel fundamental en el intercambio de una gran variedad de datos.
Es un lenguaje muy similar a HTML pero su función principal es describir datos
y no mostrarlos como es el caso de HTML. XML es un formato que permite la
lectura de datos a través de diferentes aplicaciones.
Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a
las demandas más frecuentes por parte de los usuarios. XML sirve para
estructurar, almacenar e intercambiar información.
Conceptos
Entre las tecnologías XML disponibles se pueden destacar:
XSL: Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar

cómo debería estar estructurado el contenido, cómo debería ser diseñado el
contenido de origen y cómo debería ser paginado en un medio de presentación
como puede ser una ventana de un navegador Web o un dispositivo de mano,
o un conjunto de páginas de un catálogo, informe o libro.
XPath: Lenguaje de Rutas XML, es un lenguaje para acceder a partes de un

documento XML.
XLink: Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos
en documentos XML para crear enlaces entre recursos XML.
XPointer: Lenguaje de Direccionamiento XML, es un lenguaje que permite el

acceso a la estructura interna de un documento XML, esto es, a sus elementos,
atributos y contenido.
XQL: Lenguaje de Consulta XML, es un lenguaje que facilita la extracción de

datos desde documentos XML. Ofrece la posibilidad de realizar consultas
flexibles para extraer datos de documentos XML en la Web.
Cómo funcionan
XSL funciona como un lenguaje avanzado para crear hojas de estilos. Es capaz
de transformar, ordenar y filtrar datos XML, y darles formato basándolo en sus
valores. XPath identifica partes de un documento XML concreto, como pueden
ser sus atributos, elementos, etc. XLink por su lado, describe un camino
estándar para añadir hipervínculos en un archivo XML. Es decir, es un
mecanismo de vinculación a otros documentos XML.
Funciona de forma similar a un enlace en una página Web, es decir, funciona

como lo haría <a href="">, sólo que a href es un enlace unidireccional. Sin
embargo, XLink permite crear vínculos bidireccionales, lo que implica la
posibilidad de moverse en dos direcciones. Esto facilita la obtención de
información remota como recursos en lugar de simplemente como páginas
Web. XPointer funciona como una sintaxis que apunta a ciertas partes de un
documento XML, es como una extensión de XPath. Se utiliza para llegar a
ciertas partes de un documento XML.
Primero, XLink permite establece el enlace con el recurso XML y luego es

XPointer el que va a un punto específico del documento. Su funcionamiento es
muy similar al de los identificadores de fragmentos en un documento HTML ya
que se añade al final de una URI y después lo que hace es encontrar el lugar
especificado en el documento XML.
Al ser XPointer una extensión de XPath, XPointer tiene todas las ventajas de
XPath y además permite establecer un rango en un documento XML, es decir,
con XPointer es posible establecer un punto final y un punto de inicio, lo que
incluye todos los elementos XML dentro de esos dos puntos.
Finalmente, XQL, lenguaje de consultas, se basa en operadores de búsqueda

de un modelo de datos para documentos XML que puede realizar consultas en
infinidad de tipos de documentos como son documentos estructurados,
colecciones de documentos, bases de datos, estructuras DOM, catálogos,
etc.10
XML Y SQL SERVER 2000
Una de las prestaciones más esperadas de SQL 2000 ha sido el soporte para
XML (eXtensible Markup Language o Lenguaje de marcas extensible).
Paradójicamente, es una característica cuyo valor práctico e inmediato no
acaba de estar claro. Por una parte, todo el mundo ha oído hablar de ese
lenguaje tan especial que haría de puente entre el resto de los lenguajes y, por
otra, la práctica totalidad de sistemas gestores de bases de datos relacionales
proclaman soportar el estándar XML. Pero veamos, ¿cuándo, dónde y por qué
habría que usar XML?
XML, el estándar de Internet para intercambio de información, fue diseñado

para publicar tipos de datos independientemente de la plataforma empleada,
permitiendo así la interoperabilidad y el comercio electrónico. En las páginas
web, XML también separa el contenido de la presentación y, de este modo,
permite un sistema estándar para definir e intercambiar datos entre
aplicaciones y bases de datos. (En el artículo «XML: el último gran invento»,
publicado en exclusiva en esta sede web, hallará las ventajas de utilizar XML
para separar la presentación de los contenidos).
Al tratarse de un lenguaje construido para la definición de otros lenguajes de

marcas o códigos (markup languages), su primera ventaja proviene por la
10
http://www.netyweb.com/contenido.asp?vcon=33 (05-aGO-05)
aceptación de algún lenguaje definido mediante XML, o por la aceptación del
propio estándar XML, y después por la proliferación de utilidades, herramientas
e infraestructura que sin duda surgirán para soportar su utilización. Aunque
XML ya dispone de algunos lenguajes definidos excelentes --como BizTalk,
DSML (Directory Markup Language o Lenguaje de marcas de directorio) y
SOAP (Simple Object Access Protocol o Protocolo de acceso a objetos
simples)--, no es un lenguaje al alcance de cualquiera, especialmente de
quienes están acostumbrados a desarrollar aplicaciones Windows de 32 bits
con los productos más conocidos de Microsoft. Si hablamos de transferir datos
a través de redes locales, la opción más lógica parecen ser las tablas de
resultados ADO. Pero, ya metidos de lleno en la era Internet, pocas son las
organizaciones que desean aislarse del resto del mundo. E incluso dentro de
una misma organización, empieza a ser raro encontrar un entorno puro (no
híbrido), con tipos de servidores, plataformas o lenguajes únicos.
Si bien SQL Server 2000 es la primera versión de SQL Server que soporta
XML, las primeras entregas de tecnología XML desarrolladas por Microsoft ya
podían ejecutarse bajo las versiones 7.0 y 6.5 (entregas que pueden
descargarse desde la sede web de Microsoft
http://msdn.microsoft.com/workshop/xml/articles/xmlsql/). Otra manera de
proporcionar soporte para XML bajo SQL Server 7.0, 6.x y 4.2 consiste en
escribir procedimientos almacenados ampliados y estándares, aunque estos
últimos podrían menguar considerablemente el rendimiento si se están
manipulando grandes tablas de resultados con estructuras complejas. Por otro
lado, algunas funciones de SQL Server 7.0, como la búsqueda de textos
completos, son capaces de almacenar el código XML como texto. La pregunta
obvia es: ¿qué otras prestaciones aporta SQL Server 2000 para que
oficialmente se declare compatible con XML?
Tradicionalmente, desde una base de datos se podían solicitar dos clases de

XML: XML estático almacenado dentro de la base de datos y XML dinámico
generado a partir de los datos contenidos en la base de datos. Ya la primera
versión de SQL Server era capaz de utilizarse como repositorio de XML y los
programadores han utilizado ampliamente las versiones anteriores a SQL
Server 2000 para crear aplicaciones que generan XML. Pero ahora, SQL
Server 2000 soporta un nuevo tipo de datos denominado XML que permite
almacenar XML en la base de datos, de forma nativa. Disponer de un tipo de
datos nativo XML es uno de los criterios que hace de SQL Server 2000 un
producto compatible con XML. Pero, además, SQL Server 2000 también
introduce:
· URL (Universal Resource Locator o Localizador de recursos universal) que

permiten acceder a SQL Server a través del protocolo http,
· la cláusula FOR XML dentro de la sentencia SELECT, pudiendo así recuperar
resultados en formato XML,
 procedimientos almacenados del sistema para la manipulación de datos

XML,
 operaciones por lotes basadas en XML (grams) de actualización para
 operaciones por lotes
 y extensiones proveedoras de SQL Server OLE DB para XML.
A continuación, examinaremos de cerca estas mejoras introducidas por el XML

de SQL Server 2000 y veremos un ejemplo de cómo compatibilizar sus
sistemas para extraer datos en formato XML desde su SQL Server 2000,
formateando dichos datos a su medida para utilizarlos después en sus
aplicaciones.
ACCESO A TRAVÉS DE HTTP
SQL Server 2000 permite introducir una sentencia SQL en el campo Dirección
de IE 5.0 (Internet Explorer 5.0 de Microsoft) y recuperar registros en formato
XML. La siguiente consulta pseudo URL muestra los diversos componentes de
una consulta del tipo mencionado:
http://<SERVIDOR WEB>/
<DirectorioVirtual>
?sql=<CONSULTA SQL CODIFICADA>+FOR+XML+RAW
En primer lugar, la consulta utiliza el protocolo HTTP, lo cual permite utilizar
cualquier tipo de software cliente existente o que usted mismo pueda crear. A
continuación, la consulta dirige su petición al servidor web, IIS (Internet
Information Server, de Microsoft), a través de una raíz virtual ubicada en el
servidor IIS y que debe configurarse previamente para que pueda utilizar las
extensiones XML de SQL Server. En tercer lugar, la consulta pide los datos
deseados. Por lo general, cuando se solicitan datos desde un servidor web,
suele utilizarse un formulario HTML con uno de los dos métodos típicos: GET o
POST. Con GET, los datos del formulario contenido en el cliente se transfieren
hasta el servidor como pares nombre/valor añadidos al final de la URL. Este
mecanismo está sujeto a inconvenientes harto conocidos, entre los que se
cuentan la limitación de longitud para la URL y ciertos fallos de seguridad. El
método preferido en el desarrollo de aplicaciones es POST, ya que los pares
nombre/valor contenidos en el formulario se almacenan en el cuerpo de la
solicitud HTTP. A pesar de lo dicho, los ejemplos de este artículo utilizarán el
método GET para enviar consultas a la base de datos, ya que, de este modo,
usted podrá visualizar la cadena que conforma la solicitud de datos.
Otra de las nuevas posibilidades consiste en utilizar sentencias SQL o

procedimientos almacenados para acceder a los datos en formato XML. O bien
ejecutar una plantilla XML, es decir, un documento XML que contiene una o
más consultas válidas, sentencias u operaciones por lotes basadas en XML
(grams) actualizadas. Las plantillas suelen tener la siguiente forma:
<sql:query xmlns:sql="urn:schemas-microsoft-com:xml-sql" name1=‟valor1‟

name2=‟valor2‟> sentencia(s) sql
</sql:query>
La invocación de plantillas se realiza incluyéndolas en la petición GET o POST

o llamándolas como archivos guardados en el directorio virtual del servidor
web.
Si sus consultas SQL suelen ser largas, IE no podrá mostrarlas en la barra de

tareas y, por lo tanto, va a tener que teclearlas una y otra vez durante las
pruebas que vaya ejecutando. Por esta razón, y otras muchas, resulta
conveniente almacenar las plantillas de consultas como archivos del directorio
virtual e invocarlas del modo siguiente:
http://miservidor/Northwind/miconsulta.xml
La consulta miconsulta.xml solicita la información sobre el pedido de un cliente

representado por un determinado identificador de cliente. La plantilla tiene el
siguiente aspecto:
ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query IDCliente=‟PACOS‟>
SELECT IDPedido, FechaPedido, FechaEntregaSolicitada, FechaEnvio FROM
PEDIDOS WHERE IDCliente=? ORDER BY IDPedido XML RAW
</sql:query></ROOT>
Con las consultas-plantilla también pueden utilizarse parámetros. Esto permite

combinar las consultas con el lenguaje XSL (Extensible Style Language o
Lenguaje de estilo extensible) pudiendo así sustituir rápidamente el código de
determinadas páginas ASP (Active Server Pages o Páginas de servidor activo)
superdinámicas que realizan consultas contra bases de datos y formatean los
registros resultantes como tablas HTML. El lenguaje XSL describe cómo
formatear o mostrar los datos XML. El empleo de consultas-plantilla vinculadas
a hojas de estilo XSL se acerca mucho al uso de los archivos HTX (Hypertext
Markup Language Extension o Extensión del lenguaje de marcas
hipertextuales) y conectores IDC (Internet Database Conector o Conector de
base de datos de Internet), posteriormente remplazados y mejorados por las
páginas ASP. Si bien es verdad que las prestaciones XML de SQL Server, por
sí solas, son incapaces de remplazar a las ASP, tampoco deja de ser cierto que
XML permite recuperar los datos de forma más sencilla, aparte de resultar más
rápido y fácil de implementar. En la Pantalla de Vista de un navegador con
los registros devueltospor una consulta en formato XML se muestra el
resultado de una consulta simple en la que se combinan una consulta-plantilla
XML y una hoja de estilo XSL:
http://miservidor/Northwind/miconsulta.xml?
IDCliente=pacos&xsl=ptab.xsl
LA CLÁUSULA 'FOR XML'
En SQL Server 2000, el empleo de la nueva cláusula FOR XML dentro de una
sentencia SELECT genera documentos XML en lugar de un conjunto de filas.
Esta nueva cláusula puede utilizarse tanto en consultas como en
procedimientos almacenados. Los argumentos admitidos por FOR XML son
XML mode, SchemaOptions y ELEMENTS.
 XML Mode. Las tres

modalidades XML posibles son
RAW, AUTO o EXPLICIT. Cada
una de ellas especifica la forma
del árbol XML resultante (en la
Tabla 1, hallará una descripción
de las tres modalidades). De las
tres, la más útil es EXPLICIT, ya
que permite crear un árbol XML
(siempre que disponga de los
datos imprescindibles) que, a su
vez, proporciona los datos XML
en el formato que usted prefiera.
 SchemaOption. Esta opción instruye a la base de datos para que

devuelva un esquema. SchemaOption puede devolver resultados DTD
(Document Type Definition o Definición de tipo de documento) o
XMLData. DTD devuelve el esquema y añade el elemento raíz a los
resultados. XMLData, a su vez, devuelve el esquema pero no añade el
elemento raíz. Si se especifica SchemaOption, la cláusula añadirá el
esquema al principio del documento. En caso contrario, la base de datos
no devolverá ningún esquema.
 ELEMENTS. En caso de utilizar la opción ELEMENTS, la sentencia
SELECT devolverá subelementos en las columnas. De otro modo, la
sentencia correlaciona las columnas con los atributos XML. SQL Server
2000 únicamente soporta esta opción si la modalidad AUTO está
activada.
Para especificar la modalidad XML en la cláusula FOR de la sentencia

SELECT, deberá utilizar la sintaxis:
FOR | [XML mode [, SchemaOption] [, ELEMENTS]]
PROCEDIMIENTOS ALMACENADOS DEL SISTEMA.
SQL Server 2000 introduce seis nuevos procedimientos almacenados del

sistema para manipular los datos XML: sp_xml_preparedocument,
sp_xml_fetchdocument, sp_xml_removedocument, sp_xml_insertfromxml,
xp_xml_removexml y sp_xml_fetchintoxml.
Los procedimientos almacenados para la manipulación de datos XML sólo

están disponibles por cada conexión que se establece. Esto no los hace
especialmente útiles en aplicaciones n-tier (multicapa), que reservan
conexiones precisamente para asegurarse la escalabilidad. No obstante, los
procedimientos ofrecen otro tipo de funcionalidad, ya que permiten almacenar
(preparedocument) y recuperar documentos mediante un puntero
(fetchdocument). Complementariamente, también se puede eliminar un
documento entero o algunos elementos del documento (removedocument,
removexml), realizar inserciones en un documento XML desde una tabla o
desde un documento XML a una tabla (insertfromxml, fetchintoxml).
A pesar de que SQL Server 2000 ofrece un acceso muy completo desde el
programa al lenguaje XML, algunos motores y extensiones de XML específicos,
como interMedia, de Oracle8i, proporcionan un control de XML mucho más
exhaustivo en tareas como, por ejemplo, consultar conjuntos de documentos
XML o encontrar elementos o patrones específicos dentro de un documento.
No obstante, SQL Server 2000 dispone de otros avances, como las funciones
definidas por el usuario, que podrían suplir esas carencias al permitir la
redacción de código adicional adaptado a las necesidades de cada usuario.
Pero aun con la funcionalidad actual, que le permite usar XML como medio de
transporte para los datos relacionales, SQL Server 2000 no sólo cumple
sobradamente los requisitos de una base de datos compatible con XML, sino
que además destaca por su facilidad de uso. A partir de la base de datos de
ejemplo Northwind, por ejemplo, podría construirse una aplicación web
compatible con XML, diseñada para dar servicio a sus clientes, en unas pocas
horas.
GRAMS DE ACTUALIZACIÓN
Las grams de actualización son operaciones por lotes, basadas en XML,

destinadas a insertar, suprimir y actualizar con el siguiente formato general:
<sql:sync xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:before>
<NOMBRE_TABLA [sql:id="valor"] col="valor" col="valor" ../>
</sql:before>
<sql:after>
<NOMBRE_TABLA [sql:id="valor"] [sql:at-identity="valor"] col="valor col="valor" ../>
</sql:after>
</sql:sync>
Para llevar a cabo una operación INSERT, basta con utilizar un bloque
sql:after. El bloque sql:before ejecuta una operación de DELETE y la de
UPDATE se consigue empleando ambos bloques. Para que la transacción se
produzca con éxito, la base de datos debe completar todas las operaciones
dentro de un bloque sql:sync.
OLE DB PARA XML
Las nuevas extensiones de SQL Server 2000 proveedoras de OLE DB para

XML --ICommandText::SetCommandText y ICommand::Execute-- permiten que
los documentos XML se conviertan en auténticos mandatos, pudiendo
ejecutarlos y recuperar los resultados en forma de corrientes (streams),
fácilmente manipulables en procesos posteriores. No resultaría difícil, por
ejemplo, pasar el documento XML a DOM (Document Object Model o Modelo
de objeto documento), una interfaz gracias a la cual los programas y guiones
acceden –dinámicamente-- a los documentos y actualizan sus contenidos,
estructura y estilo.
SQL Server también soporta plantillas que se comportan como textos de

mandatos; sólo hay que passar DBGUID_MSSQLXML como GUID (Globally
Unique ID o ID único global) del mandato. El consumidor debe invocar el
mandato ICommand:Execute para ejecutar plantillas XML. Para obtener un
conjunto de resultados como documento XML, hay que establecer el «riid» a
«Istream», consiguiendo de este modo que el proveedor devuelva los
resultados como una corriente (stream).
COMPATIBLE CON XML
Lo primero que cualquier desarrollador de SQL Server desea conseguir con

XML es transformar datos relacionales estándares a formatos XML. Aunque
muchas empresas también puedan estar desarrollando nuevas aplicaciones, su
primer interés se centrará en transformar al formato XML todos aquellos datos
que ya estén disponibles. He aquí un ejemplo sencillo que debería ayudarle a
ponerse en marcha.
En primer lugar, configure un usuario e inicio de sesión para que la base de

datos Northwind (incluida en la instalación del producto como ejemplo de base
de datos) pueda utilizar todas las consultas relacionadas con XML. A
continuación, entre en Programas, Microsoft SQL Server 2000 y Configurar
soporte SQL para XML en IIS para llegar a la pantalla que le permitirá
configurar las extensiones XML SQL Server de IIS.
La Pantalla de Registro de las extensiones XML para SQL Server muestra

esta configuración, con la mayoría de las opciones por omisión seleccionadas.
Sin embargo, la casilla «Permitir consultas URL» está marcada para poder
ejecutar consultas de este tipo. Como ya hemos mencionado, una consulta
URL es una sentencia SQL inmersa en la URL de una máquina IIS configurada
para soportar el lenguaje XML de SQL Server. En consultas expresas de este
tipo, la URL transfiere la sentencia SQL como un único parámetro. En este
ejemplo, los parámetros de la conexión también se han configurado para
utilizar una cuenta de SQL Server ya existente. (Observe que en todos los
ejemplos de los libros en línea SQL Server --Books on line o BOL-- siempre se
menciona a Nwind como raíz virtual; por lo tanto, deberá cambiar dicho valor
por el nombre de su propia raíz virtual).
En nuestro caso, durante la instalación de Windows 2000 hemos incluido tanto

el servidor web como SQL Server 2000. Si decide instalar SQL Server 2000 en
una máquina donde ya tenga instalado SQL Server 7.0, asegúrese de estar
refiriéndose a la versión correcta de SQL Server.
Veamos ahora un ejemplo de consulta URL :
http://miservidor/Northwind?sql=SELECT+IDCliente,
NombreContacto+FROM+Clientes+FOR+XML+RAW
en la que miservidor es el nombre de la máquina que ejecuta el servidor IIS,

/Northwind se refiere al directorio virtual configurado para el soporte XML y
?sql= es el único parámetro que describe la sentencia SQL. El resto de la
consulta es la propia sentencia SQL codificada de modo que pueda pasarse de
forma segura dentro de la dirección URL. SQL Server recibe la sentencia como:
SELECT IDCliente, NombreContacto FROM Clientes FOR XML RAW
La consulta solicita XML RAW (XML puro), lo que devuelve cada fila como un
elemento independiente, con campos en cada fila listados como atributos
separados de ese elemento. La Pantalla de Resultado de una consulta URL
muestra un ejemplo del resultado de esta consulta.
En aplicaciones de múltiples capas (n-tier) que utilizan
un número limitado de procedimientos almacenados
con parámetros establecidos para controlar el acceso a
los datos, el esquema de la base de datos puede
modificarse, sin tener que cambiar ningún código
cliente, con sólo editar los procedimientos almacenados
relevantes. Tome como ejemplo el procedimiento
almacenado de la base de datos Northwind mostrado
en el Listado 1. Para que este procedimiento
almacenado sea compatible con XML, deberá crearse
un nuevo procedimiento almacenado con las modificaciones que se resaltan en
el Listado 2. A continuación, tendrá que enviar al servidor SQL una solicitud
“execute pedidosclientesxml ´GNZLZ´", introduciendo la siguiente URL en el
campo Dirección de IE 5.0:
http://miservidor/northwind?sql=execute+
pedidosclientesxml+GNZLZ
Los resultados generados dentro de su navegador

serán registros con formato XML, tal como se muestra
en la Figura. Este ejemplo utiliza la convención T-SQL
“execute <nombre_procedimiento_almacenado>" , pero
las extensiones XML de SQL Server para IIS también
soportan las llamadas a función mediante CALL, al
estilo de ODBC.
La consulta ilustrada demuestra cómo sacar partido de

las funcionalidades más básicas, pero,
indudablemente, útiles. Si además introducimos hojas de estilo XSL, podremos
generar documentos HTML con informes de seguimiento acerca de los pedidos
de los clientes. Para conseguirlo, bastaría con combinar este documento XML
con otro XSL.
Las ventajas del método XML sobre las páginas ASP tradicionales son que, por
una parte, XML ofrece más flexibilidad para generar presentaciones de datos
sencillas y, por otra, su implementación es mucho menos costosa. Si desea
conocer todas sus posibilidades, espere a ver el alud de aplicaciones de
ejemplo que nos llegarán con la nueva versión de SQL Server 2000.
Vista de un navegador con los registros devueltospor una consulta en

formato XML
Registro de las extensiones XML para SQL Server

Resultado de una consulta URL
RASCANDO EN LA SUPERFICIE
Con XML pueden definirse tipos de documentos estándares que le permitirán

compartir, transmitir y transformar la información de la empresa, así como
facilitar la automatización de los procesos empresariales. En el recuadro
«Enlaces XML» encontrará algunas direcciones web que le ayudarán a
investigar más a fondo las posibilidades y ventajas del lenguaje XML.
Este artículo apenas deja al descubierto una parte insignificante de todo lo que
se puede hacer –y rápidamente-- con XML y SQL Server 2000. Un último
ejemplo: hace poco creamos un servicio muy sencillo basado en el protocolo
HTTP (un conjunto de URL con parámetros de consulta bien definidos que
devolvían datos XML) en un asombroso tiempo récord de 10 minutos.
Conseguimos tener la URL funcionando en menos tiempo del que tardamos en
telefonear para averiguar si la especificación había llegado correctamente. Este
tipo de productividad mejorada hará de SQL Server 2000 la plataforma ideal
para la entrega de formatos XML11

A25-ER6 Examen Rápido XML.
Formular 5 preguntas del tema y dictárselas a los alumnos para que se
resuelvan.
c) Fecha inicio:
d) Fecha entrega:

Examen Rápido XML dictárselas a los alumnos para 5 puntos
que se resuelvan.
Total 5 Puntos

Entender claramente el lenguaje XML
http://www.windowstimag.com/sqlmag/atrasados/01_sep00/articulos/XML_1.htm
6.1.7. DOCUMENTOS
6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y

ASP.
Manejar una base de datos a traves de una de las tecnologías mencionas en el
titulo del tema.
11
http://www.windowstimag.com/sqlmag/atrasados/01_sep00/articulos/XML_1.htm (9-08-05)
6.2.3. DESARROLLO
Aquí se describe las distintas interfaces de programación de aplicaciones

(API) disponibles en SQL Server. El apéndice pretende proporcionar una
breve panorámica de cada API, presentar las ventajas y desventajas
relativas de cada una y explicar qué las interfaces juegan un papel
importante en la estrategia de futuro de Microsoft.
Guías generales de selección de una interfaz
Como administrador de bases de datos, necesita conocer qué interfaces de

programación hay disponibles para SQL Server. Por ejemplo, puede que se
incorpore a un grupo de desarrolladores que estén trabajando en la
construcción de un programa personalizado que utilice SQL Server como
base de datos. En este tipo de entorno, puede que le pidan ayuda para
decidir qué API es la más adecuada para el tipo de aplicación que esté
siendo desarrollada. Incluso si usted mismo no escribe directamente código
de programa utilizando una de las API de SQL Server, tiene que conocer
cuáles hay disponibles y las ventajas y desventajas de cada una.
También debe ser consciente de que cualquier producto de otras empresas
escrito para SQL Server debe incluir el logotipo de Windows ó el de
BackOffice. El logotipo de Windows indica que los productos pueden
ejecutarse tanto en plataformas NT 4.0 como Windows 95/98, mientras que
los productos compatibles con BackOffice se ejecutarán como servicios NT y
permitirán inicios de sesión unificados y la utilización del protocolo TCP/lP,
entre otras funciones. Consulte el sitio web de Microsoft, en la dirección
http://www.microsoft.com/windows/thirdparty/winlogo/. para obtener más
información sobre la compatibilidad con Windows, y consulte la dirección
http://www.microsoft.com/backoffice/designed/, para obtener más
información sobre la compatibilidad con BackOffice.
TABLA D.1. INTERFACES DE PROGRAMACIÓN DE SQL SERVER
API Lenguaje Estándar Soporte OLAP Características
de SQL Server
7.0
ADO VB, ve, VJ, VBS, JS Emergente Sí La mayoría
OLE DB ve Emergente Sí Todas
RDO VB,VJ Actual No La mayoría
ODBe Ve,VB Actual No Todas
DAO VB,Ve Actual No Limitadas
DB-Library VB,Ve Heredada No Limitadas
VB-SQL oex VB Heredada No Limitadas
SQL incrustado ve Heredada No Limitadas
La Tabla es un resumen de las distintas interfaces disponibles en SQL Server,

en el que se indica bajo qué lenguajes de programación está disponible y si la
API forma parte de la estrategia de futuro de Microsoft o forma parte del código
heredado.
VB = Visual Basic, VC = Visual C++, VJ = Visual J++, VBS = VBScript y JS = JavaScript
ADO
Los objetos de datos ActiveX (ActiveX Data Objects, ADO) pueden

considerarse como un envoltorio de OLE DB, que proporciona un modelo de
objetos estructurado, fácil de programar y sencillo de utilizar: un conjunto de
interfaces COM que proporcionan acceso a muchos orígenes de datos
diferentes. Puede emplearse ADO para comunicarse con distintos orígenes de
datos compatibles con OLE DB, y no sólo con SQL Server. Se recomienda
utilizar ADO como API principal para acceder a datos desde aplicaciones de
propósito general. Puesto que ADO está construido sobre la API OLE DB y es
un modelo de objetos simplificado, reduce el tiempo de desarrollo y la curva de
aprendizaje asociados con cualquier nueva Apl.
Una aplicación ADO se comunica con un origen de datos OLE DB utilizando un
proveedor OLE DB. Un proveedor OLE DB es una biblioteca de enlace
dinámico que utiliza interfaces OLE DB para acceder a un origen de datos
concreto. Pueden utilizarse dos tipos de proveedores OLE DB con SQL Server:
 SQLOLEDB. El proveedor OLE DB de SQL Server, que hace

corresponder de manera directa las interfaces OLE DB a SQL
Server.
 MSDASQL. El proveedor OLE DB para ODBC, que hace
corresponder las interfaces OLE DB con una API ODBC.
El proveedor OLE DB de SQL Server, que se suministra con éste, es el

suministrador preferido para las aplicaciones ADO que accedan a SQL
Server. Es una asignación directa de la interfaz a SQL Server, en lugar de
un nivel colocado sobre una API preexistente, como es el caso de
MSDASQL con ODBC.
OLE DB
OLE DB es una API de bajo nivel basada en COM12 (Desde un punto de vista
práctico, un objeto COM es básicamente una caja negra que nuestra aplicación
puede usar para llevar a cabo una o más tareas) para acceder a datos de
diversos orígenes de datos. OLE DB es el método preferido para desarrollar
utilidades o aplicaciones SQL Server que requieran un máximo rendimiento. El
proveedor OLE DB de SQL Server, SQLOLEDB, es un proveedor compatible
con la versión 2.0 de OLE DB. Proporciona acceso directo al protocolo nativo
de SQL Server, TDS (Tabular Data Stream, Flujo de Datos Tabulares). Sin
embargo, esta potencia tiene un precio asociado: la complejidad. Requerirá
más tiempo de desarrollo, tanto en términos de la curva de aprendizaje de la
nueva API, como del tiempo requerido para escribir programas.
SQL-DMO y SQL Namespace

SQL Distributed Management Objects (SQL-DMO, Objetos de Administración
Distribuidos) es un conjunto de objetos COM que proporciona un modelo de
objetos para la administración de la duplicación y las bases de datos SQL
Server. Se implementa como un servidor en proceso de interfaz dual. Puede
desarrollarse una aplicación SQL-DMO utilizando un control de automatización
OLE, como el de Visual Basic, o desarrollando una aplicación basada en COM
12
El COM (Component Object Model ) es un estándar binario que define como se crean y destruyen los objetos y, lo
más importante, como interactúan entre ellos. La idea es que distintas aplicaciones con distintos códigos fuente puedan
comunicarse entre ellas mediante procesos, siempre que dichas aplicaciones sigan el estándar COM. Normalmente se
usa el COM para establecer fácilmente comunicaciones con otros procesos.
http://www.etse.urv.es/EngInf/assig/ens4/2004/net4a.pdf (04/Ago/05)
mediante C++. SQL-DMO requiere el controlador ODBC de SQL Server,
versión 3.70 o posterior, incluido en SQL Server 7.0.
SQL Namespace, SQL-NS, es un conjunto de interfaces COM que permite a
una aplicación mostrar los componentes de interfaz de usuario del
Administrador corporativo. Esto permite a cualquier aplicación desarrollada en
Visual Basic o Visual C++ mostrar cualquiera de los muchos asistentes, hojas
de propiedades y cuadros de diálogo del Administrador corporativo. Utilizando
los objetos SQL Namespace, cualquier des arrollador de aplicaciones puede
aprovecharse de la funcionalidad ya incorporada en SQL Server. Por ejemplo,
un desarrollador de aplicaciones que quiera que se puedan realizar copias de
seguridad de las bases de datos SQL Server directamente desde su
aplicación, puede utilizar objetos SQL Namespace para proporcionar esta
capacidad, en lugar de escribir su propio código.
ODBC y RDO
ODBC es la API estándar empleada para acceder a datos almacenados en
bases de datos relacionales o ISAM. SQL Server incluye ODBC como una
de sus API nativas para el desarrollo de aplicaciones escritas en Visual
C++ y Visual Basic. Las aplicaciones que se comunican con SQL Server
mediante ODBC requieren un mayor esfuerzo de desarrollo que otras API,
porque se trata de una interfaz de bajo nivel.
Al igual que ADO, RDO es un conjunto de objetos simplificados que
proporciona acceso a bases de datos compatibles con ODBC. Requiere
menos esfuerzo que ODBC, pero carece de la rapidez y grado de control
disponibles cuando se utilizan llamadas a funciones nativas ODBC. Las
aplicaciones escritas en Visual Basic y Visual J++ pueden utilizar RDO.
Para el uso futuro de ODBC, Microsoft recomienda que todas las
aplicaciones de nuevo desarrollo realicen la migración desde ODBC o
RDO a OLE DB o ADO. OLE DB es la dirección futura para todas las API
de acceso a datos, porque proporciona la posibilidad de consultar y extraer
datos de orígenes tan diversos como SQL Server, Microsoft Access e
incluso hojas de cálculo Microsoft Excel.
Interfaces heredadas: DB-Library, ODS y SQL incrustado

DB-Library es una API que consiste en un conjunto de funciones y macros
en C. Un subconjunto de esta biblioteca está disponible para su utilización
con Visual Basic. DBLibrary es la API original proporcionada con SQL
Server y fue su API estándar hasta el advenimiento de ODBC y, ahora, de
OLE DB.
PRECAUCIÓN
DB-Library no ha sido mejorado con respecto a las capacidades disponibles en
SQL Server 6.5. Aunque todas las aplicaciones basadas en DB-Library
seguirán funcionando con SQL Server 7.0, no podrán acceder a las numerosas
funciones nuevas que SQL Server 7.0 proporciona. Considere realizar la
migración de sus aplicaciones DB-Library a alguna de las nuevas API, como
ADO.
SQL incrustado para C permite a las aplicaciones incrustar instrucciones

Transact-SQL en código fuente escrito en lenguaje C. Las aplicaciones que
utilicen SQL incrustado para C necesitarán que se preprocese el código
fuente mediante un precompilador. El precompilador de SQL incrustado
convierte las instrucciones incrustadas Transact-SQL en llamadas de
función que pueden ser procesadas por un compilador C. El compilador C
generará un programa ejecutable a partir de los resultados preprocesados.
SQL incrustado se considera una API heredada y Microsoft sugiere que
sólo se utilice cuando una aplicación deba forzosamente mantener
estándares ANSI SQL estrictos.
Los Servicios abiertos de datos (ODS, Open Data Services) son una API
basada en SQL Server, que puede ser utilizada para ampliar las
capacidades que SQL Server incluye. La API consiste en un conjunto de
funciones y macros C/C++, que pueden usarse para construir
procedimientos almacenados extendidos y aplicaciones de pasarela.
Los procedimientos almacenados extendidos son bibliotecas de enlace
dinámico que añaden funcionalidad mediante rutinas desarrolladas en C/C++
(y pronto en Visual Basic y Visual J++, también) utilizando la API de los
servicios abiertos de datos y la API Win32. Los usuarios pueden invocar los
procedimientos almacenados extendidos de la misma forma que los
procedimientos almacenados normales. SQL Server contiene diversos
procedimientos almacenados extendidos, todos los cuales llevan como prefijo
xp. El procedimiento xp_sendmail es un buen ejemplo de procedimiento
almacenado extendido: . amplía la funcionalidad de SQL Server, permitiendo
enviar correo electrónico desde un lote Transact-SQL.
En las versiones anteriores de SQL Server, ODS era el único medio de
proporcionar una pasarela con aplicaciones que no fueran de SQL Server. Si
se deseaba escribir una aplicación que almacenara datos en SQL Server y
accediera a otro origen de datos situado en una aplicación de otra compañía,
había que desarrollar una aplicación pasarela utilizando ODS. ODS es difícil de
programar y requiere una gestión exhaustiva de las excepciones.
Con el advenimiento de la función de consulta distribuida y los Servicios de
transformación de datos de SQL Server 7.0, y con el lanzamiento de Microsoft
Transaction Server, hay menos necesidad de emplear ODS. Es recomendable
que las nuevas aplicaciones de pasarela para SQL Server empleen alguna de
las tecnologías basadas en componentes. Las aplicaciones basadas en
componentes son independientes del lenguaje y pueden ser ejecutadas bajo
MTS, que ofrece ampliabilidad, seguridad y una gestión estructurada de los
errores.
ASP
Qué es ADO?
ActiveX Data Objects (ADO) es una tecnología ampliable y de fácil uso para
agregar acceso a bases de datos a sus páginas Web. Puede utilizar ADO para
escribir secuencias de comandos compactas y escalables que conecten con
bases de datos compatibles con Open Database Connectivity (ODBC,
Conectividad abierta de bases de datos) y orígenes de datos compatibles con
OLE DB. Si no tiene mucha experiencia en conectividad con bases de datos,
encontrará que las instrucciones de ADO son asequibles y no complicadas. Del
mismo modo, si ya tiene experiencia en la programación con bases de datos,
apreciará las características avanzadas de conexión y de manipulación de
consultas independientes del lenguaje de ADO.
Nota. Si se desean usar las constantes de ADO se deben incluir los siguientes
archivos.
 ó

Características de ADO
 Objetos creados independientemente.

 Ayudas de modificación en lote.
 Soporte para procedimientos almacenados.
 Diferentes tipos de cursores.
 Soporte para retornar múltiples recordsets
 Aplicaciones libres de Hilos para aplicaciones de servidor web eficientes.
Objetos ADO
 Connection: Mantiene la información de conexión con el proveedor de

datos.
set VarConexion = Server.CreateObject(ADODB.Connection)

Métodos:
Open: VarConexion.Open ConnectionString [,UserID] [,Password]
Close: VarConexion.Close
Execute: VarConexion.Execute CommandText,RecordsAffected,Options
Propiedades:
CommandTimeOut
ConnectionString
ConnectionTimeOut
State
Version
DefaultDataBase
 Command: Mantiene información acerca de un comando
set VarComando = Server.CreateObject(ADODB.Command)

Métodos:
CreateParameter:
Set varParametro= command.CreateParameter(Name, Type, Direction, Size,
Value)
Execute:
Set recordset = command.Execute( RecordsAffected, Parameters, Options )
Propiedades:
ActiveConectionComandtext
CommandTimeOut
CommandType
Name
Prepared
State
 Error: Mantiene información acerca de algún error ocurrido en el

proveedor
set VarError = Server.CreateObject(ADODB.Error)
 Field: Mantiene información de un único campo dentro de un recordset
set VarConexion = Server.CreateObject(ADODB.Connection)
 Parameter: Es un parámetro para ser usado en un objeto command.
set VarParametro = Server.CreateObject(ADODB.Parameter)
 Property: Características de un objeto.
set VarPropiedad = Server.CreateObject(ADODB.Property)
 Recordset: Conjunto de registros retornados desde una consulta con un

cursor asociado.
set VarConexion = Server.CreateObject(ADODB.Recordset)
Métodos:
AddNew: recordset.AddNew Fields, Values
CancelUpdate: recordset.CancelUpdate
Close: object.Close
Delete: recordset.Delete AffectRecords
GetRows: array = recordset.GetRows( Rows, Start, Fields )
Move: recordset.Move NumRecords, Start
Movefirst, MoveNext, MoveLast, MovePrevious: recordset.MoveX
Open: recordset.Open Source, ActiveConnection, CursorType, LockType,
Options
Requery: recordset.Requery
Update: recordset.Update Fields,Values
Supports: boolean = recordset.Supports( CursorOptions )
Propiedades:
AbsolutePage,
AbsolutePosition,
ActiveConnection,
BOF,
Bookmark,
CacheSize,
CursorLocation,
CursorType,
EditMode,
EOF,
Filter,
LockType,
MarshalOptions,
MaxRecords,
PageCount,
PageSize,
RecordCount,
Source,
State,
Status
Creación del Archivo de Acceso a Datos (DSN)
Antes de crear secuencias de comandos para bases de datos tiene que

proporcionar una forma para que ADO encuentre, identifique y se comunique
con una base de datos.
Los controladores de bases de datos (programas que pasan información desde

su aplicación Web a una base de datos) utilizan un Nombre de origen de datos
(DSN) para encontrar e identificar una base de datos ODBC en particular.
Normalmente, el DSN contiene información de configuración de la base de
datos, seguridad de usuarios y ubicación, y puede tener la forma de una
entrada en el registro del sistema de Windows NT o de un archivo de texto.
Con ODBC puede elegir el tipo de DSN que va a crear: Usuario, Sistema o
Archivo.
Los DSN de Usuario y de Sistema residen en el registro del sistema de

Windows NT. Los DSN de Sistema permiten que todos los usuarios que han
iniciado una sesión en un servidor concreto tengan acceso a una base de
datos, mientras que los DSN de Usuario limitan la conectividad con la base de
datos a los usuarios que dispongan de las credenciales de seguridad
apropiadas. Los DSN de Archivo, que tienen la forma de archivos de texto,
proporcionan acceso a varios usuarios y son fácilmente transferibles entre un
servidor y otro mediante la copia de los archivos DSN. Por estas razones, los
ejemplos de este tema utilizan DSN de Archivo.
Puede crear un DSN de Archivo si abre Panel de control desde el menú Inicio
de Windows. Haga doble clic en el icono ODBC y seleccione la hoja de
propiedades DSN de Archivo. Haga clic en Agregar, elija el controlador de la
base de datos y haga clic en Siguiente.
 Para configurar un DSN de Archivo para una base de datos de

Microsoft Access
1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione
Controlador Microsoft Access en el cuadro de lista, después, haga clic
en Siguiente.
2. Escriba el nombre de su DSN de Archivo y haga clic en Siguiente.
3. Haga clic en Finalizar para crear el origen de datos.
4. En el cuadro de diálogo Instalación de ODBC para Microsoft Access
97, haga clic en Seleccionar. Elija un archivo de base de datos de
Microsoft Access (*.mdb) y haga clic en Aceptar.
Nota Por razones de rendimiento y confiabilidad, se recomienda

encarecidamente que utilice un motor de base de datos cliente-servidor para el
despliegue de aplicaciones Web controladas por datos que requieran una
elevada demanda de accesos por parte de más de 10 usuarios simultáneos. Si
bien Páginas Active Server funciona con cualquier base de datos compatible
con ODBC, se ha probado y está diseñado para funcionar con bases de datos
cliente-servidor como Microsoft (r) SQL Server u Oracle.
ASP acepta bases de datos de archivos compartidos (Microsoft(r) Access o
Microsoft(r) FoxPro) como orígenes válidos de datos. Aunque algunos ejemplos
de la documentación de ASP utilizan una base de datos de archivos
compartidos, se recomienda utilizar estos tipos de motores de bases de datos
únicamente con fines de desarrollo o en situaciones de despliegue limitado. Las
bases de datos de archivos compartidos pueden no ser tan adecuadas como
las bases de datos cliente-servidor para aplicaciones Web de producción muy
exigentes.
 Para configurar un DSN de Archivo para una base de datos de SQL

Server
Nota Si la base de datos reside en un servidor remoto, póngase en contacto

con el administrador del servidor para obtener información de configuración
adicional; el siguiente procedimiento utiliza la configuración predeterminada de
ODBC para SQL Server, que puede no funcionar con su configuración
hardware.
1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione SQL
Server en el cuadro de lista y haga clic en Siguiente.
2. Escriba el nombre de su DSN de Archivo y haga clic en Siguiente.
4. Escriba el nombre del servidor que ejecuta SQL Server, su Id. de inicio
de sesión y su contraseña.
5. En el cuadro de diálogo Crear un nuevo origen de datos SQL Server,
escriba en el cuadro de lista Servidor el nombre del servidor que
contenga la base de datos de SQL Server y haga clic en Siguiente.
6. Seleccione el método de comprobar la autenticidad del Id. de inicio de
sesión.
7. Si elige la autenticación SQL Server, escriba el Id. de inicio de sesión y
la contraseña; después, haga clic en Siguiente.
8. En el cuadro de diálogo Crear un nuevo origen de datos SQL Server,
establezca la base de datos predeterminada, la configuración de los
procedimientos almacenados del controlador y los identificadores ANSI;
después, haga clic en Siguiente. (Para obtener más información, haga
clic en Ayuda.)
9. En el cuadro de diálogo (también se llama Crear un nuevo origen de
datos SQL Server), elija el método de traducción de caracteres y haga
clic en Siguiente. (Para obtener más información, haga clic en Ayuda.)
10. En el siguiente cuadro de diálogo (también se llama Crear un nuevo
origen de datos SQL Server), seleccione las opciones de registro.
Nota Normalmente, sólo debe utilizar el registro para depurar problemas

de acceso a la base de datos.
11. En el cuadro de diálogo Instalación de ODBC para Microsoft SQL

Server, haga clic en Comprobar origen de datos. Si el DSN se ha
creado correctamente, el cuadro de diálogo Resultados de la
comprobación indicará que la comprobación es correcta.
Información de conexión y seguridad de SQL Server
Si va a desarrollar una aplicación ASP de base de datos diseñada para

conectar con una base de datos remota de SQL Server, debe tener en cuenta
también los aspectos siguientes:
o Esquema de conexión Puede elegir entre los métodos Sockets

TCP/IP y Canalizaciones con nombre para tener acceso a bases de datos
remotas de SQL Server. Con Canalizaciones con nombre, los clientes de
la base de datos tienen que estar autenticados por Windows NT antes de
establecer una conexión, dejando la posibilidad de que un equipo remoto
que ejecute canalizaciones con nombre pueda denegar el acceso a un
usuario que tenga las credenciales apropiadas de acceso a SQL Server,
pero no tenga una cuenta de usuario de Windows NT en dicho equipo.
o Como alternativa, las conexiones que utilizan Sockets TCP/IP
conectan directamente con el servidor de la base de datos, sin conectar a
través de un equipo intermediario (como es el caso de Canalizaciones con
nombre). Como las conexiones establecidas mediante Sockets TCP/IP
conectan directamente con el servidor de la base de datos, los usuarios
pueden tener acceso mediante la autenticación de SQL Server, no
mediante la autenticación de Windows NT.
Nota Para aumentar el rendimiento en la conexión con bases de datos remotas,

utilice Sockets TCP/IP.
o Seguridad Si utiliza las características de seguridad Integrada o

Mixta de SQL Server y la base de datos de SQL Server reside en un
servidor remoto, no podrá utilizar la autenticación Desafío/Respuesta de
Windows NT. Específicamente, no puede reenviar credenciales
Desafío/Respuesta de Windows NT al equipo remoto. Esto significa que
quizá tenga que utilizar la autenticación Básica, que se basa en que el
usuario proporcione la información del nombre de usuario y la contraseña.
Para obtener más información acerca de estos aspectos, visite la página
principal de Microsoft SQL Server Technical Support en
http://www.microsoft.com/sqlsupport/.
 Para configurar un DSN de Archivo para una base de datos de Oracle
Asegúrese de que el software cliente de Oracle esté correctamente instalado

en el equipo donde vaya a crear el DSN. Para obtener más información,
consulte con el administrador del servidor y la documentación de la base de
datos.
1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione

Controlador ODBC de Microsoft para Oracle en el cuadro de lista y
haga clic en Siguiente.
2. Escriba el nombre del DSN de Archivo y haga clic en Siguiente.
4. Escriba un nombre de usuario, una contraseña y el nombre del servidor;
después, haga clic en Aceptar.
Nota Los archivos DSN tienen la extensión .dsn y residen en el directorio

\Archivos de programa\Archivos comunes\ODBC\Data Sources.
Para obtener más información acerca de la creación de DSN de Archivo, visite
el sitio Web de Microsoft ODBC en http://microsoft.com/odbc/.
Conexión con una Base de Datos
El primer paso para tener acceso a la información de una base de datos

consiste en establecer una conexión con el origen de datos. ADO proporciona
el objeto Connection, que puede utilizar para establecer y administrar las
conexiones entre sus aplicaciones y las bases de datos de ODBC. El objeto
Connection incorpora diversas propiedades y métodos que puede utilizar para
abrir y cerrar conexiones con bases de datos, y para enviar consultas de
actualización de la información.
Para establecer una conexión con una base de datos, cree primero una
instancia del objeto Connection. Por ejemplo, la siguiente secuencia de
comandos crea una instancia del objeto Connection y procede a abrir una
conexión:
<%
'Crea un objeto Connection
Set cn = Server.CreateObject("ADODB.Connection")
'Abre una conexión; la cadena hace referencia al DSN
cn.Open "FILEDSN=MiBaseDeDatos.dsn"
%>
Nota La cadena DSN no contiene espacios en blanco ni antes ni después del
signo igual (=).
En este caso, el método Open del objeto Connection hace referencia al DSN
de Archivo, que contiene la información de ubicación y la configuración de la
base de datos. Opcionalmente, también puede hacer referencia directamente a
un proveedor, origen de datos, Id. de usuario y contraseña, en lugar de al DSN.
Ejecución de Consultas con el Objeto CONNECTION

Con el método Execute del objeto Connection puede enviar consultas en el
Lenguaje de consulta estructurado (SQL) al origen de datos y recuperar los
resultados. SQL, un lenguaje estándar para comunicarse con bases de datos,
tiene comandos para recuperar y actualizar información.
La siguiente secuencia de comandos utiliza el método Execute del objeto
Connection para enviar una consulta con un comando INSERT de SQL, que
inserta datos en una tabla concreta de la base de datos. En este caso, el
bloque de la secuencia de comandos inserta el nombre José Lugo en una tabla
de la base de datos llamada Customers.
<%
'Define el DSN de Archivo
strDSN = "FILEDSN=MiBaseDeDatos.dsn"
'Crea la instancia del objeto Connection y abre una conexión con la base de datos
cn.Open strDSN
'Define la instrucción SELECT de SQL

strSQL = "INSERT INTO Customers (FirstName, LastName) VALUES ('José','Lugo')"
'Utiliza el método Execute para enviar una consulta SQL a la base de datos cn.Execute(strSQL)
%>
Nota La ruta del DSN de Archivo no debe incluir espacios en blanco antes ni
después del signo igual (=).
Además del comando INSERT de SQL, puede utilizar los comandos UPDATE y
DELETE de SQL para modificar y quitar información de la base de datos.
Con el comando UPDATE de SQL puede modificar los valores de los
elementos de una tabla de la base de datos. La siguiente secuencia de
comandos usa el comando UPDATE para cambiar todos los campos FirstName
de la tabla Customers a Juan en todas las filas cuyo campo LastName
contenga el apellido Robles.
<%
cn.Execute "UPDATE Customers SET FirstName = 'Juan' WHERE LastName = 'Robles' "
%>
Para quitar determinados registros de una tabla de la base de datos, < BR >
utilice el comando DELETE de SQL. La siguiente secuencia de comandos quita
todas las filas de la tabla Customers cuyo apellido sea Robles:
<%
cn.Execute "DELETE FROM Customers WHERE LastName = 'Robles'"
%>
Nota Debe tener mucho cuidado al utilizar el comando DELETE de SQL. Un
comando DELETE que no vaya acompañado de una cláusula WHERE
eliminará todas las filas de la tabla. Asegúrese de incluir una cláusula WHERE
de SQL, que especifica las filas exactas que se van a eliminar.
Uso del Objeto RECORDSET para manipulación de resultados

Aunque el objeto Connection simplifica la tarea de conectar con una base de
datos y emitir una consulta, el objeto Connection tiene sus limitaciones. En
concreto, con el objeto Connection no se pueden crear secuencias de
comandos que recuperen y presenten información de una base de datos; tiene
que saber exactamente las modificaciones que desea realizar en la base de
datos y después implementar las modificaciones como consultas.
Para recuperar datos, examinar resultados y modificar su base de datos, ADO
proporciona el objeto Recordset. El objeto Recordset tiene las funciones
necesarias para, dependiendo de las restricciones de las consultas, recuperar y
presentar un conjunto de filas, o registros, de una base de datos. El objeto
Recordset mantiene la posición de cada registro devuelto por la consulta, lo
que permite "recorrer" los resultados de uno en uno.
Dependiendo de cómo configure las propiedades del tipo de cursor del objeto
Recordset, puede recorrer y actualizar los registros. Los cursores de la base
de datos se comportan como punteros que le permiten encontrar un elemento
específico de un conjunto de registros. Los cursores son especialmente útil
para recuperar y examinar registros, y después realizar operaciones basadas
en dichos registros. El objeto Recordset tiene propiedades que le permiten
controlar con precisión el comportamiento de los cursores, lo que aumenta la
capacidad de examinar y actualizar los resultados.
Por ejemplo, puede utilizar las propiedades CursorType y CursorLocation
para configurar un tipo de cursor que devuelva un conjunto de resultados a su
aplicación cliente (los resultados permanecen normalmente en el servidor de
base de datos) y presente las últimas modificaciones realizadas en la base de
datos por otros usuarios.
Recuperar un conjunto de registros
Las buenas aplicaciones de base de datos emplean el objeto Connection para
establecer un vínculo y el objeto Recordset para manipular los datos
devueltos. Si utiliza conjuntamente las funciones especializadas de ambos
objetos puede desarrollar aplicaciones de bases de datos que realicen casi
cualquier tarea de tratamiento de datos. Por ejemplo, la siguiente secuencia de
comandos del servidor utiliza el objeto Recordset para ejecutar un comando
SELECT de SQL. El comando SELECT recupera un conjunto específico de
información basándose en las restricciones de la consulta.
La consulta también contiene una cláusula WHERE de SQL, que se utiliza para
establecer el criterio de selección de la consulta. En este ejemplo, la cláusula
WHERE limita la consulta a todos los registros que contengan el apellido Soto
en la tabla Customers de la base de datos.
<%
'Establece una conexión con un origen de datos
cn.Open strDSN
'Crea una instancia de un objeto Recordset

Set rsCustomers = Server.CreateObject("ADODB.Recordset")
'Abre un objeto Recordset con el método Open

'y utiliza la conexión establecida por el objeto Connection
strSQL = "SELECT FirstName, LastName FROM Customers WHERE LastName = 'Soto' "
rsCustomers.Open strSQL, cn
'Recorre el conjunto de los registros y presenta los resultados

'e incrementa la posición del registro con el método MoveNext
Set objFirstName = rsCustomers("FirstName")
Set objLastName = rsCustomers("LastName")
Do Until rsCustomers.EOF
Response.Write objFirstName & " " & objLastName & "<BR>"
rsCustomers.MoveNext
Loop
%>
Observe que en el ejemplo anterior, el objeto Connection estableció la
conexión con la base de datos y el objeto Recordset utilizó la misma conexión
para recuperar resultados de la base de datos. Este método es útil cuando
tenga que configurar con precisión la forma en que se establece el vínculo con
la base de datos. Por ejemplo, si necesitara especificar el tiempo de espera
antes de anular un intento de conexión, tendría que utilizar el objeto
Connection para establecer dicha propiedad. Sin embargo, si sólo desea
establecer una conexión con las propiedades de conexión predeterminadas de
ADO, podría utilizar el método Open del objeto Recordset para establecer el
vínculo:
<%
strSQL = "SELECT FirstName, LastName FROM Customers WHERE LastName = 'Soto' "
Set rsCustomers = Server.CreateObject("ADODB.Recordset")
'Abre una conexión con el método Open

'y utiliza la conexión establecida por el objeto Connection
rsCustomers.Open strSQL, strDSN
'Recorre el conjunto de registros, presenta los resultados

'e incrementa la posición del registro con el método MoveNext
Set objFirstName = rsCustomers("FirstName")
Set objLastName = rsCustomers("LastName")
Do Until rsCustomers.EOF
Response.Write objFirstName & " " & objLastName & "<BR>"
rsCustomers.MoveNext
Loop
%>
Cuando establece una conexión con el método Open del objeto Recordset,
está utilizando implícitamente el objeto Connection para proteger el vínculo.
Manejo de consultas con el Objeto COMMAND
Con el objeto Command de ADO puede ejecutar consultas de la misma forma

que con los objetos Connection y Recordset, excepto en que con el objeto
Command puede preparar, o compilar, la consulta con el origen de la base de
datos y después enviar la misma consulta repetidamente con distintos valores.
La ventaja de compilar consultas de esta manera consiste en la enorme
reducción del tiempo necesario para volver a enviar las modificaciones de una
consulta existente. Además, puede dejar las consultas SQL parcialmente
indefinidas, con la posibilidad de alterar partes de las consultas justo antes de
su ejecución.
La colección Parameters del objeto Command le ahorra los problemas de

tener que volver a construir la consulta cada vez que tenga que ejecutarla. Por
ejemplo, si tiene que actualizar periódicamente la información de suministros y
costos en un sistema de inventario Web, puede predefinir su consulta de la
siguiente manera:
<%
'Abre una conexión mediante el objeto Command del objeto
'Connection no tiene un método Open para establecer
'la conexión
cn.Open strDSN
'Crea el objeto Command; utiliza la propiedad

'ActiveConnection para
'adjuntar la conexión al objeto Command
Set cm= Server.CreateObject("ADODB.Command")
Set cm.ActiveConnection = cn
'Define laconsulta
SQL cm.CommandText = "INSERT INTO Inventory (Material, Quantity) VALUES (?, ?)"
'Guarda una versión preparada (o precompilada) de la consulta < BR >
'especificada en la propiedad
'CommandText antes de la primera ejecución del objeto Command.
cm.Prepared = True
'Define la información de configuración

'de los parámetros de la consulta
cm.Parameters.Append cm.CreateParameter("material_type",200,,255)
cm.Parameters.Append cm.CreateParameter("quantity",200, ,255 )
'Define y ejecuta la primera inserción

cm("material_type") = "Bombillas"
cm("quantity") = "40"
cm.Execute
'Define y ejecuta la segunda inserción

cm("material_type") = "Fusibles"
cm("quantity") = "600"
cm.Execute
%>
Si examina el ejemplo anterior, observará que la secuencia de comandos
vuelve a construir repetidamente y envía una consulta SQL con distintos
valores, sin tener que volver a definir y enviar la consulta al origen de datos.
Compilar consultas con el objeto Command también le ofrece la ventaja de
evitar los problemas que pudieran provenir de concatenar cadenas y variables
para formar consultas SQL.
En particular, si utiliza la colección Parameter del objeto Command puede
evitar problemas relacionados con la definición de ciertos tipos de variables de
cadenas, fechas y horas. Por ejemplo, los valores de las consultas SQL que
contengan apóstrofos (') pueden hacer que la consulta falle:
strSQL = "INSERT INTO Customers (FirstName, LastName) VALUES ('Roberto','O'Hara')"
Observe que el apellido O'Hara contiene un apóstrofo que entra en conflicto

con los apóstrofos que se utilizan como delimitadores de datos en la palabra
clave VALUES de SQL. Si enlaza el valor de la consulta como un parámetro
del objeto Command, se evitan este tipo de problemas.
MANEJO DE CONEXIONES A BASES DE DATOS
Uno de los mayores retos del diseño de una aplicación Web sofisticada de
base de datos, como una aplicación de entrada de pedidos en línea que
atienda a miles de clientes, es la correcta administración de la conexiones con
la base de datos. Abrir y mantener las conexiones con las bases de datos,
incluso cuando no se transmita información, puede afectar severamente a los
recursos del servidor de base de datos y provoca problemas de conectividad.
Las aplicaciones Web de bases de datos bien diseñadas reciclan las
conexiones con la base de datos y compensan los retrasos debidos al tráfico
de la red.
Abandonar los intentos de conexión
Un servidor de base de datos que experimente un repentino incremento en su
actividad puede quedar saturado en sus conexiones, lo que incrementa
considerablemente el tiempo necesario para establecer una nueva conexión.
Como resultado, los retrasos excesivos en la conexión pueden reducir el
rendimiento de su aplicación de base de datos.
Con la propiedad ConnectionTimeout del objeto Connection puede limitar la
cantidad de tiempo que su aplicación espera antes de abandonar un intento de
conexión y emitir un mensaje de error.
Por ejemplo, la siguiente secuencia de comandos establece la propiedad
ConnectionTimeout para esperar veinte segundos antes de cancelar el intento
de conexión:
cn.ConnectionTimeout = 20
El valor predeterminado de la propiedad ConnectionTimeout es 30 segundos.

Nota Antes de incorporar la propiedad ConnectionTimeout a sus aplicaciones
de bases de datos, asegúrese de que su proveedor de conexiones y el origen
de datos acepten esta propiedad.
Aceptar conexiones
Las aplicaciones Web de bases de datos que establecen y terminan con
frecuencia conexiones con bases de datos pueden reducir el rendimiento del
servidor de base de datos.
ASP acepta la eficiente administración de las conexiones que se consigue
mediante la función de agrupamiento de conexiones de ODBC 3.5. El
agrupamiento de conexiones mantiene abiertas las conexiones con las bases
de datos y administra el uso compartido de las conexiones entre distintas
peticiones de usuario para mantener el nivel de rendimiento y reducir el número
de conexiones inactivas.
En cada petición de conexión, el conjunto de conexiones determina si hay
alguna conexión inactiva en el conjunto. Si es así, el conjunto de conexiones
devuelve una de ellas en lugar de establecer una nueva conexión con la base
de datos.
Si desea que su controlador ODBC participe en el conjunto de conexiones,
debe configurar su controlador específico de base de datos y después
establecer la propiedad CPTimeout del controlador en el registro del sistema
de Windows NT.
Cuando ODBC desconecta una conexión, la conexión se guarda en un
conjunto, en lugar de desconectarse.
La propiedad CPTimeout determina el periodo de tiempo de inactividad que
una conexión puede permanecer en el conjunto de conexiones. Si la conexión
permanece en el conjunto durante un periodo de tiempo mayor que el
establecido en CPTimeout, la conexión se cierra y se quita el conjunto. El valor
predeterminado de CPTimeout es 60 segundos.
Puede establecer selectivamente la propiedad CPTimeout para permitir el
agrupamiento de conexiones por cada controlador específico de base de datos
ODBC si crea una entrada en el registro del sistema con los siguientes valores:
\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\controlador
\CPTimeout = timeout
(REG_SZ, en segundos)
Por ejemplo, la clave siguiente establece el tiempo de inactividad del conjunto

de conexiones a 180 segundos (3 minutos) para el controlador de SQL Server.
\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\SQL
Server\CPTimeout = 180
Nota De forma predeterminada, su servidor Web activa el conjunto de

conexiones para SQL Server y asigna a CPTimeout 60 segundos.
A26-EC12 Manejo de Bases de Datos atraves de ADO.
Realizar una aplicación que manipule una base de datos utilizando la
tecnología de acceso ADO.
b) Producto esperado: Aplicacion
c) Fecha inicio:
d) Fecha entrega:

Aplicación que manipula una
Manejo de Bases de Datos
Base de Datos en cualquier 10 puntos
atraves de ADO
lenguaje de programación
Total 10 Puntos

Aprender a utilizar una tecnología de acceso a datos
6.2.7. DOCUMENTOS
6.3. JDBC, PAGINAS DEL SERVIDOR JAVA.
Aprender de forma general las característica del manejador de Base de Datos
para Java (JDBC).
6.3.3. DESARROLLO
Acceso a Bases de DatosJava IDL

JDBC fue diseñado para mantener sencillas las cosas sencillas. Esto significa
que el API JDBC hace muy sencillas las tareas diarias de una base de datos,
como una simple sentencia SELECT. Esta sección nos llevará a través de
ejemplos que utilizan el JDBC para ejecutar sentencias SQL comunes, para
que podamos ver lo sencilla que es la utilización del API JDBC básico.
Esta sección está dividida a su vez en dos secciones.

JDBC Basico que cubre el API JDBC 1.0, que está incluido en el JDK 1.1.
La segunda parte cubre el API JDBC 2.0 API, que forma parte de la versión 1.2
del JDK. También describe brevemente las extensiones del API JDBC, que, al
igual que otras extensiones estándard, serán liberadas independientemente.
Al final de esta primera sección, sabremos como utilizar el API básico del JDBC
para crear tablas, insertar valores en ellas, pedir tablas, recuperar los
resultados de las peticiones y actualizar las tablas. En este proceso,
aprenderemos como utilizar las sentencias sencillas y sentencias preparadas, y
veremos un ejemplo de un procedimiento almacenado. También aprenderemos
como realizar transaciones y como capturar excepciones y avisos. En la última
parte de este sección veremos como crear un Applet.
Nuevas Características en el API JDBC 2.0 nos enseña como mover el
cursor por una hoja de resultados, cómo actualizar la hoja de resultados
utilizando el API JDBC 2.0, y como hacer actualizaciones batch. También
conoceremos los nuevos tipos de datos de SQL3 y como utilizarlos
en aplicaciones escritas en Java. La parte final de esta lección entrega una
visión de la extensión del API JDBC, con caracterísitas que se aprovechan de
la tecnologías JavaBeans y Enterprise JavaBeans.
Esta sección no cubre cómo utilizar el API metadata, que se utiliza en
programas más sofisticados, como aplicaciones que deban descubrir y
presentar dinámicamente la estructura de una base de datos fuente.
La Conectividad de Bases de Datos Java (Java Database Connectivity, JDBC)
es una especificación de la interfaz de aplicación de programa (application
program interface, API) para conectar los programas escritos en Java a los
datos en bases de datos populares. La interfaz de aplicación de programa nos
permite codificar órdenes de solicitud de acceso en lenguaje estructurado de
solicitud (structured query language, SQL) que luego pasan al programa que
administra la base de datos. Devuelve los resultados a través de una interfaz
similar. La JDBC es muy similar a la Conectividad Abierta de Base de Datos
(Open Database Connectivity, ODBC) de Microsoft y, con un pequeño
programa "puente" podemos usar la interfaz JDBC para acceder a bases de
datos a través de la interfaz ODBC de Microsoft. Por ejemplo, podemos escribir
un programa diseñado para acceder a muchos productos populares de base de
datos en una variedad de plataformas de sistema operativo. Cuando se accede
a una base de datos en un PC que corre bajo Windows 95 de Microsoft y, por
ejemplo, una base de datos de Microsoft Access, nuestro programa con
órdenes JDBC será capaz de acceder a la base de datos de Access de
Microsoft.
La JDBC tiene actualmente dos niveles de interfaz. Además de la interfaz

principal hay también una API de un "administrador" JDBC que a su vez se
comunica con los "controladores" de producto de las bases de datos
individuales, si es necesario, el puente JDBC-ODBC bridge y a un controlador
de red JDBC cuando el programa Java está corriendo en un entorno de red (es
decir, accediendo a una base de datos remota).
Cuando accede a una base de datos remota, la JDBC aprovecha el esquema

de dirección de archivos de Internet y un nombre de archivo que tiene en
mucho la apariencia de una dirección de página web (o URL). Por ejemplo, una
orden SQL en Java puede identificar a la base de datos como:
jdbc:odbc://www.empresa.com:400/basededatos
JDBC especifica un conjunto de clases de programación orientada a objetos
para que el programador lo use en la construcción de solicitudes SQL. Un
conjunto adicional de clases describe el controlador API de JDBC. Soporta los
tipos de datos más comunes de SQL, mapeados en forma de tipos de datos
Java. La API permite el soporte específico de implementación para las
solicitudes transaccionales y la capacidad de "comprometerse" o volver al
principio de una transacción.13

A27-I7 JDBC.
Hacer una investigación de complemento al tema de JDBC.
b) Producto esperado: Investigación
c) Fecha inicio:
d) Fecha entrega:

Documento que avale la
investigacón, el documento
JDBC 5 puntos
debe contener fuentes
bibliograficas
Total 5 Puntos

Conocer las características generales de JDBC
http://www2.terra.com/informatica/que-es/jdbc.cfm
6.3.7. DOCUMENTOS
13
http://www2.terra.com/informatica/que-es/jdbc.cfm (05-Ago-05)
UNIDAD TEMATICA 7. PROYECTO FINAL
PONER EN PRACTICA TODO LO APRENDIDO EN ESTA MATERIA
7.1.3. DESARROLLO
Esta unidad consite básicamente en realizar un proyecto que incluya muchos
de los conceptos y practicas vistas en el curso. Por lo cual se pide un proyecto
por equipo de 4 personas, el cual debe cumplir con los siguientes requisitos:
1. El proyecto a realizar debe de estar basado en una organización real.

2. Debe manejar una base de datos distribuida o relacional la que mejor se
adpate a la organización.
3. Todas las reglas de negocio deben de estar validadas ya sea por
restricciones CHECK, Reglas, Transacciones, Procedimientos, además
debe de contener los posibles usuarios que el sistema requiera.
4. Por ultimo debe de haber una aplicación que manipule los datos de la
base de datos.
7.1.3.1. TÉCNICA DIDÁCTICA Practica por parte de los alumnos

A28-T7 Análisis del sistema.
Realizar el análisis del negocio para poder definir la base da datos (Los puntos
a cubrir que a disposición del docente)
b) Producto esperado: Análisis del Sistema
c) Fecha inicio:
d) Fecha entrega:

Debe cubrir con todos los
Análisis del sistema puntos que el docente 10 puntos
disponga
Total 10 Puntos

A29-T8 Diseño de la Base de Datos.
Diseñar la Base de Datos en base al análisis hecho en la practica anterior.
g) Valor actividad: 15 Puntos
h) Producto esperado: Base de Datos
i) Fecha inicio:
j) Fecha entrega:
k) Forma de entrega: Archivo
l) Tipo de Actividad: Equipo (4 gentes)

La Base de Datos debe de
estar normalizada y debe de
Diseño de la Base de Datos 15 puntos
cubrir con todos los aspectos
del negocio
Total 15 Puntos

A30-T9 Reglas de Negocio.
Aplicar todas las reglas del negocio utilizando restricciones CHECK, reglas,
transacciones, relaciones, etc. Asi como tambien debe de contener los usuarios
con los privilegios correspondientes.
m) Valor actividad: 20 Puntos
n) Producto esperado: Reglas del negocio aplicadas
o) Fecha inicio:
p) Fecha entrega:
q) Forma de entrega: Archivo
r) Tipo de Actividad: Equipo (4 gentes)

Las reglas deben de estar
Reglas de Negocio 20 puntos
aplicadas
Total 20 Puntos
A31-T10 Sistema de Base de Datos.
En cualwuier lenguaje de programación, realizar la aplicación que interacte con
la base de datos.
s) Valor actividad: 10 Puntos
t) Producto esperado: Sistema de Base de Datos
u) Fecha inicio:
v) Fecha entrega:
w) Forma de entrega: Archivo
x) Tipo de Actividad: Equipo (4 gentes)

Checar que el sistema cumpla
Sistema de Base de Datos con las especificaciones 10 puntos
necesarias
Total 10 Puntos

Conocer el negocio del cual se va a realizar el diseño de la base de datos
Manual de las materias de “Calidad de SoftWare” y el de “Ingenieria de
SoftWare”.
Diseño y Administración de Bases de Datos, HANSEN-HANSEN, PRENTICE-
HALL , Segunda edición.
7.1.7. DOCUMENTOS
ANEXO A
BASE DE DATOS II
RESUMEN DE ACTIVIDADES DE APREDIZAJE
MES 1
Actividad de Fecha de Fecha de
Puntuación
Aprendizaje Inicio Entrega
A1-T1 Cuestionario. 5 puntos
A2-T2 Realizar Base de Datos 5 Puntos
A3-EC1 Sentencias SQL “Tablas
10 puntos
Multiples”
A4-ER1 Examen Rápido. 10 Puntos
A5-EC2 Procedimientos
10 Puntos
Almacenados
A6-EC3 Procedimientos de
10 Puntos
disparo
A7-EC4 Vistas 10 Puntos
Subtotal 60 Puntos
Examen 40 Puntos
Puntaje total del mes: 100 Puntos
MES 2
Puntuación
A8-ER2 Examen Rápido 5 Puntos
A9-EC5 Restricciones
5 Puntos
CONSTRAINTS
A10-EC6 Valores por omision 5 Puntos
A11-I1 Investigacion de
5 Puntos
Indices
A12-EC7 Crear Indices 5 Puntos
A13-T3 Cuestionario
2.5 Puntos
transacciones
A14-ER3 Examen Rápido 5 Puntos
A15-T4 Cuestionario planes 2.5 Puntos
A16-EC8 Transacciones 10 Puntos
A17-EC9 Crear usuarios 5 Puntos
A18-EC10 Seguridad de SQL 5 Puntos
A19-T5 Concesion y Renovación
5 Puntos
de privilegios
Subtotal 60 Puntos
Examen 40 Puntos
MES 3
Puntuación
A20-T6 Configurar SQL Server
para poder supervisar los 5 Puntos
sucesos
A21-ER4 Examen Rápido de los
Requisito
temas 4.3 y 4.4
A22-I2 Sistemas en
5 Puntos
organizaciones
A23-ER5 Examen Rápido de SGBD 5 Puntos
A24-EC11 Realización de una
30 Puntos
Base de Datos Distribuida.
A25-ER6 Examen Rápido XML 5 Puntos
A26-EC12 Manejo de Bases de
10 Puntos
Datos a través de ADO
Subtotal 60 Puntos
Examen 40 Puntos
MES 4
Puntuación
A27-I7 JDBC 5 Puntos
A28-T7 Análisis del sistema 10 Puntos
A29-T8 Diseño de la Base de
15 Puntos
Datos.
A30-T9 Reglas de Negocio. 20 Puntos
A31-T10 Sistema de Base de
10 Puntos
Datos.
Subtotal 60 Puntos
Examen 40 Puntos
Claves de apoyo:
A: Actividad (A#-Tipo#)
T: Tarea
I: Investigación
EC: Ejercicios en clases
ER: Examen Rápido
ANEXO B
BASE DE DATOS II
RESUMEN DE ACTIVIDADES DE SESIONES

MES 1
Fecha de la No.
Tema
sesión Hrs.
1.1. LA VENTAJA DEL SQL 1
1.2. CONSULTA DE UNA SOLA TABLA 2
1.3. CONSULTA DE TABLAS MULTIPLES 3
1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O
SUBCONSULTAS 5
1.5. PROCEDIMIENTOS ALMACENADOS 6
1.6. TRIGGERS 7
1.7. VISTAS 6
SUBTOTAL DE
HRS FRENTE A 28
GRUPO
HORAS
0
EXTRACLASE
TOTAL DE HRS
28
AUTORIZADAS
MES 2
Fecha de la No.
Tema
sesión Hrs.
2.1. TIPOS DE INTEGRIDAD DE DATOS 1
2.2. USANDO RESTRICCIONES (CONSTRAINTS) 2
2.3. USANDO VALORES POR OMISIÓN Y REGLAS 4
2.4. INTRODUCCIÓN A INDICES 1
2.5. ARQUITECTURA y CREACIÓN DE INDICES 3
3.1. PROCESAMIENTO DE TRANSACCIONES ½

3.2. CONCEPTOS DE TRANSACCIONES ½
3.3. PROPIEDADES DE LAS TRANSACCIONES 1
3.4. PLANES Y RECUPERABILIDAD 1
3.5. SERIABILIDAD DE PLANES 1
3.6. TRANSACCIONES SQL 8
4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS 1

4.2. TIPOS DE SEGURIDAD 2
4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN / 2
RENOVACION DE PRIVILEGIOS.
SUBTOTAL DE
HRS FRENTE A 28
GRUPO
HORAS
0
EXTRACLASE
TOTAL DE HRS
28
AUTORIZADAS
MES 3
Fecha de la No.
Tema
sesión Hrs.
4.4. SEGUIMIENTO DE AUDITORIA 2
5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES 2

5.2. MODELO GENERAL DE UN SGBD 1
5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y
RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS. 7
6.1. ARQUITECTURAS MULTICAPA y XML 4

6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y
ASP. 12
SUBTOTAL DE
HRS FRENTE A 28
GRUPO
HORAS
0
EXTRACLASE
TOTAL DE HRS
28
AUTORIZADAS
MES 4
Fecha de la No.
Tema
sesión Hrs.
6.3. JDBC, PAGINAS DEL SERVIDOR JAVA. 5
PROYECTO FINAL 16
SUBTOTAL DE
HRS FRENTE A 21
GRUPO
HORAS
0
EXTRACLASE
TOTAL DE HRS
21
AUTORIZADAS

Manual Base de Datos II TIC Completo

Cargado por

Copyright:

Formatos disponibles

Manual Base de Datos II TIC Completo

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

Manual Base de Datos II TIC Completo

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD TECNOLÓGICA DE LA HUASTECA

TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

Manual de la asignatura del profesor:

ISC LEODEGARIO REDONDO MARTÍNEZ

Revisado por Director de Carrera

M en C FELIPE DE JESÚS NÚÑEZ CARDENAS

FIRMAS DE AUTORIZACIÓN ...................................................................................................... 3

ISC LEODEGARIO REDONDO M en C FELIPE DE JESÚS NÚÑEZ

Vo. Bo. Autorizó

MAD. Marisol Flores Contreras Dra. Miriam Yta

Elevar la calidad académica de esta universidad se ha convertido en el objetivo

Dentro de este marco los materiales didácticos se convierten en instrumentos

Esta guía pretende proporcionar una visión de conjunto de la asignatura, así

Creemos que esta Guía puede facilitar al alumno de la Universidad Tecnológica

El presente manual representa ser un instrumento de apoyo para que el

1.1. LA VENTAJA DEL SQL

1.1.2. RECURSO TIEMPO DEL TEMA 1 hora

Debido a la diversidad de lenguajes y de bases de datos existentes, la manera

Es de eso de lo que trata el Structured Query Language que no es mas que un

Aparte de esta universalidad, el SQL posee otras dos características muy

LENGUAJE DE CONSULTA ESTRUCTURADO SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos

Transact-SQL (T-SQL) es el lenguaje de programación del SQL Sever, a través

EL T-SQL se puede utilizar desde multitud de aplicaciones y desde diferentes

No se utiliza dentro de estos lenguajes sino en desde los llamados

El RDBMS es responsable de:

 Mantener las relaciones entre la información y la Base de Datos.

PLATAFORMAS PARA SQL

Los componentes Cliente y Servidor de SQL Server corren en los Sistemas

1.1.3.1. TÉCNICA DIDÁCTICA Exposición del profesor.

1.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1

1.1.5. RESULTADO DE APRENDIZAJE

1.2. CONSULTA DE UNA SOLA TABLA

Como sabemos una base de datos esta compuesta de tablas donde

Un aspecto previo a considerar es la naturaleza de los valores que

Cada base de datos introduce tipos de valores de campo que no

Alfanuméricos Contienen cifras y letras. Presentan una longitud

Booleanos Poseen dos formas: Verdadero y falso (Sí o No)

Almacenan fechas facilitando posteriormente su

Son campos alfanuméricos de longitud ilimitada.

Son campos numéricos enteros que incrementan en una

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y

Existen dos tipos de comandos SQL:

Las funciones de agregado se usan dentro de una cláusula SELECT en grupos

Valor que se aplica a un grupo de registros.

Bases de datos-SQL-Sentencias SQL-Consultas de Selección

La sintaxis básica de una consulta de selección es la siguiente:

SELECT Campos FROM Tabla

En donde campos es la lista de campos que se deseen recuperar y tabla es

SELECT Nombre, Teléfono FROM Clientes

Esta sentencia devuelve un conjunto de resultados con el campo nombre y

SELECT Empleados.Nombre, 'Tarifa semanal: ', Empleados.TarifaHora * 40

ORDENAR LOS REGISTROS

Adicionalmente se puede especificar el orden en que se desean recuperar los

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER y Nombre

Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la

SELECT CodigoPostal, Nombre, Telefono FROM Clientes

Incluso se puede especificar el orden de los registros: ascendente mediante la

SELECT CodigoPostal, Nombre, Telefono FROM Clientes