Módulo I: Diseño de una base de datos

Tema 1:Teoría de sistemas de base de datos relacional

Conceptos básicos
Que es un sistema de base de datos?
El modelo Relacional
Terminología relacional

Tema 2: Introducción al diseño de bases de datos

Componentes de una base de datos SQL Server
Normalizar un diseño de base de datos
. Lograr una base de datos bien diseñada
Relaciones entre entidades
. Relaciones entre tablas uno-a-uno
. Relaciones entre tablas uno-a-muchos
. Relación entre tablas muchos-a-muchos

Tema 3: Elementos adicionales para el diseño una base de datos SQL Server
Archivos y Grupos de archivos
. Reglas para diseñar Archivos y Grupos de archivos
. Grupos de archivos predefinido
. Recomendaciones
Registros de transacciones
Ambiente
. Estimar el Tamaño de una base de datos
. Diseño físico de la base de datos
Algunas consideraciones sobre instalación de SQL Server
. Seguridad
. Planificar la Seguridad
. Niveles de seguridad
. Modos de autenticación

Tema 4: Identificar los requerimientos de diseño

El Proceso de Identificar los Requerimientos de diseño
Identificar las Metas del Sistema
Identificar la Cantidad y Tipos de Datos
Identificar Cómo se usarán los Datos
Identificar las Reglas Comerciales del Sistema

Tema 5: Desarrollar un modelo lógico de base de datos

Identificar Entidades y Sus Atributos
Identificando Relaciones Entre las Entidades
Identificar Restricciones sobre los Datos

Ejercicios Prácticos

Módulo II: Implementar una base de datos y sus tablas

Tema 1: Crear y administrar una base de datos SQLServer
Métodos para crear una base de datos SQLServer
. El comando CREATE DATABASE
. Usar el Enterprise Manager
. El asistente Create Database
Administrar una base de datos SQL Server
. Ver información referida a la base de datos
Modificar una base de datos
. Configurar opciones de la base de datos
Borrar una base de datos SQL Server

Tema 2: Identificar Tipos de Datos

Tipos de datos provistos por el sistema
Tipos de datos definidos por el usuario

Tema 3: Crear y administrar tablas en SQL Server

Crear tablas en una base de datos SQL-Server
. Determinar la anulabilidad de las columnas
. Definir valores por defecto
. Auto numeración y columnas de identificación
Crear columnas de identificación
Propiedad IDENTITY
Identificadores globalmente únicos
. Métodos para crear tablas
Comando CREATE TABLE
 Enterprise Manager
Database Designer (Diseñador de base de datos)
Administrar tablas de una base de datos SQL Server
. Consultar información sobre tablas
. Modificar tablas de una base de datos SQL Server
. Borrar tablas de una base de datos SQL Server

Tema 4: Implementar la integridad de los datos

Introducción a la integridad de los datos
. Asegurar la integridad de los datos
. Tipos de Dato
. Definiciones NOT NULL
. Definiciones DEFAULT
. Propiedades IDENTITY
. Restricciones (constraints)
. Reglas (rules)
. Desencadenadores
. Indices
Tipos de Integridad de datos
. Integridad de entidad
. Integridad de dominio
. Integridad referencial
. Integridad definida por el usuario
Implementar restricciones de integridad
. Introducción a las restricciones de integridad
. Restricciones PRIMARY KEY
Crear restricciones PRIMARY KEY
. Restricciones UNIQUE
Crear restricciones UNIQUE
. Restricciones FOREIGN KEY
Crear restricciones FOREIGN KEY
Deshabilitar restricciones FOREIGN KEY
. Restricciones CHECK
Crear restricciones CHECK
Deshabilitar restricciones CHECK

Tema 5: Implementar índices

Introducción
Arquitectura de los índices
. Propósito y estructura
. Tipos de índices
. Índices agrupados
. Índices no agrupados
. Características de los índices
Unicidad
Índices compuestos
Factor de llenado
Sentido de ordenamiento
. Información sobre índices
. Indexado Full-Text
Crear y administrar índices
. Crear índices
Usar interfase gráfica
Usar comandos Transact-SQL
. Administrar índices
Eliminar un índice
Reconstruir un índice
Renombrar un índice
. Elegir un índice
Índices agrupados
Índices no agrupados
. Recubrimiento de índice
. Índices compuesto frente a índices múltiples

Módulo III: Consultar y modificar datos

Tema 1: Principios de álgebra relacional
Operaciones relacionales
. Restricción
. Proyección
. Producto
. Unión
. Intersección
. Diferencia
. Reunión
. División
Cálculo relacional
 . Listas objetivo
. Expresiones

Tema 2: Consultar a los datos en una base de datos SQL Server

Los fundamentos del comando SELECT
El comando SELECT
. Usar cláusulas en la lista de selección
La cláusula DISTINCT
La cláusula TOP n
La cláusula AS
Tipos de información en la lista de selección
La cláusula INTO
La cláusula FROM
Las cláusulas WHERE, GROUP BY, y HAVING
. La cláusula GROUP BY
. Procesar las cláusulas WHERE, GROUP BY , y HAVING
La cláusula ORDER BY

Tema 3: Usar técnicas de consulta avanzadas para acceder a los datos

Usar combinaciones para recuperar datos
. Combinaciones INNER
. Combinaciones OUTER
Usar LEFT OUTER JOIN
Usar RIGHT OUTER JOIN
Usar FULL OUTER JOIN
. Definir subconsutas dentro del comando SELECT
. Tipos de Subconsultas
Subconsultas que son usadas con IN y NOT IN
Subconsultas que son usadas con operadores de comparación
Subconsultas que son usadas con EXISTS y NOT EXISTS
Resumir datos
. Usar el operador CUBE para resumir datos
. Usar el operador ROLLUP para resumir datos

Tema 4: Modificar datos en una base de datos SQL Server

Insertar datos en un base de datos SQL Server
. Usar el comando INSERT para agregar datos
Usar el comando INSERT...VALUES para agregar datos
Usar una subconsulta SELECT para agregar datos
. Usar un comando SELECT...INTO para agregar datos
. Agregar texto o imágenes a filas ya insertadas
Modificar datos en una base de datos SQL Server
. Usar el comando UPDATE para modificar datos
Usar la cláusula SET para modificar datos
Usar la cláusula WHERE para modificar datos
Usar la cláusula FROM para modificar datos
Modificar textos o imágenes
Borrar datos de una base de datos SQL Server
. Usar el comando DELETE para borrar datos
. Usar el comando TRUNCATE TABLE para borrar datos

Módulo IV: Implementar procedimientos almacenados

Tema 1: Introducción a los procedimientos almacenados
Propósitos y ventajas de los Procedimientos Almacenados
. Rendimiento
Marco de programación
Seguridad
Categorías de procedimientos almacenados
. Procedimientos almacenados del sistema
. Procedimientos almacenados locales
. Procedimientos almacenados temporarios
. Procedimientos almacenados extendidos
. Procedimientos almacenados remotos

Tema 2: Crear, ejecutar, modificar y borrar procedimientos almacenados

Cómo se almacena un procedimiento
Métodos para crear procedimientos almacenados
. El comando CREATE PROCEDURE
Proveer a un procedimiento almacenado de un contexto
Crear procedimientos almacenado temporarios
Agrupar, levantar y encriptar procedimientos almacenados
Enterprise Manager
El asistente para crear de procedimientos almacenados
Crear y agregar procedimientos almacenados Extendidos
 Diferir la resolución de nombres
Ejecutar un procedimiento almacenado
. Llamar un procedimiento almacenado para ejecutarlo
. Especificar parámeros y sus valores
. Ejecutar prcedimientos almacenados cuando SQL Server arranca
Modificar procedimientos almacenados
Borrar procedimientos almacenados

Tema 3: Programar procedimientos almacenados

Parámetros y variables
El comando RETURN y el manejo de errores
Valores por defecto y parámetros NULL
Comprobar errores del Server
Procedimientos asidados
Cursores
Métodos para recuperar datos

Módulo V: Conectarse a un SQL Server

Tema 1: Comenzando con ADO - ActiveX Data Objects

Tema 2: Modelo de objetos de ADO

Tema 3: Objetos ADO

Tema 4: Propiedades ADO

MODULO I

Tema 1: Teoría de Sistema de Base de Datos Relacional

Lo que aprenderá:

Al terminar este tema usted podrá:

· Entender los principales conceptos de la teoría de base de datos relacionales

Que es un sistema de base de datos?

Un sistema de Base de Datos es básicamente un sistema para archivar en computador; o sea, es un sistema
computarizado cuyo propósito general es mantener información y hacer que esté disponible cuando se
solicite.
La información en cuestión puede ser cualquier cosa que se considere importante para el individuo o la
organización a la cual debe servir el sistema; dicho de otro modo, cualquier cosa necesaria para apoyar el
proceso general de atender los asuntos de esa organización.
Pero es fundamental para el éxito de su proyecto limitar el sistema de base de datos, que Ud. quiere diseñar,
a un específico y bien definido conjunto de objetos e interacciones; lo que le permitirá definir el alcance del
sistema. Como veremos mas adelante no se trata de modelizar "todo" el mundo sino solo la parte
"importante" y "pertinente" para alcanzar los objetivos funcionales del sistema. Esa parte del mundo que nos
interesa la llamaremos el espacio del problema.
El término modelo de datos se utilizará se utilizará para significar una descripción conceptual del espacio del
problema, esto incluye la definición de sus entidades, que son clases de objetos que comparten determinadas
características (por ejemplo un "cliente" es una entidad), dichas características se las denomina atributos
(por ejemplo el "nombre" del cliente es un atributo de un cliente).
El modelo de datos incluye la descripción de las interrelaciones entre las entidades y las restricciones sobre
dichas relaciones (por ej: las "facturas de venta" se emiten a nombre de un "cliente" y esta relación no puede
faltar, es decir , no puede haber una factura que no tenga asignada un cliente.
La capa física o esquema físico del diseño, está constituida por las tablas y vistas que serán implementadas,
y constituye la traslación del modelo conceptual en una representación física que pueda ser implementada
utilizando el Sistema de Gestión de Bases de Datos Relacional (SGBDR) a ser empleado, a los fines del
presente Kit, el MS-SQL Server 2000. Este esquema no es mas que la representación del modelo conceptual
o lógico expresado en términos que puedan ser usados para describirlo al SGBDR.
A medida que Ud. le vaya explicando al SGBDR como quiere que almacene los datos, el SGBDR creará los
objetos necesarios para gestionarlos (tablas, vistas, índices, relaciones, etc). Lo que dará origen a la
estructura la base de datos.
Por último, llamaremos base de datos a la combinación de los datos y su estructura. La base de datos
incluye, entonces, a los datos mas las tablas, vistas, procedimientos almacenados, consultas, y a las reglas
que el motor de base datos utilizará para asegurar el resguardo de los datos.
El término base de datos no incluye a la aplicación la cual consiste de los formularios y los reportes con los
que interactuarán los usuarios, ni incluye la piezas de código usadas para unir las partes de la aplicación.
En un modelo de tres capas, la aplicación que accede a los datos almacenados en una base de datos y que a
la vez interactúa con el usuario se divide en dos partes: la llamada capa intermedia que contiene todas las
validaciones y las reglas del negocio y es la que interactúa con la base de datos y el front end que es la que
contiene los formularios y realiza la presentación de los reportes, interactuando con el usuario final (ver
figura 1.1).

El modelo Relacional

El modelo relacional está basado en una colección de principios matemáticos desarrollado inicialmente sobre
un conjunto de conceptos teóricos y predicados lógicos. Esto principios fueron aplicados al campo de los
modelos de datos a finales de los años ´60 por el Dr. E. F. Codd, investigador de IBM, y publicados por
primera vez en 1970.
El modelo relacional define el modo en que los datos van a ser representados (estructura de datos), la forma
en que van ser protegidos (integridad de los datos) y las operaciones que pueden ser aplicadas sobre ellos
(manipulación de datos).
El MS-SQLServer 2000 implementa un modelo relacional de base de datos.
En términos generales un sistema de base de datos relacional tiene las siguientes características:
· Todos los datos están conceptualmente representados como un arreglo ordenado de datos en filas y
columnas, llamado relación.
· Todos los valores son escalares, esto es, que dada cualquier posición fila/columa dentro de la relación hay
uno y solo un valor.
· Todas las relaciones son realizadas sobre la relación completa y dan como resultado otra relación, concepto
conocido como clausura .
A los fines prácticos una relación puede ser considerada como una tabla, aún cuando al momento de
formularse la teoría intencionalmente se excluyó el término tabla por tener connotaciones de ordenamiento
que no se deben aplicar al concepto de relación que es mas un conjunto, que una tabla ordenada. De todos
modos y a los fines del presente Kit utilizaremos en forma indistinta la denominación de relación o de tabla.
Es importante destacar que el concepto de clausura permite que el resultado de una operación sobre un
relación sea el dato para otra operación. Por lo que como veremos mas adelante al resultado de una orden
select se le puede aplicar otro select.

Terminología relacional

La Figura 1.2 muestra una relación con los nombres formales de sus componentes principales
La estructura de la figura constituye una relación, donde cada fila constituye una tupla. La cantidad de tuplas
en una relación indica la cardinalidad de la relación. Cada columna en la relación es un atributo, y la cantidad
de atributos indica el grado de la relación.
La relación se divide en dos secciones el encabezado y el cuerpo, donde el encabezado contiene la etiquetas
de los atributos. Estas etiquetas constan de dos parte separadas por dos puntos ":" la parte izquierda es la
denominación propiamente dicha del atributo, mientras que la parte derecha configura el dominio del
atributo, que es el conjunto de todos los valores posibles y legales que puede tomar el atributo en las tuplas
(por ej: el primer atributo de la relación de la figura tiene como dominio a todas las compañías que existen,
mientras que solo algunas son valores efectivamente incorporados a la relación).
El cuerpo consiste en un conjunto desordenado de cero o más tuplas, esto indica que las tuplas no tienen un
orden intrínseco, el número de registro no es tenido en cuenta en el modelo relacional. Por otro lado las
relaciones sin tuplas siguen siendo relaciones. Por último las relaciones son conjuntos donde cualquier
elemento puede ser inequívocamente identificado, por lo que la relación no permite tuplas duplicadas.
En cuanto a la terminología, en esta parte se utilizó una lenguaje formal para la definición de los elementos
abordados, a partir de ahora se utilizarán las siguientes equivalencias de significado:
Una relación puede ser una tabla, o un recordset o un result set.
Una tupla puede ser una fila (row) o un registro (record)
Un atributo puede ser una columna (column) o un campo (field).
Dichas equivalencias se generan porque al instanciar en la implementación física el modelo conceptual, se
utilizan términos que corresponden precisamente al modelo físico de implementación en el SGBDR, en este
caso el MS-SQLServer 2000, que utiliza la terminología Microsoft.

MODULO I

Tema 2: Introducción al diseño de bases de datos

Lo que aprenderá:

Al terminar este tema usted podrá:

· Describir los componentes principales de una base de datos relacional.
· Describir el proceso de normalización y normalizar tablas en un diseño de bases de datos.
· Identificar las relaciones que existen entre las entidades.

Antes de que usted pueda desarrollar un modelo lógico de datos, y subsecuentemente crear una base de
datos y los objetos que esta contiene, usted debe comprender los conceptos fundamentales del diseño de
bases de datos. Además, deberá estar familiarizado con los componentes básicos de una base de datos y
cómo esos componentes trabajan juntos para proporcionar un almacenamiento eficaz de los datos y acceso a
aquellos que requieren tipos específicos de datos, en formatos específicos, desde la base de datos.
Este tema presenta los componentes básicos de una base de datos y la terminología que describe esos
componentes. Se discute la normalización y el concepto de relaciones entre entidades, dos conceptos que
deben integrarse para entender el diseño de bases de datos relacionales.

Componentes de una base de datos SQL Server

Una base de datos SQL Server consiste en una colección de tablas que guardan conjuntos específicos de
datos estructurados. Una tabla (entidad) contiene una colección de filas (tuplas) y columnas (atributos). Cada
columna en la tabla se diseña para guardar un cierto tipo de información (por ejemplo, fechas, nombres,
montos, o números). Las tablas tienen varios tipos de controles (restricciones, reglas, desencadenadores,
valores por defecto, y tipos de datos de usuario) que aseguran la validez de los datos. Las tablas pueden
tener índices (similar a los de los libros) que permiten encontrar las filas rápidamente. Usted puede agregar
restricciones de integridad referencial a las tablas para asegurar la consistencia entre los datos
interrelacionados en tablas diferentes. Una base de datos también puede utilizar procedimientos almacenados
que usan Transact-SQL programando código para realizar operaciones con los datos en la base de datos,
como guardar vistas que proporcionan acceso personalizado a los datos de la tabla.

Por ejemplo, suponga que se crea una base de datos llamada MiCoBD para manejar los datos en su
compañía. En la base de datos MiCoBD, crea una tabla llamada Empleados para guardar información sobre
cada empleado, y la tabla contiene las columnas EmpID, Apellido, Nombre, Dept, y Cargo. Para asegurar que
nunca dos empleados tengan el mismo EmpID y que la columna de Dept contiene números sólo válidos para
las secciones en su compañía, usted debe agregar restricciones a la tabla. Si usted quisiera realizar
búsquedas rápidas para encontrar los datos de un empleado basado en el ID del empleado, usted definiría
índices. Por cada empleado, se agrega una fila de datos a la tabla Empleados, para esto usted crea que un
procedimiento almacenado llamado AgregarEmp que se personaliza para aceptar los valores de los datos por
un nuevo empleado y que realiza la operación de agregar la fila a la tabla Empleados. Se podría necesitar un
resumen departamental de empleados, por lo que usted define una vista llamada EmpsDept que combina
datos de las tablas Secciones y Empleados. Figura 2.1 muestra las partes de la base de datos MiCoBD.
Figura 2.1 La base de datos MiCoBD, la tabla Empleados, y la vista EmpsDept

Normalizar un diseño de base de datos

A continuación se verá el tema de normalización desde un punto vista práctico, resaltando aquellos conceptos
útiles y comentando las limitaciones que deben tenerse en cuenta en el proceso de normalizado de una base
de datos.

Perfeccionar un diseño de base de datos incluye el proceso de normalización. Normalizar un diseño lógico de
base de datos involucra usar métodos formales para separar los datos en múltiples tablas relacionadas. Tener
un número mayor de tablas con pocas columnas es característico de una base de datos normalizada;
mientras que tener pocas tablas con más columnas cada una es característico de una base de datos no-
normalizada.

Una normalización razonable mejora a menudo el comportamiento general del sistema. Cuando se utilizan los
índices, el SQL Server 2000 Query Optimizer (Optimizador de Consultas de SQL Server) es muy eficiente al
seleccionar interrelaciones entre las tablas.
Un aumento de la normalización produce una mayor cantidad y complejidad de combinaciones entre las
tablas requeridas para recuperar los datos. Demasiadas combinaciones complejas entre varias tablas puede
deteriorar el rendimiento en las consultas. Una normalización razonable debería incluir la mínima cantidad de
consultas habituales posible que involucren más de cuatro tablas relacionadas.

Una base de datos que se usa principalmente para soporte de decisión (al revés de una base de datos
operacional que realiza tareas de actualización de datos) podría no tener actualizaciones redundantes y
podría ser más entendible y eficaz para las consultas si el diseño no se normaliza totalmente. No obstante,
tener datos no-normalizados es el error de diseño más común en aplicaciones de base de datos más que
tener datos demasiado normalizados. Empezar con un diseño completamente normalizado y a partir de allí
desnormalizar selectivamente algunas tablas por razones específicas de rendimiento de las consultas es una
buena estrategia.

A veces el diseño de la base de datos lógico ya está definido, tal el caso de una base de datos existente, y el
rediseño total no es factible. Pero aún entonces, podría ser posible normalizar una tabla grande
selectivamente en varias tablas más pequeñas. Si la base de datos es accedida a través de los
procedimientos almacenados, este cambio del esquema podría tener lugar sin afectar las aplicaciones. Si no,
podría ser posible crear una vista que esconde de las aplicaciones el cambio del esquema.

Lograr una base de datos bien diseñada

En la teoría de diseño de base de datos relacionales, las reglas de normalización identifican ciertos atributos
que deben estar presentes o ausentes en una base de datos bien diseñada. Estas reglas pueden ponerse
bastante complicadas y pueden ir más allá del alcance del presente. De todos modos, hay algunas reglas que
pueden ayudarlo a lograr un diseño de la base de datos correcto. Una tabla debe tener un identificador, debe
guardar datos para sólo un solo tipo de entidad, debería evitar columnas que acepten valores nulos, y no
debe tener valores o columnas repetidas.

Una Tabla debe Tener un Identificador

La regla fundamental de la teoría del diseño de base de datos es que cada tabla debe tener un identificador
de las filas, que es una columna o un conjunto de columnas que toman valores únicos para cada registro de
la tabla. Cada tabla debe tener una columna de ID, y ningún registro puede compartir el mismo valor de ID
con otro. La columna (o columnas) que sirve como identificador único de la fila para una tabla constituye la
clave primaria de la tabla.

En la Figura 2.2, la tabla Empleados no incluye una columna que identifica unívocamente cada fila dentro de
la tabla. Fíjese que el nombre de David Mendlen aparece dos veces. Al no haber ningún identificador único en
esta tabla, no hay ninguna manera de distinguir fácilmente una fila de otra. Esta situación podría ser un
problema, más aún, si ambos empleados trabajaron en la misma sección y tienen el mismo tipo de trabajo.
Figura 2.2 Una tabla que no tiene ningún identificador único.
Usted puede normalizar la tabla agregando una columna que singularmente identifique cada fila, como se
muestra en la Figura 2.3. Fíjese que cada instancia de David Mendlen tiene un único valor de EmpID.

Figura 2.3 Una tabla normalizada con un identificador único.

Una Tabla debe Guardar Datos para un Solo Tipo de Entidad
Intentar guardar demasiada información en una tabla puede afectar la administración eficaz y fiable de los
datos en la tabla. Por ejemplo, en la Figura 2.4, la tabla Libros incluye información sobre cada editor de
libros.

Figura 2.4 Una tabla de libros que incluye título e información del editor.

Aunque es posible tener columnas que contienen información para el libro y su editor en la misma tabla, este
diseño lleva a varios problemas. La información del editor debe agregarse y debe guardarse
redundantemente para cada libro publicado por un editor dado. Esta información usa espacio extra de
almacenamiento en la base de datos. Si la dirección del editor cambia, el cambio debe realizarse en todos los
registros de libros de ese editor. Además, si el último libro de un editor es eliminado de la tabla Libros, la
información de ese editor se pierde.

En una base de datos normalizada, se guardaría la información sobre los libros y editores en por lo menos
dos tablas: una para los libros y una para los editores (como se muestra en Figura 2.5).
Figure 2.5 Un diseño de la base de datos normalizado incluye una tabla para los libros y una tabla para
información sobre el editor.

La información sobre el editor tiene que ser grabada sólo una vez y quedar vinculada a cada libro de ese
editor. Si la información del editor cambia, debe cambiarse en sólo un lugar, y la información del editor
estará allí aún cuando el editor no tenga ningún libro en la base de datos.

Una Tabla debe Evitar Columnas que acepten valores nulos

Las tablas pueden tener columnas definidas para permitir valores nulos. Un valor nulo indica que el registro
no tiene valor por ese atributo. Aunque puede ser útil permitir valores nulos en casos aislados, es mejor
usarlos muy poco porque ellos requieren un manejo especial con el consiguiente aumento de la complejidad
de las operaciones de datos. Si tiene una tabla que tiene varias columnas que permiten valores nulos y varias
de las filas tienen valores nulos en dichas columnas, debería considerar poner estas columnas en otra tabla
vinculada a la tabla primaria. Guardar los datos en dos tablas separadas permite que la tabla primaria sea
simple en su diseño pero a la vez mantener la capacidad de almacenar información ocasional.

Una Tabla no Debe tener Valores o Columnas Repetidas

Una tabla no debe contener una lista de valores para un pedazo específico de información. Por ejemplo,
suponga que usted quiere consultar los títulos de libros y sus autores. Aunque la mayoría de los libros
podrían tener sólo un autor, muchos de ellos podrían tener dos o más. Si hay sólo una columna en la tabla
Libros para el nombre del autor, esta situación presenta un problema. Una solución es guardar el nombre de
ambos autores en una columna, pero mostrar una lista de autores individuales sería entonces difícil. Otra
solución es cambiar la estructura de la tabla para agregar otra columna para el nombre del segundo autor,
pero esta solución guarda sólo dos autores. Debería agregarse otra columna si algún libro tiene tres autores.

Figure 2.6 Dos modos de estructurar la tabla Libros

Si usted encuentra que necesita guardar una lista de valores en una sola columna o si tiene columnas
múltiples para una sola pieza de datos (Autor1, Autor2, y así sucesivamente), debe considerar poner los
datos duplicados en otra tabla con un vínculo a la tabla primaria. En el caso de la tabla Libros, usted podría
crear una tabla primaria adicional para los autores y luego crear una tercera tabla que vincule los libros a sus
autores y almacene los valores repetidos, como se muestra en la Figura 2.7. Este diseño habilita cualquier
número de autores para un libro sin modificar la definición de la tabla y no desperdicia espacio libre para
almacenar libros que tienen un solo autor.

Figura 2.7 Tres tablas que guardan información sobre los libros y sus autores.

Relaciones entre entidades

En una base de datos relacional, las relaciones entre entidades ayudan a prevenir datos redundantes. Una
relación entre entidades trabaja vinculando datos de dos tablas a través de columnas clave, que
generalmente tienen el mismo nombre en ambas tablas. En la mayoría de los casos, la relación entre
entidades vincula la clave primaria de una tabla que proporciona a un identificador único para cada fila con
una entrada en la clave foránea de la otra tabla. Se discuten claves primarias y las claves foráneas en más
detalle en Tema 5, "Llevando a cabo Integridad de los Datos."

Hay tres tipos de relaciones entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de
relación depende de cómo se definen las columnas relacionadas.

Relaciones entre tablas uno-a-uno

En una relación uno-a-uno, una fila en tabla A no tiene más de una fila vinculada en tabla B (y viceversa).
Una referencia uno-a-uno se crea si las dos columnas relacionadas son claves primarias o tienen restricción
de unicidad. Este tipo de referencia no es común, sin embargo, porque la información relacionada de esta
manera normalmente estaría en una sola tabla.

Relaciones entre tablas uno-a-muchos

Una relación uno-a-muchos es el tipo más común de relación entre entidades. En este tipo de relación, una
fila en la tabla A tiene muchas filas vinculadas en la tabla B, pero una fila en la tabla B tiene una única fila
vinculada en la tabla A. Por ejemplo, las tablas Editores y Título mencionadas previamente tienen una
relación uno-a-muchos. Cada editor produce muchos títulos, pero cada título tiene un solo editor. Una
relación uno-a-muchos se crea si solo una de las columnas relacionadas es una clave primaria o tiene una
restricción de unicidad.

Relación entre tablas muchos-a-muchos

En una relación muchos-a-muchos, una fila en tabla A tiene muchas filas vinculadas en tabla B (y viceversa).
Se puede crear tal relación definiendo una tercera tabla, llamada tabla de unión cuya clave primaria consiste
en las claves foráneas de ambas tablas A y B. En las Figuras 2.6 y 2.7, usted vio cómo la información del
autor puede separarse en otra tabla. La tabla Libros y la tabla Autores tienen una relación muchos-a-muchos.
Cada una de estas tablas tiene una relación uno-a-muchos con la tabla de LibrosAutores que sirve como la
tabla de la unión entre las dos tablas primarias.

Ejercicio 1: Explorando los Conceptos Básicos de Diseño de la base de datos

En este ejercicio, usted verá los objetos primarios que están contenidos en una base datos SQL Server. Usted
aplicará los principios de normalización a un diseño de la base de datos e identificará las relaciones que
existen entre las entidades dentro de una base de datos.

Resumen del tema

Una base de datos SQL Server consiste en una colección de tablas que guardan un conjunto específico de
datos estructurados. Una tabla contiene una colección de filas y columnas. Cada columna en la tabla se
diseña para guardar un cierto tipo de información (por ejemplo, fechas, nombres, montos, o números). El
diseño lógico de la base de datos, incluyendo las tablas y las relaciones entre ellas, es el corazón de una base
de datos relacional optimizada. Perfeccionar un diseño de base de datos incluye el proceso de normalización.
Normalizar un diseño lógico de base de datos lógico involucra usar métodos formales para separar los datos
en múltiples tablas relacionadas. A medida que la normalización aumenta, incrementa el número y la
complejidad de los vínculos que son necesarios para recuperar los datos. Las reglas de normalización
identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseñada. Las
tablas en una base de datos normalizada deben tener un identificador, deben guardar sólo datos para un solo
tipo de entidad, deben evitar columnas que acepten valores nulos, y no deben tener valores o columnas
repetidos. Usted puede crear relaciones entre sus tablas en un diagrama de la base de datos y mostrar cómo
se vinculan las columnas en una tabla a las columnas de otra tabla. En una base de datos relacional, las
relaciones ayudan a prevenir datos redundantes. Una relación trabaja vinculando datos de las columnas,
generalmente columnas clave que tienen el mismo nombre en ambas tablas. Hay tres tipos de relaciones
entre las tablas: uno-a-uno, uno-a-muchos, y muchos-a-muchos. El tipo de relación entre tablas depende de
cómo usted define las columnas relacionadas.

MODULO I

Tema 3: Elementos adicionales para el diseño una base de datos SQL Server

Lo que aprenderá:

Al terminar este tema usted podrá:

· Describir los factores que se deben tener en cuenta al diseñar una base de datos SQL Server.

Al diseñar una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos
de la base de datos y grupos de archivos, registros de transacciones, la instalación del SQL Server y su
ambiente operativo, y la seguridad. Esta lección discute cada uno de estos temas.

Archivos y Grupos de archivos

Para definir una base de datos, SQL Server 2000 usa un conjunto de archivos del sistema operativo. Todos
los datos y objetos de la base de datos, como tablas, procedimientos almacenados, desencadenadores, y
vistas, se guardan dentro de los siguientes tipos de archivos del sistema operativo:
· Archivo Primario. Este archivo contiene la información de arranque para la base de datos y es usado para
almacenar datos. Cada base de datos tiene un archivo de los datos primario.
· Archivo Secundario. Estos archivos mantienen todos los datos que no caben en el archivo de los datos
primario. Si el archivo primario puede almacenar todos los datos da la base de datos, las bases de datos no
necesitan tener archivos de los datos secundarios. Algunas bases de datos podrían ser lo suficientemente
grandes para necesitar archivos de datos secundarios múltiples o usar archivos secundarios en unidades de
disco separadas para distribuir datos en múltiples discos o para mejorar el rendimiento de la base de datos.
· Registros de transacciones. Estos archivos mantienen la información del registro que se usa para recuperar
la base de datos. Debe haber por lo menos un archivo de registro para cada base de datos.

Una base de datos simple puede crearse con un archivo primario que contiene todos los datos y objetos y un
archivo de registro que contiene la información del registro de transacciones.

Alternativamente, una base de datos más compleja puede crearse con un archivo primario y cinco archivos
secundarios. Los datos y objetos de la base de datos son distribuidos por los seis archivos, y cuatro archivos
de registro adicionales contienen la información del registro de transacciones.

Los grupos de archivos agrupan archivos para propósitos administrativos y de ubicación de datos. Por
ejemplo, tres archivos (Data1.ndf, Data2.ndf, y Data3.ndf) pueden crearse en tres unidades de disco y
pueden asignarse al grupo de archivos fgroup1. Una tabla puede crearse entonces específicamente en el
grupo de archivos fgroup1. Las consultas sobre los datos de la tabla se extenderán por los tres discos y se
mejorará el rendimiento. La misma mejora de rendimiento puede lograrse con un solo archivo creado sobre
un arreglo redundante de discos independientes (RAID).

Los archivos y grupos de archivos, sin embargo, ayudan a agregar nuevos archivos fácilmente a los nuevos
discos. Adicionalmente, si su base de datos excede el tamaño del máximo para un solo archivo Windows NT,
usted puede usar un archivo de datos secundario para permitir el crecimiento de su base de datos.

Reglas para diseñar Archivos y Grupos de archivos

Cuando usted diseña archivos y grupos de archivos, debe adherir a las reglas siguientes:
· Un archivo o grupo de archivos no puede ser usado por más de una base de datos. Por ejemplo, los
archivos que ventas.mdf y ventas.ndf que contienen datos y objetos de la base de datos de ventas no
pueden ser usados por cualquier otra base de datos.
· Un archivo puede ser un miembro de sólo un grupo de archivos.
· Los datos y la información de registro de transacción no pueden ser parte del mismo archivo o grupo de
archivos.
· Los archivos de registro de transacciones nunca son parte de un grupo de archivos.

Grupos de archivos predefinidos

Una base de datos comprende un grupo de archivos primario y varios grupos de archivo definidos por el
usuario. El grupo de archivos que contiene el archivo primario es el grupo de archivos primario. Cuando una
base de datos se crea, el grupo de archivos primario contiene el archivo de datos primario y cualquier otro
archivo que no se pone en otro grupo de archivos. Todas las tablas del sistema se asignan en el grupo de
archivos primario. Si el grupo de archivos primario se queda sin espacio, ninguna información nueva del
catálogo puede agregarse a las tablas del sistema. El grupo de archivos primario sólo se llenará si la bandera
de configuración "autogrow" está apagada o si todos los discos que están sosteniendo los archivos en el
grupo de archivos primario se quedaron sin espacio. Si sucede esto, se deberá encender la bandera de
configuración "autogrow" o mover archivos a un nuevo almacenamiento para liberar mas espacio.

Los grupos de archivos definidos por el usuario son cualquier grupo de archivos que son específicamente
creados por el usuario cuando él o ella están inicialmente creando o posteriormente alterando la base de
datos. Si un grupo de archivos definido por el usuario se llena, se afectarán sólo las tablas de los usuarios
específicamente asignadas a ese grupo de archivos.
En cualquier momento, un grupo de archivos puede ser designado como el grupo de archivos predefinido.
Cuando se crean objetos en la base de datos sin especificar a que grupo de archivos pertenecen, se asignan
al grupo de archivos predefinido. Los grupos de archivos predefinidos deben ser suficiente grandes para
almacenar cualquier objeto no asignado a un grupo de archivos definido por el usuario. Inicialmente, el grupo
de archivos primario es el grupo de archivos predefinido.
Los grupos de archivos predefinidos pueden ser cambiados usando la sentencia ALTER DATABASE. Cuando
usted cambia el grupo de archivos predefinido, cualquier objeto que no tiene un grupo de archivos
especificado se asigna a los archivos de los datos en el nuevo grupo de archivos predefinido cuando se crea.
La asignación para los objetos y tablas del sistema, sin embargo, se mantiene en el grupo de archivos
primario y no en el nuevo grupo de archivos predefinido.
Cambiar el grupo de archivos predefinido previene que objetos del usuario que no se crean específicamente
en un grupo de archivos definidos por el deban competir con los objetos y tablas del sistema para el espacio
de los datos.

Recomendaciones

Al implementar una base de datos, usted debe intentar adherir a las pautas siguientes para usar archivos y
grupos de archivos:
· La mayoría de las bases de datos trabajará bien con un solo archivo del datos y un solo archivo de registro
de transacciones.
· Si usted usa archivos múltiples, cree un segundo grupo de archivos para los archivos adicionales y
configúrelo como el grupo de archivos predefinido. De esta manera, el archivo primario contendrá sólo tablas
y objetos del sistema.
· Para maximizar rendimiento, usted puede crear archivos o grupos de archivos en tantos discos físicos
locales disponibles como sea posible, y ubicar grandes objetos que compiten por espacio en grupos de
archivos diferentes.
· Use grupos de archivos para habilitar la colocación de objetos en discos físicos específicos.
· Ubique las diferentes tablas que se usan para una misma consulta en grupos de archivos diferente. Este
procedimiento mejorará el rendimiento al tomar ventaja del procesamiento paralelo de input/output del disco
(I/O) al buscar datos vinculados.
· Ponga las tablas fuertemente accedidas y los índices no-agrupados que pertenecen a esas tablas en grupos
de archivos diferentes. Este procedimiento mejorará el rendimiento debido al I/O paralelo si los archivos se
localizan en discos físicos diferentes.
· No ponga el archivo de registro de transacciones en el mismo disco físico con los otros archivos y grupos de
archivos.

Registros de transacciones

Una base de datos en SQL Server 2000 tiene por lo menos un archivo de datos y un archivo de registro de
transacciones. Los datos y la información del registro de transacciones nunca es mezclada en el mismo
archivo, y archivos individuales son sólo por una única base de datos.

El SQL Server usa el registro de transacciones de cada base de datos para recuperar transacciones. El
registro de transacciones es un registro serial de todas las modificaciones que han ocurrido en la base de
datos así como de las transacciones que realizaron dichas modificaciones. El archivo de registro de
transacciones graba el comienzo de cada transacción y archiva los cambios producidos en los datos. Este
registro tiene bastante información para deshacer las modificaciones (si es necesario) que hizo durante cada
transacción. Para algunas operaciones pesadas, como CREATE INDEX, el registro de transacciones registra,
en cambio, los hechos a los que la operación dio lugar. El registro crece continuamente tanto como
operaciones ocurran en la base de datos.
El registro de transacciones graba la asignación y liberación de las páginas y la grabación definitiva (commit)
o la vuelta atrás (rollback) de cada transacción. Este capacidad permite al SQL Server rehacer (Rollup) o
deshacer (Rollback) cada transacción de las siguientes maneras:
· Una transacción es rehecha cuando se aplica un registro de transacciones. El SQL Server copia la imagen
posterior a cada modificación de la base de datos o vuelve a ejecutar sentencias como CREATE INDEX. Estas
acciones se aplican en el mismo orden en la que ellas ocurrieron originalmente. Al final de este proceso, la
base de datos está en el mismo estado que estaba en el momento en que el registro de transacciones fue
copiado.
· Una transacción se deshace cuando una transacción queda incompleta por alguna causa. El SQL Server
copia la imagen previa de todas las modificaciones a la base de datos desde el BEGIN TRANSACTION. Si
encuentra archivos de registro de transacciones que indican que un CREATE INDEX fue ejecutado, realiza
operaciones que lógicamente invierten la sentencia. Éstos imágenes previas Ye inversiones del comando
CREATE INDEX son aplicados en orden inverso a la secuencia original.

A un punto de salvaguarda, el SQL Server asegura que se han grabado en el disco todos los archivos de
registro de transacciones y las páginas de la base de datos que se modificaron. Durante cada proceso de
recuperación de base de datos, que ocurre cuando el SQL Server se reinicia, una transacción necesita ser
rehecha sólo si no se conoce si todas las modificaciones de datos de la transacción fueron realmente
transferidas desde el caché de SQL Server al disco. Debido a que en un punto de salvaguarda se obliga a que
todas las páginas modificadas sean efectivamente grabadas en el disco, este representa el punto que se toma
como punto de inicio para el comienzo de las operaciones de recuperación. Dado que para todas las páginas
modificadas antes del punto de salvaguarda se garantiza que están en el disco, no hay ninguna necesidad de
rehacer algo que se hizo antes del punto de salvaguarda.

Las copias de respaldo del registro de transacciones le permiten a usted que recupere la base de datos al
momento de un punto específico (por ejemplo, previo a entrar en datos no deseados) o a un punto de falla.
Las copias de respaldo del registro de transacciones deben ser tenidas muy en cuenta dentro de su estrategia
de recuperación de bases de datos.

Ambiente

Generalmente, cuanto más grande es la base de datos, mayores son los requisitos de hardware. El diseño de
la base de datos siempre debe tomar en cuenta la velocidad del procesador, el tamaño de la memoria, y el
espacio del disco duro y su configuración. Hay otros factores determinantes, sin embargo: el número de
usuarios o sesiones coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la
base de datos. Por ejemplo, una base de datos que contiene datos de la biblioteca escolar con escasos
niveles de actualización generalmente tendrá requisitos de hardware más bajos que un almacén de datos de
un-terabyte que contiene ventas, productos, e informaciones de los clientes frecuentemente analizados, para
una gran corporación. Aparte de los requisitos de almacenamiento de disco, se necesitará más memoria y
procesadores más rápidos para levantar en memoria grandes volúmenes de datos del almacén de datos y
procesar mas rápidamente las consultas.

Estimar el Tamaño de una base de datos

Al diseñar una base de datos, usted podría necesitar estimar cuán grande será la base de datos cuando este
llena de información. Estimar el tamaño de la base de datos puede ayudarle a determinar la configuración del
hardware que usted necesitará para alcanzar los siguientes requisitos:
· Lograr el rendimiento requerido por sus aplicaciones
· Asegurar la cantidad física apropiada de espacio en disco para guardar los datos y índices

Estimar el tamaño de una base de datos también puede llevarlo a determinar si el diseño de la base de datos
necesita mayor refinamiento. Por ejemplo, usted podría determinar que el tamaño estimado de la base de
datos es demasiado grande para ser implementada en su organización y que requiere mayor normalización.
Recíprocamente, el tamaño estimado podría ser más pequeño que el esperado, permitiendo denormalizar en
cierto grado la base de datos para mejorar el rendimiento de las consultas.

Para estimar el tamaño de una base de datos, estime el tamaño de cada tabla individualmente y sume dichos
valores. El tamaño de una tabla depende si la tabla tiene o no índices y, en este caso, qué tipo de índices.

Diseño físico de la base de datos

El subsistema de entrada/salida (motor de almacenamiento) es un componente importante de cualquier base

de datos relacional. Una aplicación de base de datos exitosa normalmente requiere una planificación
cuidadosa en las fases tempranas de su proyecto. El motor de almacenamiento de una base de datos
relacional requiere de esta planificación que incluye a lo siguiente:
· Qué tipo de hardware de disco será utilizado
· Cómo distribuye sus datos en los discos
· Qué diseño de índices se va a utilizar para mejorar el rendimiento de las consultas.
· Cómo se van a configurar apropiadamente todos los parámetros de configuración para que la base de datos
funcione correctamente.

Instalación de SQL Server

Aunque la instalación de SQL Server está más allá del alcance de este Kit de Entrenamiento, usted siempre
debe tener en cuenta lo siguiente antes de realizar una instalación:
· Esté seguro que la computadora reúne los requisitos de sistema para SQL Server 2000.
· Haga copias de respaldo de su instalación actual de Microsoft SQL Server si usted está instalando SQL
Server 2000 en la misma computadora.
· Si usted está instalando un failover cluster, desactive el NetBIOS en todas las tarjetas de la red privada
antes de ejecutar el instalador de SQL Server.
· Repase todas las opciones de instalación de SQL Server y este preparado para hacer las selecciones
apropiadas cuando ejecute el instalador.
· Si usted está usando un sistema operativo que tiene configuraciones regionales diferentes a inglés (Estados
Unidos), o si usted está personalizando el juego de caracteres o la configuración del ordenamiento de los
caracteres, revise los temas referidos a la configuración de colecciones.
Antes de ejecutar el instalador de SQL Server 2000, cree uno o más cuentas de usuario del dominio si usted
está instalando SQL Server 2000 en una computadora con Windows NT o Windows 2000 y quiere que SQL
Server 2000 se comunique con otros clientes y servidores.

Usted debe iniciar el sistema operativo bajo una cuenta de usuario que tiene permisos locales de
administrador; por otra parte, usted debe asignar los permisos apropiados a la cuenta de usuario de dominio.
Esté seguro de cerrar todos los servicios dependientes sobre SQL Server (incluso cualquier servicio que usa
ODBC, como el Internet Information Server, o IIS). Además, cierre al Windows NT Event Viewer y a los
visualizadores de la registry (Regedit.exe o Regedt32.exe).

Seguridad

Una base de datos debe tener un sistema de seguridad sólido para controlar las actividades que pueden
realizarse y determinar qué información puede verse y cuál puede modificarse. Un sistema de seguridad
sólido asegura la protección de datos, sin tener en cuenta cómo los usuarios obtienen el acceso a la base de
datos.

Planificar la Seguridad

Un plan de seguridad identifica qué usuarios pueden ver qué datos y qué actividades pueden realizar en la
base de datos. Usted debe seguir siguientes los pasos para desarrollar un plan de seguridad:
· Liste todas los items y actividades en la base de datos que debe controlarse a través de la seguridad.
· Identifique los individuos y grupos en la compañía.
· Combine las dos listas para identificar qué usuarios pueden ver qué conjuntos de datos y qué actividades
pueden realizar sobre la base de datos.

Niveles de seguridad

Un usuario atraviesa dos fases de seguridad al trabajar en SQL Server: la autenticación y autorización
(aprobación de los permisos). La fase de la autenticación identifica al usuario que está usando una cuenta de
inicio de sesión y verifica sólo su capacidad para conectarse a un instancia de SQL Server. Si la autenticación
tiene éxito, el usuario se conecta a una instancia de SQL Server. El usuario necesita entonces permisos para
acceder a las bases de datos en el servidor, lo que se obtiene concediendo acceso a una cuenta en cada base
de datos (asociadas al inicio de sesión del usuario). La validación de los permisos permite controlar las
actividades que el usuario puede realizar en la base de datos SQL Server.

Modos de autenticación

El SQL Server puede operar en uno de dos modos de seguridad (autenticación): la Autenticación de Windows
y el modo Mixto. El modo de Autenticación de Windows le permite a un usuario que se conecte a través de
una cuenta de usuario Windows NT 4.0 o Windows 2000. El modo mixto (Autenticación de Windows y
Autenticación de SQL) le permite a los usuarios que conecten a una instancia de SQL Server usando
Autenticación de Windows o Autenticación de SQL Server. Los usuarios que se conectan a través de una
cuenta del usuario Windows NT 4.0 o Windows 2000 pueden hacer uso de conexiones de confianza en el
modo de Autenticación de Windows o en el modo mixto.

Resumen del tema

Al diseñar una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos
de la base de datos y grupos de archivos, registros de transacciones, la instalación del SQL Server y su
ambiente operativo, y la seguridad. Todos los datos y objetos de la base de datos, como tablas,
procedimientos almacenados, desencadenadores, y vistas, se guardan dentro de los archivos primario,
secundarios, dentro del registro de transacciones. Los grupos de archivos agrupan archivos para propósitos
administrativos y de ubicación de los datos. El grupo de archivos que contiene el archivo primario es el grupo
de archivos primario. Una base de datos en SQL Server 2000 tiene al menos un archivo de datos y un archivo
de registro de transacciones. Datos y la información del registro de transacciones nunca se mezclan en el
mismo archivo, y los archivos individuales son utilizados por solo una base de datos. El SQL Server usa el
registro de transacciones de cada base de datos para recuperar transacciones. El diseño de la base de datos
siempre debe tomar en consideración la velocidad de procesador, la memoria, y el espacio del disco duro y su
configuración. Hay otros factores determinantes, sin embargo: el número de usuarios o sesiones
coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la base de datos Al
diseñar una base de datos, usted podría necesitar estimar cuán grande será la base de datos cuando este
llena de información. Al instalar SQL Server, usted debe tener en cuenta varios problemas. Una base de
datos debe tener un sistema de seguridad sólido para controlar las actividades que pueden o no realizarse y
determinar qué información puede verse y cuál puede modificarse. Un diseño de seguridad identifica qué
usuarios pueden ver qué datos y qué actividades pueden realizar sobre la base de datos.

MODULO I

Tema 4: Identificar los requerimientos de diseño

Lo que aprenderá:

Al terminar este tema usted podrá:

· Identificar las metas y el alcance de un proyecto de base de datos.

· Identificar los tipos de datos que manejará la base de datos, la cantidad actual de datos, el crecimiento
esperado, y cómo se usan actualmente.
· Identificar cómo se usarán los datos en la nueva base de datos.
· Identificar cualquier regla comercial que se utilizará en el sistema.

El Proceso de Identificar los Requerimientos de diseño

El proceso de identificar los requerimientos del sistema incluye una variedad de pasos. El número de pasos
incluidos en este proceso, cómo estos pasos se definen, y la forma en que ellos se definen puede variar
grandemente de recurso a recurso (sin que un método sea necesariamente es el más correcto). Según el
propósito de este kit de entrenamiento, este proceso ha sido dividido en cuatro tareas primarias:
· Identificar la metas del sistema
· Identificar la cantidad y los tipos de datos
· Identificar cómo se usarán los datos
· Identificar las reglas comerciales

Usted necesariamente no tiene que realizar esta una tarea por vez. Por ejemplo, mientras identifica la
cantidad y los tipos de datos, usted podría determinar cómo se usarán los datos y qué restricciones deben
asociarse a dichos datos. La Figura 4.1 ilustra el proceso de identificar los requerimientos de diseño.
Figure 4.1 Identificar los requerimientos del sistema.

Identificar las Metas del Sistema

Diseñar una base de datos requiere de un entendiendo de las funciones comerciales que usted quiere
soportar. Tanto como sea posible, su diseño de la base de datos debe modelar el negocio con precisión. Es
significativamente costoso en tiempo tratar de cambiar el diseño de una base de datos una vez que se ha
implementado. Una base de datos bien diseñada obtiene el mayor rendimiento. Al diseñar una base de datos,
usted debe considerar el propósito de la base de datos y cómo este afecta el diseño. En otras palabras, usted
debe determinar las metas del nuevo sistema. ¿Por qué está creando usted esta base de datos?

Las metas del sistema son las razones por las qué usted está implementando la nueva base de datos. Para
crear un diseño de base de datos eficaz, usted debe tener conocimiento completo y profundo del trabajo que
se espera que la base de datos haga. Sin esta comprensión, usted no puede tomar decisiones informadas
sobre cómo la base de datos debe ser diseñada.

Determinar las metas del sistema no siempre es un proceso directo. La mayoría de los proyectos de
desarrollo de bases de datos tienen muchas metas (tangibles e intangibles), y intentar descubrirlos puede
tomar a menudo una cantidad importante de trabajo de investigación. Por ejemplo, una compañía industrial
podría decidir automatizar su proceso de administración de inventario. Uno de las metas declaradas de la
compañía para el proyecto es "para hacer mas fácil manejar el inventario."

Su trabajo es tomar esta meta intangible y intentar determinar la meta tangible subyacente. ¿Quiere la
compañía acelerar el proceso de administración del inventario? ¿Quiere rastrear inventario más con
precisión? ¿Quiere reducir costos? La meta intangible de "haciéndolo más fácil" podría incluir todos éstas
metas más tangibles y algunas otras.

Aunque estas metas son más tangibles, ellas todavía son vagas. Las metas vagas tienden a ser declaradas
términos generales, como "aumento de productividad" o "mejora del rendimiento" Cuando usted pasa por el
proceso de identificar metas, usted debe determinar el grado al que estas metas deben lograrse. Si la meta
es aumentar productividad, usted debe intentar determinar el grado en que esas metas deben lograrse.
Siempre que sea posible, sus metas deben ser directamente mensurables.

Usted debe ser consciente, sin embargo, de los peligros que se presentan al medir ciertas metas. A menudo
para determinar una meta mensurable, usted debe poder establecer una medida inicial. Por ejemplo, si una
meta de la base de datos de inventario es mejorar la exactitud, podría consumir muchos recursos estudiar
cuánta inexactitud existe en el proceso actual. Un estudio de esta clase podría abarcar años de historia del
inventario y quizás podría costar más que diseñar e implementar cabo la base de datos. En casos como
éstos, podría ser mejor hablar primero con gerentes y tenedores de libros para lograr un sentido general de
donde están los problemas y lo que puede hacerse para resolverlos. Al determinar que hasta que punto una
medida base debe ser estudiada, usted debe tener presente la balanza del proyecto y su aplicación práctica
manteniendo siempre un sentido de proporción.

A veces, las metas intangibles pueden ser difíciles de traducir en metas más tangibles. Esta situación es
particularmente cierta para metas que adoptan la jerga del mercadeo popular. Por ejemplo, la meta
declarada podría ser algo que no parece tener ningún significado o relevancia: "Nosotros queremos el nuevo
sistema para mostrar a nuestros clientes que estamos pensando de manera innovadora y siguiendo la
tendencia de ellos, para así mejorar el posicionamiento del producto." En estos casos, usted debe trabajar
estrechamente con la organización para definir eso claramente que significan las metas declaradas.

Después de que usted ha definido las metas iniciales para la nueva base de datos, usted puede continuar
determinando el tipo y la cantidad de datos que el sistema soportará. Sin embargo, cuando usted avance con
el proceso de diseño de la base de datos, deberá estar preparado para reevaluar estas metas. Cuando los
proyectos avanzan, la dirección cambia, los requerimientos comerciales cambian, y se revisan las
expectativas de la compañía. Como resultado, las metas evolucionan, lo cual significa que el diseño de la
base de datos podría necesitar ser modificado. Usted también podría descubrir, cuando usted excava más
profundamente en el proyecto, que algunas metas son inalcanzables o impropias. Dado que surgen nuevas
comprensiones y nueva información a ser administrada, usted debe prepararse a actuar de acuerdo con esto.

Identificar la Cantidad y Tipos de Datos

La cantidad y tipos de datos que su base de datos guardará pueden afectar el rendimiento de la base de
datos y debe tenerse en cuenta al crear su base de datos. La cantidad de datos, por supuesto, afecta el
tamaño de su base de datos, y los tipos de datos son un factor que determina los tipos de restricciones que
se incorporarán al diseño de la base de datos.

En muchos casos, determinar la cantidad y tipos de datos es un proceso directo porque un sistema antiguo
ya se encuentra funcionando y usted simplemente está actualizando o reemplazando ese sistema. En estas
situaciones, usted puede examinar el cuerpo de datos que ya existen.

En los casos en los que usted está llevando a cabo un nuevo sistema, o uno que radicalmente altera el
trabajo, su labor podría ser un poco más difícil porque podría tener que gastar una importante cantidad de
tiempo en determina qué tipos de datos se guardarán y cuánto datos habrá. Usted podría necesitar
entrevistar a los participantes importantes y coleccionar copias de documentos pertinentes y formas, como
facturas de venta, los listados de inventario, los informes de dirección, y cualquier otro documento que está
usándose actualmente.

Usted debe determinar el volumen de datos que el sistema manejará. Cuando examine el volumen de datos,
debe identificar la cantidad actual de datos y su modelo de crecimiento. Por ejemplo, un almacén podría
llevar sólo unos mil artículos actualmente, pero podría estar planeando agregar varios centenar al día durante
los próximos años para aumentar la artículos disponibles en el stock. Otro almacén podría llevar millones de
artículos pero podría planear agregar sólo unos nuevos artículos al día y nunca permitir que el inventario
vaya mucho más allá de su capacidad actual. Los modelos de crecimiento para estos dos sistemas son muy
diferentes, y como resultado, el diseño variará.

Al mirar los tipos de datos, usted está básicamente intentando conseguir un sentido general de las categorías
de información que usted estará guardando y qué detalles sobre las categorías son necesarios guardar. Este
proceso lo preparará por exponer las entidades y atributos que usted incorporará en su diseño de la base de
datos. Por ejemplo, si usted está desarrollando una base de datos para un minorista de la ropa, los tipos de
datos podrían incluir información sobre clientes que compran productos de la tienda. La información del
cliente podría incluir nombres, direcciones, números de teléfono, y incluso las preferencias de estilo.

A estas alturas en el proceso del diseño, usted no tiene que ponerse demasiado específico sobre cómo deben
categorizarse los datos o deben agruparse. Usted está intentando ganar un sentido general de los tipos de
datos involucrados y creando una lista centralizada para esos tipos de datos. Cuando usted empiece a
identificar realmente los objetos de la base de datos, usted tomará la información que recogió aquí y la usará
para desarrollar un modelo de datos.
Identificar Cómo se usarán los Datos

Cuando usted recoge los requerimientos del sistema, usted debe determinar cómo se usará la información en
su base de datos. El propósito de este paso es identificar quién estará usando los datos, el número de
usuarios que estarán accediendo a los datos, y las tareas que ellos estarán realizando cuando accedan ese
datos.

Al determinar quién estará usando los datos, usted debe pensar en términos de categorías de usuarios. Por
ejemplo, una categoría de usuarios podría ser el público general (quién accede a los datos a través del
Internet). Usted también podría tener otra categoría de usuarios que acceden datos a través del intranet de
la compañía. Algunas organizaciones podrían tener sólo un tipo de usuario, mientras otras organizaciones
podrían tener muchos tipos. No hay ningún mínimo fijo o número del máximo de usuarios que cada categoría
debe contener. Las únicas limitaciones son aquellas dictadas por configuraciones del hardware y diseño de la
base de datos. Una categoría podría contener a sólo un usuario, mientras otra categoría podría contener a
100.000 usuarios.

Cuando usted determina quién estará usando los datos, usted también debe identificar cuántos usuarios en
cada categoría estarán accediendo a los datos. Esta estimación no sólo debe incluir los números actuales
pero los valores proyectados, también. Además, usted tendrá que definir la concurrencia de los usuarios.
Usted debe saber que cuántas personas se conectarán a la vez a la base de datos y cuántos podría estar
intentando actualizar simultáneamente la base de datos.

Una vez que ha definido quiénes y cuántos son sus usuarios, usted debe identificar las tareas que ellos
estarán realizando cuando acceden a la base de datos. Por ejemplo, suponga que una compañía industrial
incluye una categoría de usuarios que toman órdenes de clientes. Este grupo de tomadores de ordenes deben
poder acceder y actualizar información del cliente. Además, deben poder ver los datos del inventario para
hacer los pedidos. La compañía también podría incluir una categoría de usuarios de recursos humanos. El
grupo de recursos humano debe poder ver y actualizar información del empleado. Identificando estas tareas,
usted puede determinar cómo será accedida la base de datos y cómo se verán y manipularán los datos.
Cuando usted combina esta información con el número y tipo de usuarios, usted podrá llevar a cabo un
diseño de la base de datos que satisface las necesidades de todos en la organización.

Identificar las Reglas Comerciales del Sistema

Al identificar las reglas comerciales, usted está determinando las restricciones que gobiernan cómo deben
manejarse y protegerse los datos y el sistema. Estas restricciones se refieren van más allá que la integridad
individual de los atributos de la entidad. Las reglas comerciales son mucho más amplias e incorporan todas
las restricciones del sistema, incluidas la integridad de los datos y la seguridad del sistema. En otras
palabras, usted está definiendo lo que cada categoría de usuarios puede o no puede hacer.

Volviendo al ejemplo de la compañía industrial, el grupo de tomadores de órdenes pueden acceder y

actualizar registros de los clientes y ver los datos de inventario. Sin embargo, usted podría determinar que
estos usuarios no deben poder actualizar datos del inventario y no deben poder ver datos de los empleados.
Usted también podría determinar que ningún archivo del cliente puede crearse sin que se complete la
dirección de envío y el número de teléfono. Otra restricción podría ser que cualquier artículo agregado a un
orden del cliente debe quitarse del inventario. Las reglas comerciales pueden incluir un amplio espectro de
restricciones, algunas que pertenecen en conjunto al sistema y otras que pertenecen a los tipos específicos
de datos.

Resumen del tema

Antes de que usted pueda desarrollar a un modelo del datos, usted debe identificar las metas de su proyecto
de base de datos, el tipo y cantidad de datos con los que usted estará trabajando, cómo se usarán esos
datos, y cualquier restricción comercial que deberá existir sobre los datos. Usted debe considerar el propósito
de la base de datos y cómo afecta el diseño. Usted debe tener una comprensión clara de por qué usted está
creando esta base de datos. Otra área de preocupación cuando se están identificando los requerimientos del
sistema es la cantidad y tipo de datos que su base de datos almacenará. Cualquier sea el sistema actual,
usted debe determinar el volumen de datos que el sistema manejará. Cuando examina el volumen de los
datos, usted debe determinar la cantidad real de datos y su modelo de crecimiento. Al mirar los tipos de
datos, usted está intentando conseguir un sentido general de las categorías de información que básicamente
se estarán guardando y qué detalles sobre las categorías son necesarios guardar. Cuando usted recoge
requerimientos del sistema, usted debe identificar quién estará usando los datos, el número de usuarios que
estarán accediendo a los datos, y las tareas que ellos estarán realizando sobre esos datos. Al identificar las
restricciones sobre los datos, usted estará determinando las reglas comerciales que gobiernan cómo deben
manejarse y protegerse los datos. Las reglas comerciales incluyen tanto la integridad de los datos así como la
seguridad del sistema. Ellos le permiten definir lo que cada categoría de usuarios puede y no puede hacer.

MODULO I

Tema 5: Desarrollar el Modelo Lógico de Datos

Lo que aprenderá:

Al terminar este tema usted podrá:

· Identificar entidades y sus atributos.
· Identificar relaciones entre las entidades.
· Definir restricciones en los datos.

Identificar Entidades y Sus Atributos

Cuando se recogen los requisitos del sistema para al diseño de la base de datos, uno de los pasos que se
realizan es el de definir los tipos de datos que contendrá la base de datos. Pueden separarse estos tipos de
datos en categorías que representan una división lógica de información. En la mayoría de los casos, cada
categoría de tipo de dato se traduce en un objeto tabla dentro de la base de datos. Hay normalmente, un
conjunto de objetos primarios, y después de que ellos son identificados, surgen los objetos relacionados.

Por ejemplo, en la base de datos Editores, uno de los objetos primarios es la tabla Titulos. Uno de los objetos
relacionado a la tabla Títulos es la tabla de RoyAgenda que proporciona información sobre la agenda de
royalties asociada con cada libro. Otro objeto es la tabla TituloAutor que vincula a los autores con los libros.

Usando las categorías de datos definidas en los requisitos del sistema, se puede empezar a crear un mapa
del objeto tabla dentro de la nueva base de datos. Por ejemplo, suponga que usted está diseñando una base
de datos para el sistema de reservaciones de un hotel. Durante el proceso de recolección de requisitos de
sistema, identifica varias categorías de datos, incluido los cuartos, huéspedes, y reservaciones. Como
resultado, agrega tablas a su diseño de la base de datos que representan a cada una de estas categorías,
como se muestra en la Figura 5.1.

Figura 5.1 Los objetos primarios en un diseño de la base de datos: la tabla Habitaciones, la tabla Reservas, y
la tabla Huespedes.

Al identificar las reglas comerciales para este sistema, usted determinó que el hotel tiene ocho tipos de
cuartos y que los huéspedes regulares prefieren un cierto tipo de cuarto. Como resultado, tanto la tabla
Habitaciones como la tabla Huespedes deberán incluir un atributo de tipo de cuarto. Usted decide crear una
tabla para los tipos del cuarto, como se muestra en Figura 5.2.
Figura 5.2 La base de datos de reservaciones del hotel que incluye la tabla de TipoHab.

Ahora, la tabla Habitaciones y la tabla Huespedes referencian a la tabla TipoHab sin tener que repetir una
descripción del cuarto para cada cuarto y cada huésped. Además, ante un cambio en los tipos de cuarto,
usted puede actualizar la información en un solo lugar, en lugar de tener que actualizar múltiples tablas y
archivos.

Antes de que usted pueda completar el proceso de definir objetos de la tabla dentro de la base de datos,
debe definir las relaciones entre las tablas. Siempre que identifique una relación muchos-a-muchos, tendrá
que agregar una tabla de unión. Se discuten relaciones con más detalle adelante en este tema.

Después de que usted ha definido todas las tablas que puede definir a estas alturas, puede definir las
columnas (atributos) para esas tablas. De nuevo, usted estará tomando esta información directamente de los
requisitos del sistema en los que identificó qué tipos de datos deben ser incluidos en cada categoría de
información.

Usando el ejemplo de base de datos del hotel, suponga que determinó durante el proceso de recolección de
requisitos del sistema que la categoría Huespedes debe incluir información la siguiente información sobre los
huéspedes: nombre, apellido, dirección, número de teléfono, y preferencias del cuarto. Como resultado,
usted planea agregar columnas a la tabla de los Huespedes para cada uno de estos tipos de información.
Usted también planea agregar un identificador único para cada huésped, tal como con cualquier entidad
normalizada. La Figura 5.3 muestra la tabla Huespedes con todas las columnas que contendrá la tabla.

Figura 5.3 La tabla Huespedes y sus atributos.

Identificar Relaciones Entre las Entidades

Después de que ha definido las tablas y sus columnas, usted debe definir las relaciones entre las tablas. A
través de este proceso, podría descubrir que necesita modificar el diseño que ha creado.
Empiece escogiendo una de las tablas primarias y seleccionando las entidades que tienen relaciones con esa
tabla. Siguiendo con el ejemplo del hotel, asuma que los requisitos del sistema indican que todas las
reservaciones deben incluir cuarto e información del huésped. Los cuartos, huéspedes, y reservaciones son
las categorías de datos. Como resultado, usted puede deducir que una relación existe entre los cuartos y
reservaciones y entre los huéspedes y reservaciones. La Figura 5.4 muestras las relaciones entre estos
objetos. Una línea que conecta las dos tablas significa una relación. Advierta que una relación también existe
entre la tabla Habitaciones y la tabla TipoHab y entre la tabla Huespedes y la tabla TipoHab.

Figura 5.4 Las relaciones que existen entre las tablas en la base de datos de las reservaciones del hotel.

Una vez que establece que una relación existe entre las tablas, usted debe definir el tipo de relación. En la
Figura 5.4, cada relación (línea) es marcada a cada extremo (donde conecta a una tabla) con el número 1 o
con un símbolo de infinito (8). El 1 se refiere al lado uno de una relación, y el símbolo de infinito se refiere al
lado muchos de una relación uno-a-muchos. Algunos autores también las llaman relaciones 1:N.

Para determinar los tipos de relaciones que existen entre las tablas, usted debe mirar los tipos de datos que
cada tabla contiene y los tipos de conexiones entre ellos. Por ejemplo, una relación existe entre la tabla
Huespedes y la tabla Reservas. La relación existe porque los huéspedes son parte de la información que se
recaba cuando se registra una reservación. Según las reglas comerciales, un huésped puede hacer una o más
reservaciones, pero cada reservación grabada puede incluir solo el nombre de un huésped, normalmente la
persona que está haciendo la reservación. Como resultado, una relación uno-a-muchos existe entre las dos
tablas: un huésped, una o muchas reservaciones.

Una relación también existe entre la tabla Reservas y la tabla Habitaciones. Según las reglas comerciales,
una reservación puede solicitar uno o más cuartos, y un cuarto puede ser incluido en una o más
reservaciones (en fechas diferentes). En este caso, existe una relación muchos-a-muchos: muchas
reservaciones a muchos cuartos. En un diseño de base de datos normalizado, sin embargo, relaciones
muchos-a-muchos deben ser modificadas agregando una tabla de unión y creando una relación uno-a-
muchos entre cada tabla original y la tabla de unión, como se muestra en la Figura 5.5.
Figura 5.5 La tabla de HabReservas como tabla de unión entre la tabla Habitaciones y la tabla Reservas.

Identificar Restricciones sobre los Datos

A estas alturas del proceso de diseño de la base de datos, usted debería tener definidas las entidades, sus
atributos, y las relaciones entre entidades. Ahora, usted debe identificar las restricciones sobre los datos que
se guardarán en las tablas. El mayor trabajo ya fue completado cuando usted identificó las reglas comerciales
al momento de recoger los requisitos del sistema. Como se vio, las reglas comerciales incluyen todo las
restricciones en un sistema, incluida la integridad de los datos y la seguridad del sistema. Para esta fase del
proceso de diseño, su enfoque se centrará en las restricciones sobre los datos. Usted tomará las reglas
comerciales relacionadas a los datos y las refinará y organizará. Debe intentar organizar las restricciones en
base a los objetos que creó en la base de datos, y formularlas de modo que se refieran a ellos.

Volviendo al diseño de la base de datos de la Figura 5.5, suponga que una de las reglas comerciales indica:
"Un registro de huésped puede, pero no es obligatorio, incluir una preferencia por uno de los tipos de cuarto
predefinidos pero no puede incluir ninguna otra preferencia de tipo de cuarto." Al definir las restricciones
sobre los datos, usted debe referenciar las tablas y columnas pertinentes y dividir la regla comercial de modo
que cada restricción esté contenida en una instrucción simple:
· La columna de TipoHabID en la tabla Huespedes no requiere un valor.
· Todo valor distinto de NULL en la columna de TipoHabID en la tabla Huespedes debe ser un valor incluido
en la columna de TipoHabID en la tabla de TipoHab.
· Una fila en la tabla de los Huespedes puede incluir sólo un valor en la columna de TipoHabID.

En cuanto sea posible, usted debe organizar las restricciones sobre los datos según las tablas y sus
columnas. En algunos casos, una restricción se aplica al conjunto de una tabla, a más de una tabla, a una
relación entre las tablas, o a la seguridad de los datos. En estos casos, intente organizar las restricciones de
modo que sea lógica y más pertinente al proyecto. La meta de identificar las restricciones sobre los datos es
tener un mapa claro del camino para cuando se creen los objetos de la base de datos y sus relaciones que
fuerce la integridad de los datos

MODULO I

Ejercicio 1: Identificar los Requerimientos de Diseño de la base de datos

En este ejercicio, usted repasará el siguiente caso. De la información descripta en el caso, usted identificará
los requerimientos del sistema para el diseño de la base de datos. Usted estará usando este caso y el
resultado de este ejercicio en ejercicios subsecuentes. El producto final será la base de datos que usted ha
diseñado y ha llevado a cabo en SQL Server. Dado usted necesita guardar el resultado de este ejercicio, sin
embargo, que usted podría querer copiarlo en un archivo de su procesador de palabras o archivo de texto.

NOTA
Al diseñar un sistema de la base de datos relacional, sus especificaciones del diseño incluyen a menudo las
aplicaciones que son necesarias para acceder a los datos. Para los propósitos de este kit de entrenamiento,
sin embargo, los ejercicios se enfocarán en diseñar y llevar a cabo sólo el componente de la base de datos
del sistema entero.

Caso de una librería

El gerente de una librería pequeña le ha pedido diseñar y llevar a cabo una base de datos que centraliza
información para que sea más fácil y más eficaz de manejar el inventario, las órdenes de pedido y las ventas.
La tienda maneja libros raros y agotados y tiende a llevar sólo unos mil títulos en cualquier momento.
Actualmente, el gerente registra todas las ventas y el inventario en papel. Para cada libro, el gerente escribe
el título, autor, editor, la fecha de la publicación, edición, costo, precio minorista sugerido, y una valoración
que indica el estado del libro. A cada libro se le asigna una de las siguientes valoraciones: extraordinario,
excelente, bueno, justo, pobre, o dañado. Al gerente le gustaría poder agregar una descripción a cada
valoración (sólo un par de frases), pero la descripción no debe ser obligatoria. La información sobre cada
libro debe incluir el título, autor, costo, precio minorista sugerido, y valoración. El editor, fecha de la
publicación, y edición no siempre están disponibles. Si el año en que un libro fue publicado está disponible, el
año nunca será anterior al 1600. Y para los propósitos del nuevo sistema de la base de datos, la fecha de la
publicación se nunca caerá después del año 2099.

Dado que estos libros son raros, cada título debe registrarse individualmente, aún si son el mismo libro (título
idéntico, autor, editor, fecha de la publicación, y edición). Actualmente, el gerente asigna un único ID a cada
libro para que puedan diferenciarse títulos idénticos. Este ID debe ser incluido con la información del libro. El
ID de libro asignado por el gerente es un ID de ocho caracteres compuestos de números y letras.

El gerente también mantiene información limitada sobre cada autor de los libros que han pasado por la
tienda. La tienda podría tener más de un libro por autor, y a veces un libro a sido escrito por de un autor. El
gerente mantiene información actualmente de aproximadamente 2500 autores. La información incluye el
nombre del autor, el apellido, año de nacimiento, y año de muerte (si es aplicable). La información debe
incluir como mínimo el apellido del autor. Al gerente le gustaría incluir una descripción breve de cada autor,
cuando la dispone, cuando un autor se agrega a la lista. La descripción normalmente no excederá a una o
dos frases.

La librería tiene 12 empleados (incluidos el gerente y su asistente). El gerente espera contratar a un

empleado adicional todos los años durante los próximos años. El gerente y su asistente deben poder acceder
y modificar información sobre cada empleado. La información del empleado debe incluir el nombre, el
apellido, dirección, el número de teléfono, fecha de nacimiento, fecha de ingreso, y cargo en la tienda. Los
cargos incluyen a Gerente, Asistente de Gerente, Empleado de Ventas Full Time Lleno, y Empleado de Ventas
Part Time. El gerente podría querer en algún momento agregar un nuevo cargo a la lista o cambiar uno que
existe y le gustaría en el futuro agregar una descripción breve de los deberes del trabajo a cada cargo (por lo
menos, a algunos de los cargos). Un empleado puede tener sólo un cargo en un momento dado. Ningún
empleado, fuera de los dos gerentes, debe tener acceso a la información del empleado. Al gerente le gusta
también registrar cuántos y qué libros está vendiendo cada empleado.

La librería mantiene información actualmente sobre los clientes. Para cada cliente, la información incluye el
nombre del cliente, apellido, número de teléfono, dirección de correo de envío, libros que el cliente ha
comprado, y fecha de la compra. Dado que a algunos clientes no les gusta repartir información personal, sólo
el nombre o el apellido son obligatorios. El gerente tiene actualmente una lista de aproximadamente 2000
clientes. No todos los clientes que son incluidos en la lista han comprado libros, aunque la mayoría sí.

El gerente mantiene un registro de ventas de cada pedido con datos sobre la fecha del pedido y la fecha de
cuando se completó la venta. En algunos casos, como con los clientes sin pedido previo, estos dos eventos
ocurren concurrentemente. Cada orden debe incluir información sobre el libro vendido, el cliente que compró,
el vendedor que vendió, la cantidad de la venta, y la fecha de la orden. La orden también debe incluir la
fecha en que el libro debe ser entregado o retirado. Una orden se completa cuando el libro se ha pagado y es
retirado de la tienda o enviado al cliente. Un libro no puede sacarse de la tienda o puede enviarse a menos
que se haya pagado. Cada orden incluye el método del pago y el estado de la orden. Los métodos del pago
incluyen dinero en efectivo, cheque, y tarjetas del crédito. Los estados de una orden pueden ser uno de los
siguientes: (1) para ser enviado, (2) a ser retirado por el cliente, (3) enviado, o (4) retirado. Una orden
puede tener sólo un cliente, vendedor, fecha del orden, fecha de la entrega, método de pago, y estado del
orden; sin embargo, una orden puede contener uno o más libros.

Actualmente, se generan órdenes, se rastrean, y se modifican en formas de orden en papel. Las formas se
usan para asegurarse que los órdenes se envían (si es aplicable) y para mantener un registro de ventas.
Siempre que un libro se agrega a una orden, es eliminado de la lista del inventario. Este proceso ha sido muy
tedioso y no siempre eficaz. Esta situación también puede llevar a confusión y errores. Al gerente le gustaría,
que los libros vendidos permanecieran en la lista de libros pero marcados para mostrar de algún modo que el
libro se ha vendido.
La tienda vende aproximadamente 20 libros al día. La tienda está abierta cinco a la semana por
aproximadamente 10 horas por día. Hay uno a dos vendedores que trabajan al mismo tiempo, y hay dos
contadores de ventas donde las personas retiran y pagan por los libros y donde se procesan las órdenes de
los vendedores. Siempre está en la tienda al menos uno de los dos gerentes.

El gerente espera que las ventas aumenten aproximadamente un 10 por ciento al año. Como resultado, el
número de libros disponible, autores, y clientes deberán todos aumentar en la misma proporción.

Para servir a los clientes eficazmente, cada empleado debe poder acceder a una fuente centralizada de
información sobre los autores, libros, clientes, y órdenes. Actualmente, los empleados acceden a esta
información a través de las tarjetas del índice y de listas. A menudo, estas listas no están actualizadas, y
tienen errores. Además, cada empleado debe poder crear, rastrear, y modificar un pedido online, en lugar de
tener que mantener las formas de orden en papel. Sin embargo, sólo los gerentes deben poder modificar
información sobre los autores, libros, y clientes.

Para identificar metas del sistema

1. Repase el caso. No intente memorizar todos los detalles; en cambio, intente conseguir un sentido general
de lo que el proyecto está intentando lograr.
2. Apunte las metas del sistema que usted puede identificar en el caso.
¿Cuáles son esas metas?
3. Repase cada meta para determinar si es mensurable.
¿Qué metas son mensurables?

Para identificar la cantidad y tipo de datos

1. Apunte las categorías de datos que usted puede identificar en este caso.
¿Qué categorías de datos puede identificar?

2. Para cada categoría de datos que identificó en el Paso 1, apunte el tipo de información que usted debe
registrar para cada categoría.
¿Qué tipo de información puede identificar?

3. Para cada categoría de datos que identificó en el Paso 1, apunte la cantidad actual de datos por categoría.
¿Cuál es el volumen de datos para cada categoría?

4. Para cada categoría de datos que identificó en el Paso 1, apunte el modelo de crecimiento esperado.
¿Cuál es el modelo de crecimiento para cada categoría?

Para identificar cómo se usarán los datos

1. Apunte las categorías de usuarios que puede identificar en este caso.
¿Cuáles son esas categorías de usuarios?
2. Para cada categoría de usuario que identificó en el Paso 1, apunte el número de usuarios.
¿Cuál es el número actual de usuarios y el número proyectado de usuarios en cada categoría?

3. Para cada categoría de usuario que identificó en el Paso 1, apunte las tareas que ellos realizan.
¿Qué tareas realizará cada tipo de usuario?

Para identificar reglas comerciales

1. Apunte las reglas comerciales que usted puede identificar en este caso.
¿Cuáles son las reglas comerciales?

MODULO I

Ejercicio 2: Desarrolle un Modelo Lógico de Datos

En este ejercicio, usted se entrenará en los pasos necesarios para crear un modelo lógico de datos. Este
ejercicio involucra dibujar las tablas, entidades, y relaciones entre entidades que constituyen la base de
datos. Aunque usted puede usar un programa del dibujo como Visio para crear estos objetos; papel y un
lápiz es todo que usted realmente necesita. Si lo desea, usted puede transferir luego su modelo a un
programa del dibujo. Además, usted necesitará papel y un lápiz para escribir las restricciones a los datos.
También puede escribirlos directamente en un documento de un procesador de palabras. Cualquiera que sea
el método que usted escoja, deberá guardar el resultado para los ejercicios subsecuentes. Para realizar este
ejercicio, usted usará el caso de la tienda de libros de Ejercicio 1 del Tema 4 de este módulo.

Para identificar qué tablas agregar a una base de datos

1. Refiérase a los requisitos de diseño que usted desarrolló para el caso de la tienda de libros y apunte las
categorías de datos.
Cada categoría representa uno de los objetos tabla primarios en su diseño de la base de datos.

2. Dibuje una tabla para cada categoría de datos. Las tablas deben ser lo suficientemente grandes para que
usted pueda agregar los nombres de las columnas. Ponga las tablas en un modo que le permita dibujar las
relaciones entre las tablas. Usted agregará los nombres de la columna y definirá las relaciones mas adelante
en este ejercicio. Su dibujo debería incluir cinco tablas.

3. Etiquete cada tabla con el nombre de cada una de las categorías. Para consistencia, use las etiquetas
siguientes para los nombres de las tablas: Libros, Autores, Empleados, Clientes, y Ordenes.

Su próximo paso será identificar cualquier tabla relacionada. A estas alturas, diseñar una base de datos se
pone un poco más complicado. Una buena fuente para determinar las relaciones entre tablas es la lista de
reglas comerciales que usted identificó cuando usted recogió los requisitos de diseño. Esencialmente, usted
está buscando subcategorías de información o reglas de negocio que lo llevan a creer que son necesarias
tablas adicionales. Recuerde, usted puede modificar el diseño de la base de datos cuando usted identifica
relaciones entre tablas y restricciones sobre los datos.

4. Refiérase a las reglas comerciales en los requisitos de diseño. Fíjese que hay cuatro subcategorías de
información: la condición de un libro, la posición del empleado, la forma de pago, y el estado de la orden.

5. Dibuje las cuatro tablas relacionadas para soportar las tablas primarias.
Para consistencia, use los nombres siguientes para sus nuevas tablas: EstadoOrden, FormaDePago,
Posiciones, y CondicionLibro.

6. Refiérase a las reglas comerciales en los requisitos de diseño. Fíjese que una orden puede contener más
de un libro.
7. Agregue una tabla más (OrdenLibros) para rastrear los libros pedidos y las órdenes tomadas a los clientes.

Usted ahora debería tener 10 tablas.

Para identificar qué columnas agregar a las tablas

1. Refiérase a los requisitos de diseño que usted desarrolló para el caso de la tienda de libro.
Para cada categoría de datos, usted definió qué información debe ser incluida en cada categoría. Esta
información constituye sus columnas.

2. Agregue nombres a las columnas de cada tabla. También recuerde que cada fila en una tabla debe ser
singularmente identificable, por lo que algunas tablas podrían necesitar un identificador.

Además, en donde los nombres de las columnas se refirieran a información en una tabla relacionada, usted
normalmente sólo necesitará la columna del identificador de la tabla relacionada. Por ejemplo, la tabla
Ordenes incluiría una columna de EstadoID que la referencia a la tabla de EstadoOrden.

Para consistencia, use las etiquetas siguientes para los nombres de las columnas:

Tabla Columnas
Libros LibroID, Titulo, AutorID, Editor, FechaEd, Costo, CondicioID, Vendido
LibrosEstado CondicionID, NombreCond, Descripcion
Autores AutorID, Apellido, Nombre, AñoNac, AñoMuerte, Descripcion
Empleados EmpleadosID, Nombre, Apellido, Dir1, Dir2, Ciudad, Estado, CP, FechaIng, PosicionID
Posiciones PosicionID, Cargo, Descripcion
Clientes ClienteID, Nombre, Apellido, Telefono, Dir1, Dir2, Ciudad, Estado, CP
Ordenes OrdenID, ClienteID, EmpleadoID, Monto, FechaOrden, FechaEnvio, PagoID, EstadoID
EstadoOrden EstadoID, EstadoDescrip
FormaDePago PagoID, PagoDescrip
LibrosOrdenes OrdenID, LibroID

Fíjese que la tabla Clientes no incluye una columna para los libros comprados y fecha de compra. Dado que
cada cliente puede comprar más de un libro, usted no incluirá esta información aquí. Usted podría crear una
tabla para guardar esta información, pero sería innecesario porque reproduciría información que ya existe en
la base de datos (información que puede derivarse a través de vistas o consultas).

Para identificar relaciones entre las entidades

1. Determine qué relaciones existen entre la tabla Libros y otras tablas en la base de datos. Si necesita,
refiérase al caso de la tienda de libro y a los requisitos de diseño que lo ayudarán a determinar qué
relaciones existen entre los objetos.

Usted está buscando relaciones directas. Por ejemplo, la tabla Libros tiene una relación directa con la tabla
LibrosEstado. Los datos de LibrosEstado aplica directamente a los datos de Libros. Además, los datos de
Autores se relacionan directamente con los datos de Libros (los autores escriben libros). Hay también una
relación directa entre los datos de Libros y los datos LibrosOrdenes (los órdenes incluyen los libros que se
venden).

Fíjese, que no hay ninguna relación directa entre las tablas Libros y la tabla Ordenes. La relación entre las
dos tablas es indirecta y se expresa a través de la tabla de LibrosOrdenes.

2. Para cada tabla, trace una línea desde esa tabla a cualquier otra tabla con la que exista una relación.
Usted podría encontrar que necesita mover algunas de sus tablas para mostrar esas relaciones más
claramente.
Su diseño de la base de datos debe parecer similar al esquema en Figura 5.6.

Figura 5.6 Identificar las relaciones entre las tablas en el modelo de lógico datos.

3. Determine si cada relación es uno-a-uno, uno-a-muchos, o muchos-a-muchos. Escriba el número 1 en el

extremo "uno" de la relación, y escriba el símbolo infinito (8) en el extremo "muchos" de la relación.

Para determinar el tipo de relación, piense en los términos de los datos asociados con cada objeto. Por
ejemplo, existe una relación entre los empleados y los órdenes que ellos generan. Un empleado puede crear
muchos órdenes, pero una orden es creada por sólo un empleado. Por consiguiente, una relación uno-a-
muchos existe entre la tabla Ordenes y la tabla Empleados (un empleado puede crear muchas órdenes). La
tabla Empleados está en el lado "uno" de la relación, y la tabla Ordenes en el lado "muchos".

Su base de datos debe parecer similar ahora al esquema en Figura 5.7.

Figura 5.7 Identificar los tipos de relaciones entre las tablas en el modelo de los datos lógico.

4. Identifique las relaciones muchos-a-muchas en el diseño de la base de datos.

¿Qué relaciones son muchos-a-muchos?

5. Cree que una tabla de la unión llamada LibrosAutores. La tabla debe incluir la columna de AutorID y la
columna de LibroID.

6. Anule la relación entre la tabla Libros y la tabla Autores, entonces anule la columna de AutorID en la tabla
Libros.

Usted está anulando la relación entre las dos tablas porque una relación directa ya no existe. En cambio, una
relación indirecta se crea a través de la tabla de LibrosAutores. Además, la columna AutorID no es mas un
requisito en la tabla Libros porque la relación libro/autor se expresa en la tabla LibrosAutores.

7. Dibuje la relación entre los Autores y tablas LibrosAutores y la relación entre los Libros y tablas
LibrosAutores.

8. Determine los tipos de relaciones que existen con la tabla LibrosAutores.

Su diseño de la base de datos debe parecer similar ahora al esquema en Figura 5.8.

Figura 5.8 Agregar la tabla de LibrosAutores al modelo de datos lógico.

Para identificar restricciones en los datos

1. En una hoja de papel, apunte los nombres de cada tabla en su diseño de base de datos. Deje espacio
suficiente entre cada nombre de la tabla para escribir las restricciones de los datos.

2. Repase la regla comercial que declara que información del libro se debe incluir: título, autor, costo, precio
sugerido, evaluación, y ID único.

3. Identifique el objeto al que esta regla de negocio se aplica.

¿A qué objecto/s aplica esta regla de negocio?

4. Bajo los nombre de la tabla Libros y de la tabla LibrosAutores, escriba las restricciones a los datos que se
pueden derivar de la regla comercial.

¿Cuáles son las restricciones a los datos?

5. Para cada regla comercial, defina las restricción a los datos. Donde sea aplicable, escriba las restricciones
bajo el nombre de la tabla. Si una restricción no es aplicable específicamente a una tabla, escríbalo en otro
espacio en su papel.

¿Cuáles son las restricciones a los datos para su diseño de la base de datos?

6. Repase las restricciones a los datos que usted creó para asegurarse que cada tabla y cada columna dentro
de esas tablas tienen alguna clase de regla asociada con él.

MODULO II: Implementar una base de datos y sus tablas

Tema 1: Crear y administrar una base de datos SQLServer

El primer paso para implementar físicamente una base de datos es crear los objetos de la base de datos.
Usando la información que obtuvo cuando se determinaron los requerimientos de diseño, y los detalles que
identificó en el diseño lógico de la base de datos, Ud. puede crear los objetos de la base de datos y definir
sus características. Podrá modificar estas características después que haya creado los objetos de la base de
datos.

Cuando cree una base de datos, deberá primero definir su nombre, su tamaño, y los archivos y grupos de
archivos usados para soportarla. Deberá considerar varios factores antes de crear la base de datos:

 Por defecto solo tienen permiso para crear bases de datos los miembros de los roles “sysadmin” y
“dbcreator”, Ud. podría no tener asignados ninguno de dichos roles pero aún contar con la
autorización para crear bases de datos en caso que el administrador se los hubiera otorgado.

 El usuario que crea una base de datos se convierte en el dueño de la base de datos

 Un máximo de 32.767 bases de datos pueden ser creadas sobre un servidor.

 El nombre de la base de datos debe seguir las reglas de los identificadores.

Como ya indicamos, se usan tres tipos de archivos para almacenar una base de datos: archivos primarios,
que contienen la información de arranque para la base de datos; archivos secundarios, que hospedan a todos
los datos que no caben en el archivo primario; y registro de transacciones, que contienen la información de la
transacciones, usadas para recuperar la base de datos. Toda base de datos tiene al menos dos archivos: un
archivo primario y un registro de transacciones.

Cuando se crea una base de datos, los archivos se llenan de ceros para sobrescribir cualquier otro dato que
archivos que han sido borrados puedan haber dejado en el disco. Aunque esto significa que los archivos
pueden tardar en ser creados, esta acción evita al sistema operativo tener que llenar con cero los archivos al
momento de la efectiva grabación de los datos durante la normal operación de la base de datos, mejorando
la performance operacional de cada día.

Cuando Ud. crea una base de datos, deberá especificar el tamaño máximo que un archivo tiene autorizado a
alcanzar. Esto previene que el archivo crezca, cuando los datos son ingresados, hasta que el espacio en disco
se termine.

SQLServer implementa una nueva base de datos en dos pasos:

 SQLServer usa una copia de la base de datos “Model” para inicializar la nueva base de datos y sus
metadatos.
  SQLServer luego llena el resto de la base de datos con páginas vacías (excepto aquellas páginas que
tienen grabados datos internos como el espacio usado)

Cualquier objeto definido por el usuario en la base de datos “Model” es copiado a todas las bases de datos
que sean creadas. Se pueden agregar objetos a la base de datos “Model”, tales como tablas, vistas,
procedimientos almacenados, tipos de datos, etc. que serán incluidos en las nuevas bases de datos. Además,
cada nueva base de datos hereda la configuración de la opciones de la base de datos “Model”.

Métodos para crear una base de datos SQLServer

SQLServer provee muchos métodos que se pueden utilizar para crear bases de datos: el comando Transact-
SQL CREATE DATABASE, el árbol de la consola del Enterprise Manager, y el asistente Create Database , al
cual puede acceder a través del SQL Server Enterprise Manager.

El comando CREATE DATABASE

Se puede usar el comando CREATE DATABASE para crear una base de datos y los archivos almacenados en
una base de datos. El comando CREATE DATABASE le permitirá especificar una serie de parámetros que
definirán las características de la base de datos.

Por ejemplo, se puede especificar el máximo tamaño que puede alcanzar un archivo o el incremento que
puede experimentar dicho archivo. Si sólo utiliza CREATE DATABASE nombre_de_la_base_de_datos la base
de datos es creada del mismo tamaño de la base de datos “Model”.

El comando puede ser ejecutado desde el SQL Query Analizer. El siguiente ejemplo crea una base de datos
llamadas “Productos” y especifica que se usará un solo archivo.

El archivo especificado será el archivo primario, y un archivo de registro de 1Mb se crea automáticamente.
Dado que ni megabytes (Mb) ni kilobytes (Kb) son especificados en el parámetro SIZE para el archivo
primario, el archivo será generado en megabytes. Además, al no consignarse una especificación de archivo
para para el archivo de transacciones, el archivo de transacciones no tendrá un tamaño máximo (MAXSIZE) y
podrá crecer hasta ocupar todo el espacio en el disco.

USE master
GO
CREATE DATABASE Productos
ON
(
NAME = prods.dat,
FILENAME = ‘c:\program files\Microsoft SQL server\mssql\data\prods.mdf’,
SIZE = 4,
MAXSIZE = 10,
FILEGROWTH = 1
)
GO

Usar el Enterprise Manager

Se puede crear una base de datos directamente utilizando la herramienta SQL Server Enterprise Manager.
Para crear una base de datos en el Enterprise Manager, expanda la consola del árbol de su servidor, haga clic
derecho en el nodo Database, y haga clic en New Database. Cuando el cuadro de propiedades aparezca,
modifique los valores por defecto como sea necesario en orden a crear la nueva base de datos.

La figura muestra el cuadro de diálogo Database Properties cuando este se abre por primera vez.

El asistente Create Database

El asistente Create Database lo lleva a través de una serie de pasos necesarios para para crear una nueva
base de datos. Se accede al asistente seleccionando Wizards desde el menú Tools. Desde allí se deberán
completar los pasos que presenta el asistente. En la Figura se muestran varias opciones que pueden ser
modificadas cuando se ejecuta el asistente.

Figura 1: La pestaña General del cuadro de diálogo Database Properties para una nueva base de datos

Administrar una base de datos SQL Server

Una vez que se ha creado la nueva base de datos, Ud. podrá ver información acerca de dicha base de datos,
modificar sus características o eliminar la base de datos.

Ver información referida a la base de datos

Se puede ver la definición de la base de datos y sus opciones de configuración en casos de problemas de
funcionamiento o cuando se considere necesario realizar cambios en la base de datos. SQL Server provee
diferentes métodos que se pueden utilizar para ver información acerca de la base de datos: el procedimiento
almacenado sp_helpdb, la sentencia DATABASEPROPERTYEX, mediante el uso del SQL Server Enterprise
Manager.

Borrar una base de datos SQL Server

Se puede eliminar una base de datos SQL Server cuando esta no será necesaria o cuando es movida a otra
base de datos o a otro servidor. Cuando una base de datos es eliminada, esto se produce de manera
permanente y no puede ser recuperada sin usar un resguardo (backup) previo. Las bases de datos de
sistema (Model, MSdb, Master y Tempdb) no pueden ser eliminadas.

La base de datos Master debería ser resguardada después que se elimina una base de datos, porque el borrar
una base de datos actualiza las tablas del sistema en la base de datos Master. Si la base Master necesita ser
recuperada, cualquier base de datos que ha sido eliminada desde el último resguardo que se hizo, estaría aún
siendo referenciada y podría generar mensajes de error.

Una base de datos puede ser eliminada utilizando el comando DROP DATABASE o ser borrada desde la
consola del árbol en el SQL Server Enterprise Manager.

MODULO II: Implementar una base de datos y sus tablas

Tema 2: Identificar Tipos de Datos

Una vez que se ha creado una base de datos, se crearán las tablas que guardarán los datos dentro de la base
de datos.

Para crear estas tablas, sin embargo, se deben definir previamente los tipos de datos que serán definidos
para cada columna. Un tipo de dato es un atributo que especifica como serán los datos que pueden ser
almacenados en una columna, parámetro, o variable.

SQL Server provee de un conjunto de tipos de datos predefinidos. Además, se pueden crear tipos de datos
definidos por el usuario, este punto intentará explicar como identificar que tipos de datos se deben emplear
cuando se define una columna.

Tipos de datos provistos por el sistema

En SQL Server cada columna tiene un tipo de dato definido, el cual es un atributo que especifica como serán
los datos que pueden guardarse en esa columna (números enteros, caracteres, valores monetarios, fechas,
etc.). Otras objetos, además de las columnas, tienen también asociados tipos de datos, los objetos que
tienen asociados tipos de datos son:

 Columnas en tablas y vistas

 Parámetros de procedimientos almacenados

 Variables

 Funciones Transact-SQL que retornan uno o mas valores de un tipo específico de dato.

 Procedimientos almacenados que tienen un código return (el cual siempre es un valor entero)

Asignar tipos de datos a cada columna es uno de los primeros pasos que se dan en el diseño de una base de
datos. SQL Server provee un conjunto de tipos de datos predefinidos por el sistema. Los tipos de datos se
pueden utilizar para asegurar la integridad de los datos, dado que un dato para ser grabado o modificado
deberá ajustarse al tipo de dato especificado para la columna a la que pertenece, según fue establecido en
comando original CREATE TABLE. Por ejemplo, no se puede grabar el apellido de alguien en una columna
definida como tipo de dato fecha y hora (datetime), dado que esta columna solo aceptará datos de fechas y
horas.

El asignar un tipo de dato a un objeto define cuatro atributos del objeto:

 El tipo de dato contenido por el objeto. Por ejemplo, el dato podría ser carácter, entero o binario.

 La longitud o el tamaño del valor almacenado. Las longitudes de los tipos image (imágenes), binary
(binarios) y varbinary ( binarios de longitud variable) son definidos en bytes. La longitud de cualquiera
de los tipos numéricos de datos es el número de bytes necesarios para representar el número de
 dígitos máximo permitido para ese tipo de dato. Las longitudes para los tipos de datos string (cadena
de caracteres) y Unicode son definidos en caracteres.

 La precisión de los números (solamente tipos de datos numéricos). La precisión es la cantidad de

dígitos que el número puede tener. Por ejemplo un objeto smallint (entero pequeño) puede tener un
máximo de cinco dígitos, por lo que tiene una precisión de cinco.

 La escala de un número (solamente tipos de datos numéricos). La escala de un número es la cantidad

de dígitos que puede tener a la derecha de la coma decimal. Por ejemplo, un objeto int (entero) no
puede aceptar dígitos decimales, por lo que su escala es de cero. Un valor monetario puede tener un
máximo de cuatro dígitos decimales y su escala es de cuatro.

La tabla siguiente provee la descripción de las categorías de tipos de datos que SQL Server soporta y las
descripciones de los tipos de datos base que cada categoría contiene:

Categoría Descripción
Un dato Binary almacena cadenas de
bits. El dato consiste de números
Binary hexadecimales. Por ejemplo, el
número decimal 245 vale en
hexadecimal F5.
Los datos Character consisten de
cualquier combinación de letras,
símbolos, y caracteres numéricos. Por
Character
ejemplo, datos character
válidos:"John928" "(0*&(%B99nh
jkJ"
Los datos Date time consisten de
combinaciones de fechas o horas
Date time válidas. No existe tipos de datos
separados para fechas y horas para
almacenar solo fechas o solo horas
Los datos Decimal consisten de datos
Decimal numéricos que son almacenados al
menor dígito significativo
Datos numéricos aproximados que
Floating consisten de datos con una
point aproximación tanto como el sistema
de numeración binaria pueda ofrecer
Tipo de Dato
Descripción
Base
Los datos deben tener la misma longitud
binary
fija (hasta 8 KB)
Los datos pueden variar en el número de
varbinary
dígitos hexadecimales (hasta 8 KB)
Los datos pueden ser de longitud variable y
image
exceder los 8 KB.
Los datos deben tener la misma longitud
char
fija (hasta 8 KB)
Los datos pueden variar en el número de
varchar
caracteres (hasta 8 KB)
Los datos pueden ser cadena de caracteres
text
ASCII que excedan los 8 KB.
Los datos fecha están comprendidos entre
en el 1 de Enero de 1753 hasta el 31 de
datetime
diciembre de 9999 (requiere 8 bytes por
dato).
Los datos fecha están comprendidos entre
en el 1 de Enero de 1900 hasta el 31 de
smalldatetime
diciembre de 2079 (requiere 4 bytes por
dato).
Los datos pueden tener un máximo de 30
dígitos, que pueden estar todos a la
decimal derecha de la coma decimal. El tipo de dato
almacena un representación exacta del
número.
En SQL Server, el tipo de datos numeric es
numeric
equivalente al tipo de datos decimal.
float Desde –1.79E + 308 a 1.79E + 308.

Categoría Descripción
Los datos Integer consisten de
Integer números enteros positivos y negativos bigint
tales como: –15, 0, 5, y 2.509.
Monetary representa montos de
Monetary
dinero positivos o negativos
Special se utiliza para datos que
Special caben en ninguna de las categorís
anteriores.
Al usar tipo de datos Unicode, una
columna puede almacenar cualquier
cualquier caracter definido por el
estándar Unicode. Lo cual incluye a
Unicode todos los caracteres definidos en los nchar
distintos conjuntos de caracteres. Los
tipos de datos Unicode toman el doble
de espacio de almacenamiento que los
tipos no-Unicode.
Tipo de Dato
Descripción
Base
real Desde –3.40E + 38 a 3.40E + 38.
Desde –2^63 (–9223372036854775808) a
2^63–1 (9223372036854775807). Tamaño
8 bytes.
Desde –2.147.483.648 a 2.147.483.647
int
(requiere de 4 bytes por valor).
Desde –32,768 a 32.767 (requiere de 2
smallint
bytes por valor).
Desde cero a 255 (requiere de 1 bytes por
tinyint
valor).
Desde –922.337.203.685.477,5808 a
money +922.337.203.685.477,5807 Tamaño 8
bytes.
Desde –214.748,3648 a 214.748,3647
smallmoney
Tamaño 4 bytes.
Consisten en un 1 o un 0. Se usan para
bit representar valores lógicos VERDADERO o
FALSO, SI o NO
Este tipo de dato es usado para variables o
prámetros OUTPUT en procedimientos
almacenados que contenga una referencia
cursor
a un cursor. Cualquier variable creada con
el tipo de datos cursor puede tomar valor
nulo
Este tipo de datos es usado para indicar la
secuencia de la actividad del SQL Server
timestamp
sobre una fila y es representado por un
número incremental en formato binario.
Consiste de números hexadecimales de 16
byte, indicando un identificador único
uniqueidentifier global (GUID). Los GUID son usados
cuando una columna deba ser única frente
a cualquier otra columna.
Este tipo de datos soporta a cualquier otro
tipo de datos soportado por SQL Server
SQL_variant
excepto text, ntext, timestamp, image, y
sql_variant.
Es utilizado para almacenar un conjunto de
resultados para su posterior procesamiento.
El tipo de datos Table puede ser usado
table
únicamente para para definir variable
locales de tipo table o para retornar valores
de una función definida por el usuario.
Los datos deben tener la misma longitud
fija (hasta 4000 caracteres Unicode)
nvarchar Los datos pueden variar en el número de
 Tipo de Dato
Categoría Descripción Descripción
Base
caracteres (hasta 4000 caracteres Unicode)
Los datos pueden exceder los 4000
ntext
caracteres Unicode.

Todos los datos almacenados en el SQL Server deben ser compatibles con uno de estos tipos de datos base.
El tipo de dato cursor es el único tipo dedatos base que no puede ser asignado a una columna de una tabla.
Se puede usar este tipo de dato solamente para variables y para parámetros de procedimientos
almacenados.

Varios tipos de datos base tienen sinónimos (por ejemplo, rowversion es sinónimo de timestamp, y varying
es sinónimo de nvarchar).

Tipos de datos definidos por el usuario

Los tipos de datos definidos por el usuario están basados en tipos predefinidos por el sistema en SQL Server
2000.

Los tipos de datos definidos por el usuario pueden ser usados en varias tablas que deban guardar el mismo
tipo de dato en una columna y cuando se necesita asegurar que estas columnas tengan exactamente el
mismo tipo de dato, longitud y capacidad de aceptar nulos. Por ejemplo, un tipo de datos definido por el
usuario llamado codigo_postal podría ser creado en base al tipo char.

Cuando se crea un tipo de dato definido por el usuario, se deben proveer los siguientes parámetros:

 Nombre

 Tipo de datos del sistema sobre el que se basa el nuevo tipo de dato

 Anulabilidad (si el tipo de dato permite valores nulos).

Cuando la anulabilidad no es explícitamente definida, se toma por defecto la configuración de nulos ANSI
para la base de datos o conexión.

Si un tipo de datos definido por el usuario es creado en la base de datos Model el tipo de datos estará
disponible para todas las nuevas bases de datos que se creen. Si el tipo de datos es creado en una base de
datos definida por el usuario el tipo de datos sólo estará disponible para dicha base de datos.

Se pueden crear tipos de datos definidos por el usuario utilizando el procedimiento almacenado sp_addtype o
utilizando el Enterprise Manager.

MODULO II: Implementar una base de datos y sus tablas

Tema 3: Crear y administrar tablas.

Una vez que se ha creado la base de datos e identificado el tipo de datos, se está listo para crear los objetos
tabla que almacenaran los datos dentro de la base de datos. Cuando se crea una tabla, la definición de la
tabla deberá incluir, como mínimo, el nombre de la tabla, los nombres de las columnas, sus tipos de datos (y
longitudes, en caso de ser necesarios) y si las columnas aceptarán valores NULL. Se pueden configurar otras
propiedades posteriormente, aunque es aconsejable definir la mayor cantidad de propiedades al crear la tabla
para evitar problemas posteriores de mantenimiento. En este punto trataremos como crear tablas,
incluyendo como especificar la anulabilidad, generar valores para las columnas y definir valores por defecto
en las columnas. Además, se verá como obtener información acerca del objeto tabla, modificar las
características de las tablas, y eliminar tablas.

Crear tablas en una base de datos SQL-Server

Una tabla es una colección de datos acerca de una entidad específica, como un cliente, una orden de
compra, o un inventario. Una tabla contiene un conjunto de columnas. Cada columna representa un atributo
de la entidad. Por ejemplo, la fecha de una orden podría ser un atributo de la entidad orden. Cada instancia
de la entidad en la tabla es representada por un solo registro o fila (llamada también tupla).

En este punto del desarrollo de la base de datos se deberá contar con la información necesaria para crear las
tablas en la base de datos. Idealmente, se debería contar con toda la información acerca de las tablas,
incluyendo tanto las restricciones de clave primaria PRIMARY KEY como todas las otras restricciones. Primero
aprenderá a crear tablas básicas y posteriormente se verá como incorporar las restricciones

Determinar la anulabilidad de las columnas

La anulabilidad de una columna determina si las filas en la tabla pueden contener un valor nulo para esta
columna. Un valor nulo no es lo mismo que un cero, un blanco o una cadena de caracteres de longitud cero.
Nulo significa que ninguna entrada ha sido cargada para ese dato. La presencia de un valor nulo
generalmente implica que el valor o es desconocido o no esta definido. Por ejemplo, un valor nulo en la
columna Precio de la tabla Libros de la base Pubs no significa que no tenga precio, sino que este es
desconocido o no ha sido ingresado.

En general, se debe evitar permitir ingresar valores nulos porque ello provoca mayor complejidad en las
consultas y actualizaciones y porque estos no pueden ser usados con algunas opciones de configuración de
las columnas, como la restricción PRIMARY KEY. Comparaciones entre dos valores nulos, o entre un valor
nulo y cualquier otro valor, retornan un valor desconocido (unknow) porque el valor de cada NULL es
desconocido por definición. Valores nulos no pueden ser usados para información requerida para distinguir
una fila de otra fila en una tabla. Además, eliminar valores nulos cuando se están realizando operaciones de
cálculo puede ser importante porque ciertos cálculos (tales como promedios) pueden ser inexactos si existe
valores nulos dentro de los datos analizados. Si se necesita crear columnas donde algunos de cuyos valores
serán desconocidos se puede crear un valor por defecto que sea asignado en tales casos.

Por ejemplo, la columna Telefono en la tabla Autores de la base de datos Pubs no permite valores nulos. La
columna incluye un valor por defecto DESCONOCIDO para cuando no se tiene el dato. Si el valor para la
columna Telefono no es agregado en el comando de grabación del registro, el SQL automáticamente grabará
DESCON en dicha columna. Mas adelante se verá como definir valores por defecto para las columnas.

Si una fila es insertada pero sin valores para una columna que permite valores nulos, SQL Server provee un
valor nulo (sino existe un definición por defecto).

Una columna definida con la cláusula NULL también acepta una entrada explícita de NULL por parte del
usuario, sin importar cual sea el tipo de dato de la columna o si tiene un valor por defecto definido. El valor
NULL no debe ser expresado entre comillas porque será interpretado como una cadena de caracteres en vez
de un valor NULL.

Especificar una columna para que no permita valores nulos puede ayudar a mantener la integridad de los
datos asegurando que la columna tiene datos para todas las filas. Si los valores nulos no son permitidos, el
usuario que ingresa los datos se verá obligado a ingresar datos en la columna o toda la fila será rechazada
por el sistema.

Columnas definidas con las cláusulas PRIMARY KEY o IDENTITY no pueden permitir valores nulos.
La anulabilidad de una columna se define cuando se define la columna, ya sea cuando se crea o modifica una
tabla. Para definir columnas que permiten o no valores se utilizan las cláusulas NULL o NOT NULL
respectivamente.

El siguiente ejemplo usa el comando CREATE TABLE para crear la tabla Empleados. La columna Emp_ID y la
columna Apel no permiten valores nulos, mientras que la columna Nombre sí.

CREATE TABLE Empleados

(
Emp_ID char(4) NOT NULL,
Nombre varchar(30) NULL,
Apel varchar(30) NOT NULL,
)

Definir valores por defecto

Cada columna en un registro debe contener un valor (aún si ese valor es un valor nulo). Hay situaciones en
la cuales se necesita cargar una fila de datos en una tabla donde no se conocen los valores para todas las
columnas ( o esos valores no existen aún). Si la columna permite valores nulos, se puede cargar un valor
nulo para esa fila. Dado que como vimos los valores nulos no son aconsejables, una mejor solución puede ser
definir una valor por defecto para esa columna,. Por ejemplo, es común asignar un valor cero como el valor
por defecto (DEFAULT) para columnas numéricas o N/A para columnas de caracteres cuando no se
especifican valores.

La cláusula DEFAULT en el comando CREATE TABLE se considera una restricción aún cuando en realidad no
fuerza a nada.

Cuando se carga una fila en una tabla con una definición de un valor por defecto para una columna, se le
está indicando en forma implícita al SQL Server que cargue el valor por defecto en la columna en aquellos
casos que no se indique valor para dicha columna.

Si una columna no permite valores nulos y no tiene una definición por defecto, se deberá explícita indicar un
valor para esa columna o el SQL Server generará un mensaje de error indicando que la columna no permite
valores nulos.

Se puede crear una definición de valores por defecto para una columna de dos maneras:

 Creando la definición del valor por defecto cuando se crea la tabla (como parte de la definición de la
tabla)

 Agregando el valor por defecto a una tabla existente (cada columna permite solo un valor por defecto)

El siguiente ejemplo usa el comando CREATE TABLE para crear la tabla Empleados. Ninguna de las tres
columnas permite valores nulos; sin embargo, la columna Nombre provee la posibilidad de un nombre
desconocido al agregar una definición por defecto a la definición de la columna. El comando CREATE TABLE
usa la cláusula DEFAULT para definir el valor por defecto:

CREATE TABLE Empleados

(
Emp_ID char(4) NOT NULL,
Nombre varchar(30) NOT NULL DEFAULT ‘desconocido’,
Apel varchar(30) NOT NULL,
)

Se puede modificar o eliminar una definición por defecto existente. Por ejemplo se puede modificar el valor
insertado en una columna cuando no ha sido entrado ningún valor.
Cuando se utilice el Transact-SQL para modificar una definición por defecto, se debe primero borrar la
cláusula DEFAULT existente y luego recrearla con la nueva definición.

La definiciones DEFAULT no pueden ser creadas sobre columnas creadas con alguna de las siguientes
características:

 Con tipo de dato timestamp

 Con la propiedad IDENTITY o ROWGUIDCOL

 Con una definición por defecto existente o con un objeto por defecto.

El valor por defecto debe ser compatible con el tipo de dato definido para la columna. Por ejemplo para una
columna con un tipo de dato entero (int) el valor por defecto deberá ser un número entero y no una cadena
de caracteres.

Cuando una definición DEFAULT es agregada a una columna existente en una tabla, SQL Server (por defecto)
aplica el valor por defecto solo a las filas nuevas que sean ingresadas de ahí en adelante. Las filas que
tomaron el valor por defecto anterior no son afectadas. Cuando se agrega una nueva columna a una tabla
existente, sin embargo, se puede especificar al SQL Server que inserte el valor por defecto (especificado en
la definición de la nueva columna) en vez de un valor nulo en la nueva columna para las filas preexistentes
de la tabla.

Auto numeración y columnas de identificación

Para cada tabla, se puede crear una sola columna de identificación conteniendo los valores secuenciales
generados por el sistema que unívocamente identifican cada fila en la tabla. Por ejemplo, una columna de
identificación podría generar automáticamente un número único de recibo de compra a medida que las filas
son insertadas en la tabla.

Las columnas de identificación contienen valores únicos dentro de la tabla en la cual ellas son definidas. En
otras palabras, otras tablas que contienen columnas de identificación pueden contener los mismos valores de
identificación que los usados por otras tablas. Sin embargo, esta situación generalmente no es un problema,
porque los valores de identificación son típicamente usados solamente dentro del contexto de una sola tabla,
y las columnas de identificación no se relacionan a otra columna de identificación de otra tabla.

Puede ser creada una columna de identificación globalmente única para cada tabla que deba contener valores
que son únicos para todas las redes de computadoras del mundo. A menudo, se utiliza una columna que
garantice contener valores globalmente únicos cuando datos similares pueden ser generados desde múltiples
sistemas de base de datos. (por ejemplo en un sistema de facturación a clientes con datos ubicados en varias
subsidiarias distribuidas por el mundo). Cuando el dato es tomado en el sitio central para consolidación y
para la generación de reportes, el utilizar datos globalmente únicos permite a los clientes en diferentes países
evitar tener los mismos números de factura o de identificación de cliente. SQL Server utiliza internamente
columnas de identificación únicas globalmente en procesos de replicación, asegurando que las filas son
identificadas de forma unívoca a través de las múltiples copias de la tabla.

Crear columnas de identificación

Solamente una columna de identificación y una columna de identificación globalmente única pueden crearse
por cada tabla

Propiedad IDENTITY

Las columnas de identificación pueden ser implementadas usando la propiedad IDENTITY, la cual especifica el
primer número de identificación a ser usado en la primera fila que se ingrese y un incremento (propiedad
Identity Increment) que se agregará al último usado para generar un nuevo número de identificación para
una fila cualquiera que sea agregada. Cuando se insertan valores en una tabla con una columna de
identificación, SQL Server automáticamente genera el próximo número de identificación adicionando el
incremento al último generado.

Cuando se usa la propiedad IDENTITY para definir una columna de identificación, se debe considerar lo
siguiente:

 Una tabla puede tener solamente una columna con la propiedad IDENTITY property, y la columna
debe ser definida utilizando los tipos de datos int, numeric, smallint, bigint, o tynint.

 Se pueden especificar el número inicial y el incremento de la secuencia, siendo ambos por defecto
iguales a uno.

 La columna de identificación no debe permitir valores nulos y no debe contener una definición u
objeto por defecto.

 La columna puede ser referenciada en una lista de selección utilizando la palabra clave IDENTIFYCOL
después que la propiedad IDENTITY ha sido configurada.

 La función OBJECTPROPERTY puede ser usada para determinar si una tabla tiene una columna
IDENTITY, y la función COLUMNPROPERTY puede ser usada para determinar el nombre de la columna
IDENTITY.

El siguiente ejemplo utiliza el comando CREATE TABLE para crear la tabla Empleados. Ninguna columna
acepta valores nulos. Además, la columna Emp_ID es una columna de identificación. El valor inicial es 101, y
el incremento 1.

CREATE TABLE Empleados

(
Emp_ID SMALLINT IDENTITY(101,1) NOT NUL,
EmpNombre varchar(50) NOT NULL,
)

Si existe una columna de identificación en una tabla sobre la que se realizan frecuentes operaciones de
borrado de filas, se puede generar huecos en la secuencia de valores de la columna. Los valores eliminados
de las columnas de identificación no será reutilizados. Si se quieren evitar tales huecos no se debería utilizar
la propiedad IDENTITY, en cambio, se puede crear un desencadenador que determine un nuevo valor de
identificación (basado en los valores que ya existen en la columna de identificación) para cada nueva fila.

Identificadores globalmente únicos

Aunque la propiedad IDENTITY automatiza la numeración de las filas dentro de una tabla; tablas separadas,
sin embargo, cada una con su propia columna de identificación, pueden generar los mismos valores para sus
columnas de identificación. La propiedad IDENTITY garantiza valores no repetidos solo para la tabla que la
contiene. Si una aplicación debe generar una columna de identificación que genere valores únicos para toda
una base de datos o para todas las bases de datos en todo el mundo, se deberá utilizar la propiedad
ROWGUIDCOL, el tipo de dato uniqueidentifier y la función NEWID.

Cuando se utiliza la propiedad ROWGUIDCOL para definir un identificador globalmente único se deberá tener
en cuenta lo siguiente:

 Una tabla puede tener una sola columna ROWGUIDCOL, y esta columna debe ser definida con el tipo
de dato uniqueidentifier.

 SQL Server no genera valores automáticamente para esta columna. Para insertar un valor
globalmente único, se deberá crear una definición DEFAULT sobre la columna que utilice la función
NEWID.
  La columna puede ser referenciada en una lista de selección con la palabra clave ROWGUIDCOL
después que la propiedad ROWGUIDCOL fue configurada. Este funcionamiento es similar al modo en
que se puede referenciar una columna IDENTITY utilizando la palabra IDENTITYCOL.

 Dado que la propiedad ROWGUIDCOL no asegura unicidad, el comando UNIQUE debería ser usado
para determinar que serán insertados valores únicos en la columna con la propiedad ROWGUIDCOL.

El siguiente ejemplo utiliza el comando CREATE TABLE para crear la tabla Empleados. La columna Emp_ID
automáticamente generará un valor globalmente único cuando se inserte una nueva fila.

CREATE TABLE
(
Emp_ID uniqueidentifier DEFAULT NEWID() NOT NULL,
EmpNombre varchar(609 NOT NULL
)

Métodos para crear tablas

SQL Server provee varios métodos para crear tablas: el comando Transact_SQL CREATE TABLE, el árbol de la
consola del SQL Server Enterprise Manager, y el Database Designer (al cual se puede acceder a través del
SQL Server Enterprise manager).

Comando CREATE TABLE

Se puede utilizar el comando CREATE TABLE para crear una tabla dentro de una base de datos SQL Server,
Cuando se utiliza este comando, se debe definir, como mínimo, el nombre de la tabla, las columnas y el tipo
de datos (y si corresponde sus valores).

El siguiente ejemplo muestra como crear una tabla SQL:

CREATE TABLE Clientes

(
Cliente_ID char(4),
ClienteNombre varchar(40),
)

Además de los elementos básicos de la tabla (nombre, columnas y tipos de datos), el comando CREATE
TABLE también permite definir otra propiedades. Por ejemplo, se puede especificar el grupo de archivos
sobre el que se almacenará la tabla, o se pueden definir restricciones que se aplique a columnas individuales
o a toda la tabla.

Enterprise Manager

Se pueden crear tablas directamente en el SQL Server Enterprise Manager. Para crear una tabla en una base
de datos existente, expanda el árbol de la consola hasta que la base de datos aparezca, clic derecho sobre el
nodo Tables, y clic sobre New Table (Nueva Tabla). Cuando la ventana New Table se abra, complete la
información necesaria para definir la tabla como se muestra en la Figura.
 Figura 1: La ventana New Table en el SQL Enterprise Manager

Database Designer (Diseñador de base de datos)

Se puede utilizar el Database Designer en el SQL Server Enterprise Manager para agregar una tabla a un
diagrama de base de datos, editar su estructura, o relacionarla a otras tablas en el diagrama. Se puede tanto
insertar tablas existentes de la base de datos al diagrama como insertar una nueva tabla a la base de datos y
al diagrama. Además, desde el Table Designer se pueden modificar tablas existentes. Table Designer es una
herramienta visual que permite diseñar y ver una tabla en una base de datos a la que uno debe estar
conectado.

Administrar tablas de una base de datos SQL Server

Una vez que se ha creado una tabla en una base de datos SQL Server, se puede consultar información sobre
la tabla, modificar sus características, o eliminar la tabla de la dbase de datos.

Consultar información sobre tablas

Después que ha creado las tablas de una base de datos, Ud. podría necesitar encontrar información acerca de
las propiedades de una tabla (por ejemplo, el nombre o el tipo de dato de una columna, la naturaleza de sus
índices, etc.) Se puede también mostrar las dependencias de la tabla, determinando que objetos (tales como
vistas, procedimientos almacenados, y desencadenadores) tiene dependencia con la tabla. Advierta que si se
realizan modificaciones sobre la tabla, los objetos dependientes pueden ser afectados.

SQL Server incluye varios métodos para ver las características de una tabla y de sus dependencias.

 Para ver la definición de un tabla, utilice el procedimiento almacenado provisto por el sistema sp_help
o el SQL Server Enterprise Manager para ver las propiedades de una tabla.

 Para ver las dependencias de una tabla, utilice el procedimiento almacenado sp_depends o le opción
Display Dependencies en el SQL Server enterprise Manager.

 Para ver propiedades de las columnas, utilice el comando COLUMNPROPERTY para retornar
información acerca de una columna o un parámetro de procedimiento.
Modificar tablas de una base de datos SQL Server

Después que se crea una tabla se pueden cambiar muchas opciones que fueron definidas para la tabla
cuando esta fue originalmente creada, incluyendo las siguientes:

Pueden ser agregadas, modificadas o eliminadas columnas. Por ejemplo, el nombre de la columna, longitud,
tipo de dato, precisión, escala, y anulabilidad pueden ser modificadas, aunque con algunas restricciones.

 Pueden ser agregadas o modificadas las restricciones PRIMARY KEY y FOREIGN KEY

 Pueden ser agregadas o modificadas las restricciones UNIQUE y CHECK y la definición DEFAULT (y
objetos).

 Se puede agregar o borrar una columna de identificación usando las propiedades IDENTITY o
ROWGUIDCOL. La propiedad ROWGUIDCOL puede ser agregada o removida de una columna
existente, aunque sólo una columna en la tabla puede tener la propiedad ROWGUIDCOL al mismo
tiempo.

 Una tabla y las columnas seleccionadas dentro de la tabla pueden ser registradas para una indexación
a texto completo(full-text indexing)

Se puede, también, cambiar el nombre y el dueño (owner) de una tabla. Cuando se ejecuta esta operación,
se debe cambiar el nombre de tabla en todos los desencadenadores, procedimientos almacenados, Transact-
SQL scripts, o cualquier otro código de programación que use el nombre o el dueño anterior de la tabla.

El siguiente cuadro provee una lista de varios tipos de modifcaciones que se pueden hacer sobre las
propiedades de las tablas. El cuadro muestra, además, la lista de los métodos a utilizar a tal efecto.

Tipo de Modificación Método de Modificación

El procedimiento almacenado de sistema sp_rename. La opción Rename en el

Renombrar una tabla
Cambiar el dueño de una
tabla
Modificar las propiedades de
las columnas
Renombrar una columna
SQL Server Enterprise Manager
El procedimiento almacenado de sistema sp_changeobjectowner
El comando ALTER DATABASE La opción Design Table en el SQL Server
Enterprise Manager
El procedimiento almacenado de sistema sp_rename La opción Design Table
en el SQL Server Enterprise Manager

Borrar tablas de una base de datos SQL Server

A veces, se necesita borrar una tabla (por ejemplo, cuando se quiere implementar un nuevo diseño o liberar
espacio en una base de datos). Cuando se elimina una tabla, la definición de su estructura, los índices a texto
completo, las restricciones y los índices son borrados de manera permanente, y el espacio que ocupaban es
liberado para otros objetos. Se puede explícitamente borrar una tabla temporaria si no se quiere esperar a
que sea eliminada en forma automática.

Si se necesita eliminar tablas que se encuentran relacionadas a través de FOREIGN KEY y de las restricciones
UNIQUE o PRIMARY KEY, se deben eliminar primero las tablas con la restricción FOREIGN KEY primero. Si se
necesita eliminar una tabla que tiene la restricción FOREIGN KEY pero no se quiere eliminar la tabla con la
clave ajena, primero se deberá eliminar la restricción FOREIGN KEY.
Para eliminar una tabla de una base de datos SQL Server se utiliza el comando DROP TABLE o el Enterprise
Manager removiendo la tabla del nodo Tables.

MODULO II: Implementar una base de datos y sus tablas

Tema 4: Implementar la integridad de los datos

Introducción a la integridad de los datos

Las tablas en una base de datos SQL Server pueden incluir diferentes tipos de propiedades para asegurar la
integridad de los datos. Estas propiedades incluyen: tipos de dato, definiciones NOT NULL, definiciones
DEFAULT, propiedades IDENTITY, restricciones, reglas, desencadenadores e índices. A continuación se
presenta una introducción de todos estos tipos de integridad de datos soportados por SQL Server. Además,
se discutirán los diferentes tipos de integridad de datos, incluyendo integridad de entidad, integridad de
dominio, integridad referencial e integridad definida por el usuario.

Asegurar la integridad de los datos

Asegurar la integridad de los datos garantiza la calidad de los datos. Por ejemplo, suponga que Ud. crea la
tabla Clientes en su base de datos. Los valores en la columna Cliente_ID deberían identificar unívocamente a
cada cliente que es ingresado a la tabla. Como resultado, si un cliente tiene un Cliente_ID de 438, ningún
otro cliente debería tener el valor Cliente_ID en 438. Luego, suponga que se ha creado una columna
Cliente_Eval que es utilizada para evaluar a cada cliente con una calificación de 1 a 8. En este caso, la
columna Cliente_Eval no deberá aceptar un valor de 9 o cualquier otro valor que no esté entre 1 y 8. En
ambos casos, se deben usar métodos soportados por SQL Server para asegurar la integridad de los datos.

SQL Server soporta varios métodos para asegurar la integridad de los datos, que incluyen: tipos de dato,
definiciones NOT NULL, definiciones DEFAULT, propiedades IDENTITY, restricciones, reglas,
desencadenadores e índices. Ya se han visto algunos de estos métodos. Un breve resumen de ellos es
incluido aquí a fin de mostrar una visión comprehensiva de los distintos modos de asegurar la integridad de
los datos. Algunas de esta propiedades de la tablas, tales como las definiciones NOT NULL y DEFAULT, son a
veces consideradas tipos de restricciones. Para los propósitos de este Kit, sin embargo, son tratadas de
forma separada.

Tipos de Dato

Un tipo de dato es un atributo que especifica el tipo de dato (carácter, entero, binario, etc.) que puede ser
almacenado en una columna, parámetro o variable. SQL Server provee de un conjunto de tipos de dato, aún
cuando se pueden crear tipos de dato definidos por el usuario que se crean sobre la base de tipos de dato
provisto por el SQL Server. Los tipos de dato provistos por el sistema definen todos los tipos de dato que se
pueden usar en SQL Server. Los tipos de dato pueden ser utilizados para asegurar la integridad de los datos
porque los datos ingresados o modificados deben cumplir con el tipo de dato especificado para el objeto
correspondiente. Por ejemplo, no se puede almacenar el nombre de alguien en una columna con un tipo de
dato datetime, ya que esta columna solo aceptará valores válidos de fecha y hora.

Definiciones NOT NULL

La anulabilidad de una columna determina si las filas en la tabla pueden contener valores nulos para esa
columna. Un valor nulo no es lo mismo que un cero, un blanco o una cadena de caracteres de longitud cero.
Un valor nulo significa que no se ha ingresado ningún valor para esa columna o que el valor es desconocido o
indefinido. La anulabilidad de una columna se define cuando se crea o se modifica una tabla. Si se usan
columnas que permiten o no valores nulos, se debería usar siempre las cláusula NULL y NOT NULL dada la
complejidad que tiene el SQL Server para manejar los valores nulos y no prestarse a confusión. La cláusula
NULL se usa si se permiten valores nulos en la columna y la cláusula NOT NULL si no.
Definiciones DEFAULT

Los valores por defecto indican que valor será guardado en una columna si no se especifica un valor para la
columna cuando se inserta una fila. Las definiciones DEFAULT pueden ser creadas cuando la tabla es creada
(como parte de la definición de la tabla) o pueden ser agregadas a una tabla existente. Cada columna en una
tabla puede contener una sola definición DEFAULT.

Propiedades IDENTITY

Cada tabla puede tener sólo una columna de identificación, la que contendrá una secuencia de valores
generados por el sistema que unívocamente identifican a cada fila de la tabla. Las columnas de identificación
contienen valores únicos dentro de la tabla para la cual son definidas, no así con relación a otras tablas que
pueden contener esos valores en sus propias columnas de identificación. Esta situación no es generalmente
un problema, pero en los casos que así lo sea (por ejemplo cuando diferentes tablas referidas a una misma
entidad conceptual, como ser clientes, son cargadas en diferentes servidores distribuidos en el mundo y
existe la posibilidad que en algún momento para generar reporte o consolidación de información sean unidas)
se pueden utilizar columnas ROWGUIDCOL como se vio anteriormente.

Restricciones (constraints)

Las restricciones permiten definir el modo en que SQL Server automáticamente fuerza la integridad de la
base de datos. Las restricciones definen reglas indicando los valores permitidos en las columnas y son el
mecanismo estándar para asegurar integridad. Usar restricciones es preferible a usar desencadenadores,
reglas o valores por defecto. El query optimizer (optimizador de consultas) de SQL Server utiliza definiciones
de restricciones para construir planes de ejecución de consultas de alto rendimiento.

Reglas (rules)

Las reglas son capacidades mantenidas por compatibilidad con versiones anteriores de SQL Server, que
realizan algunas de las mismas funcionalidades que las restricciones CHECK. Las restricciones CHECK son el
modo preferido y estándar de restringir valores para una columna. Las restricciones CHECK, por otro lado,
son mas concisas que las reglas; se puede aplicar solo una regla por columna mientras que se pueden aplicar
múltiples restricciones CHECK. Las restricciones CHECK son especificadas como parte del comando CREATE
TABLE, mientras que las reglas son creadas como objetos separados y luego vinculadas a la columna.

Se utiliza el comando CREATE RULE para crear una regla, y luego se debe utilizar el procedimiento
almacenado sp_bindrule para vincular la regla a una columna o a un tipo de dato definido por el usuario.

Desencadenadores

Los desencadenadores son una clase especial de procedimientos almacenados que son definidos para ser
ejecutados automáticamente cuando es ejecutado un comando UPDATE, INSERT o DELETE sobre una tabla o
una vista. Los desencadenadores son poderosas herramientas que pueden ser utilizados para aplicar las
reglas de negocio de manera automática en el momento en que los datos son modificados. Los
desencadenadores pueden comprender el control lógico que realizan loas restricciones, valores por defecto, y
reglas de SQL Server (aún cuando es recomendable usar restricciones y valores por defecto antes que
desencadenadores en la medida que respondan a todas las necesidades de control de integridad de datos).

Indices

Un índice es una estructura que ordena los datos de una o más columnas en una tabla de base de datos. Un
índice provee de punteros a los valores de los datos almacenados en columnas especificadas de una tabla y
luego ordena esos punteros de acuerdo al orden que se especifique. Las bases de datos utilizan los índices
del mismos modo que se utilizan los índices de un libro: se busca en el índice para encontrar un determinado
valor y luego se sigue un puntero a la fila que contiene ese valor. Un índice con clave única asegura la
unicidad en la columna.

Tipos de integridad de datos

SQL Server soporta cuatro tipos de integridad de datos: integridad de entidad, integridad de dominio,
integridad referencial e integridad definida por el usuario.

Integridad de entidad

La integridad de entidad define una fila como una única instancia de una entidad para una tabla en particular.
La integridad de entidad asegura la integridad de la columna de identificación o la clave primaria de una tabla
( a través de índices, estricciones UNIQUE, restricciones PRIMARY KEY, o propiedades IDENTITY).

Integridad de dominio

La integridad de dominio es la validación de las entradas en una determinada columna. Se puede asegurar la
integridad de dominio restringiendo el tipo (a través de tipos de datos), el formato (a través de las
restricciones CHECK y de las reglas), o el rango de valores posibles ( a través de restricciones FOREIGN KEY,
restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL, y reglas)

Integridad referencial

La integridad referencial preserva las relaciones definidas entre tablas, cuando se entran, modifican o borran
registros. En SQL Server, la integridad referencial esta basada en interrelaciones entre claves ajenas y claves
primarias o entre claves ajenas y claves únicas (a través de la restricciones FOREIGN KEY y CHECK). La
integridad referencial asegura que los valores de las claves son consistentes a través de distintas tablas. Tal
consistencia requiere que no existan referencia a valores inexistentes y que, si un valor clave cambia, todas
las referencias cambien consistentemente a lo largo de la base de datos.

Cuando se fuerza la integridad referencial, SQL Server previene a los usuarios de realizar lo siguiente:

 Agregar registros a una tabla relacionada si no hay registros asociados en la correspondiente tabla
primaria.

 Cambiar valores en la tabla primaria que resulten en registros huérfanos en las tablas relacionadas.

 Borrar registros desde una tabla primaria si existen registros relacionados en la tabla ajena.

Por ejemplo, con las tablas Ventas y Títulos en la base de datos Pubs, la integridad referencial está basada
sobre las relaciones entre la clave ajena (tit_ID) en la tabla ventas y la clave primaria (tit_ID) en la tabla
Titulos, como se muestra en la Figura.

Figura 1: Integridad referencial entre la tabla Ventas y la tabla Titulos

Integridad definida por el usuario

La integridad definida por el usuario permite definir reglas de negocios específicas que no caigan dentro de
alguna de las categorías anteriores. Todas las categorías soportan integridad definida por el usuario (todas
las restricciones a nivel columna y a nivel tabla en el comando CREATE TABLE, procedimientos almacenados
y desencadenadores)

Implementar restricciones de integridad

Una restricción es una propiedad asignada a una tabla o a una columna que previene que datos inválidos
sean grabados en la o las columnas especificadas. Por ejemplo, una restricción UNIQUE o PRIMARY KEY
previene de inserciones de valores que dupliquen un valor existente, mientras que las restricciones CHECK
previenen de inserciones que no igualen una condición de búsqueda, y una restricción FOREIGN KEY asegura
la consistencia de la relación entre dos tablas.

Introducción a las restricciones de integridad

La restricciones permiten definir la forma en que SQL Server automáticamente asegurará la integridad de la
base de datos. Las restricciones definen reglas en base a los valores permitidos en las columnas y son los
mecanismos estándar para asegurar la integridad. Se deberían usar restricciones en vez de
desencadenadores, procedimientos almacenados, valores por defecto o reglas.

Las restricciones pueden ser restricciones de columnas o de tablas:

 Una restricción de columna es especificada como parte de la definición de la columna y se aplica solo
a esta columna.

 Una restricción de tabla es declarada independientemente de las definiciones de la columna y se

puede aplicar a mas de una columna en la tabla.

Las restricciones de tabla deben ser usadas cuando mas de una columna se incluye en la formulación de la
condición. Por ejemplo, si una tabla tiene dos o mas columnas en la clave primaria, se debe usar una
restricción de tabla para incluirlas a todas en la clave primaria. Supongamos una tabla que registra eventos
que suceden en una computadora de una fábrica. Dicha tabla registra eventos de diferente tipo que pueden
suceder al mismo tiempo, pero no pueden suceder dos eventos del mismo tipo al mismo tiempo. Esta regla
puede ser forzada incluyendo a ambas columnas; tipos de eventos y tiempo, en una clave primaria de dos
columnas, como se muestra en el siguiente comando CREATE TABLE:

CREATE TABLE Procesos

(
TipoEvento int,
TiempoEvento datetime,
LugarEvento char(50),
DescripEvento char(1024),
CONSTRAINT event_key PRIMARY KEY (TipoEvento, TiempoEvento)
)

SQL Server soporta cuatro clases principales de restricciones: PRIMARY KEY, UNIQUE, FOREIGN KEY y
CHECK.

Restricciones PRIMARY KEY

Una tabla usualmente tiene una columna (o una combinación de columnas) que identifica unívocamente cada
fila de la tabla. Esta columna (o columnas) son llamadas “clave primaria” de la tabla y aseguran la integridad
de la entidad de la tabla. Se puede crear una clave primaria usando la restricción PRIMARY KEY cuando se
crea o modifica la tabla.

Una tabla puede tener solo una restricción PRIMARY KEY, y ninguna columna que participa de la clave
primaria puede aceptar nulos. Cuando se especifica una restricción PRIMARY KEY para una tabla, SQL Server
2000 asegura la unicidad de los datos creando un índice principal para las columnas de la clave primaria.
Este índice permite, además, un acceso rápido a las filas cuando la clave primaria se usa para formular
consultas.

Si se define la restricción PRIMARY KEY para mas de una columna, los valores se pueden duplicar para una
columna, pero cada combinación de valores para todas las columnas de la clave principal de una fila debe ser
única para toda la tabla. La figura muestra como las columnas Autor_ID y Titulo_ID de la tabla TituloAutor
forman una restricción PRIMARY KEY, la que asegura que las combinaciones Autor_ID Titulo_ID son únicas.

Figura 2: La clave primaria de la tabla TituloAutor en la base de datos pubs

Crear restricciones PRIMARY KEY

Se pueden crear restricciones PRIMARY KEY utilizando uno de los siguientes métodos:

 Crear la restricción cuando se crea la tabla

 Agregar la restricción a una tabla ya existente, siempre que no exista otra restricción PRIMARY KEY
para esa tabla.

Se puede modificar o eliminar una restricción PRIMARY KEY después que ha sido creada.

Por ejemplo se podría querer que la restricción PRIMARY KEY de la tabla referencie a otras columnas, o
querer cambiar el orden de las columnas, nombre de índice, agrupamiento o factor de llenado definido con un
restricción PRIMARY KEY.

El siguiente comando CREATE TABLE crea la tabla Tabla1 y define la columna Col1 como clave primaria:

CREATE TABLE Tabla1

(
Col1 int PRIMARY KEY,
Col2 varchar(30)
)

Se puede definir la misma restricción utilizando la definición a nivel de tabla:

CREATE TABLE Tabla1

(Col1 int,
Col2 varchar(30),
CONSTRAINT tabla_pk PRIMARY KEY (Col1)
)
Se puede usar el comando ALTER TABLE para agregar una restricción PRIMARY KEY a una tabla existente:

ALTER TABLE Tabla1

ADD CONSTRAINT tabla_pk PRIMARY KEY (Col1)

Cuando una restricción PRIMARY KEY se agrega a una columna (o columnas) existente en un tabla, SQL
Server 2000 controla los datos ya existentes en las columnas para asegurar que se cumplen las siguientes
reglas:

 No hay valores nulos

 No hay valores duplicados

Si se agrega una restricción PRIMARY KEY a una columna que tiene valores nulos o duplicados, SQL Server
emite un mensaje de error y no agrega la restricción.

SQL Server automáticamente crea un índice único para asegurar la unicidad de los valores de la restricción
PRIMARY KEY. Si no existe un índice agrupado ( o no se especifica un índice no-agrupado) se crea un índice
único y no agrupado para asegurar la restricción PRIMARY KEY (ver índices mas adelante en este módulo).

Restricciones UNIQUE

Se pueden usar las restricciones UNIQUE para asegurar que no sean entrados valores duplicados en
columnas específicas que no participan de la clave primaria. Aunque tanto la restricción PRIMARY KEY como
la restricción UNIQUE aseguran unicidad, se debería usar UNIQUE en vez de PRIMARY KEY en los siguientes
casos:

 Si una columna ( o combinación de columnas) no son la clave primaria. Se pueden definir muchas
restricciones UNIQUE para una tabla, muientras que solo una restricción PRIMARY KEY,

 Si la columna permite valores nulos. Las restricciones UNIQUE permiten que se las defina para
aceptar valores nulos, mientra que las restricciones PRIMARY KEY no lo permiten.

Una restricción UNIQUE pueden ser referenciadas por una restricción FOREIGN KEY.

Crear restricciones UNIQUE

Se pueden crear restricciones UNIQUE en el mismo modo que se crean restricciones PRIMARY KEY:

 Creando la restricción al momento de crear la tabla ( como parte de la definición de la tabla)

 Agregando la restricción a una tabla existente, previendo que la o las columnas comprendidas en la
restricción UNIQUE contengan solo valores no duplicados o valores nulos. Una tabla puede aceptar
múltiples restricciones UNIQUE.

Se pueden usar los mismos comandos Transact-SQL para crear restricciones UNIQUE que los utilizados para
crear restricciones PRIMARY KEY. Simplemente reemplace las palabras PRIMARY KEY por UNIQUE. Al igual
que con las restricciones PRIMARY KEY las restricciones UNIQUE pueden ser modificadas o eliminadas una
vez creadas.

Cuando se agrega una restricción UNIQUE a una columna (o columnas) existente en la tabla, SQL Server (por
defecto) controla los datos existentes en las columnas para asegurar que todos los valores, excepto los nulos,
son únicos. Si se agrega una restricción UNIQUE a una columna que tienen valores no nulos duplicados, SQL
Server genera un mensaje de error y no agrega la restricción.

SQL Server automáticamente crea un índice UNIQUE para asegurar la unicidad requerida por la restricción
UNIQUE. Por lo que, si se intenta ingresar un nueva fila con valores duplicados para la columna (o
combinación de columnas) especificada se genera una mensaje de error diciendo que ha sido violada la
restricción UNIQUE y no se agrega la fila a tabla. Si no se especifica un índice agrupado, se creará un índice
no-agrupado por defecto cuando se crea una restricción UNIQUE.

Restricciones FOREIGN KEY

Una clave ajena es una columna o combinación de columnas usadas para establecer y asegurar una conexión
entre dos tablas. Al agregar una columna (o columnas) a una de las tablas y definir estas columnas con una
restricción FOREIGN KEY se crea una conexión entre dos tablas. Las columnas tendrán únicamente valores
que se encuentren en las columnas de la clave primaria de la segunda tabla.

Una tabla puede tener múltiples restricciones FOREIGN KEY.

Por ejemplo, la tabla Titulos en la base de datos Pubs tiene una conexión a la tabla Editores al haber una
relación lógica entre autores y editores.

La columna Pub_ID en la tabla Titulos concuerda con la columna de clave principal en la tabla Editores, como
muestra la Figura. La columna Pub_ID en la tabla Titulos es la clave ajena asociada la tabla Editores.

Se puede crear una clave ajena definiendo una restricción FOREIGN KEY cuando se crea o modifica una tabla.
Además de a una PRIMARY KEY, una clave ajena puede referenciar a una restricción UNIQUE en otra tabla.

Una restricción FOREIGN KEY puede contener valores nulos; sin embargo, si cualquier columna de una
restricción FOREIGN KEY compuesta contiene valores nulos, la verificación de la restricción FOREIGN KEY
será omitida.

Una restricción FOREIGN KEY puede referenciar columnas en tablas de la misma base de datos o dentro de la
misma tablas (tablas auto-referenciadas).

Figura 3: AUna restricción FOREIGN KEY definida en la tabla Titulos de la base datos Pubs.

Aún cuando el propósito primario de una restricción FOREIGN KEY en es el de controlar que datos pueden ser
guardados en la tabla de la clave ajena, también controla cambios a datos en la tabla de la clave primaria.
Por ejemplo, si se elimina la fila de un editor de la tabla de editores y el ID de ese editor esta siendo utilizado
en alguna fila de la tabla Titulos, la integridad entre las dos tablas se destruiría. Los libros del editor
eliminado quedarían huérfanos, sin una conexión a los datos de la tabla Editores. Una restricción FOREIGN
KEY previene esta situación. La restricción fuerza la integridad referencial al asegurar que no se puedan
hacer cambios en los datos en la tabla de la clave primaria si esos cambios invalidan la conexión a los datos
de la tabla de la clave ajena. Si se trata de eliminar una fila en la tabla de clave primaria o de cambiar un
valor de clave primaria, dicha acción no se ejecutará si el valor de clave primaria cambiado o eliminado
corresponde a un valor en la restricción FOREIGN KEY de otra tabla.
Para cambiar o eliminar una fila en una restricción FOREIGN KEY, se debe primero o bien eliminar los datos
correspondientes en la tabla de clave ajena o cambiar los datos de clave ajena en la tabla de clave ajena, a
través de conectar la clave ajena a distinto valor de la clave principal.

Crear restricciones FOREIGN KEY

Se pueden crear restricciones FOEREIGN KEY utilizando alguno de los siguientes métodos:

 Creando la restricción cuando se crea la tabla (como parte de la definición de la tabla).

 Agregando la restricción a una tabla existente, indicando que la restricción FOREING KEY esta
conectada a una restricción PRIMARY KEY existente o a una restricción UNIQUE.

Se puede modificar o eliminar una restricción FOREIGN KEY una vez que esta ha sido creada.

Por ejemplo, se podría querer que la tabla de clave ajena referencie a otras columnas. No se puede cambiar
la longitud de una columna definida con un restricción FOREIGN KEY.

Para modificar una restricción FOREIGN KEY utilizando Transact-SQL, se debe primero eliminar la restricción
FOREIGN KEY anterior y luego recrearla con su nueva definición.

El siguiente comando CREATE TABLE crea la tabla Tabla1 y define la columna Col2 con una restricción
FOREIGN KEY que apunta a la columna Empleado_ID que es clave primaria de la tabla Empleados.

CREATE TABLE Tabla1

(Col1 int PRIMARY KEY,
Col2 int REFERENCES Empleados(Empleado_ID)
)

Se puede definir, además la misma restricción usando la restricción FOREIGN KEY a nivel de tabla:

CREATE TABLE Tabla1

(
Col1 int PRIMARY KEY,
Col2 int,
CONSTRAIT col2_fk FOREIGN KEY (Col2)
REFERENCES Empleados(Empleado_ID)
)

Se puede usar el comando ALTER TABLE para agregar una restricción FOREIGN KEY a una tabla existente:

ALTER TABLE Tabla1

ADD CONSTRAIT col2_fk FOREIGN KEY (Col2)
REFERENCES Empleados(Empleado_ID)

Cuando se agrega una restricción FOEREING KEY a una columna (o columnas) existentes en un tabla, SQL
Server 2000 (por defecto) controla los datos existentes en las columnas para asegurar que todos los valores,
excepto los nulos, existen en las columnas referenciadas por las restricciones PRIMARY KEY o UNIQUE. Se
puede configurar al SQL Server para que no realice este control y obligarlo a agregar la nueva restricción sin
fijarse en los datos previos, esto puede ser útil cuando se quiere que la restricción funcione solo de aquí en
adelante.

De todos modos, se deberá ser cuidadoso cuando se agregan restricciones sin controlar la consistencia de los
datos previos dado que se pueden provocar inconsistencias no deseadas.

Deshabilitar restricciones FOREIGN KEY

Se pueden deshabilitar restricciones FOREIGN KEY preexistentes cuando se realicen alguna de las siguientes
acciones:

 Al ejecutar los comandos INSERT y UPDATE: Deshabilite una restricción FOREIGN KEY durante un
comando INSERT o UPDATE si el dato nuevo violará la restricción o si la restricción se debe aplicar
solo a datos ya existentes en la tabla. Deshabilitar restricciones permite que los datos sean
modificados sin que sean validados por las restricciones.

 Al implementar procesos de replicación: Deshabilite una restricción FOREIGN KEY durante el proceso
de replicación si la restricción es específica de la base de datos fuente. Cuando se replica una tabla,
los datos y la definición de la tabla son copiados desde una base de datos fuente a una base de datos
destino. Estas bases de datos están generalmente (pero no necesariamente) sobre servidores
separados. Si las restricciones FOREIGN KEY específicas de la base de datos fuente no están
deshabilitadas, estas podrían innecesariamente prevenir que nuevos datos sean ingresados en la base
de datos destino.

Restricciones CHECK

Las restricciones CHECK aseguran la integridad de dominio al limitar los valores que son aceptados para una
columna. Son similares a lar restricciones FOREIGN KEY en que ambas controlan los valores que son puestos
en una columna. La diferencia está en cómo se determina cuales son valores válidos. Las restricciones
FOREIGN KEY toman los valores válidos de otra tabla, mientras que las restricciones CHECK determinan los
valores válidos evaluando una expresión lógica que no se basa en datos de otra columna. Por ejemplo, es
posible limitar el rango de valores para una columna Salario creando una restricción CHECK que permita
solamente datos dentro del rango de $15.000 a $100.000. Este capacidad evita el ingreso de salarios fuera
del rango normal de salarios de la compañía.

Se puede crear una restricción CHECK con una expresión lógica (Booleana) que retorne TRUE (verdadero) o
FALSE (falso) basada en operadores lógicos. Para permitir solamente datos que se encuentren dentro del
rango de $15.000 a $100.000, la expresión lógica será como la siguiente:

Salario >= 15000 AND Salario <= 100000

Se puede aplicar múltiples restricciones CHECK para una sola columna. Las restricciones son evaluadas en el
orden en que han sido creadas. Además, se puede aplicar una misma restricción CHECK a múltiples
columnas creando la restricción a nivel de tabla. Por ejemplo, se puede usar una restricción CHECK para
múltiples columnas para confirmar que cualquier fila con la columna País igual a USA tenga valor para la
columna Estado que sea una cadena de dos caracteres. Esta posibilidad permite que múltiples condiciones
sean controladas en un lugar.

Crear restricciones CHECK

Se pueden crear restricciones usando uno de los siguientes métodos:

 Creando la restricción cuando se crea la tabla (como parte de las definiciones de la tabla)

 Agregando la restricción a una tabla existente.

Se puede modificar o eliminar una restricción CHECK una vez que ha sido creada. Por ejemplo, se puede
modificar la expresión usada por la restricción CHECK sobre una columna en la tabla.

Para modificar una restricción CHECK primero se debe eliminar la antigua restricción y luego recrearla con su
nueva definición.

El siguiente comando CREATE TABLE crea una tabla Tabla1 y define la columna Col2 con un restricción
CHECK que limita los valores que puede tomar la columna al rango comprendido entre 0 y 100.
CREATE TABLE Tabla1
(
Col1 int PRIMARY KEY,
Col2 int
CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100),
Col3 varchar(30)
)

También se puede definir la misma restricción usando restricción CHECK a nivel tabla:

CREATE TABLE Tabla1

(
Col1 int PRIMARY KEY,
Col2 int ,
Col3 varchar(30),
CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100)
)

Se puede utilizar el comando ALTER TABLE para agregar una retricción CHECK a una tabla existente:

ALTER TABLE Tabla1

ADD CONSTRAIT monto_limite CHECK (Col2 BETWEN 0 AND 100)

Cuando se agrega una restricción CHECK a una tabla existente, la restricción CHECK puede aplicarse solo a
los datos nuevos o también a los datos existentes. Por defecto la restricción CHECK se aplica a los datos
existentes tanto como a los nuevos datos.

La opción de aplicar la restricción a los nuevos datos solamente es útil cuando las reglas de negocios
requieren que la restricción se aplique de ahora en más.

Por ejemplo, una vieja restricción podría requerir códigos postales restringidos a 5 caracteres siendo los
mismos aún válidos mientras que los nuevos códigos que se ingresen deberán tener nueve caracteres. Por lo
que solo los datos nuevos deberían ser controlados para verificar que cumplen con la restricción.

Sin embargo, se debe ser cuidadoso cuando se agregan restricciones sin controlar los datos existentes,
porque esta acción saltea los controles de SQL Server 2000 que aseguran la integridad para los datos de la
tabla.

Deshabilitar restricciones CHECK

Se pueden deshabilitar restricciones CHECK preexistentes cuando se realicen alguna de las siguientes
acciones:

 Al ejecutar los comandos INSERT y UPDATE: Deshabilite una restricción CHECK durante un comando
INSERT o UPDATE si el dato nuevo violará la restricción o si la restricción se debe aplicar solo a datos
ya existentes en la tabla. Deshabilitar restricciones permite que los datos sean modificados sin que
sean validados por las restricciones.

Al implementar procesos de replicación: Deshabilite una restricción CHECK durante el proceso de replicación si la
restricción es específica de la base de datos fuente. Cuando se replica una tabla, los datos y la definición de la tabla
son copiados desde una base de datos fuente a una base de datos destino. Estas bases de datos están generalmente
(pero no necesariamente) sobre servidores separados. Si las restricciones CHECK específicas de la base de datos
fuente no están deshabilitadas, estas podrían innecesariamente prevenir que nuevos datos sean ingresados en la
base de datos destino.
 MODULO II: Implementar una base de datos y sus tablas

Tema 5: Implementar índices

Introducción

Los índices son objetos de base de datos diseñados para mejorar el rendimiento de las consultas. En este
punto veremos la estructura y el propósito de los índices y sus tipos y características. Se verá como
determinar cuando un índice es necesario y apropiado, que tipo de índice usar y como crearlos. Una vez que
se crean los índices se deben mantener para maximizar la performance de las consultas, para ello existen
varias herramientas que asisten en la tarea de administración y mantenimiento de los índices. La
administración comprende las tareas de reconstrucción, renombrado, y eliminación de índices.

Arquitectura de los índices

Los índices están estructurados para facilitar una respuesta rápida de conjuntos de resultados. Los dos tipos
de índices que SQL Server soporta son agrupados y no agrupados. Los índices son aplicados a una o más
columnas en tablas o vistas. Tablas indexadas son soportadas por todas las ediciones de SQL Server 2000, y
vistas indexadas son soportadas por las ediciones SQL Server Entreprise y SQL Server Developer. Las
características de un índice afecta el uso de los recursos del sistema y performance general. El Query
Optimizer usará un índice si este mejorará la performance de la consulta.

Propósito y estructura

Un índice en SQL Server asiste al motor de base de datos en la ubicación de los registros, tal como un índice
en un libro ayuda a ubicar información rápidamente. Sin índices, una consulta deberá buscar en todos los
registros de la tabla en orden a encontrar coincidencias. Un índice de base de datos una o más columnas de
valores de la tabla (llamadas clave del índice) y punteros a los correspondientes registros de la tabla. Cuando
se ejecuta una consulta usando la clave del índice, el Query Optimizer utilizará el índice para ubicar los
registros que cumplen con la consulta.

Un índice es estructurado por el SQL Server Index manager como un árbol balanceado (B-tree). Un B-tree es
análogo a un árbol invertido con la raíz del árbol arriba, y los niveles hoja abajo, con niveles medios entre
ambos. Cada objeto en la estructura de árbol es un grupo de claves del índice ordenadas llamadas páginas
del índice.

Un B-tree facilita realizar consultas rápidas y consistentes dado el cuidadoso balance del ancho y profundidad
del árbol a medida que el índice crece. Ordenar el índice sobre la clave del mismo también mejora la
performance. Todas las búsquedas comienzan en la raíz del B-tree y luego se mueven a través del árbol
hasta el correspondiente nivel hoja. El número de registros de la tabla y el tamaño de la clave del índice
afectan el ancho y profundidad del árbol. El tamaño de la clave del índice es llamado el ancho de la clave.
Una tabla con muchos registros y un gran ancho de la clave crea un profundo y amplio B-tree. Cuanto menor
sea el B-tree mas rápido retornará un valor buscado.

Para un rendimiento óptimo, se crean sobre columnas que son comúnmente usadas en las consultas. Por
ejemplo, los usuarios pueden consultar la tabla de Clientes en base al apellido o al ID del cliente. Por lo tanto
se deberían crear dos índices para la tabla: un índice por apellido y otro por ID del cliente. Para ubicar
eficientemente a los registros, el Query Optimizer usa un índice que concuerde con la consulta. El Query
Optimizer usará el índice por el ID del cliente cuando se ejecute la siguiente consulta:

SELECT * FROM Clientes WHERE Cliente_ID = 798

No cree índices para todas las columnas de una tabla, porque demasiados índices impactarán negativamente
en la performance general. La mayoría de la bases de datos son dinámicas; esto es, regularmente los
registros son agregados, eliminados y modificados. Cuando una tabla que contiene un índice es modificada,
el índice debe ser actualizado para reflejar la modificación. Si la actualización del índice no se produjera, el
índice se volvería inútil. Por lo tanto, las inserciones, eliminaciones y modificaciones de registros disparan al
Index Manager para que actualice los índices de la tabla. Al igual que la tablas, los índices son estructuras
que ocupan espacio en la base de datos. El espacio que ocupa un índice es directamente proporcional a la
cantidad de registros en la tabla y al ancho de la clave del índice. Antes de crear un índice se debe realizar un
balance que asegure que el incremento de performance por el aumento de las respuestas en la consultan
justifica con creces la caída de rendimiento y la sobrecarga producida por la tarea de mantenimiento del
índice.

Tipos de índices

Hay dos tipos de índices: agrupados (clustered) y no agrupados (non clustered). Ambos tipos de índices son
estructuras tipo B-tree. Un índice agrupado contiene los registros de la tabla a nivel hoja del B-tree. Un índice
no agrupado es una estructura de índice separada, independiente del ordenamiento físico de los registros en
la tabla. Si existe un índice agrupado en un tabla, un índice no agrupado utilizará al índice agrupado para la
búsqueda de los registros. En la mayoría de los casos se creará antes un índice agrupado que los índices no
agrupados sobre una tabla.

Índices agrupados

Puede haber solo un índice agrupado por tabla o vista, dado que estos índices ordenan físicamente la tabla o
vista según la clave del índice agrupado. Este tipo de índices es particularmente eficiente para consultas,
dado que los registros de datos completos (en páginas de datos) son guardados a nivel de hoja del B-tree. El
ordenamiento y la ubicación de los datos en un índice agrupado es análogo al de un diccionario donde las
palabras son ordenadas en forma alfabética y las definiciones aparecen junto a las palabras.

Cuando se crea una restricción PRIMARY KEY en un tabla que no contiene un índice agrupado, SQL Server
creará uno y utilizará la columna de clave primaria como clave para el índice agrupado. Si ya existe un índice
agrupado SQL Server creará un índice no agrupado sobre la columna definida con una restricción PRIMARY
KEY. Una columna definida como la clave primaria es un índice muy útil porque los valores de la columna
están garantizados que son únicos. Índices sobre columnas de valores únicos son de menor tamaño que los
índices sobre columnas con valores duplicados y generan estructuras de búsqueda más eficientes.

Una columna definida con una restricción UNIQUE genera automáticamente un índice no agrupado.

Para forzar el tipo de índice a ser creado para una columna o columnas, se puede especificar las cláusulas
CLUSTERED o NONCLUSTERED en los comandos CREATE TABLE, ALTER TABLE o CREATE INDEX. Suponga
que se crea una tabla Personas que contiene las siguientes columnas: PersonaID, Nombre, Apellido y
NumDocumento. La columna PersonID se define con la restricción PRIMARY KEY, la columna NumDocumento
con la restricción UNIQUE. Para hacer un índice agrupado para la columna NumDocumento y un índice no
agrupado para la columna PersonID, se crea la tabla usando la siguiente sintaxis:

CREATE TABLE dbo.Personas

(
PersonID smallint PRIMARY KEY NONCLUSTERED,
Nombre varchar(39),
Apellido varchar(40),
NumDocumento char(11) UNIQUE CLUSTERED
)

Los índices no se limitan a las restricciones. Se pueden crear índices sobre cualquier columna o combinación
de columnas en una tabla o vista. Índices agrupados aseguran la unicidad internamente. Por lo que, si se
crea un índice agrupado sobre columnas con valores no únicos SQL Server crea un único valor sobre las
columnas duplicadas para servir de clave de ordenamiento secundaria. Para evitar el trabajo adicional
requerido para mantener valores únicos sobre columnas duplicadas, generalmente se generan índices
agrupados sobre columnas con la restricción PRIMARY KEY.

Índices no agrupados
Sobre una tabla o vista se pueden crear 250 índice no agrupados o 249 índices no agrupados y un índice
agrupado. Se debe primero crear un índice único agrupado sobre una vista previo a crear los índices no
agrupados. Esta restricción no se aplica a las tablas. Un índice no agrupado es análogo a un índice al final de
un libro. Se puede usar el índice del libro para ubicar las páginas que contienen una tema del índice del libro.
La base de datos usa los índices no agrupados para encontrar registros según una clave.

Si no existe un índices agrupado para la tabla, los datos de la tabla se encontrarán desordenados físicamente
y se dice que la tabla tendrá la estructura de montón (heap). Un índice no agrupado sobre una tabla montón
contiene punteros a las filas de la tabla. Cada entrada en las páginas de índice contiene un identificador de
fila (RID, row ID). El RID es un puntero a una fila en un montón, y este consiste de un número de página, un
número de archivo y un número de ranura. Si existe un índice agrupado, las páginas de un índice no
agrupado contienen las claves del índice agrupado en vez del RID.

Características de los índices

Una serie de características se pueden definir para los índices, además de si son o no agrupados, siendo las
mas importantes:

 Unicidad o no de los registros según la clave del índice.

 Índices compuestos, formados por varias columnas.

 Con un factor de llenado para permitir que las páginas crezcan como sea necesario.

 Con un sentido de ordenamiento que especifique si será ascendente o descendente.

Con algunas limitaciones se pueden establecer índices sobre columnas computadas.

Unicidad

Cuando un índice es definido como UNIQUE, la clave del índice y sus correspondientes valores de la clave
serán únicos. Un índice UNIQUE puede ser aplicado a cualquier columna si todos los valores de la columna
son únicos. Un índice UNIQUE se puede definir sobre un conjunto de columnas mediante un índice
compuesto. Por ejemplo , un índice UNIQUE puede ser definido sobre las columnas Apellido y
NumDocumento, ninguna de ambas columnas deberá tener valores nulos y las combinaciones de los valores
de ambas columnas para los registros deberán ser únicas.

SQL Server automáticamente crea un índice UNIQUE para una columna o columnas definidas con las
restricciones PRIMARY KEY o UNIQUE. Por lo tanto, utilice solo las restricciones para forzar unicidad en vez
de aplicar la característica UNIQUE al índice. SQL Server no permite crear un índice UNIQUE sobre una
columna que contenga valores de la clave repetidos.

Índices compuestos

Un índice compuesto es cualquier índice que use mas de una columna como clave. Los índices compuesto
pueden mejorar el rendimiento de las consultas al reducir el número de operaciones de entrada/salida,
porque una consulta sobre una combinación de columnas contenidas en el índice será ubicada
completamente en el índice. Cuando el resultado de una consulta se obtiene completamente desde el índice
sin tener que consultar a los registros de la tabla , se dice que hay un recubrimiento de índice, esto tiene
como resultado una extracción mas rápida de los datos, ya que solo se consultan las páginas del índice. Esto
se produce cuando todas las columnas indicadas en las cláusulas SELECT y WHERE se encuentran dentro de
la clave del índice o dentro de la clave del índice agrupado (si este existe). Recuerde que los valores de la
clave del índice agrupado se encuentran también en las páginas de los índice no agrupados para poder
encontrar los registros en la tabla.

Suponga que se ejecuta la siguiente consulta:

SELECT Emp_ID, Apel, NivelTrabajo
FROM Empleados01
WHERE Fecha_ingreso < (GETDATE() – 30)
AND NivelTrabajo >= 100
ORDER BY NivelTrabajo

Si existe un índice agrupado sobre la columna Emp_ID y un índice no agrupado sobre las columnas Apel,
NivelTrabajo y Fecha_Ingreso, luego habrá un recubrimiento de índice por parte del índice no agrupado, ya
que contiene todas las columnas usadas en la consulta, por su propia clave y por tener indicados los registros
a través de la clave del índice agrupado.

Factor de llenado

Cuando se inserta una fila en una tabla,SQL Server debe dispones de cierto espacio para ello. Un operación
de inserción ocurre cuando se ejecuta un comando INSERT o cuando se ejecuta un comando UPDATE para
actualizar una clave de un índice agrupado. Si la tabla no contiene un índice agrupado, el registro y la página
del índice son colocados en cualquier espacio disponible en el montón. Si la tabla contiene un índice
agrupado, SQL Server ubica el la página apropiada del índice dentro del B-tree y luego inserta el registro en
el orden correspondiente. Si la página del índice se encuentra llena, esta es dividida (mitad de la página
permanece en la página original y la otra mitad se mueve a una nueva página). Si la fila insertada es muy
grande, podrían ser necesarias divisiones adicionales. Las divisiones de páginas son complejas e insumen
recursos de manera intensiva. La divisiones de páginas mas comunes suceden en el nivel de las páginas
hoja. Para reducir la ocurrencia de las divisiones de páginas se especifica cuánto se llenarán las páginas
cuando se crea el índice. Este valor es llamado factor de llenado . Por defecto el factor de llenado vale cero,
esto es que las páginas del índice serán llenadas cuando el índice se crea sobre datos existente. Un factor de
llenado de cero es lo mismo que un factor de llenado de 100. Se puede definir un valor global por defecto del
factor de llenado utilizando el procedimiento almacenado sp_configure o asignarlo para un índice específico
con la cláusula FILLFACTOR.

Sentido de ordenamiento

Cuando se crea un índice, este es ordenado de manera ascendente. Tanto los índices agrupados como los no-
agrupados se ordenan, el índice agrupado representa el sentido de ordenamiento de la tabla. Considere el
siguiente comando SELECT:

SELECT Emp_ID, Apel, NivelTrabajo

FROM Empleados01
WHERE Fecha_ingreso < (GETDATE() – 30)
AND NivelTrabajo >= 100

Fíjese, que no hay un sentido de ordenamiento especificado. Ya vimos que el Query Optimizer usa una índice
compuesto para devolver un resultado para esta consulta. El índice compuesto es un índice no agrupado, y la
primera columna es Apel. Supongamos que cuando se creó el índice no estableció tampoco un sentido de
ordenamiento, por lo que el resultado es mostrado en orden ascendente comenzando con la columna Apel. La
cláusula ORDER BY no ha sido indicada, para ahorrar recursos. Pero el resultado aparece ordenado por el
apellido. El sentido de ordenamiento depende del incide utilizado para resolver la consulta (si no se especifica
la cláusula ORDER BY o si no se indica explícitamente que índice utilizar). Si el Query Optimizer usa un índice
agrupado para resolver la consulta, el resultado aparecerá en el orden establecido por ese índice, el cual es
equivalente a las páginas de datos de la tabla. El siguiente comando Trnsact-SQL usa el índice agrupado
sobre la columna Emp_ID para devolver un resultado en orden ascendente.

SELECT Emp_ID, Apel, Nombre FROM Empleados01

Información sobre índices

Para ver los índice y sus propiedades se pueden utilizar procedimientos almacenados del sistema, el Object
Browser en el Query Analizer, o el Enterprise Manager. Conocer los índices aplicados a una tabla o vista
ayuda a optimizar las consultas. Se puede analizar índices para diseñar comandos SELECT que retornen los
resultados de manera eficiente., o se pueden crear nuevos índices para mejorar las consultas. Para ver los
índices aplicados a una tabla o vista se puede utilizar los procedimientos almacenados del sistema sp_help
sp_helpindex. Los siguientes comandos Transact-SQL muestra todos los índices creados para la tabla
Empleados01

sp_helpindex Empleados01

El resultado que se retorna del sp_helpindex incluye el nombre del índice, el tipo de índice, el archivo de base
de datos, y la o las columnas contenidas por el índice.

El Object Browser del Query Analizer provee similar información. En el Object Browser, expanda un nodo
tabla y luego expanda el nodo Indexes. Luego, clic derecho sobre un índice en particular y seleccione Edit
para mostrar la ventana de diálogo Edit Existing Index como se verá mas adelante.

Se pueden ver las propiedades de un índice y acceder al cuadro de diálogo Edit Existing Index desde un plan
de ejecución. Clic derecho sobre un índice que aparezca en la pestaña del Execution Plan y seleccione
Manage Indexes. Hecho esto se muestra el cuadro de diálogo Manage Index. Desde aquí se puede presionar
el botón Edit para mostrar el cuadro de diálogo Edit Existing Index. El cuadro de diálogo Manage Indexes
esta también disponible en el Enterprise Manager. Primero ubique el nodo Tables para la base de datos en la
consola del árbol. En el panel Details, clic derecho sobre una tabla, apuntar a All Task y por último clic en
Manage Indexes. Se puede modificar, crear y borrar índices desde el cuadro de diálogo Manage Indexes, tal
como veremos mas adelante.

Para ver todos los índices asignados en una base de datos, se puede consultar la tabla del sistema
sysindexes en la base de datos. Por ejemplo, para consultar información sobre índices seleccionados en la
base de datos Pubs, se ejecuta el siguiente código Transact-SQL:

USE Pubs
GO
SELECT name, rows, rowcnt, keycnt from sysindexes
WHERE name NOT LIKE ‘%sys%’
ORDER BY keycnt

Indexado Full-Text

El indexado Full-Text no es parte de las funciones de indexado descripta hasta ahora, pero se debe entender
como este difiere del indexado provisto por el sistema SQL Server. UN índice Full-Text permite realizar
consultas a texto completo para buscar datos en forma de cadenas de caracteres en la base de datos. Un
índice Full-Text se guarda en un catálogo Full-Text. El motor Microsoft Search, no SQL Server, mantiene los
índices y catálogos Full-Text.

Crear y administrar índices

Crear índices

Hay varios modos de crear un índice en SQL Server. Se puede crear una aplicación propia que use la
interfase SQL-DMO para crear un índice. Como se vio se puede usar la opción Manage Indexes desde el
Object Browser o accederlo desde un plan de ejecución en el Query Analizer. La opción Manage Indexes está
también disponible desde el menú contextual de una tabla o vista en el Enterprise Manager. El Enterprise
Manager ofrece además el asistente Create Index para crear índices paso a paso. Otro modo es crear un
índice para una tabla utilizando el comando Transact-SQL CREATE INDEX. Por último, se pueden especificar
las propiedades de una restricción de clave primaria o de una restricción de clave única durante la creación
(CREATE TABÑE9 o modificación (ALTER TABLE) de una tabla.

Usando interfase gráfica

Desde el cuadro de diálogo Manage Indexes, clic el botón New para crear un índice y se muestra el cuadro de
diálogo para acceder al cuadro de diálogo Create New Index como se muestra en la figura

Figura 1: El cuadro de diálogo Create New Index para la tabla Productos de la base de datos Northwind.

Desde el cuadro de diálogo Create New Index, se puede proveer de un nombre al índice, el tipo de índice
(agrupado o no agrupado), y de las propiedades del índice (unicidad, factor de llenado, el grupo de archivos
donde el índice deberá ser creado, etc.). Se puede además cambiar el orden de las columnas que son parte
de una clave compuesta, seleccionando la columna y con clic en los botones Up y Down. La columna que está
primera en la lista de columnas seleccionadas determinará el primer ordenamiento de la clave del índice.
Fíjese que se puede especificar el orden descendiente para cualquier parte del índice. El Query Optimizer
seleccionará el índice Productos que aparece en la figura cuando se ejecute el siguiente comando:

SELECT proveedorID, PrecioUnitario, NombreProducto

FROM Productos

El resultado muestra el ProveedorID en orden ascendente, seguido por el PrecioUnitario en orden

descendiente. El índice ordena NombreProducto en orden ascendente, pero ese orden no aparece en el
resultado porque ProveedorID y PrecioUnitario prevalecen al orden de la columna NombreProducto. Se
muestran a continuación algunos registros del resultado para ilustrar este tema:

ProductoID PrecioUnitario NombreProducto

1 19.0000 Chang
1 18.0000 Chai
1 10.0000 Aniseed Syrup
2 22.0000 Chef Anton's Cajun Seasoning
2 21.3500 Chef Anton's Gumbo Mix
2 21.0500 Louisiana Fiery Hot Pepper Sauce
2 17.0000 Louisiana Hot Spiced Okra
3 40.0000 Northwoods Cranberry Sauce
 ProductoID PrecioUnitario NombreProducto
3 30.0000 Uncle Bob's Organic Dried Pears

Si se prefiere mas ayuda para crear índices se puede usar el asistente Create Index en el Enterprise
Manager. El asistente Create Index está disponible en la opción Wizards del menú Tools. Haciendo clic en la
opción Wizards se muestra el cuadro Select Dialog. En el cuadro Select Dialog, expanda Database, seleccione
el asistente Create Index, y clic en Ok para comenzar el asistente. El asistente habilita para ver los índices ya
creados sobre una tabla o vista y para crear nuevos índices seleccionando la columna (o columnas) que
deberían ser parte del índice, pudiendo además configurar las propiedades del índice.

Usar comandos Transact-SQL

Los comandos CREATE INDEX, CREATE TABLE y ALTER TABLE participan en la creación de los índices. Se
puede crear un índice usando estos comandos Transact-SQL a través del Query Analizer o con una
herramienta tal como osql.

Cuando se utiliza CREATE INDEX, se debe especificar el nombre del índice, la tabla o la vista, y la olas
columnas sobre las que se aplicará el índice. Opcionalmente, se puede especificar si el índice deberá contener
sólo valores no duplicados, el tipo de índice (agrupado o no), el sentido de ordenamiento para cada columna,
propiedades del índice, y el grupo de archivos que lo contendrá. La configuración por defecto es la siguiente:

 Se crean índices no agrupados

 Se ordenan todas las columnas en un sentido descendente y se usa la base de datos actual para
ordenar el índice.

 Se usan las configuraciones globales del SQL Server para fijar el factor de llenado.

 Se crean todos los ordenamientos resultantes durante ela creación del índice en el grupo de archivos
por defecto

 Actualiza estadísticas del índice

 Deshace un proceso de múltiples inserciones si la condición de unicidad del índice es violada por
alguno de los registros que están siendo ingresados.

 Previene de ser sobrescrito a los índices existentes.-

Las principales cláusulas en un comando CREATE INDEX son resumidas como sigue:

CREATE
[UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX
nombre_indice
ON [nombre_tabla | nombre_vista] (nombre_columna [,...n])
[WITH [propiedad_indice [,...n] ]
[ON grupo_archivos ]

Ya hemos aprendido el significado de esta cláusulas, cuales son opcionales y que configuraciones por defecto
existen para cualquier cláusula no especificada en el comando CREATE INDEX. Resumiendo, las cláusulas
UNIQUE y CLUSTERED o NONCLUSTERED son opcionales. Es también opcional el especificar las propiedades
del índice a través de la cláusula WITH y especificar el grupo de archivos donde el índice será creado usando
la cláusula ON.

El siguiente comando CREATE INDEX usa las configuraciones por defecto para todas las cláusulas opcionales:

CREATE INDEX Indice01 ON Tabla01(Columna01)

Un índice llamado Indice01 se crea sobre Tabla01. La clave del índice para la tabla será Columna01. El índice
no tiene unicidad y no es agrupado. Todas las propiedades concuerdan con los valores por defecto de las
base de datos.

El uso de cláusulas opcionales personaliza el comando CREATE INDEX siguiente:

CREATE UNIQUE CLUSTERED INDEX Indice01

ON Tabla01(Columna01, Columna03, DESC)
WITH FILLFACTOR = 60
IGNORE_DUP_KEY, DROP_EXISTING,
SORT_IN_TEMPDB

Un índice llamado Indice01 reemplazará al índice existente del mismo nombre creado sobre la tabla Tabla01.
La cláusula DROP_EXISTING indica que el índice Indice01 debe ser reemplazado. La clave del índice incluye a
las columnas Columna01 y Columna03, haciendo de Indice01 un índice compuesto. La cláusula DESC
configura el sentido de ordenación para la Columna03 como descendente (en vez de ascendente). La
cláusula FILLFACTOR establece que las páginas de nivel hoja del índice estén llenas en un 40% al crearse el
índice, dejando libre un 60% del espacio para contener entradas adicionales. Las cláusulas CLUSTERED y
UNIQUE configuran al índice como agrupado y sin valores duplicados; por lo que la tabla será físicamente
ordenada por la clave del índice y los valores de la clave serán únicos. La palabra IGNORE_DUP_KEY habilita
para que un proceso por lotes que contenga múltiple comandos INSERT sea exitoso al ignorar cualquier
INSERT que viole el requerimiento de unicidad.. La palabra SORT_IN_TEMDB indica al índice que efectúe las
operaciones de ordenamientos intermedios en TempDB. Esta cláusula se usa típicamente para mejorar la
velocidad a la que se crea o reconstruye un índice grande o para disminuir la fragmentación del índice. Dado
que una segunda cláusula ON no se ha puesto el índice será creado en el grupo de archivos por defecto de la
base de datos.

Crear una restricción PRIMARY KEY o UNIQUE automáticamente crea un índice. Como se vio, estas
restricciones se definen cuando se crea o modifica una tabla. Los comandos CREATE TABLE y ALTER TABLE
incluyen configuraciones para los índices por lo que se puede personalizar a los índices que se crean con
estas restricciones.

Las principales cláusulas en el comando CREATE TABLE que se relacionan con la creación de índices son:

CREATE TABLE nombre_tabla

( nombre_columna tipo_dato
CONSTRAINT nombre_restriccion
[PRIMARY KEY | UNIQUE]
[CLUSTERED | NONCLUSTERED]
[WITH FILLFACTOR = factor_llenado]
[ON grupo_archivo] )

una restricción e clave primaria esta siempre configurada NOT NULL. Se puede especificar NOT NULL pero
está implícita en la definición de la restricción PRIMARY KEY. El siguiente comando CREATE TABLE usa
configuraciones por defecto en la definición de una restricción PRIMARY KEY cuando crea una tabla con
restricción de clave principal.

CREATE TABLE Tabla01 (Columna01 int

CONSTRAINT pk_columna01
PRIMARY KEY)

Una tabla llamada Tabla01 es creada con una sola columna llamada Columna01. la cláusula PRIMARY KEY
define a Columna01 con una restricción de clave principal llamada pk_columna01, que es un índice agrupado
con valores únicos de clave por defecto.

El uso de cláusulas opcionales para la creación de índices personaliza el siguiente comando CREATE TABLE:
CREATE TABLE Tabla01 (Columna01 int
CONSTRAINT pk_columna01
PRIMARY KEY
WITH FILLFACTOR = 50
ON SECONDARY)

La sintaxis de ALTER TABLE para crear o modificar restricciones PRIMARY KEY o UNIQUE es similar a la del
comando CREATE TABLE. En el comando ALTER TABLE, s debe especificar si se está modificando, agregando
o eliminando una restricción. Por ejemplo, el siguiente comando ALTER TABLE agrega una columna una
restricción UNIQUE para la tabla Tabla01:

ALTER TABLE tabla01 ADD Columna02 int

CONSTRAINT uk_columna02
UNIQUE

La restricción de unicidad se llama uk_columna02 y es un índice no agrupado. Una restricción de unicidad

crea un índice no agrupado salvo que se especifique la cláusula CLUSTERED y que no exista previamente un
ningún índice agrupado.

Administrar índices

Las tareas de mantenimiento de índices incluyen reconstrucción, eliminación, y renombrado. Un índice se

elimina si no se lo va a utilizar más o si esta corrupto. Se reconstruye para la mantener un factor de llenado
personalizado o para reorganizar el almacenamiento de los datos del índice para eliminar su fragmentación.
Los índices se renombran si cambió la convención de nombres adoptada o si existen índices que no respetan
la convención de nombres.

Eliminar un índice

Los índices en desuso de tablas que son frecuentemente actualizadas con nueva información deberían ser
removidos. En caso contrario, SQL Server desperdiciaría recursos en mantener índices en desuso. Use la
siguiente sintaxis para eliminar un índice:

DROP INDEX nombre_tabla.nombre_indice | nombre_vista.nombre_indice

El nombre de la tabla o de la vista debe ser incluido en el comando DROP INDEX. Se pueden eliminar varios
índices con un solo comando DROP INDEX. El siguiente comando borra un índice de una tabla y uno de una
vista:

DROP INDEX Tabla01.Indice01, Vista01.Indice02

Se puede eliminar un índice usando el Object Browser en el Query Analizer o utilizando el Entreprise
Manager.

Reconstruir un índice

Si existe un índice agrupado sobre una tabla o una vista, cualquier índice no agrupado sobre la misma tabla o
vista usará el índice agrupado y su clave. Si se elimina el índice agrupado utilizando el comando DROP INDEX
se provocará que todos los índices no agrupados sean reconstruidos para que utilicen el RID (en vez de la
clave del índice). Si un índice agrupado se recrea usando el comando CRETE INDEX provoca que todos los
índices no agrupados sean reconstruidos utilizando para acceder a cada registro la clave del nuevo índice
agrupado en vez del RID. Para tablas o vista grandes con varios índices, este proceso de reconstrucción
puede consumir bastantes recursos. Afortunadamente existen otros recursos para reconstruir un índice que
eliminarlo y volverlo a crear. Utilizando el comando DBCC DBREINDEX o especificando la cláusula
DROP_EXISTING en el comando CREATE TABLE.

El comando DBCC DBREINDEX reconstruye, a través de un solo comando, uno o más índices sobre una tabla
o vista. Esta capacidad evita tener que utilizar múltiples comandos DROP INDEX y CREATE INDEX para
reconstruir múltiples índices. Para reconstruir todos los índices, utilice el comando DBCC DBREINDEX para
reconstruir el índice agrupado y por lo tanto, se procederá a la reconstrucción de todos los índices en la tabla
o vista. Si se usa el comando DBCC DBREINDEX sin indicar ningún índice se reconstruirán todos los índices
de la tabla o vista. El comando DBCC DBREINDEX es especialmente útil para índices creados por las
restricciones de clave primaria y de unicidad, porque a diferencia de DROP INDEX, no es necesario borrar la
restricción antes de reconstruir el índice. Por ejemplo, el siguiente comando fallará al borrar un índice sobre
una restricción de clave primaria llamada pk_Columna01:

DROP INDEX Tabla01.pk_columna01

Sin embargo, el siguiente comando DBCC DBREINDEX reconstruirá el índice para la restricción de clave
primaria:

DBCC DBREINDEX (Tabla01.pk_columna01, 60)

El índice pk_columna01 soblre la restricción de clave primaria pk_columna01 es reconstruido con un factor de
llenado del 60 por ciento. DBCC DBREINDEX es comúnmente utilizado para reestablecer la configuración del
factor de llenado sobre los índices a fin de bajar la frecuencia de división de las páginas del índice.

La cláusula DROP_EXISTING de un comando CREATE INDEX reemplaza un índice con el mismo nombre de
una tabla o vista. Como resultado, el índice es reconstruido, la cláusula DROP_EXISTING provee de mayor
eficiencia al proceso de reconstrucción del índice, mas que DBCC DBREINDEX,. Si se utiliza el comando
CREATE INDEX con la cláusula DROP_EXISTING para reemplazar un índice agrupado con idéntica clave de
índice, los índices no agrupados no son reconstruidos y la tabla no es reordenada. Si se cambia la clave del
índice agrupado los índices no agrupados son reconstruidos y la tabla reordenada.

Renombrar un índice

Se puede renombrar un índice eliminándolo y recreándolo. Una forma mas simple de renombrar un índice, sin
embargo, es usar el procedimiento almacenado del sistema sp_rename. El siguiente ejemplo muestra como
renombrar un índice llamado indice01 por indice02.

sp_rename @objname = ‘Tabla01.indice01’ , @newname = ‘indice02’,

@objtype = ‘INDEX’

El nombre de la tabla fue incluido en el parámetro de entrada @objname. Si no se indica el nombre de la

tabla en dicho parámetro, el procedimiento almacenado no podría encontrar al índice para renombrarlo. Sin
embargo, el nombre de la tabla fue intencionalmente excluido del parámetro @newname, ya que si se lo
incluyera el nuevo nombre del índice incluiría el nombre de la tabla. Por ejemplo, si se especifica @newname
= ‘Tabla01.indice02’ el índice se llamaría Tabla01.indice02 en vez de indice02. El nombre de la tabla es
innecesario en el parámetro @newname porque lo toma de parámetro @objname. El parámetro de entrada
@objtype debe ser configurado como ‘INDEX’ o el procedimiento almacenado será incapaz de ubicar el tipo
de objeto correcto a ser renombrado.

Elegir un índice

Esta sección provee lineamientos adicionales para determinar cuando crear un índice y decidir que
propiedades del índice configurar para un óptimo rendimiento. Tenga en cuenta que solamente un índice
agrupado es permitido por tabla o vista. Por lo que un diseño cuidadoso del índice no agrupado será mas
importante que el diseño de los índices no agrupados.

Se crean índices de acuerdo a los tipos de consultas que los usuarios comúnmente ejecutan contra la base de
datos. El Query Optimizer luego selecciona uno o mas índices para realizar la consulta. Los siguientes tipos
de consultas, separadas o en combinación se benefician de los índices:

Índices agrupados
Puesto que los datos están ordenados físicamente según una clave agrupada, realizar búsquedas mediante
un índice agrupado es casi siempre más rápidos que realizarlas mediante un índice no agrupado. Puesto que
sólo se permite crear un índice agrupado por tabla, selecciones dicho índice de manera juiciosa. Las
siguientes reglas le ayudarán a determinar cuándo elegir un índice agrupado:

 Columnas en las que el índice tenga pocos valores distintos. Puesto que los datos están físicamente
ordenados, todos los valores duplicados se mantienen agrupados. Cualquier consulta que trate de
extraer registros con tales claves encontrará todos los valores con un número mínimo de operaciones
de E/S.

 Columnas que suelan ser especificadas en la cláusula ORDER BY. Puesto que los datos ya están
ordenados, SQL Server no tiene que volverlos a ordenar.

 Columnas en las que se suelan realizar búsquedas de rangos de valores. Puesto que la página hoja de
un índice agrupado es, en realidad una página de datos, los punteros de un índice agrupado hacen
referencia a las páginas en las que los datos residen. SQL Server puede usar este índice para localizar
las páginas inicial y final del rango especificado, lo que permite una más rápida exploración del rango.

 Columnas que sean usadas más frecuentemente en la cláusula JOIN.

 Consultas que puedan devolver grandes conjuntos de resultados con valores de clave adyacentes.

Índices no agrupados

Recuerde siempre que, a medida que añada mas índices al sistema, las instrucciones de modificación de
datos se harán mas lentas.

Las siguientes reglas le ayudarán a elegir el índice no agrupado correcto para su entorno:

 Columnas que tengan un gran número de valores diferentes o consultas que devuelvan conjuntos de
resultados pequeños. Puesto que las páginas hojas de un índice no agrupado contienen punteros al
identificador de la fila de la página de datos. SQL Server puede utilizar un índice no agrupado para
acceder de forma bastante eficiente a los registro individuales.

 Consultas que empleen columnas indexadas en las cláusulas WHERE y ORDER BY Si el Query
Optimizer selecciona un índice no agrupado, el orden de los valores de clave en el árbol binario será el
mismo que las columnas especificadas en la cláusula ORDER BY. En tales casos, SQL Server puede
prescindir de crear una tabla de trabajo temporal interna para realizar la ordenación de los datos. La
siguiente consulta es un ejemplo de situación en la que SQL Server evita el paso adicional de crear
una tabla de trabajo para una ordenación:

SELECT * FROM Autores WHERE Estado LIKE “c%”

ORDER BY Estado

Recubrimiento de índice

El recubrimiento de índice es una situación en que todas las columnas de las cláusulas SELECT y WHERE de
la consulta forman también parte del índice no agrupado o de la clave del índice agrupado (si es que existe).
Esto tiene como resultado una consulta mucho más rápida porque toda la información puede provenir
directamente de la página índice y SQL Server evita realizar accesos a las páginas de datos. El siguiente
ejemplo tiene n índice no agrupado sobre las columnas Autor_Apellido y Autor_Nombre de la tabla Autores

SELECT Autor_Apellido, Autor_Nombre

FROM Autores
WHERE Autor_Apellido LIKE ‘M%’
Mucha otras consultas que utilicen una cláusula de agregación (como MIN, MAX, AVG, etc) o que
comprueben la existencia de un criterio también se benefician del recubrimiento de índice. La consulta
siguiente es un ejemoplo de recubrimiento de índice mediante agregados:

SELECT COUNT(Autor_Apellido) FROM Autores WHERE Autor_Apellido LILE ‘M%’

Índices compuesto frente a índices múltiples

A medida que la clave se hace más ancha, la selectividad de la misma se hace también mejor. Pudiera
parecer, por tanto, que crear índices anchos da como resultado un mejor rendimiento, pero eso no es cierto
de manera general. La razón es que, cuanto más ancha sea la clave, menos filas puede almacenar SQL
Server en la páginas de índice, haciendo que haya un mayor número de niveles de árbol binario; como
consecuencia, para llegar a una fila específica. SQL Server debe realizar más operaciones de E/S. Para
obtener un mejor rendimiento de las consultas, cree múltiples índices estrechos, en lugar de unos pocos
anchos. La ventaja es que con claves más pequeñas, el optimizador puede explorar rápidamente múltiples
índices para crear el plan de acceso más eficiente. Asimismo, al disponer de más índices, el optimizador
puede elegir entre varias alternativas. Si está tratando de determinar si usar una clave ancha, compruebe la
distribución individual de cada miembro de la clave compuesta. Para ello utilice el valor de la selectividad que
es el cociente entre la cantidad de registros distintos de la clave sobre el total de registros de la tabla y
configura la inversa de la densidad de la clave Si la selectividad de la columnas individuales es muy buena
(mayor al 70%), considere partir el índice en múltiples índices. Si la selectividad de las columnas individuales
es mala, pero es buena para las columnas combinadas, tiene sentido disponer claves más anchas en una
tabla. Para obtener la combinación correcta, llene la tabla con datos tomados del mundo real, experimente
creando múltiples índices y compruebe la distribución de cada columna. Basándose en los pasos de
distribución y en la densidad de índice podrá tomar la decisión que mejor funcione para su entorno.

MODULO III: Implementar una base de datos y sus tablas

TEMA 1: Principios del álgebra relacional

Un panorama general del álgebra:

El álgebra relacional consiste en un conjunto de operadores de alto nivel que operan sobre relaciones. Cada
uno de estos operadores toma una o dos relaciones como entrada y produce una nueva relación como salida.
Desde luego, sería posible en principio definir cualquier cantidad de operadores que se ajustaran a esta
sencilla definición (ya sea una o dos relaciones como entrada, otra relación como salida) No obstante, Codd
definió un conjunto muy especifico de ocho operadores de este tipo, en dos grupos de cuatro cada uno:

1. las operaciones tradicionales de conjuntos unión, intersección, diferencia y producto cartesiano (todas ellas
con ligeras modificaciones debidas al hecho de tener relaciones como operandos, y no conjuntos arbitrarios,
después de todo, una relación es un tipo especial de conjunto) y,
2. las operaciones relacionales especiales restricción, proyección, reunión y división.

Por añadidura, Codd tenia un claro objetivo cuando definió precisamente estos ocho operadores, y lo
analizaremos en el siguiente capitulo. Pero el lector debe entender que sin duda es posible definir operadores
adicionales de naturaleza algebraica, y en efecto muchos de ellos han sido propuestos por distintos autores.
En este capitulo analizaremos primero los operadores originales de Codd (o al menos nuestra versión de esos
operadores), y los utilizaremos como base para el análisis de varios conceptos algebraicos, en seguida
consideraremos cómo podría ser conveniente ampliar el conjunto original de Codd.
Los ocho operadores originales se representan en forma simbólica en la figura
A grandes rasgos, funcionan como sigue:

Restricción: Extrae las tuplas especificadas de una relación dada (o sea, restringe la relación sólo a las
tuplas que satisfagan una condición especificada.
Proyección: Extrae los atributos especificados de una relación dada.

Producto: A partir de dos relaciones especificadas, construye una relación que contiene todas las
combinaciones posibles de tuplas, una de cada una de las dos relaciones.

Unión: Construye una relación formada por todas las tuplas que aparecen en cualquiera de las dos relaciones
especificadas.

Intersección: Construye una relación formada por aquellas tuplas que aparezcan en las dos relaciones
especificadas.

Diferencia: Construye una relación formada por todas las tuplas de la primera relación que no aparezcan en
la segunda de las dos relaciones especificadas.

Reunión: A partir de dos relaciones especificadas, construye una relación que contiene todas las posibles
combinaciones de tuplas, una de cada una de las dos relaciones, tales que las dos tuplas participantes en una
combinación dada satisfagan alguna condición especificada.

División: Toma dos relaciones, una binaria y una unaria, y construye una relación formada por todos los
valores de un atributo de la relación binaria que concuerdan (en el otro atributo) con todos los valores en la
relación unaria.
Figura 1: Los ocho operadores originales (panorama general)
Adviértase que el resultado de cada una de las operaciones es (por supuesto) otra relación. Esta es la
importantísima propiedad de cerradura. En esencia, dado que el resultado de cualquier operación es un
objeto del mismo tipo que los operandos, todos son relaciones, el resultado de una operación puede
convertirse en operando de otra. Así pues, es posible (por ejemplo) sacar la proyección de una unión, o una
reunión de dos restricciones, o la diferencia de una unión y una intersección, etc. Dicho de otro modo, es
posible escribir expresiones relacionales anidadas, es decir, expresiones en las cuales los operandos mismos
están representados mediante expresiones, y no sólo mediante nombres. Veremos muchos ejemplos de tales
operaciones anidadas mas adelante en este tema.

Nota:
Existe una analogía obvia entre la capacidad de anidar expresiones algebraicas en álgebra relacional y la
capacidad de anidar expresiones aritméticas en aritmética ordinaria. En efecto el hecho de que las relaciones
estén cerradas en el álgebra es importante exactamente por las mismas razones por las que es importante el
hecho de que los números estén cerrados en la aritmética ordinaria.
Por cierto, cuando hablamos de la importancia de la cerradura y decimos que el resultado de toda operación
es otra relación, estamos hablando desde luego desde un punto de vista conceptual. No es nuestra intención
sugerir que el sistema debe siempre materializar en su totalidad el resultado de cada operación individual.
Vamos a suponer, por ejemplo, que estamos tratando de calcular una restricción de una reunión. Al
construirse cada tupla de la reunión, el sistema puede aplicar de inmediato la restricción a la tupla para ver si
debe incluirse en el resultado final, y desecharla en ese momento si no. En otras palabras, el resultado
intermedio producido por la reunión podría no existir nunca en si mismo como una relación materializada por
completo. De hecho, y como regla general, el sistema trata hasta donde puede de no materializar resultados
intermedios en su totalidad, por razones de desempeño obvias.

Las operaciones tradicionales de conjuntos:

Ahora examinaremos con cierto detalle las operaciones individuales del álgebra relacional original
Las operaciones tradicionales de conjuntos son unión, intersección, diferencia y producto (en términos más
precisos, producto cartesiano ampliado). Nos concentraremos primero en la unión.
En matemáticas, la unión de dos conjuntos es el conjunto de todos los elementos pertenecientes a uno de los
conjuntos originales, o a ambos. Como una relación es, en términos informales, un conjunto (de tuplas),
resulta obvio que es posible construir la unión de dos relaciones, el resultado será un conjunto formado por
todas las tuplas que aparecen en una de las relaciones originales, o en ambas. Por ejemplo, la unión del
conjunto de tuplas de proveedores en la relación S y el conjunto de tuplas de partes en la relación P será sin
duda un conjunto.
Sin embargo, aunque el resultado es un conjunto, no es una relación, las relaciones no pueden contener una
mezcla de diferentes tipos de tuplas, deben ser ¨homogéneas en sus tuplas¨. Y, desde luego, queremos que
el resultado sea una relación: deseamos conservar la propiedad de cerradura. Por tanto, la unión incluida en
el álgebra relacional no es la unión matemática completamente general, más bien, es una forma limitada de
unión, en la cual se obliga a las dos relaciones de entrada a tener lo que podríamos llamar en términos
informales ¨la misma forma¨, es decir, por ejemplo, que las dos deben contener tuplas de proveedores, o las
dos deben contener tuplas de partes, y no una mezcla. Si las dos relaciones tienen la misma forma en este
sentido, podremos obtener su unión, y el resultado será también una relación con la misma forma, en otras
palabras, se habrá conservado la propiedad de cerradura.
Un termino mas preciso para el concepto ¨la misma forma¨ es compatibilidad respecto a la unión. Diremos
que dos relaciones son compatibles respecto a la unión si y solo si sus cabeceras son idénticas, lo cual
significa, en términos precisos que:

a. las dos tienen el mismo conjunto de nombres atributos (adviértase, por tanto, que deben tener por fuerza
el mismo grado), y
b. los atributos correspondientes (es decir, los atributos con el mismo nombre en las dos relaciones) se
definen sobre el mismo dominio.

La unión, la intersección y la diferencia requieren todas operandos compatibles respecto a la unión (se
aplican argumentos análogos a los presentados en el caso de la unión, también a la intersección y a la
diferencia). El producto cartesiano, en cambio, no tiene este requerimiento (aunque si tiene otro
requerimiento distinto).

· Unión

La unión de dos relaciones A y B compatibles respecto a la unión, A UNION B, es una relación cuya cabecera
es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes ya sea a A o a B (o
a las dos)
Ejemplo: sean A y B las relaciones presentadas en la figura (A contiene en términos intuitivos, los
proveedores de Londres y B contiene los proveedores que suministran la parte P1). Entonces A UNION B,
véase la parte (a) de la figura, consistirá en los proveedores que o bien están situados en Londres, o que
suministran la parte P1 (o las dos cosas). Adviértase que el resultado tiene tres tuplas, no cuatro (se
eliminan las tuplas repetidas).

Relaciones base

A S# SNOMBRE SITUACION CIUDAD B S# SNOMBRE SITUACION CIUDAD

S1 Salazar 20 Londres S1 Salazar 20 Londres
S4 Corona 20 Londres S2 Jaime 10 Paris.

Unión (A UNION B)

S# SNOMBRE SITUACION CIUDAD

S1 Salzar 20 Londres
S4 Corona 20 Londres
S2 Jaimes 10 Paris

Interseccion (A INTERSECT B)

S# SNOMBRE SITUACION CIUDAD

S1 Salazar 20 Londres

Diferencia (A MINUS B)

S# SNOMBRE SITUACION CIUDAD S# SNOMBRE SITUACION CIUDAD

S4 Corona 20 Londres S2 Jaimes 10 Paris.

Figura 2: Ejemplos de unión, intersección y diferencia.

· Intersección

La intersección de dos relaciones compatibles respecto a la unión A y B, A INTERSECT B, es una relación cuya
cabecera es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes tanto a A
como a B.
Ejemplo: Una vez más, sean A y B las relaciones presentadas en la figura Entonces A INTERSECT B, véase la
parte B de la figura, consistirá en los proveedores situados en Londres, y que suministran la parte P1.

· Diferencia

La diferencia entre dos relaciones compatibles respecto a la unión A y B, A MINUS B, es una relación cuya
cabecera es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes a A pero
no a B.
Ejemplo: Sean A y B las relaciones presentadas en la figura. Entonces A MINUS B contendrá los proveedores
situados en Londres que no suministran la parte P1, y B MINUS A incluirá los proveedores que suministran la
parte P1 y no están situados en Londres. Adviértase que MINUS tiene cierta direccionalidad, como la tiene la
resta en aritmética ordinaria (por ejemplo, ¨5 - 2¨ y ¨2-5¨ son diferentes en aritmética).
· Producto cartesiano ampliado.

En matemáticas, el producto cartesiano de dos conjuntos es el conjunto de todos los pares ordenados de
elementos tales que el primer elemento de cada par pertenece al primer conjunto y el segundo elemento de
cada par pertenece al segundo conjunto. Así, el producto cartesiano de dos relaciones sería un conjunto de
pares ordenados de tuplas. Pero (una vez más) deseamos conservar la propiedad de cerradura, en otras
palabras, deseamos un resultado compuesto de tuplas, no de pares ordenados de tuplas (aquí también
empleamos términos un poco informales). Por tanto, la versión del producto cartesiano en álgebra relacional
es una forma ampliada de la operación, en la cual cada par ordenado de tuplas es reemplazado por la tupla
resultante de la combinación de las dos tuplas en cuestión. Aquí, ¨combinacion¨ significa en esencia unión
(en el sentido de la teoría de conjuntos, no del álgebra relacional), es decir, dadas las dos tuplas

(A1:a1, A2: A2, ......., Am, am) y (B1: b1, B2: b2,......, Bn: bn)

(se muestran los nombres de atributos para hacerlas más explicitas), la combinación de las dos es la tupla
única

(A1:a1, A2: A2, ......., Am, am, B1: b1, B2: b2,......, Bn: bn)

Otro problema que surge en conexión con el producto cartesiano es la necesidad de una cabecera bien
formada para la relación resultante. Ahora bien, es evidente que la cabecera del resultado es en esencia sólo
la combinación de las dos cabeceras de las dos relaciones de entrada. Por tanto, se presentará un problema
si esas dos cabeceras tienen algún nombre de atributo en común. Así pues, si necesitamos formar el
producto cartesiano de dos relaciones cuyas cabeceras tienen nombres de atributo en común, deberemos
modificar de manera apropiada los nombres de los atributos. Entonces diremos que dos relaciones son
compatibles respecto al producto si y solo si sus cabeceras son disjuntas (es decir, no tienen nombres de
atributo en común).
Por tanto, definimos el producto cartesiano de dos relaciones (compatibles respecto al producto) A y B, A
TIMES B, como una relación cuya cabecera es la combinación de las cabeceras de A y B y cuyo cuerpo está
formado por el conjunto de todas las tuplas t tales que t es la combinación de una tupla a perteneciente a A y
una tupla b perteneciente a B.
Ejemplo: Sean A y B las relaciones presentadas en la figura (A, en términos intuitivos, consiste en todos los
números de proveedores vigentes y B en todos los números de parte vigentes) Entonces A TIMES B, véase la
parte inferior de la figura, estará formada por todas las combinaciones de números de proveedor/número de
parte vigentes.
No debemos terminar este análisis del producto cartesiano sin señalar que esta operación no tiene mucha
importancia práctica. Es decir, no es muy importante en la práctica que un sistema relacional maneje esa
operación (aunque de hecho la mayor parte de ellos lo hacen ). El producto cartesiano se incluye en el
álgebra relacional sobre todo por razones conceptuales. En particular, se verá que el producto cartesiano es
necesario como paso intermedio en la definición de la operación reunión theta¨ (y esta ultima operación si es
importante en la práctica).

Relaciones base

A S# B P#
S1 P1

S2 P2

S3 P3

S4 P4

S5 P5

P6
Producto Cartesiano (A TIMES B)

S# P#
S1 P1 S2 P1 S3 P1 S4 P1 S5 P1

S1 P2 S2 P2 S3 P2 S4 P2 S5 P2

S1 P3 S2 P3 S3 P3 S4 P3 S5 P3

S1 P4 S2 P4 S3 P4 S4 P4 S5 P4

S1 P5 S2 P5 S3 P5 S4 P5 S5 P5

S1 P6 S2 P6 S3 P6 S4 P6 S5 P6

Figura 3: Ejemplo de producto cartesiano.

Asociatividad

Es fácil comprobar que la unión es asociativa; es decir, si A,B y C son ¨proyecciones¨ arbitrarias (en el
sentido de la figura 13.2), entonces las expresiones

( A UNION B) UNION C

A UNION (B UNION C)

son equivalentes
Así, por comodidad, nos permitiremos escribir una secuencia de uniones sin insertar paréntesis, por ejemplo,
cualquiera de las dos expresiones anteriores puede simplificarse a:

A UNION B UNION C

Sin provocar ambigüedad.

Algo análogo puede decirse de la intersección y el producto (pero no de la diferencia). Señalamos también
que la unión, la intersección y el producto (pero no la diferencia) son conmutativas, es decir, las expresiones

A UNION B

B UNION A

Son equivalentes también, y lo mismo sucede con INTERSECT y TIMES.

Operaciones relacionales especiales:

Ahora nos ocuparemos de las operaciones relacionales especiales restricción, proyección, reunión (varias
clases) y división.

· Restricción
Sea theta la representación de cualquier operador de comparación escalar simple (por ejemplo =. <>, >,>=,
etc.). La restricción theta de la relación A según los atributos X y Y-

A WHERE X theta Y

Es una relación con la misma cabecera que A y con un cuerpo formado por el conjunto de todas las tuplas t
de A tales que la evaluación de la comparación ¨X theta Y¨ resulta verdadera en el caso de esa tupla t. (Los
atributos X y Y deben estar definidos sobre el mismo dominio y la operación theta debe ser aplicable a ese
dominio. Además, por supuesto, la relación A no debe ser por fuerza una relación nombrada, y puede
representarse mediante una expresión arbitraria del álgebra relacional).
Se puede especificar un valor literal en vez del atributo X o del atributo Y (o de ambos, desde luego), de
hecho, esto es lo más común en la práctica. Por ejemplo:

A WHERE X theta literal

Adviértase que el operador de restricción theta produce en realidad un subconjunto ¨horizontal¨ de una
relación dada, es decir, el subconjunto de las tuplas de la relación dada para las cuales se satisface una
comparación especificada. Nota: se acostumbra abreviar ¨restriccion theta¨ a sólo ¨restriccion¨.
La operación de restricción tal como se acaba de definir permite sólo una comparación simple en la cláusula
WHERE (donde). No obstante, es posible, en virtud de la propiedad de cerradura, ampliar la definición sin
ambigüedad a una forma en al cual la expresión arbitraria de tales comparaciones simples, según se indica
con las siguientes equivalencias:

1. A WHERE c1 AND c2

Se define como equivalente a

(A WHERE c1) INTERSECT (A WHERE c2)

2. A WHERE c1 OR c2

Se define como equivalente a

( A WHERE c1) UNION (A WHERE c2)

3. A WHERE NOT c

Se define como equivalente a

A MINUS (A WHERE c)

En adelante daremos por hecho que la expresión condicional en la cláusula WHERE de una restricción está
formada por este tipo de combinaciones booleanas arbitrarias de comparaciones simples. Una expresión
condicional como ésta (es decir, una validez en el caso de una tupla determinada puede establecerse con sólo
examinar esa tupla aislada) se conoce como condición de restricción.
En la figura 4 se presentan algunos ejemplos de restricción.

S WHERE CIUDAD = ¨Londres¨

S# SNOMBRE SITUACION CIUDAD

S1 Salazar 20 Londres

S4 Corona 20 Londres

P WHERE PESO < 14

P# PNOMBRE COLOR PESO CIUDAD
P1 Tuerca Rojo 12 Londres

P5 Leva Azul 12 Paris

SP WHERE S# = ¨S1¨
AND P# = ¨P1¨

S# P# CANTIDAD
S1 P1 300

Figura 4: Ejemplos de restricción.

· Proyección

La proyección de la relación A según los atributos X,Y,...., Z-

A (X,Y,....,Z)

Es una relación con (X,Y,..., Z) como cabecera y cuyo cuerpo está formado por el conjunto de todas las
tuplas (X:x, Y:y,...,Z:z) tales que una tupla t aparece en A con el valor X en X, el valor y en Y, ..., y el valor z
en Z. Así, el operador de proyección produce un subconjunto ¨vertical¨ de una relación dada, o sea, el
subconjunto obtenido mediante la selección de los atributos especificados y la eliminación de las tuplas
repetidas dentro de los atributos seleccionados. Desde luego, en este caso la relación A tampoco necesita ser
una relación nombrada, y puede representarse mediante una expresión arbitraria.
Nota: ningún atributo puede especificarse más de una vez en la lista de atributos de una operación de
proyección (¿por qué no?). Sin embargo, la sintaxis de la figura 13.2 si permite omitir del todo la lista de
atributos. Omitir por completo esta lista equivale a especificar una lista con todos los atributos de la relación
original, es decir, representa la proyección identidad. (En cambio, la especificación de una lista vacía, como
en R (), por ejemplo, representaría la proyección nula.
En la figura 13.6 se presentan algunos ejemplos de proyección. Obsérvese en el primer ejemplo (la
proyección de proveedores según el atributo CIUDAD) que, aunque la relación S tiene cinco tuplas y por
tanto cinco ciudades, sólo hay tres ciudades en el resultado, como ya se explicó, las tuplas repetidas se
elimina (como siempre). Desde luego, lo mismo puede decirse también de los otros ejemplos.

S (CIUDAD)

CIUDAD
Londres

Paris

Atenas

P (COLOR, CIUDAD)

COLOR CIUDAD
Rojo Londres

Verde Paris

Azul Roma

Azul Paris
( S WHERE CIUDAD = ¨Paris¨) (S#)

S#
S2

S3

Figura 5: Ejemplos de proyección.

· Reunión natural

La operación de reunión tiene varias formas distintas. Definitivamente, la más importante es la reunión
natural, que definimos como sigue.
Sean las cabeceras de las relaciones A y B.

(X1, X2,...Xm, Y1, Y2,....., Yn)

(Y1,Y2,...,Yn,Z1,Z2,....Zp)

respectivamente, es decir, los atributos Y1, Y2,..., YN son (los únicos) comunes a las dos relaciones, los
atributos X1,X2,...Xm son los demás atributos de A, y los atributos Z1, Z2,...,Zp son los demás atributos de
B. Vamos a suponer también que los atributos correspondientes (es decir, los atributos con el mismo
nombre) están definidos sobre el mismo dominio. Consideremos ahora (X1,X2,...,Xm), (Y1,Y2,....,.Yn) y
(Z1,Z2,...Zp) como tres atributos compuestos X,Y y Z, respectivamente. La reunión natural de A y B

A JOIN B

Es una relación con la cabecera (X,Y,Z) y un cuerpo formado por el conjunto de todas las tuplas (X:X, Y:y,
Z:z) tales que una tupla a aparezca en A con el valor x en X y el valor y en Y, y una tupla b aparezca en B
con el valor y en Y y el valor z en Z. Como siempre, las relaciones A y B pueden estar representadas por
expresiones arbitrarias.
En la figura se presenta un ejemplo de reunión natural (la reunión natural S JOIN P, según el atributo común
CIUDAD)
La reunión natural, tal como la hemos definido, es tanto asociativa como conmutativa (Ejercicio: Comprobar
estas aseveraciones). En consecuencia, las dos expresiones.

( A JOIN B ) JOIN C

A JOIN (B JOIN C)

Se puede simplificar, sin provocar ambigüedad, a

A JOIN B JOIN C

Además, las dos expresiones

A JOIN B

B JOIN A
son equivalentes.
Cabe señalar que, si A y B no tienen nombres de atributos en común, A JOIN B es equivalente a A TIMES B
(es decir, la reunión natural degenera en el producto cartesiano, en este caso).

S# SNOMBRE SITUACION CIUDAD P# PNOMBRE COLOR PESO

S1 Salazar 20 Londres P1 Tuerca Rojo 12

S1 Salazar 20 Londres P4 Birlo Rojo 14

S1 Salazar 20 Londres P6 Engrane Rojo 19

S2 Jaime 10 Paris P2 Perno Verde 17

S2 Jaime 10 Paris P5 Leva Azul 12

S3 Bernal 30 Paris P2 Perno Verde 17

S3 Bernal 30 Paris P5 Leva Azul 12

S4 Corona 20 Londres P1 Tuerca Rojo 12

S4 Corona 20 Londres P4 Birlo Rojo 14

S4 Corona 20 Londres P6 Engrane Rojo 19

Figura 6: La reunión natural S JOIN P

· Reunión - theta

Ahora pasamos a la operación de reunión theta. La reunión theta es adecuada para aquellas ocasiones (poco
frecuentes en comparación, pero de ninguna manera desconocidas) en las cuales necesitamos juntar dos
relaciones con base en alguna condición diferente a la igualdad. Sean las relaciones A y B compatibles
respecto al producto (o sea, no tienen nombres de atributos en común, véase el análisis del producto
cartesiano en la sección 13.3), y sea theta un operador según la definición dada en el análisis de la
restricción. La reunión theta de la relación A según el atributo X con la relación B según el atributo Y se
define como el resultado de evaluar la expresión.

( A TIMES B) WHERE X theta Y

En otras palabras, es una relación con la misma cabecera que el producto cartesiano de A y B, y con un
cuerpo formado por el conjunto de todas las tuplas t tales que t pertenece a ese producto cartesiano y la
evaluación de condición ¨X theta Y¨ resulta verdadera para esa tupla t. (Los atributos X y Y deberán estar
definidos sobre el mismo dominio, y la operación theta debe ser aplicable a ese dominio)
Vamos a suponer, por ejemplo, que deseamos calcular la ¨reunion mayor que de la relación S según CIUDAD
con la relación P según CIUDAD¨
Una expresión apropiada del álgebra relacional es:

( ( S RENAME CIUDAD AS SCIUDAD) TIMES ( P RENAME CIUDAD AS PCIUDAD) )

WHERE SCIUDAD > PCIUDAD.

El resultado se muestra en la figura. Nota: seria suficiente renombrar sólo uno de los dos atributos CIUDAD,
la única razón para cambiar el nombre de los dos es la simetría.
Adviértase que la reunión theta no es una operación primitiva, siempre es equivalente a obtener el producto
cartesiano ampliado de las dos relaciones (con modificaciones apropiadas de los nombres de los atributos, si
es necesario), y después realizar una restricción apropiada sobre el resultado.
Si theta es ¨igual a¨, la reunión theta se llama equirreunion. Por la definición, el resultado de una
equirreunión debe incluir dos atributos con la propiedad de que los valores de esos dos atributos son iguales
entre si en cada tupla de la relación. Si se elimina uno de esos dos atributos (lo cual puede hacerse mediante
una proyección), el resultado será la ¡la reunión natural! Por tanto, la reunión natural tampoco es una
operación primitiva, es una proyección de una restricción de un producto (una vez más, con las operaciones
apropiadas para renombrar atributos) Por ejemplo, la expresión que representa la reunión natural de
proveedores y partes (según ciudades).

S JOIN P

Es equivalente a la siguiente expresión, más compleja:

( ( S TIMES ( P RENAME CIUDAD AS PCIUDAD ) ) WHERE CIUDAD = PCIUDAD)

(S#, SNOMBRE, SITUACIÓN, CIUDAD, P#, PNOMBRE, COLOR, PESO)

S# SNOMBRE SITUACION CIUDAD P# PNOMBRE COLOR PESO PCIUDAD

S2 Jaime 10 Paris P1 Tuerca Rojo 12 Londres

S2 Jaime 10 Paris P4 Birlo Rojo 14 Londres

S2 Jaime 10 Paris P6 Engrane Rojo 19 Londres

S3 Bernal 30 Paris P1 Tuerca Rojo 12 Londres

S3 Bernal 30 Paris P4 Birlo Rojo 14 Londres

S3 Bernal 30 Paris P6 Engrane Rojo 19 Londres

Figura 7: La reunión mayor - que de S y P según ciudades.

· División:

Sean las cabeceras de las relaciones A y B

(X1,X2,...Xm, Y1,Y2,..., Yn)

(Y1,Y2,...Yn)

respectivamente, es decir, los atributos Y1, Y2,....Yn son comunes a las dos relaciones. Además, A tiene los
atributos X1,X2,...Xm y B no tiene otros atributos. (Las relaciones A y B representan al dividendo y al divisor,
respectivamente) Vamos a suponer que los atributos correspondientes ( es decir, los atributos con el mismo
nombre) están definidos sobre el mismo dominio. Consideremos ahora a (X1, X2,...,Xm) y (Y1, Y2,...Yn)
como dos atributos compuestos X y Y. La división de A entre B.

A DIVIDEBY B

Es una relación con la cabecera (X) y un cuerpo formado por el conjunto de todas las tuplas (X:x) tales que
aparece una tupla (X:x, Y:y) en A para todas las tuplas (Y:y) presentes en B. En otras palabras, el resultado
contiene todos los valores de X en A cuyos valores de Y correspondientes en A incluyen a todos los valores de
Y en B, en términos informales). Como siempre, las relaciones A y B pueden ser expresiones.
 MODULO III: Consultar y modificar datos

TEMA 2: Acceder a los datos en una Base de Datos SQL Server

El comando SELECT se utiliza para recuperar datos desde una base de datos SQL Server y para presentarlos
al usuario en uno o mas conjuntos de resultados. Un conjunto de resultados es un arreglo tabular de los
datos que se recupera al ejecutarse el comando SELECT. Al igual que una tabla, el conjunto de resultados
posee filas y columnas. Este tema proveerá de una vista general de los principales componentes del comando
SELECT, y de cómo estos componentes pueden ser usados para recuperar datos específicos desde una base
de datos SQLServer.

Los Fundamentos del comando SELECT

Un comando SELECT en Transact-SQL permite recuperar datos desde una base de datos SQL Server. La
mayoría de los comandos SELECT incluyen cuatro propiedades primarias del conjunto de resultados:

 La columnas a ser incluidas en el conjuntos de resultados.

 Las tablas de donde se grabarán los datos del conjunto de resultados
 Las condiciones que las filas de las tablas fuentes deben cumplir para ser incluidas en el conjunto de
resultado.
 El ordenamiento de las filas en el conjunto de resultados.

Por ejemplo, el siguiente comando SELECT recupera el ID, nombre y precio unitario de cualquier producto
cuyo precio unitario supere los $40:

SELECT ProductoID, ProductoNombre, PrecioUnit

FROM Productos
WHERE PrecioUnit > 40
ORDER BY PrecioUnit ASC

En este ejemplo, la cláusula SELECT define qué columnas deberán ser recuperados y la cláusula FROM
identifica la tabla que contiene estas columnas La cláusula WHERE limita las filas que serán incluidas en el
conjunto de resultados a aquellos productos que tengan un valor de PrecioUnit mayor a $40. Por último, la
cláusula ORDER BY especifica que el conjunto de resultados estará ordenado de manera ascendente según el
valor de la columna PrecioUnit.
La sintaxis completa del comando SELECT es compleja, pero las principales cláusulas se pueden resumir
como sigue:

SELECT lista_de_selección
[INTO nueva_tabla]
FROM lista_de_tablas
[WHERE condiciones_de_búsqueda]
[GROUP BY lista_de_agrupamientos]
[HAVING condiciones_de_búsqueda]
[ORDER BY lista_de_ordenamiento [ASC | DESC] ]

En el resto de este tema se verá cada cláusula en detalle, junto a ejemplos sobre como definir estas
cláusulas para recuperar datos específicos desde una base de datos SQL Server.

La cláusula SELECT

La cláusula SELECT incluye la palabra clave SELECT y la lista de selección. La lista de selección es una serie
de expresiones separadas por comas. Cada expresión define una columna del conjunto de resultado. Las
columnas en el conjunto de resultados estarán en el mismo orden que la secuencia de expresiones en la lista
de selección.
Usar palabras claves en la lista de selección.
La lista de selección puede también contener palabras claves que controlen el formato final del conjunto de
resultados.

La palabra clave DISTINCT

La palabra clave DISTINCT elimina filas duplicadas del conjunto de resultados. Por ejemplo, la tabla Ordenes
en la base de datos Northwind contiene valores duplicados en la columna CiudadVenta. Para obtener una lista
con los valores duplicados de la columna CiudadVenta removidos, ingrese el siguiente código:

SELECT DISTINCT CiudadVenta, RegionVenta

FROM Ordenes
ORDER BY CityVenta

La palabra clave TOP n

La palabra clave TOP n especifica que solo serán devueltas las primeras n filas del conjunto de resultados. Si
se especifica ORDER BY, las filas son seleccionadas después que el conjunto de resultados se ordena. El valor
n indica el número de filas a ser retornadas (siempre que la palabra clave PERCENT no sea indicada).
PERCENT especifica que n es el porcentaje de filas en el conjunto de resultados que se retornarán. Por
ejemplo el siguiente comando SELECT retorna las primeras 10 ciudades en orden alfabético de la tabla
Ordenes:

SELECT DISTINCT TOP 10 CiudadVenta, RegionVenta

FROM Ordenes
ORDER BY CityVentas

La palabra clave AS

Se puede mejorar la comprensión de un comando SELECT dando a la tabla un alias. Se puede asignar un
alias de tabla usando o no la palabra clave AS:

 nombre_tabla AS alias_tabla
 nombre_tabla alias_tabla

En el ejemplo siguiente, el alias p se asigna a la tabla Editores:

USE pubs
SELECT p.ed_id, p.ed_nonmbre
FROM editores AS p

IMPORTANTE

Si se asigna un alias a una tabla, toda referencia explícita a la tabla en un comando Transact-SQL debe usar
el alias, en vez del nombre de la tabla.

Tipos de información en la lista de selección

Una lista de selección puede incluir muchos tipos de información, tal como una expresión simple o una
subconsulta escalar. Los ejemplos siguientes muestran varios de los ítems que se pueden incluir en las listas
de selección:

SELECT Nombre + ' ' + Apellido AS "Nombre_Empleado",

IDENTITYCOL AS "ID_Empleado",
Telefono_casa,
Region
FROM Northwind.dbo.Empleados
ORDER BY Apellido, Nombre ASC

En este ejemplo, los apellidos y los nombres de los empleados son combinados en una columna. Un espacio
se inserta entre el nombre y el apellido. El nombre de la columna que contendrá los nombres de los
empleados será Nombre_Empleado. El conjunto de resultados también incluirá la columna de identificación
llamada ID_Empleado; la columna Telefono_casa; y la columna Region. El conjunto de resultado se ordenará
primero por apellido y después por nombre.

La cláusula INTO

La cláusula INTO habilita para especificar que el conjunto de resultados se utilizará para crear una tabla
nueva con el nombre definido en la cláusula. El comando SELECT...INTO se utiliza para combinar datos de
varias tablas o vistas en una nueva tabla. Se puede usar para crear una tabla nueva desde un servidor
conectado. El ejemplo utiliza un comando SELECT para recuperar valores desde las columnas Apellido y
Nombre de la tabla Empleados:

SELECT Nombre, Apellido

INTO NombresEmpleados
FROM Empleados

El comando crea una nueva tabla llamada NombresEmpleados y guarda en ella el conjunto de resultados
generado. La nueva tabla contendrá las columnas Nombre y Apellido, y estas columnas contendrán los
valores de la tabla Empleados. El conjunto de resultados no se muestra en el panel Results a no ser que
específicamente se consulte la nueva tabla.

La cláusula FROM

La cláusula FROM se requiere en todo comando SELECT que recupere datos de tablas o vistas. Se usa la
cláusula FROM para listar las tablas y vistas que contienen las columnas referenciadas en la lista de selección
y en la cláusula WHERE. Se pueden asignar alias a las tablas y vistas mediante el uso de la cláusula AS. Se
puede utilizar, además, la cláusula FROM para unir tablas especificando las condiciones de unión en la
cláusula JOIN.
La cláusula FROM es una lista separada por comas de nombres de tablas, vistas y de cláusulas JOIN. El
comando SELECT usa la cláusula FROM para especificar la tabla Vendedores:

SELECT *
FROM Vendedores

Por otra parte, se puede usar la cláusula FROM para especificar combinaciones entre dos tablas o vistas, lo
que se discutirá mas adelante en detalle.

Las cláusulas WHERE, GROUP BY, y HAVING

Las cláusulas WHERE y HAVING en un comando SELECT controlan qué filas de las tablas fuentes serán
usadas para construir el conjunto de resultados. Las cláusulas WHERE y HAVING son filtros. Especifican una
serie de condiciones de búsqueda, y solo se utilizan para construir el conjunto de resultados aquellas filas que
satisfacen las condiciones de filtro. Se dice que estas filas califican para participar del conjunto de resultados.
Por ejemplo, la cláusula WHERE en el siguiente comando

SELECT retornará solo aquellas filas cuyo valor para la región sea Washington:
SELECT IDCliente, NombreCompañia
FROM Northwind.dbo.Clientes
WHERE Region = 'WA'

La cláusula HAVING se usa típicamente en conjunción con la cláusula GROUP BY, aún cuando se puede
especificar sin la cláusula GROUP BY. La cláusula HAVING especifica filtros adicionales y posteriores a los
aplicados por la cláusula WHERE. El siguiente comando SELECT incluye una cláusula WHERE, una cláusula
GROUP BY, y una cláusula HAVING:

SELECT OrdD1.OrdenID AS OrdenID,

SUM(OrdD1.Cantidad) AS "Ventas_Unidas",
SUM(OrdD1.PrecioUnitario * OrdD1.Cantidad) AS Precio
FROM [Detalle_Orden] AS OrdD1
WHERE OrdD1.OrdenID in (SELECT DISTINCT OrdD2.OrdenID
FROM [Detalle_Orden] AS OrdD2
WHERE OrdD2.Precio_Unitario > $100)
GROUP BY OrdD1.OrdenID
HAVING SUM(OrdD1.Cantidad) > 100

En este comando SELECT, la cláusula WHERE retornará solo aquellas órdenes que incluyan un producto con
un precio unitario mayor a $100, y la cláusula HAVING incorpora una restricción adicional tomando aquellas
órdenes que incluyen más de 100 unidades. La cláusula GROUP BY limitará las filas a valores distintos de la
columna OrdenID.

La cláusula GROUP BY

La cláusula GROUP BY se utiliza para producir valores agregados para cada fila en el conjunto de resultados.
Cuando no se usa la cláusula GROUP BY, las funciones de agregación retornan un solo valor para un comando
SELECT.
La palabra clave GROUP BY se sigue de una lista de columnas, conocidas como columnas de agrupamiento.
La cláusula GROUP BY restringe las filas del conjunto de resultados. Habrá una sola fila para cada valor
distinto de la o las columnas de agrupamiento. Cada fila del conjunto de resultados contendrá datos
resumidos relacionados con el valor específico de la columna de agrupamiento.
SQL Server tiene restricciones sobre los ítems que pueden ser especificados en la lista de selección cuando
un comando SELECT contiene una cláusula GROUP BY. La lista de selección puede contener las columnas de
agrupamiento y expresiones que retornen sólo un valor para cada valor de las columnas de agrupamiento, tal
como funciones de agregación que tienen un nombre de columna como uno de sus parámetros
Típicamente la cláusula HAVING se usa con la cláusula GROUP BY, aunque no necesariamente.
En una cláusula GROUP BY, se debe especificar el nombre de la columna de la tabla o vista, no el nombre de
la columna del conjunto de resultados asignada con una cláusula AS. Se puede listar más de una columna en
la cláusula GROUP BY para anidar grupos; esto es, se puede agrupar una tabla por una combinación de
columnas.

Cómo se procesan las cláusulas WHERE, GROUP BY, y HAVING

Entender la secuencia correcta en la que las cláusulas WHERE, GROUP BY, y HAVING se aplican, ayuda a
formular consultas eficientes:

 La cláusula WHERE se usa para filtrar las filas que resultan de aplicar las operaciones indicadas en la
cláusula FROM.
 La cláusula GROUP BY se aplica para agrupar el resultado de la cláusula WHERE.
 Por último, la cláusula HAVING se utiliza para filtrar las filas del resultado agrupado.

Para cualquier condición de búsqueda que se podría aplicar indistintamente antes o después de la operación
de agrupamiento, es más eficiente indicarla en la cláusula WHERE. Esto reduce el número de filas a ser
agrupadas. Las únicas condiciones de filtro que deben ser indicadas en la cláusula HAVING son aquellas que
deben ser aplicadas después que se realicen las operaciones de agrupamiento.

La cláusula ORDER BY

La cláusula ORDER BY ordena el resultado de una consulta por una o más columnas (hasta 8060 bytes). Un
ordenamiento puede ser ascendente (ASC) o descendente (DESC). Si no se especifica una ordenamiento, se
asume ASC. Si se indican más de una columna en la cláusula ORDER BY el ordenamiento es anidado.
El siguiente comando ordena las filas en la tabla Titulos, primero por Editor (en orden descendente), luego
por tipo (en orden ascendente dentro de cada editor), y finalmente por precio (en orden ascendente, dado
que no se indica DESC):
USE Pubs
SELECT Pub_id, Tipo, Titulo, Precio
FROM Titulos
ORDER BY Pub_id DESC, Tipo, Precio

MODULO III: Consultar y modificar datos

Tema 3: Usar Técnicas Avanzadas de Consulta para Acceder a los Datos

Una vez que ha logrado sentirse confortable con los fundamentos del comando SELECT, y está familiarizado
con varias de sus cláusulas, Ud. está listo para aprender técnicas de consultas más avanzadas. Una de estas
técnicas es la de combinar el contenidos de una o mas tablas para producir un conjunto de resultados que
incorpore filas y columnas de cada tabla. Otra técnica es la de usar subconsultas, las cuales se anidan dentro
de otros comando SELECT, INSERT, UPDATE, o DELETE. Subconsultas pueden también ser anidadas dentro
de otras subconsultas. Se pueden usar los elementos de Transact-SQL tales con CUBE y ROLLUP para resumir
datos.

Usar combinaciones para recuperar datos

Usando combinaciones (joins), se pueden recuperar datos desde dos o más tablas basados en relaciones
lógicas entre las tablas. Las combinaciones indican cómo el SQL Server utilizará los datos de una tabla para
seleccionar las filas en otra tabla.
Las combinaciones se pueden especificar tanto en la cláusulas FROM o WHERE. Las condiciones de
combinación se unen con las condiciones de búsqueda de las cláusulas WHERE y HAVING para controlar qué
filas serán seleccionadas desde las tablas base referenciadas en la cláusula FROM. Especificar las condiciones
de combinación en la cláusula FROM, sin embargo, sirve para separarlas de cualquier otra condición que
podría ser especificada en una cláusula WHERE y se recomienda para especificar combinaciones.
Cuando se referencian múltiples tablas en una sola consulta, todas las columnas referenciadas deben ser
indicadas de manera no ambigua. El nombre de la tabla debe ser utilizado para calificar cualquier nombre de
columna que esté duplicado en dos o más tablas referenciadas en una consulta simple.
La lista de selección para una combinación puede referenciar a todas las columnas de las tablas combinadas
o a cualquier subconjunto de columnas. No se requiere que la lista de selección contenga las columnas de
todas las tablas en la combinación. Por ejemplo, en una combinación de tres tablas, una tabla puede ser
utilizada como puente desde una de las otras tablas a la tercera tabla, y no ser referenciada en la lista de
selección ninguna de las columnas de la tabla puente
Aunque las condiciones de combinación utilizan generalmente el operador de comparación igual (=), se
puede especificar cualquier otro operador relacional, así como otros predicados.
Cuando SQL Server procesa combinaciones, el motor de consultas elige el método más eficiente (de entre
varias posibilidades) para procesar la combinación. Aunque la ejecución física de varias combinaciones usa
diferentes caminos, se respeta la siguiente secuencia lógica:

 Se aplican las condiciones de combinación de la cláusula FROM.

 Se aplican las condiciones de combinación y las condiciones de búsqueda de la cláusula WHERE.
 Se aplican las condiciones de búsqueda de la cláusula HAVING.

Esta secuencia puede, algunas veces, influenciar el resultado de la consulta si se mueven las condiciones
entre la cláusulas FROM y WHERE.
Las columnas usadas en las condiciones de combinación, no necesariamente deben tener el mismo nombre o
el mismo tipo de datos. Si los tipos de datos no son idénticos, sin embargo, deben ser compatibles o ser tipos
que SQL Server pueda convertir de manera implícita. En caso que los tipos de datos no puedan ser
convertidos de manera implícita, la condición de combinación debe explícitamente convertir los tipos de datos
usando la función CAST.
NOTA

La mayoría de las combinaciones pueden ser reescritas como subconsultas (una consulta anidada dentro de
otra consulta), y muchas subconsultas pueden ser reescritas como combinaciones. Veremos subconsultas en
detalle mas adelante.
Muchas combinaciones pueden ser categorizadas como combinaciones inner o outer. Las combinaciones inner
retornan las filas sólo cuando existe al menos una fila en ambas tablas que cumplen con la condición de
combinación, eliminando las filas que no se asocian a otra fila en la otra tabla. Las combinaciones outer, sin
embargo, retornan todas las filas desde al menos una tabla o vista, mencionada en la cláusula FROM,
siempre que esa fila cumpla con las condiciones de búsqueda de las cláusulas WHERE y HAVING.

Combinaciones Inner

Una combinación inner es una combinación en la cual los valores de las columnas a ser combinadas son
comparados a través de un operador de comparación. En el SQL-92 estándar, las combinaciones inner
pueden ser especificadas tanto en las cláusulas FROM o WHERE. Las combinaciones inner son el único tipo de
combinación que el SQL-92 soporta en la cláusula WHERE. Combinaciones inner establecidas en la cláusula
WHERE son conocidas como combinaciones al viejo estilo.
El siguiente comando SELECT usa una combinación inner para recuperar datos desde la tabla Editores y la
tabla Titulos en la base de datos Pubs.

SELECT t.Titulo, p.Ed_Nombre

FROM Editores AS p INNER JOIN Titulos AS t
ON p.Ed_id = t.Ed_id
ORDER BY Titulo ASC

Este comando SELECT recupera datos desde la columna Titulo en la tabla Titulos (t) y desde la columna
Ed_Nombre en la tabla Editores (p). Dado que este comando utiliza una combinación inner, esta retornará
sólo aquellas columnas que tengan un valor igual en las columnas de la combinación (la columna p.Ed_id y la
t.Ed Publishers).

Combinaciones Outer

SQL Server soporta tres tipos de combinaciones outer: izquierda (left), derecha (right), y completa (full).
Todas las filas recuperadas desde la tabla izquierda son referenciadas con una combinación outer izquierda, y
todas las filas de la tabla derecha son referenciadas en una combinación outer derecha. Todas las filas de
ambas tablas son retornadas en una combinación outer completa.

Usar combinaciones outer izquierdas

Un conjunto de resultados generado por un comando SELECT que incluye una combinación outer izquierda
incluye todas las filas de la tabla referenciada a la izquierda del LEFT OUTER JOIN. Las únicas filas de la tabla
de la derecha que se recuperarán serán aquellas que cumplan con la condición de la combinación.
En el siguiente comando SELECT, se usa una combinación outer izquierda para recuperar los apellidos y
nombres de los autores y (cuando corresponda) los nombres de cualquier editor que se encuentre en la
misma ciudad que el autor:

USE Pubs
SELECT a.Au_nombre, a.Au_apellido, p.Ed_nombre
FROM Autores a LEFT OUTER JOIN Editores p
ON a.Ciudad = p.Ciudad
ORDER BY p.Ed_nombre ASC, a.Au_apellido ASC, a.Au_nombre ASC

El conjunto de resultados para esta consulta listará el nombre de todos los autores de la tabla Autores. El
conjunto de resultados incluirá sólo aquellos editores que se encuentren en las mismas ciudades de los
autores. Si un editor no se encuentra en la ciudad del autor, un valor nulo es retornado para la columna
Ed_nombre del conjunto de resultados.
Usar combinaciones outer derecha

Un conjunto de resultados generado por un comando SELECT que incluye una combinación outer derecha
incluirá todas las filas de la tabla referenciada a la derecha del RIGHT OUTER JOIN. Las únicas columnas que
serán recuperadas de la tabla izquierda serán aquellas que cumplan con la condición de la combinación.
En el siguiente comando SELECT, se usa una combinación outer derecha para obtener la lista de editores y
los nombres y apellidos de los autores, si estos autores se encuentran en la misma ciudad de los editores:

USE Pubs
SELECT a.Au_nombre, a.Au_apellido, p.Ed_nombre
FROM Autores a RIGHT OUTER JOIN Editores p
ON a.Ciudad = p.Ciudad
ORDER BY p.Ed_nombre ASC, a.Au_apellido ASC, a.Au_nombre ASC

El conjunto de resultados de esta consulta listará los nombre de todos los editores de la tabla Editores. El
conjunto de resultados incluirá solo aquellos autores que se encuentren en la misma ciudad del editores. Si
un autor no se encuentra en la ciudad del editor, un valor nulo se retorna para las columnas Au_apellido y
Au_ nombre del conjunto de resultados.

Usar combinaciones outer completas

Un conjunto de resultados generado por un comando SELECT que incluya una combinación outer completa
incluirá todas las filas desde ambas tablas, sin tener en cuenta si los valores cumplen con la condición de la
combinación.
En el siguiente comando SELECT, s usa una combinación outer completa para obtener la lista de los editores
y los nombres y apellidos de los autores:

USE Pubs
SELECT a.Au_nombre, a.Au_apellido, p.Ed_nombre
FROM Autores a FULL OUTER JOIN Editores p
ON a.Ciudad = p.Ciudad
ORDER BY p.Ed_nombre ASC, a.Au_apellido ASC, a.Au_nombre ASC

El conjunto de resultados de esta consulta listará el nombre de todos los editores de la tabla Editores y todos
los autores de la tabla Autores. Si un autor no se encuentra ubicado en la misma ciudad del editor, un valor
nulo se retorna en la columnas Au_apellido y Au_nombre del conjunto de resultados. Si un editor no se
encuentra en la misma ciudad del autor, se retorna un valor nulo en la columna Ed_nombre del conjunto de
resultados. Cuando se cumple la condición todas las columnas del conjunto de resultados tendrán un valor.

Definir subconsultas dentro del comando SELECT

Una subconsulta es un comando SELECT que retorna un valor simple y se encuentra anidado dentro de un
comando SELECT, INSERT, UPDATE, o DELETE o dentro de otra subconsulta. Una subconsulta puede usarse
en cualquier lugar en que una expresión lo permita.
En el ejemplo siguiente, se anida una subconsulta en la cláusula WHERE de un comando SELECT:

USE Northwind
SELECT NombreProducto
FROM Productos
WHERE PreciioUnit =
(
SELECT PrecioUnit
FROM Productos
WHERE NombreProducto = 'Sir Rodney''s Scones'
)

El comando SELECT embebido primero ubica el valor de PrecioUnit de los Sir Rodney's Scones, el cual es de
$10. Este valor ($10) se usa luego en el comando SELECT exterior para obtener los nombres de los
productos que tienen el mismo precio unitario.
Si una tabla figura solo en la subconsulta y no en la consulta exterior, las columnas de esta tabla no pueden
ser incluidas en el resultado de la consulta exterior.
En algunos comandos Transact-SQL, la subconsulta puede ser evaluada como una consulta independiente.
Conceptualmente, el resultado de una subconsulta se sustituye dentro de la consulta exterior (aún cuando no
sea necesariamente cómo SQL Server resuelve los comandos Transact-SQL que tienen subconsultas)

Tipos de subconsultas

Las subconsultas se pueden definir en muchos lugares dentro de un comando SELECT. Sin embargo, los
comandos que incluyen subconsultas generalmente adoptan uno de los siguientes formatos:

 WHERE <expresión> [NOT] IN (<subconsulta>)

 WHERE < expresión > <operador_de_comparación> [ANY | ALL] (<subconsulta>)
 WHERE [NOT] EXISTS (<subconsulta>)

Subconsultas que se usan con IN o con NOT IN

El resultado de una subconsulta introducida con IN (o con NOT IN) es una lista de cero o más valores.
Después que la subconsulta devuelve el resultado, la consulta exterior lo utiliza.
En el ejemplo siguiente. Una subconsulta se anida dentro de la cláusula WHERE, usando la palabra clave IN:

USE Pubs
SELECT Ed_nombre
FROM Editores
WHERE Ed_id IN
(
SELECT Ed_id
FROM Titulos
WHERE Tipo = 'negocios'
)

Se puede evaluar este comando en dos pasos. Primero, la subconsulta retorna los números de ID de los
editores que han publicado libros de negocios. Luego estos valores son sustituidos en la consulta exterior. la
cual encuentra los nombres que igualan estos números de identificación. Primero, la subconsulta retorna los
números de identificación de los editores que tienen libros de negocios publicados. Segundo, estos valores se
sustituyen en la consulta exterior, la cual encuentra los nombres de los editores que tienen números de
identificación dentro del conjunto de resultados de la subconsulta en la tabla Editores.
Las subconsultas introducidas con la palabra clave NOT IN también retornan una lista de cero o más valores.
La consulta trabaja exactamente igual que una con IN, excepto que con NOT IN se seleccionan a todos
aquellas filas cuyos valores en la columna de comparación (Ed_in en este caso) no se encuentren del
conjunto de resultados de la subconsulta.

Subconsultas que son usadas con operadores de comparación

Los operadores de comparación que introduce una subconsulta se pueden modificar con las palabras claves
ALL o ANY. La palabra clave SOME del SQL-92 estándar es equivalente a ANY. Las subconsultas introducidas
con un operador de comparación modificado retornan una lista de cero o más valores y pueden incluir una
cláusula GROUP BY o HAVING. Estas consultas pueden tener la cláusula EXISTS.
Las palabras clave ALL y ANY comparan un valor escalar con un conjunto de valores simples. La palabra clave
ALL indica que se debe aplicar a todos los valores, mientras que ANY indica que al menos a un valor.
En el siguiente ejemplo, el operador de comparación mayor que (>) es usado con ANY:

USE Pubs
SELECT Titulo
FROM Titulos
WHERE Adelanto > ANY
(
SELECT Adelanto
FROM Editores INNER JOIN Titulos
ON Titulos.Ed_id = Editores.Ed_id
AND Ed_nombre = 'Algodata Infosystems'
)

Este comando encuentra los títulos que reciben un adelanto mayor que el mínimo adelanto pagado por
Algodata Infosystems. La cláusula WHERE en el comando SELECT exterior contiene una subconsulta que usa
una combinación para recuperar monto de adelantos para Algodata Infosystems. El mínimo adelanto es
utilizado para determinar que títulos obtener de la tabla Titulos.

Subconsultas que se usan con EXISTS y NOT EXISTS

Cuando se introduce una subconsulta con la palabra clave EXISTS. Esta funciona como un test de existencia.
La cláusula WHERE de la consulta exterior comprueba por la existencia de las filas retornadas por la
subconsulta. La subconsulta en realidad no produce ningún dato, solo retorna un valor de TRUE o FALSE.
En el siguiente ejemplo, la cláusula WHERE en el comando SELECT exterior contiene una subconsulta que usa
EXISTS:

USE Pubs
SELECT Ed_nombre
FROM Editores
WHERE EXISTS
(
SELECT * FROM Titulos
WHERE Titulos.Ed_id = Editores.Ed_id
AND Tipo = 'negocios'
)

Para determinar el resultado de esta consulta, se toma cada fila de la tabla Editores y se verifica que exista
dentro de las filas de la base titulo que sean de ese editor (Titulos.Ed_id = Editores.Ed_id) y el tipo sea
"negocios". Si existe algún título que cumpla, el nombre de ese editor figurará en el conjunto de resultados.
La palabra clave NOT EXISTS trabaja como EXISTS, excepto que la cláusula WHERE que tiene NOT EXIST
será satisfecha solo si la subconsulta no devuelve ninguna fila.
Resumir datos
Transact-SQL incluye varios elementos que lo habilitan para generar reportes simples resumidos. Se pueden
usar los operadores CUBE o ROLLUP, los que son parte de la cláusula GROUP BY del comando SELECT.
También se pueden usar los operadores COMPUTE o COMPUTE BY, los que también se asocian a la cláusula
GROUP BY.
Los operadores COMPUTE y COMPUTE BY se mantienen por compatibilidad con versiones anteriores.

Usar el operador CUBE para resumir datos

El operador CUBE genera un conjunto de resultados que es un cubo multidimensional. Un cubo

multidimensional es una expansión de datos sobre sucesos, o datos que registran eventos individuales. La
expansión está basada sobre columnas que el usuario desea analizar. Estas columnas son llamadas
dimensiones. El cubo es un conjunto de resultados conteniendo un tabla cruzada de todas las combinaciones
posibles.
El siguiente comando SELECT usa al operador CUBE en la cláusula GROUP BY:

USE Pubs
SELECT SUBSTRING(Titulo, 1, 65) AS Titulo,
SUM(cant) AS 'Cantidad'
FROM Ventas INNER JOIN Titulos
ON Ventas.Titulo_id = Titulos.Titulo_id
GROUP BY Titulo
WITH CUBE
ORDER BY Titulo
Este comando SELECT cubre una relación uno a muchos entre los títulos de los libros y las cantidades
vendidas de cada uno. Al usar el operador CUBE, el comando devuelve una columna extra. La columna extra
(la cual contiene un valor nulo en la columna Titulo del conjunto de resultados) representa a todos los valores
en la columna Titulo de la tabla Titulos. El conjunto de resultado devuelve los valores para la cantidad
vendida de todos los títulos. En este caso, usar el operador CUBE o el operador ROLLUP retorna el mismo
resultado.

Usar el operador ROLLUP para resumir datos

El operador ROLLUP es útil para generar reportes que contienen subtotales y totales. El operador ROLLUP
genera un conjunto de resultados que es similar al conjunto de resultados del operador CUBE. Las diferencias
entre los operadores CUBE y ROLLUP son las siguientes:

 CUBE genera un conjunto de resultados mostrando agregaciones para todas las combinaciones de
valores en las columnas seleccionadas.
 ROLLUP genera un conjunto de resultados mostrando agregaciones para jerarquías en las columnas
seleccionadas.

El siguiente comando SELECT contiene un operador ROLLUP en la cláusula GROUP BY:

USE Pubs
SELECT Ed_nombre, Au_apellido, Titulo, SUM(cant) AS 'Sum'
FROM Autores a INNER JOIN TituloAutor ta
ON a.Au_id = ta.Au_id INNER JOIN Titulos t
ON t.Titulo_id = ta.Titulo_id INNER JOIN Editores p
ON p.Ed_id = t.Ed_id INNER JOIN Ventas s
ON s.Titulo_id = t.Titulo_id
GROUP BY Ed_nombre, Au_apellido, Titulo
WITH ROLLUP

Al usar el operador ROLLUP, se pueden crear agrupamientos en el conjunto de resultados. Para las filas
agrupadas, se usa un valor nulo para representar todos los valores para la columna (excepto la columna
Sum). Si se usa un comando SELECT sin el operador ROLLUP, el comando generará los siguientes datos
cuando se listen las columnas Ed_nombre, Au_nombre, y Titulo (en ese orden) en la cláusula GROUP_BY:

 Cantidad de cada título que cada editor vendió para cada autor.
 Cantidad de todos los títulos que cada editor vendió
 Cantidad total de todos los títulos vendidos por todos los editores para todos los autores.

MODULO III: Consultar y modificar datos

Tema 4: Modificar datos en una Base de Datos SQL Server

Un componente esencial de un sistema de bases de datos es la capacidad para modificar los datos que se
encuentran almacenados dentro del sistema. SQL Server soporta métodos para agregar filas de datos a las
tablas de una base de datos SQL Server, cambiar los datos en las filas existentes, y eliminar filas.

Insertar datos en un base de datos SQL Server

SQL Server varios métodos para insertar datos a una base de datos:

 El comando INSERT
  El comando SELECT...INTO
 El comando WRITETEXT y varias opciones en la API (Application Programming Interface) de la base de
datos, que se pueden usar para agregar texto e imágenes a una fila.

NOTA

Un comando INSERT trabaja tanto sobre tablas como sobre vistas (con algunas restricciones).

Usar el comando INSERT para agregar datos

El comando INSERT agrega una o más nuevas filas a una tabla. En un tratamiento simplificado, el comando
INSERT toma la siguiente forma:

INSERT [INTO] tabla_o_vista [(lista_de_columnas)] valores_de_datos

Este comando hace que los valores de los datos (valores_de_datos) sean insertados como una o mas filas en
la tabla o vista. La lista de los nombres de columnas (lista_de_columnas), separadas por comas, se usan
para especificar las columnas que recibirán los datos. Si no se indican columnas, todas las columnas de la
tabla o vista recibirán datos. Si solo se indica una lista parcial de columnas, el resto de las columnas recibirán
un valor nulo o el valor configurado por defecto para esa columna, en caso que lo tenga.
Además, no se deben asignar valores a los siguientes tipos de columnas, dado que SQL Server genera
automáticamente este valor.

 Columnas con la propiedad IDENTITY

 Columnas con una definición DEFAULT que use la función NEWID()
 Columnas computadas

NOTA

La palabra clave INTO en un comando INSERT es opcional y solo se utiliza para clarificar el código.
Los valores ingresados deben coincidir con la lista de columnas. La cantidad de valores provistos debe ser
igual a la cantidad de columnas indicadas en la lista de columnas, y el tipo de dato, precisión, y escala de
cada valor debe coincidir con los de las columnas correspondientes.
Cuando se define un comando INSERT, se puede usar la cláusula VALUES para especificar los valores de los
datos para una fila o usar una subconsulta SELECT para especificar los valores para una o más columnas.

Usar el comando INSERT...VALUES para agregar datos

Una cláusula VALUES permite especificar los valores para una fila de la tabla. Los valores son indicados a
través de una lista de expresiones escalares separadas por comas. Estos valores deben ser implícitamente
convertibles al tipo, precisión y escala de las columnas correspondientes. Si no se especifica la lista de
columnas, los datos deben ser ingresados en el mismo orden que tiene en la definición de la tabla o vista.
Por ejemplo, suponga que se crea la siguiente tabla en la base de datos Pubs:

USE Pubs
CREATE TABLE NuevosLibros
(
LibroID INT IDENTITY(1,1) NOT NULL,
LibroTitulo VARCHAR(80) NOT NULL,
LibroTipo CHAR(12) NOT NULL
CONSTRAINT [tipolibro_df] DEFAULT ('no informado'),
CiudadEd VARCHAR(50) NULL
)

Una vez creada la tabla, se decide ingresar datos a una fila de la tabla. EL siguiente comando INSERT utiliza
la cláusula VALUES para insertar una nueva fila en la tabla NuevosLibros:
USE Pubs
INSERT INTO NuevosLibros (LibroTitulo, CiudadEd)
VALUES ('Life Without Fear', 'Chicago')

En este comando, los valores han sido definidos para la columnas LibroTitulo y CiudadEd. Sin embargo, no es
necesario incluir la columna LibroID en el comando INSERT, dado que la columna LibroID se define con la
propiedad IDENTITY, porque los valores para esa columna se generan automáticamente. Además, al no
ingresarse un valor para la columna TipoLibro, SQL Server automáticamente inserta el valor por defecto (no
informado) en la columna al ejecutar el comando.

Usar una subconsulta SELECT para agregar datos

Se puede usar una subconsulta SELECT dentro de un comando INSERT para agregar datos a una tabla desde
otra u otras tablas o vistas. Una subconsulta permite agregar más de una fila a la vez.

NOTA: Una subconsulta SELECT en un comando INSERT se utiliza para agregar subconjuntos de datos
existentes a una tabla, mientras que la cláusula VALUES se usa para guardar datos nuevos en una tabla.

El siguiente comando INSERT usa una subconsulta SELECT para insertar filas en la tabla NuevosLibros:

USE Pubs
INSERT INTO NuevosLibros (LibroTitulo, LibroTipo)
SELECT Titulo, Tipo
FROM Titulos
WHERE Tipo = 'mod_cook'

Este comando INSERT usa la salida de una subconsulta SELECT para proveer los datos que se usarán para
ser insertados en la tabla NuevosLibros.

Usar el comando SELECT...INTO para agregar datos

EL comando SELECT INTO permite crear una nueva tabla y llenarla con el resultado del comando SELECT. Ver
Tema 2 de este módulo

Agregar datos ntext, text, o imagen a filas ya insertadas

SQL Server incluye varios métodos para agregar valores ntext, text, o imagen a un fila:

 Se pueden especificar relativamente pequeños montos de datos en un comando INSERT de la misma

forma que se especifican datos char, nchar, o binary.
 Utilizar el comando WRITETEXT, que permite actualización interactiva, y no registrada, de una
columna existente tipo text, ntext, o image. Este comanado sobrescribe completamente cualquier
dato preexistente en la columna que afecta. Un comando WRITETEXT no puede usarse sobre
columnas de una vista.
 Las aplicaciones ADO (Active Data Object) pueden usar el método AppendChunk para especificar
grandes cantidades de datos tipo ntext, text, o image.
 Las aplicaciones OLE DB, por su parte, utilizan la interfase ISequentialStream.
 Las aplicaciones ODBC (Open Database Connectivity) usan el SQLPutData para ingresar nuevos
valores del tipo ntext, text, o image.
 Por último, las aplicaciones DB-Library usan la función Dbwritetext.

Modificar datos en una base de datos SQL Server

Una vez que se crean las tablas y que se ingresan datos, cambiar y actualizar los datos se convierte en una
tarea de mantenimiento diario SQL Server provee varios métodos para cambiar datos en una tabla existente:

 El comando UPDATE
 La API de la base de datos y los cursores
 El comando UPDATETEXT

Estos procedimientos se pueden tanto a tablas como a vistas (con algunas restricciones)

Usar el comando UPDATE para modificar datos

El comando UPDATE puede cambiar datos en una columna simple, en grupos de columnas, o en todas las
columnas de una tabla o vista. Este comando se puede usar también para actualizar filas en un servidor
remoto, ya sea usando el nombre de un servidor conectado o las funciones OPENROWSET,
OPENDATASOURCE, y OPENQUERY (siempre y cuando el proveedor OLE DB usada para acceder al servidor
remoto soporte actualizaciones). Un comando UPDATE que referencia a una tabla o una vista puede cambiar
los datos en sólo un tabla base por vez.

NOTA
Una actualización será exitosa sólo si el nuevo valor es compatible con el tipo de datos de la columna y
cumple con todas las restricciones asociadas a esta.

Las cláusulas más importantes del comando UPDATE son:

 SET
 WHERE
 FROM

Usar la cláusula SET para modificar datos.

SET indica que columna será actualizada y los nuevos valores que se guardarán. Los valores en las columnas
indicadas serán actualizados con los valores provistos en la cláusula SET en todas las filas que cumplan con la
condición de búsqueda especificada en la cláusula WHERE. Si no se especifica la cláusula WHERE, todas las
columnas serán actualizadas.
Por ejemplo, el siguiente comando UPDATE incluye la cláusula SET que incrementa el precio de los libros en
la tabla NuevosLibros un 10 por ciento:

USE Pubs
UPDATE NuevosLibros
SET Precio = Precio * 1.1

En este comando, no se usa la cláusula WHERE, por lo que todas las filas serán modificadas (salvo aquellas
que tengan un valor nulo para la columna Precio).

Usar la cláusula WHERE para modificar datos

La cláusula WHERE realiza dos funciones:

 Indica las filas a actualizar

 Indica las filas de la tabla fuente que califican para proveer valores de actualización cuando se
especifica la cláusula FROM.

Si no se indica la cláusula WHERE, todas las filas serán actualizadas.

En el siguiente comando UPDATE, la cláusula WHERE se utiliza para limitar la actualización a sólo aquellas
filas que cumplen con la condición definida en la cláusula:

USE Pubs
UPDATE NuevosLibros
SET LibroTipo = 'popular'
WHERE LibroTipo = 'popular_comp'

Este comando cambia el nombre del tipo de libro de aquellas filas con el valor popular_comp por el de
popular. Si no se hubiese puesto la cláusula WHERE todos los valores de LibroTipo tomarían el valor popular.

Usar una cláusula FROM para modificar los datos

Se puede usar la cláusula FROM para traer datos desde una o más tablas o vistas a la tabal que se quiere
actualizar. Por ejemplo, en el siguiente comando UPDATE, la cláusula FROM incluye un inner join que
combina los títulos en las tablas NuevosLibros y Titulos:

USE Pubs
UPDATE NuevosLibros
SET Precio = Titulos.Precio
FROM NuevosLibros JOIN Titulos
ON NuevosLibros.LibroTitulo = Titulos.Titulo

En este comando, los valores de Precio en la tabla LibrosNuevos se actualizan al mismo valor que la columna
Precio de la tabla Titulos.

Usar APIs y cursores para modificar datos

Las APIs ADO, OLE DB, y ODBC soportan actualizar los datos de la fila actual sobre la que la aplicación se
encuentra posicionada en un conjunto de resultados. Además, cuando se usa un cursor del servidor Transact-
SQL, se puede actualizar la fila actual utilizando el comando UPDATE con la cláusula WHERE CURRENT OF.
Los cambios realizados con esta cláusula sólo afectarán a la fila donde se encuentre posicionado el cursor.
Este punto se verá más en detalle en otro módulo del Kit.

Modificar datos ntext, text, o image

SQL Server provee varios métodos para modificar valores del tipo ntext, text, o image en una fila cuando se
reemplazan los valores completos:

 Se pueden especificar relativamente pequeños montos de datos en un comando UPDATE de la misma

forma que se modifican datos char, nchar, o binary.
 Utilizar los comandos WRITETEXT o UPDATETEXT, para modificar datos ntext, text, o image.
 Las aplicaciones ADO (Active Data Object) pueden usar el método AppendChunk para especificar
grandes cantidades de datos tipo ntext, text, o image.
 Las aplicaciones OLE DB, por su parte, utilizan la interfase ISequentialStream.
 Las aplicaciones ODBC (Open Database Connectivity) usan el SQLPutData para ingresar nuevos
valores del tipo ntext, text, o image.
 Por último, las aplicaciones DB-Library usan la función Dbwritetext.

SQL Server soporta, además, actualizaciones de sólo una porción de datos del tipo ntext, text, o image. En
DB-Library, se puede hacer usando la función Dbupdatetext. Todas las otras aplicaciones y los scripts
Transact-SQL, batches, procedimientos almacenados y disparadores pueden usar el comando UPDATETEXT
para actualizar sólo una porción de columnas ntext, text, o image.

Eliminar datos de una base de datos SQL Server

SQL Server soporta varios métodos para eliminar datos de una tabla:

 El comando DELETE
 APIs y cursores
  El comando TRUNCATE TABLE

Usar el comando DELETE para eliminar datos

Un comando DELETE remueve una o más filas en una tabla o vista. La sintaxis siguiente es una forma
simplificada del comando DELETE:

DELETE tabla_o_vista FROM tabla_fuente WHERE condicion_de_busqueda

En tabla_o_vista se colocan los nombre de la tabla o vista en que serán eliminadas las filas. Serán eliminadas
todas las filas que cumplan con la condición de búsqueda especificada en la cláusula WHERE. Si esta no se
indica, se eliminarán todas las filas de la tabla o vista. La cláusula FROM indica tablas, vistas o combinaciones
adicionales que se pueden usar en el predicado de condición de la cláusula WHERE. No se borran las filas de
las tablas indicadas en la cláusula FROM, sino sólo de la especificada en la cláusula DELETE.
Si a una tabla se le eliminan todas tablas las misma permanece en la base de datos de todos modos. Para
eliminar la tabla de la base de datos se debe usar el comando DROP TABLE.
Considere el comando DELETE siguiente:

USE Pubs
DELETE NuevosLibros
FROM Titulos
WHERE NuevosLibros.LibroTitulo = Titulos.Titulo
AND Titulos.Royalty = 10

En este comando, se borrarán aquellas filas de la tabla NuevosLibros con un royalty del 10 por ciento. Este
valor de royalty se toma de la columna royalty de la tabla Titulos.

Usar APIs y Cursores para eliminar datos

Las APIs ADO, OLE DB, y ODBC soportan eliminación de la fila actual sobre la cual se encuentra posicionada
la aplicación en el conjunto de resultados. Además, cuando se usa un cursor del servidor Transact-SQL, se
puede eliminar la fila actual utilizando el comando UPDATE con la cláusula WHERE CURRENT OF. Los cambios
realizados con esta cláusula sólo afectarán a la fila donde se encuentre posicionado el cursor. Este punto se
verá más en detalle en otro módulo del Kit.

Usar el comando TRUNCATE TABLE para eliminar datos

El comando TRUNCATE TABLE es una forma rápida y no registrada de eliminar todas las filas en una tabla.
Este método es casi siempre más rápido que un comando DELETE sin condiciones, porque DELETE graba un
registro de transacciones por cada fila eliminada, mientras que TRUNCATE TABLE solo graba registro de
liberación de las páginas de datos completas. El comando TRUNCATE TABLE inmediatamente libera el espacio
ocupado por los datos de la tabla e índices. También se liberan las páginas de distribución de todos los
índices.
El comando TRUNCATE TABLE siguiente elimina todas las filas de la tabla NuevosLibros en la base de datos
Pubs:

USE Pubs
TRUNCATE TABLE NuevosLibroswBooks

Como en el caso del comando DELETE, la definición de la tabla se mantiene en la base de datos después que
se aplica un comando TRUNCATE TABLE (incluidos sus índices y objetos asociados). Para eliminar la
definición de la tabla se debe usar el comando DROP TABLE.
 MODULO IV: Implementar procedimientos almacenados

TEMA 1: Introducción a los procedimientos almacenados

Hasta ahora hemos utilizado el Query Analizer (o la herramienta on-line) para ejecutar comandos o grupos
de comandos en el lenguaje Transact SQL. A los grupos de comandos los llamaremos scripts (guiones).

Cuando se ejecuta un script, los comandos son ejecutados por SQL Server para mostrar un conjunto de
resultados, configurar un comportamiento y administrar al servidor o para manipular datos contenidos en una
base de datos.

A estos scripts se les puede dar un nombre y guardar como procedimientos almacenados en el SQL Server.
Posteriormente se los puede invocar de diversas maneras, tal como desde el Query Analizer, para que
realicen el procesamiento de los comandos Transact SQL incorporados.

El SQL Server provee una serie de procedimientos almacenados del sistema, algunos de los cuales ya hemos
utilizado en este Kit. Estos procedimientos son guardados en la base de datos Master y contienen comando
Transact SQL que facilitan muchas tareas.

Propósito y ventajas de los procedimientos almacenados

Los procedimientos almacenados proporcionan ventajas de performance, un marco de trabajo, y mayores

capacidades de seguridad. La mejora en el rendimiento se logra a través de un almacenamiento local (en la
base de datos), código precompilado, y manejo de cachés (almacenamientos temporarios). El marco de
programación se logra a través de construcciones comunes de programación tales como parámetros de
entrada/salida y reutilización de los procedimientos. Las capacidades de seguridad incluye encriptación y
limitaciones de privilegios que permiten mantener a los usuarios fuera de la vista de la estructura de la base
de datos subyacente, mientras se los habilita a ejecutar procedimientos almacenados que actúan sobre la
base de datos.

Rendimiento

Cada vez que un comando Transact-SQL, o conjunto de comandos, es enviado el servidor para su
procesamiento, el servidor debe determinar si el remitente tiene suficientes privilegios para ejecutar esos
comandos y si los comandos son válidos. Una vez que los permisos y la sintaxis de los comandos se han
verificado, SQL Server construye un plan de ejecución para procesar el pedido.

Los procedimientos almacenados son más eficientes en parte porque el procedimiento es almacenado en el
SQL Server cuando se crea. La sintaxis de los comandos contenidos en un procedimiento almacenado se
comprueba que este libre de errores antes de ser guardado. El nombre del procedimiento almacenado se
almacena en la tabla SysObjects, mientras que el texto del procedimiento se guarda en la tabla
SysComments. Por otro lado, invocar al procedimiento almacenado implica ejecutar un solo comando en vez
de cientos de comandos que un procedimiento almacenado podría contener.

La primera vez que se ejecuta el procedimiento, se crea un plan de ejecución y se compila al procedimiento
almacenado. Los procesamientos subsecuentes del procedimiento almacenado son mucho más rápidos ya
que el SQL Server no vuelve a controlar la sintaxis, ni recrea un plan de ejecución, ni se recompila el
procedimiento. Por último se verifica el caché por si ya existe un plan de ejecución para ese procedimiento
antes de generar un nuevo plan de ejecución.

La relativa pérdida de rendimiento producida por ubicar los planes de ejecución de los procedimientos
almacenados en el caché de procedimiento se reduce ya que los planes de ejecución para todos los comandos
SQL se guardan ahora en el caché de procedimientos. Por lo que un comando Transact-SQL tratará de utilizar
un plan de ejecución ya existente en todos casos posibles.
Marco de programación

Una vez que se crea un procedimiento almacenado, puede ser llamado todas las veces que sea necesario.
Esta capacidad provee modulación y habilita la reutilización del código. La reutilización del código mejora el
mantenimiento de la base de datos al aislar la base de datos de los cambios en las prácticas del negocio. Si
las reglas de negocios cambian en una organización, se puede modificar a los procedimientos almacenados
para cumplir con las nuevas reglas de negocio. Todas las aplicaciones que llaman a esos procedimientos
almacenados cumplirán con la nuevas reglas, sin tener que ser directamente modificados.

Tal y como otros lenguajes de programación, los procedimientos almacenados pueden aceptar parámetros de
ingreso, retornar parámetros de salida, producir información de retroalimentación de la ejecución en la forma
de códigos de estatus y texto descriptivo, y llamar a otros procedimientos. Por ejemplo, un procedimiento
almacenado puede retornar un código de estatus a un procedimiento que lo llamó para que este
procedimiento realice una operación según el código recibido.

Los desarrolladores de software pueden escribir sofisticados en un lenguaje como el C++; luego, se puede
utilizar un tipo especial de procedimiento almacenado, denominado procedimiento almacenado extendido,
para invocar al programa desde dentro del SQL Server.

Ante cualquier tarea simple, se debería escribir un procedimiento almacenado. Mientras más genérico sea el
procedimiento más útil será para muchas bases de datos. Por ejemplo; el procedimiento almacenado
sp_rename cambia el nombre de un objeto creado por el usuario, tal como una tabla, una columna o un tipo
de datos definido por el usuario en la base de datos actual, pudiéndose aplicar a cualquier base de datos.

Seguridad

Otro capacidad importante de los procedimientos almacenados es que mejoran la seguridad a través de la
encriptación y el aislamiento. Los usuarios de las bases de datos pueden tener permisos de ejecutar un
procedimiento almacenado sin tenerlos para acceder directamente a los objetos de la bases de datos sobre
las que opera el procedimiento almacenado. Además un procedimiento almacenado puede ser encriptado
cuando se lo crea o modifica inhabilitando a los usuarios a leer los comandos Transact-SQL contenidos en el
procedimiento almacenado. Estas capacidad de seguridad permiten aislar la estructura de la base de datos
del usuario de la base de datos, con la consiguiente ganancia en seguridad.

Categorías de procedimientos almacenados

Existen cinco categorías de procedimientos almacenados: procedimientos almacenados del sistema,

procedimientos almacenados locales, procedimientos almacenados temporarios, procedimientos almacenados
extendidos y procedimientos almacenados remotos.

Procedimientos almacenados del sistema

Los procedimientos almacenados del sistema son guardados en la base de datos Master y son típicamente
identificados por el prefijo sp_ . Ellos realizan una amplia variedad de tareas para soportar las funciones del
SQL Server soportando: llamadas de aplicaciones externas para datos de las tablas del sistema,
procedimientos generales para administración de las bases de datos, y funciones de administración de
seguridad. Por ejemplo, se pueden ver los privilegios de una tabla usando el procedimiento almacenado de
catálogo sp_table_privileges. El comando siguiente utiliza este procedimiento almacenado para mostrar los
privilegios de la tabla stores en la base de datos Pubs:

USE Pubs
GO
EXECUTE sp_table_privileges Stores

Una tarea común de administración de bases de datos es consultar la información acerca de los usuarios y
procesos que se están ejecutando en una base de datos. Este paso es importante cuando se debe dar de baja
la base de datos. El siguiente comando usa el procedimiento sp_who para mostrar todos los procesos en uso
por el usuario LAB1\Administrator:

EXECUTE sp_who @loginame=’LAB1\administrator’

La seguridad de base de datos es crítica para la mayoría de las organizaciones que almacenan datos privados
en su base de datos. El comando siguiente usa el procedimiento almacenado del sistema sp_validatelogins
para mostrar cualquier usuario y grupo de usuarios Windows NT o Windows 2000 huérfanos que no existan
más y que aún tengan entradas en las tablas del sistema del SQL Server:

EXECUTE sp_validatelogins

Hay cientos de procedimientos almacenados del sistema incluidos con el SQL Server. Para una lista completa
de los procedimientos almacenados, consultar “System Store Procedures” en SQL Server Books Online.

Procedimientos almacenados locales

Los procedimientos almacenados locales son usualmente almacenados en una base de datos y están
típicamente diseñados para completar tareas en la base de datos donde residen. Un procedimiento
almacenado local se podría crear también para personalizar código de los procedimientos almacenados del
sistema. Para crear una tarea personalizada basada sobre un procedimiento almacenado del sistema, primero
copie el contenido del procedimiento almacenado del sistema y guarde el nuevo procedimiento almacenado y
guarde el nuevo procedimiento almacenado como un procedimiento almacenado local.

Procedimientos almacenados temporarios

Un procedimiento almacenado temporario es similar a un procedimiento almacenado local, pero existe sólo
hasta que se cierre la conexión que lo creó o se dé de baja el SQL Server, dependiendo del tipo de
procedimiento almacenado. Estos procedimientos tienen una existencia volátil debido a que son creados son
almacenados en la base de datos TempDB. TempDB se recrea cuando se reinicia el servidor; por lo tanto,
todos los objetos dentro de la base de datos desaparecen después de la base de datos. Los procedimientos
almacenados temporarios son muy útiles si Ud. está accediendo a versiones anteriores del SQL Server que no
soportan la reutilización de los planes de ejecución y si no se quiere almacenar las tareas que serán
ejecutadas con distintos parámetros.

Hay tres tipos de procedimiento almacenado temporarios: locales (también llamados privados), globales, y
procedimientos almacenados en TempDB. Un procedimiento almacenado temporario local siempre comienza
con #, un procedimiento almacenado temporario global siempre comienza con ##. Mas adelante se explicará
como crear cada tipo de procedimiento almacenado temporario. El alcance de ejecución de un procedimiento
almacenado local esta limitado a la conexión que lo creó. Todos los usuarios que tienen conexión a la base de
datos, sin embargo, pueden ver el procedimiento almacenado en la ventana del Object Browser del Query
Analizer. Dado que se encuentra limitado en su alcance, no existe la posibilidad de colisión de nombres con
otras conexiones que crean procedimientos almacenados temporarios. Para asegurar unicidad, SQL Server
agrega al nombre de un procedimiento almacenado con una serie de caracteres _ y un número único de
conexión. Los privilegios no pueden ser garantizado a otros usuarios para el procedimiento almacenado
temporario. Cuando la conexión que creó el procedimiento almacenado temporario se cerró, el
procediemiento se elimina de la TempDB.

Cualquier conexión para la base de datos puede ejecutar un procedimiento almacenado temporario global.
Este tipo de procedimientos debe tener un nombre único , dado todas las conexiones pueden ejecutarlo y,
cómo todos los procedimientos almacenados temporarios, este es creado en TempDB. El permiso para
ejecutar procedimientos almacenados es automáticamente garantizado al rol público y no puede ser
cambiado. Un procedimiento almacenado temporario global es casi tan volátil como los locales. Este tipo de
procedimiento es removido cuando la conexión usada para crear el procedimiento se cierra y cualquier
conexión que este ejecutando el procedimiento almacenado es completada.

Los procedimientos almacenados temporarios creados directamente en la TempDB son diferentes a los
procedimientos almacenados locales y globales en lo siguiente:
  Se pueden configurar permisos para ellos.

 Existen aún después que la conexión que los creó se terminan

 No son removidos hasta que el SQL Server no sea apagado.

Ya que este tipo de procedimiento almacenado se crea directamente en la TempDB, es importante calificar
completamente los objetos de base de datos referenciados por comandos Transact-SQL en el código. Por
ejemplo, se debe referenciar la tabla Authors, la cual es propiedad de dbo en la base de datos Pubs, como
pubs.dbo.authors.

Procedimientos almacenados extendidos

Un procedimiento almacenado extendido usa un programa externo, compilado como una DLL, librería de
vínculos dinámicos (dynamic link library) para expandir las capacidades de un procedimiento almacenado. Un
número de procedimiento almacenado del sistema son también calificados como procedimientos almacenados
extendidos. Por ejemplo, el programa xp_sendmail, el cual envía un mensaje y un archivo de conjunto de
resultados de una consulta adjunto a una dirección específica de email, es tanto un procedimiento
almacenado de sistema como un procedimiento almacenado extendido. La mayoría de los procedimientos
almacenados extendidos usan el prefijo xp_ como un convención de nombre. Sin embargo, hay algunos
procedimientos almacenados extendidos que comienzan con el prefijo sp_, y hay algunos procedimientos
almacenados del sistema que no son procedimientos extendidos y usan el prefijo xp_. Por lo tanto, no se
puede depender sobre convención de nombres para identificar procedimientos almacenados del sistema y
procedimientos almacenados extendidos.

Se puede usar la función OBJECTPROPERTY para determinar si un procedimiento almacenado es extendido o

no. OBJECTPROPERTY retorna un valor de 1 si es un procedimiento extendido (IsExtendedProc), indicando un
procedimiento almacenado extendido, o retorna un valor de 0, indicando que no es un procedimiento
extendido. El siguiente ejemplo demuestra que el sp_prepare es un procedimiento almacenado extendido y
que xp_logininfo no es un procedimiento almacenado extendido:

USE Master

 un procedimiento almacenado extendido que usa el prefijo sp_ SELECT

OBJECTPROPERTY(object_id(‘sp_prepare’), ‘IsExtendedProc’)

Este ejemplo retorna un valor de 1

USE Master

 un procedimiento almacenado que no es extendido y usa el prefijo xp_ SELECT

OBJECTPROPERTY(object_id(‘xp_logininfo’), ‘IsExtendedProc’)

Este ejemplo retorna un valor de 0.

MODULO IV: Implementar procedimientos almacenados

TEMA 2: Creando, ejecutando, modificando y borrando procedimientos

almacenados

Como se guarda un procedimiento

Cuando se crea un procedimiento, SQL Server chequea la sintaxis de los comandos Transact-SQL que
incluye. Si la sintaxis es incorrecta, SQL Server generará un mensaje de error “sintax incorrect” (sintaxis
incorrecta), y el procedimiento no será creado. Si el procedimiento pasa el chequeo de sintaxis, el
procedimiento se guarda, escribiéndose su nombre y otras informaciones (tal como un número autogenerado
de identificación) en la tabla SysObject. El texto usado para crear el procedimiento se escribe en la tabla
SysComments de la base de datos actual.

El siguiente comando SELECT consulta a la tabla SysObjects en la base de datos Pubs para mostrar el
número de identificación del procedimiento almacenado ByRoyalty:

SELECT [name].[id] FROM [pubs].[dbo].[SysObjects]

WHERE [name] = ‘byroyalty’

Esta consulta retorna lo siguiente:

name id
byroyalty 581577110

Usando la información retornado de la tabla SysObjects, el próximo comando SELECT consulta a la tabla
SysComments al usar el número de identificación del procedimiento almacenado ByRoyalty:

SELECT [text] FROM [pubs].[dbo].[SysComments]

WHERE [id] = 581577110

Esta consulta retorna el texto del procedimiento almacenado, cuyo número de identificación es el 581577110.

Usar el procedimiento almacenado de sistema sp_helptext es una mejor opción para mostrar el texto usado
para crear un objeto (tal como un procedimiento almacenado no encriptado), dado el texto es retornado en
múltiples filas.

Métodos para crear procedimientos almacenados

SQL Server provee muchos métodos que se pueden usar para crear un procedimiento almacenado: el
comando Transact-SQL CREATE PROCEDURE, SQL-DMO (usando el objeto StoredProcedure y escapa alcance
de este Kit), a través del árbol de consola del Enterprise Manager, el asistente para crear procedimientos
almacenados (al cual se puede acceder a travé del Enterprise Manager).

El comando CREATE PROCEDURE

Se puede usar el comando CREATE PROCEDURE, o su versión abreviada, CREATE PROC, para crear un
procedimiento almacenado en el Query Analyzer o una herramienta de comando como osql. Cuando utiliza
CRETE PROC, se pueden realizar las siguientes tareas:

 Especificar agrupamientos de procedimientos almacenados

 Definir parámetros de entrada-salida, sus tipos de datos, y sus valores por defecto. Cuando se
definen parámetros de entrada y salida, estos siempre van precedidos por el signo @, seguido del
nombre del parámetro y luego una designación del tipo de dato. Los parámetros de salida deben
incluir la palabra clave OUTPUT para diferenciarlos de los de entrada.

 Usar códigos de retorno para mostrar información acerca del éxito o falla de una tarea.
  Controlar si un plan de ejecución debería ser guardado temporariamente (en el cache) para un
procedimiento.

 Encriptar el contenido del procedimiento almacenado por razones de seguridad.

 Especificar las acciones que deberá tomar el procedimiento almacenado cuando se ejecute.

Proveer de contexto a un procedimiento almacenado

Con la excepción de los procedimiento almacenado temporarios, un procedimiento almacenado se crea

siempre en la base de datos actual. Por lo tanto, Ud. siempre debería especificar la base de datos actual
usando el comando USE nombre_base seguido por el por el comando GO ntes de crear un procedimiento
almacenado- Se puede usar la lista desplegable Cahnge Database en el Query Analizer para seleccionar la
base de datos actual.

El script siguiente selecciona la base Pubs y luego crea un procedimientos llamado ListAuthorNames (lista de
los nombres de los autores) , que pertenece a dbo:

USE Pubs

GO

CREATE PROCEDURE [dbo].[ListAuthorNames]

AS

SELECT [au_fname], [aufname] FROM [pubs].[dbo].[authors]

Fíjese que el nombre del procedimiento está totalmente calificado en el ejemplo. Un nombre de procedimiento
almacenado totalmente incluye el nombre de su propietario (en este caso dbo) y el nombre del procedimiento,
ListAuthorNames. Se especifica dbo como propietario si se quiere asegurar que la tarea del procedimiento
almacenado correrá sin importar la tabla propietaria en la base de datos. El nombre de la base de datos no es parte
del nombre totalmente calificado de un procedimiento almacenado cuando se usa el comando CREATE
PROCEDURE.

Crear procedimientos almacenados temporarios

Para crear un procedimiento almacenado temporal local, agregue adelante del nombre del procedimiento el
símbolo #. Este signo numeral instruye al SQL Server para que cree el procedimiento en la TempDB. Para
crear un procedimiento almacenado temporario global, , se agrega adelante del nombre del procedimiento un
doble símbolo numeral ##, que también será creado en la TempDB. SQL Server ignora la base de datos
actual cuando crea un procedimiento temporario. Por definición, un procedimiento almacenado sólo puede
existir en la TempDb. Para crear un procedimiento almacenado directamente en la TempDB que no es ni local
ni global haga que la TempDB sea la base de datos actual y luego cree el procedimiento. El ejemplo siguiente
crea un procedimiento almacenado temporario local, un procedimiento almacenado temporario global y un
procedimiento directamente en la TempDB:

 crear un procedimiento temporario local

CREATE PROCEDURE #localtemp

AS

SELECT * from [pubs].[dbo].[authors]

GO
 crear un procedimiento temporario global

CREATE PROCEDURE #globaltemp

AS

SELECT * from [pubs].[dbo].[authors]

GO

 crear un procedimiento almacenado temporario que sea local en tempdb

USE TEMPDB

GO

CREATE PROCEDURE directtemp

AS

SELECT * from [pubs].[dbo].[authors]

GO

Nombres de bases de datos totalmente calificadas son especificadas en los comandos SELECT. Si el
procedimiento no se ejecuta en el contexto de una base de datos específica, luego nombre de bases de datos
totalmente calificadas aseguran que se está referenciando a la base de datos apropiada.

En el tercer parte del ejemplo, cuando se crea un procedimiento almacenado temporario directamente en la
base de datos TempDB, se debe hacer a la base de datos TempDB la base actual antes de crearlo, o se debe
calificar totalmente el nombre ([TempDb].[dbo].[directtemp]). Tal como los procedimientos almacenados del
sistema, que se guardan en la base Masters, los procedimientos almacenados temporarios locales y globales
están disponibles para ser usados por su nombre corto (sin importar la base de datos actual).

Agrupar, almacenar temporariamente en memoria y encriptar procedimientos almacenados

Los procedimientos almacenados puedes ser agrupados lógicamente al momento de su creación. Esta técnica
es muy útil para procedimientos almacenados que deberían ser administrados cono una unidad independiente
y que son usados por una aplicación específica. Para agrupar procedimientos almacenados, se debe asignar a
cada procedimiento del grupo el mismo nombre y agregarle un número único separado por un punto y coma.
Por ejemplo: el denominar a dos procedimientos almacenados con ProcAgrupado;1 y ProcAgrupado;2 al
momento de su creación, los agrupa lógicamente. Cuando se ve el contenido de ProcAgrupado, se ve el
código para ambos ProcAgrupado;1 y ProcAgrupado;2.

Por defecto, un plan de ejecución de un procedimiento almacenado se guarda en memoria temporal (cacheo)
la primera vez que se ejecuta, y no es cacheado de nuevo hasta que el servidor se reinicie o hasta que la
estructura de una tabla usada por el procedimiento almacenado cambie. Por razones de performance se
podría no querer cachear un plan de ejecución de un procedimiento almacenado. Por ejemplo, cuando los
parámetros de un procedimiento almacenado varían considerablemente de una ejecución a la siguiente,
cachear un plan de ejecución es contraproducente. Para provocar que un procedimiento almacenado sea
recomplilado cada vez que se ejecuta, agregue las palabras claves WITH RECOMPILE cuando crea el
procedimiento almacenado. Se puede también forzar una recompilación mediante el uso del procedimiento
almacenado del sistema sp_recompile o especificando WITH RECOMPILE cuando se ejcuta el procedimiento.

Encriptar un procedimiento almacenado protege su contenido de ser visto. Para encriptar un procedimiento
almacenado, use la palabra clave WITH ENCRYPTION cuando crea el procedimiento. Por ejemplo, el código
siguiente crea un procedimiento encriptado llamado Protected:
USE Pubs

GO

CREATE PROC [dbo].[protected] WITH ENCRYPTION

AS

SELECT [au_fname], [au_lname] FROM [pubs].[dbo].[authors]

Las palabras claves WITH ENCRYPTION encriptan la columna de texto del procedimiento almacenado en la
tabla SysComments. Un modo simple para determinar si un procedimiento almacenado está encriptado es
usar la función OBJECTPROPERTY:

• controla si el procedimiento almacenado esta encriptado retornando 1 para IsEncrypted

SELECT OBJECTPROPERTY(object_id(‘protected’), ‘IsEncrypted’)

O llamando al procedimiento con sp_halptext:

• si el procedimiento esta encriptado, retorna “The objects comments have been encrypted.”

EXEC sp_helptext protected

Un procedimiento almacenado encriptado no puede ser replicado. Después que un procedimiento almacenado
es encriptado, SQL Server lo desencripta para sólo para su ejecución. Su definición no puede ser
desencriptada para ser vista por nadie, incluido el propietario del procedimiento almacenado. Por lo tanto, se
debe estar seguro que se cuenta con una copia en algún lugar seguro antes de encriptar un procedimiento
almacenado.

Enterprise Manager

Se puede crear un procedimiento almacenado directamente en el Enterprise Managrer. Para ello, se expande
el árbol de la consola para su servidor y luego se expande la base de datos donde se creará el procedimiento
almacenado. Clic derecho sobre el nodo Stored Procedure, y luego clic sobre New Stored Procedure. Cuando
aparezca el cuadro de diálogo Stored Procedure Properties – New Stored Procedure se ingresa el contenido
del nuevo procedimiento almacenado. La figura muestra el cuadro de diálogo Stored Procedure Properties –
New Stored Procedure que contiene el código del ejemplo anterior.
Se puede, además, controlar la sintaxis del procedimiento almacenado antes de su creación y guardar una
plantilla que aparecerá siempre que se cree un nuevo procedimiento almacenado y se configuren permisos.
Una vez que el procedimiento almacenado se crea, se puede abrir las propiedades del procedimiento y
configurar los permisos. Por defecto el propietario del procedimiento y el administrador tienen permisos
totales sobre el procedimiento almacenado.

Las plantillas son muy útiles porque proveen un marco de trabajo para crear documentación consistente
sobre los procedimientos almacenados. Comúnmente se agrega texto al encabezamiento que describe como
se deberá documentar cada procedimiento almacenado que se crea.

El asistente Create Stored Procedure

El asistente Create Stored Procedure (crear procedimientos almacenados) permite crear nuevos
procedimientos almacenados paso a paso. Se puede acceder al asistente seleccionando Wizars (asistentes)
desde el menú Tools (herramientas). En la ventana Select Wizard (seleccionar asistente), expandir la opción
Database (base de datos), y luego seleccionar Create Stored Procedure Wizard (asistente para crear
procedimientos almacenados) y presionar Ok. A partir de quí se deben completar los pasos indicados por el
asistente. La Figura muestra la pantalla de bienvenida del Create Stored Procedure Wizard mostrando las
cosas que se pueden hacer con él.
El asistente Create Stores Procedures lo habilita para que Ud. cree procedimientos que inserten, eliminen, o
actualicen datos en las tablas. Para modificar los procedimientos almacenados que crea el asistente, se puede
editarlos dentro del asistente o utilizar otras herramientas (como el Query Analizer).

Crear y agregar procedimientos almacenados extendidos

Después de crear un procedimiento almacenado extendido, se debe registrar con SQL Server. Sólo los
usuarios que tiene permisos de administrador pueden registrar un procedimiento almacenado con el SQL
Server. Para registrar un procedimiento almacenado extendido, se puede usar el procedimiento del sistema
sp_addextendedproc en el Query analyzer o usar el Enterprise Manager. En el Enterprise Manager, expanda
la base de datos Master, clic derecho sobre el nodo Extended Stored Procedure (procedimiento almacenado
extendido), y clic sobre la opción New Extended Stored Procedure (nuevo procedimiento almacenado
extendido). Los procedimientos almacenados extendidos sólo pueden ser agregados a la base de datos
Master.

Resolución diferida de nombres

Cuando se crea un procedimiento almacenado, SQL Server no controla por la existencia de los objetos que
este pueda referenciar. Esto es así porque es posible que un objeto, tal como una tabla referenciada en un
procedimiento almacenado no existe al momento de la creación del procedimiento almacenado. Esta
capacidad se denomina resolución diferida de nombres. La verificación de la existencia de los objetos se
produce al momento de la efectiva ejecución del procedimiento.

Cuando se refiere a un objeto (como una tabla) en un procedimiento almacenado se debe asegurar que se
especifica el propietario del objeto. Por defecto, SQL Server asume que el creador del procedimiento
almacenado es también el propietario de los objetos referenciados en el procedimiento. Para evitar confusión,
considere especificar a dbo como el propietario de todos objetos (tanto los procedimientos almacenados
como los objetos referenciados dentro de estos).

Ejecutar un procedimiento almacenado

Como ya vimos, se puede correr un procedimiento almacenado en el Query Analyzer simplemente ingresando
su nombre y cualquier parámetro requerido. Por ejemplo se vió el contenido de un procedimiento
almacenado ingresando sp_helptext seguido del nombre del procedimiento almacenado a ser visto. El
nombre del procedimiento almacenado a ser visto es en este caso el valor del parámetro.

Si el procedimiento almacenado no es el primer comando en un batch, para ejecutarlo se debe preceder el

nombre del procedimiento con las palabras claves EXECUTE o EXEC.

Llamar un procedimiento almacenado para ejecución

Cuando se especifica el nombre de un procedimiento, el nombre puede ser totalmente calificado, tal como
[nombre_base].[propietario].[nombre_proc] o, si la base que contiene al procedimiento es la base actual,
mediante el comando USE, entonces se puede ejecutar el procedimiento almacenado especificando sólo
[propietario].[nombre_proc]. Si el nombre de el nombre del procedimiento es único en la base de datos
activa, se puede simplemente especificar [nombre_proc].

Nota: En este tema se han utilizado los identificadores entre [] en los nombres de los objetos, aún cuando
dichos nombres no violan la reglas de nombres de objetos, con fines de claridad de los ejemplos.

Nombres totalmente calificados no son necesarios cuando se ejecutan procedimientos del sistema que tienen
el prefijo sp_, ni para procedimientos almacenados temporarios locales, o globales. SQL Server buscará en la
base Master por cualquier procedimiento almacenado que tenga el prefijo sp_ donde el propietario sea dbo.
Para evitar confusión, no se debe nombrar procedimientos almacenados locales con los mismos nombres de
procedimientos almacenados en la base Master. Si ello ocurre, se debe asegurar que el propietario de la base
sea otro que dbo. SQL Server no busca automáticamente en la base master por procedimientos
almacenados extendidos, Por lo tanto, o se lo invoca por su nombre totalmente calificado o se cambia la base
actual a la que pertenece el procedimiento.

Especificar parámetros y sus valores

Si un procedimiento almacenado requiere valores de parámetros, se deben especificar cuando se ejecuta el

procedimiento. Cuando se definen parámetros de entrada y salida se los precede del símbolo @, seguido por
el nombre del parámetro y la designación del tipo de dato. Cuando se los invoca para ser ejecutados, se debe
incluir un valor para el parámetro (y opcionalmente, el nombre del parámetro). Los próximos dos ejemplos
corren el procedimiento almacenado au_info de la base Pubs con dos parámetros: @lastname (apellido) y
@firstname (nombre):

--llama al procedimiento almacenado con los valores de los parámetros

USE Pubs

GO

EXECUTE au_info Green, Marjorie

--llama al procedimiento alamcenado con los valores y nombres de los parámetros

USE Pubs

GO

EXECUTE au_info

Green, Marjorie

@lastname = ‘Green’, @firstname = ‘Marjorie’

En el primer ejemplo, los valores de los parámetros fueron especificados pero los nombres no. Si se especifican los
valores sin sus correspondientes nombres, los valores se deben indicar en el mismo orden con se especificaron en
la definición del procedimiento. En el segundo ejemplo, los nombres y los valores son ambos indicados. En este
caso, se los puede poner en cualquier orden. Aquellos parámetros a los que se les especifica un valor por defecto en
la definición del procedimiento no necesitan ser obligatoriamente especificados cuando se los llama.

La lista siguiente muestra algunas sintaxis opcionales disponibles cuando se ejecuta un procedimiento almacenado:

 Un variable de código de retorno de tipo entero (integer) para almacenar valores retornados desde el
procedimiento almacenado. La palabra clave RETURN con un valor (o unos valores) debe ser
especificada en el procedimiento almacenado para que este variable opcional funcione.
 Un punto y coma seguida por un número de grupo. Para procedimientos almacenados agrupados, se
puede o ejecutar todos los procedimientos en el grupo simplemente especificando el nombre del
procedimiento almacenado, o se puede incluir un número para indicar cual procedimiento almacenado
se desea ejecutar. Por ejemplo, si se crean dos procedimientos almacenados llamados
ProcAgrupado;1 y ProcAgrupado;2, se puede correr a ambos ingresando EXEC ProcAgrupado. O, se
puede ejecutar el procedimiento 2 escribiendo EXEC ProcAgrupado;2. Si se definen parámetros en los
procedimientos almacenados agrupados, cada nombre de parámetro debe ser único en el grupo.
 Variables para mantener los parámetros definidos en el procedimiento almacenado. Las variables son
definidas con el uso de la palabra clave DECLARE antes de usar EXECUTE.

Ejecutar procedimiento almacenado cuando arranca SQL Server

Ya sea por razones de performance, administración, o cumplimiento de tareas, se puede indicar que al arrancar el
SQL Server se ejecuten procedimientos almacenados. Se utiliza para ello el procedimiento almacenado
sp_procoption. Este procedimiento acepta tres parámetros: @ProcName, @OptionName y @OptionValue. El
comando siguiente configura un procedimiento almacenado llamado AutoStart para que arrnque automáticamente:

USE Master

GO

EXECUTE sp_procoption

@procname = autostart,

@optionname = startup,

@optionvlue = true

Sólo los procedimientos de dbo y ubicados en la base master pueden ser configurados para ejecutarse
automáticamente. Para ejecutar al arrancarse el SQL Server a procedimientos ubicados en otras bases deberán ser
llamados desde un procedimiento almacenado ubicado en la Master y configurado para arrancar automáticamente.
Llamar a un procedimiento desde otro se denomina llamadas anidadas.

Se puede configurar a un procedimiento para que arranque automáticamente desde el Enterprise Manager. Se
accede a la base Master, se hace clic en el nodo Stored Procedures. Se selecciona al procedimiento almacenado, y
luego clic derecho. Se abre el cuadro de diálogo Properties (Propiedades) y se marca la casilla de selección Execute
Whenever SQL Server Start (ejecutar siempre que el SQL Server arranca).

Para determinar si un procedimiento almacenado arranca automáticamente, se puede ejecutar la función

OBJECTPROPERTY y controlar la propiedad ExecIsStartup. Por ejemplo el código siguiente invoca a la función
para determinar si el procedimiento AutoStart está configurado para ejecutarse automáticamente:

USE Master

SELECT OBJECTPROPERTY(object_id(‘autostart’), ‘ExecIsStartup’)

Para deshabilitar procedimientos para que no continúen ejecutándose automáticamente, se puede correr el
procedimiento almacenado sp_configure. El siguiente comando configura al SQL Server para que los
procedimientos almacenados configurados para ejecutarse automáticamente no se arranquen la próxima vez que se
encienda el SQL Server:

EXECUTE sp_configure

@configname = ‘scan for startup procs’, @configvalue = 0

RECONFIGURE

GO

Modificar procedimientos almacenados

Se puede usar el comando ALTER PROCEDURE (ALTER PROC en su versión abreviada),para modificar el
contenido de un procedimiento almacenado de usuario, utilizando el Query Analyzer o una herramienta de
comandos como osql. La sintaxis del comando ALTER PROCEDURE es casi idéntica a la del CREATE
PROCEDURE.

La ventaje de usar el comando ALTER PROCEDURE en vez de eliminar el procedimiento y crearlo de nuevo es
que con este comando se retiene la mayoría de la propiedades configuradas para el procedimiento, tales como su
ID. El conjunto de permisos, y su bandera de arranque. Para mantener la encriptación o la configuración de
recompilación, se debe especificar con las palabras claves WITH ENCRYPTION o WITH RECOMPILE cuando
se ejecuta ALTER PROCEDURE.

Se puede usar el Enterprise Manager o el Query Analyzer para modificarprocedimientos almacenados de usuario.
En el Enterprise Manager, clic derecho sobre el procedimiento almacenado y luego clic en Properties. En el cuadro
de diálogo Stored Procedure Properties, modifique los comandos del procedimiento que aparecen en la caja Text, y
luego clic en OK. Usando el Query Analyzer, clic derecho en el procedimiento almacenado y clic en Edit. Después
de modificar un procedimiento almacenado ejecútelo.

Para modificar el nombre de un procedimiento almacenado definido por el usuario, se usa el procedimiento
almacenado sp_rename. El comando siguiente renombra el procedimiento almacenado ByRoyalty a
RoyaltyByAuthorID:

USE PUBS

GO

EXECUTE sp_rename

@objname = ‘byroyalty’, @newname = ‘RoyaltyByAutorID’,

@objtype = ‘object’

Procedimientos almacenados definidos por el usuario pueden ser renombrados en el Enterprise Manager haciendo
clic derecho en el nombre del procedimiento almacenado y clic en Rename (renombrar)

Se deberá tener cuidado cuando se renombre un procedimiento almacenado u otros objetos, como tablas. Los
procedimientos almacenados pueden ser anidados. Si se produce una llamada a un objeto renombrado, el
procedimiento que llama no podrá ubicar al objeto renombrado y generará un mensaje de error.
Eliminar procedimientos almacenados

Se puede usar el comando DROP PROCEDURE, o su versión abreviada DROP PROC, para eliminar un
procedimiento almacenado definido por el usuario, varios procedimientos a la vez o un conjunto de procedimientos
agrupados. El comando siguiente borra dos procedimientos en la base de datos Pubs: Procedure01 y Procedure02:

USE Pubs

GO

DROP PROCEDURE procedure01, procedure02

Fíjese que primero se configuró a Pubs como la base actual. No se puede especificar un nombre de base de datos
cuando se elimina un procedimiento. El nombre totalmente calificado para eliminar procedimientos es
[propietario].[nombre_procedimiento]. Si se ha creado un procedimiento almacenado del sistema definido por el
usuario (con prefijo sp_), el comando DROP PROC buscará primero en la base actual y luego en la Master.

Para borrar un grupo de procedimientos almacenados, especifique el nombre del procedimiento. No se puede
borrar parte de un grupo de procedimientos almacenados con el comando DROP PROCEDURE. Por ejemplo si se
tiene un grupo de procedimientos llamados ProcAgrupados conteniendo ProcAgrupados;1 y ProcAgrupados;2 no
se puede borrar ProcAgrupados;1 sin borrar ProcAgrupados;2. Si se necesita eliminar un procedimiento dentro de
un grupo de procedimientos, se elimina el grupo y luego se lo recrea sin el procedimiento a eliminar.

Los cuidados indicados al final del punto anterior también son válidos para las operaciones de eliminación.

MODULO IV: Implementar procedimientos almacenados

TEMA 3: Programar procedimientos almacenados

Parámetros y variables

Los parámetros y las variables son una parte fundamental de hacer dinámico a un procedimiento almacenado. Los
parámetros de entrada habilitan al usuario que está ejecutando el procedimiento a pasar valores al procedimiento
almacenado. Los parámetros de salida amplían la salida de los procedimientos almacenados mas allá del conjunto
de resultados retornado por una consulta. Los datos desde un parámetro de salida son capturados en memoria
cuando el procedimiento se ejecuta. Para retornar un valor desde el parámetro de salida se debe crear una variable
para que lo mantenga. Se puede mostrar el valor con los comando SELECT o PRINT, o usar el valor para
completar otro comando en el procedimiento.

En resumen, un parámetro de entrada se define en el procedimiento almacenado y un valor es provisto cuando el

procedimiento se ejecuta. Un parámetro de salida se define usando la palabra clave OUTPUT. Cuando se ejecuta el
procedimiento, se guarda en memoria un valor para el parámetro de salida. Para utilizarlo, se declara una variable
para mantener al valor. Los valores de salida típica de muestran en pantalla una vez que terminó la ejecución del
procedimiento.

El siguiente procedimiento muestra el uso de ambos parámetros, de salida y de entrada:

USE Pubs

GO
CREATE PROCEDURE dbo.SalesForTitle

@Title.varchar(80), --Parámetro de entrada

@YtdSales int OUTPUT, --Primer parámetro de salida

@TitleText varchar(80) OUTPUT –Segundo parámetro de salida

AS

-- Asigna la columna de datos a los parmetros de salida y

-- controla por un título que coincida con el parámetro de entrada

SELECT @YtdSales = ytd_sales, @TitleText = title

FROM titles WHERE title LIKE @Title

GO

El parámetro de entrada es @Title (título), y los de salida son @YtdSales y @TitleText. Fíjese que los tres
parámetros tienen definidos sus tipos de datos. Los parámetros de salida incluye la palabra clave OUTPUT.
Después que se definen los parámetros, el comando SELECT utiliza a los tres parámetros. Primero, a los
parámetros de salida se les asigna a las columnas de la consulta. Cuando se ejecuta la consulta, los parámetros de
salida contendrán los valores de esas dos columnas. La cláusula WHERE del comando SELECT contiene el
parámetro de entrada, @Title. Cuando se ejecuta el procedimiento, se debe proveer un valor para el parámetro de
entrada o fallará la consulta.

El siguiente comando ejecuta el procedimiento almacenado que vimos:

-- Declara variables para recibir las salidas del procedimiento

DECLARE @y_YtdSales int, @t_TitleText varchar(80)

EXECUTE SalesForTitle

-- configura los valores de variables con los parámetros de salida

@YtdSales = @y_YtdSales OUTPUT,

@Titletext = @t_TitleText OUTPUT,

@Title = “%Garlic%” – especifica un valor para el parámetro de entrada

-- Muestra las variables retornadas por el procedimiento

SELECT “Title” = @t_TitleText, “Número de Ventas” = @y_YtdSales

GO

Se declaran dos variables: @y_YtdSales y @t_TitleText. Estas dos variables recibirán los valores almacenados en
los parámetros de salida. Advierta que el tipo de datos de la variables que reciben son los mismos que los tipos de
los correspondientes parámetros de salida. Estas dos variables pueden tener el mismo nombre que los parámetros
de salida correspondientes dado que las variables en un procedimiento almacenado son locales al batch que las
contiene. Por claridad, los nombres de las variables son diferentes a los de los parámetros de salida. Cuando se
declara una variable, esta no se asigna con un parámetro de salida. Las variables son asignadas con parámetros de
salida después del comando EXECUTE. Fíjese que la palabra OUTPUT se indica cuando el parámetro se asigna a
la variable. Si no se especifica OUTPUT, la variable no puede mostrar los valores en el comando SSELECT al
final del código. Por ‘ultimo, el parámetro de entrada @Title es igualado a %Garlic%. Este valor se envía a la
cláusula WHERE del comando SELECT del procedimiento almacenado. Dado que la cláusula WHERE usa la
palabra clave KEYWORD, se pueden usar caracteres comodines (tal como %) para que que la consulta busque
aquellos títulos que contienen la palabra Garlic.

A continuación se muestra un modo mas sucinto de ejecutar el procedimiento. Fíjese que no es necesario asignar
específicamente las variables desde el procedimiento almacenado al valor del parámetro de salida o a las variables
de salida declaradas aquí:

DECLARE @y_YtdSales int, @t_TitleText varchar(80)

EXECUTE SalesForTitle

“%Garlic%”, -- configura el valor del parámetro de entrada

@y_YtdSales OUTPUT -- recibe el primer parámetro de salida

@t_TitleText OUTPUT -- recibe el segundo parámetro de salida

-- muestra las variables retornadas por la ejecución del procedimiento

SELECT “Title” = @t_TitleText, “Número de ventas” = @y_YtdSales

GO

Cuando se ejecuta el procedimiento, este retorna lo siguiente:

Title Number Return of Sales

NULL NULL

Un interesante resultado de este procedimiento es que se retorna sólo una fila. Aún cuando el comando SELECT en
el procedimiento devuelve múltiples filas, cada variable mantiene sólo un valor (la última fila de datos retornada).
Mas adelante veremos algunas soluciones a este problema.

El comando RETURN y el manejo de errores

A menudo, se necesita codificar para manejar errores. SQL Server provee funciones y comandos para tratar con los
errores que se producen durante la ejecución de un procedimiento almacenado. Las dos categorías primarias de
errores de computo, tales como una base no disponible o errores de usuarios. Se utilizan códigos de retorno y la
función @@ERROR para manejar errores que se producen cuando se ejecuta el procedimiento.

Los códigos de retorno pueden usarse para otros propósitos además de manejar errores. El comando RETURN se
usa para generar códigos y salidas de un batch, y puede proveer d cualquier valor entero al programa que llamador.
Veremos ejemplos de códigos que usan los códigos de retorno para proveer un valor tanto como para manejar
errores o para otros fines.

El comando RETURN se usa primariamente para el manejo de errores porque cuando se corre el comando
RETURN, el procedimiento almacenado termina inmediatamente.
Considere el procedimiento almacenado SalesForTitle del punto anterior. Si el valor especificado para el valor de
entrada (@Title) no existe en la base ded atos, ejecutar el procedimiento retorna el siguiente conjunto de
resultados:

Title Number Return of Sales Code

Onions, Leeks, and Garlic: Cooking Secrets of the Mediterranean 375 0

Es mas claro explicar el usuario que no se han encontrado registroa. El ejemplo siguiente muestra como modificar
el procedimiento almacenado SalesForTitle para usar un código de retorno (y proveer un mensaje mas útil):

ALTER PROCEDURE dbo.SalesForTitle

@Title varchar(80), @YtdSales int OUTPUT,

@titletext varchar (80) OUTPUT

AS

-- Controla para ver si el titulo esta la base. Sino, sale y devuelve 1

IF (SELECT COUNT(*) FROM titles WHERE title LIKE @Title) = 0

RETURN(1)

ELSE

SELECT @YtdSales = ytd_sales, @TitleText = title

FROM titles WHERE title LIKE @Title

GO

La sentencia IF posterior la palabra clave AS determina si el parámetro de entrada es provisto cuando el

procedimiento se ejecuta y si coincide con algún registro de la base de datos. Si la función COUNT retorna 0,
entonces el código de retorno es puesto en 1, RETURN(1). En otro caso, se ejecuta la consulta SELECT por las
ventas anuales y la información del libro. En este caso el código de retorno es igual a 0.

Para invocar el procedimiento se necesitan hacer algunos cambios. El ejemplo siguiente configura al parámetro de
entrada @Title igual a Garlic%:

--Agrega @r_Code para mantener el resultado

DECLARE @y_YtdSales int, @t_TitleText varchar(80), @r_Code int

-- Ejecuta el procedimeinto e iguala @r_Code al el procedimiento

EXECUTE @r_Code = SalesForTitle

@YtdSales = @y_YtdSales OUTPUT,

@TitleText = @t_TitleText OUTPUT,

@Title = "Garlic%"

-- Determina el valor de @r_Code y ejecuta el codigo

IF @r_Code = 0

SELECT "Title" = @t_TitleText,

"Number of Sales" = @y_YtdSales, "Return Code" = @r_Code

ELSE IF @r_Code = 1

PRINT 'No matching titles in the database. Return code=' + CONVERT(varchar(1),@r_Code)

GO

MODULO IV: Conectarse a un SQL Server

TEMA 1: Comenzando con ADO - ActiveX Data Objects

Definición

ADO en ActiveX Data Objets es un modelo de objetos de acceso a datos que se apoya sobre OLEDB. Permite
dirigir los datos que vienen de bases de datos relacionales (SQL Server, Oracle…), o de otras fuentes de
datos no relacionales como ficheros de texto, fuentes de datos que no son de Microsoft, etc. Es un medio
para acceder uniformemente a todos los tipos de datos. En cierta manera podemos decir que ODBC permite
acceder a bases de datos relacionales, mientras que OLEDB permite el acceso a todos los tipos de datos,
sean relacionales o no.

Este modelo de objetos se ha introducido como modelo de acceso de datos para IIS. Sus principales
características son las siguientes:

Mínimo tráfico en la red Thread Safe (soportando accesos concurrentes o multithread) Número mínimo de
capas entre las aplicaciones y los datos. Facilidad de utilización: modelo de objetos automatizado Tiene en
cuenta los conocimientos adquiridos por los desarrolladores sobre la otras tecnologías como DAO o RDO

Arquitectura tecnológica
OLEDB es una tecnología que tiene como objetivo resolver ciertas restricciones de ODBC. Esta tecnología
autoriza el acceso a todo tipo de datos, permitiendo administrar el aspecto de tener distribuidas las fuentes
de datos, y tiene en cuenta las restricciones de la web. Esta tecnología tiene como objetivo reemplazar a la
tecnología ODBC. ADO es el modelo de objetos que permite simplificar el acceso a esta tecnología.
Un proveedor OLEDB implementa las interfaces OLEDB. Permite a un usuario OLEDB alcanzar todo tipo de
fuentes de datos de una manera uniforme a través de este juego de interfaces documentado. En cierto
sentido, un proveedor OLEDB es similar a un driver ODBC que proporciona un mecanismo uniforme de acceso
a los datos relacionales. Los proveedores OLEDB no sólo proporcionan un mecanismo uniforme de acceso a
los datos relacionales, si no que también a datos no relacionales. Además, los proveedores OLEDB se
construyen sobre la base del modelo COM (Component Objet Model) mientras que los drivers ODBC están
basados en una especificación de APIs de C.

El modelo de objetos ADO

El esquema siguiente muestra los objetos y las relaciones existentes entre los objetos y el modelo.
Objetos y Colecciones del modelo de objetos ADO

Los objetos Connection, Recordset y Command son los objetos más significativos de este modelo.
Clásicamente, una aplicación las utiliza como:

Objeto o Colección Utilización

Objeto Connection Permite establecer las conexiones entre el cliente y el origen de datos
Objeto Command Permite realizar los comandos, como las consultas SQL o las actualizaciones de
una base de datos.
Objeto Recordset Permite ver y manipular los resultados de una consutla
Colección Parameters Es utilizada cuando la consulta del objeto Command necesita los parámetros.
Colección Errors La colección Errors y el objeto Error se acceden a través del objeto Connection, a
no ser que se produzca un error de proveedor . El objeto Error es diferente del
objeto Err de VB, en la medida en que no contiene los errores generados y
definidos por el proveedor, por lo tanto, permite obtener información precisa
sobre la causa del error.
Colección Fields La colección Fields y el objeto Field se utilizan a través del objeto Recordset, una
vez que éste contiene los datos.

Descripción de los objetos y colecciones

La colección Properties proporciona la información sobre las características de los diferentes objetos
Connection, Command, Recordset y Field. Cada objeto de Property es accesible a través de la colección
Properties de cada uno de estos objetos.

Colección Properties

Aunque ADO es un modelo del tipo jerárquico, los objetos de ADO, excepto Error, Field y Property pueden
crearse de forma autónoma, es decir, sin hacer referencia al objeto relacionado. Esto es diferente de los
objetos DAO y RDO, que requieren en la mayoría de los casos la creación del objeto Parent (por ejemplo, un
objeto DAO.Connection necesita un objeto DAO.Workspace para poder crearse).

ADO es un modelo de objetos que permite una gran flexibilidad al programador. Por consiguiente, hay
distintas posibilidades para lograr la misma tarea. Por ejemplo, para ejecutar una consulta, es posible usar el
método Execute del objeto Command o bien el del objeto Connection.
En resumen, este es un diagrama que muestra las relaciones entre los diferentes objetos que constituyen
ADO:

Ejemplos de ADO

Abrir y cerrar una conexión con una base de datos SQL Server usando el proveedor por defecto que es el
proveedor de OLEDB para ODBC

Sub ConnectionExample1()
Dim cn As ADODB.Connection
Set cn = New ADODB.Connection

' Abrir la conexión, especificando el nombre del origen de datos,

' id de usuario, y contraseña.
cn.Open "DSNPubs", "sa", ""

' Si la conexión está abierta, lo muestra.

If cn.State = adStateOpen Then
Debug.Print "Conexión abierta."
End If

' Cerrar la conexión.

cn.Close

End Sub

Abrir y cerrar una conexión con una base de datos SQL Server usando el proveedor OLEDB para SQL Server
que es el proveedor recomendado

Private Sub ConnectionExemple2()

Dim cn As New ADODB.Connection

cn.Provider = "SQLOLEDB"
cn.Open "Data Source=MySQLServerName;Initial Catalog=pubs;", "sa", ""

' Si la conexión está abierta, lo muestra.

If cn.State = adStateOpen Then
Debug.Print "Conexión abierta."
End If
' Cerrar la conexión.
cn.Close
Set cn = Nothing

End Sub

Abrir y cerrar un Recordset

Sub RecordsetExample() Dim rs As

New ADODB.Recordset ' Abrir el recordset, especificando la

sentencia SQL ' y la cadena
de conexión. rs.Open "Select * fromtitles","DSN=pubs;UID=sa"

' Bucle a través del recordset e impresión del primer campo.

Do While Not rs.EOF
Debug.Print rs(0)
rs.MoveNext
Loop

' Cerrar el recordset.

rs.Close
End Sub

Usar el método Execute del objeto Command para ejecutar una consulta de tipo texto

Sub CommandExample()
Dim cmd As New ADODB.Command
Dim rs As New ADODB.Recordset

' Establecer el comando conexión usando una cadena de conexión.

cmd.ActiveConnection = "DSN=pubs;UID=sa"
' Establecer el comando texto, y especificar que es
' una sentencia SQL.
cmd.CommandText = "Select * from titles"
cmd.CommandType = adCmdText

' Crear un recordset.

Set rs = cmd.Execute()

' Bucle a través del recordset e impresión del primer campo.

Do While Not rs.EOF
Debug.Print rs(0)
rs.MoveNext
Loop

' Cerrar el recordset.

rs.Close

End Sub

Usar el método Execute del objeto Command para ejecutar un procedimiento de almacenado

Sub ParameterExample()
Dim cmd As New ADODB.Command
Dim rs As New ADODB.Recordset
 Dim prm As ADODB.Parameter

' Establecer el comando conexión usando una cadena de conexión.

cmd.ActiveConnection = "DSN=pubs;uid=sa"

' Establecer el comando texto, y especificar que es

' una sentencia SQL.
cmd.CommandText = "byroyalty"
cmd.CommandType = adCmdStoredProc

' Establecer un nuevo parámetro para el procedimiento guardado.

Set prm = cmd.CreateParameter("Royalty", adInteger, adParamInput, , 50)
cmd.Parameters.Append prm

' Crear un recordset.

Set rs = cmd.Execute

' Bucle a través del recordset e impresión del primer campo.

Do While Not rs.EOF Debug.Print rs(0)
rs.MoveNext
Loop

' Cerrar el recordset.

rs.Close

End Sub

Almacenar los resultados de una consulta Access en un fichero Excel

Private Sub Command1_Click()

Dim cn As ADODB.Connection

Set cn = New ADODB.Connection

cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=
c:\bd1.mdb" cn.Execute "Select * into
[Excel8.0];Database=c:\Test1.xls;Hdr=Yes].[Sheet3] From Clients"
cn.Close
Set cn = Nothing
End Sub

' Explorar la colección Errors.

Sub ErrorExample()
Dim cn As ADODB.Connection
Set cn = New ADODB.Connection
On Error GoTo AdoError

' Abrir la conexión usando un DSN que no existe.

cn.Open "MissingDSN", "sa", ""

Exit Sub

AdoError:
Dim Errs As ADODB.Errors
Dim errLoop As Error
Dim strError As String

' Bucle hasta el objeto Error en la

' colección Errors y muestra las propiedades.
Set Errs = cn.Errors
For Each errLoop In Errs
Debug.Print errLoop.SQLState
Debug.Print errLoop.NativeError
Debug.Print errLoop.Description
Next

End Sub

Enumerar los campos (nombre, tipo y valor) de un recordset

Sub FieldExample()
Dim rs As ADODB.Recordset
Dim fld As ADODB.Field

Set rs =
New ADODB.Recordset ' Abrir el recordset, especificando la
sentencia SQL ' y la cadena
de conexión. rs.Open "Select * fromauthors","DSN=pubs;UID=sa"

Debug.Print "Fields in Authors Table:" & vbCr

' Bucle hasta el objeto Field en la

' Colección Fields de la tabla y muestra las propiedades.
For Each fld In rs.Fields
Debug.Print "Name: " & fld.Name & vbCr & _
"Type: " & fld.Type & vbCr & _
"Value: " & fld.Value
Next fld

' Cierre del recordset.

rs.Close

End Sub

Mostrar los valores de ciertas propiedades de una conexión (el curso de la colección de Properties)

Sub PropertyExample()
Dim cn As New ADODB.Connection
Dim cmd As New ADODB.Command
Dim rs As New ADODB.Recordset

' Abrir la conexión, especificando el nombre del origen de datos,

' id del usuario, u contraseña.
cn.Open "pubs", "sa"

' Establecer el comando conexión usando una cadena de conexión.

Set cmd.ActiveConnection = cn
' Establecer el comando texto, especificando que es una sentencia SQL.
cmd.CommandText = "Select * from titles"
cmd.CommandType = adCmdText

' Crear el recordset.

Set rs = cmd.Execute()

' Muestra la propiedad ConnectionTimeout de la conexión.

Debug.Print cn.Properties("Connect Timeout")
' Muestra la propiedad CommandTimeout del comando.
Debug.Print cmd.Properties("Command Time out")

' Muestra la propiedad Updatability del recordset.

Debug.Print rs.Properties("Updatability")

' Cierra el recordset.

rs.Close
End Sub

Las cadenas de conexión

Si necesita escribir una cadena de conexión, existe una manera de generarla con el asistente de creación de
una conexión de datos.

Se puede usar esta herramienta de creación de conexiones de datos en VB:

 Utilize el menú Ver y seleccione Ventana de la vista Datos

 Cree un Entorno de datos haciendo clic en el botón derecho en la ventana de datos.
 En la ventana Entorno de datos, hacer clic en el botón derecho sobre Connection1 para ver las
características de la conexión (el proveedor, DSN, las propiedades específicas).
 Probar la conexión antes de hacer clic en el botón de Aceptar
 Entrar en la ventana de propiedades y seleccionar el objeto Connection1: La propiedad DataSource
contiene la cadena de conexión necesaria.
 MODULO IV: Conectarse a un SQL Server

TEMA 2: Modelo de objetos de ADO

Objetos de datos ActiveX

Los Objetos de datos ActiveX® (ActiveX® Data Object, ADO) constituyen una interfaz de Microsoft,
estratégica y de alto nivel, para toda clase de datos. ADO constituye un método de acceso a datos coherente
y de alto rendimiento, tanto cuando se crea una base de datos cliente de usuario, como si se crea un objeto
de trabajo de capas intermedias con una aplicación, herramienta, lenguaje o, incluso, con un explorador de
Internet. ADO es la única interfaz de datos necesaria para programar soluciones cliente/servidor de 1 a n
capas y soluciones basadas en datos Web.
ADO está diseñada como una interfaz de nivel de aplicación, fácil de usar, para el modelo más reciente y
potente de acceso a datos de Microsoft, OLE DB. OLE DB proporciona acceso de alto rendimiento a cualquier
origen de datos, como las bases de datos relacionales y no relacionales, los sistemas de correo electrónico y
archivo, texto y gráficos, los objetos de trabajo personalizados, etc. ADO se implementa con un mínino de
tráfico de red en escenarios Internet clave y con un mínino de capas entre los datos de origen y los
resultados proporcionando una interfaz ligera y de altas prestaciones.
ADO es fácil de usar porque se activa mediante un método conocido: la interfaz OLE, disponible
prácticamente en todas las herramientas y lenguajes existentes actualmente en el mercado. Y, puesto que
los ADO han sido diseñados para combinar las mejores funciones de RDO y DAO, y eventualmente para
sustituirlos, utiliza convenciones similares con semántica simplificada que facilitan el aprendizaje a los
programadores.

Modelo de objetos de ADO

Cada uno de los objetos Connections,Command,Recordset y Field También tiene una colección Properties.
 MODULO IV: Conectarse a un SQL Server

TEMA 3: Objetos ADO

Command, objeto (ADO) Descripción

Un objeto Command es la definición de un comando específico que se piensa ejecutar contra un origen de
datos.

Utilice un objeto Command para consultar una base de datos y obtener registros en un objeto Recordset para
ejecutar una operación de manejo masivo de datos o para manipular la estructura de una base de datos.
Dependiendo de la funcionalidad del proveedor, algunas colecciones, métodos o propiedades de Command
pueden generar un error cuando se les haga referencia. Con las colecciones, métodos y propiedades de un
objeto Command, puede hacer lo siguiente:

· Definir el texto ejecutable del comando (por ejemplo, una instrucción SQL) con la propiedad CommandText.

· Definir consultas parametrizadas o argumentos de procedimientos almacenados con los objetos Parameter y
la colección Parameters.

· Ejecutar un comando y obtener un objeto Recordset si resulta apropiado con el método Execute.

· Especificar el tipo de comando con la propiedad CommandType antes de la ejecución para optimizar el
rendimiento.

· Controlar con la propiedad Prepared, si el proveedor guarda una versión preparada (o compilada) del
comando antes de la ejecución.

· Establecer el número de segundos que un proveedor esperará que el comando se ejecute con la propiedad
CommandTimeout.

· Asociar una conexión abierta con un objeto Command estableciendo su propiedad ActiveConnection.

· Establecer la propiedad Name para identificar el objeto Command como un método del objeto Connection
asociado.

· Pasar un objeto Command a la propiedad Source de un Recordset para obtener los datos.

Nota: Para ejecutar una consulta sin utilizar un objeto Command, pase una cadena de consulta al método
Execute de un objeto Connection o al método Open de un objeto Recordset. Sin embargo, se requiere un
objeto Command cuando quiera que el texto del comando persista y volver a ejecutarlo, o utilizar parámetros
en la consulta.

Para crear un objeto Command independientemente de un objeto Connection previamente definido,

establezca su propiedad ActiveConnection a una cadena de conexión válida. ADO sigue creando un objeto
Connection, pero no asigna dicho objeto a una variable de objeto. Sin embargo, si va a asociar varios objetos
Command con la misma conexión, tiene que crear y abrir de forma explícita un objeto Connection; esto
asigna el objeto Connection a una variable de objeto. Si no establece la propiedad ActiveConnection de los
objetos Command a esta variable de objeto, ADO crea un nuevo objeto Connection por cada objeto
Command, incluso si utiliza la misma cadena de conexión. Para ejecutar un Command, sólo invóquelo
utilizando su propiedad Name en el objeto Connection asociado. El objeto Command ha de tener su
propiedad ActiveConnection establecida al objeto Connection. Si el objeto Command tuviera parámetros,
pase los valores de los parámetros como argumentos del método.
Propiedades

Propiedad ActiveConnection (ADO), Propiedad CommandTect (ADO), Propiedad

CommandTimeout (ADO), Propiedad CommandType (ADO), Propiedad Prepared (ADO), Propiedad State
(ADO).

Métodos

Método Cancel (ADO), Método CreateParameter (ADO), Método Execute (ADO Command), Método Execute
(ADO Connection).

Colecciones

Colección Properties, Colección Parameters.

Connection, objeto (ADO) Descripción

Un objeto Connection representa una conexión abierta con un origen de datos.

Un objeto Connection representa una sesión única con un origen de datos. En el caso de un sistema de base
de datos cliente/servidor, puede ser equivalente a una conexión de red actual con el servidor. Dependiendo
de la funcionalidad que acepte el proveedor, algunas colecciones, métodos o propiedades de un objeto
Connection puede que no estén disponibles. Mediante las colecciones, métodos y propiedades de un objeto
Connection puede hacer lo siguiente:

· Configurar la conexión antes de abrirla con las propiedades ConnectionString, ConnectionTimeout y Mode.

· Establecer la propiedad CursorLocation para invocar al Client Cursor Provider, que acepta actualizaciones
por lotes.

· Establecer la base de datos predeterminada para la conexión con la propiedad DefaultDatabase.

· Establecer el nivel de aislamiento de las transacciones abiertas en la conexión con la propiedad

IsolationLevel.

· Especificar un proveedor de OLE DB con la propiedad Provider.

· Establecer, y después romper, la conexión física con el origen de datos con los métodos Open y Close.

· Ejecutar un comando en la conexión con el método Execute y configurar la ejecución con la propiedad
CommandTimeout.

· Administrar transacciones en la conexión abierta, incluyendo transacciones anidadas si el proveedor las

acepta, con los métodos BeginTrans, CommitTrans y Rolí-backjrans y la propiedad Attributes.

· Examinar los errores devueltos por el origen de datos con la colección Errors.

· Leer la versión de la implementación de ADO en uso con la propiedad Version.

· Obtener información del esquema de la base de datos con el método OpenSchema.

Nota: Para ejecutar una consulta sin utilizar un objeto Command, pase una cadena de consulta al método
Execute de un objeto Connection. Sin embargo, se requiere un objeto Command cuando se quiere que el
texto del comando persista y se vuelva a ejecutar, o utilice parámetros en la consulta.
Puede crear objetos Connection de forma independiente de cualquier objeto previamente definido.

Nota: Se pueden ejecutar comandos o procedimientos almacenados como si fuesen métodos nativos del
objeto Connection.

Para ejecutar un comando, dé un nombre al comando mediante la propiedad Name del objeto Command.
Establezca la propiedad ActiveConecction del objeto Command como la conexión. Después emita una
instrucción donde el nombre del comando se utilice como si fuese un método del objeto Connection, seguido
de cualquier parámetro, seguido de un objeto Recordset si se devuelve alguna fila. Establezca las
propiedades del Recordset para personalizar el conjunto de registros resultante:

Para ejecutar un procedimiento almacenado, emita una instrucción donde se utilice el nombre del
procedimiento almacenado como si fuese un método del objeto Connection, seguido de sus parámetros. ADO
realizará una "mejor suposición" de los tipos de parámetros

Propiedades

Propiedad Attributes (ADO), Propiedad CommandTimeout (ADO), Propiedad ConnectionString (ADO),

Propiedad ConnectjonTimeout (ADO), Propiedad CursorLocation (ADO), Propiedad DefaultIDatabase (ADO),
Propiedad IsolationLevel (ADO), Propiedad Mode (ADO), Propiedad Provider (ADO), Propiedad State (ADO),
Propiedad Version (ADO). Objetos ADO 1315

Métodos

Métodos BeginTrans, CommitTrans y RollbackTrans (ADO>, Método Cancel (ADO), Método Close (ADO),
Método Execute (Comando ADO), Método Execute (Conexión ADO), Método Open (Conexión ADO), Método
Open (Conjunto de Registros ADO), Método OpenSchema (ADO), Método Save (Conjunto de Registros ADO).

Colecciones

Colección Properties, Colección Errors.

Error, objeto (ADO) Descripción

Un objeto Error contiene los detalles sobre los errores de acceso a los datos pertenecientes a una única
operación relacionada con el proveedor.

Cualquier operación relacionada con objetos ADO puede generar uno o varios errores del proveedor. Al
ocurrir los errores, uno o varios objetos Error se agregan a la colección Errors del objeto Connection. Cuando
otra operación ADO genera un error, se borra la colección Errors y el nuevo conjunto de objetos Error se
agrega a la colección Errors.

Nota: Cada objeto Error representa un error del proveedor concreto, no un error de ADO. Los errores de ADO
pasan al mecanismo de control de excepciones de ejecución. Por ejemplo, en Microsoft Visual Basic, la
ocurrencia de un error concreto de ADO desencadenará un evento On Error y aparecerá en el objeto Err. Para
obtener la lista completa de los errores de ADO, vea el tema Códigos de error ADO tema.

Puede leer las propiedades de un objeto Error para obtener detalles específicos sobre cada error, incluyendo
los siguientes:

· La propiedad Description, que contiene el texto del error.

· La propiedad Number, que contiene el valor entero Long de la constante del error.
· La propiedad Source, que identifica el objeto que ha provocado el error. Esto es particularmente útil cuando
tiene varios objetos Error en la colección Errors después de una petición a un origen de datos.

· Las propiedades SQLState y NativeError, que proporcionan información desde orígenes de datos SQL.

Cuando ocurre un error en el proveedor, se agrega a la colección Errors del objeto Connection. ADO acepta la
devolución de varios errores por una misma operación ADO para permitir tener acceso a la información de
error específica del proveedor. Para obtener esta rica información de error en un controlador de errores,
utilice las funciones de interceptación de errores apropiadas de su lenguaje o entorno de trabajo y después
utilice bucles anidados para enumerar las propiedades de cada objeto Error de la colección Errors.

Microsoft Visual Basic y VBScript. Si no hay un objeto Connection válido, tendrá que obtener la información
de error desde el objeto Err.

Igual que los proveedores, ADO borra el objeto OLE Error Info antes de hacer una llamada que pueda
generar un nuevo error del proveedor. Sin embargo, la colección Errors del objeto Connection sólo se borra y
se llena cuando el proveedor genera un nuevo error, o cuando se invoca el método Clear. Algunas
propiedades y métodos devuelven advertencias que aparecen como objetos Error en la colección Errors, pero
no detienen la ejecución de los programas. Antes de invocar los métodos Resync, UpdateBatch o CancelBatcb
de un objeto Recordset, el método Open de un objeto Connection, o de establecer la propiedad Filter de un
objjeto Recordset, invoque el método Clear de la colección Errors para que pueda leer la propiedad Count de
la colección Errors y comprobar las advertencias devueltas.

Propiedades

Propiedad Description (ADO), Propiedad NaviteError (ADO), Propiedad Number (ADO), Propiedad Source
(ADO Error), Propiedad SQLState (ADO), Archivo Help.

Field, objeto (ADO)

Un objeto Field representa una columna de datos con un tipo de datos comun.

Un objeto Recordset tiene una colección Fields que consiste en varios objetos Field. Cada objeto Field se
corresponde con una columna del Recordset. La propiedad Value de los objetos Field se utiliza para
establecer u obtener los datos del registro actual. Dependiendo de la funcionalidad ofrecida por el proveedor,
algunas colecciones, métodos o propiedades de un objeto Field puede que no estén disponibles.

Con las colecciones, métodos y propiedades de un objeto Field, puede hacer lo siguiente:

· Obtener el nombre de un campo con la propiedad Name.

· Ver o modificar los datos del campo con la propiedad Value.

· Obtener las características básicas de un campo con las propiedades Type, Precision y NumericScale. ·
Obtener el tamaño declarado de un campo con la propiedad DefinedSize.

· Obtener el tamaño actual de los datos de un campo dado con la propiedad ActualSize.

· Determinar qué tipos de funcionalidad se aceptan para un campo dado con la propiedad Attributes y la
colección Properties.

· Manipular los valores de los campos que contengan datos binarios o de gran tamaño con los métodos
AppendChunk y GetChunk. · Si el proveedor acepta actualizaciones por lotes, resolver discrepancias en los
valores de tos campos durante una actualización por lotes con las propiedades OriginalValue y
UnderlyingValue.
Todas las propiedades de metadatos (Name, Type, DefinedSize, Precision y NumericScale) están disponibles
antes de abrir el Recordset del objeto Field. Su establecimiento en tal momento es útil en la generación
dinámica de formularios.

Propiedades Propiedad ActualSize (ADO), Propiedad Attributes (ADO), Propiedad DefinedSize (ADO),
Propiedad Name (ADO), Propiedad NumericScale (ADO), Propiedad OriginalValue (ADO), Propiedad Precision
(ADO), Propiedad Type (ADO), Propiedad UnderlyingValue (ADO), Propiedad Value (ADO).

Métodos Método AppendChunk (ADO), Método GetChunk (ADO).

Colecciones Colección Properties.

Parameter, objeto (ADO)

Un objeto Parameter representa un parámetro o un argumento asociado con un objeto Command basado en
una consulta parametrizada o en un procedimiento almacenado.

Muchos proveedores aceptan comandos parametrizados. Estos son comandos en los que la acción deseada
está definida una sola vez, pero se utilizan variables (o parámetros) para alterar algunos detalles del
comando. Por ejemplo, una instrucción SQL SELECT podría utilizar un parámetro para definir los criterios de
búsqueda de la cláusula WHERE, y otro para definir el nombre de la columna de la cláusula SORT BY. Los
objetos Parameter representan parámetros asociados con consultas parametrizadas, o los argumentos de
entrada/salida y los valores devueltos por los procedimientos almacenados. Dependiendo de la funcionalidad
del proveedor, algunas colecciones, métodos o propiedades de un objeto Parameter puede que no estén
disponibles. Con las colecciones, métodos y propiedades de un objeto Parameter, puede hacer lo siguiente:

· Establecer u obtener el nombre de un parámetro con la propiedad Name.

· Establecer u obtener el valor de un parámetro con la propiedad Value.

· Establecer u obtener características de un parámetro con las propiedades Attributes, Direction, Precision,
NumericScale. Size y Type.

· Pasar datos binarios o de gran tamaño a un parámetro con el método AppendChunk.

Si conoce los nombres y las propiedades de los parámetros asociados con el procedimiento almacenado o la
consulta parametrizada a la que vaya a invocar, puede utilizar el método Createparameter para crear objetos
Parameter con los valores apropiados y utilizar el método Append para agregarlos a la colección Parameters.
Esto le permite establecer y obtener valores de parámetros sin tener que invocar el método Refresh de la
colección Parameters para obtener información de los parámetros desde el proveedor, una operación que
potencialmente consume bastantes recursos.

Propiedades

Propiedad Attributes (ADO), Propiedad Direction (ADO), Propiedad Name (ADO>, Propiedad NumericScale
(ADO), Propiedad Precision (ADO), Propiedad Size (ADO), Propiedad Type (ADO), Propiedad Value (ADO).

Métodos

Método AppendChunk (ADO), Método Delete (Colección de parámetros ADO), Método Delete (Conjunto de
Registros ADO).

Colecciones

Colección Properties.
Recordset, objeto (ADO)

Un objeto Recordset representa todo el conjunto de registros de una tabla o del resultado de un comando
ejecutado. En cualquier momento, el objeto Recordset sólo hace referencia a un único registro dentro del
conjunto, llamado registro actual.

Los objetos Recordset se utilizan para manipular los datos de un proveedor. Cuando se utiliza ADO, se
manipulan los datos casi completamente con objetos Recordset. Tollos los objetos Recordset se construyen
utilizando registros (filas) y campos (columnas). Dependiendo de la funcionalidad aceptada por el proveedor,
algunos métodos o propiedades del objeto Recordset puede que no estén disponibles.

ADOR.Recordset y ADODB.Recordset son ProgID que se utilizan para crear objetos Recordset. Los objetos
Recordset que resultan se comportan de forma idéntica, independientemente del ProgID. ADOR.Recordset se
instala con Internet Explorer de Microsoft®; ADODB.Recordset se instala con ADO. El comportamiento de un
objeto Recordset esta afectado por su entorno (esto es, cliente, servidor, Internet Explorer, etc.). Las
diferencias se describen en los temas de Ayuda de sus propiedades. métodos y eventos. Hay cuatro tipos
diferentes de cursores en ADO:

· Cursor dinámico: le permite ver inserciones, modificaciones y eliminaciones de otros usuarios, y permite
todos los tipos de movimientos a través del Recordset que estén relacionados con marcadores; permite
marcadores si el proveedor los acepta.

· Cursor de conjunto de claves: se comporta como un cursor dinámico, excepto que impide ver registros
agregados por otros usuarios, e impide el acceso a registros eliminados por otros usuarios. Las
modificaciones en los datos efectuadas por otros usuarios siguen siendo visibles. Acepta siempre marcadores
y, por tanto, permite todos los tipos de movimientos a través del Recordset.

· Cursor estático: proporciona una copia estática de un conjunto de registros para que se utilicen en
búsquedas de datos o para generar informes; permite siempre los marcadores y, por tanto, permite todos los
tipos de movimientos a través del Recordset. Las inserciones, modificaciones o eliminaciones efectuadas por
otros usuarios no serán visibles. Este es el único tipo de cursor permitido cuando se abre un objeto Recordset
en el lado del cliente (ADOR).

· Cursor de tipo Forward-only: se comporta de forma idéntica al cursor dinámico, excepto en que sólo le
permite recorrer los registros hacia delante. Esto aumenta el rendimiento en situaciones en las que sólo
tenga que efectuar un paso a través de un Recordset.

Establezca la propiedad CursorType antes de abrir el Recordset para elegir el tipo de cursor, o pase un
argumento CursorType con el método Open. Algunos proveedores no aceptan todos los tipos de cursores.
Compruebe la documentación del proveedor. Si no se especifica el tipo del cursor, ADO abre un cursor de tipo
Forward-only de manera predeterminada. Cuando se utilizan con algunos proveedores (como Microsoft ODBC
Provider para OLE DB junto con Microsoft SQL Server), se pueden crear objetos Recordset
independientemente de un objeto Connection definido previamente pasando una cadena de conexión al
método Open. ADO sigue creando un objeto Connection, pero no asigna dicho objeto a una variable de
objeto. Sin embargo, si se están abriendo varios objetos Recordset en la misma conexión, se tiene que crear
y abrir explícitamente un objeto Connection; así se asigna el objeto Connection a una variable de objeto. Si
no se utiliza dicha variable de objeto cuando se abren los objetos Recordset, ADO crea un nuevo objeto
Connection por cada nuevo Recordset, incluso si se pasa la misma cadena de conexión. Se pueden crear
tantos objetos Recordset como sea necesario. Cuando se abre un Recordset, el registro actual está situado
en el primer registro (si lo hay) y las propiedades BOBy EOF están establecidas a False. Si no hay registros,
los valores de las propiedades BOF y EOF son True. Pueden utilizarse los métodos Movelfirst, MoveLast,
MoveNext y MovePrevious, así como el método Move, y las propiedades AbsolutePosition, AbsolutePage y
Filter para volver a colocar el registro actual, asumiendo que el proveedor acepta la funcionalidad necesaria.
Los objetos Recordset de tipo Forward-only sólo aceptan el método MoveNext. Cuando se utilizan métodos
Move para visitar todos los registros (o para enumerar el Recordset), se puede utilizar las propiedades BOF y
EOF para saber si ha llegado al principio o al final del Recordset. Los objetos Recordset pueden aceptar dos
tipos de actualización: inmediata y por lotes. En la actualización inmediata, todas las modificaciones se
escriben inmediatamente en el origen de datos después de invocar el método Update. También se pueden
pasar matrices de valores como parámetros en los métodos AddNew y Update y actualizar de forma
simultánea varios campos de un registro. Si un proveedor acepta la actualización por lotes, se puede hacer
que el proveedor guarde en la caché las modificaciones efectuadas en varios registros y transmitirlos después
en una sola llamada a la base de datos con el método UpdateBatch. Esto se aplica a las modificaciones
efectuadas con los métodos AddNew, Update y Delete. Después de invocar el método UpdateBatch, se puede
utilizar la propiedad Status para comprobar si ha habido algún conflicto en los datos para resolverlo.

Nota: Para ejecutar una consulta sin utilizar un objeto Command, pase una cadena de consulta al método
Open de un objeto Recordset. Sin embargo. se requiere un objeto Command cuando quiera que el texto del
comando persista para volver a ejecutarlo, o cuando utilice parámetros en la consulta.

Propiedades

Propiedad AbsolutePage (ADO), Propiedad AbsolutePosition (ADO), Propiedad ActiveConnection (ADO),

Propiedad BOF, EOF (ADO), Propiedad Bookmark (ADO), Propiedad CacheSize (ADO), Propiedad
CursorLocation (ADO), Propiedad CursorType (ADO), Propiedad EditMode (ADO), Propiedad F'ilter (ADO),
Propiedad LockType (ADO), Propiedad MarshalOption (ADO), Propiedad MaxRecords (ADO), Propiedad
PageCount (ADO), Propiedad PageSize (ADO), Propiedad RecordCount (ADO), Propiedad Source (Conjunto de
Registros ADO), Propiedad State (ADO), Propiedad Status (ADO).

Métodos

Método AddNew (ADO), Método Cancel (ADO), Método CancelBatch (ADO), Método CancelUpdate (ADO),
Método Clone (ADO), Método Delete (Colección de parámetros ADO). Método Delete (Colección de campos
ADO), Método Delete (Conjunto dc registros ADO), Método Move (ADO), Métodos MoveFirst, MoveLast,
MoveNext y MovePrevious (ADO), Método NextRecordset (ADO), Método Open (Conexión ADO) Método Open
(Conjunto de regi~tros ADO), Método Requery (ADO), Método Resync (ADO), Método Save (Conjunto de
registros ADO), Método Supports (ADO). Método Update (ADO), Método UpdateBatch (ADO).

MODULO IV: Conectarse a un SQL Server

TEMA 4: Propiedades ADO

AbsolutePage, propiedad (ADO)

Especifica en qué página reside el registro actual.

Se aplica a Objeto Recordset (ADO).

Configuración y valores devueltos

Establece o devuelve un valor de tipo Long entre 1 y el número Recordset (PageCount) o devuelve una de las
constantes siguientes:

El objeto Recordset está vacío, la posición actual se desconoce o el

adPosUnknown
proveedor no admite la propiedad AbsoltitePage.
El puntero del registro actual está al comienzo del archivo (C5 decir, la
adPosBOF
propiedad BOF tiene el valor True).
El puntero del registro actual está al final del archivo (es decir, la
adPosEOF
propiedad EOF tiene el valor True).

Utilice la propiedad AbsolutePage para identificar el número de la página en que se encuentra el registro
actual. Utilice la propiedad PageSize para dividir lógicamente el objeto Recordset en varias páginas, cada una
de las cuales debe tener un número de registros igual a PageSize (excepto la última página, que puede tener
menos registros). El proveedor debe ser compatible con la funcionalidad apropiada para que esta propiedad
esté disponible. Al igual que la propiedad AbsolutePosition, la propiedad AbsolutePage está en base 1 v es
igual a 1 cuando el registro actual es el primer registro del objeto Recordset. Establezca esta propiedad para
moverse al primer registro de una página específica. Obtenga el número total de páginas a partir de la
propiedad PageCount.

AbsolutePosition, propiedad (ADO)

Especifica la posición ordinal del registro actual de un objeto Recordset.

Se aplica a

Objeto Recordset (ADO).

Configuración y valores devueltos

Establece o devuelve un valor de tipo Long entre 1 y el número de registros del objeto Recordset
(RecordCount) o devuelve una de las constantes siguientes: Constante Descripción

El objeto Recordset está vacío, la posición actual se desconoce o el

adPosUnknown
proveedor no admite la propiedad AbsoltitePage.
El puntero del registro actual está al comienzo del archivo (C5 decir, la
adPosBOF
propiedad BOF tiene el valor True).
El puntero del registro actual está al final del archivo (es decir, la
adPosEOF
propiedad EOF tiene el valor True).

Utilice la propiedad AbsolutePosition para moverse a un registro según su posición ordinal en el objeto
Recordset o para determinar la posición ordinal del registro actual. El proveedor debe ser compatible con la
funcionalidad apropiada para que esta propiedad esté disponible. Al igual que la propiedad AbsolutePage, la
propiedad AbsolutePosition está en base 1 y es igual a 1 cuando el registro actual es el púrner registro del
objeto Recordset. Puede obtener el número total de registros contenidos en dicho objeto Recordset a partir
de la propiedad RecordCount. Cuando establece la propiedad AbsoiutePos¡tion, incluso si es para un registro
contenido en la memoria caché actual, ADO vuelve a cargar la memoria caché con un nuevo grupo de
registros que comienza con el registro especificado. La propiedad CacheSize determina el tamaño de este
grupo.

Nota: No debería utilizar la propiedad AbsolutePosition como un número de registro sustirntorio. La posición
de un registro dado cambia cuando se elimina un registro anterior Tampoco hay ninguna seguridad de que un
registro dado tendrá la misma propiedad AbsolutePosition si se vuelve a consultar o se vuelve a abrir el
objeto Recordset. Los marcadores siguen siendo la forma recomendada para conservar y volver a una
posición dada, v son la única manera de posicionamiento en todos los tipos de objetos Recordset.

Ejemplo
Este ejemplo muestra cómo la propiedad AbsolutePosition puede llevar cuenta del progreso de un bucle que
enumera todos los registros de un Recordset. Utiliza la propiedad CursorLocation para habilitar la propiedad
AbsolutePosition ajustando el cursor a un cursor de cliente:

Public Sub AbsolutePositionX()

Dim rstEmployees As ADODB.Recordset

Dim strCnn As String
Dim strMessage As String

' Open a recordset for the Employee table

' using a client cursor.
strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
Set rstEmployees = New ADODB.Recordset
' Use client cursor to enable AbsolutePosition property.
 rstEmployees.CursorLocation = adUseClient
rstEmployees.Open "employee", strCnn, , , adCmdTable

' Enumerate Recordset.

Do While Not rstEmployees.EOF
' Display current record information.
strMessage = "Employee: " & rstEmployees!lName & vbCr & _
"(record " & rstEmployees.AbsolutePosition & _
" of " & rstEmployees.RecordCount & ")"
If MsgBox(strMessage, vbOKCancel) = vbCancel _
Then Exit Do
rstEmployees.MoveNext
Loop

rstEmployees.Close

End Sub

BOF, EOF, propiedades (ADO)

BOF indica que la posición del registro actual está antes del primer registro de un objeto Recordset EOF
indica que la posición del registro actual esta después del último registro de un objeto Recordset.

Valor devuelto
Las propiedades BOF y EOF devuelven valores Boolean.

Se aplica a Objeto Recordset ADO.

Utilice las propiedades BOF y BOF para determinar si un objeto Recordset contiene registros o si se han
sobrepasado los límites de un objeto Recordset al moverse de un registro a otro.
La propiedad BOF devuelve True (-1) si la posición del registro actual está antes del primer registro, y
devuelve False (O) si la posición del retristro actual esta en o después del primer registro.
La propiedad EOF devuelve True si la posición del registro actual está después del último registro, y devuelve
False si la posición del registro actual está en o después del último registro.
Si una de las dos propiedades BOF o EOF es true. no hay ningún registro actual.
Si se abre un objeto Recordset que no contiene registros las propiedades BOF y EOF se establecen a True y el
valor de la propiedad RecordCount del objeto Recordset es cero.
Cuando se abre un objeto Recordset que contiene. al menos. un registro. el primer registro es el registro
actual y las propiedades BOF y BOF tienen el valor False.
Si se elimina el último registro que queda en el objeto Recordset, las propiedades BOF y EOF pueden
conservar el valor False hasta que se intente volver a colocar el registro actual.
Esta tabla muestra qué métodos Move se permiten con diferentes combinaciones de las propiedades BOF y
EOF:

MoveFirst, MovePrevious, MoveNext,

Move O
MoveLast Move<O Move>O
BOF=True,EOF=False Permitido Error Error Permitido
BOF=False,EOF=True Permitido Permitido Error Error
Ambas True Error Error Error Error
Ambas False Permitido Permitido Permitido Permitido

Permitir un método Move no garantiza que el método localizará correctamente un registro, sólo significa que
al llamar al método Move especificado no se producirá un error. La tabla siguiente muestra qué ocurre en los
valores de las propiedades BOF y EOF cuando se llama a varios métodos Move, pero no puede localizar
correctamente un registro:

BOF EOF
MoveFirst, MoveLast Se establece a True. Se establece a True.
Move O Ningún cambio Ningún cambio
MovePrevious, Move <O Se establece a True. Ningún cambio
MoveNext, Move > O Ningún cambio Se establece a True.

E¡emplo
Este ejemplo utiliza las propiedades BOF y EOF para visualizar un mensaje si un usuario intenta desplazarse
más allá del primer o último registro de un Recordset. Utiliza la propiedad Bookmark para permitir al usuario
etiquetar un registro en un Recordset y volver a él más tarde:

Public Sub BOFX()

Dim rstPublishers As ADODB.Recordset

Dim strCnn As String
Dim strMessage As String
Dim intCommand As Integer
Dim varBookmark As Variant

' Open recordset with data from Publishers table.

strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
Set rstPublishers = New ADODB.Recordset
rstPublishers.CursorType = adOpenStatic
' Use client cursor to enable AbsolutePosition property.
rstPublishers.CursorLocation = adUseClient
rstPublishers.Open "SELECT pub_id, pub_name FROM publishers " & _
"ORDER BY pub_name", strCnn, , , adCmdText

rstPublishers.MoveFirst

Do While True
' Display information about current record
' and get user input.
strMessage = "Publisher: " & rstPublishers!pub_name & _
vbCr & "(record " & rstPublishers.AbsolutePosition & _
" of " & rstPublishers.RecordCount & ")" & vbCr & vbCr & _
"Enter command:" & vbCr & _
"[1 - next / 2 - previous /" & vbCr & _
"3 - set bookmark / 4 - go to bookmark]"
intCommand = Val(InputBox(strMessage))

Select Case intCommand

' Move forward or backward, trapping for BOF
' or EOF.
Case 1
rstPublishers.MoveNext
If rstPublishers.EOF Then
MsgBox "Moving past the last record." & _
vbCr & "Try again."
rstPublishers.MoveLast
End If
Case 2
rstPublishers.MovePrevious
If rstPublishers.BOF Then
MsgBox "Moving past the first record." & _
vbCr & "Try again."
rstPublishers.MoveFirst
 End If

' Store the bookmark of the current record.

Case 3
varBookmark = rstPublishers.Bookmark

' Go to the record indicated by the stored

' bookmark.
Case 4
If IsEmpty(varBookmark) Then
MsgBox "No Bookmark set!"
Else
rstPublishers.Bookmark = varBookmark
End If

Case Else
Exit Do
End Select

Loop

rstPublishers.Close

End Sub

Este ejemplo utiliza las propiedades Bookmark y Filter para crear una vista limitada del Recordset. Sólo son
accesibles los registros referenciados por la matriz de marcadores:

Public Sub BOFX2()

Dim rs As New ADODB.Recordset

Dim bmk(10)

rs.CursorLocation = adUseClient
rs.ActiveConnection = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=;"

rs.Open "select * from authors", , adOpenStatic, adLockBatchOptimistic

Debug.Print "Number of records before filtering: ", rs.RecordCount

ii = 0
While rs.EOF <> True And ii < 11
bmk(ii) = rs.Bookmark
ii = ii + 1
rs.Move 2
Wend
rs.Filter = bmk
Debug.Print "Number of records after filtering: ", rs.RecordCount

rs.MoveFirst
While rs.EOF <> True
Debug.Print rs.AbsolutePosition, rs("au_lname")
rs.MoveNext
Wend

End Sub

CommandTimeout, propiedad (ADO) Descripción

Indica el intervalo de espera para que se ejecute un comando antes de que finalice el intento y se genere un
error.
Se aplica a

Objeto Command (ADO), Objeto Connection (ADO).

Configuración y valores devueltos

Establece o devuelve un valor Long que indica, en segundos, el intervalo de espera para que se ejecute un
comando. El valor predeterminado es 30.

Comentarios

Use la propiedad CommandTimeout en un objeto Connection o en un objeto Command para permitir la

cancelación de una llamada al método Execute, debida a demoras en el tráfico de la red o a una sobrecarga
en el servidor. Si transcurre el intervalo establecido en la propiedad CommandTimeout antes de que termine
la ejecución de la orden, se produce un error y ADO cancela el comando. Si establece la propiedad a cero,
ADO esperará indefinidamente hasta que termine la ejecución. Compruebe que el proveedor y el origen de
datos para los que está escribiendo código admiten la funcionalidad CommandTimeout. El valor de
CommandTimieout en un objeto Connection no afecta al valor de CommandTimeout en un objeto Command
de la misma Connection,. es decir, la propiedad CommandTimeout del objeto Command no hereda el valor de
CommandTimeout del objeto Connection. En un objeto Connection, la propiedad CommandTimeout
permanece en modo lectura/escritura después de que se abra Connection.

ConnectionString, propiedad (ADO)

Contiene la información que se utiliza para establecer una conexión a un origen de datos.

Se aplica a

Objeto Connection (ADO).

Configuración y valores devueltos

Establece o devuelve un valor String.

Use la propiedad ConnectionString para especificar un origen de datos pasando una cadena de conexión
detallada que contenga una serie de instrucciones argumento = valor separadas con punto y coma.

ADO admite cuatro argumentos con la propiedad ConnectionString; cualquier otro argumento pasa
directamente al proveedor sin que ADO lo procese. Los argumentos compatibles con ADO son los siguientes:

Argumento Descripción
Provider= Especifica el nombre del proveedor que se usa con la conexion
Indica el nombre de un archivo especifico del proveedor (por Qíempío, un objeto de origen de
File Name=
datos persistente) que contiene información sobre la conexión preestablecida.
Remote Especifica el nombre de un proveedor que se usa al abrir una conexión del lado del cliente
provider= (solamente con Remote Data Service).
Remote Especifica la ruta de acceso del servidor que se usa al abrir una conexión del lado del cliente
Server= (solamente con Remote Data Service).

Argumento Descripción Provider Especifica el nombre del proveedor que se usa con la conexion. Indica el
nombre de un archivo especifico del proveedor (por Qíempío, un objeto de origen de datos persistente) que
contiene información sobre la conexión preestablecida. File Name Remote provider
Especifica el nombre de un proveedor que se usa al abrir una conexión del lado del cliente (solamente con
Remote Data Service).

Remote Server Especifica la ruta de acceso del servidor que se usa al abrir una conexión del lado del cliente
(solamente con Remote Data Service).

Después de que se establezca la propiedad ConnectionString y se abra el objeto Connection. es posible que el
proveedor modifique el contenido de la propiedad: por ejemplo, asignando los nombres de argumento
definidos con ADO a sus equivalentes en el proveedor. La propiedad ConnectionString hereda
automáticamente el valor que se utiliza con el argumento Connections del método Open para que se pueda
hacer caso omiso de la propiedad connectionString actual durante la llamada al método Open. Debido a que
el argumento File Name hace que ADO cargue el proveedor asociado. no se pueden pasar ambos
argumentos, Provider y File Name. La propiedad ConnectionString es de lectura/escútura cuando la conexión
está cerrada y de sólo lectura cuando está abierta.

Uso de Remote Data Service. Cuando se usa el objeto Connection del lado del cliente, la propiedad
ConnectionString solamente puede incluir los parámetros Remote provider y Remote Server

Count, propiedad (ADO)

Indica el número de objetos de una coleccion.

Devuelve un valor Long.

Se aplica a

Colección Errors (ADO). Colección Fields (ADO) Colección Parameter (ADO). Colección Properties (ADO).

Use la propiedad Count para determinar cuántos objetos hay en una colección dada. Debido a que la
numeración de miembros de una colección empieza por cero, debe codificar siempre los bucles empezando
siempre con el miembro cero y terminando con el valor de la propiedad Count menos 1. Si está usando
Microsoft Visual Basic y desea hacer un recorrido por los miembros de una colección sin comprobar la
propiedad Count use el comando For Each...Next. Si la propiedad Count es cero. no hay ningún objeto en la
colección.

CursorLocation, propiedad (ADO) Descripción

Establece o devuelve la posición de un motor de cursores.

Se aplica a

Objeto Connection (ADO), Objeto Recordset (ADO).

Establece o devuelve un valor Long que se puede establecer a alguna de las siguientes constantes:

Constante Descripción
No se usan servicios de cursor. (Esta constante es obsoleta y aparece únicamente por
adUseNone
compatibilidad con versiones anteriores.)
Usa cursores del lado del cliente suministrados por una biblioteca de cursores locales. Los
motores de cursores locales admitirán a menudo muchas características que los cursores
adUseClient proporcionados por controladores no admitirán; por tanto, el uso de esta configuración puede
proporcionar una ventaja con respecto a características que serán habilitadas. Por
compatibilidad con versiones anteriores. se admite también el sinónimo adUseClientBatch.
adUseServer Predeterminado. Usa cursores suministrados por el controlador o por el proveedor de datos.
 Estos cursores son, en ocasiones. muy flexibles y conceden un margen de sensibilidad
adicional a los cambios realizados por otros usuarios en el origen de datos. No obstante.
algunas características de Microsoft Client Cursor Provider (como los conjuntos de registros
disociados) no pueden ser simuladas con cursores del lado del servidor y no estarán
disponibles con esta configuración.

Esta propiedad le permite elegir entre distintas bibliotecas de cursores accesibles para el proveedor.
Normalmente, puede elegir entre usar una biblioteca de cursores del lado del cliente o una ubicada en el
servidor.

El valor de esta propiedad afecta solamente a las conexiones establecidas después de que se haya
establecido la propiedad. Los cambios en la propiedad CursorLocation no afectan a las conexiones existentes.
Esta propiedad es de lectura/escritura en un Connection o Recordset cerrado, y de sólo lectura en un
Recordset abierto. Los cursores de Connection.Execute heredarán esta configuración. Los objetos Recordset
heredarán automáticamente esta configuración de sus conexiones asociadas.

Uso de Remote Data Service. Cuando se usa en un objeto Recordset o Connection (ADOR) del lado del
cliente, la propiedad CursorLocation sólo se puede establecer a adUseClient:

Direction, propiedad (ADO)

Indica si Parameter representa un parámetro de entrada, un parámetro de salida o ambos bien, si el

parámetro es el valor devuelto por un procedimiento almacenado. Se aplica a

Objeto Parameter (ADO).

Establece o devuelve uno de los siguientes valores de ParameterDirectionEnum:

Constante Descripción
adParamUnknown Indica que la dirección del parámetro es desconocida.
adParamlnput Valor predeterminado. Indica un parámetro de entrada.
adParamOutput Indica un parámetro de salida.
adParamlnputOutput Indica un parámetro de entrada y otro de salida.
adParamReturnValue Indica un valor devuelto.

Utilice la propiedad Direction para especificar cómo se pasa un parámetro hacia o desde un procedimiento. La
propiedad Direction es de lectura/escritura; esto le permite trabajar con proveedores que no devuelven esta
información o establecer esta información cuando desea que ADO realice una llamada adicional al proveedor
para recuperar información acerca del parámetro. No todos los proveedores pueden determinar la dirección
de los parámetros en sus procedimientos almacenados. En estos casos, debe establecer la propiedad
Direction antes Ejecutar la consulta.

Ejemplo
Este ejemplo utiliza las propiedades ActiveConnection, CommandText, CommandTimeout, CommandType.
Size y Direction para ejecutar un procedimiento almacenado:

Public Sub ActiveConnectionX()

Dim cnn1 As ADODB.Connection

Dim cmdByRoyalty As ADODB.Command
Dim prmByRoyalty As ADODB.Parameter
Dim rstByRoyalty As ADODB.Recordset
Dim rstAuthors As ADODB.Recordset
Dim intRoyalty As Integer
Dim strAuthorID As String
 Dim strCnn As String

' Define a command object for a stored procedure.

Set cnn1 = New ADODB.Connection
strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
cnn1.Open strCnn
Set cmdByRoyalty = New ADODB.Command
Set cmdByRoyalty.ActiveConnection = cnn1
cmdByRoyalty.CommandText = "byroyalty"
cmdByRoyalty.CommandType = adCmdStoredProc
cmdByRoyalty.CommandTimeout = 15

' Define the stored procedure's input parameter.

intRoyalty = Trim(InputBox( _
"Enter royalty:"))
Set prmByRoyalty = New ADODB.Parameter
prmByRoyalty.Type = adInteger
prmByRoyalty.Size = 3
prmByRoyalty.Direction = adParamInput
prmByRoyalty.Value = intRoyalty
cmdByRoyalty.Parameters.Append prmByRoyalty

' Create a recordset by executing the command.

Set rstByRoyalty = cmdByRoyalty.Execute()

' Open the Authors table to get author names for display.
Set rstAuthors = New ADODB.Recordset
rstAuthors.Open "authors", strCnn, , , adCmdTable

' Print current data in the recordset, adding

' author names from Authors table.
Debug.Print "Authors with " & intRoyalty & _
" percent royalty"
Do While Not rstByRoyalty.EOF
strAuthorID = rstByRoyalty!au_id
Debug.Print , rstByRoyalty!au_id & ", ";
rstAuthors.Filter = "au_id = '" & strAuthorID & "'"
Debug.Print rstAuthors!au_fname & " " & _
rstAuthors!au_lname
rstByRoyalty.MoveNext
Loop

rstByRoyalty.Close
rstAuthors.Close
cnn1.Close

End Sub

PageCount, propiedad (ADO)

Indica cuántas páginas de datos contiene el objeto Recordset.

Se aplica a

Objeto Recordset (ADO).

Devuelve un valor de tipo Long.

Utilice la propiedad PageCount para determinar cuántas páginas de datos hay en el objeto Recordset. Las
páginas son grupos de registros cuyo tamaño es igual al valor de la propiedad PageSize. Incluso si la última
página no está completa, debido a que hay menos regístros que el valor de la propiedad PageSize, se cuenta
como una página adicional en el valor de PageCount.
Si el objeto Recordset no admite esta propiedad, el valor será -l para indicar que no se puede determinar el
valor de PageCount. Vea las propiedades PageSize y AbsolutePage para obtener más información acerca de la
funcionalidad de las páginas.

Ejemplo

Este ejemplo utiliza las propiedades AbsolutePage, PageCount y PageSize para visualizar nombres y tomar
fechas de la tabla Empleado cinco registros cada vez:

Public Sub AbsolutePageX()

Dim rstEmployees As ADODB.Recordset

Dim strCnn As String
Dim strMessage As String
Dim intPage As Integer
Dim intPageCount As Integer
Dim intRecord As Integer

' Open a recordset using a client cursor

' for the employee table.
strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
Set rstEmployees = New ADODB.Recordset
' Use client cursor to enable AbsolutePosition property.
rstEmployees.CursorLocation = adUseClient
rstEmployees.Open "employee", strCnn, , , adCmdTable

' Display names and hire dates, five records

' at a time.
rstEmployees.PageSize = 5
intPageCount = rstEmployees.PageCount
For intPage = 1 To intPageCount
rstEmployees.AbsolutePage = intPage
strMessage = ""
For intRecord = 1 To rstEmployees.PageSize
strMessage = strMessage & _
rstEmployees!fname & " " & _
rstEmployees!lname & " " & _
rstEmployees!hire_date & vbCr
rstEmployees.MoveNext
If rstEmployees.EOF Then Exit For
Next intRecord
MsgBox strMessage
Next intPage
rstEmployees.Close

End Sub

PageSize, propiedad (ADO)

Indica cuántos registros constituyen una página en el objeto Recordset.

Se aplica a

Objeto Recordset (ADO).

Establece o devuelve un valor de tipo Long que indica cuántos registros hay en una página. El valor
predeterminado es 10.

Utilice la propiedad PageSize para determinar cuántos registros componen una página lógica de datos. Al
establecer un tamaño de página, puede utilizar la propiedad AbsolutePage para moverse al primer registro de
una página específica. Esto es útil en las situaciones de servidor Web cuando se desea permitir que el usuario
pase páginas de datos y vea cierto número de registros al mismo tiempo. Esta propiedad se puede establecer
en cualquier momento y su valor se utilizará para calcular la ubicación del primer registro de una página
específica.

RecordCount, propiedad (ADO)

Indica el número actual de registros de un objeto Recordset.

Se aplica a

Objeto Recordset (ADO).

Devuelve un valor de tipo Long.

Utilice la propiedad RecordCount para averiguar cuántos registros hay en un objeto Recordset. La propiedad
devuelve -1 cuando ADO no puede determinar el número de registros. Al leer la propiedad RecordCount de
un objeto Recordset cerrado, se produce un error. Si el objeto Recordset admite el posicionamiento
aproximado o los marcadores, es decir, si las propiedades Supports (adApproxPosition) o Supports
(adBookmark), respectivamente, devuelven True, este valor será el número exacto de registros del objeto
Recordset independientemente de si se ha llenado completamente. Si el objeto Recordset no admite el
posicionamiento aproximado, esta propiedad puede consumir muchos recursos debido a que será necesario
recuperar y contar todos los recursos para devolver un valor preciso de RecordCount.

Ejemplo
Este ejemplo utiliza la propiedad Filter para abrir un Recordset nuevo basado en una condición específica
aplicada a un Recordset existente. Utiliza la propiedad RecordCount para mostrar el número de registros en
los dos Recordsets. Es necesaria la función FilterField para que funcione este procedimiento:

Public Sub FilterX()

Dim rstPublishers As ADODB.Recordset

Dim rstPublishersCountry As ADODB.Recordset
Dim strCnn As String
Dim intPublisherCount As Integer
Dim strCountry As String
Dim strMessage As String

' Open recordset with data from Publishers table.

strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
Set rstPublishers = New ADODB.Recordset
rstPublishers.CursorType = adOpenStatic
rstPublishers.Open "publishers", strCnn, , , adCmdTable

' Populate the Recordset.

intPublisherCount = rstPublishers.RecordCount

' Get user input.

strCountry = Trim(InputBox( _
"Enter a country to filter on:"))

If strCountry <> "" Then

' Open a filtered Recordset object.
Set rstPublishersCountry = _
 FilterField(rstPublishers, "Country", strCountry)

If rstPublishersCountry.RecordCount = 0 Then
MsgBox "No publishers from that country."
Else
' Print number of records for the original
' Recordset object and the filtered Recordset
' object.
strMessage = "Orders in original recordset: " & _
vbCr & intPublisherCount & vbCr & _
"Orders in filtered recordset (Country = '" & _
strCountry & "'): " & vbCr & _
rstPublishersCountry.RecordCount
MsgBox strMessage
End If
rstPublishersCountry.Close

End If

End Sub

Public Function FilterField(rstTemp As ADODB.Recordset, _

strField As String, strFilter As String) As ADODB.Recordset

' Set a filter on the specified Recordset object and then

' open a new Recordset object.
rstTemp.Filter = strField & " = '" & strFilter & "'"
Set FilterField = rstTemp

End Function

Nota: Cuando sabe los datos que desea seleccionar, suele ser más eficiente abrir un Recordset con una
sentencia SQL. Este ejemplo muestra cómo puede crear un único Recordset y obtener registros de un país en
particular.

Public Sub FilterX2()

Dim rstPublishers As ADODB.Recordset

Dim strCnn As String

' Open recordset with data from Publishers table.

strCnn = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=; "
Set rstPublishers = New ADODB.Recordset
rstPublishers.CursorType = adOpenStatic
rstPublishers.Open "SELECT * FROM publishers " & _
"WHERE Country = 'USA'", strCnn, , , adCmdText

' Print current data in recordset.

rstPublishers.MoveFirst
Do While Not rstPublishers.EOF
Debug.Print rstPublishers!pub_name & ", " & _
rstPublishers!country
rstPublishers.MoveNext
Loop

rstPublishers.Close

End Sub

Sort, propiedad (ADO)

Especifica uno o más nombres de campos por los que se ordena el objeto Recordset y si cada campo se
ordena de forma ascendente o descendente.

Configuración y valores devueltos

Establece o devuelve un valor de tipo String con los nombres de los campos utilizados para ordenar
separados por comas, donde cada nombre es un objeto Field del objeto Recordset Y, opcionalmente, está
seguido de un espacio en blanco y de la palabra clave ASCENDING o DESCENDING, que especifica el orden
del campo.

Los datos no se vuelven a ordenar físicamente, sino que, simplemente, se tiene acceso a los mismos en el
orden indicado. Se creará un índice temporal para cada uno de los campos especificados en la propiedad Sort
si la propiedad CursorLocation se establece a adUseClient y no existe ya un índice. Al establecer la propiedad
Sort a una cadena vacía. se restablecen las filas a su orden original y se eliminan los índices temporales. Los
índices existentes no se eliminarán.

Ejercicio 1

Creación de una nueva base de datos

Crear una base de datos implica decidir el nombre de la misma, quién es el propietario, el tamaño inicial y los
archivos y grupos de archivos que se utilizarán para almacenar la base de datos.

Existen tres tipos de archivos que se utilizan para almacenar una base de datos:

· Primario. Estos archivos se utilizan para almacenar información sobre la base de datos, cómo fue creada,
el tamaño de la misma, la ubicación de los otros archivos de base de datos y varias otras configuraciones
específicas de la base de datos. Asimismo, el archivo primario se utiliza para almacenar objetos y datos.
Cada base de datos debe tener uno y sólo un archivo primario. En forma predeterminada, este archivo
terminará con la extensión .mdf.
· Secundario. Similar al archivo primario, el archivo secundario también contiene objetos y datos, pero la
diferencia es que no incluye configuraciones de base de datos. Las bases de datos no tienen que tener ningún
archivo de datos secundario si el archivo primario es lo suficientemente grande para albergar todos los datos
en la base de datos. Asimismo, los archivos secundarios se pueden utilizar para distribuir datos entre varios
discos físicos. En forma predeterminada, estos archivos terminarán con al extensión .ndf.
· Bitácora. Estos archivos almacenan información de bitácora utilizada en recuperar una base de datos. Para
cada base de datos, se crea únicamente un archivo de bitácora, a pesar de que puede haber más de uno. En
forma predeterminada, estos archivos terminarán con la extensión .ldf.

Creación de su primera base de datos

1. Inicie Enterprise Manager desde el grupo de programas de Microsoft® SQL Server™ versión 7.0.

2. Conéctese a su servidor al hacer doble clic en el nombre del mismo. Si el nombre del servidor no aparece
en pantalla, haga clic en el símbolo + al lado de MS SQL Servers, y después haga clic en el símbolo + a la
izquierda de SQL Server Group, ahora deberá ver su servidor en la lista. Si no, haga clic con el botón derecho
para registrar un nuevo servidor.
3. El panel derecho se llamará Hoja de tareas de introducción. Haga clic en el vínculo Configurar la solución
de base de datos.

4. El panel derecho ahora se llama configurar la solución de base de datos. Haga clic en Crear una base de
datos. Esto lanzará el asistente para la creacion de bases de datos.

5. Haga clic en Siguiente.

6. En el campo Nombre de la base de datos, introduzca entrenamiento. Para este ejercicio, deje los valores
predeterminados en Ubicación del archivo de base de datos y Ubicación del archivo de registro o de bitacora
de transacciones. Haga clic enSiguiente.

7. Especifique el tamaño inicial de su archivo de datos principal. Este será su archivo .mdf . Deje el tamaño
de archivo inicial y haga clic en Next.
8. Defina cómo crecerá la base de datos. Se le puede dar un tamaño inicial a la base de datos e
incrementarla puntualmente cuando se necesite o podemos configurar para que se incremente
automáticamente cuando lo necesite, de esta forma podemos aplicar dos formas en que crecerá, por un
porcentaje del tamaño de la base de datos, o por un tamaño fijo en Megabytes.
Para este ejercicio, acepte los valores predeterminados y haga clic en Siguiente.

9. Especifique el tamaño inicial de su archivo de bitácora o log de transacciones. Este será su archivo .ldf (.
Deje el tamaño inicial como 1 MB y haga clic en Siguiente.
10. Defina cómo crecerá la bitácora de transacciones de la misma forma que el archivo de datos en el punto
8.
Para este ejercicio, acepte los valores predeterminados y haga clic en Siguiente.

11. Ahora, puede revisar las propiedades de la base de datos entrenamiento. Haga clic en Atrás si desea
realizar cambios. Si no, haga clic en Finalizar.
12. Haga clic en OK.

13. En este punto, no cree un plan de mantenimiento a esto lo haremos mas adelante. Haga clic en No.

Ejercicio 2

Revisión y modificación de su base de datos

Ahora que su base de datos está creada, analizaremos cómo puede revisar las propiedades de la base de
datos entrenamiento y cómo puede modificarlas.

Revisión de las propiedades de su base de datos

1. Seleccione la base de datos entrenamiento en SQL Server Enterprise Manager. Haga clic con el botón
derecho y seleccione Propiedades.

Nota: Si selecciona Nueva base de datos puede crear una nueba base de datos sin usar el Asistente

2. Deslice el separador del margen derecho en la columna Ubicación para ver el nombre completo del
archivo. Observe que este campo termina en .mdf y tiene 1 MB de memoria asignada. Asimismo, observe
que la base de datos está configurada para crecer automáticamente cuando se necesita espacio y aquí
también se puede cargar esta configuración.

3. Haga clic en Registro de Transacciones para ver las propiedades de la bitácora de transacciones.
4. Haga clic en Opciones. Aquí tenemos varias opciones para configurar la base de datos

Sólo para uso del DBO Especificar que la base de datos sólo puede ser utilizada por su propietario.

Un único usuario Especificar que sólo puede tener acceso a la base de datos un usuario a la vez.

Sólo lectura Especificar que los usuarios pueden obtener datos de la base de datos pero no
modificarlos.

Valor NULL ANSI predeterminado Especificar si las columnas de la base de datos se definen como NULL o NOT
NULL de forma predeterminada.

Desencadenadores recursivos Habilitar la activación recursiva de los desencadenadores o triggers.

Select into o copia masiva Especificar que se pueden realizar operaciones no registradas.

Truncar registro en un punto de Especificar que el registro de transacciones se trunque cuando se produzca el
comprobación proceso de comprobar el punto de comprobación.

Detección de página rasgada Especificar que se puedan detectar las páginas incompletas.

Cerrar automáticamente Especificar que la base de datos se cierre después de que se liberen sus
recursos y hayan salido todos los usuarios.

Reducción automática Especificar que los archivos de la base de datos son aptos para reducirse de
forma automática y periódica.

Crear estadísticas automáticamente Especificar que las estadísticas que falten para la optimización de una consulta
se generarán automáticamente durante la optimización.

Actualizar estadísticas Especificar que las estadísticas que precise una consulta para su optimización y
automáticamente que estén obsoletas se generarán automáticamente durante la optimización.

Utilizar identificadores entre comillas Especificar que SQL Server haga cumplir las reglas ANSI relativas al uso de
 comillas. Esta opción especifica que las comillas dobles sólo se pueden utilizar
para los identificadores, tales como nombres de columna o de tabla. Las
cadenas de caracteres deben estar delimitadas por comillas simples.

Deje las opciones que vienen por defecto, seleccione Truncar registro en punto de comprobación y después
haga clic en Aplicar.

5. Haga clic en Permisos. Observe que puede establecer permisos por usuario/roll. Para este ejercicio, no
cambiaremos los permisos. Haga clic en Aceptar para cerrar las propiedades de bases de datos.

Ejercicio 3

Configuración del mantenimiento de la base de datos

Ahora que su base de datos está creada, querrá asegurar que se realice el mantenimiento según sea
necesario. Para esto, Microsoft ha incluido el Asistente para planes de mantenimientos de bases de datos en
Microsoft SQL Server 7.0.

Uso del Asistente de Plan de mantenimiento

1. Maximice Enterprise Manager y la ventana interna en Enterprise manager para ver toda la tarea.

2. Seleccione la base de datos entrenamiento en Enterprise Manager al hacer clic en el nombre de la base de
datos con el botón derecho, a continuación elija todas las tareas/Plan de mantenimiento, tal como lo indica la
imagen anterior.
3. Haga clic en Siguiente.

4. Debido a que la base de datos entrenamiento se seleccionó en la carpeta de bases de datos que ya está
marcada, sin embargo, se puede cambiar para incluir otras bases de datos en este plan de mantenimiento.
Para este ejercicio, no agregue ninguna otra base de datos. Haga clic en siguiente.
5. Aparece la pantalla Información de la optimización de la actualización de datos. Que tiene las siguientes
opciones:

Reorganizar páginas de datos y de índices
Reorganizar páginas con la cantidad
original de espacio disponible
Cambiar el porcentaje de espacio libre por
página a
Actualizar estadísticas para el optimizador
de consultas.
Muestrear % de la B.D.
Quitar el espacio no utilizado de los
archivos de la base de datos
Al incrementarse por encima de
Espacio libre tras la reducción
Programación
Cambiar...
Eliminar y volver a crear los índices de las tablas de la base de datos con un nuevo valor de FILLFACTOR
espacio vacío que se deja en cada página del índice, con el fin de reservar un porcentaje de espacio libre
para su expansión en el futuro. Al agregar datos a la tabla, el espacio libre se llena, ya que no se conserv
organizar las páginas de datos y de índices se puede restablecer el espacio libre.
Eliminar y volver a crear los índices de las tablas de la base de datos con el valor original de FILLFACTOR
Eliminar y volver a crear los índices de las tablas de la base de datos con un nuevo valor de FILLFACTOR
así la cantidad de espacio libre especificada en las páginas de índice. Cuanto mayor sea el porcentaje, m
páginas de índice y más podrá crecer el índice. Los valores válidos son de 0 a 100.
Volver a muestrear las estadísticas de distribución de cada índice creado en las tablas de usuario de la ba
utiliza las estadísticas de distribución para optimizar la exploración de las tablas durante el proceso de la
generar automáticamente las estadísticas de distribución, SQL Server muestrea periódicamente un porce
correspondiente para cada índice. Este porcentaje se basa en el número de filas de la tabla y en la frecue
Utilice esta opción para realizar un muestreo adicional con el porcentaje especificado de datos de las tabl
Generar estadísticas de distribución por muestreo del porcentaje indicado de datos de las tablas. Cuanto
serán las estadísticas, pero también llevará más tiempo el muestreo. Si el valor especificado no genera u
determinará automáticamente un tamaño de muestra adecuado. Los valores válidos son de 1 a 100.
Quitar el espacio no utilizado de la base de datos y permitir así que se reduzca el tamaño de los archivos
Quitar el espacio no utilizado de la base de datos sólo si ésta excede el tamaño especificado (en MB).
Determinar el espacio libre que se mantiene en la base de datos después de reducir su tamaño (cuanto m
podrá reducir la base de datos). El valor es un porcentaje de los datos actuales de la base de datos. Por
que contenga 60 MB de datos y 40 MB de espacio libre, con un porcentaje de espacio libre del 50 por cie
datos y 30 MB de espacio libre (porque el 50 por ciento de 60 MB es 30 MB). Sólo se elimina el espacio d
porcentaje indicado. Los valores válidos son de 0 a 100.
Establecer la frecuencia con que se ejecutan las tareas de optimización de datos (programadas con el Ag
predeterminada es los domingos a medianoche.
Cambiar la programación predeterminada.

Haga clic en Actualizar estadísticas para el optimizador de consultas. en Muestrear déjelo como 10% de la
base de datos. Para este ejercicio, deje Programacion en una vez a la semana el domingo a la 1:00:00
Recuerde que la mejor estrategia de optimización de datos dependerá del rol de su base de datos. Seleccione
la frecuencia y opciones que mejor se ajusten a sus necesidades. Haga clic en Siguiente.
6. Es posible realizar verificaciones de integridad de datos en su base de datos. Para esto tiene las siguientes
opciones:

Comprobar la integridad de la base de Comprobar la integridad de asignación y estructural de las tablas de usuario y de sistema, así como de lo
datos mediante la instrucción DBCC CHECKDB de Transact-SQL. De este modo se notificarán los problemas de
base de datos, lo que permitirá su tratamiento por parte de un administrador del sistema o del propietari
Incluir índices Comprobar las páginas de datos y de índices de la base de datos durante las pruebas de integridad.
Intentar reparar los problemas menores Intentar corregir automáticamente los problemas menores detectados durante las pruebas de integridad
seleccionar esta opción.
Excluir índices Comprobar únicamente las páginas de datos de la base de datos durante las pruebas de integridad. Los í
hace que la ejecución sea más rápida que al seleccionar Incluir índices, ya que se comprueban menos p
Realizar estas pruebas antes de las copias Ejecutar las pruebas de integridad de la base de datos o de los datos internos antes de hacer copias de s
de seguridad registro de transacciones. Si las pruebas de integridad detectan incoherencias, no se realizarán las copias
datos o del registro de transacciones.
Programación Establecer la frecuencia con que se ejecutan las tareas de integridad de los datos (programadas con el Ag
predeterminada es los domingos a medianoche.
Cambiar... Cambiar la programación predeterminada.

Seleccione Comprobar la integridad de la base de datos y Intentar reparar los problemas menores y si desea
incluir o no índices. De nuevo, la frecuencia y opciones que elija se basarán en el rol de su base de datos.
Haga clic en Siguiente.
7. Es muy importante que lleve a cabo respaldos programados regulares de sus bases de datos. Establezca el
plan de respaldo que mejor se ajuste a sus requerimientos de recuperación de datos. Cuando termine, haga
clic en Siguiente.

8. Ahora puede especificar la ubicación del respaldo y el período de retención del mismo. Establezca la
ubicación y programa de respaldo que mejor se ajusten a sus necesidades de datos. Haga clic en Siguiente.
9. Puede decidir respaldar la bitácora de transacciones como parte de su plan de recuperación de datos. En
este ejercicio, no respaldaremos la bitácora de transacciones porque ya hemos especificado la opción de base
de datos Truncar registro en punto de comprobación. Haga clic en Siguiente.

10. Aparece la pantalla Informes para generar. Tiene la opción de generar un reporte de texto para una
ubicación especificada y enviar el reporte por correo electrónico a un alias de correo electrónico especificado.
Seleccione las opciones que mejor se ajusten a sus necesidades de reporte. Haga clic en Siguiente.
11. el Historial de mantenimiento se puede almacenar en el servidor local o en un servidor remoto. Esto es
útil para monitorear y determinar tendencias en la información. Seleccione los métodos de rastreo de
historiales que mejor se ajusten a sus necesidades. Haga clic en Siguiente.

12. Finalmente, nombre a su plan de mantenimiento. Se recomienda que seleccione un nombre descriptivo
que identifique fácilmente al plan. Haga clic en Finalizar.

Nota: Los Planes de mantenimiento de base de datos se crean como trabajos en el Agente de SQL Server.
Puede activar su plan de mantenimiento al ejecutar el trabajo.
Ha creado satisfactoriamente su plan de mantenimiento para sus bases de datos. Puede ver o editar su plan
haciendo clic en la carpeta Administración en Enterprise Manager y seleccionando Planes de mantenimiento
de la base de datos.