Bases - De.datos - con.SQL - Server.2000.transact - Sql. .Jorge - Moratalla.grupo - Eidos

El texto est diseado
para programadores,
analistas o tcnicos de
sistemas que deseen
conocer la mecnica de
trabajo de las bases de
datos a travs del uso de
una de ellas en concreto:
Microsoft SQL Server
2000.
Aspectos que se revisan:

1- Conceptos tericos
sobre Bases de Datos.
2- Diseo y modelizacin
de datos tomando como
base el modelo
Entidad/Relacin
3- Generalidades de SQL
Server 2000
4- Lenguaje SQL a travs
de la implementacin del
mismo en SQL Server
2000 (Transact SQL)
5- Ejemplos de diseo
utilizando una
herramienta CASE: Power
Designor

Se requiere como mnimo
tener conocimientos del
sistema operativo
Windows a nivel de
usuario. No es
imprescindible, aunque si
recomendable, conocer
fundamentos de
programacin.

B
BA AS SE ES S D DE E D
DA AT TO OS S C CO ON N S
S
Q
Q
L
L

S
SE ER RV VE ER R 2
2
0
0
0
0
0
0
.
.
T
TR RA AN NS SA AC CT T S
S
Q
Q
L
L

J JO OR RG GE E M MO OR RA AT TA AL LL LA A
Desarrollo de software
ADVERTENCIA LEGAL
Todos los derechos de esta obra estn reservados a Grupo EIDOS Consultora y Documentacin Informtica,
S.L.
El editor prohbe cualquier tipo de fijacin, reproduccin, transformacin, distribucin, ya sea mediante venta
y/o alquiler y/o prstamo y/o cualquier otra forma de cesin de uso, y/o comunicacin pblica de la misma, total
o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio mecnico o
electrnico, incluido el tratamiento informtico de la misma, en cualquier lugar del universo.
El almacenamiento o archivo de esta obra en un ordenador diferente al inicial est expresamente prohibido, as
como cualquier otra forma de descarga (downloading), transmisin o puesta a disposicin (an en sistema
streaming).
La vulneracin de cualesquiera de estos derechos podr ser considerada como una actividad penal tipificada en
los artculos 270 y siguientes del Cdigo Penal.
La proteccin de esta obra se extiende al universo, de acuerdo con las leyes y convenios internacionales.
Esta obra est destinada exclusivamente para el uso particular del usuario, quedando expresamente prohibido su
uso profesional en empresas, centros docentes o cualquier otro, incluyendo a sus empleados de cualquier tipo,
colaboradores y/o alumnos.
Si Vd. desea autorizacin para el uso profesional, puede obtenerla enviando un e-mail fmarin@eidos.es o al fax
(34)-91-5017824.
Si piensa o tiene alguna duda sobre la legalidad de la autorizacin de la obra, o que la misma ha llegado hasta
Vd. vulnerando lo anterior, le agradeceremos que nos lo comunique al e-mail fmarin@eidos.es o al fax (34)-91-
5012824). Esta comunicacin ser absolutamente confidencial.
Colabore contra el fraude. Si usted piensa que esta obra le ha sido de utilidad, pero no se han abonado los
derechos correspondientes, no podremos hacer ms obras como sta.
Jorge Moratalla, 2001
Grupo EIDOS Consultara y Documentacin Informtica, S.L., 2000
ISBN 84-88457-24-3
Bases de datos con SQL Server 2000. Transact SQL
Jorge Moratalla

Responsable editorial
Paco Marn (fmarin@eidos.es)
Autoedicin
Magdalena Marn (mmarin@eidos.es)
Jorge Moratalla (jmoratalla@eidos.es)
Coordinacin de la edicin
Antonio Quirs (aquiros@eidos.es)

Grupo EIDOS
C/ Tllez 30 Oficina 2
28007-Madrid (Espaa)
Tel: 91 5013234 Fax: 91 (34) 5017824
www.grupoeidos.com/www.eidos.es
www.LaLibreriaDigital.com
ndice
NDICE................................................................................................................................................... 5
INTRODUCCIN................................................................................................................................. 9
DEFINICIN DE BASE DE DATOS........................................................................................................... 9
CONCEPTOS BSICOS ......................................................................................................................... 10
DEL ENFOQUE TRADICIONAL A LOS SISTEMAS DE BASES DE DATOS ................................................. 10
ARQUITECTURA ANSI/X3/SPARC ................................................................................................... 12
EL MODELO RELACIONAL .................................................................................................................. 12
VISIN GENERAL SOBRE EL DISEO DE BASES DE DATOS.............................................. 15
FASES DEL DISEO............................................................................................................................. 15
DISEO CONCEPTUAL ........................................................................................................................ 17
DISEO LGICO.................................................................................................................................. 17
DISEO FSICO.................................................................................................................................... 21
DISEO CONCEPTUAL................................................................................................................... 23
INTRODUCCIN.................................................................................................................................. 23
ETAPAS DEL DISEO CONCEPTUAL .................................................................................................... 24
EL MODELO ENTIDAD / RELACIN ..................................................................................................... 24
EJEMPLOS PRCTICOS DE DISEO CONCEPTUAL................................................................................ 29
DISEO LGICO............................................................................................................................... 35
INTRODUCCIN.................................................................................................................................. 35
PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA LGICO ESTNDAR ............................................... 36
ETAPAS EN EL DISEO LGICO........................................................................................................... 37
PARTICIONAMIENTO HORIZONTAL DE RELACIONES .......................................................................... 38
PARTICIONAMIENTO VERTICAL DE RELACIONES ............................................................................... 41
PARTICIONAMIENTO MIXTO............................................................................................................... 44
TEORA DE LA NORMALIZACIN........................................................................................................ 45
EJEMPLOS PRCTICOS DE NORMALIZACIN ...................................................................................... 49
PROCESO DE DESNORMALIZACIN .................................................................................................... 55
DISEO FSICO................................................................................................................................. 57
INTRODUCCIN.................................................................................................................................. 57
ESTRATEGIAS EN EL DISEO FSICO................................................................................................... 58
CONCEPTOS BSICOS SOBRE GESTIN DE FICHEROS ......................................................................... 58
ORGANIZACIN DE FICHEROS............................................................................................................ 59
TCNICAS PARA EL AUMENTO DE EFICIENCIA ................................................................................... 59
INTRODUCCIN A SQL SERVER................................................................................................. 63
QU ES SQL SERVER?...................................................................................................................... 63
ORGENES........................................................................................................................................... 64
SQL SERVER E INTERNET.................................................................................................................. 64
LO NUEVO EN SQL-SERVER 2000................................................................................................ 65
INTRODUCCIN.................................................................................................................................. 65
NUEVAS CARACTERSTICAS............................................................................................................... 65
SOPORTE PARA XML......................................................................................................................... 66
PARTICIONAMIENTO HORIZONTAL DE RELACIONES Y GESTIN DE VISTAS DISTRIBUIDAS ............... 67
SOPORTE PARA VIRTUAL INTERFACE ARCHITECTURE (VIA) ........................................................... 67
FUNCIONES DE USUARIO.................................................................................................................... 67
INDEXACIN DE VISTAS ..................................................................................................................... 67
NUEVOS TIPOS DE DATOS................................................................................................................... 67
NUEVOS TRIGGERS............................................................................................................................. 68
REGLAS DE INTEGRIDAD REFERENCIAL EN CASCADA ....................................................................... 68
NUEVAS CARACTERSTICAS DE INDEXACIN .................................................................................... 68
SOPORTE PARA CONSULTAS DISTRIBUIDAS ....................................................................................... 68
CARACTERSTICAS DE SEGURIDAD Y CIFRADO DE DATOS................................................................. 68
INSTALACIN DE SQL SERVER 2000 ......................................................................................... 69
EL MODELO E/R EN SQL-SERVER 2000..................................................................................... 75
INTRODUCCIN.................................................................................................................................. 75
CREAR UN NUEVO DIAGRAMA ........................................................................................................... 77
RESTRICCIONES E INTEGRIDAD REFERENCIAL................................................................................... 79
MODIFICACIN DEL ESQUEMA........................................................................................................... 81
CREAR UNA NUEVA RELACIN .......................................................................................................... 82
EL ANALIZADOR DE CONSULTAS.............................................................................................. 85
INTRODUCCIN.................................................................................................................................. 85
LAS OPCIONES DE MEN.................................................................................................................... 85
LA BARRA DE HERRAMIENTAS........................................................................................................... 91
EJECUTANDO UNA CONSULTA ........................................................................................................... 92
EL LENGUAJE DE DEFINICIN DE DATOS (DDL) .................................................................. 97
INTRODUCCIN.................................................................................................................................. 97
TIPOS DE DATOS................................................................................................................................. 97
CREACIN DE TABLAS ....................................................................................................................... 99
MODIFICACIN DE TABLAS.............................................................................................................. 100
BORRADO DE TABLAS ...................................................................................................................... 101
CREACIN Y BORRADO DE NDICES ................................................................................................. 101
7
EJEMPLOS PRCTICOS DE USO DEL DDL............................................................................. 103
INTRODUCCIN................................................................................................................................ 103
LA SENTENCIA CREATE TABLE ................................................................................................... 103
LA SENTENCIA ALTER TABLE...................................................................................................... 107
LA SENTENCIA DROP TABLE........................................................................................................ 111
LA SENTENCIA CREATE INDEX.................................................................................................... 112
LA SENTENCIA DROP INDEX......................................................................................................... 112
EL LENGUAJE DE MANIPULACIN DE DATOS (DML) ....................................................... 115
INTRODUCCIN................................................................................................................................ 115
LA SENTENCIA SELECT .................................................................................................................... 115
LA CLUSULA WHERE..................................................................................................................... 117
LA CLUSULA GROUP BY ................................................................................................................ 118
LA CLUSULA HAVING.................................................................................................................... 119
LA CLUSULA ORDER BY ................................................................................................................ 119
FUNCIONES ESCALARES PARA SELECT ............................................................................................ 119
LA SENTENCIA INSERT..................................................................................................................... 122
LA SENTENCIA UPDATE ................................................................................................................... 123
LA SENTENCIA DELETE.................................................................................................................... 123
OPERADORES BSICOS Y CONSIDERACIONES DEL LENGUAJE................................... 125
INTRODUCCIN................................................................................................................................ 125
OPERADOR PROYECCIN ................................................................................................................. 125
OPERADOR UNION ........................................................................................................................... 127
OPERADOR JOIN............................................................................................................................... 128
OPERADORES PROPIOS DE TRANSACT SQL..................................................................................... 132
VARIABLES GLOBALES..................................................................................................................... 135
SENTENCIAS CONDICIONALES.......................................................................................................... 137
SENTENCIAS ITERATIVAS................................................................................................................. 138
LA SENTENCIA INSERT................................................................................................................ 139
INTRODUCCIN................................................................................................................................ 139
SINTAXIS.......................................................................................................................................... 139
EJEMPLOS......................................................................................................................................... 140
CARGA DE LA BASE DE DATOS DE EJEMPLO..................................................................................... 143
LA SENTENCIA SELECT............................................................................................................... 147
INTRODUCCIN................................................................................................................................ 147
LA CLASULA WHERE................................................................................................................... 148
EL OPERADOR JOIN .......................................................................................................................... 149
LAS FUNCIONES DE AGREGADO....................................................................................................... 151
LA CLASULA GROUP BY............................................................................................................. 154
LA SENTENCIA UPDATE.............................................................................................................. 157
INTRODUCCIN................................................................................................................................ 157
EJEMPLOS......................................................................................................................................... 157
LA SENTENCIA DELETE.............................................................................................................. 163
INTRODUCCIN................................................................................................................................ 163
LA INTEGRIDAD REFERENCIAL......................................................................................................... 164
LA SENTENCIA TRUNCATE TABLE.............................................................................................. 165
EJEMPLOS......................................................................................................................................... 166
PROCEDIMIENTOS ALMACENADOS Y TRIGGERS ............................................................. 169
INTRODUCCIN................................................................................................................................ 169
PARMETROS POR REFERENCIA....................................................................................................... 170
PROCEDIMIENTOS ALMACENADOS DE SISTEMA............................................................................... 172
EXTENDED STORED PROCEDURES.................................................................................................... 173
TRIGGERS......................................................................................................................................... 174
EJEMPLOS PRCTICOS DE USO DE PROCEDIMIENTOS ALMACENADOS.................. 177
INTRODUCCIN................................................................................................................................ 177
LA SENTENCIA IF ... ELSE............................................................................................................... 177
LA SENTENCIA CASE ...................................................................................................................... 179
EJECUCIN DINMICA DE SENTENCIAS: LA INSTRUCCIN EXEC................................................... 180
CONVERSIN DE TIPOS..................................................................................................................... 181
LA SENTENCIA WHILE.................................................................................................................... 182
TRIGGERS EN SQL-SERVER 2000 .............................................................................................. 183
INTRODUCCIN................................................................................................................................ 183
LAS TABLAS DELETED E INSERTED.................................................................................................. 184
TIPOS DE DESENCADENADORES....................................................................................................... 184
LIMITACIONES DE LOS TRIGGERS..................................................................................................... 184
RESOLUCIN DIFERIDA DE NOMBRES .............................................................................................. 185
EJEMPLOS......................................................................................................................................... 185
SEGURIDAD..................................................................................................................................... 189
INTRODUCCIN................................................................................................................................ 189
CONCESIN DE PRIVILEGIOS............................................................................................................ 189
REVOCACIN DE PRIVILEGIOS ......................................................................................................... 191
DENEGACIN DE PERMISOS ............................................................................................................. 193
MANTENIMIENTO DE VISTAS ........................................................................................................... 193
RECOMENDACIONES ........................................................................................................................ 194
EJEMPLO PRCTICO DE IMPLEMENTACIN...................................................................... 195
INTRODUCCIN................................................................................................................................ 195
LENGUAJE DE DEFINICIN DE DATOS............................................................................................... 196
LENGUAJE DE MANIPULACIN DE DATOS ........................................................................................ 198
PRESENTE Y FUTURO DE LAS BASES DE DATOS ................................................................ 203
DISEO CONCEPTUAL CON POWER DESIGNOR................................................................. 207
INTRODUCCIN................................................................................................................................ 207
CREACIN DE UNA ENTIDAD............................................................................................................ 208
CREACIN DE RELACIONES.............................................................................................................. 213
LA RELACIN DE HERENCIA............................................................................................................. 215
DISEO FSICO CON POWER DESIGNOR............................................................................... 217
PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA FSICO ................................................................. 217
MODIFICACIN DE LAS TABLAS....................................................................................................... 218
COLUMNAS ...................................................................................................................................... 219
INDICES ............................................................................................................................................ 219
ATRIBUTOS EXTENDIDOS................................................................................................................. 221
TRIGGERS......................................................................................................................................... 221
RESTRICCIONES................................................................................................................................ 222
CREACIN DE VISTAS....................................................................................................................... 222
EJEMPLO DE DISEO CON POWER DESIGNOR................................................................... 225
Introduccin
Definicin de base de datos
La primera pregunta que surge a la hora de comenzar este curso es la siguiente: Qu es una Base de
Datos?. Existen varias definiciones para responder a esta pregunta:
"Coleccin de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales
o innecesarias; su finalidad es servir a una aplicacin o ms, de la mejor manera posible; los
datos se almacenan de modo que resulten independientes de los programas que los usan; se
emplean mtodos bien determinados para incluir nuevos datos y para modificar o extraer los
datos almacenados". (Martin, 1975).
"Coleccin o depsito de datos, donde los datos estn lgicamente relacionados entre s,
tienen una definicin y descripcin comunes y estn estructurados de una forma particular.
Una base de datos es tambin un modelo del mundo real y, como tal, debe poder servir para
toda una gama de usos y aplicaciones". (Conference des Statisticiens Europens, 1977).
"Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por
numerosas personas y cuya organizacin est regida por un modelo de datos". (Flory, 1982).
"Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador para
satisfacer simultneamente a varios usuarios de forma selectiva y en tiempo oportuno".
(Delobel, 1982).
"Coleccin no redundante de datos que son compartidos por diferentes sistemas de
aplicacin". (Howe, 1983).

Bases de datos con SQL Server 2000 Transact SQL Grupo EIDOS

10
"Coleccin integrada y generalizada de datos, estructurada atendiendo a las relaciones
naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de
datos con objeto de poder atender todas las necesidades de los diferentes usuarios". (Deen,
1985).
"Conjunto de ficheros maestros, organizados y administrados de una manera flexible de modo
que los ficheros puedan ser fcilmente adaptados a nuevas tareas imprevisibles". (Frank,
1988).
"Coleccin de datos interrelacionados". (Elsmari y Navathe, 1989).
Como se ha visto, el concepto de base de datos ha ido cambiando a lo largo del tiempo. En la
actualidad podemos establecer la definicin de base de datos como sigue.
"Coleccin o depsito de datos integrados, almacenados en soporte secundario (no voltil) y con
redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios y aplicaciones,
deben mantenerse independientes de ellos, y su definicin (estructura de la base de datos) nica y
almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar
las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualizacin y
recuperacin, comunes y bien determinados, facilitarn la seguridad del conjunto de los datos".
Conceptos bsicos
Sistema de Gestin de Base de Datos (SGBD): Conjunto de programas que permiten la
implantacin, acceso y mantenimiento de la base de datos. El SGBD, junto con la base de
datos y con los usuarios, constituyen el Sistema de Base de Datos.
Modelo de datos: Conjunto de conceptos que permiten describir, a distintos niveles de
abstraccin, la estructura de una base de datos, a la cual denominamos esquema.
Sistema de Informacin: Coleccin de personas, procedimientos y equipos diseados,
construidos, operados y mantenidos para recoger, registrar, procesar, almacenar y recuperar
esa informacin.
Esquema de una Base de Datos: Estructura de la Base de Datos.
Ocurrencia del esquema: Conjunto de datos que se encuentran almacenados en el esquema en
un momento determinado. El esquema no vara mientras no vare el mundo real que ste
describe, mientras que una ocurrencia del esquema es distinta en el transcurso del tiempo.
Del enfoque tradicional a los sistemas de bases de datos
Para comprender mejor las diferencias entre los sistemas tradicionales basados en ficheros y los
sistemas de bases de datos, pongamos un ejemplo. Supngase que disponemos de un archivo maestro
de clientes con la siguiente informacin: nombre, direccin, ciudad, provincia y telfono. Si adems de
esto, aadimos dos ficheros, uno para la emisin de facturas, y otro para la emisin de informes,
podemos encontrarnos con los siguientes problemas:
Produccin de inconsistencias o incoherencias, debido a la replica de informacin (la misma
informacin puede estar almacenada en distintos ficheros).
Grupo EIDOS 1. Introduccin.

11
Malgasto de memoria secundaria (por el mismo motivo).
Si en este momento se quiere aadir en nmero de fax, se hace necesario una completa
reestructuracin de dicho fichero, sin mencionar el rediseo del cdigo de la aplicacin, para
dar cabida a este cambio.
En cambio, en un sistema de gestin de bases de datos, estos problemas no tienen cabida, ya que el
control de la informacin es inherente al propio sistema.
Algunas de las ventajas que ofrece utilizar un Sistema de Bases de Datos son las siguientes:
1. Independencia entre datos y tratamientos. El cambio en los programas no influye en la
disponibilidad de los datos, as como la modificacin de stos no afecta a la reprogramacin
de las aplicaciones que los usan.
2. Coherencia de resultados: Debido a que los datos son almacenados una sola vez, se evitan los
problemas que puede ocasionar la redundancia. Ms adelante veremos cmo se permite una
cierta duplicidad de datos, con el fin de conseguir una mayor eficiencia, controlada por el
sistema y que no afecta a la redundancia lgica.
3. Mejor disponibilidad de datos para los usuarios: Los datos son compartidos por un conjunto de
usuarios, que accede a ellos de forma concurrente, siempre que estn autorizados a ello.
4. Mayor valor informativo: El conjunto de los datos almacenados en la BD ofrece un mayor
valor informativo, que la suma de ellos independientemente.
5. Mayor eficiencia en la recogida, validacin e introduccin de los datos en el sistema: Al no
existir redundancia, los datos se recogen y validan una sola vez, aumentando as la eficiencia.
6. Reduccin del espacio de almacenamiento: La desaparicin (o disminucin) de redundancias,
unido a las tcnicas de compactacin, implica una menor ocupacin de almacenamiento
secundario.
A pesar de todas estas ventajas, los Sistemas de Bases Datos no estn exentos de inconvenientes. Aqu
se detallan los ms importantes:
1. Instalacin costosa: La implantacin de un sistema de base de datos puede implicar un coste
elevado, tanto en el equipo fsico (adquisicin de nuevas instalaciones, o ampliaciones de las
existentes) como en el lgico (sistemas operativos, programas, compiladores, etc.), as como
el coste de adquisicin o mantenimiento del SGBD.
2. Implantacin larga y difcil: Debido a las causas mencionadas anteriormente, la implantacin
de un sistema de base de datos puede convertirse en una tarea larga y complicada.
3. Falta de rentabilidad a corto plazo: Los amplios costes que conlleva la implantacin, implica
una rentabilidad no a corto, sino a medio, o incluso largo plazo.
4. Escasa estandarizacin: Esto supone una dificultad aadida a los usuarios de la base de datos.
5. Desfase entre teora y prctica: Los constantes avances tericos en al mbito de las bases de
datos, que muchas veces no se ven traducidos en la prctica, hacen llevarse a engao a muchos
usuarios, creyendo que constituyen ya una realidad, cuando no han sido todava plasmados.

12
Arquitectura ANSI/X3/SPARC
ANSI/X3/SPARC es un grupo de estudio del Standard Planning and Requirements Commitee
(SPARC) del ANSI (American National Standars Institute), dentro del Comit X3 que se ocupa de
ordenadores e informtica. En sus estudios acerca de los SGBD, propugnaron una arquitectura basada
en tres niveles de abstraccin:
1. Nivel Externo: Es el nivel ms cercano a los usuarios, y en el se definen los datos tal y como
los va a ver este. Cada usuario puede tener su propio modelo externo, con aquellos datos e
interrelaciones que dicho usuario necesite. En este nivel, tambin debern definirse las
restricciones de uso, como por ejemplo el derecho a insertar o borrar determinados datos, o
poder acceder a ellos.
2. Nivel Conceptual: Proporciona una descripcin global del esquema independiente de la
estructura fsica de la base de datos, es decir, cuales son los datos, como estn organizados, las
relaciones entre ellos y las restricciones de integridad y confidencialidad. El modelo
conceptual, que es nico, establece el modelo terico sobre el que estn asentados los modelos
externos.
3. Nivel Interno: Nivel ms bajo en la abstraccin. Describe la estructura almacenamiento fsico
de los datos, las estrategias de acceso a los datos, etc. As mismo especifica todos los aspectos
relacionados con el hardware, como por ejemplo dispositivos de memoria a usar (tamao de
pginas, nmero de stas, tamao de los buffers, etc.), tcnicas de compresin de datos,
criptografiado, etc. El modelo interno, que es nico, corresponde a la implementacin del
modelo conceptual.
El modelo relacional
El modelo ms usado, y por lo tanto el que se estudiar en este curso, es el modelo relacional. El
motivo de que sea ste el modelo ms extendido, radica en la facilidad y en su amplia base
matemtica, lo que permitir, como ya se ver ms adelante, el poder estructurar o reestructurar las
relaciones, para evitar cierto tipo de anomalas, o acelerar las consultas / actualizaciones. Dicho
modelo se basa en la representacin de la informacin por medio de estructuras tipo tabla,
denominadas relaciones, y que almacenan informacin para una determinada entidad. Cada una de
estas relaciones representa en sus columnas los valores significativos, es decir, de los que interesa
conocer su valor, para cada entidad. Dichas columnas se denominan atributos, y para cada uno de ellos
existir un valor (cabe la posibilidad de que existan atributos en los que no aparezca ningn valor).
Cada fila representa la informacin para cada ocurrencia de una determinada entidad. La informacin
se descompondr, como ya se ha dicho, en dar valores para cada uno de los atributos de la entidad. A
dichas filas tambin se las denomina tuplas. Cada atributo o conjunto de atributos que identifica
unvocamente a cada tupla de la relacin se denomina clave. Las claves se representan subrayando el /
los atributo/s que forman parte de ella.
El siguiente ejemplo (Figura 1) representa una relacin denominada empleado, que almacena
informacin sobre los empleados de una empresa. La informacin que se desea saber de cada
empleado es su cdigo, su nombre y apellidos, su sueldo y su categora. Por lo tanto, los atributos son
cod_empleado, nombre, apellidos, sueldo y categora. Adems, el atributo cod_empleado es clave de
la relacin, ya que si se sabe el valor de dicho atributo, se puede saber a que empleado nos estamos
refiriendo.

Grupo EIDOS 1. Introduccin.

13

Figura 1
Visin general sobre el diseo de bases
de datos
Fases del diseo
El diseo de una base de datos suele descomponerse en tres grandes fases (diseo conceptual, lgico y
fsico), lo que permite reducir la complejidad que entraa el diseo, a la vez que ayuda a alcanzar los
dos principales objetivos que tienen las bases de datos:
Ser una representacin fidedigna del mundo real,
Ser un servidor operacional y eficiente de los datos.
El diseo conceptual parte de la especificacin de requerimientos, y produce como resultado el
esquema conceptual de la base de datos. Un esquema conceptual es una descripcin a alto nivel de la
estructura de la base de datos, independientemente de la eleccin del equipamiento y del Sistema
Gestor de Base de Datos (en adelante referido como SGBD) que se usen para la implementacin de la
base de datos.
El diseo lgico parte del esquema conceptual y genera el esquema lgico. Un esquema lgico es la
descripcin de la estructura de la base de datos que puede procesarse por un SGBD. Una vez elegido
el modelo lgico, pueden existir un conjunto de esquemas lgicos equivalentes al mismo esquema
conceptual. La meta del diseo lgico es producir el esquema lgico ms eficiente con respecto a las
operaciones de consulta y actualizacin.


16
El diseo fsico toma como punto de partida el esquema lgico y como resultado produce el esquema
fsico. Un esquema fsico es una descripcin de la implementacin de la base de datos en memoria
secundaria; describe las estructuras de almacenamiento y los mtodos de acceso para acceder a los
datos de una manera eficiente. Por ello, el diseo fsico se genera para un SGBD y un entorno fsico
determinado.

Figura 2. Diseo de una base de datos

En la Figura 2 se resumen las tres grandes fases del diseo de una base de datos: primero se disea el
esquema conceptual (que se realiza con un modelo conceptual de datos), esquema que proporciona
una descripcin estable de la base de datos (independiente del SGBD) que se vaya a utilizar;
posteriormente se pasa del esquema conceptual al modelo de datos propio de SGBD elegido (diseo
lgico); por ltimo se eligen las estructuras de almacenamiento, los caminos de acceso (ndices), y
todos los aspectos relacionados con el diseo fsico.

Figura 3. Correspondencia entre el diseo y la arquitectura ANSI/X3/SPARC

Grupo EIDOS 2. Visin general sobre el diseo de bases de datos.

17
La Figura 3 muestra la correspondencia existente entre las fases de diseo y los niveles de la
arquitectura ANSI/X3/SPARC. El diseo conceptual es una etapa previa al diseo lgico. A su vez, el
diseo lgico se corresponde con los niveles externo (donde se definen las vistas de usuario, es decir,
conjunto de informacin que puede ser accedida por un usuario) y lgico (estructura de tablas y
restricciones) de la arquitectura ANSI/X3/SPARC. El diseo fsico se corresponde con el nivel fsico
de dicha arquitectura.
Diseo conceptual
El objetivo del diseo conceptual, tambin denominado modelo conceptual, y que constituye la
primera fase de diseo, es obtener una buena representacin de los recursos de informacin de la
empresa, con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre
eficiencia del ordenador. Consta de dos fases:
Anlisis de requisitos: Es en esta etapa donde se debe responder a la pregunta: qu
representar?. Se pretende en esta etapa elaborar un esquema descriptivo del mundo real,
mediante distintas tcnicas, aunque la ms usada es la de entrevistas a los usuarios, lo que
implica una descripcin de los datos mediante el uso del lenguaje natural. Los problemas que
presenta esta primera especificacin, se irn refinando hasta obtener el esquema conceptual.
Conceptualizacin: En esta etapa se intenta responder a la pregunta: cmo representar?.
Consiste en ir refinando sucesivamente el primer esquema descriptivo, para conseguir pasar
del mundo real al esquema descriptivo y de ste al esquema conceptual, que deber ser
expresado sin tener en consideracin cuestiones de implementacin, es decir, debe ser
independiente del SGBD a usar.
Diseo lgico
El objetivo del diseo lgico es transformar el esquema conceptual obtenido en la fase anterior,
adaptndolo al modelo de datos en el que se apoya el SGBD que se va a utilizar.
El modelo relacional es el nico modelo que ha permitido abordar la fase de diseo lgico aplicando
una teora formal: el proceso de normalizacin.
Sin embargo, la normalizacin no cubre toda esta fase, mostrndose insuficiente para alcanzar todos
los objetivos de la misma. En la prctica a veces es preciso proceder a una reestructuracin de las
relaciones.
La Figura 4, resume la fase de diseo lgico, en la que una vez estructurado el esquema origen,
analizando diferentes factores como las distintas dependencias o la posibilidad de existencia de valores
nulos, se obtiene un esquema relacional, al que se aaden las claves ajenas y otras restricciones de
integridad. Ahora bien, si se tiene en cuenta el segundo de los objetivos mencionados anteriormente, el
de que la base de datos ha de ser un servidor operacional y eficiente de los datos, se hace necesaria una
reestructuracin de relaciones, con el fin de mejorar la eficiencia de la base de datos.
Esta reestructuracin toma como entrada el esquema relacional estructurado obtenido anteriormente,
as como el anlisis de los requisitos de determinadas vistas o aplicaciones crticas, obteniendo de esta
manera un esquema relacional resultante, en el que priman las consideraciones de eficiencia.
En la Figura 4, se detallan las dos etapas en las que se divide la fase de diseo lgico. La primera,
consistente en la estructuracin de las relaciones atendiendo a consideraciones de tipo lgico, incluye

18
la normalizacin, as como el particionamiento horizontal de las mismas cuando sea necesario,
mientras que en la segunda se reestructuran las relaciones teniendo en cuenta consideraciones de tipo
fsico que pueden llevar a la desnormalizacin, o al particionamiento horizontal, vertical o mixto. La
razn de esta etapa de reestructuracin se encuentra en la falta de flexibilidad de la estructura interna
de los actuales SGBD, los cuales no ofrecen los adecuados instrumentos de diseo fsico, obligando a
trasladar a la fase de diseo lgico consideraciones de eficiencia que deberan ser ajenas a dicha fase.

Figura 4. Estructuracin y reestructuracin de relaciones

El objetivo de la estructuracin de relaciones es obtener un esquema relacional estructurado, tomando
como entrada un esquema relacional origen con todas sus dependencias, valores inaplicables, etc.
En esta etapa de estructuracin se conseguir, por razones lgicas, un esquema normalizado, en el cual
se han eliminado los valores nulos (inaplicables) mediante un particionamiento horizontal basado en la
seleccin, seguido de la proyeccin.
Las herramientas para llevar a cabo este objetivo son dos:

19
El proceso de normalizacin
El particionamiento horizontal de relaciones
El proceso de normalizacin consiste en sustituir una relacin por un conjunto de esquemas
equivalentes, que representan la misma informacin que la relacin origen, pero que no presentan
cierto tipo de anomalas a la hora de realizar operaciones sobre ella, como se muestra en la Figura 5,
en la que una relacin origen ha sido sustituida por otras dos, mediante un proceso de normalizacin.

Figura 5. Normalizacin de relaciones

El particionamiento horizontal de relaciones, permite eliminar valores nulos inaplicables que pueden
aparecer en las relaciones mediante un proceso de seleccin, seguido de proyecciones sobre las
relaciones resultantes. El resultado de este particionamiento horizontal ser la divisin de una relacin
en la que existen o pueden existir valores nulos, en varias relaciones en las que los valores nulos
inaplicables no tienen cabida.

Figura 6. Particionamiento horizontal de relaciones

El objetivo de la reestructuracin es el de mejorar la eficiencia de la base de datos. En la primera etapa
de estructuracin de relaciones, se ha propugnado por razones lgicas, normalizar el esquema, as
como eliminar los valores nulos mediante un proceso de particionamiento horizontal. Sin embargo,
esto no quiere decir que las relaciones que se vayan a almacenar en la base de datos sean las
resultantes de estos procesos, ya que se ha logrado el primero de los objetivos de las bases de datos
(ser una representacin fidedigna del mundo real), pero puede que no el segundo: el de que la base de

20
datos ha de ser un servidor operacional y eficiente de los datos, por lo que se hace necesaria esta
segunda etapa en el diseo lgico. Para lograr este objetivo existen diversos mtodos o formas de
organizar los datos, considerando esta idea de mejora de la eficiencia, que son:
El proceso de desnormalizacin
El particionamiento de relaciones
El proceso de desnormalizacin es justamente el proceso inverso al de normalizacin. La Figura 7,
muestra un ejemplo en el que dos tablas previamente normalizadas, dan origen a una tabla ms grande
(que es justamente la tabla que se tena antes de realizar la normalizacin), mediante un proceso de
desnormalizacin.

Figura 7. Desnormalizacin de relaciones

El particionamiento de relaciones es otra forma de conseguir una mayor eficiencia en la base de datos.
El objetivo de este proceso es dada una relacin, dividirla en otras relaciones de forma horizontal, o
vertical, o mixta (incluye ambas). A cada una de estas formas de particionamiento se la denomina,
respectivamente, particionamiento horizontal, particionamiento vertical y particionamiento mixto.
El particionamiento horizontal de relaciones consiste en la divisin de las tuplas de una relacin en
subconjuntos. Esto es muy til cuando existen consultas que acceden slo a determinada parte de la
informacin dependiendo del valor de algn atributo, o en bases de datos distribuidas, ya que cada
subconjunto puede ubicarse en distintos nodos de la red, acercndose al lugar de su tratamiento.
En el particionamiento vertical, los atributos de una relacin R son distribuidos en grupos no
solapados y la relacin R se proyecta en relaciones fragmentarias de acuerdo a estos grupos de
atributos. Estos fragmentos se colocan en diferentes localizaciones de la base de datos distribuida. Por
ello, el objetivo del particionamiento vertical es crear fragmentos verticales de una relacin de manera
que minimice el coste de acceso a los elementos de datos durante el procesamiento de la transaccin.
Si los fragmentos se ajustan bien a los requisitos del conjunto de transacciones facilitado, entonces el
coste de proceso de las transacciones podra ser minimizado. El particionamiento vertical tambin
puede usarse en la particin de tablas individuales en bases de datos centralizadas, y en la divisin de
datos entre diferentes niveles de jerarquas de memoria, etc. En el caso de bases de datos distribuidas,
el coste de proceso de transacciones se minimiza incrementando el proceso local de las transacciones
(en un "nodo") as como reduciendo el nmero de accesos a objetos de datos que no son locales.

21
Como su propio nombre indica, el particionamiento mixto engloba a ambos tipos de
particionamiento (horizontal y vertical). Consiste en aplicar un particionamiento vertical a uno o ms
de los fragmentos obtenidos mediante un particionamiento horizontal, o viceversa.
Diseo fsico
El objetivo del diseo fsico, que es la ltima fase del proceso de diseo, es conseguir una
instrumentacin lo ms eficiente posible del esquema lgico. Aqu se tienen en cuenta aspectos del
hardware, requisitos de procesos, caractersticas del SGBD, del SO y en general, cualquier factor
cercano a la "maquina". Con ello se persigue:
disminuir los tiempos de respuesta
minimizar espacio de almacenamiento
evitar las reorganizaciones
proporcionar la mxima seguridad
optimizar el consumo de recursos
El principal problema que se plantea en la fase de diseo fsico es el debido a la poca flexibilidad de
los actuales SGBD, los cuales obligan a trasladar a la fase de diseo lgico, aspectos de carcter fsico,
que deberan ser ajenos a dicha fase. Esto obliga a iterar desde la fase de diseo fsico a la de diseo
lgico, y viceversa, hasta obtener conseguir los objetivos anteriormente expuestos, lo que explica la
obligacin de la etapa de reestructuracin en el diseo lgico.
Como resultado del diseo fsico se genera un esquema fsico, que es una descripcin de la
implementacin de la base de datos en memoria secundaria; describe las estructuras de
almacenamiento y los mtodos de acceso para acceder a los datos de una manera eficiente. Por ello el
diseo fsico se genera para un SGBD y un entorno fsico determinado.
Diseo conceptual
Introduccin
Como ya se ha visto en el tema anterior, el diseo conceptual, que constituye la primera etapa en el
diseo de una base de datos, consiste en obtener una buena representacin de los recursos de
informacin de la empresa, con independencia de usuario o aplicaciones en particular y fuera de
consideraciones sobre eficiencia del ordenador. Puesto que no se corresponde con ningn nivel de la
arquitectura ANSI/X3/SPARC, sino que es un paso previo, tiende a ser no tenido en cuenta a la hora
de proceder al diseo de una base de datos. Esto no es aconsejable, ya que el diseo lgico parte del
esquema conceptual y, si ste no es correcto, o no representa fielmente la informacin del mundo real,
el esquema de la base de datos no ser estable, vindonos obligados a reajustarlo constantemente
debido a las deficiencias arrastradas desde esta etapa de diseo. De ah la importancia de realizar un
buen esquema conceptual, que represente fielmente las caractersticas del mundo real.
Otro error que se suele cometer en esta etapa de diseo es el de considerar aspectos tales como la
eficiencia del equipo hardware en el que se vaya a montar la base de datos, o SGBD's concretos. Como
ya se ha dicho, el esquema conceptual debe representar la informacin fuera de consideraciones sobre
hardware y sobre el SGBD sobre el que se implementar. Por lo tanto, se pueden establecer las
siguientes caractersticas que debe cumplir un buen esquema conceptual:
Debe representar fielmente la informacin del mundo real
Es independiente del SGBD
Es independiente del Hardware


24
Conviene no olvidar, por lo tanto, que un buen diseo del esquema conceptual, influir positivamente
en el resto de etapas.
Etapas del diseo conceptual
La fase de diseo conceptual, puede subdividirse a su vez en dos etapas:
1. Etapa de anlisis de requisitos: En esta etapa se debe responder a la pregunta "Qu
representar?". El objetivo es elaborar un esquema descriptivo de la realidad, en el que se
provean detalles de los datos a representar. Dicho esquema se obtiene mediante el estudio u
observacin del mundo real (estudio de las reglas de la empresa, entrevista a los usuarios,
etc.). Aunque existen muchas respuestas sobre el modo de recoger dicha informacin, la ms
utilizada es el lenguaje natural que, aunque carece del formalismo que pueden infligir
otros mtodos, permite una mejor y ms fcil comprensin de la informacin por parte del
usuario, y le permite especificar los requisitos sin la intervencin de formalismos. Este primer
esquema percibido bruto (como lo llaman Benci y Rolland), se ira refinando sucesivamente,
hasta llegar al esquema conceptual.
2. Etapa de conceptualizacin: En esta etapa se debe responder a la pregunta "Cmo
representar?". En ella se transforma el esquema obtenido en la primera, mediante
refinaciones sucesivas. Se deber obtener el esquema conceptual mediante una
representacin normalizada, que se apoye en un modelo de datos que cumpla determinadas
propiedades (segn Piattini y De Miguel): coherencia, plenitud, no redundancia, simplicidad,
fidelidad, etc. El modelo que se estudiar es el Modelo Entidad / relacin (en adelante referido
como ME/R o modelo E/R), que es el ms utilizado hoy en da.
El modelo entidad / relacin
El modelo E/R fue propuesto por Peter P. Chen en dos artculos que public en los aos 1976 y 1977.
En ellos define dicho modelo como una vista unificada de los datos, centrndose en la estructura
lgica y abstracta de los datos, como representacin del mundo real, con independencia de
consideraciones de tipo fsico. Posteriormente se fueron proponiendo nuevas aportaciones al modelo,
lo cual explica que no exista uno slo, sino distintos modelos segn los autores.
Los objetivos que debe cumplir un esquema conceptual son los siguientes (Piattini y De Miguel):
1. Captar y almacenar el universo del discurso mediante una descripcin rigurosa.
2. Aislar la representacin de la informacin de los requisitos de mquina y exigencias de cada
usuario en particular
3. Independizar la definicin de la informacin de los SGBD en concreto.
A continuacin se describir el proceso de creacin de un esquema conceptual, siguiendo el modelo
E/R. ste se basa en una representacin grfica de una serie de entidades relacionadas entre s. Al
utilizar una representacin de este tipo, el modelo E/R permite distinguir fcilmente y a simple vista,
las relaciones existentes entre las distintas entidades. Existen muchas formas de representarlo, como
ya se ha comentado; la que se utilizar aqu no es, por supuesto, la nica forma de hacerlo. Los
elementos de los que se componen son los siguientes:
Grupo EIDOS 3. Diseo conceptual

25
1. Entidades: Una entidad es "una persona, lugar, cosa, concepto o suceso, real o abstracto,
de inters para la empresa" (ANSI 1977). En el modelo E/R, se representa por un
rectngulo, con el nombre de dicha entidad escrito en la parte superior. Por ejemplo, la
Figura 8 representa la entidad automvil.

Figura 8

2. Atributos: Un atributo es cualquier caracterstica que describe a una entidad. Los atributos
de una entidad se colocan dentro del rectngulo que representa dicha entidad, justo debajo
del nombre de sta. Por ejemplo, se puede decir que un automvil tiene las siguientes
caractersticas: n de matricula, marca, modelo y color, lo cual se muestra en la Figura 9.

Figura 9

3. Clave: La clave de una entidad es un atributo o conjunto de atributos de dicha entidad, que
son capaces de identificar unvocamente una ocurrencia de una entidad. Es decir, si
conocemos el valor de dichos atributos, seremos capaces de conocer a que ocurrencia de
entidad, entre todas las posibles, hace referencia. Esto implica que los valores de los
atributos clave no se pueden repetir para dos ocurrencias de la misma entidad. En nuestro
ejemplo, seremos capaces de identificar de que automvil estamos hablando, con slo
conocer el valor del atributo matrcula, ya que no existe una misma matrcula para dos
automviles distintos. Los atributos marca, modelo o color no identifican unvocamente
una ocurrencia de la entidad, ya que pueden existir dos automviles distintos de la misma
marca, modelo o color. En el modelo E/R, un atributo clave se representa subrayando
dicho atributo.

Figura 10

4. Relacin: Una relacin representa, como su propio nombre indica, una correspondencia
entre dos entidades. Si tenemos dos entidades automvil y persona, podemos tener una
relacin entre ellas. Dicha relacin se puede establecer en ambos sentidos:
una persona posee un automvil, y
Un automvil pertenece a una persona.

26
5. Cardinalidad de una relacin: La cardinalidad de una relacin representa el nmero de
ocurrencias que se pueden dar de una relacin. Puede ser de tres tipos:
Cardinalidad 1-1: cada ocurrencia de una entidad se relaciona con una ocurrencia de
otra entidad. Ej.: una persona posee un automvil. Se representa como indica la Figura
11.

Figura 11

Cardinalidad 1-N: tambin llamada uno a muchos. Cada ocurrencia de una entidad
puede relacionarse con varias ocurrencias de otra entidad. Ej.: una persona posee
varios automviles. Se representa como muestra la Figura 12.

Figura 12

Cardinalidad N-M: tambin llamada muchos a muchos. Cada ocurrencia de una
entidad puede relacionarse con varias ocurrencias de otra entidad y viceversa. Ej.: una
persona posee varios automviles y un automvil puede pertenecer a varias personas.
Se representa como aparece en la Figura 13.

Figura 13

6. Cardinalidad mxima de una relacin: representa el nmero mximo de ocurrencias de
una entidad con las que se puede relacionarse otra entidad. Ej.: una persona puede tener
como mximo tres automviles.
7. Cardinalidad mnima de una relacin: representa el nmero mnimo de ocurrencias de una
entidad con las que se puede relacionarse otra entidad. Ej.: un automvil debe pertenecer
como mnimo a una persona.
8. Entidad dbil: se dice que una entidad es dbil, o es dependiente de otra, cuando no somos
capaces de conocer a que ocurrencia de entidad nos estamos refiriendo, ni siquiera
conociendo su clave, sino que debemos conocer el valor de algn otro atributo de otra

27
entidad. Por ejemplo, si tenemos las entidades edificio (con el atributo clave
codigo_edificio) y planta (con el atributo codigo_planta), sta ltima es una entidad dbil,
ya que no somos capaces de identificar una planta con slo conocer el cdigo de la planta,
sino que adems se necesita conocer el cdigo del edificio al que se hace referencia, para
determinar la planta dentro del edificio.

Figura 14

En general, en una relacin se suele representar conjuntamente las cardinalidades mxima y mnima.
En los anteriores casos no se han considerado las cardinalidades mnimas. stas vienen a representar la
opcionalidad de la ocurrencia de una entidad en una relacin, es decir, si dicha ocurrencia se debe dar
obligatoriamente, o si por el contrario se puede obviar. Los tipos de cardinalidades son los que
aparecen en la Figura 15, (nos fijaremos slo en un sentido de la relacin, el de la izquierda).

Cardinalidad mxima 1, cardinalidad mnima 1.
Cardinalidad mxima 1, cardinalidad mnima 1.
Cardinalidad mxima N, cardinalidad mnima 0.
Cardinalidad mxima N, cardinalidad mnima 1.
Figura 15

Veamos a continuacin unos ejemplos para comprender mejor las cardinalidades mxima y mnima.
Como se podr comprobar, las cardinalidades de una relacin se ponen en la ltima relacin a la que
se hace referencia, por ejemplo, si se tienen las entidades alumno y asignatura, la cardinalidad de la
relacin un alumno cursa asignaturas, se pondr al lado de la entidad asignatura.
En el siguiente ejemplo(Figura 16), se tiene una relacin 1-1 en la que un automvil pertenece a una
nica persona (cardinalidad mxima 1), sin la posibilidad de que exista un automvil que no tenga
dueo (cardinalidad mnima 1). Esto significa que en el modelo no interesa tener informacin de
aquellas personas que no tengan automvil.

Figura 16

En la Figura 17, se tiene una relacin 1-1 en la que una persona puede tener un automvil como
mucho (cardinalidad mxima 1), o puede no tener ninguno (cardinalidad mnima 0). Esto significa que
el modelo interesa tener informacin de todas las personas, aunque no tengan automvil.

28

Figura 17

En el siguiente ejemplo (Figura 18), se tiene una relacin 1-N, en la que un profesor puede dar clase a
muchos alumnos (cardinalidad mxima N), pero como mnimo debe hacerlo a uno (cardinalidad
mnima 1). Esto significa que en el modelo no interesa tener informacin de aquellos profesores que
no dan clase.

Figura 18

En el siguiente ejemplo, se tiene una relacin N-N, en la que una persona puede tener varios
automviles (cardinalidad mxima N), pero puede que no tenga ninguno (cardinalidad mnima 0). Esto
significa que en el modelo interesa tener informacin de todas las personas, aunque no tengan
automvil.

Figura 19

Para concluir esta seccin se ver un ejemplo completo que representar todos los conceptos vistos
hasta ahora. Supongamos que se desea establecer un modelo conceptual para la gestin de una
biblioteca. Se desean tener almacenados todos los libros que la componen.
Para cada libro interesa conocer el ISBN, el ttulo, el autor o autores, la editorial, el ao de publicacin
y la materia. De cada autor se quiere conocer su nombre, apellidos y nacionalidad.
Un autor podr haber escrito varios libros, de la misma forma que en un libro pueden participar varios
autores. De la editorial se desea conocer el nombre y la ciudad.
A dicha biblioteca podrn estar suscritos varios usuarios. De ellos se quiere saber su DNI, nmero de
socio, nombre, apellidos, direccin y telfono. Por cuestiones directivas, se limita el nmero de
ejemplares prestados a cada usuario a uno.
Se dispone, a su vez, de un nico ejemplar de cada libro, por lo que un libro prestado a un usuario, no
podr ser prestado a otro hasta que se devuelva. Deber quedar constancia de la fecha de prstamo de
cada ejemplar.


29

Figura 20

Lo ms destacable del anterior ejemplo es la entidad prstamo. Es una entidad dbil que depende de
libro y de socio, ya que para diferenciar un prstamo de otro, se necesita saber no slo el libro, sino el
socio al cual se ha prestado. Tambin se pueden observar que las cardinalidades mnimas son 1. Esto
quiere decir que slo se guardar informacin de las entidades cuando exista, al menos, una ocurrencia
de la entidad. Las nicas relaciones que tienen cardinalidad opcional, son las que tienen como origen o
destino a la entidad prstamo, lo cual es lgico, ya que tendremos informacin de todas las entidades,
aunque todava no se haya realizado ningn prstamo.
Ejemplos prcticos de diseo conceptual
A continuacin resolveremos unos problemas de diseo conceptual, para ir familiarizando al lector
con los conceptos vistos hasta ahora. Para realizarlos se utilizar la S-Designor, que es una
herramienta CASE que abarca gran parte del ciclo de vida de las aplicaciones, incluyendo el diseo de
esquemas conceptuales. No se preocupe si no conoce la herramienta, ya que se ver en detalle en
prximos temas, simplemente qudese con la idea general de la construccin del esquema.
El problema que nos planteamos es el siguiente. Supngase que se desea informatizar una tienda de
discos. Para ello se desean tener almacenados los nombres de todos los discos disponibles, adems de
sus cantantes y canciones. As mismo se desean almacenar los clientes que han comprado en dicha
tienda. Pues bien, empezaremos identificando las entidades, entendiendo por entidad un grupo de
caractersticas que tienen entidad propia. Como primera entidad, podemos establecer los discos que se
venden, ya que se desea conocer informacin de ellos, como puede ser un cdigo que lo identifique
dentro de la estantera. Por otro lado se desea almacenar todos los artistas que intervienen en los discos
de nuestra tienda, y para cada uno de ellos se desea conocer su nombre y apellidos, por lo tanto ya
tenemos identificada una segunda entidad. Adems, se desea conocer todas las canciones que estn
disponibles en los discos, identificada cada una de ellas por un cdigo de cancin, y que adems
tendrn sus propias letras. Pues ya tenemos la tercera entidad. La cuarta estar formada por los
clientes, de los cuales se desea almacenar su nombre, apellidos, direccin y telfono, y que podrn
estar identificados internamente por un cdigo de cliente.

Figura 21

30
Una vez establecidas las entidades, slo nos queda relacionarlas. Podemos observar las siguientes
relaciones:
1. Entre disco y cancin: en un disco pueden aparecer varias canciones, y cada cancin puede
estar en varios discos (N-M).
2. Entre cantante y cancin: un cantante puede componer varias canciones, y una cancin puede
estar compuesta por varios cantantes (N-M).
3. Entre cliente y disco: un cliente puede comprar varios discos, pero un disco slo puede ser
comprado por un cliente 1-N.
Por lo tanto, el esquema conceptual es que muestra la Figura 22

Figura 22

Vamos a plantearnos otro problema. Supongamos que se desea tener almacenados todos los datos de
los profesores de una empresa dedicada a impartir cursos, as como una breve descripcin de stos, y
los alumnos a los cuales se les ha impartido. Empezamos identificando entidades.
De un profesor se desea conocer su nombre y apellidos, direccin y despacho, por lo tanto establece
una entidad. Otra entidad podra ser el alumno, del cual se desea conocer su nombre, apellidos,
direccin y telfono.
Ni que decir tiene que el curso describe otra entidad, de la cual se desea conocer su descripcin. Sin
embargo, podemos recurrir a un procedimiento muy usual, denominado tipificacin de estados, muy
usado en el diseo conceptual, y que consiste en tener una entidad que tipifique los posibles estados
que puede tomar un atributo.
La principal ventaja de este procedimiento radica en que muchas veces supone un ahorro de espacio de
almacenamiento (por ejemplo al identificar nombres de ciudades largas con un solo nmero) adems
de una estandarizacin de los datos almacenados (el estado slo se almacena una vez).
Por ejemplo podemos tipificar las ciudades, para lo cual creamos una nueva entidad ciudad, donde se
almacenar un cdigo y la descripcin de la ciudad. Cuando almacenemos la ciudad de un alumno,
slo deberemos especificar el cdigo de la ciudad.


31

Figura 23

Una vez establecidas las entidades, vamos a definir las relaciones entre ellas.
1. Profesor y Curso: un profesor puede impartir varios cursos, pero un curso slo puede ser
impartido por un profesor (1-N).
2. Alumno y Curso: un alumno puede asistir a varios cursos, y a un curso pueden asistir varios
alumnos (N-M).
3. Alumno y Ciudad: un alumno vive en una ciudad, y una ciudad puede tener varios alumnos
(1-N).
Por lo tanto, el esquema conceptual es el mostrado en la Figura 24.

Figura 24

Cabe destacar que el atributo calificacin se da como consecuencia de la relacin entre las entidades
curso y alumno. Por lo que podr ser introducido en la entidad intermedia que surja cuando se haga el
paso a tablas (vase siguiente captulo).

32
Vamos a ver un ltimo ejemplo. Supngase un banco que desea almacenar todos sus clientes, adems
de los productos que puede ofrecer a stos. Cada cliente podr escoger entre todos estos productos el o
los que ms le plazcan (crditos, fondos de inversin, libretas de ahorro, etc.).
De la misma forma, dicho banco tiene intereses en otras empresas, por lo que desea conocer en todo
momento la situacin de dichas empresas, para poder mejorar su poltica de inversiones.
Puesto que dicho banco esta constituido como sociedad annima, desea almacenar todos los
componentes de su consejo de administracin (actuales y ex-miembros) as como todas las actas de las
reuniones ordinarias y extraordinarias.
Las decisiones de inversin en estas empresas saldrn como resultado de dichas reuniones, as como la
oferta de nuevos productos.
Como habr podido observar, este ejemplo es un poco ms complejo, pero no desespere, el proceso es
similar al de los dems ejemplos. Empezaremos definiendo entidades y las veremos representadas en
la Figura 25.
1. Cliente: se desea conocer su nombre, apellidos, direccin y NIF, y estar identificado por un
cdigo interno cod_cliente.
2. Producto: del cual queremos saber su descripcin y estar identificado por un cdigo interno
cod_producto.
3. Empresa: identifica las empresas en las cuales el banco ha invertido. De ellas se desea conocer
su cdigo, nombre y CIF.
4. Consejo: establece los componentes del consejo de administracin. Para ello se almacenar el
nombre, apellidos y cdigo de cargo de cada uno de sus componentes, y si el cargo es vigente
o no. Podremos utilizar una nueva entidad que tipifique los tipos de cargo.
5. Tipo_cargo: describe los posibles cargos que puede tomar una persona en el consejo de
administracin, y esta compuesto por un cdigo de tipo de cargo, y una descripcin del mismo
(secretario, presidente, etc.).
6. Reunin: entidad encargada de describir la informacin de las actas de las reuniones. Sus
atributos son cod_reunin, fecha, extraordinaria, que especifica si la reunin ha sido ordinaria
o extraordinaria y una descripcin.

Figura 25


33
Identifiquemos ahora las relaciones. Su representacin grfica aparece en la Figura 23.
1. Cliente y producto: cada cliente puede escoger varios productos, y cada producto puede ser
ofrecido a varios clientes.
2. Consejo y cargo: un miembro del consejo slo tiene un cargo, y cada cargo puede pertenecer a
ms de un miembro.
3. Reunin y consejo: a cada reunin pueden asistir varios miembros del consejo de
administracin, y cada miembro puede asistir a ms de una reunin.
4. Reunin y producto: de cada reunin puede salir la oferta de mas de un nuevo producto pero
cada producto nuevo slo puede salir de una reunin.
5. Reunin y empresa: de cada reunin pueden salir decisiones de invertir en ms de una
empresa, y cada decisin de inversin slo sale de una reunin.
Diseo lgico
Introduccin
Como ya se ha sealado, el diseo lgico de una base de datos consta de dos etapas: el diseo lgico
estndar y el diseo lgico especfico. En el diseo lgico estndar, se toma el esquema conceptual
resultante de la fase de diseo conceptual, y teniendo en cuenta los requisitos de proceso, de construye
un esquema lgico estndar (ELS), que se apoya en un modelo lgico estndar (MLS), que ser el
mismo modelo de datos soportado por el SGBD a utilizar (relacional, jerrquico, etc.), pero sin las
restricciones de ningn producto comercial en concreto. En nuestro caso se utilizar el MLS
relacional. Una buena forma de describir el ELS es utilizando el lenguaje estndar del MLS (por
ejemplo SQL).
Una vez obtenido el ELS, y considerando el modelo lgico especfico (MLE) propio del SGBD a usar
(ORACLE, INFORMIX, SQL-SERVER, etc.), se elabora el esquema lgico especfico (ELE). Al
igual que en el caso anterior, una buena forma de describirlo es utilizando el lenguaje de definicin de
datos (LDD) del producto especifico utilizado (en el caso de SQL-SERVER, se usar el TRANSACT
SQL). El diseo lgico especfico est muy ligado a la fase de diseo fsico, ya que ambos dependen
mucho del SGBD que se utilice.
En la fase de diseo lgico, adems de las herramientas ya descritas (MLS, MLE, lenguajes SQL), se
disponen de otras que permiten establecer un buen diseo lgico, como por ejemplo la normalizacin,
la desnormalizacin, etc., que ya se vern mas adelante en este tema.


36
Paso del esquema conceptual al esquema lgico estndar
Lo primero que hay que realizar en la fase de diseo lgico, es obtener el esquema lgico estndar, a
partir del esquema conceptual obtenido en la primera fase. Las reglas que permiten pasar del modelo
E/R al esquema lgico, son las que a continuacin se explican:
Cada entidad se transforma en una relacin: esto es, cada entidad genera una tabla, con sus
mismos atributos, incluyendo las claves.
Cada relacin N-M genera una tabla: las relaciones entre entidades con cardinalidad N-M
generan una tabla, con los atributos clave de ambas entidades.
Cada relacin 1-N importa las claves de la entidad con las que se relaciona: cada relacin con
cardinalidad 1-N importa los atributos clave que contiene la entidad con cardinalidad N.
Cada relacin dependiente, importa la clave de la otra entidad, como clave.
Para entender mejor el funcionamiento de este mtodo, veamos el paso a tablas del ejemplo visto en el
tema anterior acerca de la gestin de una biblioteca. La entidad libro est relacionada con la entidad
editorial con cardinalidad 1-N, por lo tanto importa la clave de la entidad con cardinalidad 1. A su vez,
esta relacionada con la entidad con la entidad autor, pero en este caso, la cardinalidad es N-M, lo que
implica que se generar una tabla intermedia, en la que se almacenarn las claves de ambas entidades.
Esta tabla, a la que denominaremos Libro_autor mantiene la informacin de los cdigos de libros junto
con los cdigos de autores. Posteriormente, si se desea extraer ms informacin, tanto del libro como
del autor, se deber acceder a sendas tablas. Por ltimo se dispone de la entidad Prstamo, que es
dependiente tanto de la entidad Libro como de la entidad Usuario, lo que quiere decir que se generar
una tabla, con los atributos de la entidad Prstamo adems de las claves de las entidades de las que es
dependiente, es decir, ISBN y Num_socio, que entrarn como claves en dicha tabla. Esta ltima
relacin obtenida, mantiene informacin de qu libros han sido prestados a qu usuarios y en qu
fecha. El esquema de las tablas resultantes es el que se muestra en la Figura 26

Figura 26

Veamos ahora el paso a tabla de otro ejemplo visto en el tema anterior, cuyo esquema conceptual es el
que muestra la Figura 27.
Empezaremos identificando las relaciones, y concretando las tablas que generarn:
1. Cliente-Disco: puesto que es una relacin 1-N, la entidad disco generar una tabla con sus
atributos, e importar el atributo clave de la entidad con cardinalidad 1, es decir, cod_cliente.
A su vez, la entidad cliente generar su propia tabla, con sus propios atributos, es decir,
cod_cliente, nombre, apellidos y telefono.
Grupo EIDOS 4. Diseo lgico

37
2. Disco-Cancin: es una relacin 1-N, a si que, siguiendo el mismo razonamiento anterior, la
tabla cancin generada importar el cod_disco de la entidad disco.
3. Cancin-Cantante: en este caso se tiene una relacin N-M, es decir, se generar una tabla
intermedia, con los atributos claves de las entidades que relaciona, es decir, cod_cancin y
cod_cantante.
4. Disco_Cantante: siguiendo el mismo razonamiento, al ser una relacin N-M, se generar una
tabla intermedia, con los atributos cod_cantante y cod_disco.

Figura 27

Con todo esto, el esquema lgico resultante del esquema conceptual anterior, queda como aparece en
la Figura 28.

Figura 28
Etapas en el diseo lgico
Como ya se ha comentado, la fase de diseo lgico de una base de datos consiste en dos etapas:
Etapa de estructuracin: donde el objetivo primordial es encontrar un esquema que sea una
representacin fidedigna del mundo real. La forma de lograrlo es mediante el particionamiento
horizontal, para evitar valores nulos, y el proceso de normalizacin.
Etapa de reestructuracin: donde se tienen en cuenta aspectos ms ligados con el nivel fsico,
y que consiste el modificar el esquema obtenido en la fase anterior para adaptarlo a las
consideraciones de eficiencia. Esta etapa, que debera ser ajena al diseo lgico, se considera
aqu debido a la falta de flexibilidad de los SGBD, obligando a trasladar a esta etapa aspectos

38
mas relacionados con el nivel fsico. La forma de lograrlo es mediante la desnormalizacin, y
el particionamiento, bien sea horizontal, vertical o mixto.
Comenzaremos por estudiar el particionamiento horizontal de relaciones, usado tanto en la etapa de
estructuracin como en la de reestructuracin, para dar paso posteriormente al proceso de
normalizacin, dejando para el final el particionamiento vertical, mixto y la desnormalizacin.
Particionamiento horizontal de relaciones
Como su propio nombre indica, el particionamiento horizontal consiste en dividir longitudinalmente
las filas que forman una tabla, esto es, separar las filas que conforman una relacin, para llevarlas a
otra. Para entenderlo mejor, supngase el siguiente ejemplo en el que se tiene la tabla publicacin, con
los siguientes campos: cod_publicacin, ttulo, autor, editorial.
En un momento dado, la informacin que tenemos en la tabla es la mostrada en la Tabla 1.

Cod_publicacin Ttulo Autor Editorial
123BB3-3 El Quijote
Miguel de
Cervantes
Ibrica
113ZD3-0
El impacto de las
TI
Francisco Hierves
2322-DD
Rimas y
Leyendas
G. A. Becquer Alcal
Tabla 1

Tenemos informacin sobre dos libros, con su autor y su editorial correspondiente, y un artculo (El
impacto de las TI) que, como es obvio, no tiene editorial. En este caso, podra ser conveniente "partir"
dicha tabla horizontalmente en otras dos, es decir llevar parte de la informacin a una tabla, y parte a
otra.
Aqu la diferenciacin se establece entre aquellas filas que tienen editorial, es decir, libros, y aquellas
que no tienen editorial, o artculos. Por lo tanto, se crean dos tablas: una para albergar los libros y otra
para ubicar los artculos.
La Tabla 2 posee la tabla de libros, mientras que la Tabla 3 contiene los artculos.

Cod_publicacin Ttulo Autor Editorial
123BB3-3 El Quijote Miguel de Cervantes Ibrica
2322-DD Rimas y Leyendas G. A. Becquer Alcal
Tabla 2


39
Cod_publicacin Ttulo Autor
113ZD3-0 El impacto de las TI Fco. Hierves
Tabla 3
Con esto, lo que hemos conseguido es eliminar la existencia de valores nulos no aplicables. Un valor
nulo es aquel que representa informacin desconocida, inexistente o no vlida (en nuestro caso el valor
del atributo editorial en el artculo). Los valores nulos pueden ser aplicables o no aplicables. Mientras
los no aplicables no cambian, es decir, permanecen nulos, los aplicables pueden dejar de serlo en
algn momento.
Esto que acabamos de realizar, es el primer paso que se debe seguir en el proceso de estructuracin de
relaciones. Sin embargo, el particionamiento horizontal no slo se utiliza aqu, sino que tambin puede
usarse en la fase de reestructuracin para conseguir una mayor eficiencia. Por ejemplo, si se dispone
de una base distribuida (para entendernos, una base de datos con distintos nodos, situados en distintas
localizaciones, con determinada informacin en cada uno) con informacin acerca de clientes, y
suponiendo que se dispone de dos nodos, uno en Madrid y otro en Barcelona, lo lgico sera pensar en
situar la informacin de aquellos clientes que residen en Barcelona en dicho nodo, y ubicar
nicamente la informacin de los clientes que viven en Madrid en dicho nodo. Los motivos son los
siguientes:
Si se sita toda la informacin en un nico nodo, el coste del acceso remoto aumenta (si toda
la informacin est en Madrid, una consulta de un cliente que vive en Barcelona se debera
realizar al nodo de Madrid, con el coste que ello supone).
Si se sita toda la informacin en ambos nodos, el coste de almacenamiento aumenta al tener
toda la informacin duplicada.
En este caso, pues, lo que se deber realizar en un particionamiento horizontal, para situar aquellas
filas que correspondan a clientes de Madrid, en el nodo de Madrid, y aquellas filas que correspondan a
clientes de Barcelona, en el nodo de Barcelona.
Supongamos, por ejemplo, que tenemos el siguiente esquema lgico, correspondiente a una base de
datos para gestionar los alumnos de una empresa de educacin a distancia.

Figura 29

Sobre el esquema de la Figura 29, nos podemos plantear varias cuestiones:
1. Se dispone de dos tablas, alumno y profesor. La tabla alumno guarda sus datos personales, y
las calificaciones obtenidas en cada una de las asignaturas, mientras que la tabla profesor

40
almacena, adems de sus datos personales, las aulas donde dicho profesor imparte cada una de
las clases.
2. La base de datos se encuentra distribuida, es decir, se dispone de un nodo en cada una de las
provincias, donde se almacena la informacin relevante a sta.
3. Los alumnos pueden optar por dos ramas, ciencias o letras, y para cada una de ellas se
imparten dos asignaturas, arte y latn en letras, y matemticas y ciencias en la rama de
ciencias.
Nos planteamos, entonces, aumentar la eficiencia de la base de datos, para adecuarla a las necesidades
de cada una de las provincias donde se encuentra ubicada la base de datos.
Puesto que en cada nodo slo precisa informacin relevante a ste, podemos optar por tres opciones:
Opcin 1: colocar la base de datos en un slo nodo (centralizado), al que accedern los dems.
Opcin 2: colocar la parte de informacin relevante a cada nodo en cada uno de ellos.
Opcin 3: colocar una copia de toda la base de datos en cada nodo.
En la Tabla 4 se analizan las ventajas e inconvenientes de cada una de la anteriores opciones.

Ventajas inconvenientes
Opcin 1
Se disminuye el espacio de
almacenamiento (una sola copia de la
informacin), y en la provincia donde se
encuentre la base de datos se disminuir
el tiempo de acceso
El resto de las provincias deber acceder a
la provincia donde se encuentre la base de
datos, con el trfico de red y aumento de
tiempo de acceso que esto supone.
Opcin 2
Cada provincia tendr la parte de
informacin que le interesa en su propio
nodo, lo que aumenta la eficiencia en las
consultas / actualizaciones, al evitar el
acceso por red a otras provincias.
Si se precisa acceder a otras provincias
distintas, se aumenta el tiempo de acceso
(trfico de red)
Opcin 3
Cada provincia tendr toda la
informacin de todas las provincias en su
propio nodo, disminuyendo el tiempo de
acceso.
Se aumenta el espacio de almacenamiento,
de forma directamente proporcional al
nmero de provincias.
Tabla 4

Analizando la anterior tabla, y teniendo la premisa expuesta de que cada provincia trabajar de manera
aislada, la opcin que ms nos interesa es ubicar cada parte de informacin relevante a cada una de
stas, en su nodo local. La pregunta que surge ahora es cmo se puede realizar?; pues bien, la
respuesta es bastante simple: mediante el particionamiento horizontal. Para ello se deben seguir los
siguientes pasos:
Paso 1: Realizar una consulta para separar las filas correspondientes a cada provincia, en cada una de
las tablas.

41
Paso 2: Ubicar la informacin obtenida en cada uno de los nodos correspondientes a dichas provincias.
Como ejemplo, supngase que se desean ubicar las filas de las tablas alumno y profesor en el nodo
provincial de Madrid. Para ello se realizar una "criba" en ambas tablas donde el campo provincia sea
Madrid. La sentencia SQL que realiza se ve en el Cdigo fuente 1.

SELECT * FROM alumno WHERE provincia = "Madrid"
SELECT * FROM profesor WHERE provincia = "Madrid"
Cdigo fuente 1

No se preocupe demasiado si no entiende las anteriores sentencias, ya que se vern en detalle ms
adelante. Qudese simplemente con la idea de su funcionamiento, que es el de obtener de ambas tablas
solamente aquellas filas que corresponden a la provincia de Madrid. De esta manera es preciso
proceder para el resto de las provincias.
Otra de las cuestiones que hemos planteado es la referente a las ramas por las que puede optar un
alumno: letras o ciencias. Podemos observar como en la tabla alumno, se encuentran atributos que
hacen referencia a las calificaciones obtenidas en ambas ramas, lo que supone que siempre se darn, al
menos, dos valores nulos inaplicables en cada fila de la tabla, ya que un alumno puede optar por una
de las dos ramas, pero no por ambas. Llegados a este punto, podremos decidir separar las filas de
dicha tabla entre otras dos, denominadas alumno_ciencias y alumno_letras, cada una de ellas
almacenando los atributos correspondientes a cada una de estas ramas, respectivamente. De esta
manera, en la tabla alumno_letras, estaran solamente las filas o tuplas correspondientes a alumnos que
han escogido la rama de letras, y en la tabla alumno_ciencias, aquellos que han optado por la rama de
ciencias. La forma de proceder es, nuevamente, mediante un particionamiento horizontal, con el
objetivo de eliminar estos valores nulos no aplicables. Las tablas quedaran entonces como muestra la
Figura 30.

Figura 30
Particionamiento vertical de relaciones
El particionamiento vertical de relaciones consiste, al contrario que en el caso del particionamiento
horizontal, en dividir las tablas de forma transversal, es decir, crear nuevas tablas con la informacin
correspondiente a un subconjunto de los atributos de las mismas, pero manteniendo intacta la
informacin correspondiente a las filas. Veamos un ejemplo para comprenderlo mejor. Supngase que
tenemos la tabla reparto con la informacin de todos los repartos realizados por los proveedores a los
clientes. La informacin que tenemos de dicha tabla (Tabla 5) es: cod_proveedor, cod_cliente,
cod_material, nombre_proveedor, nombre_cliente, ciudad_proveedor, ciudad_cliente y cantidad.


42
cod_
proveedor
cod_
cliente
cod_
material
nombre_
proveedor
nombre_
cliente
ciudad_
proveedor
ciudad_
cliente
cantidad
123 113 112 Pepe Juan Sevilla Sevilla 10
128 114 118 Luis Paco Madrid Cuenca 29
837 998 128 Antonio ngel Barcelona Manresa 12
Tabla 5

Dada la Tabla 5, podra interesarnos tener varias tablas: una que contenga la informacin del
proveedor, con los atributos nombre_proveedor y ciudad proveedor, otra con la informacin del
cliente con los atributos nombre_cliente y ciudad_cliente y otra con la informacin de los repartos con
los atributos cod_proveedor, cod_cliente, cod_material y cantidad. Para ello realizamos un
particionamiento vertical, sobre estos atributos.

nombre_proveedor ciudad_proveedor
Pepe Sevilla
Luis Madrid
Antonio Barcelona
Tabla 6

nombre_cliente ciudad_cliente
Juan Sevilla
Paco Cuenca
ngel Manresa
Tabla 7

cod_proveedor cod_cliente cod_material cantidad
123 113 112 10
128 114 118 29
837 998 128 12
Tabla 8


43
El resultado es que tenemos el mismo nmero de filas en todas las tablas, pero ms tablas con menos
atributos. Este proceso se realiza en la reestructuracin, ya que las ventajas que ofrece estn
relacionadas con la eficiencia. Entre ellas destacan:
Aumento de la concurrencia: cada vez que un usuario accede a una fila de la tabla, sta se
bloquea, es decir, no puede ser accedida por otro usuario. Al dividir un tabla en ms, la
concurrencia aumenta, es decir, si un usuario accede a una fila de una tabla, otro podr acceder
a la misma fila en otra tabla.
Aumento de la velocidad de consulta / actualizacin: al ser las tablas ms pequeas, una
consulta o actualizacin podr realizarse en un menor tiempo, ya que se necesitarn menos
accesos a disco para completar la accin.
Disminucin de tiempos de consulta de informacin irrelevante: si se quiere consultar un solo
atributo de una tabla, se deber acceder a toda la fila, con lo que ello supone. En cambio, al
reducir el tamao de las filas, la informacin a la que accedemos tendr ms probabilidad de
ser utilizada.
Por contra, la principal desventaja que tiene este mtodo es el aumento del tiempo de consulta /
actualizacin si se desea acceder a dos o ms tablas. Es por ello por lo que hay que realizar un estudio
pormenorizado de la probabilidad de consultas que se va a realizar. Para ello existen varios algoritmos,
por ejemplo el de Navathe y Ra, en los que no entraremos, ya que escapan del objetivo del presente
curso.
Por ejemplo, supngase que se dispone un esquema lgico con una sola tabla, en la que se almacenan
los datos personales de los empleados de una empresa.

Figura 30

Si nos damos cuenta, existen muchos atributos, a los que deberemos acceder en cada consulta, aunque
no nos interese su valor. Esto es debido a que, normalmente, el acceso (o bloqueo de tupla) se realiza
al nivel de fila o tupla, es decir, se accede a toda la fila de la tabla. Puede que esto no nos sea til, por
ejemplo, sin nicamente deseamos obtener el sueldo de un empleado, ya que deberemos obtener toda
la fila correspondiente a ese empleado, para extraer un solo atributo con todos los inconvenientes que
esto supone, como por ejemplo una disminucin de la concurrencia (otro usuario no podr acceder
simultneamente a esa fila, ni siquiera para consultar el valor de otro atributo), un aumento del tiempo
de proceso (debemos procesar toda la fila para extraer un solo atributo), un mayor consumo de
memoria (por el mismo motivo), un aumento del nmero de operaciones de Entrada / salida (puede
que la fila entera no quepa en el buffer de memoria, y debamos realizar ms accesos a la base de
datos), etc.
Nos plantemos entonces un particionamiento vertical. Puesto que la nica transaccin (consulta) que
se va a realizar (de momento) es la consulta del sueldo de un empleado, se puede separar esta tabla en

44
otras dos: una con el atributo sueldo, y otra con el resto. De esta manera solventamos los anteriores
inconvenientes que se presentaban.
Para identificar unvocamente cada una de estas filas, y asociarlas a las filas de la tabla homloga, se
pueden usar dos mtodos:
1- Utilizar un identificador de fila, igual para cada fila en ambas tablas, o
2- Utilizar un atributo clave, similar para filas iguales en ambas tablas.
En esta caso optamos por la segunda opcin, utilizando el DNI, como campo unin entre ambas tablas,
quedando el esquema lgico particionado verticalmente de la como indica la Figura 31.

Figura 31

Sin embargo, que pasara si ahora se necesita saber no slo el sueldo, sino tambin la categora de un
empleado?. Pues bien, el esquema obtenido no nos valdra (bueno, de hecho si valdra, pero no sera
demasiado eficiente), ya que ahora se necesitara realizar una operacin de join o unin entre ambas
tablas, para obtener ambos valores. Destacar que la operacin de join es bastante costosa en tiempo de
ejecucin. La solucin, en este caso, pasara por aadir el campo categora a la tabla anteriormente
extrada.

Figura 32
Particionamiento mixto
El particionamiento mixto consiste en un hbrido entre ambos tipos de particionamiento. O bien se
aplica un particionamiento vertical a una tabla previamente particionada horizontalmente, o bien se
aplica un particionamiento horizontal a una tabla particionada verticalmente. Por lo tanto, existen dos
opciones:
Realizar primero un particionamiento horizontal, por ejemplo para ubicar las distintas filas de
una tabla en distintos nodos de una base distribuida (como el ejemplo visto anteriormente), y

45
posteriormente realizar un particionamiento vertical sobre las tablas obtenidas, para conseguir
un mayor ajuste de los tiempos de acceso a datos (evitar acceder a datos irrelevantes).
Realizar primero un particionamiento vertical, para conseguir disminuir los tiempos de acceso
y posteriormente realizar un particionamiento horizontal sobre dichas tablas.
El particionamiento mixto se usa en la etapa de reestructuracin, ya que se tiene en cuenta aspectos
relacionados con el nivel fsico (eficiencia). La forma de representar el particionamiento mixto se
denomina rbol de particionamiento, e indica los distintos tipos de particionamiento por los que va
atravesando una determinada relacin. La Figura 33 nos muestra como la relacin original R se ha
particionado de forma horizontal en otras dos R2 y R1, y a su vez, sta ltima, se ha particionado
verticalmente en otras dos R3 y R4.

Figura 33
Teora de la normalizacin
El proceso de normalizacin consiste en la aplicacin de un conjunto de reglas, con el objeto de
verificar que el esquema relacional obtenido en esta fase cumple un cierto conjunto de reglas. La
normalizacin se podra considerar prcticamente como el grueso de la fase de diseo lgico, ya que
es el encargado de modificar el esquema conceptual obtenido en la fase anterior, para que cumpla el
primero de los objetivos de las bases de datos, el de que ha de representar fielmente la realidad. Por lo
tanto es el segundo paso a realizar dentro de la fase de diseo lgico, despus de la eliminacin de
valores nulos no aplicables (particionamiento horizontal), y se corresponde con la etapa de
estructuracin.
La normalizacin se puede definir como el proceso de sustituir una relacin o tabla, por un conjunto
de esquemas equivalentes que representen la misma informacin, pero que no presenten cierto tipo de
anomalas a la hora de realizar operaciones sobre ella. Las anomalas que puede presentar una relacin
son de tres tipos:
Anomalas de insercin: son producidas por la prdida de informacin, al no poder insertar
filas en una relacin, ya que no se conoce el valor de algn atributo no principal (que no es
clave). Por ejemplo, supngase que se dispone de la siguiente relacin, correspondiente a los
repartos realizados por distintos proveedores.

Cod_proveedor Cod_material Ciudad Categora Cantidad
1 A234 Madrid 2 122
1 B298 Madrid 2 100

46
2 G344 Sevilla 3 200
3 F893 Valencia 1 400
Tabla 9

Si en este momento se desea aadir un nuevo proveedor, no se puede reflejar en la relacin, ya que
dicho proveedor todava no ha realizado ningn reparto.
Anomalas de borrado: vienen determinadas por la perdida de informacin que no se desea, al
eliminar una fila de una relacin. Por ejemplo, supngase el caso anterior. Si se desea borrar el
reparto realizado por el proveedor 3, al existir nicamente una fila con dicho proveedor,
perderemos toda la informacin relacionada con l, es decir, su ciudad y su categora.
Anomalas de modificacin o actualizacin: vienen impuestas por la necesidad de propagar
actualizaciones, es decir, se debe modificar el mismo atributo en ms de un sitio. Son debidas
a un diseo redundante. Sigamos con el ejemplo anterior. Si se desea modificar la ciudad de
un proveedor, no bastar con hacerlo en un sitio, sino que se debern recorrer todas las filas
correspondientes a todos los repartos de dicho proveedor, y modificar el valor de atributo
ciudad en todas ellas. Evidentemente esto es muy peligroso, ya que si nos olvidamos de
actualizar dicho valor en una fila, la base de datos quedar inconsistente, es decir, existirn
dos valores distintos de ciudad para un mismo proveedor, y eso sin contar el tiempo que se
pierde en realizar dicha actualizacin. Por estos motivos, se pueden establecer dos
conclusiones: el diseo es redundante y el esquema no est normalizado.
Por lo tanto, lo que se busca con el proceso de normalizacin es eliminar estos tres tipos de anomalas.
Consiste en conseguir, mediante varios pasos, distintas formas normales. Se dice que un esquema de
relacin esta en una determinada forma normal si satisface un determinado conjunto de restricciones.
Dichas formas normales son la primera forma normal (1FN), la segunda forma normal (2FN) y la
tercera (3FN), definidas por Codd, la forma normal de Boyce-Codd (FNBC), definida por Boyce y
Codd, y la cuarta y quinta forma normal (4FN y 5FN), definidas por Fagin. La principal caracterstica
que cumple cada una de estas formas normales es que la de nivel superior incluye a la de nivel
inferior, es decir, una relacin que est en 2FN estar en 1FN, una que este en 3FN estar en 1FN y
2FN, como muestra la Figura 34.

Figura 34

Una esquema relacional estar normalizado cuando est, al menos, en 3FN.

47
Para comprender mejor el proceso de normalizacin y la obtencin de las formas normales, veamos el
concepto de dependencia funcional. Sea el esquema de relacin R definido sobre el conjunto de
atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende
funcionalmente de X, o que X determina o implica a Y si, y slo si, cada valor de X tiene asociado en
todo momento un nico valor de Y, y se representa X ---> Y.
Por ejemplo, si se tiene la relacin Empleado, compuesta por los atributos DNI, nombre, salario, etc.,
se puede asegurar que DNI ---> Nombre , ya que por cada DNI tenemos un nombre, es decir, para un
mismo DNI no pueden existir ms de un nombre.
De la misma forma, se puede concluir que entre Salario y Nombre no existe dependencia funcional, ya
que para un mismo salario pueden existir varios nombres de empleados, (varios empleados pueden
cobrar lo mismo).
La dependencia funcional plena o completa es un caso particular de dependencia funcional. Sea X un
descriptor compuesto por X1 y X2 (X1 y X2 atributos de X), se dice que Y tiene dependencia
funcional plena o completa de X si depende funcionalmente de X pero no depende de ningn
subconjunto del mismo, veamos la Tabla 10.

X -------> Y (Y depende funcionalmente de X)
X1 --/--> Y (Y no depende funcionalmente de X1)
X2 --/--> Y (Y no depende funcionalmente de X2)
Tabla 10

Por ejemplo, si se tiene la relacin Libro con los atributos ISBN, Cod_socio y Fecha_prstamo, se
tiene:

ISBN, Cod_socio ------------> Fecha_prstamo (1)
ISBN ----/------> Fecha_prstamo (2)
Cod_socio -----/---------> Fecha_prstamo (3)
Tabla 11

ya que para un libro y un socio slo existe una fecha de prstamo (1), mientras que el mismo libro se
puede prestar varios das (2) y un mismo socio puede tomar prestado uno o varios libros ms de un da
(3). Por estos motivos, se puede concluir que Fecha_prstamo tiene dependencia funcional completa
de ISBN y socio.
Otro caso particular de dependencia funcional es el de dependencia funcional transitiva. Sea la
relacin R compuesta por los atributos X, Y, Z, en la que se tiene:
X --------> Y
Y --------> Z
Y ----/---> X


48
se dice, entonces, que Z tiene una dependencia transitiva respecto de X a travs de Y, y se representa
X ---- ----> Z.

Por ejemplo, si se tiene la relacin Empleado, con los atributos Nombre, Direccin y Cod_postal, se
tiene:
Nombre ----------> Direccin (1)
Direccin --------> Cod_postal (2)
Direccin ---/----> Nombre (3)

cada empleado slo tiene una direccin (1), y cada direccin slo tiene un cdigo postal (2), mientras
que varios empleados pueden vivir en una misma direccin (3). Por lo tanto Nombre --- --->
Cod_postal.
Veamos a continuacin las distintas formas normales.
Primera forma normal (1FN): Una relacin est en 1FN si cada atributo de dicha relacin, tiene un
slo valor en cada fila. La siguiente relacin, por ejemplo, no est en 1FN, ya que la primera fila tiene
dos valores para el atributo asignatura.

Cod_alumno Nombre Asignatura
10 L. Fernndez Matemticas
Lenguaje
20 P. Alonso Ciencias
Tabla 12

La forma de transformar esta relacin a otra que sea 1FN sin prdida de informacin, es crear una fila
por cada valor del atributo repetido, de la forma que indica la Tabla 13.

Cod_alumno Nombre Asignatura
10 L. Fernndez Matemticas
10 L. Fernndez Lenguaje
20 P. Alonso Ciencias
Tabla 13

Segunda forma normal (2FN): Una relacin est en 2FN cuando, adems de estar en 1FN, todos los
atributos que no forman parte de ninguna clave candidata suministran informacin acerca de la clave
completa, no de una parte de la clave. O lo que es lo mismo, cada atributo no principal (que no forma
parte de la clave) tiene dependencia funcional completa respecto de cada una de las claves. Por
ejemplo, si se tiene la relacin Libro con los atributos ISBN, Cod_socio y Editorial, de los cuales los
atributos clave son ISBN y Cod_socio, y se tiene la dependencia funcional que sigue:

49
ISBN ---------------> Editorial (1)

dicha relacin no esta en 2FN, ya que el atributo no principal editorial, depende funcionalmente de una
parte de la clave, no de toda ella. Para transformarla a otro esquema equivalente, que est en 2FN, se
descompone dicha relacin en otras dos:
R1 = {ISBN, Cod_socio}
R2 = {ISBN, Editorial}

Este es un esquema equivalente al anterior, es decir, representa la misma informacin, pero
cumpliendo la segunda forma normal, ya que ahora la dependencia (1) es completa. Ntese que la
relacin original se ha descompuesto en otras dos, para satisfacer este requisito.
Tercera forma normal (3FN): Una relacin esta en 3FN cuando, adems de estar en 2FN, no existe
ningn atributo no principal que dependa transitivamente de alguna de las claves de la relacin. Por
ejemplo, si tenemos la relacin Empleado, con los atributos Nombre, Direccin y Cod_postal, cuya
clave es el atributo nombre, con las siguientes dependencias funcionales:
Nombre ----------> Direccin (1)
Direccin --------> Cod_postal (2)

dicha relacin no se encuentra en 3FN, al tener que el atributo no principal cod_postal depende
transitivamente de la clave nombre. Para transformarla a 3FN, se descompone dicha relacin en otras
dos equivalentes, que cumplan la tercera forma normal:
R1 = {Nombre, Direccin}
R2 = {Direccin, Cod_postal}

Ahora las nuevas dependencias que tenemos son (1) en R1 y (2) en R2, por lo que se ha eliminado la
transitividad, es decir, dicho esquema se encuentra en 3FN.
Las formas normales que se vern ahora no son muy utilizadas, ya que supone que el esquema este
muy fuertemente normalizado, cosa que puede no interesar en la mayora de los casos, as que
simplemente se mencionarn.
Se dice que una relacin esta en forma normal de Boyce-Codd cuando se tiene que para toda
dependencia funcional se tiene que el implicante (la parte derecha de la dependencia) es clave. La
cuarta y quinta forma normal dependen de un tipo especial de dependencias, denominadas
multivaluadas y de unin respectivamente.
Ejemplos prcticos de normalizacin
Para comprender mejor el proceso ms importante en la fase de diseo lgico de una base de datos,
veremos algn ejemplo sobre cmo normalizar un esquema lgico dado. Por ejemplo, supongamos
que tenemos la instancia que aparece en la Tabla 14 de un esquema lgico, ya visto anteriormente,
referente a los repartos realizados por varios proveedores en una empresa.

Cod_proveedor Cod_material Ciudad Categora Cantidad
1 A234 Madrid 2 122
1 B298 Madrid 2 100

50
2 A234 Sevilla 3 200
3 F893 Valencia 1 400
Tabla 14

Lo primero que cabe preguntarse es est normalizado?. La respuesta es no, ya que se producen
anomalas:
Insercin: no podemos almacenar un proveedor, hasta que no haya realizado algn reparto.
Borrado: si borramos el reparto del proveedor 3, perdemos la informacin referente a dicho
proveedor.
Actualizacin: si actualizamos la ciudad del proveedor 1, debemos propagar esta modificacin
a dos filas, con la posibilidad de la consiguiente inconsistencia del esquema.
En la Tabla 15 iremos modificando el anterior esquema, hasta lograr que este normalizado, con el
objeto de eliminar las anteriores anomalas. Lo primero es identificar las dependencias del esquema:

cod_proveedor ciudad
Para cada valor del atributo cod_proveedor, tenemos un nico valor
del atributo ciudad, como podemos comprobar en las dos primeras
filas, en las que el valor 1 para el cdigo del proveedor implica la
ciudad Madrid, o para las dos siguientes en que el valor 2 para el
atributo cod_proveedor implica la ciudad Sevilla. Es decir,
conociendo el valor del cdigo del proveedor, estamos en
disposicin de asegurar la ciudad del mismo.
ciudad categora
El atributo ciudad implica el atributo categora. Para cada valor del
atributo ciudad, tenemos un valor distinto del atributo categora.
Conociendo la ciudad, conocemos la categora
cod_proveedor, cod_material
cantidad
Para cada valor distinto del conjunto de atributos cod_proveedor y
cod_material, tenemos un valor distinto para el atributo cantidad.
Conociendo el cdigo del proveedor y del material, podemos saber
la cantidad abastecida.
Tabla 15

Lo siguiente es encontrar una clave para la tabla, es decir, un atributo o conjunto de atributos que
identifiquen unvocamente cada tupla de la relacin. En nuestro caso, estara formada por los atributos
cod_proveedor y cod_material, ya que la combinacin de estos valores no se repiten para ms de una
fila en la tabla.
1FN: el esquema est en 1FN, ya que en cada fila tenemos un nico valor para cada atributo.
Un esquema lgico, normalmente, est por defecto en 1FN, al menos.
2FN: el esquema no est en 2FN, ya que, aunque est en 1FN, nos encontramos con la
siguiente dependencia:

51
cod_proveedor --------> ciudad

Puesto que la clave de la relacin esta formada por los atributos cod_proveedor y
cod_material, tenemos que hay un atributo no principal (ciudad), que depende funcionalmente
de una parte de la clave (cod_proveedor), no de toda ella. Por lo tanto, deberemos
descomponer dicha relacin en otras dos, de tal forma que el atributo ciudad dependa de toda
la clave.
Una posible forma, puede ser llevar el atributo ciudad junto con la parte de clave de la que
depende (cod_proveedor) a otra relacin, junto con las dependencias funcionales que le
afectan. Otra forma de proceder es dejar en una relacin aquellos atributos que forman parte
de la dependencia, y llevar los dems a otra relacin. Por lo tanto, nos quedan las relaciones
que muestra la Tabla 16.

Atributos Dependencias Clave
Relacin 1
cod_proveedor,
cod_maerial
cantidad
Cod_proveedor,cod_material
cantidad
cod_proveedor,cod_material
Relacin 2
Cod_proveedor
ciudad
categora
ciudad categora
cod_proveedor
Tabla 16

De esta manera, ahora la dependencia anterior ya es completa con respecto la clave, ya que en
la segunda relacin la clave es ahora cod_proveedor, por lo que el atributo ciudad depende de
toda la clave.
3FN: Hasta aqu el esquema est en 1FN y 2FN, pero no en 3FN, ya que el atributo categora
en la relacin 2 depende transitivamente de la clave de dicha relacin, que es cod_proveedor,
es decir,
ciudad categora

Como cod_proveedor no depende funcionalmente de ciudad, ya que en una ciudad puede
haber varios proveedores, esto es, para cada valor de ciudad, puede haber distintos valores de
cod_proveedor:
ciudad --/ cod_proveedor

tenemos que categora depende transitivamente de la clave cod_proveedor:
cod_proveedor categora

Por lo tanto deberemos descomponer la relacin 2 en otras dos, de manera tal que se evite la
dependencia funcional transitiva entre ambos atributos.
Esto se puede conseguir llevndonos cada dependencia a una relacin distinta.


52
Relacin 1
cod_proveedor
cod_material
cantidad
cod_proveedor,cod_material
cantidad
cod_proveedor
Relacin 2
Cod_proveedor
ciudad
cod_proveedor ciudad cod_material
Relacin 3
ciudad
categora
Ciudad categora Ciudad
Tabla 17

De esta manera se ha eliminado la dependencia transitiva, ya que al existir una sola
dependencia, es imposible que esta dependa de otra.
Por lo tanto hemos conseguido obtener un esquema normalizado en 3FN, mediante la descomposicin
de una relacin inicial en otras tres. De este modo hemos conseguido eliminar las dependencias que se
nos planteaban en la relacin original:
Insercin: si queremos insertar un nuevo proveedor, no hace falta que haga ningn reparto, ya
que bastar con insertarlo en la relacin 2.
Borrado: si borramos un reparto, no perdemos la informacin referente al proveedor, ya que
sta se almacena en la relacin 2
Actualizacin: si cambiamos la categora de una ciudad, no hace falta cambiarla en todas las
filas, sino slo una vez en la relacin 3.
Veamos ahora otro ejemplo de normalizacin. Supongamos esta vez que tenemos el esquema lgico
de la Tabla 18, que representa los cursos impartidos por un profesor, junto con su fecha, y domicilio
de ste.

Profesor Fecha Curso Precio Domicilio
Cod_post
al
Juan 01/02/99 Windows 95 10.000 C/ Alcala, 389 28027
Pedro 03/02/99 Visual Basic 20.000 C/Caimn, 28 28190
Juan 03/02/99 Windows 95 10.000 C/Alcala, 389 28027
Luis 01/02/99 Delphi 25.000 C/Remanso,34 28007
Pedro 03/03/99 Windows 98 15.000 C/Caimn, 28 28190
Tabla 18

Este esquema no est normalizado, ya que se producen las siguientes anomalas:
Insercin: No podemos insertar los datos de un profesor hasta que ste no haya impartido un
curso.

53
Borrado: Si borramos la imparticin del curso de Delphi, perdemos los datos de dicho curso, y
del profesor que lo imparte.
Actualizacin: Si modificamos la direccin del profesor Juan, debemos hacerlo en dos filas y
si modificamos el precio de un curso o el cdigo postal de un domicilio, tambin.
Procedemos de igual forma que en el ejemplo anterior. Lo primero es identificar la clave, que en
nuestro caso est compuesta por los atributos profesor, fecha y curso, ya que el conjunto de estos tres
atributos, identifica de manera unvoca cada fila de la relacin. El siguiente paso es identificar las
dependencias funcionales.

Curso precio
Para cada valor diferente del atributo curso, podemos existe un valor
diferente para el atributo precio, es decir, el atributo curso identifica el
atributo precio.
Profesor domicilio
Cada profesor vive en su domicilio. El atributo profesor identifica
unvocamente el atributo domicilio.
Domicilio cod_postal
El atributo domicilio identifica el atributo cod_postal, cada domicilio
tiene un cdigo postal.
Tabla 19

Ahora debemos comprobar si dicha relacin cumple las reglas de cada una de las formas normales:
1FN: Puesto que para cada fila existe un solo valor para cada atributo, la relacin se encuentra
en 1FN.
2FN: Dicha relacin no se encuentra en 2FN, ya que tenemos la siguiente dependencia:
curso -----> precio

es decir, el atributo precio no tiene dependencia funcional completa con respecto a la clave,
sino slo a una parte. Por lo tanto, desglosamos esta relacin en otras dos, dejando en una
dicha dependencia junto con sus atributos, y en la otra las dems.

Relacin 1
Profesor
Fecha
Curso
Domicilio
Cod_postal
Profesor domicilio
domicilio cod_postal
Profesor, fecha,
curso
Relacin 2
Curso
Precio
Curso precio curso
Tabla 20

Ya hemos eliminado la dependencia no completa de la clave para la anterior dependencia
funcional. Pero todava tenemos un atributo que depende de parte de la clave en la
relacin 1:

54
profesor domicilio

Por lo tanto, desglosamos la relacin 1 en otras dos, una que contenga los atributos
referentes a dicha dependencia y otra con los dems.

Relacin 1
Profesor
Domicilio
Cod_postal
profesor domicilio
profesor
Relacin 2
Curso
Precio
curso precio curso
Relacin 3
Profesor
Fecha
Curso

Profesor, fecha
curso
Tabla 21

Esta relacin ya se encuentra en 2FN, ya que, adems de estar en 1FN, no tiene dependencias
no completas de ningn atributo no principal con respecto de la clave.
3FN: El anterior esquema no se encuentra en 3FN, ya que la relacin 1 tiene una dependencia
transitiva con respecto de la clave:
profesor domicilio

Como domicilio no depende de profesor, ya que en un mismo domicilio pueden vivir varios
profesores, tenemos una dependencia transitiva del atributo cod_postal con respecto de la
clave:
profesor cod_postal

Por lo tanto, para romper esta dependencia, podemos llevar cada una de ellas a una nueva
relacin, con lo que nos queda lo que indica la Tabla 22.
Ahora podemos asegurar que el esquema se encuentra normalizado hasta la tercera forma
normal.

Relacin 1
Profesor
Domicilio
profesor domicilio profesor
Relacin 2
Curso
Precio
curso precio curso

55
Relacin 3
Profesor
Fecha
Curso

Profesor,
fecha curso
Relacin 4
Domicilio
Cod_postal
Domicilio cod_postal domicilio

Tabla 22

Lo que hemos conseguido es sustituir un esquema en el que slo exista una relacin, en otro con
cuatro, que mantiene la misma informacin, pero que no presenta las anomalas que se daban en el
original:
Insercin: si queremos dar de alta un nuevo curso lo haremos en la relacin 2 y si queremos
insertar un nuevo profesor, lo haremos en la relacin 1.
Borrado: si borramos la imparticin de un curso, no perdemos la informacin de dicho curso,
o del profesor que lo imparte.
Actualizacin: si cambiamos el precio de un curso, o el domicilio de un profesor, slo se har
una vez, en la relacin correspondiente.
Un ltimo detalle a tener en cuenta es el de la descomposicin sin perdida de dependencias, esto es,
que no se queden dependencias en el camino, para que el esquema original y el normalizado tengan la
misma informacin.
Proceso de desnormalizacin
El proceso de desnormalizacin hace referencia justo al proceso inverso de normalizacin que se
acaba de ver. En estos momentos, el lector puede preguntarse que para qu se procede a normalizar un
esquema, cuando posteriormente se va a desnormalizar, es decir, a dejarlo como estaba. La respuesta
es simple; primero se procede a estructurar el esquema, y una parte de esta estructuracin es la
normalizacin de relaciones. Posteriormente, y debido a aspectos de eficiencia, se puede proceder a
realizar una reestructuracin del esquema, parte de la cual supone la desnormalizacin del mismo.
Esto supone que puede que el esquema resultante de la normalizacin sea lo suficientemente eficiente
como para que no sea preciso reestructurarlo, o que simplemente no nos interese que el esquema sea
eficiente. Adems, puede que normalicemos hasta un cierto nivel, y que solo interese desnormalizar
hasta otro determinado nivel. En definitiva, el proceso de desnormalizacin supone la unin de varias
relaciones en un nmero menor de ellas, es decir, a medida que disminuya el nivel de normalizacin,
es frecuente que el nmero de relaciones disminuya.
Destacar, por ltimo, que interesa tener un nivel fuerte de normalizacin cuando el nmero de
actualizaciones sea alto con relacin al de consultas, ya que se evitarn las anomalas expuestas. Sin
embargo, si el nmero de consultas es alto con relacin al de actualizaciones, interesar que el nivel de
normalizacin sea bajo, ya que el diseo ser redundante, lo cual implica que se tardar menos en
buscar la informacin. Como norma general, se procurar que el esquema est siempre normalizado al
nivel de 3FN.
Por ejemplo, supngase el ejemplo de los cursos visto en el apartado anterior. Si tenemos que no se
van a realizar prcticamente actualizaciones, si no que se van a realizar consultas sobre los atributos
profesor, domicilio y cod_postal, nos encontramos que para realizarla necesitamos acceder a dos

56
tablas (relacin 1 y relacin 4), es decir, se deber realizar un join, con el aumento de tiempo de
proceso que ello supone. Por lo tanto, puede interesar en este caso desnormalizar dicho esquema un
nivel, hasta 2FN, donde para acceder a dicha informacin, simplemente se precisa consultar la relacin
1.

Relacin 1
Profesor
Domicilio
Cod_postal
profesor domicilio
profesor
Relacin 2
Curso
Precio
curso precio curso
Relacin 3
Profesor
Fecha
Curso

Profesor, fecha
curso

Tabla 23
Diseo fsico
Introduccin
El diseo fsico busca conseguir una instrumentacin lo ms eficiente posible del esquema lgico,
considerando los aspectos ms cercanos al hardware, es decir, los requisitos de procesos,
caractersticas del SGBD, del Sistema Operativo y del hardware, pretendiendo los siguientes objetivos:
Disminuir los tiempos de respuesta
Minimizar espacio de almacenamiento
Evitar las reorganizaciones
Proporcionar la mxima seguridad
Optimizar el consumo de recursos
Como ya se ha comentado, debido a la falta de flexibilidad de los actuales SGBD, es preciso llevar a
cabo a cabo en muchas ocasiones un proceso de reestructuracin de relaciones para conseguir una
mayor eficiencia, lo que significa que se debe iterar desde el diseo lgico especfico al fsico y
viceversa, hasta obtener un esquema aceptable, que optimice el ratio coste / beneficios.
El diseo fsico es fuertemente dependiente del producto comercial que se vaya a usar, debido a la
carencia de un modelo formal, equivalente al relacional que permita una definicin formal de esa fase
de diseo. Sin embargo, existen caractersticas que son comunes a la mayora de los productos, y que
pueden ser utilizadas para definir un esquema fsico.


58
Se podra considerar el diseo fsico como una caja negra, en la que se toman como entradas los
recursos de la mquina, los recursos lgicos (SO, etc.), el esquema lgico obtenido en la fase anterior,
informacin sobre las aplicaciones que se ejecutarn en la mquina as como los objetivos que se
plantean en esta fase, y se obtienen como salidas una estructura interna, que representa la
implementacin del esquema lgico en un hardware especfico, junto con unas normas de seguridad y
unas especificaciones para el ajuste, es decir, la forma de iterar entre la etapa de diseo lgico
especfico y la fase de diseo fsico.
Estrategias en el diseo fsico
Existen tres tipos de estrategias que los fabricantes de SGBD imponen en sus productos comerciales:
1. Inflexibilidad. El SGBD impone una estructura interna, impidiendo y dejando al administrador
pocas opciones de cambiarlo. La principal ventaja de esta estrategia es la independencia fsico
/ lgica del esquema, aunque por contra, el esquema interno resultar ms ineficiente.
2. Flexibilidad. Es el contrapunto al anterior caso. Implica que el administrador de la base de
datos pueda disear la estructura interna, lo cual supone un aumento de la eficiencia, aunque
tambin de la dependencia fsico / lgica.
3. Hbrido entre ambos. El SGBD proporciona una estructura interna opcional que el diseador
puede cambiar con el fin de mejorar la eficiencia. Entre las ventajas que supone utilizar esta
tcnica estriba la de que la BD puede empezar a funcionar de inmediato al disponer del
esquema interno opcional, con la posibilidad de ir mejorando sucesivamente la eficiencia al ir
realizando ajustes, a la par que se mantiene la independencia. Destacar que esta es la estrategia
ms utilizada en los actuales SGBD.
Conceptos bsicos sobre gestin de ficheros
La unidad bsica de las estructuras fsicas (ficheros) es el registro fsico, tambin denominado pgina
o bloque, que es la unidad mnima que puede tratarse en una operacin de Entrada / salida. Las tuplas
(en el caso del modelo relacional) se almacenan en dichos registros, pudiendo almacenar cada uno de
stos varias de aquellas. De aqu podemos definir el factor de bloqueo para un fichero como el nmero
de registros lgicos (o tuplas) por bloque para dicho fichero. Del mismo modo, si los datos son muy
grandes, un registro lgico puede estar almacenado en varios registros fsicos. El tamao de los
bloques depende del producto comercial y del sistema operativo, oscilando ste entre 2 y 4 Kbytes.
Los bloques, que se encuentran almacenados en los sectores del disco, deben ser accedidos por el
SGBD utilizando los mecanismos de gestin de ficheros que provee el sistema operativo. El tiempo en
acceder a un sector del disco, que es bastante elevado, est compuesto por varios factores:
Tiempo de arranque: tiempo que tarda el disco en empezar a mover las cabezas.
Tiempo de seek: tiempo necesario para mover las cabezas al cilindro (conjunto de pistas del
mismo dimetro) requerido.
Tiempo de latencia: tiempo que debe esperar hasta que el sector para por debajo de las
cabezas.
Tiempo de transferencia: tiempo necesario para transferir la informacin, por el bus de datos,
a memoria principal.
Grupo EIDOS 5. Diseo fsico

59
Para acelerar este proceso, se suele usar un dispositivo de almacenamiento intermedio, denominado
cach o buffer, cuyo cometido es el de almacenar los datos ms usados, aprovechando de este modo
la ley de proximidad temporal, es decir, los datos que han sido usados ms recientemente, tienen una
alta probabilidad de que sean usados en un futuro cercano, evitando de este modo accesos extra a
disco. Este dispositivo es gestionado por el sistema operativo, utilizando diversas polticas, entre la
que la ms usada es la LRU (Least Recently Used), es decir, los bloques que se han usado hace ms
tiempo, son candidatos a desalojar la cach para albergar otros bloques. Otra poltica es aprovechar la
ley de proximidad referencial, es decir, los datos prximos tienen mayor probabilidad de ser
referenciados.
Algunos SGBD permiten especificar las caractersticas de los registros fsicos. Se pueden agrupar
determinado nmero de bloques contiguos en unidades llamadas extensiones. Los parmetros que se
pueden especificar son:
El porcentaje de espacio libre que se deja en cada bloque para albergar posteriores
actualizaciones de los registros lgicos. Al modificar un valor de un atributo, puede que ste
no quepa en el espacio reservado. De esta forma se evita la concatenacin de bloques, que
incide en un menor tiempo de respuesta.
Nmero de bloques que se asignan a las extensiones.
Porcentaje de utilizacin de cada bloque.
Organizacin de ficheros
Existen varias formas de organizar los ficheros, de forma que el acceso a los mismos se realice de una
y otra forma:
Secuencial: El mtodo de acceso es secuencial, es decir, un registro detrs de otro. Es
conveniente usar esta forma de organizacin cuando existe una carga masiva de datos, las
tablas son pequeas o cuando se accede a casi todas las filas, es decir, un ndice (ya se ver
ms adelante lo que es) estorbara, ya que de todas maneras se necesita acceder a todas las
filas.
Hash: Es una forma de organizar los ficheros teniendo como base una tabla indexada que
apunta a la informacin. Es til cuando las filas se recuperan por el valor de la clave, que en
este caso acta como funcin para determinar la posicin donde se encuentra la informacin.
ISAM: Es una opcin ms amplia que la anterior, ya que soporta bsquedas por valores de
clave, adems de por parte de ella o usando patrones de bsqueda.
rbol B+: Es una estructura que soporta bsquedas dicotmicas (el nmero de bsquedas es
menor que log2 n). La ventaja con respecto al caso anterior es que crece de forma dinmica.
Tcnicas para el aumento de eficiencia
Existen varias tcnicas para aumentar la eficiencia del esquema:
ndices: Se puede definir un ndice como una estructura que sirve para mejorar la eficiencia de
las consultas a una base de datos. Un ndice se define sobre uno o varios atributos. A la hora
de acceder a dichos atributos, el tiempo de acceso ser instantneo. Un ndice se puede

60
comparar con el ndice de un libro; si disponemos de dicho ndice, podemos acceder a la
pgina del libro de forma inmediata, mientras que si no lo tenemos, deberemos ir mirando
hoja por hoja hasta encontrar la pgina deseada. Por ejemplo, supngase que tenemos la
relacin que muestra la Tabla 24.

Cod_jugador Nombre Apellido Equipo
10 Adrin Illie Valencia
20 Fernando Redondo R. Madrid
25 Jos Guardiola Barcelona
30 Claudio Lpez Valencia
49 Fernando Hierro R. Madrid
80 Rafael Alkorta At. Bilbao
90 Rafael M. Vzquez Deportivo
Tabla 24

Si en este momento se desea hacer una consulta sobre todos los jugadores que se llamen
Fernando, se deber acceder a todas las filas, encontrndose dos jugadores que cumplen este
requisito, es decir, se han realizado siete accesos. Sin embargo, si se dispone de un ndice por
el atributo Nombre, los accesos seran inmediatos a las dos nicas filas que cumplen este
requisito, reducindose en este caso el nmero de accesos a dos. Si ahora se desea buscar
todas las filas con el nombre de Rafael, y que pertenezcan al Deportivo, se realizaran siete
accesos (toda la tabla). Si tuvisemos un ndice por el atributo Nombre, se encontrara una
nica fila, pero se debera acceder a dos, es decir, las filas cuyo nombre es Rafael. Sin
embargo si tuvisemos un ndice combinado para los atributos Nombre y Equipo, solo se
realizara un acceso, la de nombre Rafael y equipo Deportivo.
Ya se ha visto entonces la ventaja de usar este tipo de estructuras para acceder rpidamente a
la informacin. Sin embargo no todo son ventajas, ya que cuanto mayor sea esta estructura,
mayor espacio de almacenamiento ser necesario, sin contar el tiempo que se pierde en
actualizar el ndice cuando se modifica algn valor de los atributos que forman parte de l. Por
este motivo, se suele indexar la clave primaria (mediante un ndice nico, es decir, que no
permita valores repetidos), o aquellos atributos que no vayan a ser modificados. La siguiente
lista resume una serie de consejos a la hora de indexar campos:
Indexar la clave primaria con un ndice nico
Indexar las claves ajenas, es decir los atributos de una tabla que son clave que otras tablas
Indexar aquellos atributos que se van a consultar con ms frecuencia, y que no van a ser
alterados
No indexar tablas pequeas
No indexar tablas que se van a recorrer secuencialmente
Grupo EIDOS 5. Diseo fsico

61
No indexar atributos de tipo carcter muy largos
Agrupamiento o "clustering": Se entiende por "clustering" de tablas la agrupacin de tablas
cuyas filas comparten un grupo de atributos llamado clave de agrupamiento. Esta tcnica
supone una desnormalizacin fsica de las tablas, que se encuentran fsicamente agrupadas,
pero que lgicamente siguen siendo dos tablas independientes, por lo que el agrupamiento ser
transparente al usuario. La Figura 35 muestra un agrupamiento de dos relaciones Empleado y
Departamento.

Figura 35

Con este mtodo se consigue mejorar la eficiencia en la consulta simultanea de ambas tablas, pero
empeora cuando se recorren de forma separada.
Compresin de datos: Por un lado, la compresin de datos permite reducir el espacio
requerido para almacenar la informacin, lo que radica en un menor nmero de operaciones de
Entrada / salida. Sin embargo, se requiere un mayor tiempo de proceso debido a la necesidad
de descomprimir los datos que se recuperan.
La tcnica de compresin ms utilizada es la de compresin diferencial, que consiste en
almacenar la diferencia entre el valor de un atributo y el que le precede.
Redundancia de datos: La redundancia de datos consiste en duplicar el valor de ciertos
atributos de una tabla en otra, con el fin de evitar accesos a tablas consultadas frecuentemente.
Sin embargo, esta redundancia debe ser controlada, es decir, se debe garantizar la consistencia
de la base de datos. La forma ms segura de controlarlo es mediante disparadores o triggers,
que cambien el valor de todos los atributos duplicados, cuando cambia uno de stos.
Introduccin a SQL Server
Qu es SQL Server?
SQL Server es un Sistema de Gestin de Bases de Datos Relacionales (SGBDR), desarrollado por
Microsoft, que permite, como su propio nombre indica, la gestin de un entorno de bases de datos
relacional. SQL Server abarca, tanto el rea de diseo, como la de administracin, proporcionando un
interfaz bastante amigable con el usuario.
Por qu se llama SQL Server?. Pues bien, se llama SQL porque utiliza este lenguaje para la
definicin y manejo de los datos, y se llama Server porque dispone de una parte servidora que se
encarga de atender a los procesos clientes, que son los que realizan las peticiones a ste; es decir, sigue
una arquitectura cliente/servidor.
SQL Server utiliza una extensin al SQL estndar, que se denomina Transact SQL. Esto quiere decir
que soporta el SQL de ANSI, pero adems se le han aadido ciertas funciones adicionales, no
contempladas en el estndar, y que son especficas para este producto, es decir, si ejecutamos una
sentencia del conjunto adicional (Transact SQL) en otro SGBRD, ste no la entendera.
El Transact SQL, soporta la definicin, modificacin y eliminacin de bases de datos, tablas, atributos,
ndices, etc., es decir, el lenguaje de definicin de datos (DDL), as como la consulta, actualizacin y
borrado de tuplas de tablas, es decir, el lenguaje de manipulacin de datos (DML).


64
Orgenes
Como podemos comprobar, el mercado de la informtica ha ido cambiando sorprendentemente desde
hace unos pocos aos. Cuando surgi aquella maquina que hoy denominamos PC, nadie poda
imaginar que iba a desbancar de su puesto a las grandes plataformas como el Sistema 36 de IBM o el
VAX de Digital.
Por aquel entonces, principios de los ochenta, empezaban a implantarse las bases de datos
relacionales, sobre todo con ORACLE, pero ni por asomo podan ser utilizadas en los PCs. ORACLE
fue el nombre que se le dio a un proyecto, destinado a investigar el modelo relacional, por aquel
entonces algo utpico. Sin embargo, ante la falta de resultados positivos, se decidi cancelar el
proyecto, y venderlo a Relational Software Inc. (RSI). En 1979, RSI lanz al mercado la versin 2 de
ORACLE, que fue la primera base de datos relacional en utilizar el lenguaje SQL. Fue un poco ms
tarde cuando RSI decidi cambiar su nombre por el de su producto estrella, ORACLE. Sin embargo, la
aparicin de dBase, de Ashton-Tate, supuso una revolucin en el mundo de las bases de datos para PC,
originando una batalla para ganar posiciones en este mercado.
En el ao 1988, ante el boom del PC, Ashton-Tate, IBM, Microsoft y Sybase, deciden aliarse para
sacar un nuevo producto al mercado: una base de datos relacional, para PC. Este hecho supuso el
nacimiento de SQL-Server. A su vez, IBM y Microsoft se comprometieron a desarrollar un nuevo
entorno, dirigido a las bases de datos, capaz de soportar SQL-Server, y le dieron el nombre de OS/2.
A su vez, SQL Server fue avanzando, adaptndose a las nuevas tendencias del mercado. Fue entonces
cuando la aparicin de Windows NT reemplaz a OS/2 como soporte para SQL Server. Desde
entonces y hasta hoy, los SGBD relacionales ms vendidos resultan ser ORACLE y SQL Server.
SQL Server e Internet
El impacto que, sobre todo durante estos ltimos aos, ha venido sufriendo el uso de Internet, obliga a
pensar si SQL Server puede ser til para manejar y/o obtener datos de la red de redes. La verdad es
que las interfaces de acceso a bases de datos, tambin han ido experimentado un largo y constante
cambio, a la vez que han ido apareciendo otros nuevos, con el fin de adecuarse a las necesidades
cambiantes del mercado.
El interfaz de acceso a bases de datos por excelencia, ha sido siempre ODBC, que significa Open
Database Connection (Conexin abierta a Bases de Datos), y que supone la abstraccin por parte del
usuario que quiere acceder a la base de datos, que no tiene por qu saber las caractersticas de sta.
ODBC ofrece una serie de mtodos encapsulados, los cuales hacen todo el trabajo de traduccin.
La aparicin de Internet, supuso el nacimiento de un nuevo interfaz, adecuado al lenguaje Java,
llamado JDBC. Su cometido es el mismo que ODBC, pero en este caso se ofrecen una serie de
funcionalidades especiales para adaptarlo al lenguaje Java.
Sin embargo, otra forma de acceder a una base de datos desde Internet es la ofrecida por un producto
llamado Microsoft Internet Information Server (IIS). La combinacin de ste con SQL Server, ofrece
una potente forma de unir SQL e Internet. Mediante esta forma, se pueden mostrar datos en un
navegador de Internet, obtenidos de una base de datos SQL, por ejemplo.
Lo nuevo en SQL-Server 2000
Introduccin
Como decamos, SQL-Server ha ido evolucionando a lo largo de los ltimos aos. La apuesta de
Microsoft por este SGBD ha sido (y es) bastante fuerte, lo cual ha hecho posible la mejora y
adaptacin del mismo, sobre todo al entorno remoto y distribuido. La Figura 36 muestra la
arquitectura general de este SGBD.
Veremos en este captulo las mejoras que ha sufrido esta nueva versin, con respecto a las anteriores,
mejoras que pasamos a detallar a continuacin.
Nuevas caractersticas
Entre las nuevas caractersticas que ofrece SQL-Server 2000, cabe destacar las siguientes:
Soporte para XML.
Particionamiento horizontal de relaciones y gestin de vistas distribuidas.
Soporte para Virtual Interface Architecture (VIA).
Funciones de usuario.
Indexacin de vistas.


66
Nuevos tipos de datos.
Nuevos triggers.
Reglas de integridad referencial en cascada.
Nuevas caractersticas de indexacin.
Soporte para consultas distribuidas.
Caractersticas de seguridad y cifrado de datos.

Figura 36
Soporte para XML
El Extensible Markup Language, ms conocido como XML es un metalenguaje, es decir, un lenguaje
utilizado para definir lenguajes, y que se usa sobre todo para el intercambio de datos.
Su sintaxis es similar a la que nos ofrece el HTML, es decir, un conjunto de etiquetas que definen la
estructura de los datos. El Cdigo fuente 2 define un posible formato de intercambio.
<cliente>
<nombre>Pepe</nombre>
<apellidos>Lopez</apellidos>
<telefono>912345678</telefono>
</cliente>
Cdigo fuente 2
Grupo EIDOS 7. Lo nuevo de SQL - Server 2000

67
SQL-Server 2000 ofrece la posibilidad de devolver un conjunto de resultados utilizando para ello este
tipo de formato, facilitando as el intercambio de datos.
Particionamiento horizontal de relaciones y gestin de
vistas distribuidas
Otra de la caractersticas nuevas que nos ofrece SQL-Server 2000 es la posibilidad de particionar
horizontalmente los datos de una relacin. Ya se ha comentado lo til que es este tipo de
reestructuracin de relaciones, sobre todo en el ambiente distribuido, en el cual se pueden colocar las
tuplas en los servidores que se supongan ms posibilidades tengan de consultarlas en forma local.
Del mismo modo, se pueden definir vistas distribuidas que accedan a estos datos, en cada uno de los
servidores que nos interese, de manera que la ejecucin de la misma d la impresin de estar
interactuando sobre un conjunto completo de resultados.
Soporte para Virtual Interface Architecture (VIA)
SQL-Server 2000 introduce nuevas libreras de red, que permiten definir un entorno distribuido de
forma eficiente, posibilitando una gran conectividad, tanto de servidores como de aplicaciones, en este
tipo de entornos.
Funciones de usuario
Una funcionalidad nueva que aparece en esta versin del SGBD es la de permitir al usuario definir sus
propias funciones. De esta forma se pueden definir funciones que oculten parte de la complejidad que
puede entraar una consulta, no slo para la posterior reutilizacin de la misma, sino tambin teniendo
en cuenta la abstraccin para otros programadores que puedan precisar su uso.
Indexacin de vistas
Esta funcionalidad permite optimizar la ejecucin de vistas que actan sobre la base de datos, creando
ndices sobre los resultados de ejecucin de la misma, que son almacenados en la base de datos. El
usuario no debe preocuparse de la actualizacin de los datos, sino que stos son indexados
automticamente cada vez que se actualicen.
Nuevos tipos de datos
SQL-Server 2000 soporta tres nuevos tipos de datos con respecto a la anterior versin, la 7, que son el
bigint o entero de 8 bytes, sql_variant, que soporta el almacenamiento de valores de distintos tipos, y
table, que permite el almacenamiento temporal de resultados para su uso posterior.

68
Nuevos triggers
Un trigger o desencadenador es un cdigo especial que se ejecuta cuando se cumple una determinada
condicin, como por ejemplo al modificar o borrar datos (se ver en detalle en un captulo posterior).
SQL-Server 2000 soporta dos nuevos tipos de triggers, que son INSTEAD OF y que sustituye el
comportamiento de ciertos comandos, como por ejemplo insert, update o delete, y AFTER, que se
ejecuta una vez concluida la accin que lo ha desencadenado.
Reglas de integridad referencial en cascada
Las reglas de integridad referencial son la base del mantenimiento de la consistencia en la base de
datos, y hacen referencia a informacin que esta relacionada entre si, como por ejemplo el
departamento de un empleado cuyo cdigo se especifica. La forma ms usual de mantenerlo es usando
claves forneas, y especificando el comportamiento de las inserciones, borrados y actualizaciones de
este tipo de datos.
Nuevas caractersticas de indexacin
Las nuevas caractersticas de indexacin permiten crear ndices sobre campos calculados (no existen
como tal en la base de datos, sino que se calculan a partir de otros valores), as como especificar si se
desea construir estos ndices de manera paralela, lo que aumenta la velocidad de procesado.
Soporte para consultas distribuidas
El optimizador de consultas ofrece la funcionalidad de ubicar datos en servidores distribuidos,
dependiendo de valores tales como el nivel de carga, el trfico de red, etc., de manera que las consultas
pueden acceder a distintos servidores para obtener el resultado final.
Caractersticas de seguridad y cifrado de datos
SQL-Server 2000 utiliza Kerberos como servidor de autenticacin, para acreditar el acceso al servidor
que se realiza desde el cliente, as como diversas tcnicas de seguridad.
Instalacin de SQL Server 2000
En este captulo, veremos como instalar SQL Server 2000, y las distintas opciones que plantea. Para
empezar, introduzca el CD-ROM que contiene el programa. Si no arranca automticamente, utilice el
explorador para ejecutar el fichero autorun contenido en el CD-ROM. Tenemos dos opciones, la
standard o la personal. La primera de ellas realiza una instalacin completa, incluyendo los
componentes servidor, mientras que la segunda es til en el caso de que no dispongamos de un
servidor. La primera pantalla que aparece es la que se muestra en la Figura 37.

Figura 37


70
En nuestro caso instalaremos la opcin standard (si no disponemos de un servidor, nicamente se
instalarn los componentes cliente).
En principio, el nico requisito que se necesita es disponer de un equipo con al menos 64 Mb de
memoria RAM (recomendable 128 Mb) y sistema operativo Windows 98/NT/2000, en el cual se haya
instalado la versin 5.5 del navegador WEB Microsoft Internet Explorer.
Para proseguir la instalacin, pulsamos la opcin SQL Server 2000 Components, aparecindonos la
pantalla que muestra la Figura 38.

Figura 38

Pulsamos el botn Next, visualizndose la pantalla que se muestra en la Figura 39.

Figura 39
Grupo EIDOS 8. Instalacin de SQL - Server 2000

71
En este caso, puesto que queremos instalar los componentes cliente en nuestro equipo local, slo nos
permite la seleccin de esta opcin. Si pulsamos el botn Next, visualizaremos la siguiente pantalla
que muestra la Figura 40

Figura 40

Nuevamente, al estar instalando la versin standard en un equipo con Windows 98, slo se nos
permite seleccionar la opcin de crear una nueva instancia de SQL Server. Pulsando el botn Next,
obtendremos la pantalla que se muestra en la Figura 41, donde se nos insta a poner nuestro
nombre y compaa.

Figura 41


72
Si pulsamos nuevamente el botn Next, podremos visualizar la pantalla que se muestra en la Figura 42,
cuyo cometido es el de mostrarnos las condiciones de uso de la licencia; pulsamos Yes para pasar a la
siguiente pantalla que se indica en la Figura 43.

Figura 42

Figura 43

Seleccionando la opcin de instalacin de las herramientas cliente y pulsando el botn Next,
accederemos a la pantalla de la Figura 44, en la que podemos seleccionar los componentes y
subcomponentes a instalar.

Grupo EIDOS 8. Instalacin de SQL - Server 2000

73

Figura 44

Dejamos marcados los que vienen por defecto y pulsamos el botn Next, para acceder a la pgina de la
Figura 45, tras la cual el sistema empezar a instalar los componentes seleccionados y, tras unos
minutos, mostrar la pantalla final en la cual se nos informa de la conclusin del proceso de
instalacin, como muestra la Figura 46.

Figura 45


74

Figura 46
El modelo E/R en SQL-SERVER 2000
Introduccin
SQL-Server nos ofrece una herramienta para realizar diseos relacionales, pero no a nivel conceptual,
sino a nivel lgico, es decir, tal y como se plasmaran las relaciones en tablas, pudiendo adems
especificar cuestiones como la integridad referencial, las restricciones, etc.
Para acceder a esta herramienta, deberemos acceder a la opcin del Administrador corporativo o
Enterprise manager.
Una vez dentro, daremos de alta el registro de servidor (si no se encuentra ya hecho), y accederemos a
la opcin Diagramas (Diagrams) de la base de datos deseada dentro del grupo Bases de datos
(Databases), como muestra la Figura 47.
En la parte derecha podremos observar como aparecen todos los diagramas disponibles para la base de
datos seleccionada.
Para acceder a uno de ellos, bastar con hacer doble click con el ratn sobre el, mientras que para crear
uno nuevo, seleccionaremos la opcin New Database Diagram del men contextual que aparece al
hacer click con el botn derecho del ratn sobre esta pantalla, como muestra la Figura 48.


76

Figura 47

Figura 48
Grupo EIDOS 9. El modelo E/R en Sql-Server 2000

77
Crear un nuevo diagrama
Vamos a crear ahora un nuevo diagrama, para lo cual actuamos como se acaba de comentar. Nos
aparecer entonces una ventana, como la de la Figura 49, que no es ms que la primera pgina de un
asistente que nos guiar durante el resto del proceso de creacin del diagrama. Pulsamos el botn
Siguiente para avanzar al siguiente paso, que se muestra en la Figura 50.

Figura 49

Figura 50

78
En la parte izquierda nos aparecen todas las tablas disponibles, mientras que en la derecha tenemos las
tablas que nosotros seleccionaremos para pasar a formar parte de nuestro diagrama. La forma de
aadir una tabla al diagrama es seleccionndola y pulsando el botn Add, mientras que para eliminarla
del mismo, como el lector ya habr podido adivinar, habremos de pulsar el botn Remove.
La caja de seleccin que aparece en la parte inferior bajo el nombre Add related tables automatically
permite aadir todas las tablas relacionadas con las seleccionadas de manera automtica, pudiendo
adems especificar el nmero de niveles que se incluirn, es decir, tablas relacionadas de tablas
relacionadas. Esta opcin es muy til para chequear restricciones de una tabla que no sabemos con
cuales se relaciona.
Una vez seleccionadas todas la tablas que deseamos pasen a formar parte del diagrama (en nuestro
caso escogemos las tablas authors, titleauthor y titles), pulsamos el botn Siguiente para avanzar al
prximo paso, que se muestra en la Figura 51.

Figura 51

Este es el ltimo paso, en el que se nos muestran las tablas que hemos seleccionado. Pulsamos el botn
Finalizar, y ya tenemos nuestro diagrama, que tendr un aspecto similar al mostrado en la Figura 52.
En el podemos observar las tablas que hemos seleccionado, junto con el nombre de sus atributos, las
claves (que aparecen con un icono en forma de llave), y las relaciones entre ellas. Estas relaciones
muestran las dependencias existentes entre ellas.
Vamos a guardar nuestro diagrama, para trabajar posteriormente con el, pulsando el icono en forma de
disco de la barra de herramientas, y dndole un nombre coherente.

79

Figura 52
Restricciones e integridad referencial
Una de las principales utilidades que nos ofrece esta herramienta es la de establecer las restricciones y
las reglas de integridad referencial de una manera fcil y visual.
Para visualizar este tipo de caractersticas, pulsamos con el botn derecho del ratn en la opcin
Propiedades (Properties) del men contextual, dentro de la tabla o relacin deseada, aparecindonos
una pantalla similar a la de la Figura 53.
Dentro de la pestaa Relationship se pueden especificar restricciones y caractersticas tales como la
integridad referencial. Para ello debemos indicar el atributo que acta como clave primaria dentro de
la tabla origen, y el atributo que acta como clave ajena dentro de la tabla destino y le damos un
nombre a dicha restriccin.
Sin embargo, para establecer este tipo de reglas, existe otra manera mucho ms cmoda, que es
seleccionar con el ratn el atributo que es clave ajena dentro de una tabla y, sin soltarlo, arrastrarlo
hasta la tabla que contiene la clave primaria con la cual se relaciona.
En la pestaa Indexes/Keys es donde se especifican aspectos referentes a los ndices que van a hacer
referencia a los atributos de la tabla, y cuyo aspecto es el mostrado en la Figura 54.

80

Figura 53

Figura 54

81
En esta pantalla podemos crear o borrar ndices, definidos sobre uno o varios atributos, de tipo
ascendente o descendente (se refiere a la ordenacin). El ndice primario har referencia a la clave
primaria de la relacin, aunque tambin podemos especificar otro tipo de ndices, como de tipo nico,
cluster, etc.
Dentro de la pestaa Check Constraints podemos indicar las restricciones sobre los atributos de la
tabla. Por ejemplo, en la Figura 55 se especifica una restriccin sobre el atributo clave de la tabla,
especificando mediante una expresin regular que dicho atributo deber ser rellenado con 9 dgitos, y
que se aplicar en las replicaciones, inserciones y actualizaciones.

Figura 55
Modificacin del esquema
Aparte de definir restricciones, la herramienta de diagramas tambin nos da la posibilidad de realizar
modificaciones del esquema, esto es, aadir o borrar tablas o atributos del diagrama (existentes o
nuevas), cambiar el tipo o el nombre de los mismos, crear nuevas relaciones, etc.
Para ello, nuevamente habr que escoger la opcin correspondiente haciendo click con el botn
derecho del ratn, como muestra la Figura 56.


82

Figura 56

Otra de las formas de modificar, por ejemplo, el nombre de un atributo, es pulsando sobre el y
escribiendo directamente el nuevo sobre la tabla, o cambiar el tipo haciendo click derecho en el
atributo y escogiendo la opcin de propiedades, y escoger la pestaa Columns.
Crear una nueva relacin
Una vez vistos los principales conceptos en la creacin de diagramas, vamos ahora a crear una nueva
relacin con una tabla existente, para practicar lo aprendido hasta ahora. Lo primero es seleccionar la
opcin Add Table del men contextual y seleccionar la tabla existente en el esquema que deseamos
aadir al diagrama, como muestra la Figura 57.
Una vez que aparezca la tabla seleccionada en el diagrama, vamos a aadir la relacin con una
existente. Para ello pulsamos con el ratn el atributo stor_id en la tabla authors y, sin soltarlo, nos
movemos a la tabla stores. Ya tenemos la relacin entre ambas tablas, slo tendremos que confirmarlo
ante la pantalla que nos aparece en la Figura 58. El diagrama resultante es el mostrado en la Figura 59.
Si hacemos click derecho y escogemos la opcin propiedades sobre la nueva relacin creada, podemos
observar las restricciones y las reglas de integridad aplicables a la misma, mostradas en la Figura 60

Figura 57

83

Figura 58

Figura 59

84

Figura 60
El analizador de consultas
Introduccin
El analizador de consultas (o query analizer) es la herramienta que permite editar y ejecutar sentencias
de T-SQL. Su apariencia es la que muestra la Figura 61.
Podemos observar en ella un editor, que sirve para ejecutar las sentencias, una barra de men, con las
opciones disponibles, y una barra de herramientas con iconos de acceso rpido a ciertas utilidades.
Las opciones de men
Entre las opciones que ofrece el men File, podemos encontrar las siguientes:
Connect: Abre una nueva conexin a una base de datos.
Disconnect: Cierra la conexin a la base de datos en uso.
Disconnect all: Idem que el anterior, pero para todas las conexiones abiertas
New: Abre una nueva ventana dentro del editor.
Open: Abre un archivo de SQL existente.
Save: Guarda a un archivo la ventana del editor en uso.


86
Save as: Idem que el anterior, pero con la posibilidad de indicar un nombre de archivo.
Save all queries: Idem que el anterior, pero para todas las ventanas abiertas en el editor.
Print: Imprime la ventana en uso del editor.
Recent file list: Muestra una lista con los archivos ms recientemente usados.
Exit: Cierra el analizador de consultas.

Figura 61

Figura 62

En el men Edit podemos encontrar las siguientes opciones:
Grupo EIDOS 10. El analizador de consultas

87
Undo: Deshace el ltimo cambio realizado en el texto de la ventana en uso del editor.
Cut: Corta el texto seleccionado al portapapeles.
Copy: Copia el texto seleccionado al portapapeles.
Paste: Pega el contenido del portapapeles a la ventana en uso del editor.
Select all: Selecciona todo el texto de la ventana en uso del editor.
Clear window: Borra todo el contenido de la ventana en uso del editor.
Find: Busca un texto determinado dentro de la ventana en uso del editor.
Repeat last find: Idem que el anterior, pero para buscar varias coincidencias.
Replace: Reemplaza un texto por otro, dentro de la ventana en uso del editor.
Go to line: Mueve el cursor a una lnea determinada, dentro de la ventana en uso del editor.
Bookmarks: Permite manejar los bookmarks, o marcas dentro del texto de las sentencias a
ejecutar, para su mejor identificacin.
Insert template: permite aadir una plantilla de una sentencias, muy util para sentencias
repetitivas. Adems SQL-Server nos ofrece plantillas predeterminadas, para cada uno de los
casos ms representativos (creacin de vistas, procedimientos almacenados, etc.), ahorrando al
programador la mayor parte del trabajo.
Replace template parameters: Permite al usuario cambiar los parmetros dentro de una
plantilla, es dccir, rellenarla con las tablas, campos, etc. que se ajusten a sus necesidades.
Advanced: Opciones avanzadas de edicin.

Figura 63


88
Dentro del men Query nos encontramos con las opciones disponibles, relacionadas con la edicin y
ejecucin de consultas:
Change Database: Permite cambiar la actual conexin a una base de datos por otra.
Parse: Compila la consulta del editor, verificando su sintaxis, y mostrando errores si no
cumple con sta.
Execute: Ejecuta la consulta del editor.
Cancel executing query: En el caso de que se est ejecutando una consulta, permite
detenerla.
Display estimated execution plan: Muestra el plan previsto, desglosando en pasos cmo se
ejecutar la consulta. La Figura 65 indica un posible plan de ejecucin para una consulta
concreta.
Index tunning wizard: Permite realizar el ajuste o tunning (cuyo concepto ya ha sido visto
en los primeros captulos) de los ndices de una base de datos concreta. En particular, esta
opcin arranca un asistente para realizarlo.
Results in text: Si est marcada esta opcin, los resultados de la consulta sern mostrados en
formato textual.
Results in grid: Si est marcada esta opcin, los resultados de la consulta sern mostrados en
una rejilla o grid, separados por filas y columnas.
Results to file: Si est marcada esta opcin, los resultados de la consultas sern enviados a un
archivo.
Show execution plan: Si esta opcin esta marcada, se muestra el plan de ejecucin de la
consulta, una vez realizada. Si la opcin display estimated execution plan nos enseaba el plan
estimado, esta opcin muestra, junto con los resultados, el plan real de ejecucin de sta.
Show server trace: Si esta opcin est marcada, se muestra informacin acerca de la traza de
ejecucin de la consulta en el servidor, es decir, pasos de la ejecucin, consumo de
procesador, nmero de lecturas/escrituras, etc. La Figura 66 muestra una posible traza de
ejecucin en el servidor de una sentencia select de ejemplo.
Show client statistics: Si esta opcin est marcada, se muestran estadsticas de ejecucin de la
consulta, vista desde la parte cliente. Una posible estadstica es la mostrada en la Figura 67.
Current connection properties: Muestra informacin acerca de la actual conexin a la base
de datos.
Por su parte, la opcin de men Tools muestra opciones referentes a herramientas que se pueden usar
para configurar diversas opciones referentes al editor o ejecucin de consultas.
La opcin Window permite manejar las ventanas que se encuentran dentro del editor, para colocarlas
en cascada, en mosaico, navegar entre ellas, etc.
Por ltimo la opcin Help ofrece una completa ayuda tanto del editor, como cuestiones diversas sobre
T-SQL.

89

Figura 64

Figura 65

90

Figura 66

Figura 67

91
La barra de herramientas
Crea un nueva consulta, pudiendo utilizar para ello una plantilla.
Abre una consulta existente en un archivo
Guarda la consulta del editor en un archivo
Introduce una plantilla de consulta en el editor
Corta el texto seleccionado al portapapeles
Copia el texto seleccionado al portapapeles
Pega el texto almacenado en el portapapeles
Borra el contenido de la ventana del editor
Busca un texto determinado en la consulta del editor
Deshace el ltimo cambio realizado en la consulta del editor
Permite seleccionar la forma en que se mostrarn los resultados (en texto,
rejilla o archivo) y la informacin adicional (plan de ejecucin, trazas de
servidor y estadsticas de cliente).
Compila la consulta para verificar su sintaxis.
Ejecuta la consulta.
Detiene la ejecucin de una consulta.
Permite seleccionar la base de datos.
Muestra el plan estimado de ejecucin de la consulta
Muestra una lista de los objetos del sistema
Permite realizar una bsqueda de los objetos del sistema
Muestra informacin acerca de la actual conexin
Muestra el panel de resultados de la ejecucin de la consulta

92
Ejecutando una consulta
Pongamos ahora en prctica los conceptos aprendidos ejecutando una consulta sencilla (no debe
preocuparse si todava no entiende nada de cdigo, ya que entraremos en detalle en posteriores
captulos). Para ello accederemos al analizador de consultas, tecleando el servidor (si no se pone nada
se acceder al servidor local) y el login y password, como muestra la Figura 68.

Figura 68

Una vez hecho esto, ya tenemos acceso a todas las bases de datos existentes en el servidor. Escogemos
una de ellas, por ejemplo pubs, y dentro del editor tecleamos el Cdigo fuente 3, cuyo cometido es
mostrar todos los valores de todos los atributos de la tabla titles.

SELECT * FROM titles
Cdigo fuente 3

A continuacin ejecutamos la sentencia, haciendo click en el botn en forma de flecha verde de la
barra de herramientas, escogiendo la opcin Execute del men Query, o tecleando F5.
Lo que nos aparecer ser una ventana como la de la Figura 69.
En ella podemos apreciar como se nos ha dividido el editor en dos partes. La de arriba contiene la
sentencia a ejecutar, mientras que la de abajo muestra los resultados de la ejecucin de la misma.
Probemos ahora a mostrar los resultados en forma de tabla. Para ello seleccionamos la opcin Results
in grid del men Query. Ejecutamos nuevamente, y lo que nos aparece ahora es una ventana como la
que muestra la Figura 70.

93

Figura 69

Figura 70

En ella podemos observar como lo que antes nos apareca en forma de texto, ahora nos aparece en un
grid, con una salvedad, el mensaje que indicaba el nmero de registros devueltos aparece ahora en otra
pestaa en la parte inferior, nombrada como Messages. Esta pestaa no slo sirve para visualizar el

94
nmero de registros seleccionados, sino muestra otro tipo de mensajes, como por ejemplo los de error,
tal como se puede observar en la Figura 71.

Figura 71

Por ltimo, guardaremos nuestra pequea consulta en un archivo, para lo cual seleccionaremos la
opcin Save as del men File, y escogiendo un nombre para el mismo, como muestra la Figura 72.

Figura 72


95
Otra de las posibilidades que nos ofrece SQL-Server es la de exportar los datos que hayamos obtenido
en una consulta. Para ello, y estando en el modo de Results in grid, seleccionamos con el ratn el
rango de resultados que deseemos exportar y hacemos clic con el botn derecho del ratn para
seleccionar la opcin Save as. Nos aparecer una ventana como la de la Figura 73, en la que
deberemos dar un nombre al archivo, y la forma de exportacin y separacin de campos.

Figura 73
El lenguaje de definicin de datos (DDL)
Introduccin
Como ya se vio en la anterior parte acerca del diseo de esquemas relacionales, existen dos tipos de
sentencias, con diferente cometido, que permiten mantener dicho esquema:
Lenguaje de Manipulacin de Datos (DML): permite manipular los datos del esquema
relacional, es decir, consultar, actualizar, o borrar informacin.
Lenguaje de Definicin de Datos (DDL): permite establecer y/o modificar el esquema
relacional, es decir, aadir, borrar o actualizar atributos, tablas, ndices, etc.
En este captulo se ver este ltimo, dejando el primero para otro posterior. Si el lector encuentra
alguna terminologa un tanto desconocida, no se preocupe, ya que en un prximo captulo se
describirn con detalle los operadores bsicos que ofrece Transact SQL, as como algunas
consideraciones acerca del lenguaje.
Tipos de datos
Existe una amplia variedad de tipos de datos que podemos utilizar en Transact SQL. Estos tipos de
datos sern utilizados a la hora de definir los atributos de una tabla. La Tabla 25 muestra una
descripcin de stos.


98
Identificador
en SQL Server
Descripcin Rango de valores Tamao
Int Entero Desde -2.147.483.648 hasta
+2.147.483.647
4 bytes
bigint Entero largo 8 bytes
Smallint Entero corto Desde -32.768 hasta 32.767 2 bytes
Tinyint Entero minsculo (sin
signo)
Desde 0 hasta 255 1 byte
numeric(p,s)
decimal(p,s)
decimal exacto sin
redondeo
Enteros y decimales desde -
1.79E308 hasta +1.79E308
en donde p es el nmero de
dgitos de la parte entera
(precisin) y s es el de la
parte decimal (escala)
de 2 a 17 bytes
dependiendo de la
precisin
especificada
float(n) numrico de coma
flotante con redondeo,
donde n est
comprendido entre 8 y
15. Doble precisin.
Redondeos de nmeros
desde -1.79E308 hasta
+1.79E308. Precisin
positiva: desde 2.23E-308
hasta 1.79E308
Precisin negativa: desde -
2.23E-308 hasta -1.79E308
8 bytes
real numrico de coma
flotante con redondeo,
donde n est
comprendido entre 1 y
7. Simple precisin.
Redondeos de nmeros
desde -3.40E38 hasta
+3.40E38. Precisin
positiva: desde 1.18E-38
hasta 3.40E38
Precisin negativa: desde -
1.18E-38 hasta -3.40E38
4 bytes
char(n) Alfanumrico de
longitud fija
Declarable hasta un mximo
de 255 caracteres
1 byte por carcter
declarado. Espacio
consumido fijo.
varchar(n) Alfanumrico de
longitud variable
Declarable hasta un mximo
de 255 caracteres
1 byte por carcter
usado. Espacio
consumido variable
money Moneda. Nmeros con
una precisin de
cuatro decimales.
8 bytes
smallmoney Moneda. Nmeros con
una precisin de
cuatro decimales.
Desde -
922.337.203.685.447,5508
hasta
922.337.203.685.447,5507
4 bytes
Grupo EIDOS 11. El lenguaje de definicin de datos (DDL)

99
datetime Fecha y hora para
fechas histricas
Desde 1-enero-1753 hasta
31-diciembre-9999. El dato
horario se guarda como
nmero de milisegundos
desde la medianoche del da
en cuestin
8 bytes
smalldatetime Fecha y hora para uso
corriente
Desde 1-enero-1900 hasta
06-junio-2079. El dato
horario se guarda como
nmero de milisegundos
desde la medianoche del da
en cuestin
4 bytes
binary(n) Campo binario de
longitud fija
Mximo de 255 bytes de
longitud
n bytes, sean usados
todos o no
varbinary(n) Campo binario de
longitud variable
Mximo de 255 bytes de
longitud
n bytes como
mximo
text Campo para texto
largo de tipo Memo.
Mximo de 2 Gigabytes de
longitud
Mximo 2 GB
image Campo para guardar
imgenes de hasta 2
Gigas
Mximo de 2 Gigabytes de
longitud
Mximo 2 GB
Sql_variant Almacena datos de
distintos tipos
table Almacena datos
temporales
bit Tipo bit 0 1 Desde 1 bit mnimo
reutilizado a partir
del espacio de otra
columna hasta 1
byte mximo si la
columna fuera
nica.
Tabla 25
Creacin de tablas
Una de las principales sentencias de definicin de datos es la de creacin de una tabla. Su sintaxis es la
siguiente:
CREATE TABLE tabla (atributo tipo)

La ejecucin de esta sentencia, genera como resultado una nueva tabla, en la base de datos en la que
estemos conectados. El nombre de la tabla debe ir despus de la palabra TABLE. El nombre de los

100
atributos deber ir entre parntesis, especificando el tipo. Si existe ms de un atributo, se debern
separar por comas.
Otra opcin nos permite cargar un nmero de filas de otra tabla, cargando su estructura. La sentencia
encargada de esto la vemos en el Cdigo fuente 4.

SELECT * INTO tabla1 FROM tabla2
Cdigo fuente 4

La anterior sentencia, lo que hara sera volcar el contenido de la tabla tabla2 en la tabla tabla1. Sin
embargo, para poder utilizar esta opcin, es necesario modificar un parmetro de SQL Server. Para
ello, deberemos ejecutar el Cdigo fuente 5.

sp_dboption base_datos, 'select into/bulkcopy', true
Cdigo fuente 5
Modificacin de tablas
Entendemos por modificar una tabla, cambiar su estructura, es decir, aadir atributos, borrarlos, o
cambiar la definicin. La sentencia que permite modificar una tabla es la que muestra el Cdigo fuente
6.

ALTER TABLE tabla ADD atrib tipo NULL
Cdigo fuente 6

Ntese que el nuevo atributo aadido debe ser de tipo NULL, ya que si no se permiten valores nulos,
se producira un error, al crearse los campos de la tabla con este valor.
Por ejemplo, si queremos aadir un atributo atributo1 de tipo varchar(30), a la tabla tabla1, deberamos
ejecutar el Cdigo fuente 7.

ALTER TABLE tabla1 ADD atributo1 varchar(30) NULL
Cdigo fuente 7

Slo pueden modificar las tablas el administrador, el propietario de la base de datos, y el propietario
de la tabla.
Grupo EIDOS 11. El lenguaje de definicin de datos (DDL)

101
Borrado de tablas
La sentencia que borra una tabla aparece en el Cdigo fuente 8.

DROP TABLE tabla
Cdigo fuente 8

El nombre de la tabla que se borra, debe ir a continuacin de la palabra reservada TABLE.
Para poder borrar una tabla, sta no debe estar siendo usada. En este caso deberemos hacer un
SELECT de otra tabla para liberarla. Adems slo podr borrar una tabla el administrador, o el
propietario de la misma.
Creacin y borrado de ndices
La creacin de ndices en SQL Server, as como en la mayora de los SGBDR existentes, se debe
realizar junto con la creacin de la estructura de las tablas. De este modo se evitan posibles colisiones
que pueden surgir al crear ndices cuando la tabla ya tiene datos. Por ejemplo, si creamos un ndice
nico por un campo, esto es no puede admitir duplicados, y se encuentran valores no nicos, la
generacin del ndice dara un error. Sin embargo, SQL Server permite la creacin de ndices, aunque
la base de datos est cargada.

ALTER TABLE tabla ADD CONSTRAINT K1 PRIMARY KEY (cod1, cod2)
Cdigo fuente 9

Esta sentencia permite aadir una clave primaria en tabla, por los campos cod1 y cod2.
Para crear un ndice en la tabla todos, denominado Cdigo, por el campo cod_cliente, se debe
especificar el Cdigo fuente 10.

CREATE INDEX codigo ON todos (cod_cliente)
Cdigo fuente 10

S adems queremos que el ndice no admita valores nulos, se debe ejecutar el Cdigo fuente 11.

CREATE UNIQUE INDEX codigo ON todos (cod) WITH IGNORE_DUP_KEY
Cdigo fuente 11


102
La sentencia que se encarga de borrar un ndice, se muestra en el Cdigo fuente 12. Esta sentencia se
encarga de borrar el ndice cdigo creado anteriormente.

DROP INDEX codigo
Cdigo fuente 12
Ejemplos prcticos de uso del DDL
Introduccin
Se vern en este captulo una serie de ejemplos para poner en prctica los conceptos aprendidos en el
anterior, para afianzar al lector en el uso del lenguaje de definicin de datos, plasmado en el
analizador de consultas de SQL-Server 2000. Adems, la definicin de estos esquemas nos servir
como base para utilizar el lenguaje de manipulacin de datos en prximos captulos.
La sentencia CREATE TABLE
Esta sentencia es la que permite la creacin de nuevas tablas dentro de una base de datos. Recordamos
su sintaxis en el Cdigo fuente 13.

CREATE TABLE tabla (atributo tipo)
Cdigo fuente 13

Por ejemplo, se proceder a continuacin a crear una tabla destinada a contener informacin acerca de
las ofertas disponibles en una agencia inmobiliaria. Interesar almacenar por cada una de las ofertas la
siguiente informacin: un cdigo de identificacin, la provincia y el domicilio donde se encuentra, el
tipo de bien inmueble al que pertenece, si se encuentra en venta o alquiler y el precio del mismo. La
sentencia SQL que nos permite crear esta tabla se muestra en el Cdigo fuente 14:


104

CREATE TABLE [dbo].[Oferta] (
[OF_ID] [int] NOT NULL PRIMARY KEY ,
[OF_Provincia] [varchar] (50) NOT NULL ,
[OF_Direccion] [varchar] (50) NOT NULL ,
[OF_Tipo] [varchar] (50) NOT NULL ,
[OF_Transaccion] [varchar] (50) NOT NULL ,
[OF_Precio] [int] NOT NULL
) ON [PRIMARY]
Cdigo fuente 14

Sin embargo, la tabla que hemos creado ms arriba puede dar problemas, ya que no esta normalizada;
por ejemplo, no podremos crear un tipo de bien inmueble nuevo hasta que no dispongamos de un bien
con esas caractersticas. Por lo tanto procederemos a crear una tabla para los tipos de bienes y otra
para las provincias (que a su vez se relacionar con una tabla de comunidades autnomas). Para ello
primero borramos el esquema creado anteriormente, utilizando la sentencia drop table (aprenderemos
como modificar un esquema en el siguiente epgrafe). El diagrama de la Figura 74 mostrara el
esquema resultante, y el Cdigo fuente 15 las sentencias a ejecutar para conseguirlo.

Figura 74

DROP TABLE Oferta
GO
CREATE TABLE [dbo].[ComunidadAutonoma] (
[CA_ID] [int] NOT NULL PRIMARY KEY,
[CA_Nombre] [varchar] (50) NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Oferta] (
Grupo EIDOS 12. Ejemplos prcticos de uso del DLL

105
[OF_ID] [int] NOT NULL PRIMARY KEY,
[Prv_ID] [int] NOT NULL ,
[OF_Direccion] [varchar] (50) NOT NULL ,
[TB_ID] [int] NOT NULL ,
[OF_Transaccion] [varchar] (50) NOT NULL ,
[OF_Precio] [int] NOT NULL
)
GO
CREATE TABLE [dbo].[Provincia] (
[Prv_ID] [int] NOT NULL PRIMARY KEY,
[CA_ID] [int] NOT NULL ,
[Prv_Nombre] [varchar] (50) NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[TipoBien] (
[TB_ID] [int] NOT NULL PRIMARY KEY,
[TB_Nombre] [varchar] (50) NOT NULL
) ON [PRIMARY]
GO
Cdigo fuente 15

Supongamos ahora que se desea tener constancia de los datos personales de los comerciales que
trabajan en dicha agencia, necesitando almacenar, para cada uno de ellos, la siguiente informacin:
NIF (que de momento har las veces de clave primaria de la tabla), nombre y apellidos, direccin,
cdigo postal, provincia, telfono y categora, como muestra el Cdigo fuente 16 .

CREATE TABLE [dbo].[Comercial] (
[Com_NIF] [char] (10) NOT NULL PRIMARY KEY,
[Com_Nombre] [varchar] (50) NOT NULL ,
[Com_Apellidos] [varchar] (50) NOT NULL ,
[Com_Direccion] [varchar] (50) NOT NULL ,
[Com_CodPostal] [char] (5) NOT NULL ,
[Com_Telefono] [char] (9) NOT NULL ,
[Com_Categoria] [varchar] (10) NOT NULL
) ON [PRIMARY]
GO
Cdigo fuente 16

Al igual que para los comerciales, se necesitar tambin conocer los datos personales de los clientes
que estn suscritos a nuestra agencia, conociendo por cada uno de ellos su NIF, nombre y apellidos,
direccin, provincia, cdigo postal, telfono y sus datos bancarios (nos bastar con el CCC de la
cuenta bancaria), siendo en NIF la clave primaria de la tabla, como muestra el Cdigo fuente 17.

CREATE TABLE [dbo].[Cliente] (
[Cli_NIF] [char] (10) NOT NULL PRIMARY KEY,
[Cli_Nombre] [varchar] (50) NOT NULL ,
[Cli_Apellidos] [varchar] (50) NOT NULL ,
[Cli_Direccion] [varchar] (50) NOT NULL ,
[Cli_CodPostal] [char] (5) NOT NULL ,
[Cli_Telefono] [char] (9) NOT NULL ,
[Cli_CCC] [varchar] (30) NOT NULL

106
) ON [PRIMARY]
GO
Cdigo fuente 17

Hasta el momento, el diagrama de la Figura 75 muestra la situacin actual en la que se encuentra
nuestro esquema relacional:

Figura 75

Sin embargo, podemos darnos cuenta de que falta una cosa bastante importante para ubicar el
inmueble, y que son los transportes pblicos ms cercanos de los cuales dispone. Nos podemos
plantear esta informacin como dos tablas: una de tipos de transporte (por ejemplo metro y cercanas
RENFE) y otra de transportes en s, que almacenar las estaciones o paradas para cada tipo de los
mencionados (por ejemplo Legazpi y Pacfico para metro y Fanjul y Mstoles para cercanas), como
muestra el diagrama de la Figura 76 y el Cdigo fuente 18.

CREATE TABLE [dbo].[TipoTransporte] (
[TT_ID] [int] NOT NULL PRIMARY KEY,
[TT_Nombre] [varchar] (30) NOT NULL )
ON [PRIMARY]
GO
CREATE TABLE [dbo].[Transporte] (
[Tr_ID] [int] NOT NULL PRIMARY KEY,
[Tr_Nombre] [varchar] (30) NOT NULL,
[TT_ID] [int] NOT NULL
) ON [PRIMARY]
GO
Cdigo fuente 18

107

Figura 76

En un momento dado nos puede interesar la posibilidad de tener almacenados en la base de datos
todos los cdigos postales, para posibles clasificaciones de inmuebles o futuras estadsticas, as que
daremos tambin de alta esta tabla, necesitando los siguientes atributos: el cdigo postal (que actuar
como clave primaria de la tabla) y la provincia (ya que una misma provincia dispondr de distintos
cdigos postales, es una relacin 1-N, e importa la clave de esta ltima tabla), como nos indica el
Cdigo fuente 19

CREATE TABLE [dbo].[CodigosPostales] (
[Prv_ID] [int] NOT NULL,
[CP_Codigo] [char] (5) NOT NULL PRIMARY KEY
) ON [PRIMARY]
GO
Cdigo fuente 19
La sentencia ALTER TABLE
Como ya se explic, esta sentencia permite la modificacin del esquema o la estructura de una tabla ya
creada. Su sintaxis es la descrita en el Cdigo fuente 20:

ALTER TABLE tabla ADD atrib tipo NULL
Cdigo fuente 20

108
Volviendo sobre el ejemplo de la agencia desarrollado en el anterior epgrafe, podemos darnos cuenta
de varios aspectos del esquema que no son del todo correctos, y que se podran mejorar.
As, por ejemplo, los comerciales aparecen desconectados de las ofertas de bienes, por lo que no
mucho sentido, a no ser que slo nos interesen dichos datos a ttulo informativo. Pero ya que tenemos
esa tabla y, puesto que el modelo relacional es eso, la relacin entre tablas, podremos conseguir
informacin de valor aadido si conectamos la tabla de ofertas a la de comerciales, para de este modo
conocer qu comerciales han intervenido en la compra/alquiler de qu inmuebles. Esto puede ser muy
til a la hora de calcular comisiones o prever promociones, etc. Para conseguir esta caracterstica
adicional en nuestro esquema, ser necesario aadir un atributo ms a la tabla de ofertas que la
relacione con el comercial. Esto es as debido a la relacin 1-N que existe entre ambas tablas (un
comercial interviene en la transaccin de muchos inmuebles, pero un inmueble slo puede ser
gestionado por un comercial), lo que hace que se importe el atributo clave de la tabla de comerciales
como muestra el diagrama de la Figura 77.

Figura 77

Sin embargo esto nos obliga a modificar el esquema, con objeto de aadir este nuevo atributo a la
tabla de ofertas existente como muestra el Cdigo fuente 21.

ALTER TABLE [dbo].[Oferta] ADD [Com_NIF] [char] (10)
GO
Cdigo fuente 21

109
Sin embargo nos encontramos con un problema, y es que no podemos aadir un nuevo atributo con la
propiedad not null, as que deberemos ejecutar una segunda sentencia, que modifique el atributo
aadido para que no pueda tomar valores nulos (ya que es una clave ajena):

ALTER TABLE [dbo].[Oferta] alter column [Com_NIF] [char] (10) not null
GO
Cdigo fuente 22

Igual que para los comerciales, nos interesara saber qu clientes han comprado/alquilado qu
inmuebles, para controlar los pagos, enviarles facturas, etc. La conexin entre ambas tablas es similar
al caso anterior. Y al igual que en el anterior caso tambin, se necesita modificar el esquema de la base
de datos, as que se utilizar, de un modo similar, la sentencia alter table (vase el Cdigo fuente 23).

ALTER TABLE [dbo].[Oferta] ADD [Cli_NIF] [char] (10)
GO
ALTER TABLE [dbo].[Oferta] alter column [Cli_NIF] [char] (10) not null
GO
Cdigo fuente 23

Siguiendo el mismo razonamiento, haremos lo mismo con la tabla de cdigos postales. El caso de la
tabla de transportes es algo especial, ya que para un mismo inmueble pueden existir ms de una
estacin de metro cercana, que a su vez puede estar prxima a otros inmuebles; es un claro ejemplo de
relacin N-M. Si recordamos lo que ocurra con este tipo de relaciones, se creaba una tabla intermedia
que importaba las claves de ambas. El Cdigo fuente 24 muestra la forma de hacerlo:

CREATE TABLE [dbo].[OfertaTransporte] (
[Of_ID] [int] NOT NULL ,
[Tr_ID] [int] NOT NULL
) ON [PRIMARY]
GO
Cdigo fuente 24

Sin embargo esta tabla dispone de una clave primaria compuesta, formada por ambos atributos, as que
se deber ejecutar el Cdigo fuente 25 para modificar el esquema de forma que se aada una
restriccin en forma de clave primaria a dicha tabla:

ALTER TABLE [dbo].[OfertaTransporte] WITH NOCHECK ADD
CONSTRAINT [PK_OfertaTransporte] PRIMARY KEY NONCLUSTERED
(
[Of_ID],
[Tr_ID]
) ON [PRIMARY]
GO
Cdigo fuente 25

110
Sin embargo no debemos olvidarnos de un aspecto muy importante, que es el de las claves ajenas y las
restricciones. Deberemos relacionar todas las tablas de manera que se establezca una relacin entre las
claves ajenas que unen las relaciones, para no tener problemas de borrar una tupla de una tabla que sea
clave ajena en otra relacin, o insertar tipos que no estn dados de alta en las tablas maestras que los
tipifican.
Ejecutando el Cdigo fuente 26 podremos estar seguro de esto:

ALTER TABLE [dbo].[Oferta] ADD
CONSTRAINT [FK_Oferta_Cliente] FOREIGN KEY
(
[Cli_NIF]
) REFERENCES [dbo].[Cliente] (
[Cli_NIF]
),
CONSTRAINT [FK_Oferta_Comercial] FOREIGN KEY
(
[Com_NIF]
) REFERENCES [dbo].[Comercial] (
[Com_NIF]
),
CONSTRAINT [FK_Oferta_Provincia] FOREIGN KEY
(
[Prv_ID]
) REFERENCES [dbo].[Provincia] (
[Prv_ID]
),
CONSTRAINT [FK_Oferta_TipoBien] FOREIGN KEY
(
[TB_ID]
) REFERENCES [dbo].[TipoBien] (
[TB_ID]
)
GO
ALTER TABLE [dbo].[OfertaTransporte] ADD
CONSTRAINT [FK_OfertaTransporte_Oferta] FOREIGN KEY
(
[Of_ID]
) REFERENCES [dbo].[Oferta] (
[OF_ID]
),
CONSTRAINT [FK_OfertaTransporte_Transporte] FOREIGN KEY
(
[Tr_ID]
) REFERENCES [dbo].[Transporte] (
[Tr_ID]
)
GO
ALTER TABLE [dbo].[Provincia] ADD
CONSTRAINT [FK_Provincia_ComunidadAutonoma] FOREIGN KEY
(
[CA_ID]
) REFERENCES [dbo].[ComunidadAutonoma] (
[CA_ID]
)
GO
ALTER TABLE [dbo].[Transporte] ADD
CONSTRAINT [FK_Transporte_TipoTransporte] FOREIGN KEY
(
[TT_ID]

111
) REFERENCES [dbo].[TipoTransporte] (
[TT_ID]
)
GO
Cdigo fuente 26

Como podemos ver, la forma de introducir claves ajenas en la base de datos es mediante restricciones,
poniendo el nombre de la tabla donde se encuentra el atributo que es clave ajena, seguido de las
palabras foreign key y a continuacin las referencias a los atributos que son clave en sus relaciones.
Con todo esto, obtenemos el esquema relacional que se muestra en el diagrama de la Figura 78:

Figura 78
La sentencia DROP TABLE
Permite el borrado de una tabla existente en la base de datos, y su sintaxis es la que se muestra en el
Cdigo fuente 27:

DROP TABLE tabla
Cdigo fuente 27

112
Retomando el ejemplo que nos lleva en este captulo, podemos observar que la tabla de cdigo
postales, de momento, no nos aporta nada, ya que la informacin que se precisa para un inmueble, no
recoge este dato como algo necesario, por contra, puede dificultarnos la gestin de la base de datos, as
que procederemos a su borrado, como muestra el Cdigo fuente 28:

Drop table CodigosPostales
Cdigo fuente 28
La sentencia CREATE INDEX
La sintaxis que permite la creacin de ndices sobre tablas es la especificada en el Cdigo fuente 29:

CREATE [UNIQUE] INDEX indice ON tabla (atributos)
Cdigo fuente 29

Recordemos cual es el cometido de un ndice, que no es otro que el de acelerar las consultas que se
realizan sobre una base de datos. Sin embargo, es una decisin del diseador el establecer los ndices
oportunos para que el rendimiento de la misma no se vea afectado, ya que un ndice es una estructura
que si bien acelera las consultas, puede llegar a ralentizar las actualizaciones de datos.
Veamos que ndices podemos crear en el ejemplo que nos lleva este captulo. Por ejemplo, podemos
adivinar que la tabla crtica para realizar consultas ser la de ofertas. Es ms, podemos intuir que la
mayora de las consultas de dicha tabla involucrarn a los atributos precio y tipo de transaccin
(alquiler o venta).
La siguiente decisin es considerar si crear un nico ndice con estos dos atributos, o crear dos por
separado. Pues bien, depende de las consultas que se vayan a realizar.
Si suponemos que la mayora de las consultas se realizarn por ambos criterios, convendra crear un
nico ndice con ambos atributos. Sin embargo y, como ser el caso, la mayora de las consultas se
realizaran por precio o por tipo de transaccin, conviene crearlos por separado de la siguiente forma:

CREATE INDEX oferta1 ON Oferta (Of_Transaccion)
GO
CREATE INDEX oferta2 ON Oferta (Of_Precio)
GO
Cdigo fuente 30
La sentencia DROP INDEX
Permite el borrado de un ndice creado para una tabla, y su sintaxis es la que se muestra en el Cdigo
fuente 31.


113
DROP INDEX codigo
Cdigo fuente 31

Si en nuestro caso deseramos borrar el ndice oferta2 creado anteriormente, deberamos ejecutar:

drop index Oferta.oferta2
Cdigo fuente 32

La salvedad es que debemos indicar el cdigo del ndice de la forma tabla.indice, para evitar
ambigedades.
El lenguaje de manipulacin de datos
(DML)
Introduccin
Ya se ha visto en un captulo anterior el lenguaje de definicin de datos (DDL), que es el que permite
definir y modificar la estructura de un esquema. Veremos a continuacin el otro lenguaje, el de
manipulacin de datos, que nos permite, como su propio nombre indica, manejar los datos contenidos
en el esquema.
La sentencia Select
La sentencia Select es una sentencia SQL, que pertenece al conjunto del Lenguaje de Manipulacin de
Datos, y que sirve para recuperar registros de una o varias tablas, de una o varias bases de datos. Su
sintaxis es la siguiente:
SELECT <atributos> FROM <tablas>
[WHERE <condicion>]
[GROUP BY <atributos>]
[HAVING <condicin>]
[ORDER BY <atributos>]

Donde las maysculas representan palabras reservadas, y lo encerrado entre corchetes es opcional,
puede ser omitido. Una vez vista la anterior forma de representacin, vamos a detenernos en la sintaxis
de la sentencia Select. Se compone de tres partes:


116
SELECT <atributos>: permite hacer una proyeccin de las tablas, es decir, seleccionar los
campos que deseamos recuperar de la base de datos, separados por comas. Si se especifica el
smbolo *, se obtendrn todos los campos de la tabla.
FROM <tablas>: permite especificar la tabla de la cual se desean obtener los datos. Si se
especifica ms de una tabla, stas irn separadas por comas.
WHERE <condicin>: permite establecer una condicin de recuperacin de las filas de la/s
tabla/s. Slo se obtendrn aquellas tuplas que verifiquen dicha condicin, que ser opcional.
En el caso de que se omita esta parte, se recuperarn todas las filas.
GROUP BY <atributos>: permite establecer una seleccin de campos cuando se utilizan
funciones escalares o de conteo (ya se ver ms adelante lo que significa.
HAVING <condicin>: establece una condicin para los atributos obtenidos como resultado
de la aplicacin de funciones escalares.
ORDER BY <atributos>: permite obtener el resultado de la consulta ordenado por los
atributos especificados.
En el caso de que se especifiquen varias tablas, en la clusula FROM, ser conveniente denotar los
campos de la clusula SELECT precedidos por el nombre de la tabla donde se encuentra y un punto,
para que, en el caso de que dicho campo exista en ms de una tabla, se sepa en cada momento a cual
de ellos nos estamos refiriendo, evitando en este caso el problema de ambigedad.
Si por ejemplo, deseamos obtener todos los valores de los atributos title y price de la tabla titles,
deberamos escribir el Cdigo fuente 33.

SELECT title, price FROM titles
Cdigo fuente 33

De esta manera, obtenemos todas las filas, ya que no hemos dado ninguna condicin, de la tabla titles
(especificada en la clusula FROM), de las cuales slo visualizaremos los valores de los atributos title
y price (especificados en la clusula SELECT). Si por el contrario, deseamos obtener todos los
atributos de dicha tabla, deberamos escribir el Cdigo fuente 34.

Cdigo fuente 34

Puesto que hemos especificado el literal * dentro de la clusula SELECT, la anterior sentencia nos
devuelve todos los atributos de todas las filas de la tabla titles, es decir, nos devuelve toda la
informacin almacenada en ella.
Grupo EIDOS 13. El lenguaje de manipulacin de datos (DML)

117
La clusula Where
La forma de usar el Transact SQL para realizar consultas realizando una proyeccin horizontal (es
decir, seleccionando las filas), es mediante la opcin WHERE. A continuacin de esta palabra
reservada, se debe especificar la condicin lgica que se debe evaluar, para obtener aquellas filas que
la cumplen.
Para expresar una expresin lgica se pueden emplear cualquiera de los operadores de Transact SQL
cuyo resultado devuelva un valor lgico, aunque tambin se pueden utilizar operadores de cadena.
Estos operadores sern vistos en detalle en el siguiente captulo, pero bsicamente son los siguientes:
: compara si una expresin es mayor que otra
< : compara si una expresin es menor que otra
>= : compara si una expresin es mayor o igual que otra
<= : compara si una expresin es menor o igual que otra
<>: compara si una expresin es distinta que otra
LIKE : compara todas las cadenas que verifican un patrn de bsqueda
NOT LIKE : compara todas las cadenas que no verifican un patrn de bsqueda
BETWEEN : compara todas las cadenas que estn comprendidas en un rango de valores
IN : compara todas las cadenas que estn contenidas en una lista
Por ejemplo, si queremos obtener los ttulos cuyos derechos de autor sean mayores del 10 %,
teclearemos el Cdigo fuente 35. De la misma forma, si queremos obtener todos los ttulos cuyo precio
no supere los 2$, ejecutaremos el Cdigo fuente 36.

SELECT * FROM titleauthor WHERE royaltyper > 10
Cdigo fuente 35

SELECT * FROM titles WHERE price <= 2
Cdigo fuente 36

Si queremos obtener el nombre de los autores cuya primera letra este comprendida entre la C y la H, y
que a continuacin tenga el literal 'urry', ejecutamos el Cdigo fuente 37.

SELECT au_fname FROM authors WHERE au_fname LIKE '[C-H]urry'
Cdigo fuente 37

118
O si queremos obtener la ciudad de todos los autores, que se corresponda con San Francisco o con Salt
Lake City, ejecutaremos el Cdigo fuente 38.

SELECT city FROM authors
WHERE city in ('San Francisco','Salt Lake City')
Cdigo fuente 38

Si se desea conocer todos los ttulos cuyo precio oscila entre 1 y 2 dlares, ejecutaremos el Cdigo
fuente 39.

SELECT title FROM titles
WHERE price BETWEEN 1 AND 2
Cdigo fuente 39
La clusula Group by
La clusula GROUP BY agrupa, como su propio nombre indica, filas que tienen el mismo valor para
un atributo, en grupos distintos. Por ejemplo, si queremos obtener el apellido de todos los autores,
ejecutamos el Cdigo fuente 40.

SELECT au_lname FROM autors
Cdigo fuente 40

Si nos fijamos en el resultado obtenido, tenemos que existen dos autores, cuyo apellido es el mismo,
Ringer. Por lo tanto, se muestran dos filas iguales para este apellido, una por cada autor que se apellida
Ringer. Supongamos ahora, que lo nico que nos interesa es obtener todos los apellidos que sean
distintos. Para ello deberemos agrupar los autores cuyo apellido sea el mismo en un nico grupo, y a
continuacin mostrar los grupos, en lugar de las filas. Con esto garantizamos que slo se mostrar una
fila por cada apellido distinto, ya que slo mostramos una fila del grupo, en lugar de todas. Esto que
parece tan complicado, se resume en una sentencia, usando la clusula GROUP BY.

SELECT au_lname FROM authors GROUP BY au_lname
Cdigo fuente 41

En ella, lo que se hace es simplemente un select, pero no de las filas de la tabla, sino de los grupos
obtenidos a partir de la clusula GROUP BY. Puesto que deseamos agrupar por el apellido, detrs de
esta clusula se debe determinar el atributo au_lname, garantizando as que todas las filas cuyo valor
de este atributo sea igual, irn al mismo grupo.

119
La clusula Having
La clusula HAVING es similar a la clusula WHERE, salvo que aquella se usa como condicin de
bsqueda cuando se especifica la clusula GROUP BY. Por lo tanto el funcionamiento es similar al ya
visto para WHERE. La nica diferencia es que HAVING se aplica a condiciones de grupo. Por
ejemplo, si dada la anterior sentencia de agrupacin, deseamos que slo se muestre el autor cuyo
apellido sea Ringer, ejecutaremos el Cdigo fuente 42.

SELECT au_lname FROM authors GROUP BY au_lname HAVING au_lname = 'Ringer'
Cdigo fuente 42
La clusula Order by
La clusula ORDER BY determina el orden de visualizacin de las filas obtenidas en la sentencia
SELECT. A continuacin de dicha palabra reservada, se debe especificar el atributo o los atributos por
los cuales se ordenar el resultado obtenido en la consulta.
Por ejemplo, si queremos mostrar el nombre y apellido de todos los autores de nuestra base de datos
pubs, bastar con ejecutar la sentencia que aparece en el Cdigo fuente 43 donde el atributo
especificado a continuacin de la clusula ORDER BY, es decir, au_lname, determina cmo se
ordenarn las filas que se mostrarn, en este caso alfabticamente por el apellido.

SELECT au_lname, au_fname FROM authors ORDER BY au_lname
Cdigo fuente 43
Funciones escalares para Select
Entendemos por funciones escalares, todas aquellas que permiten realizar operaciones de conteo de
filas, suma de atributos, obtencin de medias, etc. Dichas funciones se especifican a continuacin de la
palabra reservada SELECT. Las funciones que soporta la sentencia SELECT en el Transact SQL son
las siguientes:
SUM: Realiza una suma acumulativa de un atributo para todas las filas accedidas mediante
una consulta SQL.
Por ejemplo, supongamos que tenemos una tabla de pedidos, con los atributos cod_cliente,
cod_material y precio. Si queremos obtener la suma del precio de todos los pedidos
almacenados, bastar con realizar una funcin de tipo SUM, como la que vemos en el Cdigo
fuente 44.

SELECT sum(precio) FROM pedido
Cdigo fuente 44

120
La anterior consulta obtiene la suma del precio para todas las filas de la tabla pedido, ya que
no hemos especificado ninguna condicin en la clusula WHERE.
Si ahora queremos obtener la suma total de todos los pedidos realizados por el cliente cuyo
cdigo es "R12CE", debemos realizar la misma consulta, pero especificando una condicin
para obtener nicamente las filas cuyo cod_cliente es "R12CE":

SELECT sum(precio) FROM pedido WHERE cod_cliente = "R12CE"
Cdigo fuente 45

COUNT: Cuenta todas las filas de las tablas accedidas mediante una consulta SQL.
Por ejemplo, si tenemos una tabla cliente, con todos los clientes de una empresa de servicios,
con los atributos DNI, nombre, apellidos, direccin y poblacin, y queremos saber todos los
clientes que tenemos, deberemos realizar un count, para obtener todas el nmero de filas de la
tabla ejecutamos el Cdigo fuente 46.

SELECT count(DNI) FROM cliente
Cdigo fuente 46
En el anterior ejemplo, al existir el mismo nmero de filas, sea cual sea el atributo que
seleccionemos, podramos haber escogido cualquier otro. En general, se suele escribir el
Cdigo fuente 47.

SELECT count(*) FROM cliente
Cdigo fuente 47

Si ahora queremos saber el nmero de clientes que viven en Madrid, deberemos realizar un
conteo de todas las filas con la condicin de que el atributo poblacin sea Madrid.

SELECT count(*) FROM cliente WHERE poblacion = "Madrid"
Cdigo fuente 48

Si queremos saber cuantos ttulos tenemos nuestra base de datos, teclearemos el Cdigo fuente
49.

SELECT count(*) FROM titles
Cdigo fuente 49


121
Y si queremos saber cuantos ttulos tenemos, cuyo precio es mayor de 20 $, deberemos
realizar lo mismo, pero especificando esta condicin en la clusula WHERE. Al resultado de
la bsqueda le llamaremos caros.

SELECT count(*) caros FROM titles WHERE price > 20
Cdigo fuente 50

AVG: Realiza una media aritmtica de los atributos para todas las filas accedidas mediante la
consulta SQL.
Si por ejemplo tenemos una tabla de materiales, con los atributos cod_material, descripcin,
precio y cantidad_pedida, y queremos saber la cantidad media pedida de todos los materiales,
deberemos realizar una media aritmtica, teniendo en cuenta todas las filas de la tabla:

SELECT avg(cantidad_pedida) FROM material
Cdigo fuente 51

La anterior sentencia, internamente, realiza primero una suma de todos los valores, y a
continuacin la divide por el nmero total de filas accedidas, es decir, realiza la media
aritmtica.
Volviendo a nuestra cultural base de datos pubs, si queremos saber la media del precio de los
ttulos que tenemos disponibles, deberemos ejecutar el Cdigo fuente 52.

SELECT avg(price) media FROM titles
Cdigo fuente 52

MAX: Obtiene el mximo valor del atributo especificado, de entre todas las filas
seleccionadas mediante la sentencia SQL.
Supngase, por ejemplo, que tenemos la tabla de materiales descrita anteriormente. Si
queremos saber el material mas caro, deberemos realizar un SELECT con la clusula max, que
obtenga el mayor valor para el atributo precio de todas las filas.
Para nuestro ejemplo, si queremos saber cual es el libro ms caro, ejecutaremos el Cdigo
fuente 53.

SELECT max(price) caro FROM titles
Cdigo fuente 53


122
MIN: Obtiene el mnimo valor del atributo especificado, de entre todas las filas seleccionadas
mediante la sentencia SQL. Si queremos saber cual es el libro ms barato de nuestra base de
datos, deberemos ejecutar el Cdigo fuente 54.

SELECT min(price) barato FROM titles
Cdigo fuente 54
La sentencia Insert
La otra gran sentencia de manipulacin de datos es INSERT. Si SELECT nos permita recuperar
datos, INSERT nos va a permitir aadirlos al esquema, es decir, con esta sentencia podemos aadir
informacin a la base de datos. Recordemos que estamos en el modelo relacional, por lo que la
informacin se aadir a una tabla en forma de filas. Si slo queremos insertar un valor para un
atributo, el resto de los de la tabla deber contener el valor nulo (NULL). Sin embargo, habr ciertas
ocasiones en que esto no ser posible, cuando el atributo est definido como NO NULO, en cuyo caso
deberemos especificar un valor para ste. La sintaxis de este sentencia es:
INSERT INTO tabla (atributos)
VALUES (valores)

donde tabla especifica la tabla en la cual se aadir la fila, atributos es una lista de atributos
separados por comas que determinan los atributos para los cuales se darn valores, y valores
especifica los valores que se darn para estos atributos, separados por comas.
Por ejemplo, si queremos aadir un nuevo autor a nuestra base de datos, deberemos ejecutar el Cdigo
fuente 55.

INSERT INTO authors (au_id, au_lname, au_fname)
VALUES ('409-99-9876', 'Pepe', 'Perez')
Cdigo fuente 55

Destacar que si el valor a introducir es alfanumrico, deber ir encerrado entre comillas, mientras que
si es numrico no. Pues bien, si ejecutamos la anterior sentencia, obtenemos el siguiente error:
Server: Msg 515, Level 16, State 2, Line 1
Cannot insert the value NULL into column 'contract', table
'pubs.dbo.authors'; column does not allow nulls. INSERT fails.
The statement has been terminated.

La razn es que no hemos dado valor al atributo contract, que ha sido definido como no nulo. Por lo
tanto, rectificamos el Cdigo fuente 55, para dar un valor al Cdigo fuente 56.

INSERT INTO authors (au_id, au_fname, au_lname, contract)
VALUES ('409-99-9876', 'Pepe', 'Perez', 1)
Cdigo fuente 56

123
El valor que hemos dado al atributo contract es un 1, ya que est definido como tipo binario, es decir,
slo admite dos valores, 0 para especificar que no est contratado, y 1 para el caso contrario.
Al ejecutar esta sentencia, obtenemos como resultado
(1 row(s) affected)

lo que nos indica que la fila se ha insertado con xito. Podemos comprobarlo ejecutando un SELECT
sobre dicha fila.

SELECT * FROM authors WHERE au_id = '409-99-9876'
Cdigo fuente 57
La sentencia Update
El objetivo de la sentencia UPDATE es actualizar los valores de una o varias filas de una tabla, sin
necesidad de borrarla e insertarla de nuevo. La sintaxis es la siguiente:
UPDATE tabla SET atributo1 = valor1 , atributo2 = valor2, ...
WHERE condicion

donde tabla especifica la tabla donde se encuentran las filas que queremos actualizar, condicin
especifica la condicin que se debe cumplir para actualizar las filas, y lo que viene a continuacin de
SET especifica la asignacin de los nuevos valores a los atributos. Por lo tanto se actualizarn todas
las filas que cumplan la condicin especificada. Si queremos cambiar el nombre al autor que hemos
insertado en el anterior apartado, deberemos escribir el Cdigo fuente 58.

UPDATE authors SET au_fname = 'Pepito'
WHERE au_id = '409-99-9876'
Cdigo fuente 58

Lo que hacemos con la anterior sentencia es buscar el autor insertado, por el cdigo (condicin
where), y a continuacin actualizar el valor del atributo nombre de la fila obtenida a Pepito. Si
ejecutamos la anterior sentencia, obtenemos el resultado: (1 row(s) affected) lo que quiere
decir que la fila ha sido actualizada con xito. Podemos comprobarlo ejecutando el Cdigo fuente 59.

Cdigo fuente 59
La sentencia Delete
El objeto de la sentencia DELETE es el de borrar filas de una tabla. Para poder borrar filas en una
tabla se deben cumplir las condiciones de seguridad determinadas por el administrador (se vern en un

124
prximo captulo), y deben de cumplirse tambin las reglas de integridad referencial. La sintaxis es la
siguiente:
DELETE FROM tabla
WHERE condicion

donde tabla especifica la tabla sobre la cual queremos borrar las filas, y condicin especifica la
condicin que se debe cumplir para que se borren las filas. Si omitimos la condicin, se borrarn todas
las filas de la tabla, es decir, la sentencia que aparece en el Cdigo fuente 60 borra todas las filas de la
tabla authors.

DELETE authors
Cdigo fuente 60

Por ejemplo, si queremos borrar la fila que hemos creado en la tabla autores, deberemos ejecutar el
Cdigo fuente 61. obteniendo el siguiente resultado: (1 row(s) affected)

DELETE FROM authors
WHERE au_id = '409-99-9876'
Cdigo fuente 61

lo que viene a decir que la fila se ha borrado. Para comprobarlo, ejecutamos la sentencia que muestra
el Cdigo fuente 62. cuyo resultado es: (0 row(s) affected), lo que quiere decir que la fila
no se encuentra en la tabla, es decir, ha sido borrada.

Cdigo fuente 62
Operadores bsicos y consideraciones
del lenguaje
Introduccin
En este captulo se describirn con detalle los operadores bsicos, as como algunas apreciaciones
acerca del lenguaje que ofrece Transact SQL.
Entendemos por operadores, aquellas palabras reservadas o smbolos delimitadores que nos permiten
aplicar las diversas tcnicas del lgebra relacional. Las principales que veremos aqu son:
Proyeccin
Unin
Join o combinacin
No confundir los anteriores operadores propios del lgebra relacional, con los que ofrece SQL Server,
es decir, los que permiten la evaluacin de expresiones, unin de cadenas, comparaciones lgicas, etc.
Operador proyeccin
El operador de proyeccin es muy usado, sobre todo para acotar la consulta de tablas. Dicho operador
consiste en restringir la cantidad de informacin que obtenemos de una o varias tablas.


126
Aqu veremos la proyeccin vertical, es decir, en realizar una criba sobre aquellos atributos que nos
interesen para todas las filas de una tabla, aunque tambin se puede acotar el resultado de sta,
especificando una condicin, para que el resultado se aplique nicamente a las tuplas que la cumplan.
Veamos ahora como realizar una proyeccin utilizando Transact SQL. Para especificar los atributos de
la tabla o tablas que deseamos que aparezcan en la consulta, se debern proporcionar stos a
continuacin de la palabra reservada SELECT, y separados por comas.
Para especificar las tablas sobre las cuales se desea realizar la proyeccin, se debern especificar
despus de la palabra reservada FROM.
As, el Cdigo fuente 63 realiza una proyeccin de los atributos campo1 y campo2 de la tabla tabla1:

SELECT campo1, campo2 FROM tabla1
Cdigo fuente 63

El mtodo no varia si queremos realizar la proyeccin sobre ms de una tabla.

SELECT tabla1.campo1, tabla2.campo1 FROM tabla1, tabla2
Cdigo fuente 64

En el anterior ejemplo se ha proyectado sobre dos campos de dos tablas distintas. Para distinguir el
campo1 de tabla1, del campo1 de tabla2, se precede el nombre de la tabla al del campo, seguido por un
punto.
Probemos ahora con el query analyzer. Una vez abierto, nos conectamos a la base de datos pubs,
seleccionndola en la lista desplegable de la parte superior derecha, y tecleamos el Cdigo fuente 65.

SELECT title ttulo, type tipo FROM titles
Cdigo fuente 65

Ntese como despus de cada atributo hemos tecleado otro nombre. A este nombre se le denomina
alias y sirve para que el atributo obtenido aparezca con otro nombre.
As, en nuestro ejemplo, se recuperarn todas las filas de la tabla titles, y realizaremos una proyeccin
sobre los atributos title y type, pero como podemos observar en el resultado mostrado en la Figura 79,
dichos atributos aparecen bajo los nombre ttulo y tipo, que son los alias que les hemos dado
respectivamente.
Grupo EIDOS 14. Operadores bsicos y consideraciones del lenguaje

127

Figura 79
Operador Union
El operador unin consiste, como su propio nombre indica, en unir campos de ms de una tabla. El
resultado obtenido contendr entonces campos de las tablas especificadas en la clusula FROM. Este
operador casi nunca se utiliza por separado, sino junto con el de proyeccin, para obtener el resultado
consultando en varias tablas, y quedarnos luego slo con la informacin relevante. El Cdigo fuente
66 constituye un ejemplo de unin de las tablas tabla1 y tabla2:

SELECT * FROM tabla1, tabla2
Cdigo fuente 66

Otra forma de realizar una unin entre el resultado de dos consultas, es utilizar la palabra reservada
UNION. Por ejemplo, si queremos obtener la unin de las dos consultas a dos tablas, escribiremos el
Cdigo fuente 67.
Probemos ahora en el query analizer, tecleando el Cdigo fuente 68.
Pulsamos ahora el botn de ejecucin, o F5, y obtenemos el resultado mostrado en la Figura 80, que
no es ni ms ni menos, que todas las filas de las tablas titles y titleauthor.

128

Figura 80

SELECT * FROM tabla1 UNION SELECT * FROM tabla2
Cdigo fuente 67

SELECT * FROM titles, titleauthor
Cdigo fuente 68
Operador join
El operador de join es uno de los ms usados en el lgebra relacional. Sirve para combinar dos tablas
entre s, utilizando un atributo comn. Lo que se realiza es una unin de cada fila de una tabla, con
todas las filas de la tabla con la que se hace el join, cuyos atributos comunes coincidan.
La forma de realizarlo en Transact SQL es especificando en la clusula WHERE los atributos por los
cuales se va a realizar el join entre ambas tablas.

SELECT * FROM tabla1, tabla2 WHERE tabla1.campo1 = tabla2.campo1
Cdigo fuente 69

129

El Cdigo fuente 69 realiza un join entre las tablas tabla1 y tabla2, por el campo1 de ambas tablas.
Veamos un ejemplo de como funciona un join. Supngase que tenemos las dos siguientes tablas, y
deseamos hacer un join por el atributo campo1 de ambas.

Campo1 Campo2
1 10
2 9
3 4
4 1
Tabla 26

Campo1 Campo2
1 5
1 3
2 8
Tabla 27

Lo primero que se realiza al hacer un join es una unin de ambas tablas, copiando cada fila de la
primera tabla, y para cada fila cuyo campo comn sea igual en ambas tablas, copiar las filas de la
segunda tabla.
Por ejemplo, para la primera fila de la Tabla 26, hay dos filas en la Tabla 27 cuyo atributo campo1 es
igual. El join de estas dos tablas queda como muestra la Tabla 28

tabla1.campo2 tabla1.campo1 tabla2.campo1 tabla2.campo2
10 1 1 5
10 1 1 3
9 2 2 8
Tabla 28

Como hemos podido comprobar, la tercera fila de la tabla 1, no aparece en el join. Esto es debido a
que el valor del atributo por el que se hace el join (campo1), cuyo valor es 3, no existe en el atributo
campo1 de la tabla 2. A este tipo de join se le denomina inner join. El otro tipo de join, denominado
outer join, consiste en realizar el join, pero incluyendo todas las filas de ambas tablas, aunque stas no
tengan correspondencia en su homloga. Dentro de este tipo de join, existen dos categoras:

130
Left join: incluyen todas las filas de la primera tabla, aunque stas no tengan correspondencia
en la segunda. Los campos de la segunda tabla se rellenan con interrogantes.

Tabla1.campo2 tabla1.campo1 tabla2.campo1 tabla2.campo2
10 1 1 5
10 1 1 3
9 2 2 8
4 3 ? ?
Tabla 29

En Trasact SQL, la sentencia para realizar este left join se muestra en el Cdigo fuente 70.

SELECT * FROM tabla1
left join tabla2 on tabla1.campo = tabla2.campo2
Cdigo fuente 70
Rigth join: incluyen todas las filas de la segunda tabla, aunque stas no tengan
correspondencia en la primera. Los campos de la primera tabla se rellenan con interrogantes.

tabla1.campo2 tabla1.campo1 tabla2.campo1 tabla2.campo2
10 1 1 5
10 1 1 3
9 2 2 8
? ? 4 1
Tabla 30

En Trasact SQL, la sentencia para realizar este rigth join aparece en el Cdigo fuente 71.

SELECT * FROM tabla1
rigth join tabla2 on tabla1.campo = tabla2.campo2
Cdigo fuente 71

Tambin se puede realizar un join por ms de un campo. El Cdigo fuente 72 realiza un join entre las
tablas Tabla 26 y Tabla 27, por los campos comunes campo1 y campo2.

131

SELECT * FROM tabla1, tabla2 WHERE tabla1.campo1 = tabla2.campo1 AND tabla1.campo2
= tabla2.campo2
Cdigo fuente 72

En el lenguaje de manipulacin de datos, una de las operaciones ms usuales es precisamente la de
join de varias tablas. Veamos un ejemplo de implementacin de join en Transact SQL. Si se desea
obtener el ttulo de cada obra, junto con el nombre de su autor, deberemos ejecutar el Cdigo fuente
73.

SELECT titles.title, authors.au_lname FROM titles, titleauthor, authors
WHERE titles.title_id = titleauthor.title_id
AND titleauthor.au_id = authors.au_id
Cdigo fuente 73

Analicemos la anterior sentencia. Deberemos acceder a la tabla de ttulos, que es donde se encuentra el
ttulo de cada obra.
A continuacin, realizamos un join de esta tabla, con la tabla intermedia titleauthor, que es la que
almacena el cdigo de cada ttulo, junto con los autores que lo han escrito (recurdese que en las
relaciones N-M, se genera una tabla intermedia con la clave de cada tabla).
A partir de esta tabla, podemos acceder a los autores, realizando un join de la tabla titleauthor con la
tabla authors, precisamente por el campo au_id, que es el cdigo del autor. Por lo tanto, la clusula
WHERE realiza los dos join necesarios para acceder a las tres tablas.
Como se puede observar, en la clusula FROM se deben especificar todas las tablas que sern
accedidas, aunque de stas no se muestre ningn atributo.
El resultado es el mostrado en la Figura 81.
En la clusula WHERE, adems de las condiciones de join, podremos especificar otro tipo de
condiciones.
Por ejemplo, si queremos obtener una relacin de todos los ttulos cuyo precio no supere los 20 $,
junto con sus autores, ejecutaremos la misma sentencia que antes, pero aadiendo ahora una nueva
condicin, que es que el atributo price de la tabla titles no supere los 20$.

SELECT titles.title, authors.au_lname, titles.price FROM titles, titleauthor,
authors
WHERE titles.title_id = titleauthor.title_id
AND titleauthor.au_id = authors.au_id
AND titles.price < 20
Cdigo fuente 74


132

Figura 81

Figura 82
Operadores propios de Transact SQL
Los operadores que nos proporciona SQL Server se dividen en varios grupos:

133
Aritmticos: realizan operaciones aritmticas. Ej.: suma, multiplicacin, divisin, etc.
De nivel de bit: realizan operaciones transformando los operandos a bits. Ej.: AND al nivel de
bit, etc.
Lgicos: realizan operaciones que devuelven un resultado lgico. Ej.: comparaciones, etc.
De cadena: realizan operaciones que afectan a strings o cadenas de caracteres.
Ej.:concatenacin, bsqueda, etc.
La Tabla 31 muestra un resumen de los principales operadores con que nos podemos encontrar en
Transact SQL.

DESCRIPCIN EJEMPLO RESULTADO
+ Suma SELECT 2 + 4 6
- Resta SELECT 3 - 1 2
* Multiplicacin SELECT 3 * 2 6
/ Divisin SELECT 6 / 2 3
Operadores
Aritmticos
%
Mdulo o resto de la
divisin entera
SELECT 4 % 3 1
&
AND binario (1 si los
bits de ambos
operandos son 1)
SELECT 3 & 2
11 & 10 = 10 -
> 2
|
OR binario (1 si el bit
de alguno de los dos
operandos es 1)
SELECT 3 | 2
11 | 10 = 11 ->
3
^
OR exclusivo binario
(1 si el bit de los
operandos es distinto)
SELECT 3 ^ 2
11 ^ 10 = 01 ->
1
Operadores nivel de bit
~
NOT binario (cambia
el bit)
SELECT ~ 2 ~10 = 01 -> 1

= Igual SELECT 1 = 2 FALSO
< Menor SELECT 1 < 2 VERDADERO
> Mayor SELECT 1 > 3 FALSO
>= Mayor o igual SELECT 1 >= 1 VERDADERO
Operadores lgicos
<= Menor o igual SELECT 10 <= 1 FALSO

134
<> Distinto SELECT 1 <> 2 VERDADERO
!= Distinto SELECT 1 != 1 FALSO
!> No mayor SELECT 1 !> 3 VERDADERO

!< No menor SELECT 1 !<1 VERDADERO
+ Concatenacin SELECT 'A' + 'B' AB
[]
Cadenas coincidentes.
NOT: negacin de la
expresin LIKE:
bsqueda por patrn
SELECT * FROM
tabla WHERE
atributo1 LIKE '[C-
H]urry'
Curry Hurry
[^]
Cadenas no
coincidentes. NOT:
negacin de la
expresin LIKE:
bsqueda por patrn
SELECT + FROM
tabla WHERE
atributo1 NOT LIKE
'[^I-Z]'
J,K,L,M Operadores de Cadena
_
Cadena con ese
carcter coincidente.
NOT: negacin de la
expresin
LIKE: bsqueda por
patrn
SELECT * FROM
tabla WHERE
atributo2 like '_urry'
Hurry
Tabla 31
Otros operadores importantes aplicables a expresiones son los siguientes:
BETWEEN: Verifica los valores comprendidos dentro del rango especificado. La sintaxis es:
expresion BETWEEN expresion AND expression

Por ejemplo, si queremos obtener todos los ttulos cuyo precio oscile entre los 30 y los 50
dlares, escribimos el Cdigo fuente 75.

WHERE price BETWEEN 10 AND 50
Cdigo fuente 75

IN: Verifica si el valor especificado est contenido dentro de una lista de ellos. La sintaxis es:
expresion IN lista

Por ejemplo, si queremos obtener el nombre de todos los autores que vivan en San Francisco o
en Salt Lake City, ejecutamos el Cdigo fuente 76.


135
SELECT au_lname FROM authors
where city in ('San Francisco','Salt Lake City')
Cdigo fuente 76

Tambin se puede especificar como lista, el resultado de otra consulta. Por ejemplo, si
queremos obtener el nombre de los autores, que viven en ciudades pertenecientes al estado de
California (CA), escribimos el Cdigo fuente 77.

where city IN (SELECT city FROM authors WHERE state = 'CA')
Cdigo fuente 77

En la anterior consulta, la forma de evaluacin es desde dentro hacia fuera, es decir, primero
se evala la sentencia que est entre parntesis, y luego se aplica el valor obtenido para la
evaluacin del operador IN.
Variables globales
Existe un conjunto de variables globales, que informan en cada momento del estado del sistema, o del
resultado de una consulta, etc. Esta variables se pueden distinguir porque comienzan por dos arrobas
@@. La Tabla 32 muestra un resumen con las variables globales que nos pueden resultar de utilidad:

@@connections nmero de conexiones realizadas desde que se ejecut SQL Server
@@cpu_busy nmero de ticks (3.33 milisegundos) de ocupacin de la CPU ejecutando
instrucciones SQL Server desde que ste fue ejecutado
@@cursor_rows nmero de filas seleccionadas en la ltima seleccin
@@datefirst nmero del primer da de la semana
@@error nmero del ltimo error producido en la ejecucin de una sentencia, 0 si no
ha habido error
@@fetch_status estado de la preseleccin (0: preseleccin satisfactoria, -1: preseleccin
erronea, -2: filas no disponibles)
@@identity identificador de la ltima operacin realizada
@@idle nmero de ticks de tiempo ocioso de CPU desde que se ejecut SQL Server
@@io_busy nmero de ticks de tiempo empleado en realizar operaciones de
entrada/salida desde que se ejecut SQL Server
@@LANGID lenguaje local actual seleccionado

136
@@language descripcin del lenguaje especificado para SQL server
@@lock_timeout tiempo de time-out (tiempo hasta el cual se intenta dar por vlida la
transaccin) en milisegundos para bloqueo
@@max_connectio
ns
nmero mximo de conexiones simultaneas que permite SQL Server
@@max_precision nivel de precisin usado por los tipos de datos decimal y numeric
@@nestlevel nivel de anidamiento del actual procedimiento almacenado
@@options informacin sobre las opciones de usuario
@@pack_received nmero de paquetes recibidos por SQL Server desde que se inicializ
@@pack_sent nmero de paquetes enviados por SQL Server desde que se inicializ
@@packet_errors nmero de paquetes errneos desde que SQL Server se inicializ
@@procid identificador del actual procedimiento almacenado
@@remserver nombre del servidor remoto
@@rowcount nmero de filas afectadas por una sentencia de seleccin
@@servername nombre del servidor local
@@servicename nombre de la clave de registro para SQL Server
@@spid identificador del proceso actualmente en ejecucin
@@textsize tamao mximo para los tipos de datos texto e imgenes
@@timeticks nmero de milisegundos por tick de CPU
@@total_errors nmero total de errores producidos desde que se inicializ SQL Server
@@total_read nmero de lecturas de disco desde que se inicializ SQL Server
@@total_write nmero de escrituras en disco desde que se inicializ SQL Server
@@trancount nmero de transacciones activas por el usuario en curso
@@version versin, fecha y tipo de procesador actualmente en uso para SQL Server
Tabla 32

137
Sentencias condicionales
Las sentencias condicionales son aquellas que permiten discriminar entre diversas sentencias, segn se
cumpla el valor de una expresin lgica. Existen dos tipos de sentencias condicionales. La primera de
ellas tiene la siguiente sintaxis:
IF expresion_logica
sentencia1
[ELSE sentencia2]

La sentencia 1 slo se ejecutar si el resultado de la evaluacin de la expresin lgica es verdadera. En
otro caso, se ejecutar la sentencia 2, correspondiente a la parte ELSE (opcional). Si se desea
especificar un conjunto de sentencias, en lugar de una sola, stas debern ir encerradas entre las
palabras reservadas BEGIN y END. Si deseamos obtener los ttulos almacenados cuando stos superen
las 10 unidades, y el nmero de ellos cuando no lo superen, ejecutaremos el Cdigo fuente 78.

IF (SELECT count(*) FROM titles) > 10
BEGIN
SELECT title FROM titles
END
ELSE
BEGIN
SELECT count(*) FROM titles
END
Cdigo fuente 78

En definitiva, la sentencia SELECT title FROM titles slo se ejecuta cuando se cumple la condicin
(SELECT count(*) FROM titles) > 10. En otro caso, se ejecutar la rama ELSE, que devuelve el
nmero de ttulos almacenados en la tabla titles.
Otra forma de ejecutar sentencias de forma condicional, corresponde a la sentencia CASE. La sintaxis
es la siguiente:
CASE expresion1
WHEN expresion2 THEN resultado1
WHEN expresion3 THEN resultado2
...
[ELSE resultado3]

La anterior sentencia compara la expresin 1, con el resto de expresiones especificadas a continuacin
de la palabra reservada WHEN. Si alguna de estas expresiones se cumple, se devolver el resultado
correspondiente especificado a continuacin de la palabra reservada THEN. Si llegados al final, no ha
verificado ninguna de las expresiones, se devolver el resultado especificado a continuacin del ELSE.
Por ejemplo, si queremos saber el nombre de los estados de los autores, en lugar de las iniciales,
podemos ejecutar el Cdigo fuente 79.

SELECT state = CASE state
WHEN 'CA' THEN 'California'
WHEN 'OR' THEN 'Oregon'
ELSE 'Otro'

138
END
FROM authors
Cdigo fuente 79

En este caso se comprueba el valor del atributo state, y si este es igual a CA, se devolver California,
si es OR se devolver Oregon, y en otro caso se devolver el literal 'Otro'.
Sentencias iterativas
Una sentencia iterativa es aquella que permite ejecutar una o varias sentencias de manera repetida,
mientras se cumpla una condicin lgica. La sentencia que permite realizarlo es WHILE, y su sintaxis
WHILE expresion_logica
sentencia
[BREAK]
[CONTINUE]

La sentencia especificada se ejecuta de forma iterativa, mientras se cumpla la expresin lgica. La
clusula BREAK, permite romper el bucle, y abandonarlo, aunque se cumpla la expresin lgica,
mientras que CONTINUE permite ejecutar de nuevo las sentencias desde el comienzo del bucle,
ignorando aquellas que vienen a continuacin del CONTINUE.
La sentencia INSERT
Introduccin
La sentencia insert permite la introduccin de nuevos registros dentro de un esquema. Su sintaxis, que
ya se ha visto, especifica el nombre de una tabla, los atributos que se van a insertar, y los valores para
dichos atributos. Si insertamos un valor nulo para un atributo que no acepta ese tipo de valores, o si no
especificamos un valor concreto para este tipo de columnas, se producir un error y la fila no ser
insertada.
Sintaxis
La sintaxis de la sentencia insert es la siguiente
INSERT INTO <tabla>
(<atributos>)
VALUES (<valores>)

donde <atributos> es una lista de atributos separados por comas, y <valores> es una lista de valores
separados por comas. Existe una correspondencia unvoca entre los atributos y los valores, es decir, al
atributo especificado en primer lugar se le asignar el valor indicado en primer lugar, y as
sucesivamente. La palabra reservada INTO es opcional y se puede omitir en la sentencia.

Bases de datos con SQL Server2000 Transact SQL Grupo EIDOS

140
Ejemplos
Para comenzar veremos un ejemplo sencillo de insercin de tuplas en la tabla del ejemplo de la
agencia inmobiliaria que venimos manejando. Insertaremos dos Comunidades Autonomas en la tabla
de comunidades, como indica el Cdigo fuente 80.

INSERT INTO ComunidadAutonoma
(CA_ID, CA_Nombre)
VALUES (1, Catalunya)
(CA_ID, CA_Nombre)
VALUES (2, Madrid)
Cdigo fuente 80

Figura 83

Para ver si efectivamente se han insertado ambos registros, ejecutamos una sentencia select como
muestra el Cdigo fuente 81 (vase la Figura 83).

SELECT *
FROM ComunidadAutonoma
Cdigo fuente 81
Grupo EIDOS 15. La sentencia INSERT

141
Como decamos, si ahora intentamos insertar otra provincia si especificar el atributo CA_ID, que es
clave, se producir un error, como podemos observar en la Figura 84 al ejecutar el Cdigo fuente 82.

(CA_Nombre)
VALUES (Andaluca)
Cdigo fuente 82

O si por el contrario introducimos un valor duplicado para la clave, tambin obtendremos el error de la
Figura 85 al ejecutar el Cdigo fuente 83.

(CA_ID, CA_Nombre)
VALUES (1, Andaluca)
Cdigo fuente 83

Figura 84

Otra forma de introducir filas es no especificando la lista de atributos, en cuyo caso los valores se van
asignando de manera secuencial a los atributos de la tabla. Por ejemplo en el Cdigo fuente 84 se
asigna el valor 3 al atributo CA_ID y Andaluca al atributo CA_Nombre.

142

Figura 85

VALUES (3, 'Andaluca')
Cdigo fuente 84

Del mismo modo se pueden especificar valores para los atributos en distinto orden, siempre que se
expresen de manera explcita en la lista de los mismos, como muestra el Cdigo fuente 85, en el que se
asigna el cdigo 1 a la provincia Madrid, que pertenece a la comunidad de Madrid (es decir, cdigo 2).

INSERT INTO Provincia
(Prv_Nombre, Prv_ID, CA_ID)
VALUES ('Madrid, 1, 2)
Cdigo fuente 85

As mismo se pueden especificar menos valores que atributos, siempre que para los atributos que no se
especifiquen se puedan insertar valores nulos o los establecidos por defecto. La forma de asignar estos
valores por defecto es como se muestra en el Cdigo fuente 86.

INSERT INTO tabla DEFAULT VALUES
Cdigo fuente 86

143
Esto insertara una nueva fila en la tabla, con los valores establecidos por defecto.
Otra forma de insertar filas es a partir del resultado de una consulta. Por ejemplo, el Cdigo fuente 87
insertara en la tabla 2, los valores de la tabla 1. Ni que decir tiene que ambos esquemas deben
coincidir. Tambin se puede especificar un filtro en la clasula where para la consulta.

INSERT INTO tabla2
SELECT *
FROM tabla1
Cdigo fuente 87
Carga de la base de datos de ejemplo
Para concluir este captulo, se ofrecen las sentencias necesarias para cargar las tablas de la base de
datos del ejemplo de la agencia inmobiliaria que venimos utilizando.

INSERT INTO Provincia
VALUES (2, 1, 'Barcelona')
INSERT INTO TipoBien
VALUES (1, 'Piso')
VALUES (2, 'Chalet')
VALUES (3, 'Solar')
INSERT INTO Cliente
VALUES ('11384H', 'Juan Jose', 'Martinez', 'C/Bernardino 2', '28021', 1,
'913382888', '12888271777')
INSERT INTO Cliente
VALUES ('11383K', 'Alfonso', 'Loira', 'C/Apache 34', '28023', 1, '913334888',
'123423471777')
INSERT INTO Cliente
VALUES ('123454L', 'Amadeo', 'Lerra', 'C/Portugal 4', '08021', 2, '933485888',
'1282344777')
INSERT INTO Comercial
VALUES ('113384H', 'Juan Alberto', 'Espado', 'C/Alcala 321', '28038', 1,
'914538288', '1')
VALUES ('11323K', 'Luis', 'Canto', 'C/Esplandiu 4', '28033', 1, '913379888', '2')
VALUES ('22354L', 'Pedro', 'Alcantara', 'C/Portugal 4', '08021', 2, '933485875',
'3')
INSERT INTO Oferta
VALUES (1, 1, 'C/Samba, 4', 1, 'V', 100000, '11323K', '11384H')
INSERT INTO Oferta
VALUES (2, 2, 'C/Salca, 34', 2, 'A', 1000, '113384H', '11383K')
INSERT INTO Oferta
VALUES (3, 1, 'C/Sabueso, 83', 1, 'V', 100000, '11323K', '11383K')
INSERT INTO Oferta
VALUES (4, 2, 'C/Llobregat, 34', 2, 'V', 100000, '11323K', '11384H')
INSERT INTO Oferta
VALUES (5, 1, 'C/Alcala, 197', 1, 'A', 500, '113384H', '11384H')
INSERT INTO Oferta
VALUES (6, 2, 'C/Alquimia, 34', 2, 'V', 100000, '22354L', '123454L')

144
INSERT INTO Oferta
VALUES (7, 1, 'C/Alcosta, 867', 1, 'V', 100000, '11323K', '123454L')
INSERT INTO Oferta
VALUES (8, 1, 'C/Lorca, 33', 1, 'V', 100000, '22354L', '11384H')
INSERT INTO Oferta
VALUES (9, 1, 'C/Alcantara, 256', 1, 'V', 100000, '11323K', '11384H')
INSERT INTO Oferta
VALUES (10, 1, 'C/Arboleda, 32', 1, 'V', 100000, '11323K', '11384H')
INSERT INTO Oferta
VALUES (11, 1, 'C/Simbiosis, 32', 1, 'V', 100000, '11323K', '11384H')
INSERT INTO TipoTransporte
VALUES (1, 'Metro')
VALUES (2, 'Cercanias')
VALUES (3, 'Bus')
INSERT INTO Transporte
VALUES (1, 'Sol', 1)
VALUES (2, 'La Musas', 1)
VALUES (3, 'Alvarado', 1)
VALUES (4, 'Pacfico', 1)
VALUES (5, 'Sants', 1)
VALUES (6, 'Atocha', 2)
VALUES (7, 'Chamartin', 2)
VALUES (8, '12', 3)
VALUES (9, '24', 3)
VALUES (10, '2', 3)
VALUES (11, '123', 3)
VALUES (12, '56', 3)
VALUES (13, '34', 3)
VALUES (14, '5', 3)
INSERT INTO OfertaTransporte
VALUES (1, 1)
VALUES (1, 2)
VALUES (1, 3)
VALUES (3, 1)
VALUES (4, 4)
VALUES (4, 5)
VALUES (6, 1)
VALUES (6, 2)
VALUES (6, 6)
VALUES (8, 8)

145
VALUES (8, 9)
VALUES (8, 10)
VALUES (8, 11)
VALUES (9, 1)
VALUES (9, 8)
VALUES (10, 3)
VALUES (10, 10)
VALUES (10, 11)
VALUES (10, 12)
VALUES (10, 5)
Cdigo fuente 88
La sentencia SELECT
Introduccin
La sentencia select es la principal manera que tiene el usuario de consultar informacin de la base de
datos. Veremos aqu algunos ejemplos de utilizacin, basndonos en los ejemplos que hemos visto en
el captulo acerca del DDL.
La forma ms simple de utilizacin es especificando una lista de atributos de una tabla. As el Cdigo
fuente 89 mostrara todos los datos referentes a comerciales

SELECT *
FROM Comercial
Cdigo fuente 89

y el Cdigo fuente 90 mostrara el nombre y apellidos de todos los clientes

SELECT Cli_Nombre, Cli_Apellidos
FROM Cliente
Cdigo fuente 90


148
La clasula WHERE
La forma de especificar una condicin dentro de una sentencia select es mediante la clasula WHERE,
que especifica una condicin lgica que devolver nicamente aquellos registros que la cumplan.
Por ejemplo, para obtener todos los inmuebles de la tabla de ofertas que se encuentran en venta,
deberamos teclear el Cdigo fuente 91.

SELECT *
FROM Oferta
WHERE Oferta.Of_Transaccion = V
Cdigo fuente 91

O si queremos consultar todos los inmuebles cuyo precio oscile entre 100 y 2.000 euros, deberemos
ejecutar Cdigo fuente 92.

SELECT *
FROM Oferta
WHERE Oferta.Of_Precio >= 100 and Oferta.Of_Precio <= 2000
Cdigo fuente 92

Esta sentencia equivaldra a esta otra:

SELECT *
FROM Oferta
WHERE Oferta.Of_Precio BETWEEN 100 and 2000
Cdigo fuente 93

Si adems deseamos especificar un orden, habr que utilizar la clasula ORDER BY.
Por ejemplo, el Cdigo fuente 94 muestra el precio de todos los inmuebles de 100 a 2.000 euros,
ordenado de ms caro a ms barato, como muestra la Figura 86.

SELECT Oferta.Of_Precio
FROM Oferta
WHERE Oferta.Of_Precio BETWEEN 100 and 2000
ORDER BY Oferta.Of_Precio
Cdigo fuente 94
Grupo EIDOS 16. La sentencia SELECT

149

Figura 86
El operador join
Si la sentencia select es la ms utilizada para consulta de informacin, el operador join es el ms usado
para obtener informacin de tablas relacionadas. Si deseamos obtener datos de dos tablas que estn
relacionadas por un atributo, deberemos utilizar este operador para obtener la informacin contenida
en ambas.
Por ejemplo, para obtener una informacin detallada de en que provincias se encuentran los
inmuebles, deberemos ejecutar el Cdigo fuente 95.

SELECT Of_Direccion, Prv_Nombre
FROM Oferta
Inner join Provincia on Oferta.Prv_ID = Provincia.Prv_ID
Cdigo fuente 95

De esta manera obtenemos la informacin de la provincia, que se encuentra en otra tabla distinta de la
de ofertas, y que se encuentra relacionada con sta mediante la clave ajena Prv_ID.
En el anterior ejemplo se ha utilizado un inner join, pero tambin existen otros tipos de join, como
pueden ser el left outer y el rigth outer. La diferencia entre ambos ya se ha comentado en un captulo
anterior, as que no se entrar en detalle. Si por ejemplo deseamos obtener todas las viviendas que no

150
han sido compradas todava por ningn cliente, o que han sido asignadas a clientes errneos
deberemos ejecutar el Cdigo fuente 96.

SELECT Of_Direccion, Prv_Nombre, Cliente.Cli_NIF
FROM Oferta
Left outer join Cliente on Oferta.Cli_NIF = Cliente.Cli_NIF
WHERE Cliente.Cli_NIF is null
Cdigo fuente 96

En el anterior ejemplo, primero realizamos un inner join para obtener la provincia (caso de que no
exista no aparecera nada), y a continuacin un left outer join con la tabla de clientes para obtener el
cliente que tiene asignado la oferta; si dicho cliente no existe en la base de datos, obtendremos ese
atributo a nulo.
Puesto que se ha utilizado una clasula where que nos devuelve nicamente los clientes que tienen
dicho atributo a nulo, obtendremos los clientes que no tienen correspondencia con las ofertas.
Supongamos que ahora nos viene un cliente, y nos pregunta por todos los inmuebles, que sean pisos,
que se encuentren en alquiler y que pertenezcan a la provincia de Madrid. Habra que ejecutar el
Cdigo fuente 97.

SELECT *
FROM Oferta
and Provincia.Prv_Nombre = Madrid
inner join TipoBien on Oferta.TB_ID = TipoBien.TB_ID
and TipoBien.TB_Nombre = Piso
WHERE Oferta.Of_Transaccion = A
Cdigo fuente 97

Aunque el anterior cdigo es vlido, hubiese sido ms cmodo crear una vista como la siguiente:

CREATE VIEW dbo.vInmuebles
SELECT Oferta.Of_Transaccion, Oferta.Of_Direccion,
Provincia.Prv_Nombre, TipoBien.TB_Nombre
FROM Oferta INNER JOIN
Provincia ON
Oferta.Prv_ID = Provincia.Prv_ID INNER JOIN
TipoBien ON Oferta.TB_ID = TipoBien.TB_ID
Cdigo fuente 98

Ya continuacin hacer un select de la vista como si de una tabla se tratase:

SELECT *
FROM vInmuebles

151
WHERE Of_Transaccion = A and TB_Nombre = Piso and Prv_Nombre = Madrid
Cdigo fuente 99

Vamos ahora a por un ejemplo con los transportes. Supngase que se desea saber cuanto valen todos
los pisos que estn prximos a una estacin de cercanas o de metro. El cdigo sera el siguiente:

SELECT Of_Precio
FROM Oferta
Inner join OfertaTransporte on Oferta.Of_ID = Transporte.Of_ID
Inner join Transporte on OfertaTransporte.Tr_ID = Transporte.Tr_ID
Inner join TipoTransporte on Transporte.TT_ID = TipoTransporte.TT_ID
And (TipoTransporte.TT_Nombre = Metro
or TipoTransporte.TT_Nombre = Cercanias)
Cdigo fuente 100

Incluso podemos seleccionar todos los clientes que no han comprado ningn inmueble:

SELECT Cliente.Cli_Nombre
FROM Cliente
Left outer join Oferta on Oferta.Cli_NIF = Cliente.Cli_NIF
WHERE Oferta.Cli_NIF is null
Cdigo fuente 101

Sin embargo, el anterior cdigo podra haberse simplificado de la siguiente manera:

SELECT Cli_NIF
FROM Cliente
WHERE Cli_NIF not in (SELECT Cli_NIF FROM Oferta)
Cdigo fuente 102
Las funciones de agregado
Imaginemos ahora que deseamos obtener el inmueble ms caro de todos. Ordenando por precio de
manera descendente, lo cual se obtiene mediante la clasula ORDER BY <atributo> DESC, y
cogiendo el primer registro de todos (utilizando la clasula TOP 1), obtenemos el inmueble cuyo
precio es mximo, como muestra el Cdigo fuente 103 y podemos apreciar en la Figura 87.

SELECT top 1 Of_Direccion, Of_Precio
FROM Oferta
ORDER BY Of_Precio desc
Cdigo fuente 103

152

Figura 87

Sin embargo, T-SQL nos ofrece una forma ms sencilla de realizar esta consulta, utilizando una
funcin de agregado que se denomina max. De esta manera obtenemos el mximo valor para el
atributo que especificamos para dicha funcin, como muestra el siguiente cdigo equivalente:

SELECT max(Of_Precio)
FROM Oferta
Cdigo fuente 104

Adems de este funcin de agregado, SQL-SERVER nos ofrece otras muchas, que veremos en ms
detalle a continuacin.
Por ejemplo, y anlogamente a max, encontramos la funcin min, encargada de devolver el registro
cuyo valor es el mnimo, dentro de la consulta especificada. El Cdigo fuente 105 devolvera el
inmueble ms barato de la provincia de Madrid.

SELECT min(Of_Precio)
FROM Oferta
Inner join Provincia on Provincia.Prv_ID = Oferta.Prv_ID and
Provincia.Prv_Nombre = Madrid
Cdigo fuente 105

153
Otra funcin muy usual es la de suma, expresada por sum, y cuyo cometido es devolver como
resultado la suma del atributo especificado entre parntesis, dentro de la consulta especificada. Si
queremos obtener el dinero gastado por un cliente del que sabemos que su apellido empieza por
Marti, bastara ejecutar el Cdigo fuente 106.

SELECT sum(Of_Precio)
FROM Oferta
inner join Cliente on Oferta.Cli_NIF = Cliente.Cli_NIF
and Cliente.Cli_Apellidos like 'Marti%'
Cdigo fuente 106

En el anterior cdigo nos basamos en utilizar un join con la tabla de clientes utilizando el atributo
comn Cli_NIF, restringiendo en sta ltima tabla por aquellos clientes cuyo atributo apellidos
comience por Marti (clasula like).
No menos importante es la funcin count, cuya misin es contar es numero de filas que devuelve la
consulta. En este caso, aunque se puede especificar un atributo entre parntesis, lo ms usual es poner
el comodn *, ya que el nmero de filas es similar es para todos los atributos. El Cdigo fuente 107
servira para contar el nmero de filas de la tabla Oferta, es decir, el nmero total de ofertas
almacenadas en la base de datos.

SELECT count(*)
FROM Oferta
Cdigo fuente 107

Y si queremos obtener el nmero de ofertas existentes en la provincia de Barcelona, volveremos a
utilizar esta sentencia, pero ahora filtrando por el cdigo de provincia que, como no conocemos a
priori, ser necesario obtener por medio de un join que contenga dicho nombre, como muestra el
Cdigo fuente 108.

SELECT count(*)
FROM Oferta
And Provincia.Prv_Nombre = Barcelona
Cdigo fuente 108

Para obtener media aritmticas, SQL-SERVER nos ofrece la funcin avg, para un atributo
determinado dentro de una consulta. Por ejemplo, el cdigo que nos muestra la media del precio de los
inmuebles de Barcelona, seria equivalente al cdigo que realiza los clculos por separado.

SELECT avg(Of_Precio) FROM Oferta
Cdigo fuente 109

154

SELECT sum(Of_Precio) / count(Of_Precio) as media
FROM Oferta
Cdigo fuente 110

El funcionamiento es similar para las funciones encargadas de calcular la desviacin tpica (stdev), la
desviacin tpica de la poblacin (stdevp), la varianza estadstica (var) y la varianza de llenado (varp).
La clasula GROUP BY
Si deseamos obtener agrupaciones dentro de una consulta, deberemos utilizar esta clasula. Si por
ejemplo deseamos obtener la media del precio de los pisos por provincias, en principio deberamos
ejecutar el Cdigo fuente 111.

SELECT avg(Of_Precio), Provincia.Prv_Nombre
FROM Oferta
Cdigo fuente 111

Sin embargo, si ejecutamos este cdigo, nos mostrara un error, ya que avg devuelve un registro, y
Prv_Nombre puede que no sea nico, por lo que SQL SERVER se hace un lio. Para evitar esto,
debemos utilizar es la clasula group by, para obtener los resultados agrupados; entonces tendremos
un avg por cada grupo que obtengamos. Modificamos el cdigo para utilizar esta clusula, y
obtenemos algo como la Figura 88.

FROM Oferta
GROUP BY Provincia.Prv_Nombre
Cdigo fuente 112
Paralelamente al uso de group by se suele utilizar la clasula having. Para entendernos, es como un
where pero que se aplica a grupos de registros, en lugar de a registros por si solos. Si modificamos la
anterior consulta para que slo se devuelvan aquellas provincias cuya media de precio supera los
100.000 euros, lo lgico sera ejecutar el cdigo.

FROM Oferta
WHERE avg(Of_Precio) > 100000
Cdigo fuente 113

155

Figura 88

Sin embargo esto nos devuelve un error, ya que el where se aplica a registros y, al estar utilizando
group by deberemos especificar una funcin de agregado. Sustituimos el where por having en el
Cdigo fuente 114.

FROM Oferta
HAVING avg(Of_Precio) > 100000
Cdigo fuente 114

Otra utilidad que ofrece la clusula group by es la de obtener los valores distintos que aparecen para
uno o varios atributos. Por ejemplo, para obtener cuales son las provincias en las cuales tenemos algn
inmueble, podramos ejecutar el cdigo.

SELECT Prv_Nombre
FROM Oferta
inner join Provincia on Oferta.Prv_ID = Provincia.Prv_ID
Cdigo fuente 115


156
Sin embargo, esto nos devuelve un registro por cada oferta que se encuentre, con los consiguientes
duplicados. Para evitar esto, podemos utilizar la funcin dinstinct, como sigue.

SELECT distinct(Prv_Nombre)
FROM Oferta
Cdigo fuente 116

Sin embargo esto no es vlido si queremos realizar algn tipo de informacin adicional, por ejemplo
contar el nmero de inmuebles por provincia, que s se resolvera utilizando la clasula group by,
como muestra el Cdigo fuente 117.

SELECT count(Prv_Nombre) Cantidad, Prv_Nombre
FROM Oferta
GROUP BY Prv_Nombre
Cdigo fuente 117
La sentencia UPDATE
Introduccin
Esta sentencia es la que permite la actualizacin de la informacin almacenada en la base datos. Si la
sentencia insert se utilizaba para aadir nueva informacin, la sentencia update se utiliza para
modificar la informacin existente. Su sintaxis es la siguiente.
UPDATE <tabla>
SET <atributo> = <valor>
FROM <tablas>
WHERE <condicion>

Si se especifica ms de una asignacin de un valor a un atributo, stas se debern separar por comas.
La clasula FROM se puede omitir, en el caso de slo se necesite acceder a una tabla, que ser la
misma que la que se actualice.
Ejemplos
Para comenzar veremos un ejemplo sencillo, que se muestra en el Cdigo fuente 118 donde se
actualiza la direccin del comercial cuyo NIF es 11323K.

UPDATE Comercial
SET Com_Direccion = 'C/Esplandiu, 5'


158
WHERE Com_NIF = '11323K'
Cdigo fuente 118

Para comprobar que efectivamente el cambio ha tenido efecto, vamos a consultar los datos de este
comercial, ejecutando el Cdigo fuente 119, obteniendo el resultado de la Figura 89.

SELECT Com_NIF, Com_Direccion
FROM Comercial
WHERE Com_NIF = '11323K'
Cdigo fuente 119

Figura 89

Pero no simplemente se puede actualizar una fila cada vez, sino que se pueden actualizar todas las filas
que coincidan con un criterio de bsqueda. Por ejemplo, se puede hacer subir a la categora 4 a todos
los comerciales de Madrid, para la cual se deber ejecutar el Cdigo fuente 120.

UPDATE Comercial
SET Com_Categoria = '4'
FROM Comercial, Provincia
WHERE Comercial.Prv_ID = Provincia.Prv_ID
and Prv_Nombre = 'Madrid'
Cdigo fuente 120

Grupo EIDOS 17. La sentencia UPDATE

159
En este caso hemos tenido que especifica la clasula from para acceder a la tabla de provincias,
aunque no sea sta la que se actualice, ya que necesitbamos conocer el identificador correspondiente
a la provincia de Madrid. Para comprobar si se han actualizado los datos, y slo los correspondientes a
la provincia de Madrid, ejecutamos el Cdigo fuente 121.

SELECT Com_Categoria, Prv_Nombre
FROM Comercial, Provincia
WHERE Comercial.Prv_ID = Provincia.Prv_ID
Cdigo fuente 121

Figura 90

Hasta ahora slo hemos actualizado un atributo; pero como hemos dicho, es posible actualizar ms de
uno simultneamente. Por ejemplo, el Cdigo fuente 122 muestra como actualizar la direccin y el
telfono del cliente Juan Jose Martinez.

UPDATE Cliente
SET Cli_Direccion = 'C/Apache 35', Cli_Telefono = '912237887'
WHERE Cli_Nombre = 'Juan Jose' and Cli_Apellidos = 'Martinez'
Cdigo fuente 122


160
Para comprobar que se ha actualizado correctamente el registro, ejecutamos el Cdigo fuente 123,
obteniendo el resultado de la Figura 91.

SELECT *
FROM Cliente
WHERE Cli_Nombre = 'Juan Jose' and Cli_Apellidos = 'Martinez'
Cdigo fuente 123

Figura 91

Del mismo modo, no hace falta especificar un valor a la hora de actualizar uno o varios atributos, sino
que se puede indicar una expresin. Por ejemplo, podemos subir el precio de todos los inmuebles de
Barcelona un 5%. Primero ejecutaremos el Cdigo fuente 124 para comprobar cual es el precio de
estos inmuebles.

SELECT Of_Precio, Prv_Nombre
FROM Oferta
inner join Provincia on Provincia.Prv_ID = Oferta.Prv_ID
where Prv_Nombre = 'Barcelona'
Cdigo fuente 124

Ahora ejecutamos el Cdigo fuente 125 para actualizar su precio a un 5% ms de su valor actual.
Grupo EIDOS 17. La sentencia UPDATE

161
UPDATE Oferta
SET Of_Precio = Of_Precio + (Of_Precio * 0.05)
FROM Oferta, Provincia
WHERE Provincia.Prv_ID = Oferta.Prv_ID and Prv_Nombre = 'Barcelona'
Cdigo fuente 125

Y para comprobar que efectivamente se han actualizado estos registros, ejecutamos nuevamente el
Cdigo fuente 126.

SELECT Of_Precio, Prv_Nombre
FROM Oferta
inner join Provincia on Provincia.Prv_ID = Oferta.Prv_ID
where Prv_Nombre = 'Barcelona'
Cdigo fuente 126

De la misma forma que para la sentencia select, update nos permite la utilizacin de las funciones de
agregacin, para el clculo de expresiones. Por ejemplo, actualizaremos la categora del comercial
dependiendo del nmero de inmuebles que haya vendido cada uno. Si ha vendido entre 0 y 2, la
categora a asignar ser de 1, entre 3 y 4 ser 2, entre 5 y 6 ser 3, y as sucesivamente. Para calcular
dicha categora podemos aplicar la siguiente frmula:
Categoria = (n inmuebles vendidos / 2) + (n inmuebles vendidos mdulo 2)
El operador de mdulo o resto de la divisin entera se representa en T-SQL como %.
Vayamos paso a paso; primero veamos cuantos inmuebles ha vendido cada comercial, ejecutando la
sentencia del Cdigo fuente 127.

SELECT count(*) cantidad, Com_Nombre
FROM Comercial
left outer join Oferta on Oferta.Com_NIF = Comercial.Com_NIF
GROUP BY Comercial.Com_Nombre
Cdigo fuente 127

Por lo tanto vemos que la asignacin de categoras sera 1 para Juan Alberto y Pedro, y 4 para Luis.
Ejecutemos ahora el Cdigo fuente 128 que nos permite hacer esto.

UPDATE Comercial
SET Com_Categoria =
((SELECT count(*) / 2 FROM
Oferta where Comercial.Com_NIF = Oferta.Com_NIF) +
(SELECT count(*) % 2 FROM
Oferta where Comercial.Com_NIF = Oferta.Com_NIF))
Cdigo fuente 128

162
Lo primero que se ha hecho es para cada comercial calcular el nmero de ofertas que tiene
relacionado, para dividirlo por 2, calcular su mdulo 2 y luego sumarlo y asignarlo al campo categora.
Si ejecutamos una seleccin, como la que se muestra en el Cdigo fuente 129 para comprobar que
efectivamente la actualizacin se ha realizado con xito, nos encontraramos con lo siguiente.

SELECT Com_Nombre, Com_Categoria
FROM Comercial
Cdigo fuente 129
La sentencia DELETE
Introduccin
La sentencia delete es la que nos permite borrar tuplas almacenadas en la base de datos. Su sintaxis es
la siguiente.
DELETE FROM tabla
WHERE condicion

Donde tabla especifica el nombre de la tabla de donde se desean borrar las filas que cumplen la
condicin especificada en la clasula where. Si sta se omite, se borrarn todas las filas de la tabla
especificada (mucho cuidado con esto).
Si por ejemplo ejecutamos el Cdigo fuente 130, nos encontraremos con que se borrar la oferta cuyo
cdigo es 11 de la tabla de ofertas.

DELETE FROM Oferta
WHERE Of_ID = 11
Cdigo fuente 130

Para comprobar si se ha borrado dicho registro, podemos hacer una select completa de la tabla y
verificar que falta dicho registro aunque, lo ms sencillo, y conociendo que el registro que hemos
borrado era el ltimo introducido, podemos obtener el mximo valor para el atributo Of_ID, y
comprobar que no es superior a 10, ejecutando el Cdigo fuente 130.


164
SELECT max(Of_ID)
FROM Oferta
Cdigo fuente 131
La integridad referencial
Un aspecto a tener en cuenta es el no violar las reglas de integridad referencial que sostienen la base
de datos. Recordemos al lector que estas reglas son las que permiten mantener la informacin de la
base de datos en un estado coherente, para evitar posibles inconsistencias que pudieran surgir al
eliminar atributos que son clave ajena en otra relacin.
Para comprender mejor esto, supongamos que borramos todos los comerciales de la base de datos.
Esto supondra que tendramos ofertas inconsistentes, es decir, hacen referencia a comerciales que ya
no existen en la base de datos.
Para evitar esto, las reglas de integridad nos permiten olvidarnos a la hora de borrar un registro, si ste
esta relacionado con alguna otra tabla, evitando esta prdida de informacin.
Si lo hemos hecho bien, cuando pretendamos borrar una tupla de estas caractersticas, el SGBD nos
advertir de ello y no nos dejar borrarla.
De esta manera, si por ejemplo queremos borrar el comercial Luis Canto, ejecutaremos el Cdigo
fuente 132.

DELETE FROM Comercial
Where Com_Nombre = 'Luis' and Com_Apellidos = 'Canto'
Cdigo fuente 132

que, como caba esperar, nos da un error. Es decir, primero deberemos borrar todas las ofertas en las
que haya participado dicho comercial, ejecutando el Cdigo fuente 133.

DELETE FROM Oferta
FROM Comercial
Where Oferta.Com_NIF = Comercial.Com_NIF
and Com_Nombre = 'Luis' and Com_Apellidos = 'Canto'
Cdigo fuente 133

Sin embargo, al ejecutar este cdigo nos encontramos en la misma situacin, ya que resulta que
existen filas en la tabla que relaciona las ofertas y los transportes, que hacen referencia a dicha oferta.
Por lo tanto, primero deberemos borrar stas, como muestra el Cdigo fuente 134.

DELETE FROM Oferta
FROM Comercial
Grupo EIDOS 18. La sentencia DELETE

165
Cdigo fuente 134

Una vez borradas las filas de OfertaTransporte, volvemos atrs para borrar las filas de Oferta,
ejecutando el Cdigo fuente 135.

DELETE FROM Oferta
FROM Comercial
Cdigo fuente 135

Y una vez borradas las ofertas de dicho comercial, ya le podemos eliminar de la base de datos, sin
preocuparnos de posibles inconsistencias, con el Cdigo fuente 136.

DELETE FROM Comercial
Where Com_Nombre = 'Luis' and Com_Apellidos = 'Canto'
Cdigo fuente 136
La sentencia TRUNCATE TABLE
Esta sentencia funciona de la misma forma que la instruccin delete sin especificar una clusula
WHERE: ambas quitan todas las filas de la tabla. Pero TRUNCATE TABLE es ms rpida y utiliza
menos recursos de los registros de transacciones y de sistema que delete.
La instruccin DELETE quita una a una las filas y graba una entrada en el registro de transacciones
por cada fila eliminada. TRUNCATE TABLE quita los datos al cancelar la asignacin de las pginas
de datos utilizadas para almacenar los datos de la tabla y slo se graba en el registro de transacciones
la pgina de asignaciones quitadas.
TRUNCATE TABLE quita todas las filas de una tabla, pero permanece la estructura y sus columnas,
restricciones, ndices, etc. El contador utilizado por una identidad para las nuevas filas se restablece al
valor de inicializacin de la columna. Si desea conservar el valor del contador, se debe utilizar delete
en su lugar.
Por ejemplo, el Cdigo fuente 137 borrara todos los datos de la tabla Cliente

TRUNCATE TABLE Cliente
Cdigo fuente 137

166
Ejemplos
Veamos ahora algunos ejemplos para afianzar al lector en el uso de esta sentencia. Por ejemplo, y al
igual que hacamos con la sentencia select, se puede utilizar el resultado de una subconsulta para
borrar un conjunto de registros.
Por ejemplo, si queremos borrar todas las ofertas de la Catalunya, podemos utilizar una subconsulta
que nos devuelva los identificadores de las provincias pertenecientes a dicha comunidad, para a
continuacin efectuar el borrado de toda las ofertas que contengan dicho identificador, utilizando para
ello el operador de contenido (in).
Sin embargo, primero habr que borrar todas las filas de OfertaTransporte que estn relacionadas con
stas, para lo cual podemos volver a ejecutar una subconsulta en un segundo nivel para obtener dichas
filas. Para ello ejecutamos el Cdigo fuente 138

DELETE FROM OfertaTransporte
WHERE Of_ID in (SELECT Of_ID
FROM Oferta
WHERE Prv_ID in (SELECT Prv_ID
FROM ComunidadAutonoma, Provincia
WHERE ComunidadAutonoma.CA_Nombre = 'Catalunya'
and ComunidadAutonoma.CA_ID = Provincia.CA_ID))
Cdigo fuente 138

De esta manera y, una vez borradas todos los transportes disponibles para la oferta, borraremos las
ofertas como era nuestra pretensin, ejecutando el Cdigo fuente 139.

DELETE FROM Oferta
WHERE Prv_ID in (SELECT Prv_ID
FROM ComunidadAutonoma, Provincia
WHERE ComunidadAutonoma.CA_Nombre = 'Catalunya'
and ComunidadAutonoma.CA_ID = Provincia.CA_ID)
Cdigo fuente 139

Adems de especificar una tabla en una sentencia delete, se puede indicar una consulta. Por ejemplo,
el Cdigo fuente 140 mostrara como borrar las dos primeras ofertas.

DELETE Oferta
FROM (SELECT top 2 * FROM Oferta) as t
Cdigo fuente 140

Puesto que esto devuelve un error debido a la integridad referencial, deberemos ejecutar primero el
Cdigo fuente 141que elimine las filas de OfertaTransporte relacionadas.

Grupo EIDOS 18. La sentencia DELETE

167
DELETE OfertaTransporte
FROM (SELECT top 2 * FROM Oferta) as t
WHERE t.Of_ID = OfertaTransporte.Of_ID
Cdigo fuente 141

En este cdigo, se ha utilizado una subconsulta como tabla, especificando para la misma un alias (t),
que nos servir para luego hacer referencia a dicha subconsulta en la clasula where. Aqu, por
ejemplo, se utiliza para hacer un join con la tabla OfertaTransporte, que permita borrar dichas filas.
En este cdigo, se ha utilizado una subconsulta como tabla, especificando para la misma un alias (t),
que nos servir para luego hacer referencia a dicha subconsulta en la clasula where. Aqu, por
ejemplo, se utiliza para hacer un join con la tabla OfertaTransporte, que permita borrar dichas filas.
Procedimientos almacenados y triggers
Introduccin
Los procedimientos almacenados son conjuntos de sentencias en leguaje Transact SQL que pueden
almacenarse en el propio servidor. Los procedimientos almacenados de SQL Server, son ms potentes,
porque permiten almacenar funciones y procedimientos compuestos por varias instrucciones,
introducir saltos, bucles, etc. Tambin se pueden compilar procedimiento escritos en lenguaje C, para
ampliar su potencia modularmente.
Por ejemplo, podemos crear un procedimiento para recuperar el nombre de un autor, cuyo cdigo se
pasa por parmetro.

CREATE PROCEDURE ObtenerNombre @au_id varchar(11) AS
SELECT au_name
FROM author
WHERE author.au_id = @au_id
Cdigo fuente 142

Con esta sentencia, se crea un procedimiento almacenado, de nombre ObtenerNombre, al que se le
pasa un parmetro, llamado @au_id, de tipo varchar(11), que realiza una consulta para obtener el
nombre de la tabla author, cuyo cdigo coincida con el parmetro. De esta forma, si queremos obtener
el nombre del autor cuyo cdigo sea '123', deberemos ejecutar el procedimiento pasndole como
argumento este valor:


170
Las llamadas a procedimientos almacenados se pueden realizar de las siguientes formas:
Pasando los argumentos en el mismo orden que en el que se han declarado.

ObtenerNombre '123'
Cdigo fuente 143

Pasando los argumentos nombrados. En este caso no hace falta que los parmetros vayan en el
mismo orden.

ObtenerNombre @au_id = '123'
Cdigo fuente 144
Parmetros por referencia
Si ejecutamos las anteriores sentencias, obtendremos el resultado directamente en la ventana que
tengamos abierta en SQL Server. Pero que pasa si queremos obtener un parmetro de salida, como
resultado de la ejecucin del procedimiento?. La solucin para este caso es utilizar la palabra
reservada OUTPUT para los argumentos de salida.
Si por ejemplo, queremos obtener el nmero de autores y el nmero de libros que tenemos en la base
de datos, crearemos el procedimiento almacenado que muestra el Cdigo fuente 145.

CREATE PROCEDURE num_autores_libros @autores int OUTPUT, @libros int OUTPUT AS
SELECT * FROM Authors
SELECT @autores = @@ROWCOUNT
SELECT * FROM Titles
SELECT @libros = @@ROWCOUNT
RETURN (0)
Cdigo fuente 145

Vamos a estudiar el anterior ejemplo. Bsicamente es similar al anterior. Detrs de la palabra
reservada PROCEDURE damos el nombre del procedimiento almacenado, y a continuacin
proporcionamos los parmetros, junto con su tipo (que en este caso es entero), y diremos sin stos son
de salida, en cuyo caso especificamos la palabra reservada OUTPUT a continuacin. Tras la palabra
reservada AS se codifica el cuerpo del procedimiento.
Primero contamos todas las filas de la tabla authors, realizando un SELECT * FROM Authors. A
continuacin devolvemos en el parmetro @autores el valor obtenido, utilizando @@ROWCOUNT.
Acto seguido se realiza lo mismo para la tabla titles. Ntese como la forma de asignar un valor a un
atributo es mediante una sentencia SELECT, igualando el parmetro al valor.
La funcin @@ROWCOUNT devuelve el nmero de filas que se han seleccionado. Es equivalente a
la sentencia que aparece en el Cdigo fuente 146
Grupo EIDOS 19. Procedimientos almacenados y triggers

171

SELECT COUNT(*) FROM Authors
Cdigo fuente 146

El Cdigo fuente 146, por lo tanto, se podra sustituir por Cdigo fuente 147.

CREATE PROCEDURE num_autores_libros @autores int OUTPUT, @libros int OUTPUT AS
SELECT @autores = (SELECT COUNT(*) FROM Authors)
SELECT @libros = (SELECT COUNT(*) FROM Authors)
RETURN (0)
Cdigo fuente 147

Para ejecutar el anterior procedimiento, seguiremos los siguientes pasos:
1. Declarar las variables que vamos a utilizar para llamar al procedimiento. La sintaxis para
declarar una variable es utilizar la palabra reservada DECLARE, seguido del nombre de la
variable y el tipo.

DECLARE @num_autores int
DECLARE @num_libros int
Cdigo fuente 148

2. Ejecutar el procedimiento. La sintaxis es utilizar la palabra reservada EXEC, seguida del
nombre del procedimiento, y los parmetros, separados por comas, especificando si son de
retorno.

EXEC num_autores_libros @num_autores OUTPUT, @num_libros OUTPUT
Cdigo fuente 149

3. Mostrar los resultados.

SELECT autores = @num_autores, libros = @num_libros
Cdigo fuente 150

Tras ejecutar las anteriores sentencias, obtendremos como resultado el siguiente listado:
autores libros
--------------- ---------------
23 18
(1 row(s) affected)

172
Si queremos borrar un procedimiento almacenado, ejecutaremos la sentencia DROP PROCEDURE,
seguido del nombre del procedimiento. Por ejemplo, si queremos borrar el procedimiento almacenado,
creado en el anterior ejemplo, escribiremos el Cdigo fuente 151

DROP PROCEDURE num_autores_libros
Cdigo fuente 151
Procedimientos almacenados de sistema
SQL Server nos ofrece una serie de procedimientos almacenados ya implementados, es decir, listos
para ejecutar, cada uno con su propio objetivo o fin. Por ejemplo, si deseamos saber los usuarios
conectados a nuestro sistema, podemos elaborar una consulta SELECT sobre la tabla de sistema que
contiene los usuarios conectados, o ejecutar el procedimiento almacenado sp_who.

Figura 92

As, si escribimos sp_who, obtendremos una lista con todos los usuarios conectados, como podemos
observar en la Figura 92.
Si queremos obtener una lista con todas las tablas del sistema, disponemos de otro procedimiento
almacenado denominado sp_tables. Del mismo modo, si deseamos conocer todos los atributos de una
tabla, deberemos ejecutar sp_columns seguido del nombre de la tabla.

173
Por ejemplo, para listar los atributos de la tabla authors ejecutamos sp_columns authors, y
obtenemos el resultado de la Figura 93
Existe una gran variedad de procedimientos almacenados, como por ejemplo para crear dispositivos,
para comprobar el espacio usado por una tabla, etc. Aqu slo hemos visto dos ejemplos de aplicacin.

Figura 93
Extended stored procedures
Una de las principales ventajas que ofrece SQL Server es que permite la ejecucin de procedimientos
almacenados escritos en otro lenguaje de programacin, como por ejemplo C, aprovechando de este
modo toda la potencia que ofrece un compilador de este estilo.
De todos es conocida la potencia que ofrece el lenguaje C, ya que es un compilador a bajo nivel. Esto
es, permite interaccionar con el hardware, obtener datos del Sistema Operativo, etc. La tcnica que
permite el aprovechamiento de un lenguaje externo a SQL Server, para el diseo de procedimientos
almacenados se denomina Extended Stored Procedures.
Este es un caso un poco ms complicado que el manejo de procedimientos almacenados intrnsecos al
propio SQL Server. Los Extended Stored Procedures se implementan como DLLs, que sern
privadas a SQL Server, y cuya gestin del espacio de memoria corresponde a ste. Una DLL
(Dinamic Link Library) es un conjunto de funciones, que se cargan dinmicamente en memoria,
esto es, se cargan en memoria cuando vayan a ser usadas, y se descargan cuando no se necesiten. Si
por ejemplo, uno de estos procedimientos intenta acceder a una direccin que cae fuera del espacio de

174
direcciones permitido, SQL Server atrapa la excepcin, mata la tarea, y libera los bloqueos,
continuando normalmente con su trabajo.
Para registrar una Extended Stored Procedure, el administrador del sistema deber ejecutar la
sentencia en Transact SQL que aparece en el Cdigo fuente 152.

sp_addextendedproc nombre_funcin, nombre_DLL
Cdigo fuente 152

Para ejecutar una de estas funciones en una base de datos distinta de aquella en la que se ha registrado,
se deber preceder el nombre de la base de datos al nombre de la funcin.
Hay que destacar que estos procedimientos nicamente podrn ser ejecutados y registrados por el
administrador del sistema. Si ste desea permitir la ejecucin a los dems usuarios, deber ejecutar el
Cdigo fuente 153.

GRANT EXEC ON procedimiento TO PUBLIC
Cdigo fuente 153

Esta sentencia SQL otorga (GRANT) privilegios de ejecucin (EXEC) sobre el procedimiento
especificado, a todos los usuarios de la base de datos. Si slo deseamos otorgar este privilegio a un
usuario, deberemos especificar su identificador de usuario tras TO.
Triggers
Los disparadores de procedimiento, ms comnmente conocidos como triggers, son una especie de
procedimientos almacenados, a diferencia que se ejecutan cuando ocurre un evento sobre alguna tabla.
Entendemos por evento, cualquier accin del tipo:
Insercin
Borrado
Actualizacin
La sintaxis de la sentencia de creacin de triggers es la siguiente:
CREATE TRIGGER nombre ON tabla FOR accion AS codigo

donde accin especifica el evento que debe ocurrir para que se dispare el trigger, y que puede ser:
UPDATE: actualizacin.
INSERT: insercin.
DELETE: borrado.

175
Por ejemplo, si queremos crear un trigger llamado modificacin_autor, sobre la tabla Authors, que
muestre un mensaje cada vez que se actualiza una fila de la tabla, deberemos escribir el Cdigo fuente
154.

CREATE TRIGGER modificacion_autor ON authors FOR UPDATE AS
print "Han actualizado la tabla de autores"
Cdigo fuente 154

Para comprobar el funcionamiento de este trigger, podemos actualizar cualquier fila de la tabla de
autores, por ejemplo con la sentencia que aparece en el Cdigo fuente 155.

UPDATE authors SET au_fname = 'Miguel' WHERE au_id = '267-41-2394'
Cdigo fuente 155

Con esto conseguimos dos cosas, actualizar el nombre del autor cuyo cdigo es el especificado a
Miguel, y obtener el mensaje que se muestra como ejecucin del trigger de actualizacin.
Sin embargo, los triggers en SQL Server tienen una serie de limitaciones:
1. No se puede disparar un trigger dentro de otro trigger, ya que dara lugar a un bucle infinito
2. Por esta razn, un trigger no puede ejecutar instrucciones DDL (lenguaje de definicin de
datos)
3. No se pueden ejecutar sentencias como SELECT INTO o de creacin de dispositivos dentro
de un trigger
Del mismo modo, para borrar un trigger, deberemos ejecutar la sentencia DROP TRIGGER trigger.
Por ejemplo, si queremos borrar el trigger anteriormente creado, ejecutaremos el Cdigo
fuente 156

DROP TRIGGER modificacion_autor
Cdigo fuente 156
Ejemplos prcticos de uso de
procedimientos almacenados
Introduccin
Los procedimientos almacenados es una de las principales funcionalidades que ofrece SQL-Server,
que permite al usuario que los usa abstraerse de la complejidad interna que puede encerrar. Por
ejemplo, pueden ser llamados desde otras aplicaciones, con los parmetros adecuados, siendo el
servidor el encargado de realizar las operaciones, descargando de trabajo al cliente.
Los procedimientos almacenados suelen utilizar sentencias de diverso tipo de T_SQL, como pueden
ser las de control de flujo, las de iteracin, etc., que veremos en detalle mediante algunos ejemplos
prcticos.
La sentencia IF ... ELSE
Esta sentencia permite evaluar una expresin y provocar la entrada o ejecucin de un bloque u otro,
dependiendo de que la condicin sea verdadera o falsa.
El Cdigo fuente 157 muestra un procedimiento almacenado encargado de insertar un nuevo tipo de
transporte si no est dado de alta en la base de datos. Para ello se comprueba que el nmero de filas
que devuelve el select sea cero, en cuyo caso la condicin es verdadera, y se ejecutar el insert.


178
CREATE PROCEDURE sp_Insertar_TipoTransporte
@TT_ID int,
@TT_Nombre varchar(40)
AS
if (select count(*) from TipoTransporte where TT_ID = @TT_ID) = 0
insert into TipoTransporte
values (@TT_ID, @TT_Nombre)
Cdigo fuente 157

Probemos a insertar un tipo de transporte que exista, y otro que no exista, para comprobar como
funciona. Para ello ejecutamos el Cdigo fuente 158.

exec sp_Insertar_TipoTransporte 1, 'Metro'
exec sp_Insertar_TipoTransporte 4, 'Tranva'
Cdigo fuente 158

Para comprobar lo que ha ocurrido en la tabla de tipos de transporte, ejecutamos el siguiente cdigo.

SELECT *
FROM TipoTransporte
Cdigo fuente 159

Y como podemos comprobar, slo se ha insertado el ltimo registro. Podemos hacerlo un poco ms
elegante, y devolver un parmetro que nos indique si ha habido error o no.

CREATE PROCEDURE sp_Insertar_TipoTransporte
@TT_ID int,
@TT_Nombre varchar(40),
@error char(1) output
AS
if (select count(*) from TipoTransporte where TT_ID = @TT_ID) = 0 begin
set @error = 'N'
insert into TipoTransporte
values (@TT_ID, @TT_Nombre)
end
else set @error = 'S'
Cdigo fuente 160

Podemos observar una novedad, y es que se ha encerrado entre las palabras begin...end el bloque que
deseamos se ejecute cuando se cumple la condicin, adems del uso de la sentencia set para asignar un
valor a un parmetro o variable. Para ejecutar ahora el procedimiento, necesitamos un parmetro ms
de llamada, que devolver S si se ha producido error, y N si se ha insertado el registro con xito,
cuyo tipo debe coincidir con el tipo del parmetro de salida declarado en el procedimiento.

Grupo EIDOS 20. Ejemplos prcticos de uso de procedimientos almacenados

179
declare @error char(1)
exec sp_Insertar_TipoTransporte 1, 'Metro', @error output
select @error
Cdigo fuente 161

Al ejecutar este cdigo, mostramos el parmetro de salida y vemos como, efectivamente, se devuelve
una S, lo que indica que se ha producido un error. Sin embargo, si ejecutamos este otro cdigo, se
devolver una N, lo que indica que el registro se ha insertado correctamente, al no existir todava en
la base de datos.

declare @error char(1)
exec sp_Insertar_TipoTransporte 5, 'Aeropuerto', @error output
select @error
Cdigo fuente 162

Otro ejemplo nos muestra como comprobar si existen filas para un parmetro determinado, con el fin
de mostrar un mensaje determinado.

CREATE PROCEDURE sp_Hay_Comerciales
@Prv varchar(40)
AS
if (select count(*)
from Provincia
inner join Comercial on Comercial.Prv_ID = Provincia.Prv_ID
and Provincia.Prv_Nombre = @Prv) > 0
print 'Hay comerciales asociados a la provincia de ' + @Prv
else print 'No hay comerciales asociados a la provincia de ' + @Prv
Cdigo fuente 163

En este cdigo podemos comprobar como se obtiene el nmero de registros de un inner join, para
obtener el identificador de la provincia que coincide con el nombre que se pasa como parmetro. Si
dicho atributo es nulo, querr decir, al ser un inner join, que o bien no existe la provincia, o bien no
existe ningn comercial asociado a ella. Ejecutemos el procedimiento para comprobar si existen
comerciales para la provincia de Barcelona.

exec sp_Hay_Comerciales 'Barcelona'
Cdigo fuente 164
La sentencia CASE
Una variante a la instruccin if...else es la sentencia case, muy til sobre todo cuando tenemos muchos
if anidados. Por ejemplo, el cdigo expuesto antes utilizando if...else, equivaldra al siguiente,
utilizando case.

180
CREATE PROCEDURE sp_Hay_Comerciales2
@Prv varchar(40)
AS
select
case (select count(*) from Provincia
inner join Comercial on Comercial.Prv_ID = Provincia.Prv_ID
and Provincia.Prv_Nombre = @Prv)
when 0 then 'No hay comerciales asociados a la provincia de ' + @Prv
else 'Hay comerciales asociados a la provincia de ' + @Prv
end
Cdigo fuente 165
Ejecucin dinmica de sentencias: la instruccin EXEC
Como hemos visto, la instruccin exec se utiliza para ejecutar un procedimiento almacenado, pero no
slo eso, sino que adems sirve para evaluar una expresin de tipo carcter. Por ejemplo, el siguiente
cdigo muestra como ejecutar un select de todas las provincias.

Exec (select * from Provincia)
Cdigo fuente 166

Esto puede resultar muy til para montar sentencias en tiempo de ejecucin, cuyos valores no
conocemos a priori, o para los cuales deseamos realizar un tratamiento distinto dependiendo de los
valores que tomen.
El siguiente cdigo mostrara un procedimiento almacenado que se encarga de realizar bsquedas de
clientes. Recibe dos parmetros, uno es la provincia y otro es el cdigo postal. Si se especifica
nicamente la provincia, se realizar una bsqueda de todos los clientes que sean de esta provincia,
mientras que si especifica el cdigo postal, se realizar una bsqueda, adems, por este atributo.

CREATE PROCEDURE sp_Clientes
@Prv varchar(40),
@CP varchar(5)
AS
-- La variable condicion almacena la clasula where y la variable join los
join
declare @condicion varchar(255)
declare @join varchar(255)
set @condicion = ''
set @join = ''
-- Si se ha especificado la variable @Prv, montar la condicion y el join
if not @Prv is null begin
set @condicion = ' Provincia.Prv_Nombre = ' + '''' + @Prv + ''''
set @join = ' inner join Provincia on Provincia.Prv_ID =
Cliente.Prv_ID'
end
-- Si se ha especificado el cod postal, concatenar la condicin
if not @CP is null begin
if @condicion <> ''
set @condicion = @condicion + ' and '
Grupo EIDOS 20. Ejemplos prcticos de uso de procedimientos almacenados

181
set @condicion = @condicion + ' Cli_CodPostal = ' + '''' + @CP + ''''
end
if @condicion <>
set @condicion = where + @condicion
exec ('select * from cliente ' + @join + @condicion)
Cdigo fuente 167

Manejamos dos variables, una almacenar la condicin, que se ira concatenando, dependiendo de los
parmetros que se indiquen, y otra almacenar el join que se deber realizar con la tabla de provincia,
en el caso de que se especifique como parmetro el nombre de la provincia. Una vez montadas estas
cadenas, se ejecuta la sentencia exec, para evaluar la expresin resultante.
Si ejecutamos el anterior procedimiento almacenado, sin especificar ninguno de los parmetros,
obtendremos todos los clientes

exec sp_Clientes null, null
Cdigo fuente 168

Si especificamos el parmetro provincia = Madrid, obtendremos todos los clientes de la provincia de
Madrid

exec sp_Clientes Madrid, null
Cdigo fuente 169

Si adems especificamos el parmetro codigo postal, obtendremos lo siguiente.

exec sp_Clientes 'Madrid', 28023
Cdigo fuente 170
Conversin de tipos
Muchas veces nos encontraremos la necesidad de convertir un valor de un tipo a otro tipo para operar
con l. Es entonces cuando intervienen dos instrucciones que nos permiten realizar esto. Dichas
instrucciones son cast y convert.
La sintaxis de la expresin cast es la siguiente.
Cast (expresion as tipo)

y la de convert.
Convert (tipo, expresion)


182
Por ejemplo, podemos utilizarlo para convertir un tipo de datos carcter a fecha.

Cast (01/01/01 as datetime)
Cdigo fuente 171

O un carcter a entero

cast (3 as int)
Cdigo fuente 172
La sentencia WHILE
La instruccin while permite iterar un numero de veces que no conocemos a priori, hasta que deje de
cumplirse la condicin boleana. Su sintaxis es la siguiente.
WHILE expresion
sentencias
[BREAK]
[CONTINUE]

La clasula break es optativa y indica al bucle que deje de ejecutarse, mientras que la clasula
continue, que tambin es optativa, indica al bucle que se reinicie.
En el siguiente ejemplo, se recorre los comerciales, mientras que la categora sea distinta de 6, y va
duplicando la misma, hasta que alguno supera el valor de 6.

CREATE PROCEDURE sp_ActualizaComercial
AS
WHILE (SELECT Com_Categoria FROM Comercial) <> '6'
BEGIN
UPDATE Comercial
SET Com_Categoria = cast(Com_Categoria as int) * 2
IF (SELECT MAX(Com_Categoria) FROM Comercial) > 6
BREAK
ELSE
CONTINUE
END
Cdigo fuente 173
Triggers en SQL-Server 2000
Introduccin
Como ya se ha comentado, los triggers o desencadenadores son una especie de procedimientos
almacenados, que se ejecutan cuando ocurre una accin dentro de la base de datos. As, si por ejemplo
se ejecuta una insercin, una actualizacin, o un borrado de una tabla, se ejecutaran las sentencias
definidas para el trigger en concreto de esa tabla especfica.
Recordamos cual es su sintaxis:
CREATE TRIGGER nombre
ON tabla
FOR [DELETE | INSERT | UPDATE]
AS
sentencias

Las palabras reservadas DELETE, INSERT y UPDATE corresponden a cada una de las acciones para
las cuales se puede definir un desencadenador dentro de la tabla especificada.
El bloque de sentencias permite prcticamente cualquier tipo de ellas dentro del lenguaje T-SQL, pero
con ciertas limitaciones. Por ejemplo, no se podr utilizar la sentencia select, ya que un trigger no
puede devolver datos al usuario, sino que simplemente se ejecuta para cambiar o comprobar los datos
que se van a insertar, actualizar o borrar.


184
Las tablas deleted e inserted
Dentro de la definicin de un trigger, podemos hacer referencia a un par de tablas lgicas, cuya
estructura es similar a la tabla donde se esta ejecutando el trigger; es decir, es una copia de la tabla en
la cual se van a insertar o borrar los datos, y que contiene, precisamente, los datos que van a ser
aadidos o borrados.
La utilidad de estas dos tablas es la de realizar comprobaciones entre los datos antiguos y los nuevos.
As, por ejemplo, si queremos recuperar los datos de la tabla que estamos borrando, dentro del trigger,
se deber ejecutar el siguiente cdigo:

SELECT *
FROM deleted
Cdigo fuente 174
Tipos de desencadenadores
SQL-Server permite la definicin de varios tipos de triggers, entre los cuales cabe destacar los
siguientes:
Desencadenadores mltiples: para una misma tabla, se pueden definir distintos triggers para la
misma accin, es decir, si definimos un trigger para insert, y resulta que dicha tabla ya tena
definido un trigger para esa misma accin, se ejecutarn ambos triggers cuando ocurra dicho
evento sobre la tabla.
Desencadenadores recursivos: se permite la recursividad entre las llamadas a los triggers, es
decir, un trigger puede llamar a su vez a otro, bien de forma directa, bien de forma indirecta.
Desencadenadores anidados: si un trigger cambia una tabla en la que se encuentra definido otro
trigger, se provoca la llamada de este ltimo que, si a su vez vuelve a modificar otra tabla, puede
provocar la ejecucin de otro trigger, y as sucesivamente. Si se supera el nivel de anidamiento
permitido, se cancelar la ejecucin de los triggers.
Limitaciones de los triggers
Aunque ya se han comentado algunas de las limitaciones a la hora de programar triggers, veamos en
detalle las restricciones que implica la definicin de triggers:
Un trigger slo se puede aplicar a una tabla
Aunque un trigger se defina dentro una sola base de datos, puede hacer referencia a objetos que se
encuentran fuera de la misma
La misma accin del desencadenador puede utilizarse para definir ms de un trigger sobre la
misma tabla
La opcin SET elegida dentro de la ejecucin de un desencadenador, volver a su estado
previamente definido una vez concluya la ejecucin del mismo
Grupo EIDOS 21. Triggers en SQL Server 2000

185
As mismo, no se permite la utilizacin de las sentencias del DDL dentro de la definicin de un
trigger
En una vista no se puede utilizar un desencadenador
Resolucin diferida de nombres
La resolucin diferida de nombres es una utilidad que permite escribir triggers que hagan referencia a
tablas que no existen en el momento de la compilacin. Por ejemplo, el siguiente cdigo hace
referencia a una tabla x, que no existe en el momento de escribir el trigger.

CREATE TRIGGER trigger1
on authors
FOR INSERT, UPDATE, DELETE
AS
SELECT a.au_lname, a.au_fname, x.info
FROM authors a INNER JOIN x
ON a.au_id = x.au_id
GO
Cdigo fuente 175
Ejemplos
Veamos a continuacin algunos ejemplos que complementen lo visto hasta ahora. El siguiente cdigo,
muestra la forma de enviar un mensaje de correo electrnico a una persona, cuando se aade una
nueva oferta.

CREATE TRIGGER enviar_correo
ON Oferta
FOR INSERT
AS
EXEC master..xp_sendmail 'Pepe',
'Tenemos una nueva oferta en nuestra base de datos.'
GO
Cdigo fuente 176

Sin embargo, si queremos que se enve el mensaje cada vez que se cambia algo en la tabla de ofertas,
deberemos reescribir el trigger para las acciones update y delete, como se muestra en el siguiente
cdigo.

DROP TRIGGER enviar_correo
GO
CREATE TRIGGER enviar_correo
ON Oferta
FOR INSERT, UPDATE, DELETE
AS
EXEC master..xp_sendmail 'Pepe',

186
'La tabla de ofertas ha cambiado'
GO
Cdigo fuente 177

En el Cdigo fuente 178, se muestra como crear un trigger que, utilizando la tabla inserted para
comprobar los valores que se van a aadir o modificar, posibilite la cancelacin de la accin, si el
nivel del trabajo no est dentro de los valores permitidos.

CREATE TRIGGER empleado_modificar
ON employee
FOR INSERT, UPDATE
AS
/* Obtener el nivel para el trabajo actual */
DECLARE @min_lvl tinyint,
@max_lvl tinyint,
@emp_lvl tinyint,
@job_id smallint
SELECT @min_lvl = min_lvl,
@max_lvl = max_lvl,
@emp_lvl = i.job_lvl,
@job_id = i.job_id
FROM employee e INNER JOIN inserted i ON e.emp_id = i.emp_id
JOIN jobs j ON j.job_id = i.job_id
IF (@job_id = 1) and (@emp_lvl <> 10)
BEGIN
RAISERROR ('Debe especificar el nivel 10 para el trabajo 1', 16, 1)
ROLLBACK TRANSACTION
END
ELSE
IF NOT (@emp_lvl BETWEEN @min_lvl AND @max_lvl)
BEGIN
RAISERROR ('El nivel para el trabajo:%d debe estar entre %d y %d.',
16, 1, @job_id, @min_lvl, @max_lvl)
ROLLBACK TRANSACTION
END
Cdigo fuente 178

Primero declaramos las variables min_lvl y max_lvl, que almacenarn los valores mnimo y mximo
permitidos para un trabajo, emp_lvl, que almacenar el nivel para el empleado, y job_id que almacena
el identificador del trabajo que se va a actualizar.
A continuacin realizamos un join entre la tabla de empleados y la tabla inserted o, lo que es lo
mismo, entre la tabla de empleados tal y como est antes de ejecutar el trigger, y la tabla de empleados
tal y como quedara despus de ejecutarlo (en otras palabras, entre la antigua y la nueva), y a
continuacin con la tabla de trabajos. Todo esto sirve para encontrar los valores de la tabla de trabajos
que corresponden al trabajo que vamos a asignar al empleado.
Ahora se comprueba si el trabajo que estamos asignando es el 1, en cuyo caso el valor para el nivel
debera ser 10. Para ello comprobamos esta situacin mediante un if y, en caso de que sea verdadero,
se lanza un error con la sentencia RAISERROR, y se cancela la transaccin con ROLLBACK
TRANSACTION.
Grupo EIDOS 21. Triggers en SQL Server 2000

187
En otro caso se comprueba que el nivel de la tarea est dentro de los lmites permitidos para el
empleado. Si esto no se cumple se volver a lanzar un error, y se cancelar la transaccin.
Para los desconocedores del lenguaje C, quiz la ltima sentencia RAISERROR no les sea demasiado
clara. Destacar, simplemente, que cada %d que aparece dentro de la cadena de texto ser sustituido
respectivamente por el valor de cada una de las tres ltimas variables que aparecen dentro de dicha
sentencia.
Seguridad
Introduccin
El de la seguridad es un tema muy importante, para la proteccin de la informacin, sobre todo en
entornos grandes, donde la amenaza de potenciales accesos indebidos es muy grande.
Podemos hablar de seguridad a dos niveles:
Seguridad fsica: entendemos por seguridad fsica aquella que persigue salvaguardar los datos
de agresiones externas, como por ejemplo la destruccin de la base de datos, debido a aspectos
fsicos, como por ejemplo un incendio o una inundacin.
Seguridad lgica: la seguridad lgica afecta a la proteccin de los datos de accesos u
operaciones no deseados, como por ejemplo, una consulta a informacin no autorizada por
parte de un usuario, el borrado de una tabla, o parte de sus atributos, etc.
En este captulo nos centraremos en la seguridad lgica, ya que la seguridad fsica afecta a aspectos de
administracin (copias de seguridad, mantenimientos de dispositivos duplicados con mirror, etc.) que
escapan a los objetivos del presente curso.
Concesin de privilegios
SQL Server mantiene un sistema de perfiles, en el que la principal divisin se establece entre el
administrador del sistema y el resto de usuarios. El administrador del sistema acta al nivel de
superusuario, y puede realizar "casi" cualquier operacin, mientras que un usuario corriente slo podr


190
realizar operaciones que afecten a sus objetos, o a los objetos que le permita el administrador u otro
usuario.
Los objetos de SQL Server (tablas, bases de datos, ...) tienen un propietario, que normalmente suele
ser el superusuario, o el usuario que lo haya creado. En principio, si otro usuario desea acceder a dicho
objeto, no podr hacerlo, a menos que el propietario o el administrador le d permiso. Los permisos se
pueden establecer en el mbito de un usuario (conceder un privilegio a un usuario) o en el mbito de
grupo o pblico (accesible por todos).
Del mismo modo, los permisos pueden ser propagados en cascada, esto es, un usuario puede dar
permiso a otro usuario, para que ste a su vez pueda dar permiso a otros.
La sentencia que permite otorgar privilegios es la siguiente:
GRANT sentencia TO usuarios

Por ejemplo, si queremos otorgar el permiso de crear bases de datos y tablas al usuario Pepe,
deberemos escribir la sentencia que muestra Cdigo fuente 179

GRANT CREATE DATABASE, CREATE TABLE TO Pepe
Cdigo fuente 179

Si queremos otorgar todos los permisos a todos los usuarios, deberemos escribir la sentencia que
aparece en el Cdigo fuente 180.

GRANT ALL TO PUBLIC
Cdigo fuente 180

Cuidado con esta sentencia ya que es muy peligroso dejar que cualquier usuario haga lo que quiera. De
todas maneras, este control corresponde al administrador del sistema.
Del mismo modo se pueden establecer privilegios sobre los objetos, en lugar de sobre las acciones. En
este caso, la sintaxis es la mostrada
GRANT permisos (columnas) ON tabla TO usuario

La sentencia GRANT permite establecer los permisos deseados (insercin, borrado, actualizacin)
sobre una serie de atributos de una tabla, a unos determinados usuarios. No slo se pueden conceder
permisos en el mbito de tabla, sino tambin en el mbito de vista, o procedimientos almacenados.
Por ejemplo, si deseamos que todos los usuarios puedan consultar la tabla de autores, deberemos
escribir lo que indica el Cdigo fuente 181.

GRANT SELECT ON authors TO PUBLIC
Cdigo fuente 181
Grupo EIDOS 22. Seguridad

191

Con esto lo que hacemos es conceder el permiso SELECT sobre la tabla Authors, a todos los usuarios.
Si queremos restringir el SELECT al campo au_lname, deberemos ejecutar el Cdigo fuente 182.

GRANT SELECT (au_lname) ON authors TO PUBLIC
Cdigo fuente 182

Y si deseamos que adems de consultar se pueda actualizar, la sentencia en cuestin es la que muestra
el Cdigo fuente 183.

GRANT SELECT, UPDATE ON authors TO PUBLIC
Cdigo fuente 183

Si queremos propagar los privilegios, debemos adjuntar la opcin WITH GRANT OPTION. Por
ejemplo, si queremos conceder el privilegio de ejecucin de un procedimiento almacenado a un
usuario, y que ste a su vez pueda conceder este privilegio a otros usuarios, debemos escribir la
sentencia mostrada en el Cdigo fuente 184.

GRANT EXECUTE ON procedure TO usuario WITH GRANT OPTION
Cdigo fuente 184
Revocacin de privilegios
La sentencia homloga a la concesin de privilegios es REVOKE. Con esta sentencia podemos quitar
permisos a los usuarios sobre un objeto, o para ejecutar ciertas sentencias. La sintaxis para quitar
permisos sobre la ejecucin de sentencias es la siguiente:
REVOKE sentencia FROM usuarios

donde sentencia especifica aquellas cuyos permisos se revocan, y usuarios establece una lista de
usuarios a los cuales se les aplicar dicha sentencia. Por ejemplo, si ejecutamos el Cdigo fuente 185.

REVOKE CREATE DATABASE FROM alberto
Cdigo fuente 185

Estamos impidiendo al usuario alberto la posibilidad de crear bases de datos.
Para revocar todos los permisos, deberemos especificar ALL como sentencia a aplicar.

192
As mismo, para que la sentencia tenga efecto para todos los usuarios de la base de datos, deberemos
establecer public en la lista de usuarios. Por ejemplo, el Cdigo fuente 186 revoca todos los permisos
a todos los usuarios.

REVOKE ALL FROM PUBLIC
Cdigo fuente 186

La sentencia para aplicar revocacin de permisos a objetos aparece en el Cdigo fuente 187.

REVOKE [GRANT OPTION FOR] permisos
[(atributos)] ON tabla FROM usuarios [CASCADE]
AS papel
Cdigo fuente 187

La opcin GRANT OPTION FOR es opcional, y permite revocar la propagacin en cadena de
permisos a usuarios, es decir, stos conservarn los suyos, pero no podrn autorizar a terceros. La
opcin permisos permite especificar los permisos que se revocarn, pudiendo restringirlos a una serie
de atributos o a una o varias tablas. La opcin CASCADE es opcional, y permite revocar privilegios
en cascada, es decir, a los usuarios especificados, y a todos los que stos concedieron permisos. Por
ltimo, la opcin papel permite eliminar la ambigedad que se puede originar cuando un usuario
pertenece a varios grupos, o tiene varios perfiles.
Por ejemplo, si queremos revocar los permisos de insercin de filas en la tabla autores, al usuario
Pepe, escribimos lo que indica el Cdigo fuente 188.

REVOKE INSERT ON authors FROM Pepe
Cdigo fuente 188

Si no queremos que dicho usuario consulte los atributos au_lname y au_fname de dicha tabla, la
sentencia a ejecutar aparece en el Cdigo fuente 189.

REVOKE SELECT (au_lname, au_fname) ON authors FROM Pepe
Cdigo fuente 189

Y si queremos revocar dicho permiso no slo al usuario Pepe, sino tambin a todos los usuarios a los
que ste a otorgado dicho permiso, ejecutaremos el Cdigo fuente 190.

REVOKE SELECT (au_lname, au_fname) ON authors FROM Pepe CASCADE
Cdigo fuente 190
Grupo EIDOS 22. Seguridad

193
Denegacin de permisos
Otra opcin es la de denegar un permiso a uno o varios usuarios. Lo que permite es que dichos
usuarios no obtengan privilegios, hasta que no se revoque dicha denegacin. La sintaxis para denegar
permisos es la siguiente:
DENY sentencia TO usuarios

Y para objetos:
DENY permisos [(atributos)] ON tabla TO usuarios [CASCADE]

El funcionamiento es similar al ya visto en las anteriores sentencias.
Si por ejemplo, tenemos un usuario de la base de datos un tanto conflictivo, y no queremos que cree
bases de datos, bastar con revocarle el privilegio a hacerlo. Pero el problema surge cuando el
administrador del sistema se olvida de este detalle y, por error, le concede dicho permiso. Para evitar
que esto suceda, lo recomendable es denegar el permiso a dicho usuario.

DENY CREATE DATABASE TO conflictivo
Cdigo fuente 191

De esta manera, mientras no se revoque dicha denegacin, no se le podrn conceder privilegios para la
creacin de bases de datos a dicho usuario. Del mismo modo podemos actuar para denegarle el
permiso de acceder a determinados campos de una tabla, como por ejemplo a los atributos au_lname y
au_fname de la tabla de autores.
DENY SELECT (au_lname, au_fname) ON authors TO conflictivo
Cdigo fuente 192
Mantenimiento de vistas
Otro mtodo para controlar la seguridad y el acceso indebido a los datos almacenados, consiste en
mantener vistas de la base de datos. Una vista es un conjunto de informacin que es accesible por uno
o varios usuarios. Como ya se vio en la parte anterior sobre diseo de bases de datos, las vistas se
corresponden con el esquema externo de la base de datos, es decir la porcin de la base de datos que es
accesible a los usuarios. Tambin se dijo que poda haber ms de un esquema externo, lo que nos lleva
a pensar que la base de datos puede mantener varias vistas a la vez.
El lector se preguntar por qu una vista impide realizar accesos indebidos?. Pues bien, la respuesta
es fcil. Puesto que una vista se puede contemplar como una consulta a una parte de la informacin, si
queremos que un usuario no acceda a determinados datos, le daremos vistas que no consulten dicha
informacin. Corresponde al administrador en este caso el estudio de las consultas que se pueden
realizar con relacin a los usuarios del sistema, y otorgar permisos sobre las vistas a stos.
La sintaxis del comando para la creacin de vistas es la siguiente:

194
CREATE VIEW vista [(atributos)] [WITH ENCRYPTION] AS
sentencia [WITH CHECK OPTION]

La opcin WITH ENCRYTION permite encriptar, es decir, ocultar, el cdigo de la vista, mientras que
la opcin WITH CHECK OPTION permite hacer visibles las modificaciones realizadas tras la
ejecucin de la vista.
Por ejemplo, si queremos crear una vista sobre el atributo au_lname de la tabla authors, escribimos el
Cdigo fuente 193.

CREATE VIEW autores (au_lname) AS
Cdigo fuente 193

Si un usuario quiere consultar ahora los autores de la base de datos, deber ejecutar la vista,
escribiendo la sentencia que muestra el Cdigo fuente 194

SELECT * FROM autores
Cdigo fuente 194
Recomendaciones
Por ltimo, existen una serie de recomendaciones, que todo administrador que se precie debe tener en
cuenta a la hora de implementar la seguridad de una base de datos:
Proporcionar un nico identificador a cada usuario, para de esta manera saber en todo
momento quien est haciendo qu.
Establecer perfiles y grupos de usuarios, de forma jerrquica incluso, ya que permite
establecer ms fcilmente los niveles de seguridad.
Proporcionar a los usuarios procedimientos almacenados para la insercin, actualizacin y/o
borrado de filas, ya que permite controlar mejor los usos indebidos de estas sentencias.
Usar triggers para evitar ciertas operaciones no deseadas.
Ejemplo prctico de implementacin
Introduccin
En este captulo, estudiaremos un ejemplo, para recopilar los conocimientos aprendidos a lo largo del
curso. El problema en s es mantener una base de datos de ornitologa (ciencia que estudia las aves).
Se desea almacenar la informacin de cada una de las especies del pas. De cada especie se quiere
conocer el nombre de la misma, el nombre cientfico, la clase a la que pertenece y el tipo de rbol en el
que anida, as como si es un ave migratoria o no. De cada clase de rbol, se desea conocer su nombre,
el tipo de hoja, y la regin de la cual es autctono.
Por consiguiente, tenemos las siguientes entidades:
ave: cod_ave, nombre, nom_cientifico, clase, migratoria, observaciones
rbol: cod_arbol, nombre, tipo_hoja
regin: cod_region, desc_region
Las relaciones que tenemos son las siguientes:
ave-rbol: un ave puede anidar en varios tipos de rboles, y en un rbol pueden anidar varias
especies (N-M).
rbol-regin: un rbol puede ser autctono de varias regiones, y en una regin puede haber
distintas clases de rboles (N-M).


196
Con la anterior informacin, podemos obtener el diagrama entidad-relacin que vemos en la Figura
94.

Figura 94

Una vez realizado el diseo conceptual, el siguiente paso es realizar el diseo lgico, cuya primera
etapa es el paso a tablas. Cada entidad genera una tabla, con sus atributos, y las relaciones N-M
generan tambin tabla, con las claves de ambas entidades como atributos. Con esto, nos queda el
esquema lgico que muestra la Figura 95.

Figura 95

El siguiente paso en el diseo es realizar el diseo fsico, ya que en nuestro caso no se aplicarn
mtodos de normalizacin o particionamiento. Lo que realizaremos es codificar las instrucciones
necesarias en Transact SQL, para obtener el esquema fsico. Destacar que lo que aqu entendemos por
diseo fsico, tambin engloba al diseo lgico especfico, al usar un SGBD concreto para la
implementacin.
Para implementar el esquema en Transact SQL, utilizaremos el Query Analizer de SQL Server.
Lenguaje de definicin de datos
Lo primero que haremos ser crear la base de datos, a la que denominaremos ornitologa, para lo cual
escribimos el Cdigo fuente 195.

CREATE DATABASE ornitologia
Cdigo fuente 195

Una vez creada la base de datos, nos conectamos a ella, seleccionndola de la lista desplegable que
aparece en la parte superior derecha del Query Analizer.
Grupo EIDOS 23. Ejemplo prctico de implementacin

197
A continuacin crearemos las tablas obtenidas en el esquema lgico. Empezaremos por crear la tabla
ave.

CREATE TABLE ave (
cod_ave smallint NOT NULL,
nombre varchar(30) NOT NULL,
nom_cientifico varchar(30),
clase varchar(10),
migratoria bit)
Cdigo fuente 196

En la anterior sentencia cabe destacar que los atributos cod_ave y nombre han sido declarados como
no nulos, es decir, no se podr insertar filas que no tengan valores nulos para dichos atributos. Para
especificar si un ave es migratoria o no, se utilizar un campo bit, es decir, un 0 para indicar que el ave
no es migratoria, y un 1 si lo es. Anlogamente, creamos la tabla arbol.

CREATE TABLE arbol (
cod_arbol smallint NOT NULL,
nombre varchar(30) NOT NULL,
tipo_hoja varchar(10))
Cdigo fuente 197

Seguimos con la tabla de regiones.
CREATE TABLE region (
cod_region smallint NOT NULL,
desc_region varchar(30) NOT NULL)
Cdigo fuente 198

Y por ltimo las tablas que las relacionan, que son ave_arbol, y arbol_region:

CREATE TABLE ave_arbol (
cod_ave smallint NOT NULL,
cod_arbol smallint NOT NULL)
CREATE TABLE arbol_region (
cod_arbol smallint NOT NULL,
cod_region smallint NOT NULL)
Cdigo fuente 199

Una vez creadas las tablas, el siguiente paso es crear los ndices para ellas. Empezaremos por crear un
ndice nico que ser la clave de la tabla ave, al que llamaremos clave, y que utilizar el campo
cod_ave.


198
ALTER TABLE ave ADD CONSTRAINT clave_av PRIMARY KEY (cod_ave)
Cdigo fuente 200
Anlogamente hacemos con las dems tablas, donde los ndices de clave nica sern por cod_arbol
para la tabla arbol, por cod_regin para la tabla regin, por cod_arbol y cod_region para la
tabla.arbol_region, y por cod_ave y cod_arbol para la tabla ave_arbol:

ALTER TABLE arbol ADD CONSTRAINT clave_ab PRIMARY KEY (cod_arbol)
ALTER TABLE region ADD CONSTRAINT clave_re PRIMARY KEY (cod_region)
ALTER TABLE ave_arbol ADD CONSTRAINT clave_aa PRIMARY KEY (cod_ave,cod_arbol)
ALTER TABLE arbol_region ADD CONSTRAINT clave_ar PRIMARY KEY (cod_arbol,cod_region)
Cdigo fuente 201

Oh, !vaya!, nos hemos olvidado de definir un atributo para la tabla ave. Pero eso no es problema, ya
que podemos modificar cmodamente el esquema de dicha tabla, mediante la sentencia ALTER, para
introducir un nuevo campo.

ALTER TABLE ave ADD observaciones text NULL
Cdigo fuente 202

Por ltimo, es labor del administrador el decidir a quien y sobre que objetos otorga qu permisos.
Nosotros, de momento, crearemos una vista para consultar todas las aves que son migratorias

CREATE VIEW migratorias AS
SELECT nombre FROM ave WHERE migratoria = 1
Cdigo fuente 203
Lenguaje de manipulacin de datos
Hasta ahora hemos estado utilizando el Lenguaje de Definicin de Datos, para definir el esquema. A
continuacin utilizaremos el Lenguaje de Manipulacin de Datos para introducir informacin en el
esquema, y para realizar algunas consultas. Empezaremos aadiendo los siguientes datos:
Tabla ave

Cod_ave Nombre Nom_cientifico Clase Migratoria Observaciones
1 Flamenco Zancuda Si Migran en grupo
hacia lugares clidos
2 Pato salvaje Palmpedo No

199
3 Mirlo
Blanco
Si Emite un sonido muy
peculiar
4 Golondrina Golondrina
comn
Si Famosas por los
versos de Becquer
Tabla 33

INSERT INTO ave (cod_ave, nombre, clase, migratoria, observaciones)
VALUES (1, 'Flamenco', 'Zancuda', 1, 'Migran en grupo hacia lugares clidos')
INSERT INTO ave (cod_ave, nombre, clase, migratoria)
VALUES (2, 'Pato salvaje', 'Palmipedo', 0)
INSERT INTO ave (cod_ave, nombre, migratoria, observaciones)
VALUES (3, 'Mirlo Blanco', 1, 'Emite un sonido muy peculiar')
INSERT INTO ave (cod_ave, nombre, nom_cientifico, migratoria, observaciones)
VALUES (4, 'Golondrina', 'Golondrina comn', 1, 'Famosas por los versos de
Becquer')
Cdigo fuente 204

Tabla rbol

Cod_arbol Nombre Tipo_hoja
1 Encina Caduca
2 Roble Perenne
3 Naranjo Caduca
4 Pino Perenne
Tabla 34

INSERT INTO arbol (cod_arbol, nombre, tipo_hoja)
VALUES (1, 'Encina', 'Caduca')
VALUES (2, 'Roble', 'Perenne')
VALUES (3, 'Naranjo', 'Caduca')
VALUES (4, 'Pino', 'Perenne')
Cdigo fuente 205


200
Tabla regin

Cod_region Desc_region
1 Centro
2 Sur
3 Nor-noroeste
4 Pirineos
5 Levante
Tabla 35

INSERT INTO region (cod_region, desc_region)
VALUES (1, 'Centro')
VALUES (2, 'Sur')
VALUES (3, 'Nor-noroeste')
VALUES (4, 'Pirineos')
VALUES (5, 'Levante')
Cdigo fuente 206

Supongamos ahora que nos dicen que puede haber pinos en las regiones centro, nor-noroeste y
Pirineos, naranjos en la regin Levante, encinas en las regiones centro, sur y nor-noroeste y robles en
la regin centro. Lo que tenemos que hacer es dar de alta estas filas en la tabla arbol_region, con los
valores correspondientes a cada cdigo de arbol y regin.

INSERT INTO arbol_region (cod_arbol, cod_region)
VALUES (4, 1)
VALUES (4, 3)
VALUES (4, 4)
VALUES (3, 5)
VALUES (1, 1)
VALUES (1, 2)
VALUES (1, 3)
VALUES (2, 1)
Cdigo fuente 207


201
Supongamos ahora que nos dicen que el mirlo blanco anida en los naranjos y en los pinos, y que los
patos salvajes anidan en los estanques donde preferentemente haya encinas.
Lo que hay que hacer es crear las filas correspondientes a cada uno de los cdigos en la tabla
ave_arbol.

INSERT INTO ave_arbol (cod_ave, cod_arbol)
VALUES (3, 3)
VALUES (3, 4)
VALUES (2, 1)
Cdigo fuente 208

Puesto que de momento no hemos encontrado ningn mirlo blanco, cambiaremos este ave por el mirlo
comn. Para ello debemos actualizar la fila correspondiente, con la sentencia que aparece en el Cdigo
fuente 209.

UPDATE ave SET nombre = 'Mirlo comn'
WHERE nombre = 'Mirlo blanco'
Cdigo fuente 209

Supongamos ahora que queremos realizar las siguientes consultas, cuyas sentencias se especifican a
continuacin:
Todos los rboles de la regin centro:

SELECT nombre FROM arbol, arbol_region, region
WHERE region.desc_region = 'centro'
AND region.cod_region = arbol_region.cod_region
AND arbol_region.cod_arbol = arbol.cod_arbol
Cdigo fuente 210

Lo que hace la anterior sentencia es obtener el atributo desc_arbol de la tabla arbol. Para ello,
primero se pone la condicin de que la regin debe ser centro.
Con las filas obtenidas, hacemos un join contra la tabla arbol_region, para obtener el cdigo
de los rboles cuya regin es centro. Si ahora queremos obtener la descripcin del rbol,
deberemos realizar otro join contra la tabla rbol. El resultado obtenido son los rboles pino,
encina y roble.
El nmero de aves que son migratorias. Para ello deberemos contar todas las filas de la tabla
ave, cuyo atributo migratoria tenga el valor true.


202
SELECT count(*) FROM ave WHERE migratoria = 1
Cdigo fuente 211

El resultado obtenido es el de 3 aves.
El nombre de las aves que anidan en rboles de hoja caduca ordenados alfabticamente. Lo
que debemos hacer es seleccionar primero todas las filas cuyo atributo tipo_hoja para luego
hacer el join de estas filas con la tabla ave_arbol por el campo cod_arbol, para obtener as el
cdigo de las aves que anidan en dichos rboles. Acto seguido, si queremos obtener el nombre
de las aves, deberemos realizar un join de las filas obtenidas, con la tabla ave, por el atributo
cod_ave y proyectar sobre nombre. La anterior explicacin se resume en la sentencia mostrada
en el Cdigo fuente 212.

SELECT ave.nombre FROM arbol, ave_arbol, ave
WHERE arbol.tipo_hoja = 'caduca'
AND arbol.cod_arbol = ave_arbol.cod_arbol
AND ave_arbol.cod_ave = ave.cod_ave
ORDER BY ave.nombre
Cdigo fuente 212

Como resultado del Cdigo fuente 212, obtenemos que dichas aves corresponden al mirlo blanco y
al pato salvaje
Si ahora queremos consultar todas las aves que son migratorias, podemos aprovechar la vista anterior,
para hacerlo ejecutamos el Cdigo fuente 213.

SELECT * FROM migratorias
Cdigo fuente 213
Presente y futuro de las bases de datos
La evolucin de las bases de datos en los ltimos aos, ha permitido el afianzamiento de un modelo
que se ha tomado como base de la prctica totalidad de los SGBD existentes en la actualidad, el
modelo relacional. Sin embargo, no ha sido sino hasta hace unos pocos aos cuando este modelo vio la
luz, como consecuencia de una necesidad de simplificacin de los primeros modelos que se usaron
como base.
Como ya se ha comentado, los primeros modelos que surgieron fueron el jerrquico y el modelo en
red. El primero naci como una conceptualizacin de la forma de entender las relaciones entre los
objetos, es decir, una clasificacin natural, que permita navegar entre ellos para obtener la
informacin que se necesitaba.
Para que el lector lo comprenda mejor, era una especie de clasificacin del modo pais comunidad
provincia localidad o empresa departamento empleado. Las relaciones entre los objetos se
establecan de una manera natural, mediante referencias a los mismos.
El modelo en red naci como una ampliacin del modelo jerrquico, en el cual ya no se tienen rboles,
sino grafos, lo cual dificulta ampliamente la definicin y el manejo del esquema. Sera algo del estilo
empresa empleado empresa ....
Sin embargo, la evolucin de estos modelos, dieron lugar a uno nuevo, el relacional, cuya simplicidad
y potencia revolucionaron el mercado de las bases de datos. A pesar de ello, la evolucin sigui otra
rama alternativa, dando lugar a las denominadas bases de datos orientadas a objetos. Aunque fueron
muchos los que apostaron por stas, la realidad es que en la actualidad su uso no supera el 5% de la
cuota de mercado con respecto al modelo relacional.


204
Debido a lo anterior, fueron muchos los que pensaron que no sera mala idea unir lo mejor de ambos
modelos: el relacional y el orientado a objetos. As nace el modelo objeto-relacional. Tomando como
base el relacional, une a ste la funcionalidad que ofrece la orientacin a objetos. De esta forma se
tienen relaciones en forma de tablas, cuyos atributos pueden ser a su vez referencias a objetos, adems
de incorporar sus propios mtodos. Por ejemplo, se puede tener el atributo domicilio que se puede
descomponer en calle, provincia y localidad, que tendra el mtodo alta(), que se ejecutara cada vez
que se da de alta un nuevo domicilio.
Como el lector ya habr podido comprobar, en estos modelos ni siquiera se cumple la 1FN, lo cual
desbarata prcticamente todo el proceso de normalizacin. Adems, se necesitar un lenguaje especial
para definir y manejar la informacin. Surge entonces el SQL:1999 como lenguaje estndar para el
acceso y definicin de este tipo de esquemas.
Por otro lado, no paran de surgir nuevos estudios y propuestas de modelos que amplan los ya
existentes. As por ejemplo, podemos encontrar bases de datos espaciales (para manejo de informacin
en tres dimensiones), bases de datos fuzzy (o que manejan informacin imprecisa, como por ejemplo
alto, joven, caro, y que ya disponen de su propio lenguaje), y as un sinfn de posibilidades.
Sin embargo, lo que ms expectacin esta suscitando actualmente, y que se prev tenga un mayor
impacto si cabe, en un futuro no muy lejano, es el data warehousing y el data mining.
Por data warehousing se entiende el almacenamiento masivo de los datos que gestiona una empresa,
que debido al avance y mejora de los SGBD actuales, permite una mejor gestin de los mismos. As
por ejemplo, cabe imaginar, por ejemplo, una empresa que dispone de cantidades ingentes de
informacin (empleados, clientes, proveedores, ventas, compras), que en un principio es gestionada
desde mbitos distintos, y puede no tener relacin ninguna entre s (cada departamento manejara
nicamente la informacin relevante al mismo). Pues bien, el concepto de data warehousing (en lo
sucesivo DW) se refiere a la posibilidad de integrar toda esta informacin, que aparece dispersa en el
mbito del negocio, para su mejor gestin, de una forma ms eficaz y eficiente, de tal manera que
dicha informacin pueda ser utilizada ms provechosamente.
De esta forma se puede obtener, mediante herramientas especficas (OLAP, ROLAP, etc.) informacin
de una manera ms til. Por ejemplo, se pueden utilizar los denominados data marts, que son una
especie de vistas con la informacin que interesa obtener, con la peculiaridad que el acceso se realiza
en varias dimensiones de una forma ms eficaz (por ejemplo las ventas por proveedores en cada
regin).
En cambio, este proceso, como puede imaginar el lector, es una tarea ardua, tediosa y difcil, que
implica una carga, filtrado y proceso de los datos, para evitar incoherencias, duplicidades e
informacin irrelevante, y se resume en la Figura 96.
Una vez que se tiene el DW, se pueden aplicar procesos que permitan una obtencin de informacin
aadida, que no aparece de manera explcita en el mismo. Una de las tcnicas ms importantes de
extraccin de informacin es la denominada data minning o minera de datos (en lo sucesivo DM).
Como su propio nombre indica, consiste en la navegacin a travs de los datos para inferir
conocimiento mediante tcnicas de Inteligencia Artificial, que no se encuentra de manera explcita.
Esta tcnica es muy til sobre todo en el mbito del marketing y publicidad, para obtener, por ejemplo,
posibles clientes potenciales para una campaa comercial, o personalizar el tipo de informacin que un
cliente puede recibir, entre otras.
Grupo EIDOS 24. Presente y futuro de las bases de datos

205

Figura 96

Ya existen en el mercado varios productos que soportan tanto el DW como el DM, pero que, debido a
su elevado precio, hacen que todava sea un mercado que no se encuentre al alcance de todo el mundo,
pero que se espera crezca positivamente en un futuro no muy lejano.
Sin embargo, SQL Server 2000 ya nos permite adentrarnos es este mundo, ofrecindonos diversas
posibilidades de las ya mencionadas, como resume la Figura 97.

Figura 97
Diseo conceptual con Power Designor
Introduccin
Empezaremos dando respuesta a la pregunta "qu es Power Designor?". Pues bien, se puede
decir que Power Designor es una herramienta CASE para el diseo de bases de datos. Una
herramienta CASE es aquella que permite al usuario la realizacin de unas determinadas tareas de
forma fcil y precisa. En nuestro caso, Power Designor permite al usuario establecer el diseo de un
esquema relacional, de forma clara y sencilla, evitndole tareas engorrosas, como el paso del diseo
conceptual al fsico, etc.
Power Designor abarca dos de las tres grandes etapas del diseo de un esquema relacional:
1. El diseo conceptual
2. El diseo fsico
El diseo conceptual permite establecer la definicin de las tablas, las relaciones entre stas y su
cardinalidad, los atributos y sus tipos, las claves, etc., mientras que el diseo fsico comprende la
definicin de ndices, la redundancia controlada de datos, y en general todos los aspectos relacionados
con esta fase de diseo. Adems nos permite pasar fcilmente del esquema conceptual, al esquema
fsico, y realizar ingeniera inversa, es decir, obtener el esquema conceptual de una base de datos, con
slo conocer su esquema fsico. Y no solo esto, sino que tambin se ofrece la posibilidad de generar un
script (trozo de cdigo) que es capaz de crear el esquema fsico para una plataforma y un SGBD
concreto.
Los tipos de archivos manejables por Power Designor son dos:


208
1. Extensin CDM: contiene la definicin del esquema conceptual (Conceptual Data Model)
2. Extensin PDM: contiene la definicin del esquema fsico (Physical Data Model)
Power Designor se compone de cuatro mdulos:
Data Architect: se encarga de la definicin de los esquemas conceptual y fsico. Es en el que
nos centraremos.
MetaWorks: til para el trabajo en red de varios diseadores.
AppModeler: para la modelacin del esquema fsico.
ProcessAnalist: para realizar el diseo de procesos, es decir, diagramas de flujo de datos.
Comprende la etapa de diseo del ciclo de vida del software.
Creacin de una entidad
Para entrar en la aplicacin, ejecutar el mdulo DataArchitect. Acto seguido nos sale una pantalla
en blanco. Para crear un nuevo esquema conceptual, acceder al men File-New. Nos aparecer una
pantalla en blanco junto con una barra de herramientas, su apariencia se muestra en la Figura 98.

Figura 98

Para crear una nueva entidad, se deber pulsar el botn de creacin de entidades, y hacer click con el
botn izquierdo del ratn en cualquier parte de la pantalla. Una vez que tengamos creada la entidad, se
debern definir sus propiedades, es decir, su nombre, atributos y tipos, claves de la entidad, etc. Para
ello tenemos dos formas: pulsar el botn de definicin de entidades y hacer click izquierdo sobre la
entidad, o hacer doble click sobre dicha entidad. La pantalla que nos aparece se muestra en la Figura
99.
En ella se deber teclear el nombre que le demos a la entidad, un cdigo que representar de manera
unvoca a la entidad, y se deber especificar si la entidad generar tabla en el esquema fsico. Pulsando
el botn Rules se podrn definir las Bussiness Rules o Reglas de Negocio, es decir, las
Grupo EIDOS Apndice A. Diseo conceptual con Power Designor

209
restricciones que determinar el comportamiento de las entidades y/o sus relaciones. "Un cliente no
puede pedir un crdito superior a 1.000 euros" o "un proveedor slo puede atender a un cliente" son
ejemplos de reglas de negocio. En este apartado tambin se definen las reglas de integridad
referencial.

Figura 99

Las reglas de negocio pueden ser de los siguientes tipos:
Validacin: Especifican las restricciones que puede tener un valor en el esquema. Ej: el
crdito de un cliente no puede superar el 20% de su compra.
Hecho: Describen los hechos o forma de funcionar de la empresa. Ej: un cliente puede
realizar uno o ms pedidos.
Definicin: Especifican caractersticas o propiedades de un objeto en el sistema de
informacin. Ej: un cliente es una persona identificada por su DNI y por su
nombre.
Frmula: Definen los clculos a realizar en el sistema de informacin. Ej: la suma total de los
pedidos realizados por un cliente.
La pantalla para la asignacin de reglas de negocio a una entidad aparece en la Figura 100
Para aadir una regla, bastar con pulsar el Botn Add... y nos aparecer una lista con todas las reglas
definidas. Si todava no se ha introducido ninguna, ser preciso pulsar el botn List... para hacerlo. La
pantalla que nos permite definir las reglas de negocio es la que se muestra en la Figura 101.
Si queremos introducir una nueva regla, habr que pulsar el botn New, especificar el nombre y el
cdigo de la regla, y el tipo de sta. Pulsando el botn Define se visualizar la siguiente pantalla, en la

210
que podremos teclear la descripcin de la regla o la formula aplicable, dependiendo del tipo de regla
que hayamos escogido. Adems se puede especificar si la expresin a evaluar se desea ejecutar en el
cliente o en el servidor.

Figura 100

Figura 101

La principal ventaja de ejecutar una expresin en el servidor radica en la velocidad de ejecucin de la
misma, aunque la mayor desventaja es, sin duda, la probabilidad de cargar al servidor con demasiado
trabajo, lo que implica una ganancia de tiempo no tan drstica.

211

Figura 102
Volvemos a la pantalla de definicin de entidades para determinar los atributos de la entidad, para lo
cual pulsamos el botn Atributtes. Se mostrar entonces una nueva ventana, cuyo aspecto se muestra
en la siguiente figura, en la que podremos incluir nuevos atributos para dicha entidad. Para ello se
dispone de dos opciones:
1. Pulsar el botn New e introducir el nombre, cdigo y tipo de dato, o
2. Pulsar el botn Add... lo cual permitir seleccionar un atributo de entre los ya existentes en el
sistema de informacin.

Figura 103

212
De esta pantalla cabe destacar dos cosas. Una es la posibilidad de determinar un atributo como
identificador (identifier), es decir, ese atributo ser clave para dicha entidad, o como obligatorio
(mandatory) en cuyo caso dicho campo deber tener siempre un valor no nulo. Recurdese que un
valor nulo no es ni el cero ni el espacio en blanco, simplemente es un valor que no tiene valor (valga la
redundancia). La segunda es el tipo de atributo. Power Designor nos permite escoger entre una amplia
gama de tipos de datos, dejando al usuario la posibilidad de especificar su longitud y precisin. Dichos
atributos sern traducidos a los tipos especficos del SGBD con el que se vaya a trabajar (recordar
que en la definicin del esquema conceptual no se tiene por qu saber la implementacin fsica que se
va a realizar). Dentro de esta pantalla tambin se puede especificar el dominio de un atributo, es decir,
el rango de valores que puede tomar. En la lista desplegable etiquetada como Domain se puede
seleccionar el dominio que se va asignar a ese atributo. En el caso de que no tengamos definido ningn
dominio todava, se podr acceder a la pantalla que permite hacerlo, pulsando el botn .... sta tiene
un aspecto muy parecido al de todas las pantallas de definicin vistas hasta ahora.

Figura 104

Para incluir un nuevo dominio, se deber pulsar el botn New e introducir el nombre, cdigo y tipo de
dato de ste. La definicin en si del dominio se establece al pulsar el botn Check en el que se
mostrar una nueva pantalla, como la Figura 105, que permite establecer las principales caractersticas
del dominio.
En la carpeta de Standard Parameters es donde se especificar el rango que tomar el atributo. En este
caso se ha introducido un dominio para los nmeros telefnicos, que variar entre 600.000.000 (para
los mviles) y 999.999.999 (para los fijos), tambin se puede introducir directamente la lista de
valores que puede tomar, introducindolos en la lista de la derecha, e introducir otro tipo de
restricciones como son el caso de las maysculas o minsculas en los caracteres, o no permitir la
modificacin del atributo.
En la carpeta de Validation Rules (Figura 106), es donde se permite la definicin de restricciones mas
especificas. En nuestro caso se ha optado por la expresin ofrecida por defecto.
Se ha visto hasta ahora que en la mayora de las pantallas aparecen dos botones (o carpetas) con los
nombres Description y Annotation. La utilidad de ambos es la de disponer de un editor que permite la
introduccin de textos explicatorios y/o aclaratorios, en las definiciones de atributos, entidades y otros.

213

Figura 105

Figura 106
Creacin de relaciones
Se hablar en este apartado de las relaciones entendidas como la "unin" o relacin entre dos
entidades. Para crear una relacin entre dos entidades pulsaremos el botn de relacin entre entidades
de la paleta de herramientas. Acto seguido haremos click derecho con el ratn en la entidad origen y,

214
sin soltarlo, lo moveremos hasta la entidad destino. La Figura 107 muestra la relacin existente entre
las entidades cliente y proveedor.

Figura 107
Una vez definida la relacin, el siguiente paso es establecer la cardinalidad de la misma. Nuevamente,
para obtener el cuadro de dilogo de definicin de propiedades, haremos doble click sobre la relacin,
obteniendo algo parecido a la Figura 108.

Figura 108

Es aqu donde se deber establecer la cardinalidad mxima y mnima de la relacin en ambos sentidos.
Por ejemplo, podemos decir que un proveedor puede distribuir a uno o ms clientes. Es decir, cada
ocurrencia de la entidad proveedor puede relacionarse con una (cardinalidad mnima) o varias
(cardinalidad mxima) ocurrencias de la entidad cliente. En el sentido contrario, un cliente slo puede
abastecerse de un proveedor, lo que implica cardinalidad mnima y mxima uno.
Para establecer la cardinalidad mxima, se dispone de unos botones de seleccin, bajo el nombre de
Cardinality. Si escogemos la opcin One, estamos diciendo que la cardinalidad mxima ser uno,
mientras que si se selecciona la opcin Many, se estar indicando que la cardinalidad mxima es
muchos (o N). Para determinar la cardinalidad mnima, se dispone de otros botones de seleccin, bajo

215
el nombre Existence. Si indicamos la opcin Optional, quiere decir que la cardinalidad mnima es
cero, mientras que si se escoge la opcin Mandatory se obliga a que la cardinalidad mnima ser uno.
Un tipo especial de relacin es la relacin de dependencia. Como ya se estudio en anteriores temas,
una relacin de este tipo indica que depende de otra relacin para su identificacin. Si por ejemplo se
tiene la entidad pedido con los pedidos realizados por un cliente, y la entidad linea_pedido, con los
detalles de cada pedido, esta ltima entidad tiene una relacin de dependencia con aquella, ya que no
se sabr a que lnea de pedido nos estamos refiriendo, sin saber a que pedido corresponde. Para indicar
una relacin de este tipo, bastar con seleccionar la caja de seleccin denominada Is dependent.
Nuevamente nos encontramos en esta ventana con el botn Rules, en el cual podremos establecer las
reglas de negocio, adems de disponer de otras dos carpetas para introducir cualquier descripcin que
se nos ocurra.
La relacin de herencia
Otro tipo especial de relacin es la relacin de herencia. Consiste en la propiedad que tienen algunas
entidades de heredar el comportamiento de otras. Por ejemplo, podemos tener tres entidades:
automvil con los atributos marca, modelo, precio y num_puertas, la entidad motocicleta con los
atributos marca, modelo, precio y cilindrada y la entidad bicicleta con los atributos marca, modelo,
precio y num_cambios. Pero si nos damos cuenta, las tres relaciones tienen tres atributos en comn,
marca, modelo y precio. Podemos aprovechar esta ventaja para definir una relacin de herencia,
suponiendo que estas son caractersticas bsicas de cualquier vehculo. De esta forma se tendr una
relacin vehculo con los atributos marca, modelo y precio, de las que heredarn las entidades
automvil con atributo num_puertas, motocicleta con atributo cilindrada y bicicleta con atributo
num_cambios. Ni que decir tiene, que estas relaciones, con atributos privados o especficos a cada
una, heredan o importan los atributos de la entidad padre. El ejemplo se representa como indica la
Figura 109.

Figura 109

Para establecer una relacin de herencia, se deber escoger en la paleta el botn relacin de herencia,
seleccionar una relacin, pinchar en la relacin padre, y a continuacin pinchar en las dems
relaciones llevndolas hasta el punto de unin.
Diseo fsico con Power Designor
Paso del esquema conceptual al esquema fsico
Una vez realizado el diseo del esquema conceptual, el siguiente paso es obtener el esquema fsico.
Cabe destacar que Power Designor no da la posibilidad de realizar la fase intermedia de diseo lgico,
sino que sta est divida entre las fases de diseo conceptual y diseo fsico. Por ejemplo, si queremos
realizar un particionamiento vertical, ser preciso generar el esquema fsico y cambiarlo segn
nuestras pretensiones y/o necesidades.
Para generar el esquema fsico a partir del conceptual, se puede seleccionar la opcin de men
Dictionary - Generate Physical Model o pulsar las teclas Ctrl-G. Automticamente aparece una
pantalla, como la mostrada en la Figura 110.
En la parte superior se especifica el SGBD especfico sobre el cual se generar el esquema fsico. Esto
es importante, sobre todo, para determinar las restricciones del SGBD, los tipos de datos del mismo,
etc. Justo debajo se nos preguntar por el nombre del fichero en el que se guardar el modelo fsico,
con extensin .PDM. En la carpeta Generation se nos sigue preguntando una serie de parmetros. Por
ejemplo, permite especificar el nombre de los ndices primarios y ajenos (campos que son clave en
otras entidades) que se generarn para cada tabla. Tambin se puede decir si las reglas de actualizacin
o de borrado se propagarn a todas las tablas o slo a la que afecte, etc. En la segunda carpeta se nos
da la opcin de preservar ciertos cambios, como por ejemplo los grficos, las etiquetas, o las reglas de
negocio.
Una vez que estemos seguros de haber dado las opciones correctas, pulsaremos el botn OK y, tras un
breve perodo de tiempo nos aparecer un mensaje con el resultado de la generacin; si algo ha


218
fallado, se deber revisar nuevamente el esquema conceptual, en otro caso tendremos el
correspondiente esquema fsico.

Figura 110
Modificacin de las tablas

Figura 111
Grupo EIDOS Apndice B. Diseo fsico con Power Designor

219
Una vez generado el esquema fsico, podremos adecuarlo a nuestro gusto, teniendo en cuentas las
necesidades del sistema, y las restricciones del SGBD. De esta manera ser preciso realizar un estudio
detallado de las consultas que se realizarn a la base de datos, de la velocidad del hardware, del
nmero de actualizaciones, etc., para de esta forma, conseguir una mayor eficiencia.
En este caso ya podemos hablar de tablas, es decir, de la concrecin fsica de las entidades diseadas
en el esquema conceptual. Podemos empezar modificando las caractersticas de las tablas, para lo que
ser necesario hacer doble click sobre una de ellas, aparecindonos la Figura 111.
En ella podemos especificar varias caractersticas, que estudiaremos a continuacin en detalle.
Columnas
La edicin de columnas consiste en borrar, insertar y/o cambiar la definicin uno o ms atributos de
las tablas. La forma de hacerlo es similar a la pantalla mostrada en el anterior tema acerca de la
definicin de atributos, salvo que en esta se puede determinar un atributo como clave ajena (atributo
que es clave en otra tabla).
Otra funcionalidad que ofrece Power Designor es la definicin de atributos extendidos, que permite la
determinacin de ciertas caractersticas correspondientes a los atributos de una tabla, como pueden ser
la forma de visualizacin (lista desplegable, editor, etc.), el valor inicial o por defecto del mismo,
etiquetas, cabeceras, comentarios que se mostrarn a la hora de visualizarlos, etc. A esta funcionalidad
se accede pulsando el botn Extended, ante el cual aparece la Figura 112.

Figura 112
Indices
La definicin de los ndices de una tabla es otra de las caractersticas del diseo fsico ya estudiadas,
cuyo cometido es el aumento de eficiencia a la hora de realizar las consultas. Recurdese, sin

220
embargo, la desventaja que supone el tener una tabla de ndices demasiado extensa, a la hora de
realizar actualizaciones. Por lo tanto, es preciso realizar un estudio detallado de las transacciones que
se darn en la base de datos.
Para acceder a la pantalla de definicin de ndices, se deber pulsar el botn Indexes. Dicha pantalla
tiene la apariencia de la Figura 113.

Figura 113

Para definir un nuevo ndice, pulsaremos el botn New, teclearemos su nombre, y especificaremos su
tipo, de entre los siguientes:
Primary key: ndice por clave primaria. Es el ndice que se seguir por defecto, y define los
atributos que son clave en la tabla.
Foreign key: es el ndice que hace referencia a campos de la tabla, que son clave en otra tabla.
Unique: ndice nico, es decir, sus campos no pueden tener valores duplicados.
Cluster: ndice cluster, usado para recorrer los cluster de una base de datos (se remite al lector
al captulo de diseo fsico).
Para aadir campos a un ndice, se pulsar el botn Add y se seleccionarn los atributos que se desean
aadir. Adems se puede especificar la ordenacin del ndice, que puede ser ascendente o descendente.
En el botn Alternate Keys se pueden especificar claves alternativas o secundarias. Este es otro tipo de
claves, adems de las primarias, que sirven para identificar una ocurrencia de una entidad en la base de
datos.

221
Atributos extendidos
Como ya se ha visto, la funcionalidad que ofrece Power Designor sobre atributos extendidos, permite
la modificacin de ciertas caractersticas de stos.
Sin embargo, pulsando el botn Extended, nos podemos encontrar con otra pantalla, totalmente
distinta a la mostrada anteriormente, pero cuya finalidad es la misma: modificar el aspecto de
visualizacin de estos atributos, y cuyo aspecto es el mostrado en la Figura 114.

Figura 114

Como se puede observar, en ella no se pueden definir formas de visualizacin de los atributos, ni
valores iniciales, ni nada por el estilo, pero nos permite establecer las fuentes (tipo de letra, tamao,
estilo, etc.) con las cuales se mostrarn las tablas.
Triggers
Como su propio nombre indica, los triggers son disparadores, es decir, trozos de cdigo que se
ejecutan cuando ocurre un determinado evento.
En esta funcionalidad, accesible mediante el botn Triggers, se pueden determinar las acciones que
tendrn lugar cuando ocurra un determinado evento, como por ejemplo, al insertar una tupla en la base
de datos. Este cdigo es dependiente del SGBD, y define la accin que tendr lugar ante ciertos
eventos.
La Figura 115 muestra un ejemplo de definicin de trigger.


222

Figura 115
Restricciones
Bajo el nombre restriccin, se agrupa todo un conjunto de funciones que define el rango de valores
que puede tomar un determinado atributo, y todas las reglas que debe verificar una tabla. No se
ahondar ms en este tema, ya que ya se ha estudiado en el captulo sobre diseo conceptual, y cuyo
comportamiento es similar en el diseo fsico.
Creacin de vistas
Se entiende por vista, una porcin de la base de datos, accesible por un usuario. Recurdese la
definicin de vista recogida en el captulo de introduccin, y cuyo conjunto corresponda a la
definicin del nivel externo de la base de datos. Una vista permite la introduccin de un nivel de
seguridad. Es decir, se definirn consultas, que afecten a un determinado nmero de tablas, y cada una
de ellas podr ser accedida por uno o varios usuarios. Si no queremos que un usuario acceda a una
determinada tabla, simplemente se le ofrecern vistas que no impliquen dicha tabla.
Para definir una vista en Power Designor, pulsaremos el botn y a continuacin pincharemos en
cualquier punto de la pantalla. Para editarla, bastar con hacer doble click sobre ella, y nos aparecer
una pantalla como la que aparece en la Figura 116.
En ella podemos definir las tablas que implica, pulsando el botn Tables, y la query o consulta,
pulsando el botn Query. Adems se puede dar la opcin de modificar el contenido de las tablas
(opcin Updatable) o simplemente consultar (opcin Query Only). La query se podr definir mediante
el lenguaje SQL, pulsando el botn con dicho nombre.


223

Figura 116
Ejemplo de diseo con Power Designor
Para irnos familiarizndonos con el uso de S-Designar, vamos a tratar de resolver un planteamiento
utilizando esta herramienta.
Enterprise SL es una empresa de venta al pblico, quiere informatizar su sistema, de cara al euro y al
ao 2000. Para ello nos ha encargado que diseemos una base de datos que permita la introduccin y
recuperacin eficiente de datos. El funcionamiento de Enterprise SL es el siguiente. Existen una serie
de proveedores que abastecen a dicha empresa. A su vez, Enterprise SL desea tener almacenados los
datos de todos sus clientes. Por otra parte, de cara a Hacienda, desea simplificar el tema de la
facturacin. Para ello desea tener almacenados todos los pedidos. Adems desea conocer en todo
momento la disponibilidad de productos en el almacn, para realizar pedidos de forma automtica,
cada vez que las existencias son inferiores a las 10 unidades de cada producto.
Lo primero realizar es un diseo del esquema conceptual. Para ello abrimos la utilidad DataArchitect
de S-Designar, y creamos un nuevo modelo conceptual (.CDM). A continuacin empezamos a definir
entidades:
Proveedor: nos interesa saber su cdigo de proveedor, nombre, CIF, direccin, ciudad y
provincia.
Cliente: de que se desea conocer su cdigo de cliente, NIF, nombre, apellidos, direccin,
ciudad, provincia y telfono.
Producto: cdigo de producto, descripcin y existencias.
Pedido: cdigo de pedido.

Base de datos con SQL Server 2000 Transact SQL Grupo EIDOS

226
Linea_pedido: cdigo de la lnea de pedido y cantidad.
Factura: IVA e importe en pesetas y euros.
Empezamos creando las entidades. Pulsamos el botn entidad en la paleta de componentes y acto
seguido pulsamos seis veces en cualquier punto de la pantalla. Ya tenemos creadas las seis entidades.
El siguiente paso es definir los atributos de cada una de ellas. Para quitar la seleccin se puede pulsar
el botn flecha en la paleta, o hacer click con el botn derecho del ratn. Empezaremos por la entidad
proveedor. Para ello hacemos doble click sobre cualquiera de las entidades y, en la ventana que nos
aparece teclearemos el nombre de la entidad (Proveedor), y acto seguido pulsamos el botn
Attributes. Para crear un nuevo atributo pulsamos el botn New y le damos un nombre (CIF), un
cdigo (que ser tambin CIF) y un tipo de dato (tipo carcter de longitud 10, A10). As procederemos
con el resto de atributos, teniendo en cuenta que la clave de dicha entidad ser el atributo
cod_proveedor, por lo que tacharemos la caja de seleccin correspondiente a Identifier de dicho
atributo. La definicin completa es la mostrada en la

Figura 117

Ahora se nos plantean dos opciones:
1. Dejar que el usuario introduzca la ciudad y la provincia como texto libre, o
2. Tipificar las ciudades y provincias.
Nos decantaremos por esta ltima opcin, ya que evitar el tener diferentes definiciones para una
misma ciudad (Ej.: Sta. Cruz Tenerife, Santa Cruz de Tenerife, Sta. Cruz Trfe., Etc.). Esto implica la
creacin de otras dos nuevas entidades:
Provincia: cdigo de provincia y descripcin.
Ciudad: cdigo de ciudad y descripcin.
Grupo EIDOS Apndice C. Ejemplo de diseo con Power Designor

227
Por lo tanto creamos dos entidades ms, siguiendo el mismo proceso indicado anteriormente. En la
Figura 118 mostraremos como quedara la pantalla de definicin de la entidad provincia.

Figura 118

El atributo cod_provincia ser la clave de la entidad, y ser de tipo numrico de dos dgitos. El atributo
desc_provincia ser un texto de 20 caracteres.
La definicin de la entidad ciudad queda como indica la Figura 119.

Figura 119


228
Seguimos definiendo entidades, y pasamos a ahora a hacerlo con cliente.

Figura 120

Lo nico a destacar aqu es la clave de la entidad, que es el atributo cod_cliente, y los atributos
obligatorios que son Nombre y Apellidos.
En la Figura 121 definimos los atributos de la entidad Pedido.

Figura 121

Hacemos lo mismo con la entidad linea_pedido.

229

Figura 122

Tambin definimos la entidad producto.

Figura 123

Y concluimos definiendo la entidad factura, como se observa en la Figura 124
En esta ltima definicin, cabe destacar que se ha optado por no almacenar el importe en euros en un
nuevo campo, ya que ello supone un desperdicio de memoria, mxime cuando se sabe el cambio de
pesetas a euros. Lo nico que se deber realizar para calcularlo ser dividir el importe en pesetas por
166,386, con lo que ya tenemos una regla de negocio para la entidad factura. Para crearla, pulsamos el

230
botn Rules, y en la pantalla que nos aparece pulsamos List. Le damos el nombre Pesetas_a_euros,
y decimos que es de tipo Formula. Para definirla, pulsamos el botn Define y tecleamos lo que
muestra la Figura 125.

Figura 124

Figura 125

Una vez definida, slo nos queda aadirla a la entidad, para lo que pulsaremos el botn Add en la
pantalla y escogeremos dicha regla.

231

Figura 126
Una vez definidas todas las entidades, el siguiente paso es crear las relaciones entre ellas. Podemos
observar varias relaciones entre pares de entidades:
Un proveedor puede abastecer a la empresa de varios productos, y un producto puede ser
abastecido por varios proveedores: relacin N-M. La cardinalidad mxima es N y la mnima es
1. Para crear una relacin entre ambas entidades, pulsaremos el botn de relacin en la paleta
de componentes, y a continuacin uniremos ambas entidades. Haciendo doble click sobre la
relacin creada, obtenemos la pantalla de definicin, que debe quedar como la Figura 127.

Figura 127

232
Un cliente puede realizar muchos pedidos, pero un pedido slo puede ser realizado por un
cliente. Esto implica una relacin 1-N, y la ventana queda como la Figura 128.

Figura 128

Un pedido puede tener muchas lneas de pedido, pero una lnea de pedido slo puede
corresponder a un pedido. Adems, la relacin en el sentido de linea_pedido es dependiente,
es decir, no se puede identificar una lnea de pedido, si no se sabe el pedido al que
corresponde.

Figura 129

233
En una lnea de pedido slo puede haber un producto, mientras que un producto puede estar en
varias lneas de pedido.

Figura 130

Un cliente puede tener varias facturas, sin embargo una factura slo puede corresponder a un
cliente.

Figura 131

234

Una provincia puede tener muchas ciudades, pero como mnimo una, y una ciudad slo puede
pertenecer a una provincia.

Figura 132

Una ciudad puede tener varios proveedores, pero un proveedor slo puede pertenecer a una
ciudad. La cardinalidad mnima es uno, ya que no nos interesa tener almacenadas las ciudades
sin proveedores.

Figura 133

235
Una ciudad puede tener varios clientes, pero un cliente slo puede pertenecer a una ciudad.
Obsrvese, en la Figura 134 como no se ha incluido una relacin entre provincia y cliente, ya
que sabiendo la ciudad a la que pertenece el cliente, podemos saber su provincia.

Figura 134

Pues bien, ya tenemos el esquema conceptual, que queda como muestra la Figura 135.

Figura 135

236

Una vez obtenido el esquema conceptual, el siguiente paso es obtener el esquema fsico. Para ello
pulsamos Ctrl-G y escogemos un SGBD, por ejemplo Microsoft Access 95. Pulsamos Ok. El esquema
fsico queda como aparece la Figura 136.

Figura 136

En l podemos observar como se ha aadido una nueva relacin, denominada RELATION_63, fruto
de la relacin N-M entre las entidades producto y proveedor, y que almacena los productos que han
sido abastecidos por cada proveedor. Las flechas representan las operaciones de join que hay que
realizar para obtener la informacin de una tabla.

Figura 137

237

Lo primero que realizaremos ser cambiar el nombre de la relacin RELATION_63, ya que no queda
muy esttico. Le daremos el nombre de Proveedor-Producto, y aadiremos un nuevo atributo, que ser
la fecha en la que se ha realizado la venta. Para ello hacemos doble click en dicha entidad, pulsamos el
botn Columns, pulsamos el botn New, y tecleamos el nuevo atributo.
Crearemos ahora una vista, para que la secretaria encargada de realizar los pedidos, compruebe el
stock que queda. Para ello pulsamos el botn vista en la paleta de componentes, y pinchamos en
cualquier punto de la pantalla. Para definirla, hacemos doble click sobre ella, y establecemos una
consulta SQL.

Figura 138

No se preocupe demasiado si no entiende la anterior consulta, ya que en la siguiente parte se estudiar
a fondo la sintaxis de lenguaje SQL. Bsicamente, lo que hace es recuperar todos los productos cuyo
stock es menor de 10 unidades.

Si quiere ver ms textos en este formato, vistenos en: http://www.lalibreriadigital.com.
Este libro tiene soporte de formacin virtual a travs de Internet, con un profesor a su
disposicin, tutoras, exmenes y un completo plan formativo con otros textos. Si desea
inscribirse en alguno de nuestros cursos o ms informacin visite nuestro campus virtual en:
http://www.almagesto.com.

Si quiere informacin ms precisa de las nuevas tcnicas de programacin puede suscribirse
gratuitamente a nuestra revista Algoritmo en: http://www.algoritmodigital.com. No deje de
visitar nuestra reviata Alquimia en http://www.eidos.es/alquimia donde podr encontrar
artculos sobre tecnologas de la sociedad del conocimiento.

Si quiere hacer algn comentario, sugerencia, o tiene cualquier tipo de problema, envelo a la
direccin de correo electrnico lalibreriadigital@eidos.es.

Grupo EIDOS
http://www.eidos.es

Bases - De.datos - con.SQL - Server.2000.transact - Sql. .Jorge - Moratalla.grupo - Eidos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bases - De.datos - con.SQL - Server.2000.transact - Sql. .Jorge - Moratalla.grupo - Eidos

Cargado por

Copyright:

Formatos disponibles

El texto est diseado

También podría gustarte