Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Lo que aprenderá:
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
Lo que aprenderá:
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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
Lo que aprenderá:
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.
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 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.
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.
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.
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.
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.
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
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.
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
Modos de autenticación
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
Lo que aprenderá:
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.
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."
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.
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.
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.
Lo que aprenderá:
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.
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.
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.
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.
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 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
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.
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 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.
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.
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?
MODULO I
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.
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.
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.
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
EmpleadosID, Nombre, Apellido, Dir1, Dir2, Ciudad, Estado, CP,
Empleados
FechaIng, PosicionID
Posiciones PosicionID, Cargo, Descripcion
Clientes ClienteID, Nombre, Apellido, Telefono, Dir1, Dir2, Ciudad, Estado, CP
OrdenID, ClienteID, EmpleadoID, Monto, FechaOrden, FechaEnvio,
Ordenes
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).
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.
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.
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.
Su diseño de la base de datos debe parecer similar ahora al esquema en Figura 5.8.
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.
5. Para cada regla comercial, defina la 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
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.
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”.
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.
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.
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
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 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.
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
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.
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:
Variables
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.
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 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:
Tipo de Dato
Categoría Descripción Descripción
Base
Un dato Binary almacena
cadenas de bits. El dato
consiste de números
Los datos deben tener la misma
Binary hexadecimales. Por binary
longitud fija (hasta 8 KB)
ejemplo, el número
decimal 245 vale en
hexadecimal F5.
Los datos pueden variar en el
varbinary número de dígitos hexadecimales
(hasta 8 KB)
Los datos pueden ser de longitud
image
variable y exceder los 8 KB.
Los datos Character
consisten de cualquier
combinación de letras,
símbolos, y caracteres Los datos deben tener la misma
Character char
numéricos. Por ejemplo, longitud fija (hasta 8 KB)
datos character
válidos:"John928"
"(0*&(%B99nh jkJ"
Los datos pueden variar en el
varchar número de caracteres (hasta 8
KB)
text Los datos pueden ser cadena de
Tipo de Dato
Categoría Descripción Descripción
Base
caracteres ASCII que excedan los
8 KB.
Los datos Date time
consisten de
Los datos fecha están
combinaciones de fechas
comprendidos entre en el 1 de
o horas válidas. No
Date time datetime Enero de 1753 hasta el 31 de
existe tipos de datos
diciembre de 9999 (requiere 8
separados para fechas y
bytes por dato).
horas para almacenar
solo fechas o solo horas
Los datos fecha están
comprendidos entre en el 1 de
smalldatetime Enero de 1900 hasta el 31 de
diciembre de 2079 (requiere 4
bytes por dato).
Los datos pueden tener un
Los datos Decimal
máximo de 30 dígitos, que pueden
consisten de datos
estar todos a la derecha de la
Decimal numéricos que son decimal
coma decimal. El tipo de dato
almacenados al menor
almacena un representación
dígito significativo
exacta del número.
En SQL Server, el tipo de datos
numeric numeric es equivalente al tipo de
datos decimal.
Datos numéricos
aproximados que
consisten de datos con
Floating Desde –1.79E + 308 a 1.79E +
una aproximación tanto float
point 308.
como el sistema de
numeración binaria
pueda ofrecer
real Desde –3.40E + 38 a 3.40E + 38.
Los datos Integer
Desde –2^63 (–
consisten de números
9223372036854775808) a 2^63–
Integer enteros positivos y bigint
1 (9223372036854775807).
negativos tales como: –
Tamaño 8 bytes.
15, 0, 5, y 2.509.
Desde –2.147.483.648 a
int 2.147.483.647 (requiere de 4
bytes por valor).
Desde –32,768 a 32.767 (requiere
smallint
de 2 bytes por valor).
Desde cero a 255 (requiere de 1
tinyint
bytes por valor).
Desde –
Monetary representa
922.337.203.685.477,5808 a
Monetary montos de dinero money
+922.337.203.685.477,5807
positivos o negativos
Tamaño 8 bytes.
Tipo de Dato
Categoría Descripción Descripción
Base
Desde –214.748,3648 a
smallmoney
214.748,3647 Tamaño 4 bytes.
Special se utiliza para
Consisten en un 1 o un 0. Se usan
datos que caben en
Special bit para representar valores lógicos
ninguna de las categorís
VERDADERO o FALSO, SI o NO
anteriores.
Este tipo de dato es usado para
variables o prámetros OUTPUT en
procedimientos almacenados que
cursor contenga una referencia 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
timestamp del SQL Server 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
SQL_variant soportado por SQL Server 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.
Al usar tipo de datos
Unicode, una columna
puede almacenar
cualquier cualquier
caracter definido por el Los datos deben tener la misma
Unicode estándar Unicode. Lo nchar longitud fija (hasta 4000
cual incluye a todos los caracteres Unicode)
caracteres definidos en
los distintos conjuntos de
caracteres. Los tipos de
datos Unicode toman el
Tipo de Dato
Categoría Descripción Descripción
Base
doble de espacio de
almacenamiento que los
tipos no-Unicode.
Los datos pueden variar en el
nvarchar número de caracteres (hasta 4000
caracteres Unicode)
Los datos pueden exceder los
ntext
4000 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).
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
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.
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.
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
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.
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.
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í.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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
)
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).
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).
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.
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.
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.
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:
Una tabla y las columnas seleccionadas dentro de la tabla pueden ser registradas
para una indexación a texto completo(full-text indexing)
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.
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.
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
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 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
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.
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
Integridad referencial
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.
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)
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:
SQL Server soporta cuatro clases principales de restricciones: PRIMARY KEY, UNIQUE,
FOREIGN KEY y CHECK.
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.
Se pueden crear restricciones PRIMARY KEY utilizando uno de los siguientes métodos:
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:
Se puede usar el comando ALTER TABLE para agregar una restricción PRIMARY KEY a
una tabla existente:
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:
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 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 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.
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.
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.
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.
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.
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.
Se puede usar el comando ALTER TABLE para agregar una restricción FOREIGN KEY a
una tabla existente:
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:
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 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.
También se puede definir la misma restricción usando restricción CHECK a nivel tabla:
Se puede utilizar el comando ALTER TABLE para agregar una retricción CHECK a una
tabla existente:
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.
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.
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 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.
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:
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
Í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:
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.
Con un factor de llenado para permitir que las páginas crezcan como sea
necesario.
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.
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:
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.
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 í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.
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:
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.
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 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
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 ]
El siguiente comando CREATE INDEX usa las configuraciones por defecto para todas las
cláusulas opcionales:
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.
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.
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.
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:
Administrar índices
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:
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.
Renombrar un índice
@objtype = ‘INDEX’
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.
Í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.
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
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%’
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
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.
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.
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.
· Unión
Relaciones base
Unión (A UNION B)
Diferencia (A MINUS B)
· Intersección
· Diferencia
(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)
Relaciones base
A S# B P#
S1 P1
S2 P2
S3 P3
S4 P4
S5 P5
P6
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
Asociatividad
( 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
A UNION B
B UNION A
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:
1. A WHERE c1 AND c2
2. A WHERE c1 OR c2
3. A WHERE NOT c
A MINUS (A WHERE c)
S4 Corona 20 Londres
SP WHERE S# = ¨S1¨
AND P# = ¨P1¨
S# P# CANTIDAD
S1 P1 300
· Proyección
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#
S2
S3
· Reunión natural
(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)
A JOIN B JOIN C
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).
· Reunión - theta
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:
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
(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
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.
Por ejemplo, el siguiente comando SELECT recupera el ID, nombre y precio unitario de
cualquier producto cuyo precio unitario supere los $40:
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 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:
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:
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
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:
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 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 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:
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.
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.
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
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.
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:
NOTA
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.
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
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.
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.
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
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.
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.
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.
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.
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:
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
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).
El comando INSERT agrega una o más nuevas filas a una tabla. En un tratamiento
simplificado, el comando INSERT toma la siguiente forma:
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.
NOTA
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.
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.
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.
EL comando SELECT INTO permite crear una nueva tabla y llenarla con el resultado del
comando SELECT. Ver Tema 2 de este módulo
SQL Server incluye varios métodos para agregar valores ntext, text, o imagen a un
fila:
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
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.
SET
WHERE
FROM
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).
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.
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
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.
SQL Server provee varios métodos para modificar valores del tipo ntext, text, o image
en una fila cuando se reemplazan los valores completos:
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.
SQL Server soporta varios métodos para eliminar datos de una tabla:
El comando DELETE
APIs y cursores
El comando TRUNCATE TABLE
Un comando DELETE remueve una o más filas en una tabla o vista. La sintaxis
siguiente es una forma simplificada del comando DELETE:
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.
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
USE Pubs
TRUNCATE TABLE NuevosLibroswBooks
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.
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.
Rendimiento
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.
Seguridad
USE Pubs
GO
EXECUTE sp_table_privileges Stores
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 Commented [AMA1]:
Procedures” en SQL Server Books Online.
Procedimientos almacenados locales
USE Master
USE Master
name id
byroyalty 581577110
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).
Usar códigos de retorno para mostrar información acerca del éxito o falla de
una tarea.
USE Pubs
GO
CREATE PROCEDURE [dbo].[ListAuthorNames]
AS
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:
AS
GO
AS
GO
GO
AS
GO
USE Pubs
GO
AS
Enterprise Manager
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.
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.
USE Pubs
GO
USE Pubs
GO
EXECUTE au_info
Green, 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.
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.
USE Master
RECONFIGURE
GO
USE PUBS
GO
EXECUTE sp_rename
@objtype = ‘object’
USE Pubs
GO
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.
Los cuidados indicados al final del punto anterior también son válidos para las operaciones
de eliminación.
MODULO IV: Implementar 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.
USE Pubs
GO
AS
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.
EXECUTE SalesForTitle
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í:
EXECUTE SalesForTitle
GO
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.
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.
Number Return of
Title Code
Sales
Onions, Leeks, and Garlic: Cooking Secrets of the
375 0
Mediterranean
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):
AS
RETURN(1)
ELSE
GO
@Title = "Garlic%"
IF @r_Code = 0
ELSE IF @r_Code = 1
GO
MODULO IV: Conectarse a un SQL Server
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:
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 esquema siguiente muestra los objetos y las relaciones existentes entre los objetos
y el modelo.
Los objetos Connection, Recordset y Command son los objetos más significativos de
este modelo. Clásicamente, una aplicación las utiliza como:
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
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
cn.Provider = "SQLOLEDB"
cn.Open "Data Source=MySQLServerName;Initial Catalog=pubs;", "sa", ""
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
End Sub
Sub ParameterExample()
Dim cmd As New ADODB.Command
Dim rs As New ADODB.Recordset
Dim prm As ADODB.Parameter
End Sub
Exit Sub
AdoError:
Dim Errs As ADODB.Errors
Dim errLoop As Error
Dim strError As String
End Sub
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"
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
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.
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.
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.
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.
Propiedades
Métodos
Colecciones
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:
· Examinar los errores devueltos por el origen de datos con la colección Errors.
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.
Propiedades
Métodos
Colecciones
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 Number, que contiene el valor entero Long de la constante del error.
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
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.
· 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.
· 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.
Propiedades
Colecciones
Colección Properties.
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.
· 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).
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
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
Se aplica a
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
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:
End Sub
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.
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:
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:
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))
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:
rs.CursorLocation = adUseClient
rs.ActiveConnection = "Provider=sqloledb;" & _
"Data Source=srv;Initial Catalog= pubs;UserId=sa;Password=;"
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
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
Comentarios
Se aplica a
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,
File Name= un objeto de origen de 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
provider= del lado del cliente (solamente con Remote Data Service).
Remote Especifica la ruta de acceso del servidor que se usa al abrir una conexión
Server= del lado del cliente (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).
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
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.
Se aplica a
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
adUseNone
únicamente por 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 proporcionados por
adUseClient 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.
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
adUseServer 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.
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.
Ejemplo
Este ejemplo utiliza las propiedades ActiveConnection, CommandText,
CommandTimeout, CommandType. Size y Direction para ejecutar un procedimiento
almacenado:
' Open the Authors table to get author names for display.
Set rstAuthors = New ADODB.Recordset
rstAuthors.Open "authors", strCnn, , , adCmdTable
rstByRoyalty.Close
rstAuthors.Close
cnn1.Close
End Sub
Se aplica a
End Sub
Se aplica a
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.
Se aplica a
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:
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
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.
rstPublishers.Close
End Sub
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.
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.