Material Gestion y Consulta en Base de Datos Relacionales

Elaborado por:
Lic. Elvin German

GOTA A GOTA EN LAS BASES DE DATOS RELACIONALES
Gota a Gota en las Bases de Datos

Relacionales
Contenido
CAPITULO 1. INTRODUCCION.....................................................................................................15
Derechos Reservados. Prohibido la Venta y Distribucion sin Permiso del Autor.
Elaborado por: Elvin German

1. OBJETIVOS............................................................................................................................15
1.1. GENERALES.........................................................................................................................15
1.2. ESPECÍFICOS........................................................................................................................15
2. REQUISITOS..........................................................................................................................15
3. JUSTIFICACIÓN......................................................................................................................15
4. METODOLOGÍA.....................................................................................................................16
5. INTRODUCCIÓN....................................................................................................................16
6. CONCEPTOS GENERALES.......................................................................................................17
6.1. BASE DE DATOS...................................................................................................................17
6.2. SISTEMA DE GESTIÓN DE BASES DE DATOS.................................................................................17
6.3. GESTOR DE LA BASE DE DATOS.................................................................................................17
6.3.1. DICCIONARIO DE LA BASE DE DATOS.............................................................................................17
6.3.2. LENGUAJES.............................................................................................................................18
6.3.3. LENGUAJE DE DEFINICIÓN DE DATOS (DDL)...................................................................................18
6.3.4. LENGUAJE DE MANIPULACIÓN DE DATOS (DML)............................................................................18
6.3.5. LENGUAJE DE CONTROL DE DATOS (DCL)......................................................................................18
6.3.6. ADMINISTRADOR DE LA BASE DE DATOS........................................................................................18
6.4. USUARIOS DE LA BASE DE DATOS.............................................................................................18
6.5. ESTRUCTURA FISICA..............................................................................................................18
6.5.1. ARCHIVO DE DATOS..................................................................................................................18
6.5.2. NOMBRE DE ARCHIVOS..............................................................................................................19
6.5.3. TAMANO DE LA BASE DE DATOS..................................................................................................19


6.6. ESTRUCTURA LOGICA...............................................................................................................20
6.7. TABLAS..............................................................................................................................20
6.8. CAMPOS Y REGISTROS...........................................................................................................21
6.9. INDICES..............................................................................................................................21
6.10. CONSTRAINTS O RESTRICCIONES.............................................................................................22
6.11. VISTAS.............................................................................................................................22
6.12. SQL................................................................................................................................23
6.13. PROCEDIMIENTOS ALMACENADOS..........................................................................................23
6.14. PROGRAMACIÓN CON TRANSACT SQL.....................................................................................23
7. INSTALACIÓN DE SQL SERVER...............................................................................................24
7.1. REQUISITOS........................................................................................................................24
7.2. INSTALANDO SQL SERVER......................................................................................................26
7.3. PROCESO DE INSTALACIÓN......................................................................................................27
8. SQL SERVER CONFIGURATION MANAGER.............................................................................40
9. PLANIFICACION DEL DISEÑO DE LA BASE DE DATOS.............................................................41
9.1. ESTUDIO DE NECESIDADES......................................................................................................42
9.2. PLANIFICACIÓN....................................................................................................................43
9.3. PROPIEDADES......................................................................................................................44
9.4. DEPENDENCIAS....................................................................................................................44
9.5. NORMALIZACION..................................................................................................................46
9.6. INTEGRIDAD DE ENTIDAD........................................................................................................47
9.7. INTEGRIDAD DE DOMINIO.......................................................................................................48
9.8. INTEGRIDAD REFERENCIAL.......................................................................................................49


9.9. INTEGRIDAD FIJADA POR USUARIO.............................................................................................50
9.10. FORMAS DE NORMALIZACIÓN................................................................................................50
9.10.1. FORMA NORMAL A.................................................................................................................51
9.10.2. FORMA NORMAL B.................................................................................................................53
9.11. RELACIONES...................................................................................................................55
9.11.1. FORMA NORMAL C.................................................................................................................56
9.11.2. CONCLUSIÓN DEL PROCESO DE NORMALIZACIÓN..........................................................................56
9.12. DESNORMALIZACIÓN...........................................................................................................57
9.12.1. HERRAMIENTAS PARA LA NORMALIZACIÓN..................................................................................57
9.13. IDENTIDAD........................................................................................................................57
9.13.1. UNIQUE...............................................................................................................................58
9.13.2. DEFAULT..............................................................................................................................58
9.13.3. CHECK.................................................................................................................................58
9.14. INTEGRIDAD EN RELACIONES..................................................................................................58
9.14.1. PRIMARY KEY........................................................................................................................58
9.14.2. FOREIGN KEY.........................................................................................................................58
9.14.3. INTEGRIDAD REFERENCIAL EN CASCADA......................................................................................59
9.15. DESENCADENADORES (TRIGUERS)...........................................................................................60
9.16. EJERCICIO 1.......................................................................................................................60
9.17. EJECICIO 2........................................................................................................................60
CAPITULO 2. INICIACIÓN A LA ADMINISTRACIÓN Y DEFINICIÓN DE LA BASE DE DATOS. ............61
2. OBJETIVO..............................................................................................................................61
2.1. INTRODUCCIÓN...............................................................................................................61
2.2. SQL SERVER MANAGEMENT STUDIO........................................................................................61


2.2.1. SERVIDORES REGISTRADOS.................................................................................................67
2.2.2. REGISTRO DE SERVIDORES..........................................................................................................70
2.2.3. AGRUPAR SERVIDORES..............................................................................................................72
2.2.4. EXPLORADOR DE OBJETOS..........................................................................................................74
2.3. CONECTAR A UN SERVIDOR.....................................................................................................75
2.3.1. CARPETAS DEL EXPLORADOR DE OBJETOS......................................................................................77
2.3.2. PESTAÑA RESUMEN..................................................................................................................79
2.3.3. CARPETAS PRINCIPALES.............................................................................................................80
2.3.4. CARPETA DE BASES DE DATOS.....................................................................................................80
2.3.5. EJERCICIO 1............................................................................................................................82
2.4. DEFINIR LA BASES DE DATOS (CREACIÓN)...................................................................................83
2.4.1. PRIMARY................................................................................................................................83
2.4.2. FILENAME...............................................................................................................................84
2.4.3. SIZE.......................................................................................................................................84
2.4.4. FILEGROWTH...........................................................................................................................84
2.4.5. COLLATION.............................................................................................................................84
2.5. CÓMO FUNCIONA EL REGISTRO DE TRANSACCIONES......................................................................85
2.6. CONFIGURACIÓN DE LAS OPCIONES DE BASE DE DATOS..................................................................86
2.7. RECUPERACIÓN DE INFORMACIÓN DE LA BASE DE DATOS...............................................................88
2.8. ADMINISTRACIÓN DEL CRECIMIENTO DE LOS ARCHIVOS DE DATOS Y DE REGISTRO................................89
2.9. USO DEL CRECIMIENTO AUTOMÁTICO DE LOS ARCHIVOS................................................................89
2.10. AMPLIACIÓN DE LOS ARCHIVOS DE LA BASE DE DATOS.................................................................90
2.11. AGREGAR ARCHIVOS SECUNDARIOS A LA BASE DE DATOS.............................................................90
2.12. ELIMINACIÓN DE UNA BASE DE DATOS.....................................................................................91
2.12.1. MÉTODOS DE ELIMINACIÓN DE UNA BASE DE DATOS.....................................................................91

2.13. CÓMO SE ALMACENAN LOS DATOS..........................................................................................92
2.14. LIMITAR LISTA DE BASES DE DATOS EN SQL SERVER.....................................................................93
CAPITULO 3. EXPLOTACION Y SEGURIDAD..................................................................................96
3. OBJETIVO..............................................................................................................................96
3.1. CREAR UNA TAREA DE TOMA DE COPIA DE SEGURIDAD DE BASE DE DATOS MANUALMENTE....................96
3.2. CREAR UNA TAREA DE TOMA DE COPIA DE SEGURIDAD DE BASE DE DATOS MANUALMENTE....................96
3.3. CREAR UNA COPIA DE SEGURIDAD DE BASE DE DATOS USANDO EL ASISTENTE......................................99
3.4. ASISTENTE PARA GENERAR Y PUBLICAR SCRIPTS.......................................................................101
3.4.1. ABRIR EL ASISTENTE GENERAR Y PUBLICAR SCRIPTS........................................................................101
3.5. RESTABLECER UNA BASE DE DATOS SQL SERVER A PARTIR DE ARCHIVOS BAK....................................101
3.6. RESTABLECER UNA BASE DE DATOS SQL SERVER DE ARCHIVOS MDF...............................................102
3.7. CREAR UN USUARIO DE BASE DE DATOS...................................................................................102
ANTES DE EMPEZAR......................................................................................................................102
SEGURIDAD NOTA:.......................................................................................................................102
3.7.1. PARA CREAR UN USUARIO DE BASE DE DATOS..............................................................................102
3.7.2. OPCIONES ADICIONALES..........................................................................................................103
3.7.3. USAR TRANSACT-SQL.............................................................................................................104
CAPITULO 4. SQL I.....................................................................................................................105
4. OBJETIVO............................................................................................................................105
4.1. CARACTERÍSTICAS DEL LENGUAJE............................................................................................105
4.2. ¿QUÉ ES EL SQL?...............................................................................................................105


4.2.1. DDL....................................................................................................................................105
4.2.2. DCL....................................................................................................................................105
4.2.3. DML...................................................................................................................................106
4.3. SINTAXIS BÁSICAS DE LA SENTENCIA SELECT (CONSULTAS SIMPLES)...............................................107
4.3.1. LA TABLA ORIGEN – FROM.....................................................................................................107
4.3.2. CLÁUSULAS DISTINCT / ALL...................................................................................................107
4.3.3. CLÁUSULA TOP.....................................................................................................................109
4.3.4. CLÁUSULA WHERE................................................................................................................110
4.4. DIRECTIVAS DE PROCESOS POR LOTES......................................................................................118
4.4.1. GO:....................................................................................................................................118
4.4.2. EXEC O EXECUTE:...............................................................................................................118
4.4.3. COMENTARIOS EN SQL...........................................................................................................118
4.4.4. TABLAS EN SQL.....................................................................................................................118
4.5. IDENTIFICADORES PARA LOS OBJETOS......................................................................................118
4.6. UTILIZACIÓN DE ALIAS.........................................................................................................119
4.6.1. EJEMPLOS DE UTILIZACIÓN DE ALIAS...........................................................................................119
4.7. UTILIZACIÓN DEL *.............................................................................................................120
4.7.1. COLUMNAS DE LA TABLA ORIGEN..............................................................................................120
4.8. COLUMNAS CALCULADAS......................................................................................................121
4.9. ORDENACIÓN DE LAS FILAS - ORDER BY.................................................................................122
4.10. SUBCONSULTAS................................................................................................................125
4.10.1. ANIDAR SUBCONSULTAS........................................................................................................127
4.10.2. SUBCONSULTA EN LA LISTA DE SELECCIÓN.................................................................................127
4.10.3. EN LA CLÁUSULA FROM...................................................................................................127
4.10.4. SUBCONSULTA EN LAS CLÁUSULAS WHERE Y HAVING..............................................................128

4.10.5. CONDICIONES DE SELECCIÓN CON SUBCONSULTAS......................................................................128
10.7. PARTE 5, CAPITULO 4........................................................................................................135
10.7.1 SUBCONSULTAS.......................................................................................................................135
4.11. CONSULTAS MULTITABLAS..................................................................................................135
4.11.1. UNIÓN DE TABLAS................................................................................................................135
4.11.2. COMPOSICIÓN DE TABLAS......................................................................................................136
4.11.3. EL OPERADOR UNION............................................................................................................137
4.11.4. EL PRODUCTO CARTESIANO....................................................................................................138
4.12. INNER JOIN..................................................................................................................140
4.12.1. LEFT JOIN Y RIGHT JOIN...................................................................................................141
4.13. CONSULTAS EXTERNAS.......................................................................................................144
4.13.1. EJEMPLO PARA COMBINAR MÁS DE DOS TABLAS.........................................................................147
4.14. COMBINAR LOS VALORES DE UNA TABLA SOBRE SÍ MISMA..........................................148
10.8. PARTE 6, CAPITULO 4........................................................................................................149
10.8.1. CONSULTAS MULTITABLAS......................................................................................................149
10.9. RESUMEN DE CUÁNDO UTILIZAR CADA OPERACIÓN.....................................................150
10.10. CONSULTAS AGREGADAS...........................................................................................152
10.10.1. CLAUSULA GROUP BY....................................................................................................152
10.10.2. CLAUSULA HAVING........................................................................................................153
10.10.3. AVG...............................................................................................................................154
10.10.4. COUNT.............................................................................................................................155
10.10.5. RESUMEN DEL TEMA...........................................................................................................158
16.12. PARTE 4, CAPITULO 4.........................................................................................................159
16.12.1 SELECCIÓN CON AGRUPAMIENTOS Y FUNCIONES DE GRUPO............................................................159
10.11. FUNCIONES PREDEFINIDAS.........................................................................................159

10.11.1. FUNCIONES MATEMATICAS...................................................................................................160
10.11.2. FUNCIONES DE CADENA................................................................................................161
10.11.3. FUNCIONES DE FECHA.........................................................................................................166
16.10. PARTE 2, CAPITULO 4.........................................................................................................170
16.10.1 ELEMENTOS DEL LENGUAJE......................................................................................................170
CAPITULO 5. SQL II....................................................................................................................171
5. OBJETIVO............................................................................................................................171
4.15. ACTUALIZACIÓN DE DATOS..................................................................................................171
5.7.1. INSERTAR UNA FILA INSERT INTO...VALUES..................................................................................171
5.7.2. MODIFICAR EL CONTENIDO DE LAS FILAS (UPDATE)....................................................................174
5.7.3. BORRAR FILAS (DELETE)........................................................................................................176
5.7.4. RESUMEN DEL TEMA...............................................................................................................178
10.15 PARTE I, CAPITULO 5..........................................................................................................178
10.15.1 ACTUALIZACIÓN DE TABLAS......................................................................................................178
CAPITULO 6. TABLAS.................................................................................................................179
6. OBJETIVO............................................................................................................................179
6.7. DDL, LENGUAJE DE DEFINICIÓN DE DATOS...............................................................................179
6.7.1. CREATE TABLE.......................................................................................................................179
6.7.2. TIPOS DE DATOS EN TRANSACT SQL..........................................................................................179
6.7.3. EQUIVALENCIA DE DATOS DE SQL SERVER Y .NET.....................................................................182
6.7.4. OPERADORES EN TRANSACT SQL..............................................................................................184
6.7.5. CONSTRAINTS O RESTRICCION...................................................................................................184

16.18. PARTE 1, CAPITULO 6.........................................................................................................192
16.18.1 CREACIÓN DE TABLAS..............................................................................................................192
CAPITULO 7. INDICES................................................................................................................193
7. OBJETIVO............................................................................................................................193
7.7. CREACION DE INDICES..........................................................................................................193
7.7.1. CREAR UN ÍNDICE...................................................................................................................194
7.7.2. PARA CREAR UN ÍNDICE ÚNICO.................................................................................................197
7.7.3. CREAR UN ÍNDICE AGRUPADO...................................................................................................200
7.7.4. PARA CREAR ÍNDICES DE TEXTO COMPLETO.................................................................................201
7.7.5. PARA CAMBIAR LAS PROPIEDADES DEL ÍNDICE..............................................................................204
7.7.6. CAMBIAR EL NOMBRE DE UN ÍNDICE..........................................................................................205
7.7.7. ELIMINAR UN ÍNDICE...............................................................................................................205
CAPITULO 8. VISTAS..................................................................................................................207
8. OBJETIVO............................................................................................................................207
8.7. VISTAS.............................................................................................................................207
8.7.1. ¿QUÉ SON LAS VISTAS Y PARA QUÉ SIRVEN?................................................................................207
8.7.2. CREACIÓN Y UTILIZACIÓN DE VISTAS...........................................................................................207
8.7.3. FORMATO DE LA CREACIÓN DE VISTAS........................................................................................208
8.7.4. UTILIZACIÓN DE VISTAS...........................................................................................................208
8.7.5. EJEMPLOS CREACIÓN Y UTILIZACIÓN DE VISTAS.............................................................................209
8.7.6. CREAR UNA VISTA LOCAL CON UN ASISTENTE...............................................................................210
8.7.7. ELIMINACIÓN DE VISTAS..........................................................................................................210

CAPITULO 9. LOGICA DE NEGOCIO............................................................................................211
9. OBJETIVO............................................................................................................................211
9.7. TRANSACCIONES EN TRANSACT SQL.........................................................................................211
9.8. ESTRUCTURAS DE CONTROL EN TRANSACT SQL..........................................................................218
9.8.1. ESTRUCTURA CONDICIONAL CASE..............................................................................................219
9.8.2. BUCLE WHILE........................................................................................................................220
9.8.3. ESTRUCTURA GOTO..............................................................................................................222
9.9. CONTROL DE ERRORES EN TRANSACT SQL................................................................................222
9.9.1. FUNCIONES ESPECIALES DE ERROR.............................................................................................223
9.9.2. LA VARIABLE DE SISTEMA @@ERROR........................................................................................224
9.10. PROCEDIMIENTOS ALMACENADOS EN TRANSACT SQL...............................................................226
9.11. FUNCIONES EN TRANSACT SQL............................................................................................229
9.11.1. FUNCIONES ESCALARES..........................................................................................................229
9.11.2. FUNCIONES EN LINEA............................................................................................................231
9.11.3. FUNCIONES EN LÍNEA DE MULTIPLES SENTENCIAS........................................................................232
9.12. TRIGGERS EN TRANSACT SQL..............................................................................................235
9.12.1. TRIGGER DML....................................................................................................................235
9.12.2. TRIGGER DDL.....................................................................................................................238
9.13. CURSORES EN TRANSACT SQL.............................................................................................239
9.13.1. GLOBAL..............................................................................................................................242
9.13.2. FORWARD_ONLY..................................................................................................................242
9.13.3. SCROLL..............................................................................................................................242
9.13.4. STATIC...............................................................................................................................244
9.13.5. KEYSET...............................................................................................................................244

9.13.6. DYNAMIC...........................................................................................................................244
9.13.7. FAST_FORWARD..................................................................................................................245
9.13.8. READ_ONLY........................................................................................................................245
9.13.9. SCROLL_LOCKS................................................................................................................245
9.13.10. OPTIMISTIC.......................................................................................................................246
9.13.11. TYPE_WARNING.................................................................................................................246
9.14. SQL DINÁMICO EN TRANSACT SQL.......................................................................................247
9.14.1. PROCEDIMIENTO ALMACENADO SP_EXECUTESQL...................................................................249
10. CAPITULO 10. MANUAL DE TRABAJO...............................................................................251
10.7. OBJETIVOS......................................................................................................................251
10.8. SCRIPT EJEMPLO CREACIÓN BASE DE DATOS CURSO.................................................................251
10.9. PARTE 1 CAPITULO 4........................................................................................................256
10.9.1. EL LENGUAJE DE GESTIÓN DE BASE DE DATOS............................................................................256
10.10. PARTE 2, CAPITULO 4......................................................................................................257
10.10.1. ELEMENTOS DEL LENGUAJE..................................................................................................257
10.11. PARTE 3, CAPITULO 4......................................................................................................259
10.11.1. CONSULTAS SENCILLAS........................................................................................................259
10.12. PARTE 4, CAPITULO 4......................................................................................................260
10.12.1. SELECCIÓN CON AGRUPAMIENTOS Y FUNCIONES DE GRUPO........................................................260
10.13. PARTE 5, CAPITULO 4......................................................................................................260
10.13.1. SUBCONSULTAS.................................................................................................................260
10.14. PARTE 6, CAPITULO 4......................................................................................................261
10.14.1. CONSULTAS MULTITABLAS....................................................................................................261
10.15. PARTE I, CAPITULO 5.......................................................................................................262

10.15.1. ACTUALIZACIÓN DE TABLAS..................................................................................................262
10.16. "EVALUACIÓN I"............................................................................................................263
10.16.1. MARCA LA CASILLA CON LA RESPUESTA CORRECTA....................................................................263
10.17. "EVALUACIÓN II"...........................................................................................................268
10.17.1. MARCA LA CASILLA CON LA RESPUESTA CORRECTA....................................................................268
10.18. PARTE 1, CAPITULO 6......................................................................................................274
10.18.1. CREACIÓN DE TABLAS..........................................................................................................274
10.19. PARTE 2, CAPITULO 4, CAPITULO 5, CAPITULO 6, CAPITULO 7.................................................275
10.19.1. CONSULTAS DENTRO DE OTRAS SENTENCIAS............................................................................275
10.20. PARTE I, CAPITULO 1, CAPITULO 2, CAPITULO 3....................................................................276
10.20.1. ADMINISTRACIÓN DE SQL...................................................................................................276
11. CONTENIDO BIBLIOGRAFICO.............................................................................................278

Capitulo 1. Introduccion
1. Objetivos
Una vez finalizado este material, el lector estará preparado para:
 Instalar y Configurar SQL Server.
 Comprender los conceptos más importantes del diseño de bases de datos.
 Crear sentencias SQL para el trabajo de nuestros datos.
 Manejar el lenguaje de programación T-SQL para un tratamiento más completo de datos.
 Implementar aplicaciones que automaticen el tratamiento de datos.
 Comenzar a administrar y mantener una base de datos con SQL Server.
1.1. Generales
Con este Material de SQL Server Gota a Gota en las Bases de Datos Relacionales pretendo dejar claro los
conceptos de su funcionamiento y estructura, consiguiendo los siguientes objetivos:
 Aclarar el funcionamiento en todos los aspectos de las Bases de datos relacionales y la Gestión de
las mismas.
 Comprender los lenguajes que conforman las Bases de Datos (DDL, DML, DCL)
1.2. Específicos
Especificando un poco más los objetivos de este material, podemos declarar que el lector conseguirá
entender el funcionamiento y estructura para saber cómo aprovechar todas las capacidades de este tipo de
bases de datos en la creación de programas informáticos de cualquier nivel, aprender la utilización de las
bases de datos de SQL SERVER de cara a la programación.
Estudiar el funcionamiento de las mismas, para una mejor base de cara a la utilización de sentencias SQL y
de bases de datos de mayor complejidad. Formación específica muy demandada y valorada en el mercado
de trabajo para los profesionales de la informática. Asentar los pilares de la programación no sólo habitual,
sino también para intranets, aprovechando las funcionalidades de las bases de datos con respecto a las
tecnologías de programación para la web.
2. Requisitos
Los requisitos necesarios para que el lector pueda seguir y finalizar el material eficazmente, son mínimos. Es
suficiente con conocer el entorno de trabajo del sistema operativo Windows y que este familiarizado a
trabajar con interfaz gráfica de usuario (abrir archivos, guardar, copiar, etc.).
3. Justificación
En el mundo actual la informática y con ella la programación y desarrollo de aplicaciones centradas en el
manejo de los datos ha adquirido una importancia de primer orden para cualquier empresa o profesional, de
modo que no vale de nada saber programar en cualquier lenguaje si no se entiende a la perfección el
funcionamiento básico de cualquier base de datos y como los datos están organizados en ellas para ser
llamados desde diversas aplicaciones en cualquier entorno operativo. Partiendo de esta base y en función de
la exhaustividad de los datos y las relaciones en sí surge el concepto de Bases de Datos Relacionales, que son
aquellas que integran diversos tipos de datos en varias tablas de una misma base y que se hacen
indispensables para la agilidad y usabilidad de los mismos.
De los enunciados anteriores se desprende que el manejo de las Bases de Datos Relacionales es
indispensable en cualquier lenguaje de programación orientado al manejo de datos y por consiguiente en
cualquier aplicación informática que pretenda la administración de los mismo, más aún cuando el mayor
valor de las empresas en la actualidad radica en el tratamiento de sus productos, clientes, proveedores,
agentes, etc.
Debe quedar claro desde el primer momento que del buen diseño de la base de datos que vayamos a utilizar
depende el buen fin de la utilidad informática que pretendamos desarrollar y por tanto sería casi inútil saber
mucho de cualquier lenguaje de programación sin conocer el funcionamiento de las bases de datos, ya que
otra forma estaríamos condenados a reescribir todo el código del programa una y mil veces si no hemos
planteado correctamente las "bases" del mismo.
4. Metodología
El material se desarrollará completamente con ejemplos, dotados de su material de apoyo, el cual tendrá
como soporte los ejemplos prácticos, para poder darle seguimiento a los temas expuestos en cada capitulo,
prácticas de autoevaluación y completa ayuda y asesoramiento por medio de las sintaxis y los ejemplos
expuestos en el material.
5. Introducción
UN sistema gestor de bases de datos (SGBD) consiste en una colección de datos interrelacionados y un
conjunto de programas para acceder a dichos datos. La colección de datos, normalmente denominada base
de datos, contiene información relevante para una empresa. El objetivo principal de un SGBD es
proporcionar una forma de almacenar y recuperar la información de una base de datos de manera que sea
tanto práctica como eficiente. Los sistemas de bases de datos se diseñan para gestionar grandes cantidades
de información. La gestión de los datos implica tanto la definición de estructuras para almacenar la
información como la provisión de mecanismos para la manipulación de la información. Además, los sistemas
de bases de datos deben proporcionar la fiabilidad de la información almacenada, a pesar de las caídas del
sistema o los intentos de acceso sin autorización. Si los datos van a ser compartidos entre diversos usuarios,
el sistema debe evitar posibles resultados anómalos. Dado que la información es tan importante en la
mayoría de las organizaciones, los científicos informáticos han desarrollado un amplio conjunto de
conceptos y técnicas para la gestión de los datos. En este capítulo se presenta una breve introducción a los
principios de los sistemas de bases de datos.

6. Conceptos Generales
6.1. Base de datos
Una base de datos está constituida por un conjunto de información relevante para una empresa o entidad, junto
con los procedimientos para almacenar, controlar, gestionar y administrar esa información. Además, la
información contenida en una base de datos cumple una serie de requisitos o características:
 Los datos están interrelacionados, sin redundancias innecesarias.
 Los datos son independientes de los programas que los usan.
 Se emplean métodos determinados para recuperar los datos almacenados o para incluir datos nuevos y
borrar o modificar los existentes.
Una base de datos estará organizada de forma que se cumplan los requisitos para que la información se almacene
con las mínimas redundancias, con capacidad de acceso para diferentes usuarios pero con un control de seguridad
y privacidad. Debe tener mecanismos que permitan recuperar la información en caso de pérdida y la capacidad de
adaptarse fácilmente a nuevas necesidades de almacenamiento.
6.2. Sistema de Gestión de Bases de Datos
Un Sistema de Gestión de Bases de Datos (SGBD) es una aplicación formada por un conjunto de programas que
permite construir y gestionar bases de datos. Proporciona al usuario de la base de datos las herramientas
necesarias para realizar, al menos, las siguientes tareas:
 Definir las estructuras de los datos.
 Manipular los datos. Es decir, insertar nuevos datos, así como modificar, borrar y consultar los datos
existentes.
 Mantener la integridad de la información.
 Proporcionar control de la privacidad y seguridad de los datos en la Base de Datos, permitiendo sólo el
acceso a los mismos a los usuarios autorizados.
Para realizar las funciones que acabamos de describir, el Sistema Gestor de Bases de Datos necesita un conjunto
de programas que gestionen el almacenamiento y la recuperación de dichos datos y un personal informático que
maneje dichos programas.
Los componentes principales de un SGBD son:
6.3. Gestor de la base de datos
Es un conjunto de programas transparentes al usuario que se encargan de gestionar la seguridad de los datos y el
acceso a ellos. Interacciona con el sistema operativo proporcionando una interfaz entre el usuario y los datos.
Cualquier operación que se realice ha de estar procesada por este gestor.
6.3.1. Diccionario de la base de datos
Es donde se almacena toda la descripción de los diferentes objetos de la base de datos. Esta información se
almacena con la misma estructura que los datos de los usuarios. El almacenamiento de esta información lo realiza
el sistema gestor y cualquier usuario puede acceder a su contenido con el mismo lenguaje que al resto de los
datos almacenados (SQL)

6.3.2. Lenguajes
El sistema gestor ha de proporcionar lenguajes que permitan definir la estructura de los datos, almacenar la
información y recuperarla. Podrán utilizar estos lenguajes los usuarios y lo administradores de la base de datos.
Estos lenguajes son:
6.3.3. Lenguaje de definición de datos (DDL)
Para definir la estructura con la que almacenaremos los datos.
6.3.4. Lenguaje de manipulación de datos (DML)
Para añadir, modificar o eliminar datos, así como recuperar la información almacenada.
6.3.5. Lenguaje de control de datos (DCL)
Para controlar el acceso a la información y la seguridad de los datos. Permiten limitar y controlar los accesos a la
información almacenada. De esta tarea se ocupa el administrador de la base de datos.
6.3.6. Administrador de la base de datos
Es una persona o grupo de personas responsables de la seguridad y la eficiencia de todos los componentes del
sistema de bases de datos. Deben conocer el sistema tanto a nivel físico como lógico y a todos los usuarios que
interaccionan con él.
6.4. Usuarios de la base de datos

Tradicionalmente considerados como un componente más de los sistemas gestores de bases de datos, debido a
que estos fueron los primeros en considerarlos una parte importante para el correcto funcionamiento del sistema.
Pueden ser usuarios terminales (usuarios no especializados que interaccionan con la base de datos), usuarios
técnicos (usuarios que desarrollan programas de aplicación para ser utilizados por otros) y usuarios especializados
(usuarios que utilizan el sistema gestor de la base de datos como una herramienta de desarrollo dentro de otros
sistemas más complejos).
6.5. Estructura fisica

Una base de datos se almacena en varios ficheros o archivos en disco. Como mínimo tendremos dos ficheros
que explicaremos más adelante. Tenemos la posibilidad de almacenar estos ficheros en discos que no estén
ni tan siquiera formateados o que no tengan una partición hecha, pero este método no es el más
aconsejable. Es más razonable almacenar estos archivos en un disco ya formateado, con formato NTFS.
En empresas cuyo volumen de datos es altísimo y el trabajo que se realiza sobre la base de datos soporta
una actividad elevada, se almacenan los archivos en grupos de discos denominados RAID por hardware. Este
método mejora considerablemente el rendimiento, y nos asegura que en caso de fallos inesperados no
perdamos esa valiosa información.
Como es lógico, nosotros para realizar nuestros ejemplos, no vamos a basarnos en esta tipo de estructuras
de hardware, lo almacenaremos en nuestro disco duro, aunque veremos cómo asegurar nuestros datos
mediante planes de mantenimiento con copias de seguridad automáticas.
6.5.1. Archivo de datos
Archivo de registro de transacciones. Pero debes saber que tenemos otras posibilidades y podemos utilizar
archivos extras para mejorar el rendimiento de nuestra base de datos, podemos usar varios archivos, si
pensamos que nuestra base de datos va a alcanzar un tamaño grande. O si deseamos que nuestros datos se
almacenen en diferentes dispositivos de almacenamiento u ordenadores, y de este modo permitir un
trabajo más rápido al poder acceder a la información en paralelo.

Centrándonos en lo principal: El archivo de datos, o aquellos que añadimos como extras, son los archivos
que tendrán almacenada la información, los datos. Pero recuerda que hemos dicho que SQL Server 2008 nos
permite también crear en nuestras bases de datos, no sólo información, sino también una serie de objetos
que trabajan con la información. Pues bien, esta serie de objetos también se almacena en el archivo de
datos.
Por otro lado, tenemos el archivo de registro de transacciones. Este fichero es tan importante como el
anterior. Su importante tarea es garantizar que esa base de datos permanece integra. Gracias a estos
archivos de registros (puede haber más de uno), en caso de ser necesario, podremos recuperar la base de
datos, ya que almacena las modificaciones que se producen debido a la actividad o la explotación de la base
de datos.
6.5.2. Nombre de archivos
El modo de nombrar una base de datos, parte de una base fija, de un nombre principal que generalmente
entrega el administrador de la base de datos. Una vez que tenemos este nombre principal, SQL Server 2008
se encarga de añadir terminaciones y unas determinadas extensiones, a ese nombre principal. El
administrador además de seleccionar el nombre principal, puede elegir el destino donde se almacenarán los
ficheros que forman la base de datos.
Vamos a suponer que estamos en una empresa como administradores, y estamos creando su base de datos.
Nosotros como administradores le damos el nombre principal " miEmpresa”. Ese será el nombre de la base
de datos, pero los ficheros donde se almacenará su información y el registro de transacciones, serán:
 Archivo de datos: miEmpresa_Data.MDF
 Archivo de registro de transacciones: miEmpresa_Log.LDF
En caso de tener archivos extras, nosotros como administradores también podremos darles su nombre
principal, y la extensión que suele utilizarse es .NDF
Siguiendo con nuestra tarea de administrador, ahora sería el momento de seleccionar el lugar de
almacenamiento, como ya sabes podemos seleccionar una determinada carpeta o directorio, incluso
diferentes unidades físicas. Lo más aconsejable es guardar en diferentes unidades, por un lado el archivo de
datos, y por otro el archivo de registro de transacciones. De modo que en caso de fallo, por lo menos
tengamos uno de ellos.
6.5.3. Tamano de la base de datos
En el momento de crear la base de datos, es casi imposible conocer la cantidad de memoria que necesitará
para almacenar toda la información. Es cierto que hay ciertas técnicas que nos permiten calcular el tamaño
que podrá alcanzar la base de datos, pero estas estimaciones pueden venirse a bajo, por modificaciones
imprevistas, como puede ser el crecimiento de la empresa y que se intensifique la actividad realizada sobre
la información, por citar un ejemplo.
Tampoco es nada aconsejable pecar de precavidos y reservar una cantidad de memoria exagerada, y pensar
que con esta cantidad casi infinita no tendremos problemas de espacio para nuestros datos. De acuerdo,
puede que no haya problemas de espacio (o quizá sí), pero lo que es seguro es que tendremos muchísimos
problemas de rendimiento, de fragmentación etc...
SQL Server 2008 nos permite olvidarnos hasta cierto punto de este problema. Los archivos de datos y de
registro, crecen automáticamente. No crecen con cada dato que se añade. Nosotros como administradores,
le daremos un tamaño inicial sencillo de estimar (una cantidad muy pequeña, unos Megabytes), en ese
momento SQL Server 2008 crea la estructura correcta para la base de datos, y una vez que nuestra base de
datos está en explotación cuando alcanza el tamaño limite, lo incrementa una cantidad dada por un factor
predeterminado.
Visto de modo teórico puede asustar un poco, sólo estamos comenzando a crear la base de datos, y estamos
mencionando varias características a tener en cuenta. No tenemos porque asustarnos, veremos como estos
parámetros se pueden dar de un modo altamente sencillo mediante el interfaz de SQL Server 2008, y como

con pocos clicks, todos estos aspectos los realiza SQL Server por nosotros, así que no te preocupes y sigue
leyendo.
6.6. Estructura logica

Para entender que es la estructura lógica de una base de datos vamos a poner un sencillo ejemplo. Cuando
nosotros nos compramos un equipo de música, poco nos importa como funcionan los circuitos integrados,
los elementos electrónicos que componen nuestro equipo. En este caso, esos circuitos, esos dispositivos
electrónicos, sería la estructura física del equipo de música, al igual que hemos visto la estructura física de
nuestra base de datos.
A lo que nosotros como usuarios vamos a dar importancia es al manejo del equipo de música: como subir el
volumen, encenderlo, cambiar de emisoras, introducir un CD. De igual modo, como usuarios de la base
datos, debemos conocer la estructura lógica de la base de datos para poder gestionar o trabajar con los
datos.
Una estructura lógica mínima puede ser el ejemplo de la librería que hemos visto a modo de introducción en
esta lección.
Lo que vamos a exponer a continuación a modo de introducción son los elementos principales que
componen la estructura lógica de una base de datos, de modo que sepas de qué estamos hablando en caso
de que se mencionen en las diferentes lecciones. Sin embargo, los iremos viendo con más detenimiento más
adelante, de momento es suficiente con que te suenen y las vayas conociendo.
6.7. Tablas
Las tablas son las unidades que almacenan los datos. Como norma general se suele imponer que cada tabla,
almacena información común sobre una entidad en particular (recuerda los libros). Esta norma se conoce
como normalización.
La mayor parte de la actividad producida en una base de datos se produce sobre las tablas, siendo las
principales tareas las siguientes:
 Añadir información.

 Eliminar información.
 Modificar y actualizar información.
 Recoger información y mostrarla.
Comúnmente estas cuatro tareas se realizan mediante el lenguaje SQL (Structured Query Language) que
significa Lenguaje de consultas estructurado, que como ya sabrás es el lenguaje estándar para gestionar
bases de datos.
6.8. Campos y registros

Las tablas están compuestas de registros y campos. Si imaginamos el diseño de una tabla, como si de una
cuadrícula se tratase, sabemos que está compuesta por varias filas y columnas. Las filas corresponden a los
registros, mientras que las columnas serían los campos. Y cada una de las celdas que se forman de enlazar
un registro (fila) con un campo (columna) formaría una celda, la cual almacena un valor. Por lo tanto, un
registro esta formado por varios campos, y cada campo almacena un determinado valor.
Acabamos de mencionar que en cada celda se almacena un valor. Pero ¿siempre debe almacenar un valor?
que sucede si estamos almacenando información de un determinado producto, y en el momento de
almacenarlo desconocemos una de sus características (un valor). En ese caso ¿no podríamos almacenarlo?
Lógicamente la respuesta a esta pregunta es que sí, por supuesto que podríamos almacenarlo. Tenemos la
posibilidad de almacenar valores nulos para este caso que hemos visto y muchos otros. Los valores nulos se
conocen como NULL, pero aunque se conoce como valor nulo, no debes pensar que se almacena un valor, el
concepto de NULL podría ser un marcador que informa que hay que pasar por alto los datos de esa celda,
son datos que se ignoran. Como veremos, hay que tener mucho cuidado con el uso de esta "ausencia" de
información, ya que si tenemos algún despiste puede ser el causante de que no recibamos la información
que realmente estamos reclamando en una consulta. Si realizamos operaciones matemáticas con varios
valores de nuestra base de datos y uno de estos es NULL, el resultado siempre será NULL.
6.9. Indices
Seguimos hablando de la unidad o entidad principal de la base de datos, las tablas. Podemos tener tablas
con millones de registros, si realizamos una consulta para recuperar información de un grupo de estos
registros, podemos tener un rendimiento bajo debido a la gran cantidad de información que almacena esa
tabla. Sitúate en una tabla que almacena las ventas de productos que se han producido durante décadas en
una gran empresa, y queremos recoger la información de una determinada venta. El proceso de búsqueda

recorriendo cada uno de esos registros (ventas) de la tabla de principio a fin, puede necesitar un tiempo
considerable hasta que encuentra la información deseada.
Para acelerar este tipo de consultas contamos con la ayuda de los índices. Un índice es una característica
más de las tablas, el cual es un conjunto de valores clave. Este conjunto tiene una estructura estudiada para
que el servidor pueda realizar las consultas con un rendimiento mucho mayor.
Estos valores claves pueden almacenar el contenido de una o varias columnas de la tabla sobre la que
operan.
Además de mejorar el rendimiento, existen índices que pueden asegurar la integridad de los datos,
indicando en que orden deben almacenarse los datos en una tabla. Más adelante veremos como trabajar
con los índices.
Por lo tanto podemos decir que teóricamente nuestras tablas deberían, incluir al menos un índice que
asegure un mejor rendimiento. Y en la práctica, suele ser lo más común, pero debes tener en cuenta que
cada vez que realizamos una tarea sobre una tabla que está relacionada con índices, el servidor, no sólo
opera sobre la tabla para realizar las modificaciones que se le demanden, sino que también debe realizar
operaciones sobre los índices para asegurar que la labor de estos sigue siendo la adecuado para las
modificaciones realizadas sobre la información de la tabla. Por lo tanto la regla de tres es sencilla, a mayor
número de índices, mas tiempo dedicará a las tareas pedidas.
6.10. Constraints o Restricciones

Los Constraints son normas que imponemos a la información que puede ser almacenada, de modo que si no
se cumple una de estas condiciones no permitamos que incluya ese valor en nuestra base de datos. Si
tenemos una tabla de clientes, podríamos poner como restricción que no se pueda almacenar un cliente
cuya edad no supere los 18 años. El servidor se encargará de no permitir que se incluya ningún registro que
incumpla nuestra condición.
Estas restricciones además de permitir controlar que valores pueden ser almacenadas, con esta tarea
aseguramos también la integridad de nuestros datos. Piensa que por descuido un usuario introduce por
error un cero como el número de unidades que se han vendido a un minorista. Al calcular el precio de la
venta y multiplicarlo por cero unidades, tendremos como precio de facturación cero.
Pero no sólo debemos pensar en que es el usuario quien comete el error, puede que el programador que ha
desarrollado un software de facturación haya cometido un error al escribir el código. El programa por sí sólo,
si no ha tenido en cuenta esta posibilidad, no lanzará ningún error, y todo parecerá ir correctamente y
emitirá la factura al minorista. Pero gracias al servidor de base de datos, podemos tener controlado que uso
hace el software que trabaja con nuestros datos.
6.11. Vistas
Las consultas que se realizan sobre algunas de las tablas de la base de datos pueden ser repetitivas, de modo
que día tras día cientos de usuarios realizan las mismas consultas sobre la tabla. Todas esas consultas
repetitivas reciben el mismo grupo de datos. Para evitar la repetición de este tipo de consultas tenemos las
vistas.
Podemos pensar que una vista es un conjunto de registros determinados de una o varias tablas. De hecho se
trabaja sobre ella como una tabla, pero no es una tabla. Lo que almacena en realidad es una consulta. Pero
debes tener claro que no almacena datos sino que los extrae. Una vista puede crear los enlaces necesarios
para obtener información de varias tablas como si fuese una única tabla. Esto puede facilitar mucho la tarea
al desarrollador de software que no tiene que preocuparse de las tablas donde se almacena la información
que quiere recoger, ya que lo tiene todo en una vista sobre la que puede operar como si fuese una tabla. Por

lo tanto se olvida de construir complicadas sentencias de SQL que recoja esa información de múltiples
tablas, con diferentes enlaces entre ellas.
6.12. SQL
Las consultas y las tareas de gestión que se realizan durante la explotación de una base de datos vienen
escritas en lenguaje SQL, Structured Query Language, que como ya hemos mencionado significa Lenguaje de
Consulta Estructurado.
El ANSI (Instituto Nacional de Normalización Estadounidense) ideo este lenguaje estándar, denominado ANSI
SQL, o también SQL-92, por el último año en el que ANSI aceptó modificaciones sobre el estándar.
Como suele ocurrir en tantas ocasiones en el mundo del mercado informático. Este estándar fue recogido
por los fabricantes para personalizarlos y crear sus propias extensiones para sus productos. Microsoft así lo
hizo, para crear Transact-SQL, o más comúnmente conocido por su abreviatura T-SQL para sus servidores de
base de datos SQL Server.
Como veremos, SQL Server 2008 y sus antecesores, pueden trabajar con SQL, pero gracias a T-SQL podemos
realizar sentencias más completas que solventarán fácilmente problemas. Por lo tanto T-SQL no es un
sucesor de SQL para nosotros, sino una ampliación, una herramienta extra que utilizaremos para fines más
avanzados.
6.13. Procedimientos almacenados

SQL Server no sólo puede ejecutar las consultas de las tablas, o las vistas que ya hemos visto. También
permite que desarrollemos procedimientos con código escrito íntegramente en SQL o con la ayuda extra de
T-SQL. Tanto con el estándar como con la versión de Microsoft, podemos crear sentencias que vayan más
allá de consultas, ya que como lenguajes de programación que son, pueden contener sentencias
condicionales, bucles, etc... Si nunca te has introducido en ningún lenguaje de programación, no te
preocupes porque veremos estos conocimientos con detenimiento, y si ya conoces otros lenguajes de
programación, aprenderás la sintaxis específica de este lenguaje.
Los procedimientos almacenados, como cualquier función de otro lenguaje, pueden recibir parámetros de
entrada y de salida, o no recibir ni devolver nada. Además de devolver parámetros, pueden devolver incluso
tablas virtuales, vistas, etc...
Los procedimientos almacenados los almacena SQL Server 2008 del modo más óptimo para sacarles el mejor
rendimiento posible. De este modo las instrucciones quedan almacenadas en la propia base de datos. Esto
es una gran ventaja, en cuanto a seguridad y rendimiento, ya que los programas desarrollados por los
programadores no necesitan tener estas sentencias SQL en el código de su software, y por lo tanto esta
información que supone el propio código SQL, no tiene que "viajar" del programa a la base de datos. Y como
es lógico pensar, cuanta menos información "viaje" del programa del cliente al servidor, ganaremos en
seguridad y en rendimiento.
6.14. Programación con transact SQL

Debemos comenzar diciendo que es el SQL; es un lenguaje de consultas para los sistemas de bases de datos
relacionales, pero que no posee la potencia de los lenguajes de programación. Nos permite el uso de
variables, estructuras de control de flujo, bucles... y demás elementos caracteristicos de la programación. No
es de extrañar, SQL es un lenguaje de consulta, no un lenguaje de programación.

Sin embargo, SQL es la herramienta ideal para trabajar con bases de datos. Cuando se desea realizar una
aplicación completa para el manejo de una base de datos relacional, resulta necesario utilizar alguna
herramienta que soporte la capacidad de consulta del SQL y la versatilidad de los lenguajes de programación
tradicionales. Transact SQL es el lenguaje de programación que proporciona Microsoft SQL Server para
extender el SQL estándar con otro tipo de instrucciones y elementos propios de los lenguajes de
programación.
Con Transact SQL vamos a poder programar las unidades de programa de la base de datos SQL Server, están
son:
 Procedimientos almacenados
 Funciones
 Triggers
 Scripts
7. Instalación de SQL Server
7.1. Requisitos
Los requisitos siguientes se aplican a todas las instalaciones de SQL Server 2008:
Compomente Requisito
Frameworks El programa de instalación de SQL Server instala
los siguientes componentes de software
requeridos por el producto:
.NET Framework 3.5 SP11
SQL Server Native Client
Archivos auxiliares para la instalación de SQL
Server
Software El programa de instalación de SQL Server requiere
Microsoft Windows Installer 4.5 o una versión
posterior
Una vez instalados los componentes requeridos, el
programa de instalación de SQL Server
comprobará que el equipo en el que se ha
instalado SQL Server 2008 también cumple los
demás requisitos para su correcta instalación. Para
obtener más información, vea Comprobar los
parámetros del Comprobador de configuración del
sistema.
Software de red
Los requisitos de software de red para las
versiones de 64 bits de SQL Server 2008 son los
mismos que para las versiones de 32 bits.
Los sistemas operativos compatibles tienen el
software de red integrado. Las instancias
predeterminadas y con nombre independientes
admiten los siguientes protocolos de red:
 Memoria compartida
 Canalizaciones con nombre
 TCP/IP
 VIA

Nota: La memoria compartida y VIA no se admiten
en clústeres de conmutación por error.
Virtualización SQL Server 2008 es compatible con entornos de
máquina virtual que se ejecutan en la función
Hyper-V de las ediciones Standard, Enterprise y
Datacenter de Windows Server 2008 R2
y Windows Server 2008. La máquina virtual debe
ejecutarse en un sistema operativo compatible con
la edición de SQL Server 2008 concreta que se cita
más adelante en este tema.
Además de los recursos requeridos por la partición

primaria, a cada máquina virtual (partición
secundaria) se debe proporcionar suficientes
recursos de procesador, memoria y recursos de
disco para su instancia de SQL Server 2008. Los
requisitos se enumeran más adelante en este
tema.
Dentro de la función Hyper-V de Windows Server

2008, se puede asignar un máximo de cuatro
procesadores virtuales a máquinas virtuales que
ejecuten las ediciones de 32 o 64 bits de Windows
Server 2008. Se pueden asignar como máximo 2
procesadores virtuales a equipos virtuales que
ejecuten ediciones de 32 bits de Windows Server
2003. Para equipos virtuales que alojan otros
sistemas operativos, se puede asignar como
máximo un procesador virtual a equipos virtuales.
Notas:
Se recomienda cerrar SQL Server 2008 antes de
apagar la máquina virtual. La agrupación en
clústeres de conmutación por error del invitado se
admite en SQL Server 2008. Para obtener más
información sobre las versiones admitidas de SQL
Server y los sistemas operativos para la agrupación
en clústeres de conmutación por error del invitado,
y la compatibilidad con la virtualización, vea el
tema que trata sobre la directiva de
compatibilidad para los productos de Microsoft
SQL Server que se ejecutan en un entorno virtual
de hardware. Para obtener más información sobre
la función Hyper-V de Windows Server 2008, vea
el sitio web de Windows Server 2008.
Software de Internet Para todas las instalaciones de SQL Server 2008 se
requiere Microsoft Internet Explorer 6 SP 1 o una
versión posterior. Se requiere Internet Explorer 6
Service Pack 1 o una versión posterior para
Microsoft Management Console (MMC), SQL
Server Management Studio, Business Intelligence

Development Studio, el componente Diseñador de
informes de Reporting Services y la Ayuda HTML.
Disco duro Las necesidades de espacio en disco variarán con
los componentes de SQL Server 2008 que instale.
Para obtener más información, vea Requisitos de
espacio en disco duro, más adelante en este tema.
Unidad Óptica Para la instalación desde disco se necesita una
unidad de CD o DVD.
Pantalla Las herramientas gráficas de SQL Server 2008
requieren VGA o una resolución mayor: resolución
mínima de 1.024 x 768 píxeles.
Otros dispositivos Dispositivo señalador: se necesita un mouse
Microsoft o dispositivo señalador compatible.
Se requieren las versiones siguientes de .NET Framework:

 SQL Server 2008 en Windows Server 2003 (64 bits) IA64: .NET Framework 2.0 SP2
 SQL Server Express: .NET Framework 2.0 SP2
 Todas las demás ediciones de SQL Server 2008: .NET Framework 3.5 SP1
La instalación de .NET Framework requiere reiniciar el sistema operativo. Si la instalación de Windows

Installer también requiere un reinicio, el programa de instalación esperará hasta que se hayan instalado los
componentes de .NET Framework y Windows Installer antes de reiniciar.
NOTAS:
 Instalar .NET Framework 2.0 SP2: .NET Framework 2.0 SP2 no está disponible como descarga
independiente. Necesitará instalar .NET Framework 3.5 SP1 que incluye .NET Framework 2.0 SP2.
 El programa de instalación de SQL Server no instalará los componentes necesarios siguientes para
SQL Server Express, SQL Server Express con herramientas, y SQL Server Express con Advanced
Services. Debe instalar estos componentes manualmente antes de ejecutar el programa de
instalación de SQL Server:
 SQL Server Express: .NET Framework 2.0 SP2 y Windows Installer 4.5. En Windows Vista, use .NET
Framework 3.5 SP1.
 SQL Server Express con Advanced Services: .NET Framework 3.5 SP1, Windows Installer 4.5 y
Windows PowerShell 1.0.
 SQL Server Express con las herramientas: .NET Framework 3.5 SP1, Windows Installer 4.5 y
Windows PowerShell 1.0.

7.2. Instalando SQL Server

En esta ocasión veremos cómo es el proceso de instalación de SQL SERVER 2008 en nuestros servidores de
Windows Server 2008 y/o Windows Server 2003.
Al empezar a instalar SQL SERVER 2008, nos aparecerá una ventana que nos indicará que el programa está
procesando la operación para abrir el asistente de instalación

Luego de unos segundos, el programa nos abrirá la ventana Centro de Instalación de SQL Server con un
menú en la parte izquierda con 7 (siete) Indices;
 Planeamiento
 Instalación
 Mantenimiento
 Herramientas
 Recursos
 Avanzadas
 Opciones
7.3. Proceso de instalación

Explicaremos la instalación de la versión gratuita que será con la que trabajaremos en este material, desde
que se lanzó al mercado SQL Server 2008, han añadido una versión más avanzada a SQL Server 2008 Express
Edition, que por suerte incluye alguna herramienta más avanzada que la que en un principio publicaron. La
versión se denomina Microsoft SQL Server 2008 Express Edition with Advanced Services. Para descargarte
esta versión pincha en el siguiente enlace:
Microsoft SQL Server 2008 Express Edition with Advanced Services
Recuerda seleccionar la descarga en función de tu tipo de procesador, para 32 bits seleccionaremos la
familia x86:
Ejecutamos el programa de instalación y tras descomprimir en nuestro equipo los paquetes necesarios para
llevar a cabo la instalación, lo primero que tenemos es el contrato de licencia.

Aceptamos las condiciones y proseguimos con el asistente. En la siguiente ventana nos indica las diferentes
opciones que nos ofrece la "central" de instalación del producto. En el panel de la izquierda podremos ir
seleccionando los diferentes módulos y en el panel principal encontraremos todas las opciones que tenemos
con una breve descripción de cada una.
El primer módulo es el de Planeamiento, donde encontramos documentación previa sobre la versión 2008
que puedo ayudarnos en la toma de decisiones a la hora de instalar:
En el segundo módulo tenemos el que nos ocupa este primer capítulo del curso, la instalación. En él
podremos seleccionar los diferentes tipos de instalaciones y actualizaciones que nos permita el asistente:

En tercer lugar tenemos el módulo sobre Mantenimiento, donde encontramos las tres opciones para
actualizar entre ediciones de SQL Server 2008, reparar instalaciones o eliminación de nodos.
En el módulo Herramientas podremos acceder a información sobre si cumplimos requisitos mínimos, sobre
instalaciones de versiones previas que podamos tener en nuestro equipo, o actualizaciones de herramientas
de versiones anteriores a 2008.

En el módulo Recursos, tendremos una serie de descargas para obtener información, documentación,
descargas, foros, etc... Sobre SQL Server 2008.
En el penúltimo módulo encontramos "Avanzadas", donde podremos hacer una instalación avanzada a
partir de archivos de configuración y agrupaciones por clústeres

Por último encontramos el módulo "Opciones", donde no haremos nada ya que las rutas que ofrece como
defecto son donde se encuentran los archivos necesarios para la instalación.
Para comenzar, por fin, con la instalación volvemos a nuestro módulo de Instalación, y seleccionamos el tipo
de instalación que nos interesa, en este caso una instalación limpia de inicio de SQL Server 2008:

El primer paso que realiza el asistente es comprobar las "reglas auxiliares" donde realiza una comprobación
de los posibles errores que se pueda encontrar al guardar los ficheros auxiliares que se necesitan para llevar
a cabo la instalación del software.
En caso de que todo resulte correcto y no encuentre problemas, pulsamos en "Aceptar" para continuar con
el siguiente paso, donde nos pedirá lo números de serie en caso de tratarse de una versión de pago,
nosotros al realizar la instalación de la versión gratuita, pulsamos directamente en "Siguiente" para
continuar ya que no necesitamos validar nuestra licencia:
Aceptamos los términos de la licencia de la edición que estamos instalando:

Y comenzamos con la instalación de los archivos auxiliares, pulsando sobre el botón "Instalación":
En el siguiente paso seleccionamos las características que vamos a instalar sobre nuestro equipo, como
estamos con la versión que incluye características avanzadas de la edición Express, vamos a seleccionar
todas, aunque en este curso no veremos todas ellas.

En el siguiente paso nos piden el nombre que daremos a la instancia que estamos instalando y la carpeta
donde se realizará la instalación, dejaremos las opciones por defecto como puedes ver en la siguiente
captura:
En el próximo paso, simplemente nos informan de los requisitos de espacio en disco de la instalación en
función de las características que hemos seleccionado previamente:

La siguiente pantalla requiere que le prestemos algo más de atención. En ella configuramos la cuenta y el
tipo de inicio que tendrán los servicios del SQL Server, seleccionamos la cuenta de "Servicio de red" para
todas los servicios de SQL Server, y un tipo de inicio automático para el motor de base de datos. De este
modo nos aseguramos que el servicio de SQL Server se inicie de manera automática al iniciar el sistema
operativo. Esta característica puede no ser importante en un principio para seguir el curso, pero si pensamos
en un servidor de explotación de bases de datos donde puede sufrir algún reinicio inesperado, esto nos
garantiza que al arrancar de nuevo el servidor sea capaz de ofrecer los servicios que interesan de SQL Server.
En la configuración de Reporting Services, seleccionamos la primera opción que nos instalará el servicio de
generación de informes por defecto:
7

Continuamos con la configuración del Motor de base de datos, donde indicaremos el modo de
autentificación que utilizaremos para iniciar sesión en SQL Server. Tenemos dos modos de autenticación:
 Windows
 Mixto (Windows y SQL Server)
De estas dos opciones, como veremos más adelante, la más segura de toda es utilizar autenticación
Windows, ya que de este modo en programas clientes que conecten con nuestro servidor evitamos el envío
de información privada por la red, que puede ser interceptada y utilizada para dañar nuestro sistema. De
todos modos veremos más adelante que podemos añadir diferentes modos de registro para la conexión con
el servidor de base de datos. Por lo tanto seleccionamos "Modo de autenticación de Windows", yo en mi
caso he iniciado sesión en el sistema operativo con el usuario "Administrador" que será el mismo que quiero
para trabajar con SQL Server así que pulso sobre el botón "Agregar usuario actual" para que añada esta
cuenta como Administrador de SQL Server:
Continuando con el asistente nos pide "permiso" para enviar a Microsoft los errores que puedan darse sobre
el servidor de base de datos, e informes del uso que hacemos de las herramientas, todo esto para que
Microsoft tenga datos para llevar a cabo actualizaciones para solucionar errores o mejoras para el
rendimiento.

El asistente continúa con una nueva comprobación que determinará si el sistema puede bloquearse
mientras dura el proceso de instalación, si todo está correcto podremos continuar con la instalación:
La siguiente pantalla nos mostrará un resumen de las características y las opciones con las que hemos
determinado que se instalar SQL Server 2008 en nuestro ordenador:

Pulsamos sobre el botón "Instalación" y comienza la instalación que podrá durar unos minutos:
Si todo va correctamente, nos indicará que todas las características y tareas se han completado
correctamente:

Y con este habremos terminado la instalación de SQL Server 2008:
Pulsamos en Cerrar y fin de la instalación. Como hemos dicho, son varios pasos y puede parecer un proceso
largo, pero como habrás podido comprobar el asistente se ocupa de todo y no es muy complicado.
Para realizar la primera prueba, vamos a inicio -> programas y ejecutaremos "SQL Server Management
Studio":

La primera vez que se ejecuta realiza una configuración previa del entorno de trabajo:
Una vez finalizada esta configuración, nos muestra la pantalla de presentación mientras que trabaja en
segundo plano para lanzar la herramienta.
Lo primero que nos muestra cuando arrancamos SQL Server 2008, es una ventana para seleccionar el modo
de autorización con el que vamos a conectar al servidor:
Si has llegado hasta este punto, enhorabuena, hemos conseguido instalar correctamente SQL Server 2008 en
nuestro equipo y ya tenemos todo lo necesario para comenzar a practicar con las características de este
servidor de base de datos.
8. Sql server configuration manager

El Administrador de configuración de SQL Server es una herramienta para administrar los servicios asociados
a SQL Server, para configurar los protocolos de red utilizados por SQL Server y para administrar la
configuración de conectividad de red de los equipos cliente de SQL Server. El Administrador de configuración
de SQL Server es un complemento de Microsoft Management Console que está disponible desde el menú

Inicio o que se puede agregar a cualquier otra pantalla de Microsoft Management Console.Microsoft
Management Console (mmc.exe) utiliza el archivo SQLServerManager10.msc de la carpeta System32 de
Windows para abrir el Administrador de configuración de SQL Server.
Para poder entrar a la herramienta realizamos los siguientes pasos según la grafica
Veremos la pantalla siguiente
9. Planificacion del diseño de la base de datos

Para aquellas personas que han trabajado con desarrollo de software, entenderán que la planificación de un
programa en uno de los aspectos más importantes para un buen programa.
Cuando vamos a comenzar a crear una base de datos, el principio de todo no es arrancar nuestra
herramienta de SQL Server 2008, Management Studio, y mediante sus asistentes ponernos directamente a
crear nuestra base de datos, con sus tablas, etc...
Siempre debemos comenzar realizando un análisis de las necesidades que tenemos. Una vez que conocemos
las necesidades y partiendo de estas, definimos la estructura lógica de nuestra base de datos, y por último
pasamos a diseñarla, bien sea en papel, o mediante las herramientas de diseño que nos ofrece SQL Server
2008.

Por lo tanto tenemos diferenciados claramente tres pasos previos a la hora de planificar la creación de una
base de datos:
 Estudio y análisis de las necesidades.
 Definición de los elementos que componen la estructura lógica de la base de datos.
 Diseñar o plasmar esa estructura con diagramas en papel, o con SQL Server 2008.
Estos pasos son importantísimos, en este tipo de desarrollos no podemos utilizar el método de ir probando
estructuras hasta que funcionen, y una vez que funciona dar por sentado, que nuestra base de datos está
bien diseñada y ya podemos instalarla en un servidor para que se comience a trabajar con ella.
La planificación debe prevenirnos de imprevistos que pueden surgir, y ya no sólo imprevistos del tipo que si
tenemos mayor o menor actividad en la base de datos, hablamos de imprevistos que provocan que
tengamos que rediseñar nuestras estructuras. Una vez que tenemos la base de datos en explotación, nos
encontraremos con el problema de que será muy difícil realizar modificaciones sobre ella, ya que el método
de trabajo que marcamos al definir nuestras estructuras, limita las posibles modificaciones futuras.
Con esto puedes hacerte una idea de lo que supone la planificación, invertir tiempo en estos primeros pasos,
significa ahorrarnos tiempo en un futuro de posibles modificaciones.
9.1. Estudio de necesidades.

Como hemos dicho, se trata del primer paso que debemos analizar.
En este paso, tendremos que estudiar detenidamente que tipo de necesidad tiene nuestro cliente. Serán
necesarias tantas reuniones como creamos oportunas para que el cliente nos explique cuál es la información
desea almacenar en nuestra base de datos. Una vez tenemos claro la información fundamental para el
trabajo cotidiano de la empresa de nuestro cliente, tendremos que tener pleno conocimiento, de que
trabajo quiere hacer con esa información, es decir ¿Cuáles son los resultados que va a requerir de esa
información.
Una vez, que tenemos todo lo necesario para conocer que necesidades tenemos que cubrir con nuestra base
de datos, procedemos a identificar todos los objetos que necesitamos, con sus atributos y propiedades, y
también como estarán relacionados unos con otros. Estos objetos se convertirán más adelante en tablas,
vistas, índices, procedimientos almacenados, etc...
Es lógico pensar que estos objetos que hemos planificados no serán los definitivos ni mucho menos, durante
la etapa de diseño y normalización que explicaremos más adelante nos irán surgiendo nuestras propias
necesidades para cumplir con los objetivos que nos hemos marcado con nuestro cliente, o los encargados de
informarnos en la empresa que estamos contratados.
Lo que si debe ser definitivo (en la medida de lo posible) son los elementos que integran la base de datos, las
entidades de información que debemos almacenar. Deberemos identificar estos elementos, de modo que
podamos distinguir fácilmente unos de otros. Y más adelante, durante la planificación iremos encontrando
las relaciones y dependencias que tienen unos con otros. Para entender mejor esta definición vamos a poner
un ejemplo. Vamos a suponer que tenemos como cliente a una empresa que se dedica a la venta de
refrescos.
El primer paso es definir las necesidades que surgen de estudiar el funcionamiento de esta empresa. Por lo
tanto comenzamos describiendo el funcionamiento de la empresa.Nuestra empresa se dedica
principalmente a la venta de bebidas, estas bebidas las producen los fabricantes y las recibimos de estas a
través de unas distribuidoras a las que previamente habremos realizado unos pedidos. Una vez que hemos
recibido los pedidos, estos permanecen en nuestro almacén, para que podamos realizar las ventas a
nuestros clientes. Está claro que una empresa de bebidas tiene un funcionamiento mucho más complejo
que lo que acabamos de definir, pero para el objetivo que buscamos, nos es suficiente. Hemos subrayado las
entidades de información que han ido surgiendo en la descripción de las necesidades de la empresa que

hemos tomado como ejemplo. Todas estas entidades forman un conjunto de entidades, como puedes ver en
la siguiente figura:
9.2. Planificación
Una vez que tenemos descrita y definida la información de la etapa de análisis de necesidades y de las
indicaciones del trabajo que se desea realizar sobre esas entidades marcadas, comenzamos con la etapa de
planificación de la base de datos.
La etapa de planificación tiene el objetivo de definir las diferentes propiedades de cada entidad y analizar
qué relaciones serán necesarias entre ellas o con más elementos o entidades.
A primera vista, parece claro que cada una de las entidades de nuestro conjunto puede ser representada en
una tabla en nuestra base de datos final.
Las propiedades de cada una de estas tablas, no son otra cosa que las columnas o campos que la van a
formar. Es decir, los datos que nos interesa almacenar para las bebidas, pedidos, clientes, fabricantes etc...
Otra característica a definir en esta etapa son las dependencias que tendrán las tablas. ¿A qué cliente
estamos realizando una venta? ¿Qué fabricante ha producido una determinada bebida?
Una vez realizado este estudio, continuamos con un proceso de normalización, el cual modificará el número
de entidades o tablas, de tal manera que puede aumentar el número de tablas pero disminuir la cantidad de
información que almacena en cada una. Este proceso de normalización es de vital importancia, y lo
estudiaremos con detenimiento en este mismo capítulo.
9.3. Propiedades

Partiendo de las entidades que hemos definido en nuestro conjunto como resultado del estudio de
necesidades, vamos a analizar las propiedades de cada una de estas entidades.
Comenzamos con la más lógica, Bebidas. ¿Cuáles podrían ser las propiedades fundamentales? Piensa por
ejemplo que dato te interesaría para realizar una búsqueda: el nombre de la bebida, y el fabricante.
También necesitaremos saber que distribuidora nos ha entregado esa bebida. Estas propiedades o campos y
los anteriores, son los esenciales para cada bebida, por último podremos añadir otros campos que nos
interesen, precio, el envase, cantidad, fecha de caducidad, si es alcohólica o no, en caso de ser alcohólica los
grados y el número de lote.
Con estas propiedades ya podemos definir las columnas o campos de nuestra tabla Bebidasy del mismo
modo podemos ir definiendo las propiedades del resto de las tablas que representan nuestras entidades en
la base de datos
Todas estas propiedades definidas para cada tabla, son de carácter temporal y no son definitivas, veremos
como en el proceso de normalización, tendremos que realizar modificaciones como ya hemos comentado
9.4. Dependencias
Hemos visto como las tablas formaban un conjunto de entidades. Nunca debes pensar en una tabla como un
elemento aislado, cada una de las tablas forma parte de nuestro conjunto, y el conjunto vendría a ser la base
de datos. Por lo tanto, cada tabla es la parte de un nivel superior y no puede ser tratada individualmente, ya
que como parte de un todo, tendrá dependencias con el resto de tablas de la base de datos.
Ese es precisamente el trabajo que debemos llevar a cabo ahora, analizar las dependencias que tiene cada
tabla con el resto para poder representarla la estructura lógica de la base de datos.
Estas dependencias reciben el nombre de relaciones, y estudiaremos que tipo de relaciones podemos tener,
de momento, para nuestro ejemplo las veremos de un modo muy sencillo. Podemos encontrarnos tablas

que dependen únicamente de una segunda tabla, mientras que habrá otras que dependerán de varias. Otro
caso que nos podemos encontrar son tablas que tienen una relación única, como iremos viendo.
Cojamos el ejemplo de las tablas Bebidas y Distribuidoras, estas tablas tendrán una relación entre ellas de
"uno a muchos". La razón de porqué tendrán esta relación y porqué recibe esa descripción de "uno a
muchos" es la siguiente. Está claro, que en la tabla distribuidoras almacenamos los datos de cada una de las
distribuidoras que tenemos, y que lógicamente una distribuidora, aparecerá sólo una vez en esta tabla, es
absurdo tener repetida la misma información. En cambio, si vamos a la tabla bebidas, donde almacenamos
cada bebida, sabemos que una distribuidora no nos entregará una única bebida, sino varias. Por lo tanto,
tendremos varias bebidas que han sido entregadas por la misma distribuidora.
Resumiendo, una distribuidora sólo aparece una vez en la tabla distribuidoras, mientras que en la tabla
bebidas aparecerá muchas veces (no sabemos cuántas). Por eso afirmamos que la relación entre estas tablas
es de una (distribuidora) a muchas (bebidas). Si representamos de modo gráfico esta relación podría ser
como ves en la siguiente figura:
Tomemos ahora como ejemplo la relación entre las tablas Bebidas y Almacén.
La dependencia entre estas tablas es una relación "uno a uno", el motivo es el siguiente. Cada una de las
bebidas que tenemos en nuestra tabla bebidas, tiene una situación determinada en el almacén, por lo tanto,
existirán las mismas filas en la tabla almacén como tenemos en la tabla bebida. Así pues a un registro de la
tabla bebida le corresponde un registro en la tabla almacén. De ahí la definición de relación uno a uno.
Podemos representar esta relación gráficamente de la siguiente forma
Si continuamos con el mismo estudio de dependencias con el resto de la tabla de nuestra base de datos,
veremos que la tabla ventas depende de los clientes con relación uno a muchos y a su vez depende de la
tabla bebidas, y la tabla almacén teniendo dependencias de varias tablas. Si representamos todas estas
relaciones tendremos:

Estudia con detenimiento la figura anterior, y trata de entender las dependencias que hemos representado,
y el motivo de estas relaciones a partir de los ejemplos de relaciones uno a uno y uno a mucho que hemos
descrito anteriormente.
9.5. Normalizacion
La normalización es el mecanismo de toma de decisiones con el objetivo de recoger todos los datos de la
información que se almacenará en una base de datos y distribuirlos en tablas.
Para tomar estas decisiones tenemos un número de formas normales que nos ayudará a diseñar la mejor
estructura lógica con el mayor rendimiento posible.
Las formas normales, son los modelos o maneras en que se pueden representar la estructura de tablas.
Gracias a estos modelos conseguiremos mayor eficacia. Pero no entiendas por eficacia como una reducción
del tamaño, nos estamos refiriendo a que obtendremos una estructura muy bien organizada, de tal modo
que será escalable fácilmente, permitiendo realizar modificaciones en un futuro sin muchos problemas.
Aunque habrá veces donde gracias a la normalización también se reduzca el tamaño, este no es el objetivo
que buscamos.
La función de la normalización es favorecer la integridad de los datos, sin importar la actividad que se
desarrolle sobre la base de datos. Trata de evitar lo máximo posible la posibilidad de introducir datos que no
sean razonables. Dentro del proceso de normalización podemos distinguir cuatro tipos de integridades:
 Integridad de entidad.
 Integridad de dominio.
 Integridad referencial.
 Integridad definida por el usuario.
Vamos a explicar cada una de estas integridades y al final de cada una nombraremos que herramientas nos
ofrece SQL Server 2008 para cumplir con estas integridades, si desconoces estas herramientas, tranquilo
porque las veremos con más detenimiento en las siguientes lecciones, tan sólo que te suene para cuando
lleguemos a verlas con más detenimiento.

9.6. Integridad de entidad
Hasta ahora hemos utilizado en varias ocasiones la palabra entidad. Una entidad se define como un
concepto del mundo real, de modo que nuestras bases de datos guardan información sobre entidades. Estas
entidades pueden ser de diferente carácter:
 Entidades físicas: un libro, una bebida, un empleado
 Entidades conceptuales: una empresa
 Entidades como eventos: una alerta de nuestra agenda que nos recuerda una tarea.
Uno de los pasos de nuestro proceso de planificación es detectar estas entidades que están relacionadas con
la base de datos. La integridad de entidad pretende que cada entidad que se guarda en la base de datos sea
identificable de un modo único, es decir, que evitemos la información redundante.
Ahora bien, la identificación de entidades no es única, podemos tener varios modos de entidad para un
mismo objeto real. Por ejemplo, seguimos con el ejemplo de nuestra empresa dedicada a la venta de
bebidas, podríamos identificar las bebidas de un modo general, a un modo más individual:
 Todas las bebidas en un sólo grupo.
 Todas las bebidas de la misma marca en un grupo.
 Agrupar las bebidas en función de si son alcohólicas o no.
 Cada bebida de modo individual.
Un hecho sobre una determinada bebida, como puede ser el sabor de un refresco.
¿Qué criterio debemos seguir entonces para identificar que es una entidad en nuestra base de datos?
La respuesta a esta pregunta dependerá de lo que deseemos hacer con estos datos. Lo más razonable es que
se identifique como entidad aquellas cosas con las que vas a trabajar de modo unitario. Dicho de un modo
más claro, la información que se almacena unida (de modo unitario) es más cómodo trabajar con ella, o
recuperar esa información en una única operación.
Para tomar estas decisiones, simplemente debes realizarte las preguntas de la función que deseas realizar
sobre los datos. Por ejemplo, ¿Cuántas bebidas tenemos de un determinado fabricante?, se puede decir que
nuestra entidad será todas las bebidas que provienen de un determinado fabricante. En cambio, si nos
realizamos preguntas como ¿En qué fecha llegó al almacén una determinada bebida? Estamos requiriendo
que le entidad sea cada bebida de modo individual. Con las entidades ya identificadas, ahora debemos
identificar los hechos que nos dan la descripción de cada entidad, en el ejemplo de las bebidas ya los hemos
descrito, ya que estamos hablando de los campos:
 Nombre
 Fabricante
 Distribuidora
Como siguiente paso, tenemos que identificar la entidad o grupo de entidades que en cierta medida,
comparten este grupo de hechos que acabamos de describir. Para nuestro ejemplo está claro que sería las
bebidas que vendemos en la empresa.
Una vez vistos estos pasos de la integridad de entidad, veamos cómo se relacionan o se representan en una
base de datos:
 Una entidad se representa como el registro de una tabla.
 Un hecho (como ya hemos dicho) sería el campo o columna de la tabla.
 Un grupo de entidades que comparten unos hechos, representaría una tabla.
Y como es lógico, la tabla está formada por la cuadricula que se crea al unir las entidades con los hechos, por
lo que cada entidad tiene un valor para cada hecho determinado.
El conjunto de todos estos valores, representa todo lo que podemos saber de una entidad.

Presta atención a lo que vamos a explicar a continuación, es muy importante. Cada entidad almacenada
debe tener una clave principal. Una clave principal es un hecho, o grupo de hechos, que distinguen esa
entidad del resto de entidades que comparten unos mismos hechos. Bueno, visto así puede parecer un poco
complicado, simplemente estamos explicando que cada registro de una tabla, debe tener un campo que
identifique de modo exclusivo ese registro respecto al resto de registros de esa tabla.
Para el ejemplo de nuestra empresa de bebidas, los fabricantes que producen las bebidas que acaban en
nuestro almacén, pueden ser muchísimas empresas, para identificar cada empresa del resto, tenemos el NIF
de la empresa, sabemos que ese código es único y exclusivo para cada empresa y que no estará repetido en
ninguna otra. Pues perfectamente el NIF sería nuestra clave principal. En caso de no encontrar un hecho o
campo que pueda ser clave principal, lo que demos hacer nosotros es crear un código que identifique
exclusivamente cada registro. En caso de vernos obligados a añadir nosotros mismos un campo que haga las
funciones de clave principal, estamos utilizando lo que se denomina una clave principal suplente. Mientras
que si utilizamos un campo que ya existe como un hecho de la entidad, se denomina clave principal natural.
Otra posibilidad, es utilizar claves principales compuestas, estas claves principales son el resultado de unir
dos columnas de nuestra tabla para formar una clave principal.
Para elegir una clave principal debemos valorar tanto los datos actuales como los datos futuros, ya que
podemos seleccionar una columna como clave principal, porque actualmente nos sirve como tal ya que
identifica cada registro, pero en un futuro pueden añadirse valores que se repiten para ese campo, siendo
necesario utilizar otra columna como clave principal, o crear una compuesta.
Es de una gran importancia que definamos correctamente cada registro, ya que es la principal "herramienta"
de la que se sirve el servidor de base de datos, para seleccionar la información que necesitamos. Mediante
una clave principal el servidor conoce con qué información queremos trabajar en cada momento. En caso de
cometer errores y no tener claves principales que identifique de manera única cada entidad, tendríamos
problemas con registros repetidos, ya que el servidor no sabría a qué registro o entidad nos estamos
refiriendo en nuestra actividad, y nos lanzaría continuas excepciones.
Con las claves principales identificadas, SQL Server nos ofrece unas características que nos ayudan a forzar la
integridad de entidad:
Introducir índices únicos en un campo para evitar la duplicación de datos por parte de los usuarios.
Restricciones PRIMARY KEY o UNIQUE KEY
Propiedad Identidad.
Todas estas características las iremos viendo más adelante.
9.7. Integridad de dominio

Ya hemos visto que la integridad de identidad permite obtener los datos almacenados en una base de datos.
Con la integridad de dominio conseguimos controlar la información que guardamos en la base de datos.
Como dominio, podemos entender como un conjunto de normas de negocio que gestionan la disponibilidad
de datos en una determinada columna de una tabla. Por ejemplo que sólo podamos introducir nombres de
fabricantes validados por un dominio de valores.
Tenemos una integridad de dominio básica, como no poder introducir letras en campos destinados para
almacenar números. A mayor número de limitaciones, mejor aseguraremos el correcto funcionamiento de
nuestra base de datos. Estas normas o reglas de integridad de dominio pueden indicar que campos son
necesarios tener obligatoriamente con valores (no se pueden dejar vacíos, NULL) para que la base de datos
no tenga datos sin conectar en el caso de tener relaciones o dependencias entre tablas.
Las herramientas que nos ofrece SQL Server para asegurar la integridad de dominio y que iremos estudiando
son:

 Tipos de datos
 Tipos de datos definidos por el usuario.
Restricciones:
 CHECK
 DEFAULT
 FOREIGN KEY
Reglas
 NOT NULL
9.8. Integridad referencial

Para ver este tipo de integridad tienes que pensar en las dependencias de tablas que hemos visto en la base
de datos que hemos puesto como ejemplo de la empresa de venta de bebidas.
Hemos visto por ejemplo que para cada registro de la tabla Bebidas, teníamos un registro en la tabla
Almacén. Y otro tipo de dependencias o relaciones que habíamos denominado relaciones "uno a muchos".
Estas relaciones se producen entre columnas comunes de las tablas que se relacionan. Como pude ser el
nombre de una bebida, el de una distribuidora etc.
Con la integridad referencial tratamos de asegurar que las filas relacionadas entre tablas, no dejen de
estarlo, o varíen esta relación cuando llevemos modificaciones a los datos. Con esta integridad limitaremos
la actividad que puede realiza un usuario sobre la base de datos.
Vamos a ponernos en un ejemplo sencillo, nuestra tabla bebida tiene una columna llamada "Distribuidoras",
que se relaciona con nuestra tabla "Distribuidora" mediante esta misma columna. Ya hemos comentado este
tipo de dependencia en este mismo tema. Llevando a cabo una integridad referencial, limitaremos las
siguientes tareas a un usuario:
 El usuario no podrá cambiar el nombre de una distribuidora en una de las tablas, ya que si así lo
hace, este valor no será el mismo en las dos tablas, y provoca que la relación quede rota. Un
registro o varios (dependiendo de en que tabla realice esa modificación) se quedará sin su pareja y
no podrá encontrar la relación.
 No podrá eliminar registros de la tabla distribuidora que se encuentren en la tabla Bebidas. Ya que
todos aquellos registros de la tabla Bebidas que estuviesen vinculados a la Distribuidora eliminada
se quedarán sin relación.
 No puede añadir registros nuevos en la tabla bebida cuyo campo Distribuidora no coincida con
ninguna de las distribuidoras añadidos en la tabla Distribuidoras.
Por lo tanto, lo que debemos comprender de la integridad referencial es que existen relaciones entre tablas
que deben permanecer invariables sea cual sea la actividad sobre ellas.
Para mantener esta integridad SQL Server nos ofrece:
 Restricciones FOREIGN KEY.
 Restricciones CHECK.
 Desencadenadores y procedimientos almacenados.
9.9. Integridad fijada por usuario.

Las tres integridades que acabamos de ver, están todas integradas en las bases de datos. Además no son
exclusivas para SQL Server 2008, sino que las encontrarás en cualquier base de datos. Si bien puede que no
estén completamente integradas y funcionales, son compatibles en cualquier ámbito.

La integridad que vamos a ver en este apartado, recoge todas las reglas que no están incluidas en ninguna
de las integridades anteriores.
Un ejemplo de este tipo de integridad de usuario, sería obligar a que una determinada bebida siempre tenga
dos tipos de envases. Este tipo de integridad no la cubre ni la de entidad, ni de dominio, ni referencial.
Únicamente podemos controlarla mediante procedimientos almacenados, desencadenadores o reglas que
se almacenen en la base de datos.
Esta integridad puede ser controlada también desde los programas clientes que conectan a la base de datos.
Mediante el código de programación estos programas pueden comprobar antes de enviar los datos al
servidor, si estos cumplen con un determinado juego de normas. De este modo el usuario estará limitado al
utilizar el interface del programa, recibiendo los pertinentes avisos del modo de introducir los datos.
Ahora bien, aunque es completamente válido implementar esta integridad en el programa de cliente, lo más
eficaz es colocarlo en el servidor, en la propia base de datos. Ya que no sabemos ni el número ni el tipo de
programas que se conectará a la base de datos, y nosotros como desarrolladores tendríamos que incluir este
tipo de restricciones en cada uno de los programas desarrollados, a parte del peligro que supondría aquellos
programas clientes, que nuestra empresa a adquirido y a los que no tenemos acceso para modificar e incluir
estas reglas.
9.10. Formas de normalización

Las formas normales definen una serie de normas o reglas que ayudan a organizar los datos en la estructura
lógica de una base de datos.
Cada una de las formas que vamos a ir explicando hereda las reglas de su antecesora, así la forma normal C,
incluye las reglas de las formas A y B. Para entender desde un sentido práctico los diferentes modos de
normalización, vamos a tomar como ejemplo la base de datos de la empresa vendedora de bebidas.
Recordamos la tabla Bebidas de esta base de datos:

Debes tener claro que esta tabla contiene los datos sin ser normalizados, si bien son los datos que deseamos
gestionar. A continuación, nos basaremos en esta tabla para ver cómo aplicar sobre ella el proceso de
normalización. Por supuesto, sólo es una tabla de prueba, los campos que en un caso deberíamos controlar
serían muchos más.
9.10.1. Forma normal A
Las normas que debemos aplicar en la primera forma normal son muy básicas y sencillas.
Regla: Cada uno de los campos de la tabla sólo puede almacenar un tipo de datos, y además
cada dato sólo se almacenará por separado, es decir individualmente.
Esta regla que hemos anunciado puedes encontrarla con la definición de la regla de datos atómicos o
indivisibles.
Para entender mejor el significado de esta regla, vamos a explicar cómo podríamos quebrantarla. En la tabla
que acabamos de presentar, vemos que estamos guardando los datos del fabricante y de la distribuidora en
dos campos diferentes. Un modo de saltarnos la regla de la forma normal A, es guardar el nombre del
fabricante y el nombre de la distribuidora en un único campo. De este modo no estamos cumpliendo la
norma, ya que estamos guardando información de diferentes características en un único campo.
Otra manera de no cumplir la regla que estamos viendo es la repetición de un campo. Esta técnica es muy
común en administradores que se están iniciando en el desarrollo de bases de datos.
Vamos a poner un ejemplo de este error tan común. Nos situamos de nuevo en nuestra tabla, ahora
imaginamos que una bebida puede ser recibida en diferentes envases: lata, vidrio... El desarrollador puede

pensar, como tenemos varias opciones de envase para una misma bebida, la forma más sencilla de cubrir
esta información es tener los siguientes campos en la tabla: envase_A y envase_B. De este modo parece
lógico que podemos guardar dos tipos de envases para cada bebida.
Este tipo de soluciones provoca bastantes problemas, el principal causante de estos problemas es la poca
flexibilidad que nos ofrece esta estructura. Nuestra tabla dejará de cumplir con nuestras necesidades en el
momento en que una bebida nos llegue con más de un tipo de envase, hemos nombrado como posibles
envases lata y vidrio, pero también podrían llegar como plástico, por citar un ejemplo. Por lo tanto esta
estructura lejos de ser sencilla es muy compleja, es imposible definir en un principio los diferentes tipos de
envases que debemos controlar. Ahora podemos pensar, pues vamos a poner suficientes campos de modo
que nuestras necesidades nunca superen ese número de campos. Como ya imaginarás, tomar este tipo de
soluciones es un error enorme. Estaremos reservando memoria sin ninguna necesidad, muchas bebidas
vendrán en un sólo tipo de envase y tendremos campos vacíos que resultarán completamente inútiles.
Para solucionar el problema que hemos planteado como ejemplo, tenemos varias soluciones, como
almacenar la misma bebida en diferentes registros de nuestra tabla, un registro por cada tipo de envase.
Esta es una solución válida, pero muy poco o nada eficaz desde el punto de vista del rendimiento. La mejor
solución es sacar "fuera" una tabla con los tipos de envase llamada Tipos_Envase por ejemplo y utilizar la
integridad referencial para relacionarla con la tabla Bebidas.
Para aplicar la forma normal A, debemos pensar en qué actividad vamos a realizar en la tabla, campos por
los que vamos a ordenar, cómo vamos a recoger sus registros, si los vamos a agrupar, etc.
La tabla que hemos presentado al principio podemos decir que cumple la primera forma normal, a
excepción del caso que tengamos varios tipos de envases. Vamos a suponer que sólo nos llegan las bebidas
en un único tipo de envase.
Si nos fijamos en los registros, vemos que tenemos información que se repite:
Hemos resaltado en naranja algunos de los datos que se repiten. Vemos que la distribuidora Enterlin se
repite para las bebidas Pacharán La Navarra Etiqueta Verde y para Pacharán Endrinas. Si se diese el caso de
que la empresa contrata otra distribuidora para la entrega de pacharán, tendríamos que actualizar los dos
registros. Esto puede provocar un fallo al realizar las actualizaciones si pasamos por alto uno de los registros,
ya que tendríamos datos incoherentes. Por lo tanto tendremos que mejorar nuestra normalización.
9.10.1.1. Definición de claves principales.
Una clave principal contiene información de un registro de tal modo que gracias a esa información podamos
distinguir ese registro de todos los demás, visto de otro forma, la información de la clave principal hace a un
registro único e irrepetible en una tabla.
Un clave principal puede estar compuesta por una o varias columnas. En caso de estar formada por varias
columnas es requisito indispensable que ninguna de esas columnas tenga información repetida en un mismo
registro.

Como ya hemos visto, la clave principal garantiza la integridad de entidad en una tabla.
En una tabla podemos tener varias columnas que puedan formar parte de una clave principal, estas
columnas reciben el nombre de claves candidatas. La función del administrador de la base de datos es
definir estas claves candidatas como primer paso, para más adelante decidir de entre todas las claves
candidatas cuales finalmente formarán parte de la clave principal. En nuestra tabla tenemos varios
conjuntos de claves candidatas:
 Nombre
 nombre, fabricante
 nombre, fabricante, distribuidora
En cualquier tabla, podemos encontrar más de un grupo de claves candidatas. Veamos como seleccionar la
clave principal más válida posible.
9.10.1.2. Selección de claves principales.
Para una correcta elección de la clave principal tenemos una serie conceptos que nos ayudan:
 Actividad: Una buena clave principal puede ser aquella que tiene una información a la que los
usuarios pueden acceder con facilidad, o que de la que tienen mayor conocimiento. Un buen
ejemplo de este caso puede ser los números de factura.
 Sencillez: Hemos explicado que una clave principal puede tener varias columnas. La mejor opción
es tratar de que el número de columnas que forman la clave principal sean las menos posibles. Si
una clave principal es válida con dos columnas, añadir más columnas no incremente la exclusividad
de la clave principal (si es exclusiva con dos, será imposible aumentarla), lo único que provocamos
si añadimos más columnas es bajar el rendimiento de las operaciones que se realicen con ellas.
 Permanencia: Una columna que pertenezca a una clave principal debe ser constante, es decir su
valor no puede ser modificado o actualizado. Las claves principales juegan un papel importante en
la relaciones entre tablas, y se supone que estas relaciones deben ser administradas con los valores
de las claves principales, por lo tanto si permanecen constantes, ganaremos mucho en estabilidad.
9.10.1.3. Claves auxiliares
En una base de datos, nos podemos encontrar tablas de las cuales no podemos encontrar ninguna columna
que sea clave candidata a formar una clave principal. Para cumplir con la forma normal A del proceso de
normalización debemos incluir una clave principal como mínimo en nuestras tablas. La única solución que
nos queda si se nos presenta una tabla de este tipo es incluir una columna extra en nuestra tabla, la cual no
almacena información que defina la información que almacenamos, pero tiene la importante tarea de ser la
clave principal que distinga un registro del resto, cumpliendo con la integridad de entidad, y nos ayude con
las relaciones.
Por ejemplo podemos tener una agenda de teléfonos, con los campos nombre, teléfono y dirección. Esta
persona puede cambiar de teléfono, dirección y hasta si nos ponemos drásticos, incluso de nombre.
Solucionamos el problema añadiendo un campo con un número para cada uno de los contactos que
tenemos en esta tabla, y el problema queda resuelto. Como vemos, este problema es muy frecuente en
nuestras tablas y es una solución muy cómoda, incluso para tablas en las que dudemos que sus campos
puedan cumplir con los tres conceptos que hemos definido para ayudarnos con la selección de claves
principales.
9.10.2. Forma normal B
La primera condición que debemos cumplir en la forma normal B, es que se cumplan las reglas que hemos
fijado en la forma normal A.
La principal regla de esta segunda norma es:
Regla: Cada tabla sólo puede almacenar información de una única entidad.

Como hemos hecho antes, vamos a entender mejor estas condiciones, explicando como quebrantarlas. En
nuestra base de datos de ejemplo, teníamos entre otras entidades los fabricantes y las distribuidoras. Para
ambas entidades podríamos desear almacenar el nombre, la dirección y la ciudad. El primer error que
podemos cometer como diseñadores de la base de datos es decidir que tanto los fabricantes como las
distribuidoras pueden ser almacenadas en una misma tabla llamada Fabricantes_Distribuidoras. Esta
decisión errónea la tomamos por el hecho de que ambas entidades comparten los mismos campos.
Esta decisión incumple la regla de la forma normal B que nos exige tener estas entidades en diferentes
tablas, en caso de hacer caso omiso a esta regla nos encontraremos varios problemas. En el ejemplo que
hemos tomado, tendríamos problemas para devolver la información de todos los fabricantes por un lado y
por otro la de las distribuidoras.
Observa los datos de la siguiente tabla:
Esta tabla plantea el mismo problema que hemos identificado anteriormente si almacenamos los fabricantes
y las distribuidoras en la misma tabla. Observa que entre otras cosas, estamos almacenando información
relativa a las bebidas y del fabricante, en una misma tabla.
Los campos fabricante y localidad_fabricante, almacena información relativa a la entidad Fabricante, que no
depende en ningún caso con la entidad Bebida. La solución separarlo en dos tablas, quedando del siguiente
modo:

Separamos las entidades en dos tablas y cumplimos con la segunda forma normal. Si observamos los
registros de las dos tablas, vemos que la información de la tabla original permanece una vez desglosada en
dos tablas. Incluso vemos que tenemos información que se repite. Recuerda que el proceso de
normalización no consiste en minimizar el espacio de la base de datos, sino de mejorar el rendimiento y la
funcionalidad.
9.11. RELACIONES.
Vamos a definir las claves principales de estas dos tablas:
Tabla bebida:
Hemos destacado en rojo las columnas que forman la clave principal de la primera tabla: nombre y
fabricante, y en la segunda: fabricante.
Cuando dividimos un tabal en varias, como este caso, debemos ser capaces de combinar estas tablas para
poder recoger los datos originales como si de una única tabla se tratara. Para ello, lo primero de todo

buscamos un dato común que nos permite identificar uno (relación uno a uno) o varios (relación uno a
varios) registros de una tabla a partir de un registro de la otra.
En nuestro caso el campo común es el nombre del fabricante.
El fabricante es la clave principal de nuestra tabla Fabricantes, y su correspondiente en la tabla Bebidas es la
clave externa o foránea.
Cuando hemos identificado una clave externa y su correspondiente clave principal, nuestro servidor de base
de datos es capaz de definir la integridad referencial que relacionan las dos tablas.
Ya conocemos las relaciones uno a varios y uno a uno, en función de los registros que se devuelven a partir
de uno. Es posible crear relaciones varios a varios mediante una tercera tabla "auxiliar" que ayude a
conectar dos tablas.
9.11.1. Forma normal C
Para cumplir con la forma normal c debemos cumplir la forma normal B y la siguiente regla:
Regla: Todos los campos que no contengan una clave están obligados a depender de forma directa
con la clave principal.
La definición de esta regla puede parecer complicada, pero es tan sencilla como cualquiera de las que hemos
visto, o incluso más.
Una vez más, la explicamos comprobando como quebrantarla.
Observa la siguiente tabla Pedidos:
El camino más corto para cometer errores y no cumplir con esta tercera forma normal son los campos
calculados. En la tabla, hemos incluido un campo Total que almacena el total de un pedido. Pero este campo
es innecesario, ya que somos capaces de llegar a esa información a partir de los campos unidades y precio,
en cualquier momento.
No debemos pensar, que este error que estamos cometiendo se limita a que almacenamos información
extra y ocupamos espacio sin tener necesidad de ello. Además de esto, podemos tener problemas de
coherencia, si por ejemplo modificamos las unidades del producto cuaderno y no recalculamos el valor del
campo Total. Por lo tanto, debemos asegurarnos de que los campos de nuestras tablas son necesarios, y que
no pueden ser obtenidos a partir de otros campos. Otra característica importante de esta forma normal, es
que es una gran ayuda para identificar que tablas deben ser divididas en otras a partir de la regla que nos
exige que cada tabla sólo guarde información referente a una entidad.
9.11.2. Conclusión del proceso de normalización
Podemos concluir el proceso de normalización cuando analizando nuestras tablas comprobamos que somos
capaces de realizar una actualización sin tener que cambiar más de un dato para cada actualización.
Mencionar que el proceso de normalización ha ido evolucionando, los investigadores de bases de datos han
incluido dos formas normales a las tres que hemos explicado, la forma normal D y E.
Estas dos últimas formas pertenecen a la normalización avanzada, y no son aplicables a la mayoría de las
bases de datos, ya que es muy difícil alcanzar un nivel de complejidad tan alto como para tener que
aplicarlas. Incluso se aconseja a los diseñadores que revisen sus estructuras cuando es necesario aplicar las
formas normales D y E, ya que posiblemente si son necesarias es porque el desarrollador a cometido errores
en su diseño.

9.12. Desnormalización
Con el proceso de normalización hemos conseguido evitar al máximo la redundancia de datos, permitiendo
realizar modificaciones de un modo cómodo. Para ello hemos indicado que desglosamos nuestra base de
datos en tantas tablas como sea necesario.
De todas las reglas que hemos visto hay una que está por encima de todas, la lógica y la experiencia del
administrador. Estas reglas no son obligatorias, son aconsejables en muchos casos y son de gran ayuda.
La lógica del programador puede indicarle que siguiendo la normalización de su base de datos, ha
conseguido desglosar su estructura en tantas tablas con sus consiguientes relaciones. Esto puede provocar
que la búsqueda de un registro tenga que llevarse a cabo a través de varias tablas y relaciones, con un
rendimiento que deja mucho que desear.
Para solucionar esto, el desarrollador lleva a cabo el proceso de desnormalización, que tendrá consecuencias
de redundancia de datos, pero que posiblemente sean necesario para la mejora del rendimiento.
Para conseguir alcanzar el término medio entre el proceso de normalización y desnormalización, el mejor
medio es la experiencia. Se expone la base de datos a explotación como prueba piloto y se analiza la
actividad que se realiza sobre ella, estudiando si los resultados se adaptan a las necesidades y cumplen con
el rendimiento esperado, sino es así, gracias a estos estudios podremos ver que debemos modificar para
mejorar nuestro diseño. SQL Server 2008 tiene la herramienta SQL Server Profiler que nos ayuda a realizar
este tipo de análisis.
9.12.1. Herramientas para la normalización
El servidor SQL Server ofrece un grupo de herramientas que ayudan en el proceso de normalización. Gracias
a estas herramientas podremos gestionar nuestras tablas de modo que los datos se añadan con la lógica
deseada y que las modificaciones cumplan los requisitos deseados.
Con estas herramientas podremos indicar a nuestro servidor como debe administrar la normalización, y nos
ahorraremos muchas líneas de código en aplicaciones para que se encarguen de ella. Esto supone una gran
ventaja frente a otras bases de datos.
Vamos a explicar brevemente las herramientas que tendremos ocasión de ver cómo utilizarlas en próximos
capítulos. Estas herramientas son:
 Identidad
 Restricciones
 Integridad en relaciones
 Disparadores
9.13. Identidad
Podemos tener una columna configurada como columna identidad, esta columna identidad es la manera
más sencilla de garantizar la integridad de identidad. La columna de identidad es una columna para la cual el
propio servidor de base de datos se encarga de asignarle valores automáticamente. Por defecto, el primer
valor es uno, y los siguientes registros van aumentando este valor de unidad en unidad. Aunque estos
valores, son por defecto, veremos cómo se pueden modificar. Una columna identidad es el mejor modo de
añadir claves suplentes, como explicamos en el anterior capítulo, cuando una tabla no puede dar de modo
natural una clave principal, será tarea nuestra añadir columnas que formen esa clave principal, pues el modo
más eficaz es añadir columnas identidad. Con este tipo de claves suplentes mejoramos considerablemente la
relación entre tablas por columnas numéricas, bastante más eficaces que las claves principales formadas por
textos.

9.13.1. Unique
Esta restricción obliga a que todos los valores de una determinada columna no estén repetidos en otros
registros. Si tenemos varias restricciones UNIQUE en una misma tabla, todas deben ser cumplidas a la vez
para cada registro. Con la restricción UNIQUE aseguramos la integridad de identidad de la tabla, ya que
cumplimos con la norma de que cada registro es diferente al resto. Si aplicamos claves principales a una
tabla, automáticamente se asigna esta restricción a esa columna. No debes pensar que una columna
identidad que se incrementa ella sólo automáticamente, es otro modo de tener una restricción UNIQUE, ya
que se pueden dar casos en que tengamos valores duplicados, a no sé qué marquemos esa columna como
clave suplente o principal. Puedes llegar a esta conclusión errónea si has trabajado con ACCESS, pero en SQL
Server no es así.
9.13.2. Default
Como su propio nombre indica, esta restricción introduce un valor por defecto en una columna cuando no
se índica ningún valor para insertar. Con esta restricción aseguramos la integridad de dominio, ya que
aseguramos valores válidos para nuevos registros que se inserten.
9.13.3. Check
Esta restricción evalúa por medio de expresiones los valores que se insertan en una columna. Esta expresión,
una vez que se evalúa devuelve un resultado, en función de si el dato es válido (Verdadero) o no (Falso), por
lo tanto devuelve un valor booleano que indica si el dato tendrá permiso para ser ingresado o no.
Como puedes ver, nos ayuda a asegurar la integridad de dominio, y si vamos un poco más allá, también nos
ayuda a asegurar la estabilidad de relaciones en configuraciones mucho más avanzadas.
9.14. Integridad en relaciones

Este tipo de integridad, denominada integridad referencial declarativa (DRI - Declarative Referential
Integrity), es el proceso por el cual SQL Server fuerza de manera automática las relaciones entre tablas.
Antes de aparecer este tipo de integridad para servidores SQL Server, era necesario desarrollar códigos para
aplicaciones denominadas desencadenadores para cada tabla, y estos se encargaban de ejecutar una serie
de acciones que asegurasen esta integridad, y siempre bajo la supervisión del administrador.
A este tipo de integridad llegamos ahora de manera automática, de un modo muy sencillo y con un
rendimiento considerable, de modo que el administrador puede dedicarse a otras tareas. Para conseguir
esta integridad tenemos dos tipos de restricciones: PRIMARY KEY y FOREIGN KEY.
9.14.1. Primary key
La clave principal (PRIMARY KEY) nos permite asegurar la integridad de entidad (puesto que es única en cada
registro) y por otro lado nos garantiza la estabilidad de las relaciones con otras tablas.
9.14.2. Foreign key
La restricción FOREIGN KEY, se conoce como la clave externa o foránea que ya hemos explicado. Y como ya
sabes es la pareja de la restricción PRIMARY KEY, y juntas cumplen con la integridad referencial.
Una clave externa es una copia de la clave principal de la tabla principal, se inserta en la tabla que se
pretende enlazar y con esto creamos la relación entre un par de tablas. Las claves externas pueden ser varias
en una misma tabla, mientras que las principales deben ser únicas.
Para que esta relación que comentamos se cumpla, la clave principal que enlaza con la externa debe cumplir
obligatoriamente que las dos columnas sean del mismo tipo.

9.14.3. Integridad referencial en cascada
Esta tipo de integridad que surgió con la versión 2000 de SQL Server, permite una serie de operaciones, que
sólo pueden llevarse a cabo de este modo y no de otro.
Expliquemos porque a este tipo de integridad referencial se le añade el concepto de cascada. Imagina que
tenemos una tabla que almacena las facturas emitidas para los clientes. Esta tabla entre sus campos
contiene el campo codigo_cliente, que es la clave externa que se relaciona con la clave principal de la tabla
clientes. Por lo tanto la tabla clientes tendrá un campo codigo_cliente que se relaciona con la tabla Facturas.
Puedes verlo algo más claro en el siguiente gráfico:
Como ves, tenemos una relación uno a varios. Mientras en la tabla Clientes el campo codigo_cliente será
único en cada registro, en la tabla Facturas, este mismo campo puede aparecer varias veces en diferentes
registros, ya que emitimos varias facturas para el mismo cliente.
Esta relación representa una integridad referencial estricta, la cual no nos permite modificar el valor del
código de cliente en la tabla clientes ya que de algún modo dejaría "huérfanos" a aquellos registros que
anteriormente estaban relacionados al código de cliente que tratamos de modificar. Otra limitación que
tenemos con esta integridad es que no nos permiten eliminar un cliente que tenga facturas emitidas en la
tabla Facturas, por lo tanto no podemos eliminar un registro que tenga otros registros referenciados
mediante estas relaciones.
Precisamente para solucionar estos problemas que hemos planteado tenemos la integridad referencial en
cascada. Podemos añadir una serie de acciones que permita solventar estas complicaciones.
Podemos incluir actualizaciones en cascada, de modo que cuando modifiquemos el valor de una clave
principal en la tabla principal, se modifiquen del mismo modo los valores de las claves externas en el resto
de tablas enlazadas a la principal. En nuestro caso, al modificar el valor del campo codigo_cliente de un
determinado cliente, este nuevo valor se cambiará para todos los registros referenciados en la tabla
Facturas.
Igualmente podemos incluir eliminaciones en cascada, de tal forma que si eliminamos un registro de la tabla
principal, se eliminen también los registros enlazados en la tabla subordinada. En nuestro caso, podríamos
eliminar un cliente, y automáticamente se eliminarían todos sus registros de facturas.
Debes tener mucho cuidado a la hora de utilizar este tipo de relaciones en cascada, ya que si activamos por
ejemplo la eliminación en cascada, corremos peligro de que un usuario no sea consciente de que perderá
todos los registros vinculados a esa tabla.
Una clave principal, por norma general no cambiará su valor, por lo tanto no tiene sentido activar en esos
casos tampoco la actualización en cascada.

9.15. Desencadenadores (triguers)

Los desencadenadores representan aplicaciones que desarrollamos en lenguaje T-SQL y que se ejecutan, o
mejor dicho, se "disparan" cuando sucede algún tipo de evento en una tabla. Los desencadenadores se
llaman también disparadores o triggers.
En función del tipo de evento, tenemos los siguientes grupos de desencadenadores:
Desencadenadores de inserción. Estos desencadenadores se ejecutan cuando se añade un registro o varios.
Desencadenadores de actualización. Se ejecutan cuando se ha actualizado uno o varios registros.
Desencadenadores de eliminación.
Con estos desencadenadores aseguramos la lógica de negocio y definimos la integridad de usuario.
Antiguamente (versiones anteriores a SQL Server 2000), la integridad referencial en cascada tenía que
implementarse mediante desencadenadores que permitiesen la actualización y eliminación en cascada.
9.16. Ejercicio 1
En el siguiente ejercicio nos piden diseñar una base de datos para gestionar un videoclub. Después de varias
reuniones con el dueño del negocio que nos ha contratado, podemos describir la información que el cliente
necesita para poder gestionar los alquileres de su negocio:
 Título  Idioma.
 Productora  Duración.
 País de la productora.  Nombre de cliente.
 Protagonista.  Dirección de cliente.
 País del protagonista.  Teléfono de cliente.
 Director.  DNI de cliente.
 País del director.  Fecha de alquiler.
 Genero.  Precio.
A partir de estos datos, debemos indicar las diferentes identidades (tablas) que detectamos en el conjunto
de ésta información.
9.17. Ejecicio 2
Una vez obtenidas las diferentes identidades, debemos indicar los diferentes campos de cada una de ellas y
aplicar las relaciones que estimemos oportunas, con los cambios en las tablas que sean necesarios.

Capitulo 2. Iniciación a la Administración y definición de la
Base de Datos.
2. Objetivo
Introducción a la herramienta gráfica (SQL Server Management Studio) que nos ofrece SQL Server
2008, para la administración de una base de datos. Familiarizarse con el entorno, y los diferentes
paneles.
Al finalizar la unidad el alumno será capaz de crear y modificar una base de datos. Se describen las
diferentes opciones de configuración que nos ofrece SQL Server 2008.
2.1. INTRODUCCIÓN
A lo largo de estos años Microsoft ha ido recogiendo y estudiando las diferentes solicitudes y sugerencias de
administradores y desarrolladores de todo el mundo. Muchas de estas sugerencias solicitaban mejoras en el
diseño y el modo de gestionar y administrar las tareas de SQL Server.
Microsoft se esforzó en tratar de cumplir con todas estas sugerencias y rediseño desde su servidor de base
de datos. Como fruto de estas mejoras y otras muchas de rendimiento y estabilidad surgió SQL Server 2005.
Para usuarios veteranos y nuevos en administración de bases de datos con SQL Server, se quedarán
sorprendidos en comprobar que desde una única herramienta tenemos acceso a la gestión de casi todas las
tareas de SQL Server 2008. Esta herramienta que engloba todas las funciones, es SQL Server 2008
Management Studio.
Para usuarios con experiencia ya, pueden ver que las antiguas herramientas como Analysis Manager,
Administrador Corporativo y el Analizador de Consultas, están todas compactadas en SQL Server 2008
Management Studio.
Si además eres desarrollador de software con .net, el entorno te resultará muy familiar al que se nos
presenta a partir de Visual Studio 2005.
Como es lógico la mayor parte del tiempo que dedicaremos como administradores o desarrolladores de
bases de datos estará invertido en esta herramienta, por lo tanto debemos familiarizarnos al máximo a esta
potente herramienta.
Este capítulo pretende ser la primera toma de contacto del alumno con SQL Server 2008 Management
Studio, presentaremos sus objetos, tareas etc...Para al menos conocer donde se encuentran y para qué
sirven. En el resto de capítulos del curso aprenderemos a utilizarlos y sacarles partido, pero primero es
importante tener una idea general de la herramienta que tenemos entre las manos y que podemos llegar a
hacer con ella.
2.2. SQL Server Management Studio

Arrancamos la aplicación desde el menú de inicio tal y como vimos en el primer capítulo. Lo primero que
haremos para acceder a la herramienta es conectarnos al servidor, para eso tendremos la conexión que
hemos configurado durante la instalación del producto, así que seleccionamos esos parámetros:
"Autenticación de Windows" y pulsamos en conectar:

Al conectarnos se nos presenta la primera pantalla de nuestra herramienta, y observamos que tenemos la
pantalla dividida en dos ventanas:
Explorador de objetos.
Resumen o Detalles del explorador de objetos

Hay una tercera ventana que resulta muy útil y que por defecto es posible que SQL Server no muestre:
Servidores registrados. Para mostrar esta ventana vamos al menú "Ver" y seleccionamos "Servidores
registrados", de este modo nuestra pantalla queda dividida en tres ventanas:

Si has desarrollado programas con Visual Studio, este entorno te será muy familiar. Visual Studio se ha
convertido en el entorno de programación preferido por los desarrolladores. Parte de este éxito se debe al
diseño del entorno de esta herramienta. Ya que permite un grado de personalización muy alto, y el
desarrollador puede disponer y utilizar el espacio al máximo para tener un acceso más rápido y cómodo a
sus herramientas más utilizadas.
Al igual que sucede con Visual Studio, con SQL Server Management Studio podemos personalizar su
presentación, y acceder rápidamente a nuestras herramientas preferidas. Para aumentar nuestro espacio de
trabajo sin influir en el funcionamiento original de Management Studio tenemos las siguientes posibilidades:
Cada una de las ventanas puede cambiar a cualquier localización. Si tenemos la suerte de trabajar con
monitores compartidos, tenemos la posibilidad de desacoplar la mayoría de ventanas y arrastrarla a

cualquier posición. Las ventanas pueden ser ocultadas automáticamente, cuando una ventana permanece
oculta se convierte en una pestaña en el borde de la ventana principal. Para mostrarlas de nuevo basta con
colocar el puntero del ratón sobre esta ventana para que se muestre de nuevo. Para activar y desactivar esta
posibilidad tenemos un botón representado por una chincheta. Otro modo de utilizar esta posibilidad es
mediante el menú ventana -> Ocultar automáticamente:
La ventana cuando se muestra:
Tenemos la posibilidad de configurar el entorno para que nos muestre la información como fichas. Cada
elemento aparece como una ficha en la localización que se encuentre, o bien como una interfaz de múltiples
documentos, conocida esta opción como MDI de modo que cada documento está en su propia ventana.
Para optar a esta configuración tenemos el menú Herramientas->Opciones->Entorno->General y marcar la
opción Organización por fichas o Entorno MDI:

Los diferentes componentes de Management Studio están configurados para trabajar como un todo. Todas
las herramientas están entrelazadas, lo que hace de Management Studio una herramienta muy eficaz.
Otra opción que debemos comentar es que Management Studio no tiene porque ser instalado en el mismo
servidor donde estamos explotando nuestra base de datos. De hecho el modo más común de trabajar es
tener SQL Server 2008 instalado en el servidor para explotar la base de datos, y en un equipo a parte y
personal del administrador tener instalado Management Studio, de modo que el administrador pueda
trabajar con la base de datos sin la necesidad de trabajar en el servidor. Además este método de trabajo es
aún más eficaz, ya que desde Management Studio podemos estar conectados a varios servidores y
administrar varias bases de datos instaladas en diferentes servidores y todo esto desde el ordenador
personal del administrador.

2.2.1. SERVIDORES REGISTRADOS.
Hemos visto en el anterior capítulo que la ventana que nos presenta la información relativa a los Servidores
registrados puede permanecer oculta por defecto.
Desde esta ventana podemos organizar los servidores "favoritos" a los que accedemos con mayor
frecuencia. Entra otras opciones tenemos la posibilidad de crear grupos de servidores para facilitar la
búsqueda de uno de ellos, en caso de que trabajemos con muchos servidores a la vez.
En el caso de SQL Server 2008 Express Edition tenemos limitados los tipos de servidores al motor de base de
datos que es con el que nos centramos en este curso. En versiones más avanzadas, aparecerían el resto de
tipos de servidores que nos ofrecen.
Desde esta ventana podemos pinchar con el botón derecho sobre el servidor y seleccionar Conectar-
>Explorador de objetos, y de este modo nos conectaremos con ese servidor en concreto:

Una vez que estamos conectados, vemos que el icono del servidor aparece con un triángulo con fondo verde
que indica que estamos conectados actualmente a ese servidor:
Tenemos la posibilidad de añadir un nuevo registro de servidor, para ello pulsamos con el botón derecho en
el icono del tipo de servidor del cual queremos crear un nuevo registro. En nuestro caso sólo tenemos el
motor de base de datos, pulsamos con el botón derecho y seleccionamos Nuevo->Registro de servidor...
Dentro de la ventana de Nuevo registro de servidor tenemos dos pestañas tal y como puedes ver en las
siguientes figuras:
Pestaña General:

Desde estas ventanas tenemos la posibilidad de configurar las siguientes tareas:

Pestaña General:
Modificar el modo de autenticación: Windows o SQL Server
En caso de seleccionar el modo SQL Server de autenticación podemos introducir el nombre de usuario y la
contraseña.
Incluir o modificar el nombre del servidor registrado y añadir una descripción si así lo deseamos. La
descripción no es obligatoria.
Pestaña Propiedades de conexión:
Indicar la base de datos con la que deseamos conectar directamente al conectar con el servidor.
Seleccionar el protocolo de red con el cual conectamos.
Definir el tamaño del paquete de red.

Especificar el tiempo de espera de conexión y ejecución. Se trata del tiempo que transcurrirá para conectar,
una vez pasado este tiempo el Management Studio entenderá que ocurre algún problema que no permite la
conexión y lanzará un error.
Activar o desactivar el cifrado de la conexión.
2.2.2. Registro de servidores

En SQL Server 2008 tenemos una opción añadida respecto a la versión 2005, "Central Management Servers"
(Servidor de Administración Central). En esta nueva opción podemos crear una instancia de SQL Server como
si fuese un servidor de administración central. Este tipo de servidor lo podríamos utilizar para almacenar una
lista de instancias de SQL server organizadas por grupos. De este modo todo lo que hagamos sobre este
servidor repercutirá en cada uno de los servidores de este grupo. De este modo tanto consultas T-SQL (que
veremos más adelante), y acciones realizadas mediante el explorador de objetos, se ejecutarán en todos los
servidores del grupo.
.
Para agilizar el proceso de registro de servidores, tenemos la opción de importar y exportar las
características de conexión definidas de un servidor a otro, y viceversa. Como es razonable, podremos
importar y exportar estos registros siempre y cuando se traten del mismo tipo de servidores. Esta
información de registro se almacena en archivos. Para llevar a cabo este proceso, es tan sencillo como
pinchar con el botón derecho en un servidor o en un grupo de servidores y seleccionar del menú la opción
Importar o Exportar, dependiendo de la tarea que queramos realizar:
En la ventana que se nos muestra seleccionamos el archivo de registro y seleccionamos a que servidor o
grupo de servidor queremos aplicarlo, mediante el árbol de servidores:

Para eliminar un servidor o un grupo, lo haremos desde el menú que emerge al pulsar con el botón derecho
sobre el servidor a eliminar, nos mostrará una ventana de confirmación para evitar errores.
Para modificar el nombre o las propiedades de conexión de cualquier servidor podemos pulsar con el botón
derecho y seleccionar la opción propiedades.
Para finalizar vamos a mostrar una tabla con los diferentes iconos que podemos encontrar en los servidores
y lo que significan:

2.2.3. Agrupar servidores.
Con la versión SQL Server 2000 apareció un nuevo concepto: Grupos de servidores.
El objetivo de los grupos de servidores es meramente organizativos. Es una utilidad administrativa que
ayuda al desarrollador a ordenar varios servidores por grupos, y no tiene ninguna influencia sobre la
actividad y la estructura de nuestros servidores. Físicamente no agrupa, ni conecta los servidores que
pertenezcan a un mismo grupo.
Con los grupos de servidores se pueden mostrar los servidores con diferentes nombres a sus reales. La
ventaja de esta característica es que podemos tener nombres reales que sean complejos y utilizar nombres
más descriptivos para su administración.
Además los grupos de servidores pueden anidarse, es decir, podemos tener un grupo de servidores dentro
de otro. Y podemos tener también un servidor en más de un grupo.
Imagina que nos encargan administrar una gran empresa dividida en diferentes departamentos:
Administración, Recursos Humanos y Producción.
Como se trata de una gran empresa, tenemos además oficinas en Madrid y Barcelona. Cada departamento
tiene su propio de servidor con su correspondiente servidor de base de datos que guarda la información de
la actividad realizada por su departamento.
En este caso podíamos organizar de varios modos nuestros servidores. El más lógico sería crear dos grupos
principales a los que llamaremos Madrid y Barcelona.
Y a su vez dentro de los grupos Madrid y Barcelona crear otros tres grupos que almacenen los servidores de
cada departamento.
Vamos a crear este organigrama de servidores con SQL Server 2008:
Para crear un nuevo grupo pinchamos con el botón derecho en el lugar donde queremos crear un grupo y
seleccionamos Nuevo->Grupo de servidores, podemos hacerlo en la raíz (sobre nuestro motor de base de
datos) o sobre otro grupo de servidores si deseamos anidarlo.
Esta operación nos mostrará una ventana donde nos podremos indicar un nombre para el grupo de
servidores y una breve descripción para el grupo. Además nos muestra un panel con la estructura
organizativa de nuestros servidores, como puedes ver en la siguiente figura:

Una vez creados los grupos iremos añadiendo los registros de servidores tal y como hemos visto en capítulos
anteriores.
Siguiendo estas operaciones, y anidando nuestros grupos finalmente conseguimos el siguiente esquema que
nos muestra la ventana de servidores registrados:

2.2.4. Explorador de objetos
Otra de las ventanas principales que nos muestra Management Studio es el Explorador de Objetos
El explorador de objetos se encuentra conectado a los diferentes tipos de servidores que tenemos. Los
elementos que nos ofrece SQL Server 2008 varían en función del tipo de servidor, pero hay características de
desarrollo y herramientas de administración comunes para todos.
En esta ventana podemos ver una barra de herramientas que nos permite realizar unas determinadas
tareas. En la siguiente tabla mostramos estos botones con la tarea que tienen asignada:

2.3. Conectar a un servidor
Pulsando en el botón destinado a la conexión con un servidor ( ), nos muestra la pantalla de conexión
que ya conocemos:
En esta ventana, tenemos que dar el nombre del servidor con el que deseamos conectar, y seleccionar el
tipo de autenticación con el que realizaremos la conexión. Si seleccionamos Autenticación de Windows,
podremos realizar la conexión, mientras que si elegimos la opción Autenticación SQL Server, deberemos
introducir el nombre de usuario y la contraseña. Esta opción dependerá del tipo de registro que hayamos
definido durante la instalación, o de la modificación que hayamos realizado sobre el registro del servidor en
sus propiedades.
Si pulsamos sobre el botón opciones, se nos abre una nueva ventana que puedes ver en la siguiente figura:

Vemos que tenemos tres pestañas, la primera de ellas "Inicio se sesión" nos muestra la ventana de conexión
de la que partimos. Mientras que en la pestaña "Propiedades de conexión" nos muestra la ventana que ves
en la anterior figura. Esta ventana ya la conocemos, y la información que podemos introducir ya la hemos
visto en la ventana de propiedades que hemos comentado en el anterior capítulo.
En la pestaña "Parámetros de conexión adicionales", podremos introducir una serie de parámetros con sus
correspondientes valores para incluirlos en la cadena de conexión al servidor que vayamos a conectar. El
formato de con el que escribiremos estos parámetros será:
; parámetro1 = valor1; parámetro2=valor2;
Para conectar al servidor en nuestro ejemplo no necesitamos ningún parámetro extra, porque se lo damos
todo en la primera pestaña y la segunda de esta ventana.

2.3.1. Carpetas del explorador de objetos.

La información y los elementos que tenemos en el explorador de objetos se organizan en carpetas con
estructura de árbol.
Nota: Este capítulo muestra el "Explorador de objetos" a modo de presentación. En los siguientes
capítulos aprenderemos a trabajar con estos objetos mediante el lenguaje SQL y con SQL Server
2008 para alcanzar un nivel avanzado.
Cuando expandamos una de estas carpetas, el explorador de objetos recibe información del servidor del
contenido de la carpeta para poder mostrarlo. Esta petición sólo se realiza la primera vez que expandimos
una carpeta, por lo tanto, si hemos realizado alguna modificación en algún componente de alguna lista
desde la primera vez que expandimos la carpeta, esta modificación no se mostrará en ella. Para que se
muestre esa información "nueva", debemos seleccionar esa carpeta y actualizarla, mediante la opción
"actualizar" del menú que se muestra con el botón derecho, o mediante el botón actualizar de la barra de
herramientas.
Si trabajamos con bases de datos empresariales de gran tamaño, es posible que tengamos en una carpeta
un listado de objetos tan grande que no nos permita trabajar con comodidad. Lo más frecuenta es que de
ese listado, sólo nos interese trabajar con unos pocos en un determinado momento.

Para facilitar esta tarea, tenemos la opción de mostrar sólo aquellos objetos que nos interesa, mediante el
botón de filtrado:
Hay carpetas que no permiten realizar un filtro, nos situamos en una de las carpetas que lo permitan y
pulsamos sobre el botón, para mostrar la ventana de "Configuración de filtro del explorador de objetos":
Desde esta ventana nos permite realizar filtros por el nombre, esquema (no siempre está disponible) y la
fecha de creación, teniendo la opción de elegir el operador de comparación para el filtro (Es igual a,
Contiene y Entre).
Sincroniza la información del

servidor.
Filtra el listado, en caso de ser

posible.
Tipo de vista para mostrar la

información:
Lista: Listado de objetos de la
carpeta seleccionada.
Detalles: Muestra información
por diferentes categorías del
objeto seleccionado.
El modo de navegación por las carpetas de la pestaña "Resumen" es muy parecido al explorador de
Windows.

2.3.2. Pestaña resumen
La tercera ventana que nos muestra Management Studio aparece por defecto con la pestaña "Resumen":
Esta pestaña es utilizada por el Explorador de Objetos para mostrar información del objeto que tengamos
seleccionado. Como puedes ver, esta pestaña tiene su propia barra de herramientas con los siguientes
botones:
Icono Descripción
Sube un nivel en el árbol de

carpetas.
Actualiza el elemento
seleccionado.
Sincroniza la información del

servidor.
Filtra el listado, en caso de ser

posible.

Tipo de vista para mostrar la

información:
Lista: Listado de objetos de la
carpeta seleccionada.
Detalles: Muestra información
por diferentes categorías del
objeto seleccionado.
El modo de navegación por las carpetas de la pestaña "Resumen" es muy parecido al explorador de
Windows.
2.3.3. Carpetas principales.

En el explorador de objetos de SQL Server 2008 Express Edition (Versión avanzada) tenemos las siguientes
carpetas principales:
Bases de datos.
Seguridad.
Objetos de servidor.
Réplica.
Administración.
En este curso iremos viendo la mayoría de objetos que encierran estas carpetas.
2.3.4. Carpeta de bases de datos.

En esta carpeta podemos encontrar las bases de datos del sistema y las de usuarios que vayamos creando
nosotros.

Dentro de las bases de datos de usuarios podemos encontrar carpetas anidadas agrupadas por los objetos
que contiene:
Árbol de Bases de Datos.
Base de
datos de Diagramas de bases de datos.
usuario.
Tablas
Vistas.
Sinónimos.
Procedimientos
Almacenados.
Funciones.
Desencadenadores de
Programación. bases de datos.
Ensamblados.

Tipos.
Reglas.
Valores predeterminados.
Usuarios.
Funciones.
Esquemas.
Seguridad.
Claves asimétricas.
Certificados.
Claves simétricas.
Todos estos objetos puedes verlos al extender una base de datos de usuario. En este caso mostramos en las
siguientes figuras los nodos principales de la base de datos Northwind:

Hasta aquí llegamos con la primera toma de contacto con SQL Server Management Studio, a continuación
tendremos tres temas (4, 5 y 6) para aprender a programar con SQL y como realizar este aprendizaje con
SQL Server 2008.
A partir del tema 7, retomaremos de nuevo Management Studio, para profundizar con los objetos de las
bases de datos. Explicaremos con un nivel mucho más avanzado como trabajar con las herramientas de SQL
Server 2008 que a lo largo de estos tres primeros capítulos no hemos visto, o únicamente se han
mencionado. Pero no abandonaremos el lenguaje SQL, ya que iremos viendo cómo realizar muchas de estas
tareas mediante este lenguaje de programación, de modo que podamos realizar estas tareas en cualquier
otro servidor de base de datos del mercado.
En el resto de capítulos seguiremos avanzando con SQL Server 2008, completando su aprendizaje. Una vez
estudiadas todas las lecciones, tendremos los conocimientos necesarios para ser Administradores y
desarrolladores de bases de datos, utilizando sin problemas herramientas profesionales de SQL Server 2008.
2.3.5. Ejercicio 1
En este ejercicio vamos a organizar los servidores que tenemos en dos oficinas diferentes. En una de ellas
tendríamos tres servidores y en la segunda dos.
Para organizar las conexiones, crea los grupos de servidores que creas conveniente y los registros necesarios

2.4. Definir la bases de datos (creación)

Puede definir una base de datos mediante el Administrador corporativo de SQL Server o mediante la
instrucción CREATE DATABASE en el Analizador de consultas SQL. El proceso de definición de una base
de datos crea también un registro de transacciones para esa base de datos.
La información acerca de las bases de datos de SQL Server está almacenada en la tabla sysdatabases de
la base de datos master. Por tanto, debe utilizar la base de datos master para definir una base de datos
cuando utilice instrucciones Transact-SQL.
La definición de una base de datos consiste en especificar el nombre de la base de datos, y diseñar el
tamaño y la ubicación de los archivos de la base de datos. Cuando se crea la nueva base de datos, ésta
es un duplicado de la base de datos model. Las opciones o configuraciones de la base de datos model
se copian en la nueva base de datos.
Al crear una base de datos se pueden establecer los siguientes parámetros:
2.4.1. Primary
Este parámetro especifica los archivos del grupo de archivos principal. El grupo de archivos
principal contiene todas las tablas del sistema de la base de datos. También contiene todos

los objetos no asignados a grupos de archivos del usuario. Todas las bases de datos tienen
un archivo de datos principal. El archivo de datos principal es el punto de inicio de la base de
datos y señala a los demás archivos de la base de datos. La extensión de nombre de archivo
recomendada para los archivos de datos principales es .mdf. Si no se especifica la palabra
clave PRIMARY, el primer archivo enumerado en la instrucción es el archivo principal.
2.4.2. Filename
Este parámetro especifica el nombre del archivo del sistema operativo y la ruta de acceso al
archivo. La ruta acceso de archivoSO debe especificar una carpeta del servidor en el que está
instalado SQL Server.
2.4.3. Size
Este parámetro especifica el tamaño de los archivos de datos o de registro. Puede especificar
los tamaños en megabytes (MB), que es el valor predeterminado, o en kilobytes (KB). El
tamaño mínimo es de 512 KB, tanto para los archivos de datos como para los archivos de
registro. El tamaño especificado para el archivo de datos principal debe ser, al menos, como el
tamaño del archivo principal de la base de datos model. Cuando se agrega un archivo de
datos o un archivo de registro, el valor predeterminado es 1 MB.
Este parámetro especifica el tamaño máximo hasta el que puede crecer el archivo. Puede especificar el
tamaño en megabytes (valor predeterminado) o en kilobytes. Si no se especifica el tamaño, el archivo
crece hasta que el disco esté lleno.
2.4.4. Filegrowth
Este parámetro especifica el incremento de crecimiento del archivo. El valor de FILEGROWTH de un
archivo no puede sobrepasar el valor de MAXSIZE. Un valor de 0 indica que no hay crecimiento. El valor
se puede especificar en megabytes (el valor predeterminado), en kilobytes o como porcentaje (%). Si
no se especifica FILEGROWTH, el valor predeterminado es el 10 por ciento y el valor mínimo es 64 KB
(una extensión). El tamaño especificado se redondea al múltiplo de 64 KB más próximo.
2.4.5. Collation
Este parámetro especifica la intercalación predeterminada para la base de datos. La intercalación
incluye las reglas que gobiernan el uso de caracteres de un lenguaje o un alfabeto.
Ejemplo:
El siguiente ejemplo crea una base de datos denominada Sample con un archivo de datos principal de
10 MB y un archivo de registro de 3 MB en una instancia predeterminada de SQL Server

2.5. Cómo funciona el registro de transacciones
SQL Server graba todas las transacciones en un registro de transacciones para mantener la coherencia
de la base de datos y facilitar la recuperación. El registro es un área de almacenamiento que efectúa
automáticamente el seguimiento de todos los cambios en la base de datos. SQL Server graba las
modificaciones al registro en disco cuando se ejecutan, antes de que se escriban en la base de datos.

El proceso de registro es el siguiente:
1. La aplicación envía una modificación de datos.
2. Cuando la modificación se ejecuta, las páginas de datos afectadas se cargan en la caché del búfer
desde el disco si no están ya cargadas en la caché del búfer por una consulta anterior.
3. Cada instrucción de modificación de datos se graba en el registro mientras se ejecuta. El cambio
siempre se graba en el registro y se escribe en disco antes de hacer la modificación en la base de datos.
Este tipo de registro se denomina registro de preescritura.
4. De forma repetitiva, el proceso de punto de comprobación escribe en disco todas las transacciones
completadas en la base de datos.
Si se produce un error del sistema, el proceso automático de recuperación utiliza el registro de

transacciones para aplicar todas las transacciones confirmadas y deshacer las transacciones
incompletas.
Los marcadores de transacción del registro se utilizan durante la recuperación automática para
determinar los puntos de inicio y fin de cada transacción. Una transacción se considera completa
cuando el marcador BEGIN TRANSACTION tiene un marcador COMMIT TRANSACTION asociado. Las
páginas de datos se escriben en disco cuando existe un punto de comprobación.
2.6. Configuración de las opciones de base de datos

Establezca las opciones de la base de datos mediante:
El Administrador corporativo de SQL Server
La instrucción ALTER DATABASE
Categorías de la opción de base de datos
Opciones automáticas
Opciones de cursor
Opciones de recuperación
Opciones de SQL
Opciones de estado
Después de haber creado una base de datos, puede definir opciones de base de datos con el
Administrador corporativo de SQL Server o por medio de la instrucción ALTER DATABASE.
Puede configurar varias opciones de base de datos, pero sólo se puede hacer en una sola base de datos
al mismo tiempo. Para que las opciones afecten a todas las bases de datos nuevas, cambie la base de
datos model.
La tabla siguiente enumera algunas de las opciones de uso más frecuente.


2.7. Recuperación de información de la base de datos
La siguiente tabla enumera los procedimientos almacenados del sistema de uso común que presentan
información acerca de las bases de datos y sus parámetros.

2.8. Administración del crecimiento de los archivos de datos y de registro
Cuando los archivos de datos crecen o cuando aumenta la actividad de modificación de datos, puede
que necesite ampliar el tamaño de los archivos de datos o de registro. Puede administrar el
crecimiento de la base de datos mediante el Administrador corporativo de SQL Server o con la
instrucción ALTER DATABASE. Para utilizar la instrucción ALTER DATABASE, debe encontrarse en la base
de datos master.
Puede controlar el tamaño de la base de datos mediante las tareas siguientes:
Configure los archivos de base de datos y de registro para que crezcan automáticamente.
Aumente o disminuya manualmente el tamaño actual o el tamaño máximo de los archivos de base de
datos y de registro existentes.
Agregue manualmente archivos secundarios de base de datos y de registro
2.9. Uso del crecimiento automático de los archivos

Puede configurar la opción de crecimiento automático de los archivos mediante la instrucción ALTER
DATABASE o el Administrador corporativo de SQL Server para especificar que los archivos de la base de
datos se expandan automáticamente en una cantidad especificada cuando sea necesario. El uso del
crecimiento automático de los archivos reduce las tareas administrativas relacionadas con la
ampliación manual del tamaño de la base de datos.
Puede especificar el tamaño inicial, el tamaño máximo y el incremento de crecimiento de cada archivo.
Aunque es posible especificar el crecimiento de los archivos en megabytes o kilobytes, debe
especificarlo como un porcentaje. Si no especifica un tamaño máximo, un archivo puede seguir
creciendo hasta ocupar todo el espacio disponible en disco.

Si se emplea el crecimiento automático de archivos con varios archivos, SQL Server utiliza una
estrategia de llenado proporcional en todos los archivos de cada grupo de archivos. A medida que los
datos se escriben en el grupo de archivos, SQL Server escribe una cantidad proporcional al espacio libre
en el archivo en cada archivo del grupo de archivos, en lugar de escribir todos los datos en el primer
archivo hasta que está lleno y, luego, escribir en el siguiente archivo.
Para obtener un rendimiento óptimo:
Asigne un tamaño inicial suficiente a la base de datos y al registro para evitar que se active con
frecuencia la característica de crecimiento automático.
Establezca un tamaño máximo para los archivos de datos en caso de que utilice varias bases de datos.
Establezca los incrementos de crecimiento del archivo de datos y de registro con unos tamaños
suficientes como para evitar que se active con frecuencia la característica de crecimiento automático.
Por ejemplo, si el registro crece 40 MB cada día, establezca el incremento de crecimiento automático
en 50 MB o 100 MB, en lugar de en 1 MB.
2.10. Ampliación de los archivos de la base de datos

Incluso si no configura un archivo existente para que crezca automáticamente, aún puede aumentar su
tamaño. Un valor de cero como incremento indica que no crece automáticamente.
2.11. Agregar archivos secundarios a la base de datos

Puede crear archivos secundarios en la base de datos para ampliar el tamaño de la misma. Utilice
archivos secundarios en la base de datos para ubicar los archivos de datos en discos físicos distintos
cuando no utilice la capacidad de creación de conjuntos de bandas en disco de los sistemas RAID.
EJEMPLO

El siguiente ejemplo aumenta el tamaño actual del registro y agrega un archivo de datos secundario a
la base de datos Sample.
ALTER DATABASE Sample MODIFY FILE ( NAME = 'SampleLog', SIZE = 15MB)
GO
ALTER DATABASE Sample ADD FILE

(NAME = 'SampleData2' , FILENAME='c:\Archivos de programa\ Microsoft SQL
Server\MSSQL\Data\Sample2.ndf', SIZE=15MB , MAXSIZE=20MB)
GO
2.12. Eliminación de una base de datos
Puede eliminar una base de datos cuando ya no la necesite. La eliminación de una base de datos quita
la base de datos y los archivos de disco que utiliza la base de datos.
2.12.1. Métodos de eliminación de una base de datos

Para eliminar bases de datos, puede utilizar el Administrador corporativo de SQL Server o ejecutar la
instrucción DROP DATABASE.
DROP DATABASE baseDeDatos [,…n]
En este ejemplo, se eliminan varias bases de datos con una sola instrucción.
DROP DATABASE Northwind, pubs

Al eliminar una base de datos, tenga en cuenta los siguientes hechos y directrices:
Con el Administrador corporativo de SQL Server, sólo puede eliminar una base de datos a la vez.
Con Transact-SQL, puede eliminar varias bases de datos a la vez.
Después de eliminar una base de datos, todos los Id. De inicio de sesión que utilizaba esa base de datos
como base de datos predeterminada ya no tendrán una base de datos predeterminada.
SQL Server no permite eliminar las bases de datos master, model y tempdb, pero permite eliminar la base de
datos del sistema msdb.
2.13. Cómo se almacenan los datos
Al crear una base de datos, es importante comprender cómo SQL Server almacena los datos para poder
calcular y especificar la cantidad de espacio de disco que hay que asignar a la base de datos. Tenga en
cuenta los siguientes hechos y directrices acerca del almacenamiento de los datos:
Todas las bases de datos tienen un archivo de datos principal, que se identifica mediante la extensión
de nombre de archivo .mdf, y uno o varios archivos de registro de transacciones, que se identifican

mediante la extensión de nombre de archivo .ldf. Una base de datos puede tener también archivos de
datos secundarios, que se identifican mediante la extensión de nombre de archivo .ndf. Estos archivos
físicos tienen nombres del sistema operativo y nombres de archivo lógicos que se pueden utilizar en
instrucciones Transact-SQL.
Cuando se crea una base de datos, se hace una copia de la base de datos model, que incluye las tablas
del sistema. El tamaño mínimo de una base de datos debe ser igual o mayor que el tamaño de la base
de datos model.
SQL Server almacena, lee y escribe datos en bloques de 8 kilobytes (KB) de espacio contiguo en disco
que se denominan páginas. Esto significa que una base de datos puede almacenar 128 páginas por
megabyte.
Las filas no pueden abarcar más de una página. Por tanto, la máxima cantidad de datos de una fila,
quitando el espacio necesario para la cabecera de la fila, es de 8060 bytes.
Todas las páginas se almacenan en extensiones. Una extensión consta de ocho páginas contiguas, o 64
KB. Por tanto, una base de datos tiene 16 extensiones por megabyte.
Los archivos de los registros de transacciones contienen toda la información necesaria para recuperar
la base de datos en caso de un error del sistema. De forma predeterminada, el tamaño del registro de
transacciones es el 25 por ciento del tamaño de los archivos de datos. Utilice esta proporción como
punto de partida y ajústela según las necesidades de la aplicación.
2.14. Limitar lista de bases de datos en sql server

Hay escenarios en los que es necesario el filtrar la lista de Bases de Datos que existen en determinada
instancia para algunos usuarios. Un posible escenario seria cuando tenemos dos clientes que accesan
sus bases de datos en la misma instancia y no queremos mostrarle la base de datos de uno al otro.
Cliente1 es dueño de BaseDeDatos1 y Cliente2 es dueño de BaseDeDatos2.
CREATE DATABASE [BaseDeDatos1]
GO
CREATE DATABASE [BaseDeDatos2]

GO
Para poder lograr limitar la lista a solo las que cada cliente tiene acceso haríamos los siguientes pasos:
Crear un Login para cada uno de los clientes sin hacer el mapping a su respectiva base de datos:
CREATE LOGIN [Cliente1] WITH PASSWORD = 'P@ssw0rd'
GO

CREATE LOGIN [Cliente2] WITH PASSWORD = 'P@ssw0rd'

GO
Denegar el permiso a ver todas las bases de datos: [VIEW ANY DATABASE]
http://msdn.microsoft.com/en-us/library/ms189077%28v=sql.105%29.aspx
USE [master]
GO
DENY VIEW ANY DATABASE TO Cliente1

GO
DENY VIEW ANY DATABASE TO Cliente2

GO
Este es uno de los pasos más importantes, cambiar el owner de la base de datos al usuario
correspondiente:
USE [BaseDeDatos1]
GO
sp_changedbowner 'Cliente1'
GO
USE [BaseDeDatos2]
GO
sp_changedbowner 'Cliente2'
GO
Terminaremos con el siguiente resultado:

El Cliente1 solo puede ver lo que tiene acceso [BaseDeDatos1] y el Cliente2 solo puede ver
[BaseDeDatos2].

Capitulo 3. Explotacion y Seguridad
3. Objetivo
Proceso de puesta en funcionamiento de una base de datos para integrarla desde el equipo de
desarrollo al servidor final. Garantizar la información almacenada de una base de datos frente a
posibles pérdidas por fallos de hardware o ataques intencionados o no, con el uso de copias de
seguridad. Además se hará un estudio sobre los diferentes modos de inicio de sesión y permisos
que se pueden gestionar con SQL Server 2008 para proteger nuestras bases de datos.
3.1. Crear una tarea de toma de copia de seguridad de base de datos

manualmente
Es esencial crear y mantener copias de seguridad en cualquier sistema de administración de base de
datos. Hay un rango de escenarios que confirman esta afirmación. Fallas de hardware, software o
errores de usuario, ataques maliciosos o problemas del sistema pueden llevar a una base de datos
corrupta. Incluso si sus sistemas de administración de bases de datos nunca han experimentado tales
escenarios, usted tiene que estar preparado
Las estrategias de tomas de copias de seguridad deberían ser planeadas y documentadas en avanzada.
Es importante identificar y clasificar áreas de la base del sistema de administración de la base de datos
por importancia y nivel de riesgo de corrupción. También, cualquier estrategia de toma de copias de
seguridad de la base de datos debería ser probada y verificada en escenarios de ambiente y tiempo
apropiados – un proceso de toma de copia de seguridad fallado es como si no hubiera ocurrido tal
proceso.
SQL Server provee la característica Maintenance Plans vía SQL Server Management Studio, la cual hace
a las estrategias de toma de copias de seguridad fácil y automatizada.
Hay dos métodos para crear un plan de mantenimiento SQL Server con la tarea Back Up Database – un
manual y vía la característica Maintenance Plan Wizard. Note que un plan de mantenimiento puede
contener un número de tareas adicionales (por ejemplo, Check Database Integrity, Shrink Database,
etc.) al mismo tiempo, en un orden apropiado de ejecución, si se requiere.
3.2. Crear una tarea de toma de copia de seguridad de base de datos

manualmente
Para crear un plan de mantenimiento en SQL Server Management Studio con una tarea de respaldo de
base de datos apropiada:
En el árbol Object Explorer, usando la lista contextual de la carpeta Maintenance Plans, seleccione la
opción New Maintenance Plan.
Ingrese el nombre de un nuevo plan de mantenimiento (por ejemplo, BackupMaintenancePlan).
Usando la caja de herramientas Maintenance Plan Tasks, añada el elemento (tarea) Back Up Database
Task a la superficie de diseño BackupMaintenancePlan.

Una vez añadida, la tarea de toma de copia de

seguridad está establecida con los valores por
defecto, como BackupAction (Base de
datos), BackupDeviceType (Archivo), UseExpiration
(Falso) y así por el estilo.
Hay más de 60 propiedades en el panel Properties
de la tarea de toma de copia de seguridad que
pueden ser usadas para definir y afinar la tarea.
Usando el panel Properties, establezca las
propiedades de su estrategia de toma de copias de
seguridad.
Adicionalmente, use la opción Edit del

elemento Back Up Database Task en la superficie de diseño para abrir el diálogo Back Up Database
Task.

El diálogo provee un método más conveniente para configurar las propiedades de la tarea de toma de
copia de seguridad que el panel Properties, pero no todas las propiedades pueden ser establecidas vía
el diálogo (por ejemplo, las propiedades TimeOut u ObjectTypeSelection)
Si es necesario, use los pasos 3 al 5 para añadir copias de seguridad adicionales u otro tipo de tareas al
plan de mantenimiento
Use la opción Subplan Schedule para establecer el itinerario para la(s) tarea(s). La opción abrirá e
diálogo estándar New Job Schedule, como fue usado por la característica SQL Server Jobs.
Adicionalmente, use la opción Add Subplan para añadir sub planes al plan de mantenimiento para
agrupar tareas de mantenimiento según el tiempo del itinerario
Una vez que la(s) tarea(s) y propiedades están configuradas, grabe el plan de mantenimiento
(BackupMaintenancePlan). Esto creará al mismo tiempo la tarea correspondiente automáticamente
(BackupMaintenancePlan.Subplan_1) en el sub nodo Jobs del nodo SQL Server Agent. Usted puede
usar la tarea para establecer acciones adicionales, como alertas y notificaciones (por ejemplo, vía
correo electrónico)
3.3. Crear una copia de seguridad de base de datos usando el asistente

SQL Server Management Studio provee un método adicional similar a un asistente para crear un plan
de toma de copias de seguridad de bases de datos. Este método es más conveniente que el manual,
pero provee menos opciones de afinado. Sin embargo, si su estrategia de copias de seguridad no
requiere afinado adicional, puede ser la solución correcta.
Para crear un plan de mantenimiento con una tarea de copia de seguridad de base de datos apropiada
vía el asistente:
En el árbol Object Explorer, seleccione la opción New Maintenance Plan desde el menú contextual de
la carpeta Maintenance Plans
El diálogo Select Plan Properties se abrirá y proveerá los ajustes iniciales, como una opción de nombre
y programación

En el
diálogo Selec
t
Maintenance Tasks, seleccione las tareas de copias de seguridad de bases de datos necesarias
(Completa, Diferencial o Registro de Transacciones). Por supuesto, cualquier tarea de mantenimiento
adicional puede ser seleccionada también

Usando el
diálogo Selec
t
Maintenance Task Order, establezca las prioridades de ejecución de las tareas.

Dependiendo de las tareas seleccionadas, el asistente continuará con los diálogos apropiados (por
ejemplo, para la tarea Back Up Database, el asistente proveerá el mismo diálogo como se describió en
la sección Crear una tarea de copia de base de datos manualmente)
Después de que el asistente termina, un nuevo plan de mantenimiento es creado con los sub planes y
tareas apropiados. Note que si la opción Separate schedules for each task está seleccionada en el
diálogo Select Plan Properties, múltiples sub planes y sus tareas correspondientes serán creados
cuando el asistente se complete.
Una vez creado, el plan de mantenimiento de la base de datos puede ser modificado usando los
métodos manuales descritos previamente – el asistente puede ser usado sólo para crear, no para
modificar planes existentes
Aunque los planes de copias de seguridad de mantenimiento de SQL Server proveen ventajas viables,
como GUI y soporte de itinerario nativo, hay muchas desventajas que los DBAs deben conocer.

3.4. Asistente Para Generar Y Publicar Scripts

Use el Asistente Generar y publicar scripts para crear un script Transact-SQL para muchos objetos. El
asistente genera un script de todos los objetos de una base de datos o un subconjunto de los objetos que
seleccione. El asistente dispone de muchas opciones para los scripts, como la posibilidad de incluir permisos,
la intercalación, las restricciones, etc.
3.4.1. Abrir el asistente generar y publicar scripts
En el Explorador de objetos, expanda Bases de datos, haga clic con el botón secundario en una base de
datos, seleccione Tareas y, a continuación, haga clic en Generar scripts. Siga las instrucciones del asistente
para incluir los objetos de la base de datos en el script.
En la página Elegir objetos, seleccione los objetos que se van a incluir en el script.
En la página Establecer opciones de scripting, seleccione Guardar scripts en una ubicación específica.
Para especificar las opciones de scripting avanzadas, seleccione el botón Avanzadas en la sección Guardar
scripts en una ubicación específica.
Seleccione la ubicación para el script generado: a un archivo, una ventana del Editor de consultas del motor
de base de datos o el Portapapeles.
En la página Resumen, revise sus selecciones. Haga clic en Anterior para cambiar sus selecciones. Haga clic
en Siguiente para generar un script de los objetos seleccionados.
En la página Guardar o publicar scripts, supervise el progreso de la generación del script.
3.5. Restablecer una base de datos sql server a partir de archivos BAK
Aparecerá la caja de diálogo Connect to Server
Si no aparece, en el menú File, elija Connect Object Explorer.
En Server Type, elija Database Engine.
Ingrese el nombre del servidor requerido y de la información de autenticación (si no se rellena
automáticamente)
AVISO: Esta es la información de su instalación local de SQL Server Express.
Haga clic en Connect.
Haga clic con el botón secundario en la carpeta Databases y elija New Database.
Ingrese un nombre para base de datos y luego haga clic en OK.
Abra la carpeta de la base de datos para encontrar su base de datos nueva.
Haga clic con el botón secundario en la base de datos nueva y en el menú Tasks, elijaRestore y
luego Database.
Elija From Device y haga clic en... para buscar.
Haga clic en Add, navegue a y elija su archivo BAK y haga clic en OK.
Elija su archivo BAK.

A la izquierda, haga clic en Options y elija Overwrite the existing database.
Haga clic en OK para ejecutar la recuperación.
Verifique el contenido de su base de datos, el cual ya está activa en su máquina local.
3.6. Restablecer una base de datos sql server de archivos MDF

Aparecerá la caja de diálogo Connect to Server.
6Si no aparece, en el menú File, elija Connect Object Explorer.
En Server Type, elija Database Engine.
Ingrese la información requerida del nombre de servidor y autenticación (si no se rellena automáticamente)
AVISO: Esta es la información de su intalación local de SQL Server Express.
Haga clic en Connect.
Haga clic con elbotón secundario en la carpeta Databases y luego elija Attach.
Haga clic en Add, navegue para elegir el archivo MDF que desee usar y luego haga dos veces clic en OK.
Verifique el contenido de su base de datos, el cual ya está activo en su máquina local.
3.7. Crear un usuario de base de datos
Antes de empezar
Información previa
Un usuario es una entidad de seguridad de la base de datos. Los inicios de sesión deben estar asignados a un
usuario de base de datos para poder conectarse a una base de datos. Un inicio de sesión se puede asignar a
bases de datos diferentes como usuario diferente pero solo se puede asignar como un usuario en cada base
de datos. En una base de datos parcialmente independiente, puede crearse un usuario que no tenga un
inicio de sesión. Para obtener más información acerca de los usuarios de bases de datos independientes, vea
CREATE USER (Transact-SQL). Si el usuario invitado de una base de datos está habilitado, un inicio de sesión
que no esté asignado a un usuario de la base de datos puede entrar en la base de datos como el usuario
invitado.
Seguridad Nota:
El usuario invitado suele estar deshabilitado. No habilite al usuario invitado a menos que sea
necesario.Como entidad de seguridad, se pueden conceder permisos a los usuarios. El ámbito de un usuario
es la base de datos. Para establecer conexión con una base de datos concreta de la instancia de SQL Server,
un inicio de sesión debe estar asignado a un usuario de la base de datos. Los permisos dentro de la base de
datos se conceden y deniegan al usuario de la base de datos, no al inicio de sesión.
3.7.1. Para crear un usuario de base de datos

1. En el Explorador de objetos, expanda la carpeta Bases de datos.
2. Expanda la base de datos en la que se va a crear el usuario de la misma.
3. Haga clic con el botón secundario en la carpeta Seguridad, seleccione Nuevo y seleccione Usuario.

4. En el cuadro de diálogo Tipo de regla, seleccione Puerto, y luego pulse en Siguiente.
5. En el cuadro de diálogo Tipo de regla, seleccione Puerto, y luego pulse en Siguiente. Si ha
elegido Usuario de Windows en la listaTipo de usuario, también puede hacer clic en los puntos
suspensivos (…) para abrir el cuadro de diálogo Seleccionar usuarios o grupos.
6. En el cuadro de diálogo Tipo de regla, seleccione Puerto, y luego pulse en Siguiente. Como
alternativa, haga clic en los puntos suspensivos (…) para abrir el cuadro de diálogo Seleccionar
inicio de sesión. Si selecciona Usuario SQL con inicio de sesión o Usuario de Windows en la
lista Tipo de usuario, estará disponible Nombre de inicio de sesión.
esquema. Si selecciona Usuario SQL con inicio de sesión, Usuario SQL sin inicio de sesión,
o Usuario de Windows en la lista Tipo de usuario, estará disponible Esquema predeterminado.
certificado. Si selecciona Usuario asignado a un certificado en la lista Tipo de usuario, estará
disponible Nombre de certificado.
clave asimétrica. Si selecciona Usuario asignado a una clave asimétrica en la lista Tipo de usuario,
estará disponible Nombre de clave asimétrica.
10. Haga clic en Aceptar.
3.7.2. Opciones adicionales

En el cuadro de diálogo Usuario de base de datos - Nuevo también se proporcionan opciones en cuatro
páginas adicionales: Esquemas de propiedad, Pertenencia, Elementos protegibles y Propiedades
extendidas.
 La página Esquemas de propiedad enumera todos los esquemas posibles que pueden ser
propiedad del nuevo usuario de base de datos.Para agregar o quitar esquemas en un usuario de
base de datos, en Esquemas propiedad de este usuario, active o desactive las casillas situadas
junto a los esquemas.
 La página Pertenencia enumera todos los roles de pertenencia de base de datos posibles que
pueden ser propiedad del nuevo usuario de base de datos. Para agregar o quitar roles en un usuario
de base de datos, en Pertenencia al rol de la base de datos, active o desactive las casillas situadas
junto a los roles.
 La página Elementos protegibles muestra todos los elementos protegibles posibles y los permisos
en esos elementos protegibles que se pueden conceder al inicio de sesión.
 La página Propiedades extendidas permite agregar propiedades personalizadas a los usuarios de
base de datos. En esta página están disponibles las opciones siguientes.
Base de datos
Muestra el nombre de la base de datos seleccionada. Este campo es de solo lectura.
Intercalación
Muestra la intercalación utilizada para la base de datos seleccionada. Este campo es de solo lectura.
Propiedades

Muestra o especifica las propiedades extendidas del objeto. Cada propiedad extendida está
formada por un par nombre/valor de metadatos asociados al objeto.
Puntos suspensivos (…)
Haga clic en los puntos suspensivos (…) que se encuentran a continuación de Valor para abrir el
cuadro de diálogo Valor para propiedad extendida. Escriba o muestre el valor de la propiedad
extendida en esta ubicación mayor. Para obtener más información, vea Valor para propiedad
extendida (cuadro de diálogo).
Eliminar
Elimina la propiedad extendida que se ha seleccionado.
3.7.3. Usar Transact-SQL
Para crear un usuario de base de datos

1. En el Explorador de objetos, conéctese a una instancia del Motor de base de datos.
2. En la barra Estándar, haga clic en Nueva consulta.
3. Copie y pegue el siguiente ejemplo en la ventana de consulta y haga clic en Ejecutar.
-- Creates the login AbolrousHazem with password '340$Uuxwp7Mcxo7Khy'.

CREATE LOGIN AbolrousHazem
WITH PASSWORD = '340$Uuxwp7Mcxo7Khy';
GO
-- Creates a database user for the login created above.

CREATE USER AbolrousHazem FOR LOGIN AbolrousHazem;
GO

Capitulo 4. SQL I
4. Objetivo
Trabajo con el analizador de consultas de SQL Server 2008. Estudiar las consultas en lenguaje SQL.
Al finalizar la unidad, el alumno será capaz de implementar consultas simples, complejas y
compuestas, de modo que pueda realizar cualquier consulta que necesite sobre una o varias tablas
de bases de datos.
4.1. Características del lenguaje

Una sentencia SQL es como una frase (escrita en inglés) con la que decimos lo que queremos obtener y de
donde obtenerlo.
Todas las sentencias empiezan con un verbo (palabra reservada que indica la acción a realizar), seguido del
resto de cláusulas, algunas obligatorias y otras opcionales que completan la frase. Todas las sentencias
siguen una sintaxis para que se puedan ejecutar correctamente, para describir esa
4.2. ¿Qué es el SQL?

El SQL (Structured query language), lenguaje de consulta estructurado, es un lenguaje surgido de un
proyecto de investigación de IBM para el acceso a bases de datos relacionales. Actualmente se ha
convertido en un estándar de lenguaje de bases de datos, y la mayoría de los sistemas de bases de datos lo
soportan, desde sistemas para ordenadores personales, hasta grandes ordenadores.
Por supuesto, a partir del estándar cada sistema ha desarrollado su propio SQL que puede variar de un
sistema a otro, pero con cambios que no suponen ninguna complicación para alguien que conozca un SQL
concreto, como el que vamos a ver aquí correspondiente al SQL SERVER.
Como su nombre indica, el SQL nos permite realizar consultas a la base de datos. Pero el nombre se queda
corto ya que SQL además realiza funciones de definición, control y gestión de la base de datos. Las
sentencias SQL se clasifican según su finalidad dando origen a tres „lenguajes‟ o mejor dicho sublenguajes:
4.2.1. DDL
(Data Definition Language), lenguaje de definición de datos, incluye órdenes para definir, modificar o borrar
las tablas en las que se almacenan los datos y de las relaciones entre estas. (Es el que más varia de un
sistema a otro)
4.2.2. DCL
(Data Control Language), lenguaje de control de datos, contiene elementos útiles para trabajar en un
entorno multiusuario, en el que es importante la protección de los datos, la seguridad de las tablas y el

establecimiento de restricciones en el acceso, así como elementos para coordinar la compartición de datos
por parte de usuarios concurrentes, asegurando que no interfieren unos con otros.
4.2.3. DML
(Data Manipulation Language), lenguaje de manipulación de datos, nos permite recuperar los datos
almacenados en la base de datos y también incluye órdenes para permitir al usuario actualizar la base de
datos añadiendo nuevos datos, suprimiendo datos antiguos o modificando datos previamente almacenados.
Analizador de consultas SQL.

Instalación de base de datos Curso
4.2.3.1. LENGUAJE DE MANIPULACIÓN DE DATOS (DML).

Empezaremos por estudiar la sentencia SELECT, que permite recuperar datos de una o varias tablas. La
sentencia SELECT es con mucho la más compleja y potente de las sentencias SQL. Empezaremos por ver las
consultas más simples, basadas en una sola tabla.
Esta sentencia forma parte del DML (lenguaje de manipulación de datos), en este tema veremos cómo
seleccionar columnas de una tabla, cómo seleccionar filas y cómo obtener las filas ordenadas por el criterio
que queramos.
El resultado de la consulta es una tabla lógica, porque no se guarda en el disco sino que está en memoria y
cada vez que ejecutamos la consulta se vuelve a calcular.
Cuando ejecutamos la consulta se visualiza el resultado en forma de tabla con columnas y filas, pues en la
SELECT tenemos que indicar qué columnas queremos que tenga el resultado y qué filas queremos
seleccionar de la tabla origen.

4.3. Sintaxis básicas de la sentencia SELECT (consultas simples)
4.3.1. La tabla origen – FROM
Con la cláusula FROM indicamos en qué tabla tiene que buscar la información. En este capítulo de consultas
simples el resultado se obtiene de una única tabla. La sintaxis de la cláusula es:
FROM especificación de tabla
Una especificación de tabla puede ser el nombre de una consulta guardada (las que aparecen en la ventana
de base de datos), o el nombre de una tabla que a su vez puede tener el siguiente formato:
4.3.2. Cláusulas DISTINCT / ALL

Al incluir la cláusula DISTINCT en la SELECT, se eliminan del resultado las repeticiones de filas. Si por el
contrario queremos que aparezcan todas las filas incluidas las duplicadas, podemos incluir la cláusula ALL o
nada, ya que ALL es el valor que SQL asume por defecto.
NOTA:
Para crear un script, entiéndase escribir una sentencia sql, estando en el el Sql Server Managment Studio,
seleccionamos el explorador de objetos, nos colocamos encima de la Base de Datos con la que estamos
trabajando y le damos botón derecho del mouse, y seleccionamos New Query, o nueva consulta y se nos

pondrá una pantalla en blanco llamada, Query Analizer. Dentro de ella podemos escribir las sentencias
Select.
Una vez que tienes el código de del script, pulsamos Ejecutar (Execute) o la tecla F5 o la combinación de
teclas CTRL+E y se mostraran esos datos en el Sql Server Managment Studio.
Por ejemplo queremos saber los códigos de los directores de oficina, digitaremos el siguiente Script.
SELECT director FROM empleados
SELECT ALL director FROM empleados
Lista los códigos de los directores de las oficinas. El director 7698 aparece en 3 empleados, por lo tanto
aparecerá tres veces en el resultado de la consulta, al igual que otros empleados.

SELECT DISTINCT director FROM empleados
En este caso el valor 7698 aparecerá una sola vez ya que le decimos que liste los distintos valores de
directores
4.3.3. Cláusula TOP

La cláusula TOP permite sacar la n primeras filas de la tabla origen. No elige entre valores iguales, si pido los
25 primeros valores pero el que hace 26 es el mismo valor que el 25, entonces devolverá 26 registros en vez
de 25 (o los que sean). Siempre se guía por la columna de ordenación, la que aparece en la cláusula ORDER
BY o en su defecto la clave principal de la tabla.
Por ejemplo queremos ver todos los empleados más antiguos de la empresa.
SELECT emp_no, apellido fecha_alta

FROM empleados
Order by fecha_alta
Ahora queremos ver los dos empleados más antiguos de la empresa.
SELECT TOP 2 emp_no, apellido fecha_alta

FROM empleados
Order by fecha_alta
4.3.4. Cláusula WHERE
La cláusula WHERE selecciona únicamente las filas que cumplan la condición de selección especificada. En la
consulta sólo aparecerán las filas para las cuales la condición es verdadera (TRUE), los valores nulos (NULL)
no se incluyen por lo tanto en las filas del resultado. La condición de selección puede ser cualquier
condición válida o combinación de condiciones utilizando los operadores NOT (no) AND (y) y OR (ó).
Para empezar veamos un ejemplo sencillo:
SELECT apellido
FROM empleados
WHERE dep_no = 10
SELECT apellido
FROM empleados
WHERE dep_no = 10 AND salario > 2500

4.3.4.1. CONDICIONES DE SELECCION
Son las condiciones que pueden aparecer en la cláusula WHERE.
En SQL tenemos cinco condiciones básicas:
test de comparación
test de rango
test de pertenencia a un conjunto
test de valor nulo
test de correspondencia con patrón
4.3.4.1.1. Test de comparación

Compara el valor de una expresión con el valor de otra.
La sintaxis es la siguiente:
= igual que
<>distinto de
< menor que
<= menor o igual
> mayor que
>= mayor o igual
SELECT emp_no, apellido, salario

FROM empleados
WHERE salario >= 1300 AND salario <=1500

4.3.4.2. Test de rango (BETWEEN).
Examina si el valor de la expresión está comprendido entre los dos valores definidos por exp1 y exp2.
Tiene la siguiente sintaxis:

FROM empleados
WHERE salario BETWEEN 1300 AND 1500

FROM empleados
WHERE salario NOT BETWEEN 1300 AND 1500

4.3.4.3. Test de pertenencia a conjunto (IN)
Examina si el valor de la expresión es uno de los valores incluidos en la lista de valores.
SELECT emp_no, dep_no, apellido, oficio

FROM empleados
WHERE dep_no IN (10, 30, 1600)
SELECT emp_no, dep_no, apellido, oficio

FROM empleados
WHERE oficio IN ('analista','director','ingeniero')

4.3.4.4. TEST DE VALOR NULO (IS NULL)
Una condición de selección puede dar como resultado el valor verdadero TRUE, falso FALSE o nulo NULL.
Cuando una columna que interviene en una condición de selección contiene el valor nulo, el resultado de la
condición no es verdadero ni falso, sino nulo, sea cual sea el test que se haya utilizado. Por eso si queremos
listar las filas que tienen valor en una determinada columna, no podemos utilizar el test de comparación, la
condición oficina = null devuelve el valor nulo sea cual sea el valor contenido en oficina. Si queremos
preguntar si una columna contiene el valor nulo debemos utilizar un test especial, el test de valor nulo.
Ejemplo:
SELECT emp_no, dep_no, apellido, oficio, comision

FROM empleados
Where comision is null
SELECT emp_no, dep_no, apellido, oficio, comision

FROM empleados
Where comision is not nul
4.3.4.5. TEST DE CORRESPONDENCIA CON PATRÓN (LIKE)
Se utiliza cuando queremos utilizar caracteres comodines para formar el valor con el comparar.
4.3.4.5.1. COMODINES
% Cualquier número de caracteres

_ Para un carácter individual
[ ] Para un conjunto de caracteres que esté dentro del corchete
[ ^ ] Que el carácter individual que no esté dentro del corchete
EJEMPLO: LIKE ‘%een’ Muestra todos los caracteres que acaben con een
EJEMPLO: LIKE ‘%een%’ Muestra todos los caracteres que contengan een en ese orden
EJEMPLO: LIKE ‘_en’ Muestra todos los caracteres que contenga tres letras y acaben en en
EJEMPLO: LIKE ‘[CK% ]’ Muestra todos los caracteres que empiecen por C o K
EJEMPLO: LIKE ‘[S-V]ing’ Nombre de 4 letras cuya primera letra estuviera entre S o V y acabe
en ing
EJEMPLO: LIKE ‘M[^c]%’ Todos los que empiecen por M y segunda letra no sea una c. No hay
límite de caracteres.



4.4. Directivas de procesos por lotes

4.4.1. GO:
Envia lotes de intrucciones de TRANSACT SQL a las herramientas y utilidades (Sirve para
separar bloques de instrucciones)
4.4.2. EXEC O EXECUTE:
Ejecuta funciones definidas por el usuario, procedimientos de sistema y procedimientos
almacenados.
4.4.3. Comentarios en SQL

En línea: --
En Bloque: /* comentario */
4.4.4. Tablas en SQL

4.4.4.1. Tabla master:
Es la tabla que contiene como generar una base de datos y sobre ella, se crean todas las bases
de datos.
4.4.4.2. Tabla model:
Es la tabla modelo, las bases de datos creadas se basan en esta tabla como modelo.
4.4.4.3. Tabla Northwind y Pubs:
Son tablas de ejemplos que vienen con SQL y todo usuario puede trabajar con ellas.
4.5. Identificadores para los objetos
Los nombres que se le dan a las tablas, lo primero es que no pueden empezar por un número,
deben empezar por un signo alfabético, pueden incluir el guion bajo (_), la arroba @ y la
almohadilla #.
Generalmente para las variables locales se usan @ + el nombre.

EJEMPLO: @Contador.
Para las variables totales se usan dos arrobas + el nombre @@Contador
EJEMPLO: @@Error
#Nombre: indica una tabla o procedimiento temporal (Local)
##Nombre: Igual que el anterior pero global.

4.6. Utilización de alias
La cláusula AS que asigna el alias puede omitirse
Usar alias para una tabla es opcional cuando su finalidad consiste en simplificar su nombre original, y obligatorio
en consultas cuya sintaxis lo requiera (más adelante lo utilizaremos)
Usar alias para las columnas puede ser necesario porque los títulos o cabeceras que muestra la salida de una
consulta para las columnas seleccionadas, se corresponden con los nombres de las columnas de las tablas o las
expresiones y esto no siempre es muy visual. Para mejorar su legibilidad y estética se utilizan los alias de columna.
También puede ser utilizado, en algunos casos, para renombrar la columna y utilizar este nombre posteriormente
Aliastabla es un nombre de alias, es como un segundo nombre que asignamos a la tabla, si en una consulta
definimos un alias para la tabla, esta se deberá nombrar utilizando ese nombre y no su nombre real, además
ese nombre sólo es válido en la consulta donde se define. El alias se suele emplear en consultas basadas en
más de una tabla que veremos en el tema siguiente. La palabra AS que se puede poner delante del nombre
de alias es opcional y es el valor por defecto por lo que no tienen ningún efecto.
4.6.1. Ejemplos de utilización de alias

Ejemplos de alias de tabla
1 - Mostrar el apellido y la fecha de alta de todos los empleados.
SELECT apellido [nombre del empleado]

,fecha_alta as fecha
,oficio as "Cargo"
,Salario 'Sueldo Bruto'
FROM empleados empleados;

4.7. Utilización del *
Se utiliza el asterisco * en la lista de selección para indicar 'todas las columnas de la tabla'. Tiene dos
ventajas:
Evitar nombrar las columnas una a una (es más corto).
Si añadimos una columna nueva en la tabla, esta nueva columna saldrá sin tener que modificar la consulta.
Se puede combinar el * con el nombre de una tabla (ej. oficinas.*), pero esto se utiliza más cuando el origen
de la consulta son dos tablas.
SELECT * FROM departamentos o bien SELECT dnombre.* FROM departamentos --Lista todos los datos de
los departamentos
4.7.1. Columnas de la tabla origen

Las columnas se pueden especificar mediante su nombre simple (nbcol) o su nombre cualificado
(nbtabla.nbcol, el nombre de la columna precedido del nombre de la tabla que contiene la columna y
separados por un punto).
El nombre cualificado se puede emplear siempre que queramos y es obligatorio en algunos casos que
veremos más adelante.
Cuando el nombre de la columna o de la tabla contiene espacios en blanco, hay que poner el nombre entre
corchetes [ ] y además el número de espacios en blanco debe coincidir. Por ejemplo [codigo de cliente] no es
lo mismo que [codigo de cliente] (el segundo lleva un espacio en blanco delante de código)
Ejemplo:

SELECT apellido, oficio, fecha_alta FROM empleados
4.8. Columnas calculadas.

Además de las columnas que provienen directamente de la tabla origen, una consulta SQL puede incluir
columnas calculadas cuyos valores se calculan a partir de los valores de los datos almacenados.
Para solicitar una columna calculada, se especifica en la lista de selección una expresión en vez de un
nombre de columna. La expresión puede contener sumas, restas, multiplicaciones y divisiones,
concatenación +, paréntesis y también funciones predefinidas).
Ejemplos:
SELECT apellido as nombre, salario, comision, salario+isnull (comision, 0) as total FROM empleados

4.9. Ordenación de las filas - ORDER BY

Para ordenar las filas del resultado de la consulta, tenemos la cláusula ORDER BY.
Con esta cláusula se altera el orden de visualización de las filas de la tabla pero en ningún caso se modifica el
orden de las filas dentro de la tabla. La tabla no se modifica.
Podemos indicar la columna por la que queremos ordenar utilizando su nombre de columna (nbcolumna) o
utilizando su número de orden que ocupa en la lista de selección (Nºcolumna).
Ejemplo:
SELECT apellido, oficio, salario FROM empleados ORDER BY oficio
Es equivalente a:
SELECT apellido, oficio, salario FROM empleados ORDER BY 2

Por defecto el orden será ascendente (ASC) (de menor a mayor si el campo es numérico, por orden
alfabético si el campo es de tipo texto, de anterior a posterior si el campo es de tipo fecha/hora.
SELECT apellido, oficio, salario

FROM empleados
ORDER BY apellido -- Obtiene un listado alfabético de los empleados
Si queremos podemos alterar ese orden utilizando la cláusula DESC (Descendente), en este
caso el orden será el inverso al ASC.
Ejemplos:
SELECT apellido, oficio, salario FROM empleados ORDER BY oficio desc
SELECT apellido, oficio, salario FROM empleados ORDER BY 2 desc


También podemos ordenar por varias columnas, en este

caso se indican las columnas separadas por comas.
Se ordenan las filas por la primera columna de ordenación,
para un mismo valor de la primera columna, se ordenan por
la segunda columna, y así sucesivamente.
La cláusula DESC o ASC se puede indicar para cada columna
y así utilizar una ordenación distinta para cada columna.
Por ejemplo ascendente por la primera columna y dentro
de la primera columna, descendente por la segunda
columna.
Ejemplos:
SELECT apellido, oficio, salario FROM empleados ORDER BY oficio, apellido
Es equivalente a:
SELECT apellido, oficio, salario FROM empleados ORDER

BY 1,2 desc
También podemos utilizar

SELECT apellido, oficio, salario FROM empleados ORDER BY 1, apellido desc

4.10. Subconsultas
Una subconsulta es una sentencia SELECT que aparece
dentro de otra sentencia SELECT que llamaremos consulta
principal.
Se puede encontrar en la lista de selección, en la cláusula

WHERE o en la cláusula HAVING de la consulta principal.
Una subconsulta tiene la misma sintaxis que una sentencia

SELECT normal exceptuando que aparece encerrada entre paréntesis, no puede contener la cláusula ORDER
BY, ni puede ser la UNION de varias sentencias SELECT, además tiene algunas restricciones en cuanto a
número de columnas según el lugar donde aparece en la consulta principal. Estas restricciones las iremos
describiendo en cada caso.
Cuando se ejecuta una consulta que contiene una subconsulta, la subconsulta se ejecuta por cada fila de la
consulta principal.
Se aconseja no utilizar campos calculados en las subconsultas, ralentizan la consulta.
Las consultas que utilizan subconsultas suelen ser más fáciles de interpretar por el usuario.
A menudo, es necesario, dentro del cuerpo de una subconsulta, hacer referencia al valor de una columna en
la fila actual de la consulta principal, ese nombre de columna se denomina referencia externa. Una
referencia externa es un nombre de columna que estando en la subconsulta, no se refiere a ninguna
columna de las tablas designadas en la FROM de la subconsulta sino a una columna de las tablas designadas
en la FROM de la consulta principal. Como la subconsulta se ejecuta por cada fila de la consulta principal, el
valor de la referencia externa irá cambiando.
Ejemplo:
Obtener todos los empleados que tienen el mismo oficio que GARRIDO
SELECT emp_no "Nº Empleado", apellido, oficio

FROM empleados
WHERE oficio = (SELECT oficio
FROM empleados
WHERE apellido = 'GARRIDO');

En este ejemplo la consulta principal es SELECT emp_no "Nº Empleado", apellido, oficio
FROM empleados. La subconsulta es (SELECT oficio
FROM empleados
WHERE apellido = ‘GARRIDO’).
4.10.1. Anidar subconsultas
Las subconsultas pueden anidarse de forma que una subconsulta aparezca en la cláusula WHERE (por
ejemplo) de otra subconsulta que a su vez forma parte de otra consulta principal. En la práctica, una
consulta consume mucho más tiempo y memoria cuando se incrementa el número de niveles de
anidamiento.
La consulta resulta también más difícil de leer, comprender y mantener cuando contiene más de uno o dos
niveles de subconsultas.
Ejemplo:
SELECT numemp, nombre FROM empleados WHERE numemp = (SELECT rep FROM pedidos WHERE clie =
(SELECT numclie FROM clientes WHERE nombre = 'Julia Antequera'))
En este ejemplo, por cada linea de pedido se calcula la subconsulta de clientes, y esto se repite por cada
empleado, en el caso de tener 10 filas de empleados y 200 filas de pedidos (tablas realmente pequeñas), la
subconsulta más interna se ejecutaría 2000 veces (10 x 200).
4.10.2. Subconsulta en la lista de selección

Cuando la subconsulta aparece en la lista de selección de la consulta principal, en este caso la subconsulta,
no puede devolver varias filas ni varias columnas, de lo contrario se da un mensaje de error.
Muchos SQLs no permiten que una subconsulta aparezca en la lista de selección de la consulta principal pero
eso no es ningún problema ya que normalmente se puede obtener lo mismo utilizando como origen de
datos las doMs tablas. El ejemplo anterior se puede obtener de la siguiente forma:
SELECT numemp, nombre, MIN (fechapedido) FROM empleados LEFT JOIN pedidos ON
empleados.numemp = pedidos.rep GROUP BY numemp, nombre
4.10.3. EN LA CLÁUSULA FROM

En la cláusula FROM se puede encontrar una sentencia SELECT encerrada entre paréntesis pero más que
subconsulta sería una consulta ya que no se ejecuta para cada fila de la tabla origen sino que se ejecuta una

sola vez al principio, su resultado se combina con las filas de la otra tabla para formar las filas origen de la
SELECT primera y no admite referencias externas.
En la cláusula FROM vimos que se podía poner un nombre de tabla o un nombre de consulta, pues en vez de
poner un nombre de consulta se puede poner directamente la sentencia SELECT correspondiente a esa
consulta encerrada entre paréntesis.
Ejemplo:
SELECT Tabla1.EMP_NO as "Nº Empleado"

,Tabla1.EMP_NO as Nombre
,tabla1.OFICIO Cargo
FROM ( select emp_no, apellido, oficio
from empleados
WHERE oficio = (SELECT oficio
FROM empleados
WHERE apellido = 'GARRIDO')) Tabla1
4.10.4. Subconsulta en las cláusulas WHERE Y HAVING

Se suele utilizar subconsultas en las cláusulas WHERE o HAVING cuando los datos que queremos visualizar
están en una tabla pero para seleccionar las filas de esa tabla necesitamos un dato que está en otra tabla.
Ejemplo:
SELECT numemp, nombre FROM empleados WHERE contrato = (SELECT MIN (fechapedido) FROM pedidos)
En este ejemplo listamos el número y nombre de los empleados cuya fecha de contrato sea igual a la
primera fecha de todos los pedidos de la empresa.
En una cláusula WHERE / HAVING tenemos siempre una condición y la subconsulta actúa de operando
dentro de esa condición. En el ejemplo anterior se compara contrato con el resultado de la subconsulta.
Hasta ahora las condiciones estudiadas tenían como operandos valores simples (el valor contenido en una
columna de una fila de la tabla, el resultado de una operación aritmética...) ahora la subconsulta puede
devolver una columna entera por lo que es necesario definir otro tipo de condiciones especiales para
cuando se utilizan con subconsultas.

4.10.5. Condiciones de selección con subconsultas
Las condiciones de selección son las condiciones que pueden aparecer en la cláusula WHERE o HAVING. La
mayoría se han visto en el tema 2 pero ahora incluiremos las condiciones que utilizan una subconsulta como
operando.
En SQL tenemos cinco nuevas condiciones:
test de comparación con subconsulta

test de comparación cuantificada
test de pertenencia a un conjunto
test de existencia
test de comparación con subconsulta.
4.10.5.1. Test de comparación simple.

Se utiliza para comparar un valor de la fila que se está examinado con un único valor producido por la
subconsulta. La subconsulta debe devolver una única columna, sino se produce un error.
Si la subconsulta no produce ninguna fila o devuelve el valor nulo, el test devuelve el valor nulo, si la
subconsulta produce varias filas, SQL devuelve una condición de error. La sintaxis es la siguiente:
Lista las oficinas cuyo objetivo sea superior a la suma de las ventas de sus empleados. En este caso la
subconsulta devuelve una única columna y una única fila (es un consulta de resumen sin GROUP BY)
SELECT oficina, ciudad

FROM oficinas
WHERE objetivo > (SELECT SUM (ventas) FROM empleados WHERE empleados.oficina = oficinas.oficina)
Test de comparación cuantificada.
Este test es una extensión del test de comparación y del test de conjunto. Compara el valor de la expresión
con cada uno de los valores producidos por la subconsulta. La subconsulta debe devolver una única
columna sino se produce un error. Tenemos el test ANY (algún, alguno en inglés) y el test ALL (todos en
inglés).

4.10.5.2. TEST ANY.
La subconsulta debe devolver una única columna sino se produce un error. Se evalúa la comparación con
cada valor devuelto por la subconsulta.
Si alguna de las comparaciones individuales produce el resultado verdadero, el test ANY devuelve el
resultado verdadero.
Si la subconsulta no devuelve ningún valor, el test ANY devuelve falso. Si el test de comparación es falso
para todos los valores de la columna, ANY devuelve falso. Si el test de comparación no es verdadero para
ningún valor de la columna, y es nulo para al menos alguno de los valores, ANY devuelve nulo.
4.10.5.3. TEST ALL.

La subconsulta debe devolver una única columna sino se produce un error. Se evalúa la comparación con
cada valor devuelto por la subconsulta. Si todas las comparaciones individuales, producen un resultado
verdadero, el test devuelve el valor verdadero. Si la subconsulta no devuelve ningún valor el test ALL
devuelve el valor verdadero. (¡Ojo con esto!) Si el test de comparación es falso para algún valor de la
columna, el resultado es falso. Si el test de comparación no es falso para ningún valor de la columna, pero es
nulo para alguno de esos valores, el test ALL devuelve valor nulo.
4.10.5.4. TEST DE PERTENENCIA A CONJUNTO (IN).
Examina si el valor de la expresión es uno de los valores incluidos en la lista de valores producida por la
subconsulta. La subconsulta debe generar una única columna y las filas que sean. Si la subconsulta no
produce ninguna fila, el test da falso. Tiene la siguiente sintaxis:
4.10.5.5. TEST DE EXISTENCIA EXISTS.

Examina si la subconsulta produce alguna fila de resultados.
Si la subconsulta contiene filas, el test adopta el valor verdadero, si la subconsulta no contiene ninguna fila,
el test toma el valor falso, nunca puede tomar el valor nulo. Con este test la subconsulta puede tener varias
columnas, no importa ya que el test se fija no en los valores devueltos sino en si hay o no fila en la tabla
resultado de la subconsulta. Cuando se utiliza el test de existencia en la mayoría de los casos habrá que
utilizar una referencia externa. Si no se utiliza una referencia externa la subconsulta devuelta siempre será la
misma para todas las filas de la consulta principal y en este caso se seleccionan todas las filas de la consulta
principal (si la subconsulta genera filas) o ninguna (si la subconsulta no devuelve ninguna fila)

NOTA. Cuando se trabaja con tablas muy voluminosas el test EXISTS suele dar mejor rendimiento que el test
IN.

4.10.5.5.1. EJEMPLOS:
1. Queremos saber la lista de empleados cuyo salario supere el salario medio. En primer lugar,
tendríamos que averiguar el importe del salario medio:
select * from empleados

where salario > (SELECT AVG(salario)"Salario Medio"
FROM empleados);
2. Obtener información de los empleados que ganan más que cualquier empleado del
departamento 30.
SELECT emp_no "Nº Empleado", apellido, salario,

dep_no "Nº Departamento"
FROM empleados
WHERE salario > (SELECT MAX (salario)
FROM empleados
WHERE dep_no=30);
3. Listar, en orden alfabético, aquellos empleados que no trabajen ni en Madrid ni en

Barcelona. (USANDO IN)
SELECT emp_no, apellido, dep_no FROM empleados

WHERE dep_no IN (SELECT dep_no
FROM departamentos
WHERE localidad NOT LIKE 'MADRID'

AND localidad NOT LIKE 'BARCELONA');

Barcelona. (USANDO ANY)

WHERE dep_no =ANY (SELECT dep_no
FROM departamentos
WHERE localidad NOT LIKE 'MADRID'
AND localidad NOT LIKE 'BARCELONA');

Barcelona. (USANDO NOT IN)

WHERE dep_no NOT IN (SELECT dep_no
FROM departamentos
WHERE localidad LIKE 'MADRID'
OR localidad LIKE'BARCELONA');

Barcelona. (USANDO ALL)

WHERE dep_no <>ALL (SELECT dep_no
FROM departamentos
WHERE localidad LIKE 'MADRID'
OR localidad LIKE'BARCELONA');
7. Visualizar los departamentos en los que hay más de un trabajador. (USANDO EXISTS)
SELECT dep_no, dnombre

FROM departamentos d
WHERE EXISTS ( SELECT * FROM empleados e
WHERE e.dep_no = d.dep_no
);
8. Visualizar los departamentos en los que hay más de un trabajador. (USANDO NOT EXISTS)
SELECT dep_no, dnombre

FROM departamentos d
WHERE NOT EXISTS (SELECT * FROM empleados e
WHERE e.dep_no = d.dep_no
);

4.10.5.5.2. EJEMPLOS DE SUBCONSULTAS EN LA CLÁUSULA HAVING
1. Visualizar los departamentos en los que el salario medio de sus empleados sea mayor o
igual que la media de todos los salarios de la empresa.
SELECT dep_no "Nº Departamento",AVG(salario)"Salario Medio"

FROM empleados
GROUP BY dep_no
HAVING AVG(salario)>=(SELECT AVG(salario)
FROM empleados);
2. Visualizar el número y el nombre del departamento con más personal de oficio VENDEDOR.
SELECT dep_no "No. Departamento", dnombre Departamento
FROM departamentos
WHERE dep_no=(SELECT dep_no
FROM empleados
WHERE oficio = 'VENDEDOR'
GROUP BY dep_no
HAVING COUNT(*)=(SELECT TOP 1 COUNT(*)
FROM empleados
WHERE oficio = 'VENDEDOR'
GROUP BY dep_no
ORDER BY 1 DESC
)
);
Realizar los ejercicios de l manual de Trabajo

10.7. Parte 5, Capitulo 4

10.7.1 Subconsultas
4.11. Consultas multitablas.

En este tema vamos a estudiar las consultas multitabla llamadas así porque están basadas en más de una
tabla.
El SQL Server trabajar con diferentes grupos de consultas multitablas:
La unión de tablas
La composición de tablas
4.11.1. Unión de tablas

Esta operación se utiliza cuando tenemos dos tablas con las mismas columnas y queremos obtener una
nueva tabla con las filas de la primera y las filas de la segunda. En este caso la tabla resultante tiene las
mismas columnas que la primera tabla (que son las mismas que las de la segunda tabla).
Por ejemplo tenemos una tabla de libros nuevos y una tabla de libros antiguos y queremos una lista con
todos los libros que tenemos. En este caso las dos tablas tienen las mismas columnas, lo único que varía son
las filas, además queremos obtener una lista de libros (las columnas de una de las tablas) con las filas que
están tanto en libros nuevos como las que están en libros antiguos, en este caso utilizaremos este tipo de
operación.
Cuando hablamos de tablas pueden ser tablas reales almacenadas en la base de datos o tablas lógicas
(resultados de una consulta), esto nos permite utilizar la operación con más frecuencia ya que pocas veces
tenemos en una base de datos tablas idénticas en cuanto a columnas. El resultado es siempre una tabla
lógica.
Por ejemplo queremos en un sólo listado los productos cuyas existencias sean iguales a cero y también los
productos que aparecen en pedidos del año 90. En este caso tenemos unos productos en la tabla de
productos y los otros en la tabla de pedidos, las tablas no tienen las mismas columnas no se puede hacer
una union de ellas pero lo que interesa realmente es el identificador del producto (idfab,idproducto), luego
por una parte sacamos los códigos de los productos con existencias cero (con una consulta), por otra parte
los códigos de los productos que aparecen en pedidos del año 90 (con otra consulta), y luego unimos estas
dos tablas lógicas.
El operador que permite realizar esta operación es el operador UNION.

4.11.2. Composición de tablas
La composición de tablas consiste en concatenar filas de una tabla con filas de otra. En este caso obtenemos
una tabla con las columnas de la primera tabla unidas a las columnas de la segunda tabla, y las filas de la
tabla resultante son concatenaciones de filas de la primera tabla con filas de la segunda tabla.
El ejemplo anterior quedaría de la siguiente forma con la composición:
A diferencia de la unión la composición permite obtener una fila con datos de las dos tablas, esto es muy útil
cuando queremos visualizar filas cuyos datos se encuentran en dos tablas.
Por ejemplo queremos listar los pedidos con el nombre del representante que ha hecho el pedido, pues los
datos del pedido los tenemos en la tabla de pedidos pero el nombre del representante está en la tabla de
empleados y además queremos que aparezcan en la misma línea; en este caso necesitamos componer las
dos tablas (Nota: en el ejemplo expuesto a continuación, hemos seleccionado las filas que nos interesan).

Existen distintos tipos de composición, aprenderemos a utilizarlos todos y a elegir el tipo más apropiado a
cada caso.
Los tipos de composición de tablas son:
INNER JOIN: Indica que combine los campos con resultados comunes
FULL JOIN: Indica que combine todos los campos aunque los resultados sean diferentes.
LEFT JOIN: Indica que muestre todos los resultados de la columna de la izquierda
RIGHT JOIN: Indica que muestre todos los resultados de la columna de la derecha
CROSS JOIN: Muestra un producto cartesiano combinando todos los resultados de las dos
tablas.
4.11.3. El operador union

Como ya hemos visto en la página anterior, el operador UNION sirve para obtener a partir de dos tablas con
las mismas columnas, una nueva tabla con las filas de la primera y las filas de la segunda.
La sintaxis es la siguiente
Consulta puede ser un nombre de tabla, un nombre de consulta (en estos dos casos el nombre debe estar
precedido de la palabra TABLE), o una sentencia SELECT completa (en este caso no se puede poner TABLE).

La sentencia SELECT puede ser cualquier sentencia SELECT con la única restricción de que no puede
contener la cláusula ORDER BY.
Después de la primera consulta viene la palabra UNION y a continuación la segunda consulta. La segunda
consulta sigue las mismas reglas que la primera consulta.
Las dos consultas deben tener el mismo número de columnas pero las columnas pueden llamarse de
diferente forma y ser de tipos de datos distintos.
Las columnas del resultado se llaman como las de la primera consulta.
Por defecto la unión no incluye filas repetidas, si alguna fila está en las dos tablas, sólo aparece una vez en
el resultado.
Si queremos que aparezcan todas las filas incluso las repeticiones de filas, incluimos la palabra ALL (todo en
inglés).
El empleo de ALL tienen una ventaja, la consulta se ejecutará más rápidamente. Puede que la diferencia no
se note con tablas pequeñas, pero si tenemos tablas con muchos registros (filas) la diferencia puede ser
notable.
Se puede unir más de dos tablas, para ello después de la segunda consulta repetimos la palabra UNION y así
sucesivamente.
También podemos indicar que queremos el resultado ordenado por algún criterio, en este caso se incluye la
cláusula ORDER BY que ya vimos en el tema anterior. La cláusula ORDER BY se escribe después de la última
consulta, al final de la sentencia; para indicar las columnas de ordenación podemos utilizar su número de
orden o el nombre de la columna, en este último caso se deben de utilizar los nombres de columna de la
primera consulta ya que son los que se van a utilizar para nombrar las columnas del resultado.
4.11.4. El producto cartesiano

El producto cartesiano es un tipo de composición de tablas, aplicando el producto cartesiano a dos tablas se
obtiene una tabla con las columnas de la primera tabla unidas a las columnas de la segunda tabla, y las filas
de la tabla resultante son todas las posibles concatenaciones de filas de la primera tabla con filas de la
segunda tabla. La sintaxis es la siguiente:
El producto cartesiano se indica poniendo en la FROM las tablas que queremos componer separadas por
comas, podemos obtener así el producto cartesiano de dos, tres, o más tablas.
Nbtabla puede ser un nombre de tabla o un nombre de consulta. Si todas las tablas están en una base de
datos externa, añadiremos la cláusula IN basedatosexterna después de la última tabla. Pero para mejorar el
rendimiento y facilitar el uso, se recomienda utilizar una tabla vinculada en lugar de la cláusula IN.

Hay que tener en cuenta que el producto cartesiano obtiene todas las posibles combinaciones de filas por
lo tanto si tenemos dos tablas de 100 registros cada una, el resultado tendrá 100x100 filas, si el producto lo
hacemos de estas dos tablas con una tercera de 20 filas, el resultado tendrá 200.000 filas (100x100x20) y
estamos hablando de tablas pequeñas. Se ve claramente que el producto cartesiano es una operación
costosa sobre todo si operamos con más de dos tablas o con tablas voluminosas.
Se puede componer una tabla consigo misma, en este caso es obligatorio utilizar un nombre de alias por lo
menos para una de las dos. Por ejemplo: SELECT * FROM empleados, empleados emp
En este ejemplo obtenemos el producto cartesiano de la tabla de empleados con ella misma. Todas las
posibles combinaciones de empleados con empleados.
SELECT * FROM empleados, departamentos
Se observa que tenemos las dos filas de la primera consulta combinadas con las dos filas de la segunda.
Esta operación no es de las más utilizadas, normalmente cuando queremos componer dos tablas es para
añadir a las filas de una tabla, una fila de la otra tabla, por ejemplo añadir a los pedidos los datos del cliente
correspondiente, o los datos del representante, esto equivaldría a un producto cartesiano con una selección
de filas:
SELECT * FROM empleados, departamentos

WHERE empleados_dep_no=departamentos.dep_no
Combinamos todos los empleados con todos los departamentos pero luego seleccionamos los que cumplan
que el código del departamento de la tabla de departamentos sea igual al código del empleado de la tabla
de empleados, por lo tanto nos quedamos con los empleados combinados con los datos del departamento
correspondiente.
Las columnas que aparecen en la cláusula WHERE de nuestra consulta anterior se denominan columnas de
emparejamiento ya que permiten emparejar las filas de las dos tablas. Las columnas de emparejamiento no
tienen por qué estar incluidas en la lista de selección.
Normalmente emparejamos tablas que están relacionadas entre sí y una de las columnas de
emparejamiento es clave principal, pues en este caso, cuando una de las columnas de emparejamiento
tiene un índice definido es más eficiente utilizar otro tipo de composición, el INNER JOIN.

4.12. INNER JOIN
Es otro tipo de composición de tablas, permite emparejar filas de distintas tablas de forma más eficiente
que con el producto cartesiano cuando una de las columnas de emparejamiento está indexada. Ya que en
vez de hacer el producto cartesiano completo y luego seleccionar la filas que cumplen la condición de
emparejamiento, para cada fila de una de las tablas busca directamente en la otra tabla las filas que
cumplen la condición, con lo cual se emparejan sólo las filas que luego aparecen en el resultado.
Ejemplo:
SELECT * FROM empleados e INNER JOIN departamentos d ON e.dep_no = d.dep_no
tabla1 y tabla2 son especificaciones de tabla (nombre de tabla con alias o no, nombre de consulta
guardada), de las tablas cuyos registros se van a combinar.
Pueden ser las dos la misma tabla, en este caso es obligatorio definir al menos un alias de tabla.
col1, col2 son las columnas de emparejamiento.
Observar que dentro de la cláusula ON los nombres de columna deben ser nombres cualificados (lleva
delante el nombre de la tabla y un punto).
Las columnas de emparejamiento deben contener la misma clase de datos, las dos de tipo texto, de tipo
fecha etc. Los campos numéricos deben ser de tipos similares. Por ejemplo, se puede combinar campos
identityy Long puesto que son tipos similares, sin embargo, no se puede combinar campos de tipo Simple y
Doble.
Comp representa cualquier operador de comparación (=, <, >, <=, >=, o <>) y se utiliza para establecer la
condición de emparejamiento.
Se pueden definir varias condiciones de emparejamiento unidas por los operadores AND y R poniendo cada
condición entre paréntesis. Ejemplo:
SELECT * FROM pedidos INNER JOIN productos ON (pedidos.fab = productos.idfab) AND
(pedidos.producto = productos.idproducto)
Se pueden combinar más de dos tablas En este caso hay que sustituir en la sintaxis una tabla por un INNER
JOIN completo.
Por ejemplo:

SELECT * FROM (pedidos INNER JOIN clientes ON pedidos.clie = clientes.numclie) INNER JOIN empleados
ON pedidos.rep = empleados.numemp
En vez de tabla1 hemos escrito un INNER JOIN completo, también podemos escribir:
SELECT * FROM clientes INNER JOIN (pedidos INNER JOIN empleados ON pedidos.rep =
empleados.numemp) ON pedidos.clie = clientes.numclie
En este caso hemos sustituido tabla2 por un INNER JOIN completo
4.12.1. LEFT JOIN Y RIGHT JOIN

El LEFT JOIN y RIGHT JOIN son otro tipo de composición de tablas, también denominada composición
externa. Son una extensión del INNER JOIN.
Las composiciones vistas hasta ahora (el producto cartesiano y el INNER JOIN) son composiciones internas
ya que todos los valores de las filas del resultado son valores que están en las tablas que se combinan.
Con una composición interna sólo se obtienen las filas que tienen al menos una fila de la otra tabla que
cumpla la condición, veamos un ejemplo:
Queremos combinar los empleados con las oficinas para saber la ciudad de la oficina donde trabaja cada
empleado, si utilizamos un producto cartesiano tenemos:
SELECT empleados.*, ciudad FROM empleados, oficinas WHERE empleados.oficina = oficinas.oficina
Observar que hemos cualificado el nombre de columna oficina ya que ese nombre aparece en las dos tablas
de la FROM.
Con esta sentencia los empleados que no tienen una oficina asignada (un valor nulo en el campo oficina de
la tabla empleados) no aparecen en el resultado ya que la condición empleados.oficina = oficinas.oficina
será siempre nula para esos empleados.
Si utilizamos el INNER JOIN:
SELECT empleados.*, ciudad FROM empleados INNER JOIN oficinas ON empleados.oficina =

oficinas.oficina
Nos pasa lo mismo, el empleado 110 tiene un valor nulo en el campo oficina y no aparecerá en el resultado.
Pues en los casos en que queremos que también aparezcan las filas que no tienen una fila coincidente en la
otra tabla, utilizaremos el LEFT o RIGHT JOIN.

La sintaxis del LEFT JOIN es la siguiente:
La descripción de la sintaxis es la misma que la del INNER JOIN (ver página anterior), lo único que cambia es
la palabra INNER por LEFT (izquierda en inglés).
Esta operación consiste en añadir al resultado del INNER JOIN las filas de la tabla de la izquierda que no
tienen correspondencia en la otra tabla, y rellenar en esas filas los campos de la tabla de la derecha con
valores nulos.
Ejemplo:
SELECT * FROM empleados RIGHT JOIN oficinas ON empleados.oficina = oficinas.oficina
Con el ejemplo anterior obtenemos una lista de los empleados con los datos de su oficina, y además aparece
una fila por cada oficina que no está asignada a ningún empleado con los datos del empleado a nulos.
Una operación LEFT JOIN o RIGHT JOIN se puede anidar dentro de una operación INNER JOIN, pero una
operación INNER JOIN no se puede anidar dentro de LEFT JOIN o RIGHT JOIN. Los anidamientos de JOIN de
distinta naturaleza no funcionan siempre, a veces depende del orden en que colocamos las tablas, en estos
casos lo mejor es probar y si no permite el anudamiento, cambiar el orden de las tablas (y por tanto de los
JOIN) dentro de la cláusula FROM.
Por ejemplo podemos tener:
SELECT * FROM clientes INNER JOIN (empleados LEFT JOIN oficinas ON empleados.oficina =
oficinas.oficina) ON clientes.repclie = empleados.numclie
Combinamos empleados con oficinas para obtener los datos de la oficina de cada empleado, y luego
añadimos los clientes de cada representante, así obtenemos los clientes que tienen un representante
asignado y los datos de la oficina del representante asignado.
Si hubiéramos puesto INNER en vez de LEFT no saldrían los clientes que tienen el empleado 110 (porque no
tiene oficina y por tanto no aparece en el resultado del LEFT JOIN y por tanto no entrará en el cálculo del
INNER JOIN con clientes).
select apellido,oficio,dnombre
from empleados emp
inner join departamentos dept
on emp.dep_no=dept.dep_no
order by dept.dnombre

Devuelve todos los Empleados que tengan asociado un departamento.
from empleados emp
full join departamentos dep
on emp.dep_no= dep.dep_no
order by dep.dnombre
La combinación Full Join muestra las coincidencias de la tabla Departamentos con Empleados,
más los valores que no coincidan, como el Empleado SERRA que no tiene departamento y el
departamento EDICIÓN, que no tiene empleados.
Se podría decir que es como la suma de utilizar left join y right join.

4.13. Consultas externas
Al igual que las consultas de combinación internas, combina los valores comunes de los
campos indicados y además de la tabla que queramos, devuelve también el resto de valores
aunque no coincidan. Para ello usaremos las siguientes opciones combinadas con join:
Sintaxis:
Select tablaprincipal.campo, tabla acombinar.campo
From TablaPrincipal
Left join / right join / cross join tabla
On condicion
left Join: Indica que muestre todos los resultados de la columna de la izquierda
Right Join: Indica que muestre todos los resultados de la columna de la derecha
Cross Join: Muestra un producto cartesiano combinando todos los resultados de las dos
tablas.
from empleados
left outer join departamentos
on empleados.dep_no=
departamentos.dep_no
order by departamentos.dnombre

En este ejemplo el empleado Serra tiene el nombre del departamento con el valor null porque
no tiene ningún departamento asociado y nosotros en la consulta le estamos diciendo que
seleccione los empleados aunque no tengan departamento asociado, ponemos como principal
la tabla de la izquierda (EMPLEADOS).
from empleados
right outer join departamentos
on empleados.dep_no=
departamentos.dep_no
order by departamentos.dnombre

En esta consulta el departamento de Produccion tiene valores null porque le hemos dicho que
seleccione la tabla de la derecha como principal (departamentos), con lo cual selecciona todos
los campos de la tabla departamentos con coincidencias con empleados o sin ellas.
from empleados
cross join departamentos
Realiza un producto cartesiano combinando todos los empleados con todos los
departamentos.

4.13.1. Ejemplo para combinar más de dos tablas
Ya hemos visto cómo combinar 2 tablas con inner join, el siguiente ejemplo muestra cómo
combinar las 5 tablas que tenemos en la base de datos. Podremos combinar tantas tablas
como queramos usando inner join o full join.
select p.PEDIDO_NO 'Fact. No.'

,c.NOMBRE Cliente
,pr.DESCRIPCION Articulo
,p.UNIDADES Unidades
,p.FECHA_PEDIDO
,e.APELLIDO Vendedor
,d.DNOMBRE Departamento
from pedidos p
join CLIENTES c
on p.CLIENTE_NO = c.CLIENTE_NO
join PRODUCTOS pr
on p.PRODUCTO_NO= pr.PRODUCTO_NO
join EMPLEADOS e
on e.EMP_NO = c.VENDEDOR_NO
join DEPARTAMENTOS d
on e.DEP_NO = d.DEP_NO

Podremos usar tantos join como queramos en nuestras consultas, pero habrá que tener
cuidado a la hora de realizar las combinaciones para que no salgan productos cartesianos en la
consulta.
Esta consulta devuelve el nombre del vendedor, el nombre del producto, el nombre del
cliente, los pedidos realizados por un cliente.
4.14. COMBINAR LOS VALORES DE UNA TABLA SOBRE SÍ MISMA
Para ello crearemos dos copias de la misma tabla poniéndole un alías, para posteriormente
combinar los resultados de ambas copias.
Obtener la lista de los empleados con los nombres de sus directores.
SELECT e1.emp_no "NºEmpleado",

e1.apellido "Nombre Empleado",
e1.director "NºDirector",
e2.apellido "Nombre Director"
FROM empleados e1
join empleados e2

on e1.director=e2.emp_no

10.8.1. Consultas multitablas

10.9. RESUMEN DE CUÁNDO UTILIZAR CADA OPERACIÓN.
Para saber en cada caso qué tipo de operación se debe utilizar, a continuación tienes un gráfico que indica
qué preguntas se tienen que hacer y según la respuesta, qué operación utilizar.
Para resumir hemos llamado T1 y T2 las tablas de las que queremos sacar los datos y R la tabla lógica que
representa el resultado de consulta. T1 y T2 podrían ser tablas guardadas o consultas.


10.10.CONSULTAS AGREGADAS
10.10.1. CLAUSULA GROUP BY
La clausula GROUP BY combina los registros devueltos por una consulta SELECT obteniendo uno o varios
valores agregados (suma, valor mínimo y máximo...).
Para cada registro se puede crear un valor agregado si se incluye una función SQL agregada, como por
ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:
SELECT [ALL | DISTINCT ] [TOP <n> [WITH TIES]]

<nombre_campo> [{,<nombre_campo>}]
[{,<funcion_agregado>}]
FROM <nombre_tabla>|<nombre_vista>
[{,<nombre_tabla>|<nombre_vista>}]
[WHERE <condicion> [{ AND|OR <condicion>}]]
[GROUP BY <nombre_campo> [{,<nombre_campo >}]]
[HAVING <condicion>[{ AND|OR <condicion>}]]
[ORDER BY <nombre_campo>|<indice_campo> [ASC | DESC]
[{,<nombre_campo>|<indice_campo> [ASC | DESC ]}]]
Si se utiliza GROUP BY pero no existe una función SQL agregada en la instrucción SELECT se obtiene el

mismo resultado que con una consulta SELECT DISTINCT. Los valores Null en los campos GROUP BY se
agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de las funciones SQL
agregadas.
Todos los campos de la lista de campos de SELECT deben incluirse en la cláusula GROUP BY o como
argumentos de una función SQL agregada.
El siguiente ejemplo realiza una "cuenta" de los datos que hay en la tabla PRODUCTOS.
SELECT COUNT(*)
FROM PRODUCTOS
Este otro ejemplo, muestra la suma del PRECIO de cada uno de los productos que componen un pedido,
para calcular el total del pedido agrupado por los datos del cliente.
SELECT CLIENTES.NOMBRE,
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2,
SUM(PRECIO) -- Total del pedido
FROM DETALLE_PEDIDO
INNER JOIN PEDIDOS
ON DETALLE_PEDIDO.CO_PEDIDO = PEDIDOS.CO_PEDIDO
INNER JOIN CLIENTES
ON PEDIDOS.CO_CLIENTE = CLIENTES.CO_CLIENTE
GROUP BY CLIENTES.NOMBRE,

CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2
Siempre que incluyamos una clausula WHERE en una consulta agregada esta se aplica antes de calcular el
valor agregado. Es decir, si sumamos el valor de las ventas por producto, la suma se calcula despues de
haber aplicado el filtro impuesto por la clausulaWHERE.
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2,
FROM DETALLE_PEDIDO
INNER JOIN PEDIDOS
INNER JOIN CLIENTES
-- La clausula WHERE se aplica antes de realizar el calculo
WHERE CLIENTES.NOMBRE != 'UN NOMBRE'
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2
10.10.2. CLAUSULA HAVING

Es posible que necesitemos calcular un agregado, pero que no necesitemos obtener todos los datos, solo los
que cumplan una condición del agregado. Por ejemplo, podemos calcular el valor de las ventas por
producto, pero que solo queramos ver los datos del producto que hayan vendido más o menos de una
determinada cantidad. En estos casos debemos utilizar la clausula HAVING.
Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro agrupado por la
cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING. Se utiliza la cláusula WHERE para
excluir aquellas filas que no desea agrupar, y la cláusula HAVING para filtrar los registros una vez
agrupados.
HAVING es similar a WHERE, determina qué registros se seleccionan pero despues de calcular el agregado.
Una vez que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a
mostrar. HAVING permite el uso de funciones agregadas.
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2,
FROM DETALLE_PEDIDO

INNER JOIN PEDIDOS

INNER JOIN CLIENTES
-- La clausula WHERE se aplica antes de realizar el calculo
WHERE CLIENTES.NOMBRE != 'UN NOMBRE'
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2
HAVING SUM(PRECIO) > 100
10.10.2.1. FUNCIONES DE AGREGADOS.

Transact SQL pone a nuestra disposición multiples funciones agregadas, las más comunes son:
MAX
MIN
COUNT
SUM
AVG
10.10.3. AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo especificado de una consulta.
Su sintaxis es la siguiente
AVG(<expr>)

En donde expr representa el campo que contiene los datos numéricos para los que se desea calcular la
media o una expresión que realiza un cálculo utilizando los datos de dicho campo. La media calculada por
Avg es la media aritmética (la suma de los valores dividido por el número de valores). La función Avg no
incluye ningún campo Null en el cálculo.
CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2,
AVG(PRECIO) -- Promedio del pedido
FROM DETALLE_PEDIDO
INNER JOIN PEDIDOS

INNER JOIN CLIENTES

CLIENTES.APELLIDO1,
CLIENTES.APELLIDO2

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

FROM PEDIDOS
INNER JOIN CLIENTES
GROUP BY CLIENTES.NOMBRE
10.10.4.1.1. Max, Min
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo especifico de una

consulta. Su sintaxis es:
MIN(<expr>)
MAX(<expr>)
En donde expr es el campo sobre el que se desea realizar el cálculo. Expr puede incluir el nombre de un
campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero
no otras de las funciones agregadas de SQL).

MIN(PEDIDOS.FX_ALTA),
MAX(PEDIDOS.FX_ALTA)
FROM PEDIDOS
INNER JOIN CLIENTES
10.10.4.1.2. Sum
Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su
sintaxis es:
SUM(<expr>)
En donde expr respresenta el nombre del campo que contiene los datos que desean sumarse o una
expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden
incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o
definida por el usuario pero no otras de las funciones agregadas de SQL).
SUM(PEDIDOS.TOTAL_PEDIDO)
FROM PEDIDOS
INNER JOIN CLIENTES

10.10.4.1.3. USO DE SELECT TOP CON CONSULTAS AGREGADAS.
Podemos utilizar SELECT TOP con consultas agregadas como con cualquier otra instruccion Transact SQL.
En estos casos, la clausula TOP se aplica despues de calcular el agregado, devolviendo las N filas indicadas.
En este escenario es posible que queramos obtener los N valores que satisfagan una condicion. Por ejemplo,
queremos si queremos obtener los tres primeros clientes con mayores pedidos, usariamos una consulta
parecida a esta:
SELECT TOP 3
CLIENTES.NOMBRE,
SUM(DETALLE_PEDIDO.PRECIO)
FROM DETALLE_PEDIDO
INNER JOIN PEDIDOS
INNER JOIN CLIENTES
ORDER BY 2 -- SUM(DETALLE_PEDIDO.PRECIO_UNIDAD)
Sin embargo, puede darse el caso, de que el cuarto cliente devuelto por la consulta tenga un valor agragado
identico al tercero, (es decir, estan empatados). El uso de TOP 3 discriminaría el cuarto registro. Para evitar
este comportamiento, y que la consulta devuelva también al cuarto cliente utilizamos la clausula WITH TIES.
SELECT TOP 3 WITH TIES

CLIENTES.NOMBRE,
SUM(DETALLE_PEDIDO.PRECIO)
FROM DETALLE_PEDIDO
INNER JOIN PEDIDOS
INNER JOIN CLIENTES
ORDER BY 2 -- SUM(DETALLE_PEDIDO.PRECIO_UNIDAD)

10.10.5. Resumen del tema
¿CÓMO SE EJECUTA INTERNAMENTE UNA CONSULTA DE AGRUPACION?
Primero se forma la tabla origen de datos según la cláusula FROM,

Se seleccionan del origen de datos las filas según la cláusula WHERE,
Se forman los grupos de filas según la cláusula GROUP BY,
Por cada grupo se obtiene una fila en la tabla resultante con los valores que aparecen en las cláusulas
GROUP BY, HAVING y en la lista de selección,
Se seleccionan de la tabla resultante las filas según la cláusula HAVING,
Se eliminan de la tabla resultante las columnas que no aparecen en la lista de selección,
Se ordenan las filas de la tabla resultante según la cláusula ORDER BY
Una consulta se convierte en consulta de agrupación en cuanto aparece GROUP BY, HAVING o una función
de columna.

En una consulta de agrupación, la lista de selección y la cláusula HAVING sólo pueden contener:
valores constantes
funciones de columna
columnas de agrupación (columnas que aparecen en la cláusula GROUP BY)

16.12.1 Selección con agrupamientos y funciones de grupo
10.11.FUNCIONES PREDEFINIDAS
SQL Server pone a nuestra disposición multitud de funciones predefinidas que proporcionan un amplio abanico de
posibilidades. Mostramos aqui algunas de las frecuentes. Podemos acceder al listado completo a través del
siguiente enlace:http://technet.microsoft.com/es-es/library/ms187786.aspx
Son funciones incorporadas por el gestor y son muy utilizadas en SQL y dan mucha potencia al lenguaje. Estas
funciones predefinidas devuelven un valor dependiendo del valor de un argumento que se pasa en la llamada.
Cabe subrayar que las funciones no modifican los valores del argumento, indicado entre paréntesis, sino que
devuelven un valor creado a partir de los argumentos que se le pasan en la llamada, y ese valor puede ser
utilizado en cualquier parte de una sentencia SQL.
Existen muchas funciones predefinidas para operar con todo tipo de datos. A continuación se indican las funciones
predefinidas más utilizadas.
Vamos a ver estas funciones agrupadas según el tipo de datos con los que operan y/o el tipo de datos que
devuelven.
Nota: estas funciones pueden variar según el sistema gestor que se utilice.

Estas pueden ser:
Funciones Matemáticas
Funciones de cadena
Funciones de fecha
10.11.1. Funciones matematicas
10.11.1.1. ABS
Es el valor Absoluto
Select ABS(-4) as 'VALOR ABSOLUTO'-->4
10.11.1.2. POWER
Devuelve el valor de la expresión indicada elevada a la potencia especificada.

Select POWER(3,2) as '3 ELEVADO A 2'-->9
10.11.1.3. ROUND
Devuelve una expresión numérica, redondeada a la longitud o precisión especificada.
Round(Numero, Redondeo del Número)

ROUND siempre devuelve un valor. Si la longitud es un valor negativo y mayor que el número de dígitos
anteriores al separador decimal, ROUND devuelve 0.
Select ROUND(123.4567,2)-->123.4600
Select ROUND(123.4567,-2)-->100.0000
Select ROUND(123.4567,0)-->123.0000
Select ROUND(123.4567,-3)--->0
10.11.1.4. SQUARE
Devuelve el cuadrado de la expresión especificada.
Select SQUARE(4) as „Cuadrado‟-->16.0

10.11.1.5. SQRT
Devuelve la raíz cuadrada de la expresión especificada.
Select SQRT (4) as [RAIZ CUADRADA] -->2.0
10.11.2. FUNCIONES DE CADENA
10.11.2.1. ASCII
Devuelve el código ASCII del carácter más a la izquierda de una expresión de caracteres.
Select ASCII ('A')-->65
Select ASCII ('a')-->97
Select ASCII ('aula')-->97
10.11.2.2. CHAR
Una función de cadena que convierte un código ASCII int en un carácter.
Select char (65) -->A

Select char (97) -->a
10.11.2.3. CHARINDEX
Devuelve la posición inicial de la expresión especificada en una cadena de caracteres.
CHARINDEX (expression1, expression2 [, start_location])
Argumentos
expression1
Es una expresión que contiene la secuencia de caracteres que se desea buscar.

Expression1 es una expresión del tipo de cadenas cortas de caracteres.
Expression2
Es una expresión, normalmente una columna, en la que se busca la cadena especificada.
Expression2 es de la categoría del tipo de datos cadena de caracteres.

start_location
Es la posición del carácter de expression2 en el que se empieza la búsqueda de expression1.
Si no se especifica start_location, es un número negativo o es cero, la búsqueda empieza al principio de la

cadena expression2.
Si expression1 no se encuentra en expression2, CHARINDEX devuelve 0.

Si alguno de los dos es null, devuelve null
Select charindex ('cie','murcielago') -->4

Select charindex ('cie','murcielago', 2) -->4
Select charindex ('cie','murcielago', 5) -->0
Select charindex ('cie','murcielago',-6) -->4
10.11.2.4. LEFT
Devuelve la parte de una cadena de caracteres que comienza en un número de caracteres especificado a
partir de la izquierda
select left('murcielago',5)-->murci
10.11.2.5. RIGHT
Devuelve la parte de una cadena de caracteres que comienza en el número de caracteres especificado en
integer_expression a partir de la derecha.
select right('hola que tal',5)-->e tal
10.11.2.6. LEN
Obtiene la longitud de una cadena, es decir cuenta el número de caracteres que se incluyen en la cadena.
Select len ('murcielago')-->10

10.11.2.7. LOWER
Convierte a Minúsculas la cadena especificada
Select lower ('MurcIELaGO') as [minusculas] -->murcielago
10.11.2.8. UPPER
Convierte a Mayúsculas la cadena especificada
Select upper ('murcielago') as [MAYUSCULAS] -->MURCIELAGO
10.11.2.9. RTRIM y LTRIM
Elimina los espacios que existen a la izquierda y a la derecha respectivamente.
Select Rtrim (' murcielago ') AS [SIN ESPACIOS] -->murcielago

Select Ltrim (' murcielago ') AS [SIN ESPACIOS] -->murcielago
Select ltrim (rtrim (' hola ')) +'.'
10.11.2.10. REPLACE
Reemplaza por una tercera expresión todas las apariciones de la segunda expresión de cadena
proporcionada en la primera expresión de cadena
select replace('hola que tal estas','a','A')-->holA que tAl estAs

select replace('buenos dias, que tal estas','ue','ñññ')-->bñññnos dias,qñññ tal estas
10.11.2.11. SPACE
Coloca el número de espacios que se le indiquen para entre una cadena de caracteres.
select 'hola'+space(5)+'que tal'-->hola que tal
10.11.2.12. SUBSTRING

Devuelve parte de una expresión de caracteres, binaria, de texto o de imagen.
Sintaxis:
SUBSTRING (Expresión , Comienzo , Duración )
Argumentos
expression
Es una cadena de caracteres, cadena binaria, texto, imagen, columna o expresión que incluye una columna.
No deben usarse expresiones que incluyan funciones de agregado.
start
Es un entero que especifica el punto en que comienza la subcadena.
length
Es un entero que especifica la longitud de la subcadena (el número de caracteres o bytes que se devuelven).
select substring('murcielago',3,5)-->rciel
select substring('murcielago',3,len('murcielago'))-->rciel
10.11.2.13. REVERSE
Devuelve invertida una expresión de carácter.

select reverse('hola')
10.11.2.14. REPLICATE
Repite una expresión de caracteres un número especificado de veces.
select replicate('murcielago',5)
replicate, replicate, replicate, replicate, replicate

10.11.2.15. STUFF
Elimina el número de caracteres especificados e inserta otro conjunto de caracteres en un punto de inicio
indicado.
Select STUFF ('Murcielago', 2, 3, 'ijklmn')
Resultado
Mijklmnielago
10.11.2.15.1. Ejemplo aplicado a una tabla de la base de datos
select salario
,ABS(salario) absoluto
,POWER(salario,2) as Potencia
,ROUND(salario,0) redondear
,SQUARE(salario) cuadrado
,SQRT(abs(salario)) raiz
,apellido
,LEFT(apellido,3) izq
,RIGHT(apellido,3) Der
,LEFT(rtrim(ltrim(apellido)),3) quitarcaracteres
,LEN(apellido) longitud
,LOWER(apellido) minu
,UPPER(apellido) mayu
,REPLACE(apellido,'a','zzz') Reemp
,apellido+space(2)+oficio mezcla
from empleados
10.11.3. Funciones de fecha

10.11.3.1. GetDate()
Funcion que recupera la fecha actual del sistema.
Select getdate ()
Cast y Convert
Convierten una expresión de un tipo de datos en otro de forma explícita. CAST y CONVERT proporcionan
funciones similares.
CONVERT (data_type [(length)], expression [, style])
Donde:
data_type, es el tipo de destino al que queremos convertir la expresion
Expresion, la expresion que queremos convertir
Style, parametro opcional que especifica el formato que tiene expresion. Por ejemplo, si queremos convertir
un varchar a datetime, aqui debemos especificar el formato de la fecha (el tipo varchar).

DECLARE @fecha varchar(20)
-- Convertimos un valor varchar a datetime
-- El 103 indica el formato en el que esta escrita la fecha
-- 103 => dd/mm/aa
SET @fecha = CONVERT(datetime, '19/03/2008',103)


SELECT @fecha

DECLARE @fecha datetime,
@fechaFormateada varchar(20)
-- Convertimos ahora una fecha a varchar y la formateamos
-- 3 => dd/mm/aa
SET @fecha = GETDATE()
SET @fechaFormateada = CONVERT(varchar(20), @fecha, 3)

SELECT @fechaFormateada

-- Un ejemplo utilizando CAST
DECLARE @dato varchar(2),
@dato2 int
SET @dato = '27'
SET @dato2 = cast(@dato AS int)

SELECT @dato2
A continuación mostramos la tabla de códigos de estilo (obtenida de MicroSoft).

Sin el siglo (aa) Con el siglo ?
Estándar Entrada/salida (3)
(1 ) (aaaa)
- 0 o 100 (1, 2) Valor predeterminado mes dd aaaa hh:mia.m. (o p. m.)

1 101 EE.UU. mm/dd/aaaa
2 102 ANSI aa.mm.dd
3 103 Británico/Francés dd/mm/aa
4 104 Alemán dd.mm.aa
5 105 Italiano dd-mm-aa
6 106 (1) - dd mes aa
7 107 (1) - Mes dd, aa
8 108 - hh:mi:ss
Valor predeterminado + mes dd aaaa hh:mi:ss:mmma.m. (o p.
- 9 o 109 (1, 2)
milisegundos m.)
10 110 EE.UU. mm-dd-aa
11 111 JAPÓN aa/mm/dd

12 112 ISO aammdd
Europeo predeterminado +
- 13 o 113 (1, 2) dd mes aaaa hh:mi:ss:mmm(24h)
milisegundos
14 114 - hh:mi:ss:mmm(24h)
2
- 20 o 120 ( ) ODBC canónico aaaa-mm-dd hh:mi:ss(24h)
- 21 o 121 (2) ODBC canónico (con milisegundos) aaaa-mm-dd hh:mi:ss.mmm(24h)
aaaa-mm-ddThh:mi:ss.mmm (sin
- 126 (4) ISO8601
espacios)
aaaa-mm-ddThh:mi:ss.mmmZ
127(6, 7) ISO8601 con zona horaria Z.
(sin espacios)
1, 2 5
- 130 ( ) Hijri ( ) dd mes aaaa hh:mi:ss:mmma.m.
- 131 (2) Hijri (5) dd/mm/aa hh:mi:ss:mmma.m.
10.11.3.2. DateName
Devuelve una cadena de caracteres que representa la parte de la fecha especificada de la

fecha especificada
Los calculos para las horas no son exactos cuando se trata de SmallDateTime, por lo que
devuelve 0.
select datename(month,fecha_alta) as 'Nombre mes' from empleados where emp_no = 7867

diciembre
select datename(m,fecha_alta) as 'Nombre mes' from empleados where emp_no = 7867 diciembre
select datename(week,fecha_alta) as 'Numero Semana' from empleados where emp_no = 7867 51
select datename(week,fecha_alta) as 'Numero Semana' from empleados where emp_no = 7867 51
select datename( weekday,fecha_alta) as 'Dia Semana' from empleados where emp_no=7867 miercoles
select datename(dw,fecha_alta) as 'Dia Semana' from empleados where emp_no=7867 miercoles

10.11.3.3. Horas:
select datename(mi,fecha_alta) as 'Minutos' from empleados where emp_no = 7867
select datename( minute,getdate()) as 'minutos'
select datename( mi,getdate()) as 'minutos'
select datename( hh,fecha_alta) as 'hora' from empleados where emp_no = 7867
select datename( hour,getdate()) as 'hora'-->17
select datename( hh,getdate()) as 'hora'-->17
10.11.3.4. DatePart
Devuelve la parte de la fecha u hora indicada. Sintaxis:
Datepart(Valoradevolver, fecha)
select datepart(mm,fecha_alta) as 'Mes',apellido from emp-->11

select datepart(hh,getdate()) as 'Hora'-->17
select datepart(mi,getdate()) as 'Minutos'-->54
10.11.3.5. Nombres de Fechas
Day(fecha)
Devuelve un INT, equivale a datepart
select day(getdate()) as dia-->12

select datepart(dd,getdate())-->12
select month(getdate())-->7
select datepart(mm,getdate())-->7
select year(getdate())-->2002
select year(fecha_alt) from emp where emp_no = 7867
select datediff(yyyy,fecha_alt,getdate()) as „Diferencia‟ from emp where emp_no = 7867
10.11.3.6. DateAdd
DateAdd( datepart , number, date )
Añade un número a la fecha puesta

DatePart es el formato de lo que queremos añadir.
Number es el número que queremos incrementar la fecha expuesta.
select convert(datetime,'1-1-02')
select dateadd(dd,7,'1-1-02')
10.11.3.7. DateDiff
Devuelve la diferencia entre dos fechas en el intervalo que le indiquemos. Sintaxis:
DateDiff (DatoqueDevuelve, Fecha1, Fecha2)
Datoquedevuelve: Indicamos como queremos que haga la comparación y el tipo de dato que
nos devolverá, años, días, minutos etc.
Select datediff(yyyy,fecha_alt,getdate()) as 'Diferencia' from emp where emp_no = 7867

16.10.1 Elementos del lenguaje

Capitulo 5. SQL II
5. Objetivo
Estudiar las diferentes sentencias y modos en lenguaje SQL que permite realizar un tratamiento de
datos, para insertar, actualizar y eliminar la información almacenada en las diferentes tablas de la
base de datos.
4.15. Actualización de datos
Hasta ahora hemos estudiado el cómo recuperar datos almacenados en las tablas de nuestra base de datos.
En este tema vamos a tratar el de la actualización de esos datos, es decir insertar nuevas filas, borrar filas o
cambiar el contenido de las filas de una tabla. Estas operaciones modifican los datos almacenados en las
tablas pero no su estructura, ni su definición.
Empezaremos por ver cómo insertar nuevas filas (con la sentencia INSERT INTO), veremos una variante (la
sentencia SELECT... INTO), después veremos cómo borrar filas de una tabla (con la sentencia DELETE) y por
último cómo modificar el contenido de las filas de una tabla (con la sentencia UPDATE). Si trabajamos en un
entorno multiusuario, todas estas operaciones se podrán realizar siempre que tengamos los permisos
correspondientes.
5.7.1. Insertar una fila insert into...values

La inserción de nuevos datos en una tabla se realiza añadiendo filas enteras a la tabla, la sentencia SQL que
lo permite es la orden INSERT INTO.
La inserción se puede realizar de una fila o de varias filas de golpe, veremos las dos opciones por separado y
empezaremos por la inserción de una fila.
Esta sintaxis se utiliza para insertar una sola fila cuyos valores indicamos después de la palabra reservada
VALUES. En castellano la sentencia se leería: INSERTA EN destino...VALORES...
Los registros se agregan siempre al final de la tabla.
Destino es el nombre de la tabla donde vamos a insertar la fila también se puede utilizar un nombre de
consulta, consulta que tenga como origen de datos una única tabla. Al nombre de la tabla se le puede
añadir la cláusula IN si la tabla se encuentra en otra base de datos (en una base de datos externa).
La palabra reservada VALUES se puede sustituir por la palabra SELECT (en otros SQLs se emplea únicamente
VALUES).

A continuación de la palabra VALUES, entre paréntesis se escriben los valores que queremos añadir. Estos
valores se tienen que escribir de acuerdo al tipo de dato de la columna donde se van a insertar (encerrados
entre comillas simples ' ' para valores de tipo texto, entre # # para valores de fecha...) la asignación de
valores se realiza por posición, el primer valor lo asigna a la primera columna, el segundo valor a la segunda
columna, así sucesivamente.
Cuando la tabla tiene una columna de tipo contador (AutoNumber), lo normal es no asignar valor a esa
columna para que el sistema le asigne el valor que le toque según el contador, si por el contrario queremos
que la columna tenga un valor concreto, lo indicamos en la lista de valores.
Cuando no se indica ninguna lista de columnas después del destino, se asume por defecto todas las
columnas de la tabla, en este caso, los valores se tienen que especificar en el mismo orden en que aparecen
las columnas en la ventana de diseño de dicha tabla, y se tiene que utilizar el valor NULL para rellenar las
columnas de las cuales no tenemos valores.
EJEMPLO:
INSERT INTO empleados VALUES (200, 'Juan López', 30, NULL, 'rep ventas', ‘06/23/01’, NULL, 350000, 0)
Observar en el ejemplo que los valores de tipo texto se encierran entre comillas simples ' ' y que la fecha de
contrato se encierra entre comillas simples con el formato día/mes/año.
Dependiendo del Regional que tenga su computador. Como no tenemos valor para los campos oficina y
director (a este nuevo empleado todavía no se le ha asignado director ni oficina) utilizamos la palabra
reservada NULL. Los valores numéricos se escriben tal cual, para separar la parte entera de la parte decimal
hay que utilizar siempre el punto independientemente de la configuración que tengamos.
ERRORES QUE SE PUEDEN PRODUCIR CUANDO SE EJECUTA LA SENTENCIA INSERT INTO
Si la tabla de destino tiene clave principal y en ese campo intentamos no asignar valor, asignar el valor nulo
o un valor que ya existe en la tabla, el motor de base de datos no añade la fila y da un mensaje de error de
'infracciones de clave'.
Si tenemos definido un índice único (sin duplicados) e intentamos asignar un valor que ya existe en la tabla
también devuelve el mismo error.
Si la tabla está relacionada con otra, se seguirán las reglas de integridad referencial.
5.7.1.1. INSERTAR VARIAS FILAS INSERT INTO...SELECT

Podemos insertar en una tabla varias filas con una sola sentencia SELECT INTO si los valores a insertar se
pueden obtener como resultado de una consulta, en este caso sustituimos la cláusula VALUES lista de
valores por una sentencia SELECT como las que hemos visto hasta ahora. Cada fila resultado de la SELECT
forma una lista de valores que son los que se insertan en una nueva fila de la tabla destino. Es como si
tuviésemos una INSERT...VALUES por cada fila resultado de la sentencia SELECT.

El origen de la SELECT puede ser el nombre de una consulta guardada, un nombre de tabla o una
composición de varias tablas (mediante INNER JOIN, LEFT JOIN, RIGHT JOIN o producto cartesiano).
Cada fila devuelta por la SELECT actúa como la lista de valores que vimos con la INSERT...VALUES por lo
que tiene las mismas restricciones en cuanto a tipo de dato, etc. La asignación de valores se realiza por
posición por lo que la SELECT debe devolver el mismo número de columnas que las de la tabla destino y en
el mismo orden, o el mismo número de columnas que indicamos en la lista de columnas después de destino.
Las columnas de la SELECT no tienen por qué llamarse igual que en la tabla destino ya que el sistema sólo
se fija en los valores devueltos por la SELECT.
Si no queremos asignar valores a todas las columnas entonces tenemos que indicar entre paréntesis la lista
de columnas a rellenar después del nombre del destino.
El estándar ANSI/ISO especifica varias restricciones sobre la consulta que aparece dentro de la sentencia
INSERT:
la consulta no puede tener una cláusula ORDER BY,
la tabla destino de la sentencia INSERT no puede aparecer en la cláusula FROM de la consulta o de ninguna
subconsulta que ésta tenga. Esto prohíbe insertar parte de una tabla en sí misma,
la consulta no puede ser la UNION de varias sentencias SELECT diferentes, el resultado de la consulta debe
contener el mismo número de columnas que las indicadas para insertar y los tipos de datos deben ser
compatibles columna a columna.
Ejemplo: Supongamos que tenemos una tabla llamada repres con la misma estructura que la tabla
empleados, y queremos insertar en esa tabla los empleados que tengan como título rep ventas
INSERT INTO repres SELECT * FROM empleados WHERE titulo = 'rep ventas'
Con la SELECT obtenemos las filas correspondientes a los empleados con título rep ventas,y las insertamos
en la tabla repres. Como las tablas tienen la misma estructura no hace falta poner la lista de columnas y
podemos emplear * en la lista de selección de la SELECT.
Ejemplo: Supongamos ahora que la tabla repres tuviese las siguientes columnas numemp, oficinarep,
nombrerep. En este caso no podríamos utilizar el asterisco, tendríamos que poner:
INSERT INTO repres SELECT numemp, oficina, nombre FROM empleados WHERE titulo = 'rep ventas'
O bien:
INSERT INTO repres (numemp, oficinarep, nombrerep) SELECT numemp, oficina, nombre FROM
empleados WHERE titulo = 'rep ventas'
5.7.1.2. INSERTAR FILAS EN UNA NUEVA TABLA SELECT ... INTO

Esta sentencia inserta filas creando en ese momento la tabla donde se insertan las filas. Se suele utilizar
para guardar en una tabla el resultado de una SELECT.

Las columnas de la nueva tabla tendrán el mismo tipo y tamaño que las columnas origen, y se llamarán
con el nombre de alias de la columna origen o en su defecto con el nombre de la columna origen, pero no
se transfiere ninguna otra propiedad del campo o de la tabla como por ejemplo las claves e índices.
La sentencia SELECT puede ser cualquier sentencia SELECT sin ninguna restricción, puede ser una consulta
multitabla, una consulta de resumen, una UNION...
Ejemplo:
SELECT * INTO t2 FROM t1
Esta sentencia genera una nueva tabla t2 con todas las filas de la tabla t1. Las columnas se llamarán igual
que en t1 pero t2 no será una copia exacta de t1 ya no tendrá clave principal ni relaciones con las otras
tablas, ni índices si los tuviese t1 etc...
Si en la base de datos hay ya una tabla del mismo nombre, el sistema nos avisa y nos pregunta si la
queremos borrar. Si le contestamos que no, la SELECT no se ejecuta.
Para formar una sentencia SELECT INTO lo mejor es escribir la SELECT que permite generar los datos que
queremos guardar en la nueva tabla, y después añadir delante de la cláusula FROM la cláusula INTO
nuevatabla.
La sentencia SELECT INTO se suele utilizar para crear tablas de trabajo, o tablas intermedias, las creamos
para una determinada tarea y cuando hemos terminado esa tarea las borramos. También puede ser útil para
sacar datos en una tabla para enviarlos a alguien.
Por ejemplo: Queremos enviarle a un representante una tabla con todos los datos personales de sus clientes
para que les pueda enviar cartas etc...
EJEMPLO:
SELECT numclie AS codigo, nombre, direccion, telefono INTO susclientes FROM
clientes WHERE repclie = '103';
5.7.2. Modificar el contenido de las filas (UPDATE)

La sentencia UPDATE modifica los valores de una o más columnas en las filas seleccionadas de una o varias
tablas.
Origen puede ser un nombre de tabla, un nombre de consulta o una composición de tablas , también
puede incluir la cláusula IN si la tabla a modificar se encuentra en una base de datos externa
La cláusula SET especifica qué columnas van a modificarse y qué valores asignar a esas columnas.

Nbcolumna, es el nombre de la columna a la cual queremos asignar un nuevo valor por lo tanto debe ser
una columna de la tabla origen. El SQL estándar exige nombres sin cualificar pero algunas implementaciones
(como por ejemplo el SQL de Microsoft Jet que estamos estudiando) sí lo permiten.
La expresión en cada asignación debe generar un valor del tipo de dato apropiado para la columna
indicada. La expresión debe ser calculable a partir de los valores de la fila que se está actualizando .
Expresión no puede ser una subconsulta.
EJEMPLO:
UPDATE oficinas INNER JOIN empleados
ON oficinas.oficina = empleados.oficina
SET cuota=objetivo*0.01;
En este ejemplo queremos actualizar las cuotas de nuestros empleados de tal forma que la cuota de un
empleado sea el 1% del objetivo de su oficina. La columna a actualizar es la cuota del empleado y el valor a
asignar es el 1% del objetivo de la oficina del empleado, luego la cláusula SET será SET cuota = objetivo*0.01
o SET cuota = objetivo/100. El origen debe contener la cuota del empleado y el objetivo de su oficina, luego
el origen será el INNER JOIN de empleados con oficinas.
La cláusula WHERE indica qué filas van a ser modificadas. Si se omite la cláusula WHERE se actualizan todas
las filas.
En la condición del WHERE se puede incluir una subconsulta. En SQL standard la tabla que aparece en la
FROM de la subconsulta no puede ser la misma que la tabla que aparece como origen.
Ejemplo: Queremos poner a cero las ventas de los empleados de la oficina 12
UPDATE empleados SET ventas = 0 WHERE oficina = 12;
Ejemplo: Queremos poner a cero el límite de crédito de los clientes asignados a empleados de la oficina 12.
UPDATE clientes SET limitecredito = 0

WHERE repclie IN (SELECT numemp FROM empleados WHERE oficina = 12);
Si para el cálculo de expresion se utiliza una columna que también se modifica, el valor que se utiliza es el
antes de la modificación, lo mismo para la condición de búsqueda.
Cuando se ejecuta una sentencia UPDATE primero se genera el origen y se seleccionan las filas según la
cláusula WHERE. A continuación se coge una fila de la selección y se le aplica la cláusula SET, se actualizan
todas las columnas incluidas en la cláusula SET a la vez por lo que los nombres de columna pueden
especificarse en cualquier orden. Después se coge la siguiente fila de la selección y se le aplica del mismo
modo la cláusula SET, así sucesivamente con todas las filas de la selección.
EJEMPLO:

UPDATE oficinas SET ventas=0, objetivo=ventas;
O bien:
UPDATE oficinas SET objetivo=ventas, ventas=0;
Los dos ejemplos anteriores son equivalentes ya que el valor de ventas que se asigna a objetivo es el valor
antes de la actualización, se deja como objetivo las ventas que ha tenido la oficina hasta el momento y se
pone a cero la columna ventas.
Si actualizamos una columna definida como clave foránea, esta columna se podrá actualizar o no siguiendo
las reglas de integridad referencial. El valor que se le asigna debe existir en la tabla de referencia.
Si actualizamos una columna definida como columna principal de una relación entre dos tablas , esta
columna se podrá actualizar o no siguiendo las reglas de integridad referencial.
5.7.3. Borrar filas (DELETE)

La sentencia DELETE elimina filas de una tabla.
Origen es el nombre de la tabla de donde vamos a borrar, podemos indicar un nombre de tabla, incluir la
cláusula IN si la tabla se encuentra en una base de datos externa, también podemos escribir una
composición de tablas.
La opción tabla.* se utiliza cuando el origen está basado en varias tablas, y sirve para indicar en qué tabla
vamos a borrar.
La opción * es opcional y es la que se asume por defecto y se puede poner únicamente cuando el origen es
una sola tabla.
La cláusula WHERE sirve para especificar qué filas queremos borrar. Se eliminaran de la tabla todas las filas
que cumplan la condición. Si no se indica la cláusula WHERE, se borran TODAS las filas de la tabla.
En la condición de búsqueda de la sentencia DELETE, se puede utilizar una subconsulta. En SQL standard la
tabla que aparece en la FROM de la subconsulta no puede ser la misma que la tabla que aparece en la FROM
de la DELETE pero en el SQL de Microsoft Jet sí se puede hacer.
Una vez borrados, los registros no se pueden recuperar. (al menos que no hayamos puesto un Begin
Transaction, para poder darle el ROLLBACK)
Si la tabla donde borramos está relacionada con otras tablas se podrán borrar o no los registros siguiendo
las reglas de integridad referencial definidas en las relaciones.
Ejemplo:
DELETE * FROM pedidos WHERE clie IN (SELECT numclie FROM clientes WHERE nombre = 'Julian López');
O bien:

DELETE pedidos.* FROM pedidos INNER JOIN clientes ON pedidos.clie = clientes.numclie WHERE nombre =
'Julian López';
Las dos sentencias borran los pedidos del cliente Julian López. En la segunda estamos obligados a poner
pedidos.* porque el origen está basado en varias tablas
DELETE * FROM pedidos; o DELETE FROM pedidos; Borra todas las filas de pedidos
Clausula OUTPUT
A partir de la version de SQL Server 2005 disponemos de la clausula OUTPUT para recuperar los valores que
hemos insertado. Al igual que en un trigger disponemos de las tablas lógicas INSERTED y DELETED.
Las columnas con prefijo DELETED reflejan el valor antes de que se complete la
instrucción UPDATE o DELETE. Es decir, son una copia de los datos "antes" del cambio.
DELETED no se puede utilizar con la cláusula OUTPUT en la instrucción INSERT.
DECLARE @FILAS_BORRADAS TABLE

(
Id int,
dato varchar(100),
fx_alta datetime
)

DELETE
FROM DATOS
OUTPUT DELETED.* INTO @FILAS_BORRADAS
WHERE Id=17

SELECT * from @FILAS_BORRADAS
5.7.3.1. TRUNCATE TABLE

Para borrar datos de forma masiva disponemos de la instrucción TRUNCATE TABLE, que borra todos los
datos de una tabla.
TRUNCATE TABLE DATOS
Cuando trabajamos con TRUNCATE TABLE debemos tener en cuenta las siguientes consideraciones:
TRUNCATE TABLE no admite la clausula WHERE.
No podemos ejecutar TRUNCATE TABLE sobre tablas que sean "padres" en foreign keys.
5.7.4. Resumen del tema
Si queremos añadir en una tabla una fila con valores conocidos utilizamos la sentencia INSERT INTO tabla
VALUES (lista de valores).

Si los valores a insertar se encuentran en una o varias tablas utilizamos INSERT INTO tabla SELECT ...
Para crear una nueva tabla con el resultado de una consulta con la sentencia SELECT...INTO tabla FROM...
Para cambiar los datos contenidos en una tabla, tenemos que actualizar las filas de dicha tabla con la
sentencia UPDATE tabla SET asignación de nuevos valores.
Para eliminar filas de una tabla se utiliza la sentencia DELETE FROM tabla.
Con la cláusula WHERE podemos indicar a qué filas afecta la actualización o el borrado

10.15 Parte I, Capitulo 5
10.15.1 Actualización de tablas

Capitulo 6. TABLAS
6. Objetivo
Aprender a realizar cualquier tarea de diseño y planificación sobre la estructura de tablas. Conocer
los diferentes tipos de datos que puede almacenar una tabla y aprender a seleccionar el más
adecuado. Garantizar la integridad y la funcionalidad de una base de datos mediante el uso de
restricciones y relaciones. Trabajar con los diagramas de base de datos para realizar funciones de
diseño.
6.7. DDL, Lenguaje de Definición de Datos

Hasta ahora hemos estudiado las sentencias que forman parte del DML (Data Management Language)
lenguaje de manipulación de datos, todas esas sentencias sirven para recuperar, insertar, borrar, modificar
los datos almacenados en la base de datos; lo que veremos en este tema son las sentencias que afectan a la
estructura de los datos.
El DDL (Data Definition Language) lenguaje de definición de datos es la parte del SQL que más varía de un
sistema a otro ya que esa area tiene que ver con cómo se organizan internamente los datos y eso, cada
sistema lo hace de una manera u otra.
6.7.1. Create Table
La sentencia CREATE TABLE sirve para crear la estructura de una tabla no para rellenarla con datos, nos
permite definir las columnas que tiene y ciertas restricciones que deben cumplir esas columnas.
nbtabla: nombre de la tabla que estamos definiendo

nbcol: nombre de la columna que estamos definiendo
tipo: tipo de dato de la columna, todos los datos almacenados en la columna deberán ser de ese tipo.
6.7.2. Tipos de datos en transact SQL

Cuando definimos una tabla, variable o constante debemos asignar un tipo de dato que indica los
posibles valores. El tipo de datos define el formato de almacenamiento, espacio que de disco-
memoria que va a ocupar un campo o variable, restricciones y rango de valores validos.
Transact SQL proporciona una variedad predefinida de tipos de datos. Casi todos los tipos de
datos manejados por Transact SQLson similares a los soportados por SQL.

6.7.2.1. TIPOS DE DATOS NUMÉRICOS.
SQL Server dispone de varios tipos de datos númericos. Cuanto mayor sea el número que puedan
almacenar mayor será en consecuencia el espacio utilizado para almacenarlo. Como regla general
se recomienda usar el tipo de dato mínimo posible. Todos los datos numéricos admiten el valor
NULL.
Bit. Una columna o variable de tipo bit puede almacenar el rango de valores de 1 a 0.
Tinyint. Una columna o variable de tipo tinyint puede almacenar el rango de valores de 0 a 255.
SmallInt. Una columna o variable de tipo smallint puede almacenar el rango de valores -32768 a 32767.
Int. Una columna o variable de tipo int puede almacenar el rango de valores -231 a 231-1.
BigInt. Una columna o variable de tipo bigint puede almacenar el rango de valores -263 a 263-1.
Decimal (p, s). Una columna de tipo decimal puede almacenar datos númericos decimales sin redondear.
Donde p es la precision (número total del dígitos) y s la escala (número de valores decimales)
Float. Una columna de datos float puede almacenar el rango de valores -1,79x-10 308 a 1,79x-10308, si la
definimos con el valor máxmo de precisión. La precisión puede variar entre 1 y 53.
Real. Sinónimo de float (24). Puede almacenar el rango de valores -3,4x-10 38 a 3,4x-1038,
Money. Almacena valores númericos monetarios de -2 63 a 263-1, con una precisión de hasta diexz milesimas
de la unidad monetaria.
SmallMoney. Almacena valores númericos monetarios de -214.748,3647 a 214.748,3647, con una precisión
de hasta diez milesimas de la unidad monetaria.
Todos los tipos de datos enteros pueden marcarse con la propiedad identity para hacerlos
autonuméricos.
DECLARE @bit bit,

@tinyint tinyint,
@smallint smallint,
@int int,
@bigint bigint,
@decimal decimal(10,3), -- 10 digitos, 7 enteros y
-- 3 decimales
@real real,
@double float(53),
@money money
set @bit = 1
print @bit
set @tinyint = 255
print @tinyint
set @smallint = 32767
print @smallint
set @int = 642325
print @int
set @decimal = 56565.234 -- Punto como separador decimal
print @decimal
set @money = 12.34

print @money
6.7.2.2. TIPOS DE DATOS DE CARACTER.

Char(n). Almacena n caracteres en formato ASCII, un byte por cada letra. Cuando almacenamos datos en el
tipo char, siempre se utilizan los n caracteres indicados, incluso si la entrada de datos es inferior. Por ejemplo,
si en un char(5), guardamos el valor 'A', se almacena 'A ', ocupando los cinco bytes.
Varchar(n).Almacena n caracteres en formato ASCII, un byte por cada letra. Cuando almacenamos datos en
el tipo varchar, unicamente se utilizan los caracteres necesarios, Por ejemplo, si en un varchar(255),
guardamos el valor 'A', se almacena 'A', ocupando solo un byte bytes.
Varchar(max). Igual que varchar, pero al declararse como max puede almacenar 231-1 bytes.
Nchar(n).Almacena n caracteres en formato UNICODE, dos bytes por cada letra. Es recomendable utilizar
este tipo de datos cuando los valores que vayamos a almacenar puedan pertenecer a diferente idomas.
Nvarchar(n).Almacena n caracteres en formato UNICODE, dos bytes por cada letra. Es recomendable utilizar
este tipo de datos cuando los valores que vayamos a almacenar puedan pertenecer a diferente idomas.
Nvarchar(max).Igual que varchar, pero al declararse como max puede almacenar 2 31-1 bytes.
6.7.2.3. Tipos de datos de fecha.

Datetime. Almacena fechas con una precision de milisegundo. Debe usarse para fechas muy específicas.
SmallDatetime. Almacena fechas con una precision de minuto, por lo que ocupa la mitad de espacio de que
el tipo datetime, para tablas que puedan llegar a tener muchos datos es un factor a tener muy en cuenta.
TimeStamp.Se utiliza para marcar un registro con la fecha de inserción - actualización. El tipo timestamp se
actualiza automáticamente cada vez que insertamos o modificamos los datos.
Tipos de datos binarios.
Binary. Se utiliza para almacenar datos binarios de longitud fija, con una longitud máxima de 8000 bytes.
Varbinary. Se utiliza para almacenar datos binarios de longitud variable, con una longitud máxima de 8000
bytes...Es muy similar a binary, salvo que varbinary utiliza menos espacio en disco.
Varbinary (max).Igual que varbinary, pero puede almacenar 231-1 bytes
Tipo de datos XML.
XML.Una de las grandes mejoras que incorpora SQL Server 2005 es el soporte nativo para XML. Como
podemos deducir, este tipo de datos se utiliza para almacenar XML.
DECLARE @myxml XML

set @myxml = (SELECT @@SERVERNAME NOMBRE FOR XML RAW, TYPE)

print cast(@myxml as varchar(max))
Obtendremos la siguiente salida: <row nombre="SVR01"/>
OTROS TIPOS DE DATOS.

UniqueIdentifier. Se utiliza para identificadores únicos. Para generar identificadores únicos debemos utilizar
la función NEWID ().

DECLARE @myuniqueid UNIQUEIDENTIFIER

set @myuniqueid = NEWID()

print cast(@myuniqueid as varchar(36))
Obtendremos la siguiente salida: 46141D79-102C-4C29-A620-792EA0208637

Sql_Variant.Permite almacenar valores de diferentes tipos de datos. No puede almacena varchar (max), xml,
timestamp y tipos de datos definidos por el usuario.
TIPOS DE DATOS PERSONALIZADOS.
Transact SQL permite la creación de tipos de datos personalizados, a trevés de la
instrucción CREATE TYPE. Personalmente, desaconsejo el uso de tipos de datos personalizados.
CREATE TYPE MD5 FROM CHAR(32) NULL

GO
DECLARE @miMD5 MD5
set @miMD5 = '0000000000000000000000000000000A'
print @miMD5
6.7.3. Equivalencia de datos de SQL SERVER Y .NET

La siguiente lista muestra los tipos de datos de SQL Server 2005 y sus equivalentes con CRL, para el
namespaceSystem.Data.SqlTypes y los tipos nativos de CRL .NET FrameWork
CLR data type (.NET
SQL Server CLR data type (SQL Server)
Framework)
varbinary SqlBytes, SqlBinary Byte[]
binary SqlBytes, SqlBinary Byte[]
varbinary(1),
SqlBytes, SqlBinary byte, Byte[]
binary(1)
image ninguno ninguno
varchar ninguno ninguno
char ninguno ninguno
nvarchar(1),
SqlChars, SqlString Char, String, Char[]
nchar(1)
SqlChars, SqlString
nvarchar SQLChars es mejor para la transferencia de datos String, Char[]

ySQLString obtiene mejor rendimiento para operaciones con
Strings.
nchar SqlChars, SqlString String, Char[]

text ninguno ninguno
ntext ninguno ninguno
uniqueidentifier SqlGuid Guid
rowversion ninguno Byte[]
bit SqlBoolean Boolean
tinyint SqlByte Byte
smallint SqlInt16 Int16
int SqlInt32 Int32
bigint SqlInt64 Int64
smallmoney SqlMoney Decimal
money SqlMoney Decimal
numeric SqlDecimal Decimal
decimal SqlDecimal Decimal
real SqlSingle Single
float SqlDouble Double
smalldatetime SqlDateTime DateTime
datetime SqlDateTime DateTime
sql_variant ninguno Object
User-defined Misma clase que la
ninguno
type(UDT) definida en el assemblie.
table ninguno ninguno
cursor ninguno ninguno
timestamp ninguno ninguno
xml SqlXml ninguno
6.7.4. Operadores en transact SQL

La siguiente tabla ilustra los operadores de Transact SQL.
Tipo de operador Operadores
Operador de asignación =
Operadores aritméticos + (suma)

- (resta)
* (multiplicación)
/ (división)
** (exponente)
% (modulo)

Operadores relacionales o de = (igual a)

comparación <> (distinto de)
!= (distinto de)
< (menor que)
> (mayor que)
>= (mayor o igual a)
<= (menor o igual a)
!> (no mayor a)
!< (no menor a)
Operadores lógicos AND (y lógico)

NOT (negacion)
OR (o lógico)
& (AND a nivel de bit)
| (OR a nivel de bit)
^ (OR exclusivo a nivel de bit)
Operador de concatenación +
ALL (Devuelve TRUE si el conjunto completo de comparaciones es TRUE)

ANY(Devuelve TRUE si cualquier elemento del conjunto de comparaciones
es TRUE)
BETWEEN (Devuelve TRUE si el operando está dentro del intervalo)
EXISTS (TRUE si una subconsulta contiene filas)
Otros
IN (TRUE si el operando está en la lista)
LIKE (TRUE si el operando coincide con un patron)
NOT (Invierte el valor de cualquier operador booleano)
SOME(Devuelve TRUE si alguna de las comparaciones de un conjunto es
TRUE)
6.7.5. Constraints o Restriccion

Una restricción consiste en la definición de una característica adicional que tiene una columna o una
combinación de columnas, suelen ser características como valores no nulos (campo requerido), definición de
índice sin duplicados, definición de clave principal y definición de clave foránea (clave ajena o externa,
campo que sirve para relacionar dos tablas entre sí).
4.15.1.1. Restricción1:
Una restricción de tipo 1 es una restricción que aparece dentro de la definición de la columna después del
tipo de dato y afecta a una columna, la que se está definiendo.
4.15.1.2. Restricción2:
Una restricción de tipo 2 es una restricción que se define después de definir todas las columnas de la tabla
y afecta a una columna o a una combinación de columnas.
Para escribir una sentencia CREATE TABLE se empieza por indicar el nombre de la tabla que queremos crear
y a continuación entre paréntesis indicamos separadas por comas las definiciones de cada columna de la
tabla, la definición de una columna consta de su nombre, el tipo de dato que tiene y podemos añadir si
queremos una serie de especificaciones que deberán cumplir los datos almacenados en la columna,

después de definir cada una de las columnas que compone la tabla se pueden añadir una serie de
restricciones, esas restricciones son las mismas que se pueden indicar para cada columna pero ahora
pueden afectar a más de una columna por eso tienen una sintaxis ligeramente diferente.
6.7.5.1. RESTRICCION TIPO 1

Una restricción de tipo 1 se utiliza para indicar una característica de la columna que estamos definiendo,
tiene la siguiente sintaxis:
La cláusula NOT NULL indica que la columna no podrá contener un valor nulo, es decir que se deberá
rellenar obligatoriamente y con un valor válido (equivale a la propiedad requerido Sí de las propiedades del
campo).
La cláusula CONSTRAINT sirve para definir una restricción que se podrá eliminar cuando queramos sin tener
que borrar la columna. A cada restricción se le asigna un nombre que se utiliza para identificarla y para
poder eliminarla cuando se quiera.
Como restricciones tenemos la de clave primaria (clave principal), la de índice único (sin duplicados), la de
valor no nulo, y la de clave foránea.
La cláusula PRIMARY KEY se utiliza para definir la columna como clave principal de la tabla. Esto supone que
la columna no puede contener valores nulos ni puede haber valores duplicados en esa columna, es decir
que dos filas no pueden tener el mismo valor en esa columna.
En una tabla no puede haber varias claves principales, por lo que no podemos incluir la cláusula PRIMARY
KEY más de una vez, en caso contrario la sentencia da un error. No hay que confundir la definición de varias
claves principales con la definición de una clave principal compuesta por varias columnas, esto último sí está
permitido y se define con una restricción de tipo 2.
La cláusula UNIQUE sirve para definir un índice único sobre la columna. Un índice único es un índice que no
permite valores duplicados, es decir que si una columna tiene definida un restricción de UNIQUE no podrán
haber dos filas con el mismo valor en esa columna. Se suele emplear para que el sistema compruebe el
mismo que no se añaden valores que ya existen, por ejemplo si en una tabla de clientes queremos
asegurarnos que dos clientes no puedan tener el mismo D.N.I. y la tabla tiene como clave principal un código
de cliente, definiremos la columna dni con la restricción de UNIQUE.
La cláusula NOT NULL indica que la columna no puede contener valores nulos, cuando queremos indicar que
una columna no puede contener el valor nulo lo podemos hacer sin poner la cláusula CONSTRAINT, o
utilizando una cláusula CONSTRAINT.

La última restricción que podemos definir sobre una columna es la de clave foránea, una clave foránea es
una columna o conjunto de columnas que contiene un valor que hace referencia a una fila de otra tabla, en
una restricción de tipo 1 se puede definir con la cláusula REFERENCES, después de la palabra reservada
indicamos a qué tabla hace referencia, opcionalmente podemos indicar entre paréntesis el nombre de la
columna donde tiene que buscar el valor de referencia, por defecto coge la clave principal de la tabla2, si el
valor que tiene que buscar se encuentra en otra columna de tabla2, entonces debemos indicar el nombre de
esta columna entre paréntesis, además sólo podemos utilizar una columna que esté definida con una
restricción de UNIQUE, si la columna2 que indicamos no está definida sin duplicados, la sentencia CREATE
nos dará un error.
Ejemplo:
CREATE TABLE tab1 (col1 INTEGER CONSTRAINT pk PRIMARY KEY, col2 CHAR(25) NOT NULL, col3 CHAR(10)
CONSTRAINT uni1 UNIQUE, col4 INTEGER, col5 INT CONSTRAINT fk5 REFERENCES tab2 );
Con este ejemplo estamos creando la tabla tab1 compuesta por: una columna llamada col1 de tipo entero
definida como clave principal, una columna col2 que puede almacenar hasta 25 caracteres alfanuméricos y
no puede contener valores nulos, una columna col3 de hasta 10 caracteres que no podrá contener valores
repetidos, una columna col4 de tipo entero sin ninguna restricción, y una columna col5 de tipo entero clave
foránea que hace referencia a valores de la clave principal de la tabla tab2.
6.7.5.1.1. Ejemplos de definición de restricciones de tipo 1

Veremos un ejemplo de cada caso donde se van definiendo las columnas con las correspondientes restricciones.
a) PRIMARY KEY. El número de socio en la tabla socios
CREATE TABLE socios_1a (socio_no INT PRIMARY KEY, apellidos VARCHAR(14), telefono CHAR(9), fecha_alta
DATETIME, direccion VARCHAR(20), codigo_postal INT);
b) NOT NULL. La columna teléfono es obligatoria en la tabla socios, nunca irá sin información.
CREATE TABLE socios_1b (socio_no INT PRIMARY KEY, apellidos VARCHAR(14), telefono CHAR(9) NOT NULL,
fecha_alta DATETIME, direccion VARCHAR(20), codigo_postal INT);
c) DEAFAULT. En ausencia de valor el campo fecha _ alta tomará el valor de 1 de Noviembre de 20008
CREATE TABLE socios_1c (socio_no INT PRIMARY KEY, apellidos VARCHAR(14), telefono CHAR(9) NOT NULL,
fecha_alta DATETIME DEFAULT '2008-11-01', direccion VARCHAR(20), codigo_postal INT);
d) UNIQUE. La columna apellido será única en la tabla socios.
CREATE TABLE socios_1d (socio_no INT PRIMARY KEY, apellidos VARCHAR(14) UNIQUE, telefono CHAR(9) NOT
NULL, fecha_alta DATETIME DEFAULT '2008-11-01', direccion VARCHAR(20), codigo_postal INT );
e) CHECK. Se comprobará que la columna cdigo_postal corresponde a Madrid (valores entre 28000 y 28999)
CREATE TABLE socios_1e (socio_no INT PRIMARY KEY, apellidos VARCHAR (14) UNIQUE, telefono CHAR (9) NOT
NULL, fecha_alta DATETIME DEFAULT '2008-11-01', direccion VARCHAR (20), codigo_postal INT
CHECK (codigo_postal BETWEEN 28000 AND 28999));

6.7.5.2. Restriccion tipo 2
Una restricción de tipo 2 se utiliza para definir una característica que afecta a una columna o a una
combinación de columnas de la tabla que estamos definiendo, se escribe después de haber definido todas
las columnas de la tabla.
Sintaxis:
La sintaxis de una restricción de tipo 2 es muy similar a la CONSTRAINT de una restricción 1 la diferencia es
que ahora tenemos que indicar sobre qué columnas queremos definir la restricción. Se utilizan
obligatoriamente las restricciones de tipo 2 cuando la restricción afecta a un grupo de columnas o cuando
queremos definir más de una CONSTRAINT para una columna (sólo se puede definir una restricción1 en
cada columna).
La cláusula PRIMARY KEY se utiliza para definir la clave principal de la tabla. Después de las palabras
PRIMARY KEY se indica entre paréntesis el nombre de la columna o las columnas que forman la clave
principal. Las columnas que forman la clave principal no pueden contener valores nulos ni pueden haber
valores duplicados de la combinación de columnas, por ejemplo la tabla pedidos de nuestros ejemplos tiene
una clave principal formada por idfab e idproducto, pues no pueden haber dos filas con la misma
combinación de idfab con idproducto (aci,0001 por ejemplo) pero sí pueden haber dos filas con el valor aci
en la columna idfab si tienen valores diferentes en la columna idproducto, y pueden haber dos filas con el
mismo idproducto pero distinto idfab.
En una tabla no puede haber varias claves principales, por lo que no podemos indicar la cláusula PRIMARY
KEY más de una vez, en caso contrario la sentencia da un error.
La cláusula UNIQUE sirve para definir un índice único sobre una columna o sobre una combinación de
columnas. Un índice único es un índice que no permite valores duplicados. Si el índice es sobre varias
columnas no se puede repetir la misma combinación de valores en dos o más filas. Se suele emplear para
que el Sistema.
La sintaxis de una restricción de tipo 2 es muy similar a la CONSTRAINT de una restricción 1 la diferencia es
que ahora tenemos que indicar sobre qué columnas queremos definir la restricción. Se utilizan
obligatoriamente las restricciones de tipo 2 cuando la restricción afecta a un grupo de columnas o cuando
queremos definir más de una CONSTRAINT para una columna (sólo se puede definir una restricción1 en
cada columna).

La cláusula PRIMARY KEY se utiliza para definir la clave principal de la tabla. Después de las palabras
PRIMARY KEY se indica entre paréntesis el nombre de la columna o las columnas que forman la clave
principal. Las columnas que forman la clave principal no pueden contener valores nulos ni pueden haber
valores duplicados de la combinación de columnas, por ejemplo la tabla pedidos de nuestros ejemplos tiene
una clave principal formada por idfab e idproducto, pues no pueden haber dos filas con la misma
combinación de idfab con idproducto (aci,0001 por ejemplo) pero sí pueden haber dos filas con el valor así
en la columna idfab si tienen valores diferentes en la columna idproducto, y pueden haber dos filas con el
mismo idproducto pero distinto idfab.
En una tabla no puede haber varias claves principales, por lo que no podemos indicar la cláusula PRIMARY
KEY más de una vez, en caso contrario la sentencia da un error.
La cláusula UNIQUE sirve para definir un índice único sobre una columna o sobre una combinación de
columnas. Un índice único es un índice que no permite valores duplicados. Si el índice es sobre varias
columnas no se puede repetir la misma combinación de valores en dos o más filas. Se suele emplear para
que el sistema compruebe el mismo que no se añaden valores que ya existen.
La cláusula FOREIGN KEY sirve para definir una clave foránea sobre una columna o una combinación de
columnas. Una clave foránea es una columna o conjunto de columnas que contiene un valor que hace
referencia a una fila de otra tabla, en una restricción 1 se puede definir con la cláusula REFERENCES. Para
definir una clave foránea en una restricción de tipo 2 debemos empezar por las palabras FOREIGN KEY
después indicamos entre paréntesis la/s columna/s que es clave foránea, a continuación la palabra
reservada REFERENCES seguida del nombre de la tabla a la que hace referencia, opcionalmente podemos
indicar entre paréntesis el nombre de la/s columna/s donde tiene que buscar el valor de referencia, por
defecto coge la clave principal de la tabla2, si el valor que tiene que buscar se encuentra en otra/s
columna/s de tabla2, entonces debemos escribir el nombre de esta/s columna/s entre paréntesis, además
sólo podemos utilizar una columna (o combinación de columnas) que esté definida con una restricción de
UNIQUE, de lo contrario la sentencia CREATE TABLE nos dará un error.
Ejemplo:
CREATE TABLE tab1 (col1 INTEGER, col2 CHAR(25) NOT NULL, col3 CHAR(10), col4 INTEGER, col5 INT,
CONSTRAINT pk PRIMARY KEY (col1), CONSTRAINT uni1 UNIQUE (col3), CONSTRAINT fk5 FOREIGN KEY
(col5) REFERENCES tab2 );
Con este ejemplo estamos creando la misma tabla tab1 del ejemplo de la página anterior pero ahora hemos
definido las restricciones utilizando restricciones de tipo 2.
6.7.5.2.1. Ejemplos de definición de restricciones de tipo 2

a) PRIMARY KEY. El número de socio será la clave primaria en la tabla socios. Será obligatoriamente no nulo y
único.
CREATE TABLE socios_2a

(socio_no INT,
Apellidos VARCHAR (14),
telefono CHAR(9),
fecha_alta DATETIME,
direccion VARCHAR(20),
codigo_postal INT,
CONSTRAINT PK_ socios_2a PRIMARY KEY (socio_no));

b) UNIQUE. El campo apellido es único. Tendrá valores diferentes en cada fila o el valor nulo
CREATE TABLE socios_2b (socio_no INT, apellidos VARCHAR (14), telefono CHAR (9), fecha_alta DATE, direccion
VARCHAR (20), codigo_postal INT, CONSTRAINT PK_SOCIOS PRIMARY KEY (socio_no), CONSTRAINT UQ_UNIQUE
UNIQUE (apellidos));
c) CHECK. La columna codigo_postal no admitirá como válidas aquellas filas en las que el código postal no tenga
valores entre 28.000 y 28.999 (correspondientes a Madrid)
CREATE TABLE socios_2c (socio_no INT, apellidos VARCHAR (14), telefono CHAR (9),
fecha_alta DATETIME, direccion VARCHAR(20), codigo_postal INT, CONSTRAINT PK_DEPARTAMENTOS PRIMARY
KEY(socio_no), CONSTRAINT UQ_UNIQUE UNIQUE(apellidos), CONSTRAINT CK_CODIGO CHECK (codigo_postal
BETWEEN 28000 AND
28999) );
6.7.5.3. ALTER TABLE

La sentencia ALTER TABLE sirve para modificar la estructura de una tabla que ya existe. Mediante esta
instrucción podemos añadir columnas nuevas, eliminar columnas. Ten cuenta que cuando eliminamos una
columna se pierden todos los datos almacenados en ella.
También nos permite crear nuevas restricciones o borrar algunas existentes. La sintaxis puede parecer algo
complicada pero sabiendo el significado de las palabras reservadas la sentencia se aclara bastante; ADD
(añade), ALTER (modifica), DROP (elimina), COLUMN (columna), CONSTRAINT (restricción).
La sintaxis de restriccion1 es idéntica a la restricción1 de la sentencia CREATE TABLE, te la describimos a

continuación, si tienes alguna duda repasa la sentencia CREATE TABLE.

La sintaxis de restriccion2 es idéntica a la restricción2 de la sentencia CREATE TABLE, te la describimos a

continuación, si tienes alguna duda repasa la sentencia CREATE TABLE
La cláusula ADD permite añadir una columna nueva a la tabla. Como en la creación de tabla, hay que definir
la columna indicando su nombre, tipo de datos que puede contener, y si lo queremos alguna restricción de
valor no nulo, clave primaria, clave foránea, e índice único,
restriccion1 es opcional e indica una restricción de tipo 1 que afecta a la columna que estamos definiendo.
Ejemplo:
6.7.5.3.1. Alter table tab1 add col3 int not null constraint c1 unique
Con este ejemplo estamos añadiendo a la tabla tab1 una columna llamada col3 de tipo entero, requerida (no
admite nulos) y con un índice sin duplicados llamado c1.
Cuando añadimos una columna lo mínimo que se puede poner sería:
ALTER TABLE tab1 ADD col3 int

En este caso la nueva columna admite valores nulos y duplicados.
Para añadir una nueva restricción en la tabla podemos utilizar la cláusula ADD restriccion2 (ADD
CONSTRAINT...).
Ejemplo:
6.7.5.3.2. Alter table tab1 add constraint c1 unique (col3)

Con este ejemplo estamos añadiendo a la tabla tab1 un índice único (sin duplicados) llamado c1 sobre la
columna col3.
Para borrar una columna basta con utilizar la cláusula DROP COLUMN (COLUMN es opcional) y el nombre
de la columna que queremos borrar, se perderán todos los datos almacenados en la columna
Ejemplo:
ALTER TABLE tab1 DROP COLUMN col3
Para borrar una restricción basta con utilizar la cláusula DROP CONSTRAINT y el nombre de la restricción
que queremos borrar, en este caso sólo se elimina la definición de la restricción pero los datos almacenados
no se modifican ni se pierden.
Ejemplo:
ALTER TABLE tab1 DROP CONSTRAINT c1
Con esta sentencia borramos el índice c1 creado anteriormente pero los datos de la columna col3 no se ven
afectados por el cambio.
6.7.5.4. DROP TABLE

La sentencia DROP TABLE sirve para eliminar una tabla. No se puede eliminar una tabla si está abierta,
tampoco la podemos eliminar si el borrado infringe las reglas de integridad referencial (si interviene como
tabla padre en una relación y tiene registros relacionados).
Ejemplo:
DROP TABLE tab1
Elimina de la base de datos la tabla tab1.
Realizar ejercicios de Creación de tablas

16.18.1 Creación de tablas

Capitulo 7. INDICES
7. Objetivo
Trabajar con los diferentes tipos de índices, conociendo las ventajas y desventajas de su uso en
función del objetivo buscado.
7.7. Creacion de indices
Se hará definición de índices en SQL Server - agrupados y no agrupados indexes, el

optimizador de consultas, para crear un índice, para crear un índice único, para crear un índice
agrupado, para crear índices de texto completo, para cambiar propiedades del índice, Para
cambiar el nombre de un índice, para eliminar un índice
Cuando aumentan los volúmenes de datos, las organizaciones se enfrentan a problemas
relacionados con la recuperación de datos y publicación. Sienten la necesidad de un
mecanismo que aumentará la velocidad de acceso a datos. Un índice, al igual que el índice de
un libro, permite recuperar la base de datos y presentar los datos al usuario final con facilidad.
Un índice puede ser definido como un mecanismo para proporcionar un acceso rápido a las
filas de tabla y de hacer cumplir las restricciones.
Un índice puede ser creado mediante la selección de una o más columnas de una tabla que
está siendo buscado. Es una especie de "en el disco 'estructura asociada a la tabla o vista y
contiene las claves que se construyen a partir de una o varias de las columnas de la tabla o
vista. Esta estructura conocida como B-Tree ayuda a que el SQL Server busque la fila o filas
asociadas a los valores de clave. Los índices se pueden crear en columnas calculadas o
columnas xml también.
Los índices pueden ser agrupados en clúster o no. Un índice agrupado almacena los datos de
las filas de la tabla en función de sus valores fundamentales. Cada tabla sólo puede tener un
índice agrupado como los valores clave en las filas de datos son únicos y el índice se basa en la
columna de clave única. Cuando una tabla tiene un índice agrupado, se conoce como una
tabla de clúster. Índices no agrupados tienen estructuras que son diferentes de las filas de
datos. Un índice no agrupado valor de clave se usa para apuntar a las filas de datos que
contienen el valor clave. Este valor se conoce como localizador de fila. La estructura del
localizador de fila está determinado sobre la base del tipo de almacenamiento de las páginas
de datos. Si la página de datos se almacena como un montón, un localizador de fila se
convierte en un puntero a una fila. Si la página de datos se almacena en una tabla agrupada el
localizador de fila es una clave del índice agrupado. Índices agrupados y no agrupados pueden
ser únicos y los índices se mantienen automáticamente para una tabla o vista cada vez que la
tabla de datos se ha modificado.
SQL Server permite a los usuarios agregar columnas sin clave al nivel hoja del índice no
agrupado en el índice existente que pasa los límites de claves y para ejecutar plenamente
cubiertos consultas índices.

Cuando las restricciones de clave principal y única de una columna de la tabla se definen un
índice automático se crea.
El optimizador de consultas utiliza los índices para reducir disco I / O las operaciones y el uso
de los recursos del sistema, mientras que en la consulta de datos. Las consultas que contienen
instrucciones SELECT, UPDATE o DELETE requieren índices para un rendimiento óptimo.
Cuando se ejecuta una consulta, cada método disponible se evalúa para la recuperación de
datos y la más eficiente es seleccionada por el optimizador de consultas. La metodología
utilizada puede ser recorridos de tablas o exploraciones de índices. En la tabla I lecturas /
operaciones de E son muchos y muchos recursos en todas las filas de una tabla se analizan
para encontrar las relevantes. exploraciones de índices se utilizan para buscar en el índice de
columnas de clave para encontrar la ubicación de almacenamiento de filas que necesita la
consulta y como el índice contiene muy pocas columnas, la consulta se ejecuta más rápido.
SQL Server proporciona al usuario una nueva Transact-SQL DDL para la modificación de los
índices relacionales y XML. La instrucción CREATE INDEX se ha mejorado para admitir la
sintaxis XML índice, la separación y las columnas incluidas. Un número de opciones sobre
índices se han añadido nuevas incluyendo la opción en línea que permite el acceso de usuarios
concurrentes a los datos subyacentes durante las operaciones de índice.
7.7.1. Crear un índice

1. En Explorador de objetos, haga clic en la tabla para el que desea crear un índice y haga clic
en Modificar.

2. La tabla se abre en el Diseñador de tablas.
3. En el menú Diseñador de tablas, haga clic en Índices / Claves.

4. En los Índices / Claves cuadro de diálogo, haga clic en Agregar.
5. Seleccione el nuevo índice en la Primaria Clave única seleccionada / o la lista de índice y

establecer propiedades para el índice en la red a la derecha.
6. Especifique cualquier otra configuración para el índice y haga clic en Cerrar.

7. El índice se crea en la base de datos al guardar la tabla.
SQL Server permite a los usuarios crear índices únicos en columnas únicas como el número de
identificación del empleado o estudiante o lo que es la clave única por la que el componente
de datos se identifican. Un conjunto de columnas también se pueden utilizar para crear un
índice único. El DBA puede establecer la opción de ignorar duplicados de las llaves en un
índice único si es necesario. El valor predeterminado es No.
7.7.2. Para crear un índice único

1. En Explorador de objetos, haga clic en la tabla y haga clic en Modificar.
4. Haga clic en Agregar. La seleccionada Principal / Clave única o lista muestra el índice asignado por el sistema de
nombres del nuevo índice.

5. En la cuadrícula, haga clic en Tipo.
6. Elija Índice de la lista desplegable hacia abajo a la derecha de la propiedad.

7. En Nombre de columna, seleccione las columnas que desea indexar. Puede seleccionar
hasta 16 columnas. Para un rendimiento óptimo, seleccione sólo una o dos columnas por
índice. Para cada columna que seleccione, indicar si el índice organiza valores de esta columna
en orden ascendente o descendente.

8. En la cuadrícula, haga clic en es único.
9. Elija Sí en la lista desplegable hacia abajo a la derecha de la propiedad.

10. Seleccione la opción Ignorar duplicados llaves si desea ignorar nuevo o actualizado los
datos que permitiera crear un duplicado de la llave en el índice (con la instrucción INSERT o
UPDATE).


11. El índice se crea en la base de datos al guardar la tabla o diagrama.
Tenga en cuenta que los índices únicos no se pueden crear en una sola columna si la columna
contiene NULL en más de una fila. Del mismo modo los índices no se pueden crear en varias
columnas si la combinación de las columnas contiene valores NULL en algunas filas. Los
valores NULL se tratan como valores duplicados.
Índices agrupados se pueden crear en bases de datos SQL Server. En tales casos, el orden
lógico del índice de valores de las claves será el mismo que el orden físico de las filas de la
tabla. Una tabla sólo puede tener un índice agrupado.
7.7.3. Crear un índice agrupado

1. En Explorador de objetos, haga clic en la tabla para el que desea crear un índice agrupado y
haga clic en Modificar. 2. La tabla se abre en el Diseñador de tablas. 3. En el menú Diseñador
de tablas, haga clic en Índices / Claves. 4. En los Índices / Claves cuadro de diálogo, haga clic
en Agregar. 5. Seleccione el nuevo índice en la Selección de Primaria Clave única / o en la
lista de índice.
6. En la cuadrícula, seleccione Crear como agrupado, y elija Sí en la lista desplegable hacia
abajo a la derecha de la propiedad.

7. El índice se crea en la base de datos al guardar la tabla.

Un índice de texto completo se usa cuando una búsqueda de texto completo es requerida
para llevar a cabo en todo el texto basado en columnas de la base de datos. Este índice se
basa en un índice regular que tiene que crearse antes de un índice de texto completo es
creado. El índice regular se crea en una, no solo de columna nula. Por lo general, una columna
con valores pequeños se selecciona para la indexación en un índice normal. A menudo, un
catálogo se crea utilizando una herramienta externa, como SQL Server Management Studio.
Los datos textuales de diferentes formatos de archivos de texto se almacenan como archivos
de tipo imagen antes de la búsqueda de texto completo se puede hacer en los datos.
7.7.4. Para crear índices de texto completo

1. En Explorador de objetos, haga clic en la tabla para el que desea crear un índice de texto completo y haga clic en
Modificar.
3. En el menú Diseñador de tablas, haga clic en Índice Texto completo.

4. El índice de texto completo cuadro de diálogo se abre. Si la base de datos no está habilitada
para la indexación de texto completo el cuadro de diálogo tendrá en el botón añadir
discapacitados. Para habilitar la indexación de texto completo de la base de datos, haga clic
derecho la base de datos> Haga clic en Propiedades y compruebe el texto completo de
indexación casilla de verificación.

5. A continuación, cree un catálogo con el botón derecho sobre almacenamiento Texto
completo Catálogo> y la creación de un nuevo catálogo y de introducir la información
requerida en el cuadro de diálogo que se abre.
6. Ahora abra la propiedad Index Texto completo cuadro de diálogo haciendo clic sobre ella en
el menú Diseñador de tablas.

7. Haga clic en Agregar.

8. Seleccione el nuevo índice en el índice de texto Lista completa seleccionada y establecer
propiedades para el índice en la red a la derecha
9. Su índice se guardan automáticamente en la base de datos al guardar la tabla en el
Diseñador de tablas. El índice está disponible para su modificación en cuanto se lo crea.
7.7.5. Para cambiar las propiedades del índice

1. En Explorador de objetos, haga clic en la tabla que desea abrir y haga clic en
Modificar.
3. Seleccione el índice de la Selección de Primaria Clave única / o en la lista de índice.
4. Cambiar las propiedades de la cuadrícula.
5. Los cambios se guardan en la base de datos al guardar la tabla.
Sistema de nombres definidos se asignan a los índices basados en el nombre del archivo de
base de datos. Si se crean varios índices en una tabla los nombres de índice se incrementan
numéricamente con _1, _2, etc Un índice puede ser renombrado a ser único a una tabla. Dado
que el índice creado automáticamente lleva el mismo nombre como la clave única o principal
limitación de una tabla, otro índice no se puede cambiar más tarde para coincidir con la clave
única o principal limitación.

7.7.6. Cambiar el nombre de un índice
1. En Explorador de objetos, haga clic en la tabla con el índice que desea cambiar de nombre y
haga clic en Modificar. 2. En el menú Diseñador de tablas, haga clic en Índices / Claves. 3.
Seleccione el índice de la Selección de Primaria Clave única / o en la lista de índice. 4. En la
cuadrícula, haga clic en Nombre y escriba un nuevo nombre en el cuadro de texto.
5. Los cambios se guardan en la base de datos al guardar la tabla.

Los índices se pueden eliminar. Por lo general, un índice es considerado para su eliminación
cuando el cumplimiento de las instrucciones INSERT, UPDATE y DELETE operaciones se ven
dificultadas por el Índice.
7.7.7. Eliminar un índice

1. En Explorador de objetos, haga clic en la tabla con los índices que desea eliminar y haga clic
en Modificar.
3. En los Índices / Claves cuadro de diálogo, seleccionar el índice que desea eliminar
4. Haga clic en Eliminar.
5. El índice se elimina de la base de datos cuando la tabla se guarda. 6. Un procedimiento
similar se puede seguir para eliminar un índice de texto completo mediante la selección de
índice de texto completo desde el Diseñador de tablas y seleccionando el nombre del índice y
haciendo clic en el botón eliminar.

Microsoft SQL Server utiliza base de datos de un factor de relleno para especificar cómo se
llena cada página de índice puede ser. El porcentaje de espacio libre concedido a un índice se
define como el factor de relleno. Este es un aspecto importante de la indexación como la
cantidad de espacio a ser ocupado por un índice debe ser determinado por el DBA para que el
rendimiento no tiene retardo mental.

Capitulo 8. VISTAS
8. Objetivo
Trabajar con el diseño y uso de vistas para facilitar las consultas sobre diferentes tablas de una
base de datos.
8.7. Vistas
Podemos definir una vista como una consulta almacenada en la base de datos que se utiliza como una tabla
virtual. Se define asociadas a una o varias tablas y no almacena los datos sino que trabaja sobre los datos de las
tablas sobre las que está definida, estando así en todo momento actualizada.
8.7.1. ¿Qué son las vistas y para qué sirven?

Se trata de una perspectiva de la base de datos o ventana que permite a uno o varios usuarios ver solamente las
filas y columnas necesarias para su trabajo.
Entre las ventajas que ofrece la utilización de vistas cabe destacar:

Seguridad y confidencialidad: ya que la vista ocultará los datos confidenciales o aquellos para los que el usuario no
tenga permiso.
Comodidad: ya que solamente muestra los datos relevantes, permitiendo, incluso trabajar con agrupaciones de
filas como si se tratase de una única fila o con composiciones de varias tablas como si se tratase de una única
tabla.
Independencia respecto a posibles cambios en los nombres de las columnas, de las tablas, etcétera.
Por ejemplo, la siguiente consulta permite al departamento de VENTAS realizar la gestión de sus empleados
ocultando la información relativa a los empleados de otros departamentos.
SELECT * FROM EMPLEADOS WHERE dep_no=30;
La siguiente consulta permite a cualquier empleado de la empresa obtener información no confidencial de

cualquier otro empleado ocultando las columnas SALARIO y COMISION:
SELECT emp_no, apellido, oficio, director, fecha_alta, dep_no FROM empleados;
Para ello crearemos vistas y permitiremos a los usuarios tener acceso a las vistas sin tenerlo de la tabla completa.
8.7.2. Creación y utilización de vistas

Como hemos dicho son tablas virtuales resultado de una consulta realizadas sobre tablas ya existentes. Las vistas
no ocupan espacio en la base de datos ya que lo único que se almacena es la definición de la vista. El gestor de la
base de datos se encargará de comprobar los comandos SQL que hagan referencia a la vista, transformándolos en
los comandos correspondientes referidos a las tablas originales, todo ello de forma transparente para el usuario.

8.7.3. Formato de la creación de vistas.

Para crear una vista se utiliza el comando CREATE VIEW según el siguiente formato genérico:
El siguiente ejemplo crea la vista emple_dep30 para la gestión de los empleados del departamento 30
mencionada en el apartado anterior.
CREATE VIEW emple_dep30 AS

SELECT * FROM EMPLEADOS
WHERE DEP_NO = 30;
CREATE VIEW emple_dep30 AS SELECT * FROM EMPLEADOS WHERE DEP_NO = 30;
A continuación se muestra la sentencia que crea la vista datos_emple que contiene información de todos los
empleados ocultando la información confidencial.
CREATE VIEW datos_emple AS SELECT emp_no, apellido, oficio, director, fecha_alta, dep_no FROM empleados;
Las vistas pueden a su vez definirse sobre otras vistas. Si ya tenemos creada las vista datos_emple, podríamos
crear otra vista sobre ella:
CREATE VIEW datos_emple_10 AS SELECT * FROM datos_emple WHERE dep_no=10;
8.7.4. Utilización de vistas

Una vez definida puede ser utilizada para consultas de igual forma que una tabla. Con algunas restricciones, todos
los formatos de selección vistos para las tablas son aplicables para la selección de filas en las vistas.
Por ejemplo:
También podemos seleccionar solo algunas columnas y poner una condición

SELECT apellido, director
FROM datos_emple
WHERE oficio = 'VENDEDOR';
Pero debe tenerse en cuenta que si al definir la vista hemos indicado nuevos nombres para columnas y
expresiones si podremos hacer referencia a ellos en las sentencias de selección, pero si hemos omitido la
definición de las columnas y en la sentencia de creación hemos realizado la selección de todas las columnas
(creada con select *) solo puede hacerse una selección de todas las columnas de la vista (con *)

La vista emple_dep30 la creamos sin especificar nuevo nombre para las columnas de la vista y con una sentencia
select *. Podemos obtener los datos de la vista si escribimos:
SELECT * FROM emple_dep30;
8.7.5. Ejemplos creación y utilización de vistas

Como hemos dicho una vez creada la vista se puede utilizar como si se tratase de una tabla (observando las
restricciones anteriores). Veamos lo que podemos hacer con las vistas con los ejemplos.
1-El siguiente ejemplo crea la vista datos_vendedores que muestra solamente las columnas emp_no, apellido,
director, fecha_alta, dep_no, de aquellos empleados cuyo oficio es VENDEDOR.
CREATE VIEW datos_vendedores

(num_vendedor, apellido, director, fecha_alta, dep_no) AS
SELECT emp_no, apellido, director, fecha_alta, dep_no
FROM empleados
WHERE oficio = 'VENDEDOR';
Los datos accesibles mediante la vista creada serán:
SELECT *
FROM datos_vendedores;
2- También se pueden crear vistas a partir de consultas que incluyen agrupaciones, como en el siguiente ejemplo:
CREATE VIEW resumen_dep1

(dep_no, num_empleados, suma_salario, suma_comision) AS
SELECT dep_no, COUNT(emp_no), SUM(salario),
SUM(ISNULL(comision,0)) FROM empleados GROUP BY dep_no;
En estos casos, cada fila de la vista corresponderá a varias filas en la tabla original tal como se puede comprobar
en la siguiente consulta:

SELECT *
FROM resumen_dep1;
8.7.6. Crear una vista local con un asistente
1. En el Administrador de proyectos, seleccione una base de datos.

2. Seleccione Vistas locales y elija Nuevo.
3. Elija el botón Asistente para vistas.
4. Siga las instrucciones de las pantallas del asistente.
8.7.7. Eliminación de vistas

La sentencia DROP VIEW permite eliminar la definición de una vista.
Ejemplos de borrado de vistas
DROP VIEW resumen_emp_dep;

Capitulo 9. LOGICA DE NEGOCIO
9. Objetivo
Introducción a los procedimientos almacenados para crear sentencias en T-SQL y utilizarlos tanto
en tareas de administración como en el desarrollo de software.
Realizar tareas de administración avanzada de bases de datos mediante el uso de disparadores o
triggers que permitan automatizar el control de la actividad realizada en una base de datos.
9.7. Transacciones en transact sql

Una transacción es un conjunto de operaciones Transact SQL que se ejecutan como un único bloque, es
decir, si falla una operación Transact SQL fallan todas. Si una transacción tiene éxito, todas las
modificaciones de los datos realizadas durante la transacción se confirman y se convierten en una parte
permanente de la base de datos. Si una transacción encuentra errores y debe cancelarse o revertirse, se
borran todas las modificaciones de los datos.
El ejemplo clásico de transacción es una transferencia bancaria, en la que quitamos saldo a una cuenta y lo
añadimos en otra. Si no somo capaces de abonar el dinero en la cuenta de destino, no debemos quitarlo de
la cuenta de origen.
SQL Server funciona por defecto con Transacciones de confirmación automática, es decir, cada instrucción
individual es una transacción y se confirma automáticamente.
Ejemplo de un script:
DECLARE @importe DECIMAL(18,2),

@CuentaOrigen VARCHAR(12),
@CuentaDestino VARCHAR(12)
/* Asignamos el importe de la transferencia
* y las cuentas de origen y destino
*/
SET @importe = 50
SET @CuentaOrigen = '200700000001'
SET @CuentaDestino = '200700000002'
/* Descontamos el importe de la cuenta origen */

UPDATE CUENTAS
SET SALDO = SALDO - @importe
WHERE NUMCUENTA = @CuentaOrigen

/* Registramos el movimiento */
INSERT INTO MOVIMIENTOS
(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR, IMPORTE, FXMOVIMIENTO)
SELECT
IDCUENTA, SALDO + @importe, SALDO, @importe, getdate()
FROM CUENTAS
/* Incrementamos el importe de la cuenta destino */

UPDATE CUENTAS
SET SALDO = SALDO + @importe
WHERE NUMCUENTA = @CuentaDestino
(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR, IMPORTE, FXMOVIMIENTO)
SELECT
IDCUENTA, SALDO - @importe, SALDO, @importe, getdate()
FROM CUENTAS
Esta forma de actuar seria erronea, ya que cada instrucción se ejecutaria y confirmaría de forma
independiente, por lo que un error dejaría los datos erroneos en la base de datos (¡y ese es el peor error que
nos podemos encontrar!)
TRANSACCIONES IMPLICITAS Y EXPLICITAS
Para agrupar varias sentencias Transact SQL en una única transacción, disponemos de los siguientes
métodos:
TRANSACCIONES EXPLÍCITAS
Cada transacción se inicia explícitamente con la instrucción BEGIN TRANSACTION y se termina
explícitamente con una instrucción COMMIT o ROLLBACK.
TRANSACCIONES IMPLÍCITAS
Se inicia automátivamente una nueva transacción cuando se ejecuta una instrucción que realiza
modificaciones en los datos, pero cada transacción se completa explícitamente con una
instrucción COMMIT o ROLLBACK.
Para activar-desactivar el modo de transacciones implicitas debemos ejecutar la siguiente instrucción.
--Activamos el modo de transacciones implicitas

SET IMPLICIT_TRANSACTIONS ON


--Desactivamos el modo de transacciones implicitas
SET IMPLICIT_TRANSACTIONS OFF
Cuando la opción ANSI_DEFAULTS está establecida en ON, IMPLICIT_TRANSACTIONS también se establece

en ON.
El siguiente ejemplo muestra el script anterior haciendo uso de transacciones explicitas.


*/
SET @importe = 50

BEGIN TRANSACTION -- O solo BEGIN TRAN
BEGIN TRY
UPDATE CUENTAS

(IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR,
IMPORTE, FXMOVIMIENTO)
SELECT
FROM CUENTAS

UPDATE CUENTAS



SELECT
FROM CUENTAS

/* Confirmamos la transaccion*/
COMMIT TRANSACTION -- O solo COMMIT

END TRY
BEGIN CATCH
/* Hay un error, deshacemos los cambios*/
ROLLBACK TRANSACTION -- O solo ROLLBACK
PRINT 'Se ha producido un error!'
END CATCH
El siguiente ejemplo muestra el mismo script con transacciones implicitas.



*/
SET @importe = 50


BEGIN TRY
UPDATE CUENTAS

SELECT
FROM CUENTAS

UPDATE CUENTAS

SELECT
FROM CUENTAS

/* Confirmamos la transaccion*/
COMMIT TRANSACTION -- O solo COMMIT
END TRY
BEGIN CATCH
/* Hay un error, deshacemos los cambios*/

ROLLBACK TRANSACTION -- O solo ROLLBACK

PRINT 'Se ha producido un error!'
END CATCH
La transacción sigue activa hasta que emita una instrucción COMMIT o ROLLBACK. Una vez que la primera
transacción se ha confirmado o revertido, se inicia automáticamente una nueva transacción la siguiente vez
que la conexión ejecuta una instruccion para modificar datos.
La conexión continúa generando transacciones implícitas hasta que se desactiva el modo de transacciones
implícitas.
Podemos verificar el número de transacciones activas a través de @@TRANCOUNT.
BEGIN TRY
UPDATE CUENTAS SET FXALTA = FXALTA - 1
PRINT @@TRANCOUNT
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
PRINT 'Error'
END CATCH
BEGIN TRAN

UPDATE EMPLEADOS
SET NOMBRE = 'Devjoker'
WHERE ID=101

BEGIN TRAN

UPDATE EMPLEADOS
SET APELLIDO1 = 'Devjoker.COM'
WHERE ID=101

-- Este COMMIT solo afecta a la segunda transaccion.

COMMIT

-- Este ROLLBACK afecta a las dos transacciones.
ROLLBACK
Una consideración a tener en cuanta cuando trabajamos con transacciones anidadas es la posibilidad de
utilizar puntos de guardado o SAVEPOINTs.
PUNTOS DE RECUPERACION (SAVEPOINT).
Los puntos de recuperación (SavePoints) permiten manejar las transacciones por pasos, pudiendo hacer
rollbacks hasta un punto marcado por el savepoint y no por toda la transacción.
El siguiente ejemplo muestra como trabajar con puntos de recuperación.

BEGIN TRAN

UPDATE EMPLEADOS
SET NOMBRE = 'Devjoker'
WHERE ID=101

UPDATE EMPLEADOS
SET APELLIDO1 = 'Devjoker.COM'
WHERE ID=101

SAVE TRANSACTION P1 -- Guardamos la transaccion (Savepoint)

UPDATE EMPLEADOS
SET APELLIDO1 = 'Otra cosa!'
WHERE ID=101

-- Este ROLLBACK afecta solo a las instrucciones
-- posteriores al savepoint P1.
ROLLBACK TRANSACTION P1

-- Confirmamos la transaccion
COMMIT
9.8. Estructuras de control en transact SQL


ESTRUCTURA CONDICIONAL IF
La estuctura condicional IF permite evaluar una expresion booleana (resultado SI - NO), y ejecutar las
operaciones contenidas en el bloque formado por BEGIN END.
IF (<expresion>)
BEGIN
...
END
ELSE IF (<expresion>)
BEGIN
...
END
ELSE
BEGIN
...
END
Ejemplo de la estructura condicional IF.
DECLARE @Web varchar(100),

@diminutivo varchar(3)

SET @diminutivo = 'DJK'

IF @diminutivo = 'DJK'
BEGIN
PRINT 'www.devjoker.com'
END
ELSE
BEGIN
PRINT 'Otra Web (peor!)'
END
La estructura IF admite el uso de subconsultas:
DECLARE @coPais int,

@descripcion varchar(255)
set @coPais = 5
set @descripcion = 'España'
IF EXISTS(SELECT * FROM PAISES
WHERE CO_PAIS = @coPais)
BEGIN
UPDATE PAISES
SET DESCRIPCION = @descripcion
WHERE CO_PAIS = @coPais
END
ELSE
BEGIN
INSERT INTO PAISES
(CO_PAIS, DESCRIPCION) VALUES

(@coPais, @descripcion)
END
9.8.1. Estructura condicional case

La estructura condicional CASE permite evaluar una expresion y devolver un valor u otro.
La sintaxis general de case es:
CASE <expresion>

WHEN <valor_expresion> THEN <valor_devuelto>
WHEN <valor_expresion> THEN <valor_devuelto>
ELSE <valor_devuelto> -- Valor por defecto
END
Ejemplo de CASE.

SET @Web = (CASE @diminutivo
WHEN 'DJK' THEN 'www.devjoker.com'
WHEN 'ALM' THEN 'www.aleamedia.com'
ELSE 'www.devjoker.com'
END)
PRINT @Web
Otra sintaxis de CASE nos permite evaluar diferentes expresiones:
CASE
WHEN <expresion> = <valor_expresion> THEN <valor_devuelto>
WHEN <expresion> = <valor_expresion> THEN <valor_devuelto>
ELSE <valor_devuelto> -- Valor por defecto
END
El mismo ejemplo aplicando esta sintaxis:

SET @Web = (CASE

WHEN @diminutivo = 'DJK' THEN 'www.devjoker.com'
WHEN @diminutivo = 'ALM' THEN 'www.aleamedia.com'
END)

PRINT @Web
Otro aspecto muy interesante de CASE es que permite el uso de subconsultas.

SET @Web = (CASE

WHEN @diminutivo = 'DJK' THEN (SELECT web
FROM WEBS
WHERE id=1)
WHEN @diminutivo = 'ALM' THEN (SELECT web
FROM WEBS
WHERE id=2)
END)
PRINT @Web
9.8.2. Bucle while

El bucle WHILE se repite mientras expresion se evalue como verdadero.
Es el único tipo de bucle del que dispone Transact SQL.
WHILE <expresion>

BEGIN
...
END
Un ejemplo del bucle WHILE.
DECLARE @contador int

SET @contador = 0
WHILE (@contador < 100)
BEGIN
SET @contador = @contador + 1
PRINT 'Iteracion del bucle ' + cast(@contador AS varchar)

END
Podemos pasar a la siguiente iteración del bucle utilizando CONTINUE.

SET @contador = 0
WHILE (@contador < 100)
BEGIN

IF (@contador % 2 = 0)
CONTINUE
END
El bucle se dejará de repetir con la instrucción BREAK.

SET @contador = 0
WHILE (1 = 1)
BEGIN
IF (@contador % 50 = 0)
BREAK
END
También podemos utilizar el bucle WHILE conuntamente con subconsultas.
DECLARE @coRecibo int

WHILE EXISTS (SELECT *
FROM RECIBOS
WHERE PENDIENTE = 'S')-- Ojo, la subconsulta se ejecuta
-- una vez por cada iteracion
-- del bucle!
BEGIN
SET @coRecibo = (SELECT TOP 1 CO_RECIBO
FROM RECIBOS WHERE PENDIENTE = 'S')
UPDATE RECIBOS
SET PENDIENTE = 'N'
WHERE CO_RECIBO = @coRecibo
END
9.8.3. Estructura GOTO

La sentencia goto nos permite desviar el flujo de ejecución hacia una etiqueta. Fué muy utilizada en
versiones anteriores de SQL Server conjuntamente con la variable de sistema @@ERROR para el control de
errores.
Actualmente, se desaconseja el uso GOTO, recomendandose el uso de TRY - CATCH para la gestion de
errores.
DECLARE @divisor int,

@dividendo int,
@resultado int
SET @dividendo = 100
SET @divisor = 0
SET @resultado = @dividendo/@divisor


IF @@ERROR > 0

GOTO error

PRINT 'No hay error'
RETURN
error:
PRINT 'Se ha producido una division por cero'
9.9. Control de errores en transact SQL

USO DE TRY CATCH
A partIr de la versión 2005, SQL Server proporciona el control de errores a través de las
instrucciónes TRY y CATCH.
Estas nuevas instrucciones suponen un gran paso adelante en el control de errores en SQL Server, un tanto
precario en las versiones anteriores.
La sintaxis de TRY CATCH es la siguiente:

BEGIN TRY
...
END TRY
BEGIN CATCH
...
END CATCH
El siguiente ejemplo ilustra el uso de TRY - CATCH.
BEGIN TRY
DECLARE @divisor int ,
@dividendo int,
@resultado int
SET @divisor = 0
-- Esta linea provoca un error de division por 0

END TRY
BEGIN CATCH
PRINT 'Se ha producido un error'
END CATCH

9.9.1. Funciones especiales de error

Las funciones especiales de error, están disponibles únicamente en el bloque CATCH para la obtención de
información detallada del error.
Son:
ERROR_NUMBER(), devuelve el número de error.
ERROR_SEVERITY(), devuelve la severidad del error.
ERROR_STATE(), devuelve el estado del error.
ERROR_PROCEDURE(), devuelve el nombre del procedimiento almacenado que ha provocado el error.
ERROR_LINE(), devuelve el número de línea en el que se ha producido el error.
ERROR_MESSAGE(), devuelve el mensaje de error.
Son extremadamente útiles para realizar una auditoría de errores.
BEGIN TRY
@dividendo int,
@resultado int
SET @divisor = 0

END TRY
BEGIN CATCH
PRINT ERROR_NUMBER()
PRINT ERROR_SEVERITY()
PRINT ERROR_STATE()
PRINT ERROR_PROCEDURE()
PRINT ERROR_LINE()
PRINT ERROR_MESSAGE()
END CATCH
Lógicamente, podemos utilizar estas funciones para almacenar esta información en una tabla de la base de
datos y registrar todos los errores que se produzcan.
9.9.2. La variable de sistema @@error

En versiones anteriores a SQL Server 2005, no estaban disponibles las instrucciones TRY CATCH. En estas
versiones se controlaban los errores utilizando la variable global de sistema @@ERROR, que almacena el
número de error producido por la última sentencia Transact SQL ejecutada.


@dividendo int ,
@resultado int

SET @divisor = 0

IF @@ERROR = 0
BEGIN
END
ELSE
BEGIN
PRINT 'Hay error'
END
El uso de @@ERROR para controlar errores puede provocar multitud de problemas. Uno de los más

habituales es sin duda, incluir una nueva sentencia Transact SQL entre la línea que provoco el error y la que
lo controla. Esa nueva instrucción restaura el valor de @@ERROR y no controlaremos el error.
El siguiente ejemplo ilustra esta situación:

@dividendo int ,
@resultado int

SET @divisor = 0
PRINT 'Controlando el error ...' -- Esta linea estable @@ERROR a cero
IF @@ERROR = 0
BEGIN
-- Se ejecuta esta parte!
END
ELSE
BEGIN
PRINT 'Hay error'
END
9.9.2.1. Generar un error con raiserror

En ocasiones es necesario provocar voluntariamente un error, por ejemplo nos puede interesas que se
genere un error cuando los datos incumplen una regla de negocio.
Podemos provocar un error en tiempo de ejecución a través de la función RAISERROR.
DECLARE @tipo int,

@clasificacion int

SET @tipo = 1
SET @clasificacion = 3
IF (@tipo = 1 AND @clasificacion = 3)
BEGIN
RAISERROR ('El tipo no puede valer uno y la clasificacion 3',
16, -- Severidad
1 -- Estado
)
END
La función RAISERROR recibe tres parámetros, el mensaje del error (o código de error predefinido), la
severidad y el estado.
La severidad indica el grado de criticidad del error. Admite valores de 0 al 25, pero solo podemos
asignar valores del 0 al 18. Los errores el 20 al 25 son considerados fatales por el sistema, y cerraran la
conexion que ejecuta el comando RAISERROR. Para asignar valores del 19 al 25 necesitares ser miembros de
la función de SQL Server sysadmin.
El estado es un valor para permitir que el programador identifique el mismo error desde diferentes partes
del código. Admite valores entre 1 y 127, permite tratar.
9.10. Procedimientos almacenados en transact SQL

Un procedimiento es un programa dentro de la base de datos que ejecuta una acción o conjunto de
acciones específicas.
Un procedimiento tiene un nombre, un conjunto de parámetros (opcional) y un bloque de código.
En Transact SQL los procedimientos almacenados pueden devolver valores (numerico entero) o conjuntos
de resultados.
Para crear un procedimiento almacenado debemos emplear la sentencia CREATE PROCEDURE.
CREATE PROCEDURE <nombre_procedure> [@param1 <tipo>, ...]

AS
-- Sentencias del procedure
Para modificar un procedimiento almacenado debemos emplear la sentencia ALTER PROCEDURE.
ALTER PROCEDURE <nombre_procedure> [@param1 <tipo>, ...]

AS
-- Sentencias del procedure
El siguiente ejemplo muestra un procedimiento almacenado, denominado spu_addCliente que inserta un

registro en la tabla "CLIENTES".

CREATE PROCEDURE spu_addCliente @nombre varchar(100),

@apellido1 varchar(100),
@nifCif varchar(20),
@fxNaciento datetime
AS
INSERT INTO CLIENTES
(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES
(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento)
Para la ejecutar un procedimiento almacenado debemos utilizar la sentencia EXEC. Cuando la ejecución del
procedimiento almacenado es la primera instrucción del lote, podemos omitir el uso de EXEC.
El siguiente ejemplo muestra la ejecución del procedimiento almacenado anterior.
DECLARE @fecha_nacimiento datetime

set @fecha_nacimiento = convert(datetime, '13/05/1975', 103)
EXEC spu_addCliente 'Pedro', 'Herrarte', 'Sanchez',
'00000002323', @fecha_nacimiento
Siempre es deseable que las instrucciones del procedure esten dentro de un bloque TRY CATCH y
controlados por una transacción.
ALTER PROCEDURE spu_addCliente @nombre varchar(100),

@nifCif varchar(20),
@fxNaciento datetime
AS
BEGIN TRY
BEGIN TRAN
INSERT INTO CLIENTES
(nombre, apellido1, apellido2, nifcif, fxnacimiento) VALUES
(@nombre, @apellido1, @apellido2, @nifCif, @fxNaciento)
COMMIT
END TRY
BEGIN CATCH

ROLLBACK
PRINT ERROR_MESSAGE()
END CATCH
Si queremos que los parámetros de un procedimiento almacenado sean de entrada-salida debemos

especificarlo a través de la palabra clave OUTPUT, tanto en la definición del procedure como en la ejecución.
El siguiente ejemplo muestra la definición de un procedure con parámetros de salida.
CREATE PROCEDURE spu_ObtenerSaldoCuenta @numCuenta varchar(20),

@saldo decimal(10,2) output
AS
BEGIN
SELECT @saldo = SALDO
FROM CUENTAS
WHERE NUMCUENTA = @numCuenta
END
Y para ejecutar este procedure:
DECLARE @saldo decimal(10,2)

EXEC spu_ObtenerSaldoCuenta '200700000001', @saldo output
PRINT @saldo
Un procedimiento almacenado puede devolver valores numericos enteros a través de la instrucción

RETURN. Normalmente debemos utilizar los valores de retorno para determinar si la ejecución del
procedimiento ha sido correcta o no. Si queremos obtener valores se recomienda utilizar parámetros de
salida o funciones escalares (se verán mas adelante en este tutorial).
El siguiente ejemplo muestra un procedimiento almacenado que devuelve valores.
CREATE PROCEDURE spu_EstaEnNumerosRojos @numCuenta varchar(20)

AS
BEGIN
IF (SELECT SALDO FROM CUENTAS
WHERE NUMCUENTA = @numCuenta) < 0
BEGIN
RETURN 1
END
ELSE

RETURN 0
END
El siguiente ejemplo muestra como ejecutar el procedure y obtener el valor devuelto.
DECLARE @rv int

EXEC @rv = spu_EstaEnNumerosRojos '200700000001'
PRINT @rv
Otra caracteristica muy interesante de los procedimientos almacenados en Transact SQL es que pueden
devolver uno o varios conjuntos de resultados.
El siguiente ejemplo muestra un procedimiento almacenado que devuelve un conjunto de resultados.
CREATE PROCEDURE spu_MovimientosCuenta @numCuenta varchar(20)

AS
BEGIN
SELECT @numCuenta,
SALDO_ANTERIOR,
SALDO_POSTERIOR,
IMPORTE,
FXMOVIMIENTO
FROM MOVIMIENTOS
INNER JOIN CUENTAS ON MOVIMIENTOS.IDCUENTA = CUENTAS.IDCUENTA
WHERE NUMCUENTA = @numCuenta
ORDER BY FXMOVIMIENTO DESC
END
La ejecución del procedimiento se realiza normalmente.
EXEC spu_MovimientosCuenta '200700000001'
9.11. Funciones en transact SQL

SQL Server proporciona al usuario la posibilidad de definir sus propias funciones, conocidad como UDF (user
defined functions). Exisiten tres tipos de funciones. Estas son:
Funciones escalares.
Funciones en línea.
Funciones en línea de multiples sentencias

9.11.1. Funciones escalares
Las funciones escalares devuelven un único valor de cualquier tipo de los datos tal como int, money, varchar,
real, etc.
La sintaxis para una función escalar es la siguiente:
CREATE FUNCTION <Scalar_Function_Name, sysname, FunctionName>

(
-- Lista de parámetros
<@Param1, sysname, @p1> <Data_Type_For_Param1, , int>, ...
)
-- Tipo de datos que devuelve la función.
RETURNS <Function_Data_Type, ,int>
AS
BEGIN
...
END
El siguiente ejemplo muestra como crear una función escalar.
CREATE FUNCTION fn_MultiplicaSaldo

(
@NumCuenta VARCHAR(20),
@Multiplicador DECIMAL(10,2)
)
RETURNS DECIMAL(10,2)
AS
BEGIN
DECLARE @Saldo DECIMAL(10,2),
@Return DECIMAL(10,2)

SELECT @Saldo = SALDO
FROM CUENTAS
WHERE NUMCUENTA = @NumCuenta

SET @Return = @Saldo * @Multiplicador

RETURN @Return
END

Pueden ser utilizadas en cualquier sentencia Transact SQL. Un aspecto a tener en cuenta, es que para utilizar
una función escalar debemos identificar el nombre de la función con el propietario de la misma.
El siguiente ejemplo muestra como utilizar la función anteriormente creada en una sentencia Transact SQL.
Un aspecto muy a tener en cuenta es que la función ejecutará sus sentencias SELECT una vez por cada fila
del conjunto de resultados devuelto por la consulta SELECT principal.
SELECT IDCUENTA,
NUMCUENTA,
SALDO,
FXALTA,
-- Ejecucion de la funcion:
dbo.fn_MultiplicaSaldo( NUMCUENTA, IDCUENTA) AS RESULTADO
FROM CUENTAS
DECLARE @NumCuenta VARCHAR(20),

@Resultado DECIMAL(10,2)

SET @NumCuenta = '200700000001'
SET @Resultado = dbo.fn_MultiplicaSaldo(@NumCuenta, 30.5)

PRINT @Resultado
CREATE FUNCTION <Inline_Function_Name, sysname, FunctionName>

(
<@param1, sysname, @p1> <Data_Type_For_Param1, , int>,...
)
RETURNS TABLE
AS
RETURN
(
-- Sentencia Transact SQL
)

CREATE FUNCTION fn_MovimientosCuenta

(
@NumCuenta VARCHAR(20)
)
RETURNS TABLE
AS
RETURN
(
SELECT MOVIMIENTOS.*
FROM MOVIMIENTOS
INNER JOIN CUENTAS ON MOVIMIENTOS.IDCUENTA = CUENTAS.IDCUENTA
WHERE CUENTAS.NUMCUENTA = @NumCuenta
)
No podemos utilizar la clausula ORDER BY en la sentencia de una función el línea.

Las funciones en linea pueden utilizarse dentro de joins o querys como si fueran una tabla normal.
SELECT * FROM fn_MovimientosCuenta('200700000001')
SELECT *
FROM CUENTAS
INNER JOIN CUENTAS_CLIENTE
ON CUENTAS_CLIENTE.IDCUENTA = CUENTAS.IDCUENTA
INNER JOIN CLIENTES
ON CLIENTES.id = CUENTAS_CLIENTE.IDCLIENTE
INNER JOIN fn_MovimientosCuenta('200700000001') A
ON A.IDCUENTA= CUENTAS.IDCUENTA
9.11.3. Funciones en línea de multiples sentencias

Las funciones en línea de multiples sentencias son similares a las funciones en línea excepto que el conjunto
de resultados que devuelven puede estar compuesto por la ejecución de varios consultas SELECT.
Este tipo de función se usa en situaciones donde se requiere una mayor lógica de proceso.
La sintaxis para unas funciones de tabla de multi sentencias es la siguiente:
CREATE FUNCTION <Table_Function_Name, sysname, FunctionName>

(

<@param1, sysname, @p1> <data_type_for_param1, , int>, ...

)
RETURNS
-- variable de tipo tabla y su estructura
<@Table_Variable_Name, sysname, @Table_Var> TABLE
(
<Column_1, sysname, c1> <Data_Type_For_Column1, , int>,
<Column_2, sysname, c2> <Data_Type_For_Column2, , int>
)
AS
BEGIN
-- Sentencias que cargan de datos la tabla declarada
RETURN
END
El siguiente ejemplo muestra el uso de una funcion de tabla de multi sentencias.

/* Esta funcion busca la tres cuentas con mayor saldo
* y obtiene los tres últimos movimientos de cada una
* de estas cuentas
*/
CREATE FUNCTION fn_CuentaMovimietos()

RETURNS @datos TABLE
( -- Estructura de la tabla que devuelve la funcion.
NumCuenta varchar(20),
Saldo decimal(10,2),
Saldo_anterior decimal(10,2),
Saldo_posterior decimal(10,2),
Importe_Movimiento decimal(10,2),
FxMovimiento datetime
)
AS
BEGIN
-- Variables necesarias para la lógica de la funcion.
DECLARE @idcuenta int,
@numcuenta varchar(20),

@saldo decimal(10,2)

-- Cursor con las 3 cuentas de mayor saldo
DECLARE CDATOS CURSOR FOR
SELECT TOP 3 IDCUENTA, NUMCUENTA, SALDO
FROM CUENTAS
ORDER BY SALDO DESC

OPEN CDATOS
FETCH CDATOS INTO @idcuenta, @numcuenta, @saldo

-- Recorremos el cursor
WHILE (@@FETCH_STATUS = 0)
BEGIN
-- Insertamos la cuenta en la variable de salida
INSERT INTO @datos
(NumCuenta, Saldo)
VALUES
(@numcuenta, @saldo)
-- Insertamos los tres últimos movimientos de la cuenta
INSERT INTO @datos
(Saldo_anterior, Saldo_posterior,
Importe_Movimiento, FxMovimiento )
SELECT TOP 3
SALDO_ANTERIOR, SALDO_POSTERIOR,
IMPORTE, FXMOVIMIENTO
FROM MOVIMIENTOS
WHERE IDCUENTA = @idcuenta
ORDER BY FXMOVIMIENTO DESC
-- Vamos a la siguiente cuenta
FETCH CDATOS INTO @idcuenta, @numcuenta, @saldo
END

CLOSE CDATOS;
DEALLOCATE CDATOS;


RETURN
END
Para ejecutar la función:
select * from fn_CuentaMovimietos()
9.12. Triggers en transact SQL

Un trigger(o desencadenador) es una clase especial de procedimiento almacenado que se ejecuta
automáticamente cuando se produce un evento en el servidor de bases de datos.
SQL Server proporciona los siguientes tipos de triggers:
Trigger DML, se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de
manipulación de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o
vista.
Trigger DDL, se ejecutan en respuesta a una variedad de eventos de lenguaje de definición de datos (DDL).
Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a
determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.
9.12.1. Trigger DML.

Los trigger DML se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de
manipulación de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o
vista.
La sintaxis general de un trigger es la siguiente.
CREATE TRIGGER <Trigger_Name, sysname, Trigger_Name>

ON <Table_Name, sysname, Table_Name>
AFTER <Data_Modification_Statements, , INSERT,DELETE,UPDATE>
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for trigger here
END

CREATE TRIGGER TR_CUENTAS

ON CUENTAS
AFTER UPDATE
AS
BEGIN
-- SET NOCOUNT ON impide que se generen mensajes de texto
-- con cada instrucción
SET NOCOUNT ON;
INSERT INTO HCO_SALDOS
(IDCUENTA, SALDO, FXSALDO)
SELECT IDCUENTA, SALDO, getdate()
FROM INSERTED
END
La siguiente instrucción provocará que el trigger se ejecute:
UPDATE CUENTAS
SET SALDO = SALDO + 10
WHERE IDCUENTA = 1
Una consideración a tener en cuenta es que el trigger se ejecutará aunque la instruccion DML (UPDATE,
INSERT o DELETE) no haya afectado a ninguna fila. En este caso inserted y deleted devolveran un conjunto
de datos vacio.
Podemos especificar a que columnas de la tabla debe afectar el trigger.
ALTER TRIGGER TR_CUENTAS

ON CUENTAS
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;

IF UPDATE(SALDO) -- Solo si se actualiza SALDO
BEGIN


FROM INSERTED
END
END
Los trigger están dentro de la transacción original (Insert, Delete o Update) por lo cual si dentro de nuestro
trigger hacemos un RollBack Tran, no solo estaremos echando atrás nuestro trigger sino también toda la
transacción; en otras palabras si en un trigger ponemos un RollBack Tran, la transacción de Insert, Delete o
Update volverá toda hacia atrás.
ALTER TRIGGER TR_CUENTAS

ON CUENTAS
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
FROM INSERTED

ROLLBACK
END
En este caso obtendremos el siguiente mensaje de error:

La transacción terminó en el desencadenador. Se anuló el lote.
Podemos activar y desactivar Triggers a tarvés de las siguientes instrucciones.

-- Desactiva el trigger TR_CUENTAS
DISABLE TRIGGER TR_CUENTAS ON CUENTAS
GO
-- activa el trigger TR_CUENTAS
ENABLE TRIGGER TR_CUENTAS ON CUENTAS
GO
-- Desactiva todos los trigger de la tabla CUENTAS

ALTER TABLE CUENTAS DISABLE TRIGGER ALL

GO
-- Activa todos los trigger de la tabla CUENTAS
ALTER TABLE CUENTAS ENABLE TRIGGER ALL

9.12.2. Trigger DDL
Los trigger DDL se ejecutan en respuesta a una variedad de eventos de lenguaje de definición de datos
(DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL,
y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.
La sintaxis general de un trigger es la siguiente.
CREATE TRIGGER <trigger_name, sysname, table_alter_drop_safety>

ON DATABASE
FOR <data_definition_statements, , DROP_TABLE, ALTER_TABLE>
AS
BEGIN
...
END
La siguiente instrucción impide que se ejecuten sentencias DROP TABLE y ALTER TABLE en la base de datos.
CREATE TRIGGER TR_SEGURIDAD

ON DATABASE FOR DROP_TABLE, ALTER_TABLE
AS
BEGIN
RAISERROR ('No está permitido borrar ni modificar tablas !' , 16, 1)
ROLLBACK TRANSACTION
END
9.13. Cursores en transact SQL

Un cursor es una variable que nos permite recorrer con un conjunto de resultados obtenido a través de una
sentencia SELECT fila a fila.
Cuando trabajemos con cursores debemos seguir los siguientes pasos.
Declarar el cursor, utilizando DECLARE
Abrir el cursor, utilizando OPEN
Leer los datos del cursor, utilizando FETCH... INTO
Cerrar el cursor, utilizando CLOSE

Liberar el cursor, utilizando DEALLOCATE
La sintaxis general para trabajar con un cursor es la siguiente.
-- Declaración del cursor

DECLARE <nombre_cursor> CURSOR
FOR
<sentencia_sql>

-- apertura del cursor
OPEN <nombre_cursor>

-- Lectura de la primera fila del cursor
FETCH <nombre_cursor> INTO <lista_variables>

WHILE (@@FETCH_STATUS = 0)
BEGIN
-- Lectura de la siguiente fila de un cursor
FETCH <nombre_cursor> INTO <lista_variables>
...
END -- Fin del bucle WHILE

-- Cierra el cursor
CLOSE <nombre_cursor>
-- Libera los recursos del cursor
DEALLOCATE <nombre_cursor>
El siguente ejemplo muestra el uso de un cursor.
-- Declaracion de variables para el cursor

DECLARE @Id int,
@Nombre varchar(255),
@Apellido1 varchar(255),
@NifCif varchar(20),
@FxNacimiento datetime


DECLARE cClientes CURSOR FOR
SELECT Id, Nombre, Apellido1,
Apellido2, NifCif, FxNacimiento
FROM CLIENTES
-- Apertura del cursor
OPEN cClientes
FETCH cClientes INTO @id, @Nombre, @Apellido1,
@Apellido2, @NifCif, @FxNacimiento

WHILE (@@FETCH_STATUS = 0 )
BEGIN
PRINT @Nombre + ' ' + @Apellido1 + ' ' + @Apellido2
-- Lectura de la siguiente fila del cursor
FETCH cClientes INTO @id, @Nombre, @Apellido1,
@Apellido2, @NifCif, @FxNacimiento
END

-- Cierre del cursor
CLOSE cClientes
-- Liberar los recursos
DEALLOCATE cClientes
Cuando trabajamos con cursores, la funcion @@FETCH_STATUS nos indica el estado de la última instrucción
FETCH emitida, los valores posibles son:
Valor devuelto Descripción
0 La instrucción FETCH se ejecutó correctamente.

La instrucción FETCH no se ejecutó correctamente o la fila estaba más allá del conjunto de
-1
resultados.
-2 Falta la fila recuperada.
En la apertura del cursor, podemos especificar los siguientes parámetros:
DECLARE <nombre_cursor> CURSOR

[ LOCAL | GLOBAL ]
[ FORWARD_ONLY | SCROLL ]
[ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ]

[ READ_ONLY | SCROLL_LOCKS | OPTIMISTIC ]

[ TYPE_WARNING ]
FOR <sentencia_sql>
El primer conjunto de parámetros que podemos especificar es [ LOCAL | GLOBAL ]. A continuación
mostramos el significado de cada una de estas opciones.
LOCAL
Específica que el ámbito del cursor es local para el proceso por lotes, procedimiento almacenado o
desencadenador en que se creó el cursor.
DECLARE cClientes CURSOR GLOBAL FOR

FROM CLIENTES

DECLARE cClientes CURSOR FORWARD_ONLY FOR
FROM CLIENTES

DECLARE @Id int,


DECLARE cClientes CURSOR SCROLL FOR
FROM CLIENTES
OPEN cClientes
FETCH NEXT FROM cClientes
INTO @id, @Nombre, @Apellido1, @Apellido2, @NifCif, @FxNacimiento

BEGIN
FETCH NEXT FROM cClientes
INTO @id,@Nombre,@Apellido1,@Apellido2,@NifCif,@FxNacimiento
END
-- Lectura de la fila anterior
FETCH PRIOR FROM cClientes
CLOSE cClientes
El siguiente conjunto de parámetros que podemos especificar es [STATIC | KEYSET | DYNAMIC |

FAST_FORWARD]. A continuación mostramos el significado de cada una de estas opciones.
9.13.4. Static
Define un cursor que hace una copia temporal de los datos que va a utilizar. Todas las solicitudes que se
realizan al cursor se responden desde esta tabla temporal de tempdb; por tanto, las modificaciones
realizadas en las tablas base no se reflejan en los datos devueltos por las operaciones de recuperación
realizadas en el cursor y además este cursor no admite modificaciones.

DECLARE cClientes CURSOR STATIC FOR


FROM CLIENTES
9.13.5. Keyset
Especifica que la pertenencia y el orden de las filas del cursor se fijan cuando se abre el cursor. El conjunto
de claves que identifica las filas de forma única está integrado en la tabla denominada keyset de tempdb.

DECLARE cClientes CURSOR KEYSET FOR
FROM CLIENTES
9.13.6. Dynamic
Define un cursor que, al desplazarse por él, refleja en su conjunto de resultados todos los cambios realizados
en los datos de las filas. Los valores de los datos, el orden y la pertenencia de las filas pueden cambiar en
cada operación de recuperación. La opción de recuperación ABSOLUTE no se puede utilizar en los cursores
dinámicos.

DECLARE cClientes CURSOR DYNAMIC FOR
FROM CLIENTES
9.13.7. Fast_forward
Especifica un cursor FORWARD_ONLY, READ_ONLY con las optimizaciones de rendimiento habilitadas. No se
puede especificar FAST_FORWARD si se especifica también SCROLL o FOR_UPDATE.

DECLARE cClientes CURSOR FAST_FORWARD FOR
FROM CLIENTES
En SQL Server 2000, las opciones de cursor FAST_FORWARD y FORWARD_ONLY se excluyen mutuamente. Si
se especifican ambas, se genera un error. En SQL Server 2005, las dos palabras clave se pueden utilizar en la
misma instrucción DECLARE CURSOR.
El siguiente conjunto de parámetros que podemos especificar es [ READ_ONLY | SCROLL_LOCKS |
OPTIMISTIC ]. A continuación mostramos el significado de cada una de estas opciones.

9.13.8. Read_only
Evita que se efectúen actualizaciones a través de este cursor. No es posible hacer referencia al cursor en una
cláusula WHERE CURRENT OF de una instrucción UPDATE o DELETE. Esta opción reemplaza la capacidad de
actualizar el cursor.

DECLARE cClientes CURSOR READ_ONLY FOR
FROM CLIENTES
9.13.9. SCROLL_LOCKS
Especifica que se garantiza que las actualizaciones o eliminaciones posicionadas realizadas a través del
cursor serán correctas. Microsoft SQL Server bloquea las filas cuando se leen en el cursor para garantizar que
estarán disponibles para futuras modificaciones. No es posible especificar SCROLL_LOCKS si se especifica
también FAST_FORWARD o STATIC.

DECLARE cClientes CURSOR SCROLL_LOCKS FOR
FROM CLIENTES
9.13.10. Optimistic
Especifica que las actualizaciones o eliminaciones posicionadas realizadas a través del cursor no se realizarán
correctamente si la fila se ha actualizado después de ser leída en el cursor. SQL Server no bloquea las filas al
leerlas en el cursor. En su lugar, utiliza comparaciones de valores de columna timestamp o un valor de suma
de comprobación si la tabla no tiene columnas timestamp, para determinar si la fila se ha modificado
después de leerla en el cursor. Si la fila se ha modificado, el intento de actualización o eliminación
posicionada genera un error. No es posible especificar OPTIMISTIC si se especifica también FAST_FORWARD.

DECLARE cClientes CURSOR OPTIMISTIC FOR
FROM CLIENTES
Por último, queda la opción TYPE_WARNING

9.13.11. Type_warning
Especifica que se envía un mensaje de advertencia al cliente si el cursor se convierte implícitamente del tipo
solicitado a otro.

DECLARE cClientes CURSOR TYPE_WARNING FOR
FROM CLIENTES

DECLARE cClientes CURSOR LOCAL STATIC TYPE_WARNING FOR
FROM CLIENTES

DECLARE @Id int,
DECLARE cClientes CURSOR FOR
FROM CLIENTES
FOR UPDATE

OPEN cClientes
FETCH cClientes
BEGIN

UPDATE Clientes
SET APELLIDO2 = isnull(@Apellido2,'') + ' - Modificado'
WHERE CURRENT OF cClientes
FETCH cClientes
INTO @id, @Nombre, @Apellido1, @Apellido2,
@NifCif, @FxNacimiento
END
CLOSE cClientes
9.14. SQL dinámico en transact SQL

Transact SQL permite dos formas de ejecutar SQL dinamico (construir sentencias SQL dinamicamente para
ejecutarlas en la base de datos):
La instrucción EXECUTE - o simplemente EXEC
El procedimiento almacenado sp_executesql
Desde aquí recomendamos la utilización de sp_executesql si bien vamos a mostrar la forma de trabajar con
ambos métodos.
INSTRUCCIÓN EXECUTE
La instrucción EXECUTE - o simplemente EXEC - permite ejecutar una cadena de caracteres que representa
una sentencia SQL. La cadena de caracteres debe ser de tipo nvarchar.
El siguiente ejemplo muestra como ejecutar una cadena de caracteres con la instrucción EXEC.

DECLARE @sql nvarchar(1000)

SET @sql = 'SELECT
COD_PAIS,
NOMBRE_PAIS,
ACTIVO,
FX_ALTA
FROM
PAISES'
EXEC (@sql)

También con SQL dinamico podemos ejecutar sentencias de tipo DDL (Data Definition Languaje), como
CREATE TABLE.

SET @sql='CREATE TABLE TEMPORAL
( ID int IDENTITY, DATO varchar(100))'
EXEC (@sql)

SET @sql = 'SELECT * FROM TEMPORAL'
EXEC (@sql)

sp_executesql es más seguro y versátil que EXECUTE
sp_executesql genera planes de ejecución con más probabilidades de que SQL Server los vuelva a utilizar, es
más eficaz queEXECUTE.
El siguiente ejemplo muestra el uso (muy simple) de sp_executesql.


SET @sql = 'SELECT
COD_PAIS,
NOMBRE_PAIS,
ACTIVO,
FX_ALTA
FROM
PAISES'

EXEC sp_executesql @sql
sp_executesql admite la sustitución de valores de parámetros para cualquier parámetro especificado en la

cadena Transact-SQL a ejecutar.
El siguiente ejemplo muestra el uso de sp_executesql con parámetros:

DECLARE @sql nvarchar(1000),
@paramDefinition nvarchar(255),
@paramValue char(3)

SET @paramDefinition = '@codPais char(3)'
SET @paramValue = 'ESP'
SET @sql = 'SELECT
COD_PAIS,
NOMBRE_PAIS,
ACTIVO,
FX_ALTA
FROM
PAISES
WHERE COD_PAIS = @codPais'

EXEC sp_executesql @sql, @paramDefinition, @paramValue

Realizar los ejercicios de l manual de Trabajo las

prácticas de evaluacion

10. Capitulo 10. Manual de Trabajo
10.7. Objetivos
`Con este Manual de Trabajo se pretende ue el lector acceda a los distintos ejercicios
opcionales y obligatorios del material de de SQL. Los ejercicios están divididos según los
bloques del curso.
Selecciona cada uno de los bloques para acceder a los ejercicios correspondientes.
No obstante, se debe tener en cuenta que no se trata de un ejercicio de autoevaluación, sino
de evaluación por parte del material, por lo cual debes intentar resolverlo por tu cuenta para
medir el nivel de avance en cada tema.
10.8. Script Ejemplo creación Base de Datos Curso
Recuerda que para realizar los ejercicios de cada parte, necesitaras el Script que se encuentra
debajo; de esa manera podrás aplicar todo lo relacionado con SQL.
use master
go
create database curso
go
USE CURSO
GO
/****** Object: Table DEPARTAMENTOS Script Date: 02/29/2016 19:28:37 ******/
CREATE TABLE DEPARTAMENTOS

(
DEP_NO int NOT NULL,
DNOMBRE varchar(14) NULL,
LOCALIDAD varchar(10) NULL,
CONSTRAINT PK_DEPARTAMENTOS_DEP_NO PRIMARY KEY (DEP_NO)
)
GO
INSERT DEPARTAMENTOS (DEP_NO, DNOMBRE, LOCALIDAD) VALUES (10, 'CONTABILIDAD', 'BARCELONA')

INSERT DEPARTAMENTOS (DEP_NO, DNOMBRE, LOCALIDAD) VALUES (20, 'INVESTIGACIO', 'VALENCIA')

INSERT DEPARTAMENTOS (DEP_NO, DNOMBRE, LOCALIDAD) VALUES (30, 'VENTAS', 'MADRID')
INSERT DEPARTAMENTOS (DEP_NO, DNOMBRE, LOCALIDAD) VALUES (40, 'PRODUCCIO', 'SEVILLA')
go
/****** Object: Table PRODUCTOS Script Date: 02/29/2016 19:28:37 ******/
CREATE TABLE PRODUCTOS

(
PRODUCTO_NO int NOT NULL,
DESCRIPCION varchar(30) NULL,
PRECIO_ACTUAL float NULL,
STOCK_DISPONIBLE int NULL,
CONSTRAINT PK_PRODUCTO_NO PRIMARY KEY (PRODUCTO_NO)
)
GO
INSERT PRODUCTOS (PRODUCTO_NO, DESCRIPCION, PRECIO_ACTUAL, STOCK_DISPONIBLE) VALUES (10,
'MESA DESPACHO MOD. GAVIOTA', 550, 44)
'SILLA DIRECTOR MOD. BUFALO', 670, 15)
'ARMARIO NOGAL DOS PUERTAS', 460, 20)
'MESA MODELO UNIË', 340, 15)
'ARCHIVADOR CEREZO', 1050, 20)
'CAJA SEGURIDAD MOD B222', 280, 15)
'DESTRUCTORA DE PAPEL A3', 450, 16)
'MODULO ORDENADOR MOD. ERGOS', 550, 25)
go
/****** Object: Table EMPLEADOS Script Date: 02/29/2016 19:28:37 ******/
CREATE TABLE EMPLEADOS
(
EMP_NO int NOT NULL,
APELLIDO varchar(8) NULL,
OFICIO varchar(10) NULL,
DIRECTOR int NULL,
FECHA_ALTA datetime NULL,

SALARIO float NULL,
COMISION float NULL,
DEP_NO int NULL,
CONSTRAINT PK_EMPLEADOS_EMP_NO PRIMARY KEY (EMP_NO)
,CONSTRAINT FK_EMP_DEP_NO FOREIGN KEY(DEP_NO)
REFERENCES DEPARTAMENTOS (DEP_NO)
,CONSTRAINT FK_EMP_DIRECTOR FOREIGN KEY(DIRECTOR)
REFERENCES EMPLEADOS (EMP_NO)
)
GO
INSERT EMPLEADOS (EMP_NO, APELLIDO, OFICIO, DIRECTOR, FECHA_ALTA, SALARIO, COMISION, DEP_NO)
VALUES (7499, 'ALONSO', 'VENDEDOR', 7698, '1981/02/23', 1400, 400, 30)
VALUES (7521, 'LOPEZ', 'EMPLEADO', 7782, '1981/05/08', 1350.5, NULL, 10)
VALUES (7654, 'MARTI', 'VENDEDOR', 7698, '1981/09/28', 1500, 1600, 30)
VALUES (7698, 'GARRIDO', 'DIRECTOR', 7839, '1981/05/01', 3850.12, NULL, 30)
VALUES (7782, 'MARTINEZ', 'DIRECTOR', 7839, '1981/06/09', 2450, NULL, 10)
VALUES (7839, 'REY', 'PRESIDENTE', NULL, '1981/11/17', 6000, NULL, 10)
VALUES (7844, 'CALVO', 'VENDEDOR', 7698, '1981/09/08', 1800, 0, 30)
VALUES (7876, 'GIL', 'ANALISTA', 7782, '1982/05/06', 3350, NULL, 20)
VALUES (7900, 'JIMENEZ', 'EMPLEADO', 7782, '1983/03/24', 1400, NULL, 20)
go
/****** Object: Table CLIENTES Script Date: 02/29/2016 19:28:37 ******/
CREATE TABLE CLIENTES
(
CLIENTE_NO int NOT NULL,
NOMBRE varchar(25) NULL,
LOCALIDAD varchar(14) NULL,
VENDEDOR_NO int NULL,
DEBE float NULL,
HABER float NULL,
LIMITE_CREDITO float NULL,

CONSTRAINT PK_CLIENTE_NO PRIMARY KEY (CLIENTE_NO)
,CONSTRAINT FK_CLI_EMP_NO FOREIGN KEY(VENDEDOR_NO)
REFERENCES EMPLEADOS (EMP_NO)
ON DELETE CASCADE
)
GO
INSERT CLIENTES (CLIENTE_NO, NOMBRE, LOCALIDAD, VENDEDOR_NO, DEBE, HABER, LIMITE_CREDITO)
VALUES (101, 'DISTRIBUCIONES GOMEZ', 'MADRID', 7499, 0, 0, 5000)
VALUES (102, 'LOGITRONICA S.L', 'BARCELONA', 7654, 0, 0, 5000)
VALUES (103, 'INDUSTRIAS LACTEAS S.A.', 'LAS ROZAS', 7844, 0, 0, 10000)
VALUES (104, 'TALLERES ESTESO S.A.', 'SEVILLA', 7654, 0, 0, 5000)
VALUES (105, 'EDICIONES SANZ', 'BARCELONA', 7499, 0, 0, 5000)
VALUES (106, 'SIGNOLOGIC S.A.', 'MADRID', 7654, 0, 0, 5000)
VALUES (107, 'MARTIN Y ASOCIADOS S.L.', 'ARAVACA', 7844, 0, 0, 10000)
VALUES (108, 'MANUFACTURAS ALI S.A.', 'SEVILLA', 7654, 0, 0, 5000)
go
/****** Object: Table PEDIDOS Script Date: 02/29/2016 19:28:37 ******/
CREATE TABLE PEDIDOS
(
PEDIDO_NO int NOT NULL,
PRODUCTO_NO int NULL,
CLIENTE_NO int NULL,
UNIDADES int NULL,
FECHA_PEDIDO datetime NULL,
CONSTRAINT PK_PEDIDO_NO PRIMARY KEY (PEDIDO_NO)
,CONSTRAINT FK_PEDIDOS_CLIENTE_NO FOREIGN KEY(CLIENTE_NO)
REFERENCES CLIENTES (CLIENTE_NO)
ON DELETE CASCADE
,CONSTRAINT FK_PEDIDOS_PRODUCTO_NO FOREIGN KEY(PRODUCTO_NO)
REFERENCES PRODUCTOS (PRODUCTO_NO)
ON DELETE CASCADE
)

GO
INSERT PEDIDOS (PEDIDO_NO, PRODUCTO_NO, CLIENTE_NO, UNIDADES, FECHA_PEDIDO) VALUES (1000,
20, 103, 3, '1999/10/06')
50, 106, 2, '1999/10/06')
10, 101, 4, '1999/10/07')
20, 105, 4, '1999/10/16')
40, 106, 8, '1999/10/20')
30, 105, 2, '1999/10/20')
70, 103, 3, '1999/11/03')
50, 101, 2, '1999/11/06')
10, 106, 6, '1999/11/16')
20, 105, 2, '1999/11/26')
40, 102, 3, '1999/12/08')
30, 106, 2, '1999/12/15')
10, 105, 3, '1999/12/06')
30, 106, 2, '1999/12/06')
20, 101, 4, '2000/01/07')
70, 105, 4, '2000/01/16')
20, 105, 6, '2000/01/20')
10, 105, 5, '2007/10/06')
10, 105, 1, '2007/10/06')
20, 105, 5, '2007/10/06')
70, 103, 3, '2007/11/09')

10.9. Parte 1 Capitulo 4
10.9.1. El lenguaje de gestión de base de datos
Obligatorio
NOTA: el objetivo es familiarizarse con una base de datos relacional observando la estructura de las tablas y las
relaciones entre ellas. Estos ejercicios deben realizarse estudiando el contenido de las tablas y la forma de
relacionarse entre ellas
1.- El empleado número 7499 pertenece al departamento número:

a. 30
b. 20
c. 40
2.- El DIRECTOR del empleado 7844 es el empleado número:
a. 7698
b. 7839
c. 7782
3.- El empleado REY es el director de:

a. MARTINEZ
b. GARRIDO
c. MARTINEZ Y GARRIDO
4.- Al departamento de INVESTIGACION pertenecen los empleados:

a. ALONSO Y LOPEZ
b. GIL Y JIMENEZ
c. GARRIDO Y MARTINEZ
5.- El cliente DISTRIBUCIONES GOMEZ pidió cuatro unidades del producto SILLA DIRECTOR
MOD. BUFALO el 7 de enero de 2000:
a. Verdadero
b. Falso, los datos son incorrectos
c. Los datos facilitados son insuficientes para verificar laafirmación
6.- El cliente INDUSTRIAS LACTEAS S.A. ha realizado:

a. Un pedido

b. Dos pedidos
c. Tres pedidos
7.- Sql es un Sistema Gestor de Bases de Datos:

a. Jerárquico
b. En red
c. Relacional
8.- Según el modelo relacional:

a. Cada fila de una tabla representa un atributo o característica
b. Cada columna de una tabla representa un atributo o característica
c. Cada entidad representa un atributo o característica
9.- SQL es:

a. Un lenguaje estructurado de consulta
b. Un lenguaje procedimental de tercera generación
c. Ambas son correctas
10.- El lenguaje SQL permite:

a. Manipular datos (consultar, actualizar, etcétera)
b. Definir objetos de la base de datos (Crear, modificar y eliminar objetos de la basede datos)
c. Ambas son correctas
10.10.Parte 2, Capitulo 4
10.10.1. Elementos del lenguaje
Obligatorio
NOTA: el objetivo es familiarizarse con una base de datos relacional observando la estructura de las tablas y las
relaciones entre ellas. Estos ejercicios deben realizarse estudiando el contenido de las tablas y la forma de
relacionarse entre ellas
Elegir la respuesta correcta de las siguientes cuestiones:
1.- Cuál de los siguientes identificadores no es correcto:
a. xx

b. 2x
c. x2
2.- VARCHAR es:
a. Un comando
b. Un operador
c. Un tipo de dato
3.- Para comparar un dato alfanumérico con un patrón de comparación que contiene
caracteres comodines utilizaremos el operador:
a. IN
b. LIKE
c. =
4.- Siendo el valor de A verdadero (true) y el de B falso (false), el resultado de la expresión A
AND B será:
a. Verdadero (true)
b. Falso (false)
c. Nulo (null)
5.-Siendo el valor de A verdadero (true) y el de B nulo (null), el resultado de la expresión A

AND B será:
a. Verdadero (true)
b. Falso (false)
c. Nulo (null)
6.- Para redondear a dos decimales un número (num) utilizaremos la función:
a. POWER(num,2)
b. TRUNC(num,2)
c. ROUND(num,2)

7.- Para obtener la longitud de una cadena (cad) utilizaremos la función:
a. LPAD(cad)
b. LOWER(cad)
c. LEN(cad)
8.- Para calcular en número de días entre dos fechas (fecha1 y fecha2) utilizaremos la función:
a. DATESUBB(fecha1, fecha2)
b. DATEDIFF( fecha1,fecha2)
c. DUBDATE( fecha1,fecha2)
9.- Para sumar las columnas salario (no puede contener nulos) y comision (si puede contener
nulos) necesitaremos la expresión:
a. salario + comision
b. ISNULL (salario,0) + comision
c. salario + ISNULL(comision,0)
10.- Una condición es:
a. Una variable
b. Un conjunto de datos, operadores y funciones)
c. Un conjunto de datos, operadores y funciones cuyo resultado esverdadero o falso
10.11.1. Consultas sencillas
Obligatorio
Tablas utilizadas: EMPLEADOS y DEPARTAMENTOS
Enunciado
1. Escribir los apellidos de los empleados junto con sus fechas de alta en formato: <<numero
del día>> de <<nombre del mes>> de <<año con 4 dígitos>>
2. Hallar por orden alfabético los apellidos de los empleados, suprimiendo las tres últimas
letras, mostrando solo aquellos cuyo apellido tenga más de seis caracteres
3. Se desea hacer un regalo de un 3% del salario a los empleados que no tienen comisión.
Obtener el listado ordenado por orden alfabético con los apellidos y el importe de los regalos
4. Obtener los datos de los empleados cuyo salario total (salario+comisión) supere los 2.000
euros, siempre que además su salario supere los 1800 euros o su comisión supere los 500
euros
5. Visualizar los datos del empleado de oficio DIRECTOR más antiguo en la empresa.

6. Visualizar los datos de los dos empleados que ganan más salario entre los empleados de los
departamentos 20 y 30
10.12.1. Selección con agrupamientos y funciones de grupo
Obligatorio
Tablas utilizadas: EMPLEADOS, DEPARTAMENTOS, PEDIDOS, PRODUCTOS y CLIENTES.
1. Obtener, para cada departamento, cuantos DIRECTORES hay en el departamento

y cual es su salario medio.
2. Obtener los salarios medios por departamento, ordenados descendentemente por dicho
importe, cuando dichos salarios medios sean inferiores a 3000 euros
3. Obtener el total de unidades por producto que hay entre todos los pedidos,
visualizando el número de producto, la descripción y la suma.
4. Listar los números de cliente que tengan más de dos pedidos, ordenado por
cantidad de pedidos
5. Obtener las localidades en las que haya más de un cliente, visualizando cuantos
clientes hay.
6. Obtener Los datos de los 4 productos de los que más unidades se han vendido, visualizando
el número de producto y las unidades vendidas
10.13.1. Subconsultas
Obligatorio
1. Listar los nombres y códigos de los departamentos en los que haya empleados.
2. Obtener los datos del pedido más reciente.

3. Pare el departamento de VENTAS, visualizar para cada oficio, la suma de los
salarios de los empleados
4. Obtener los datos del producto con más unidades en los pedidos de los clientes.

5. Seleccionar los datos de los pedidos correspondientes al realizado con mayor
cantidad de unidades del mismo producto, visualizándolo para cada producto.
6. Seleccionar los empleados de la empresa que tengan igual comisión que la media de su
oficio
10.14.1. Consultas multitablas
Obligatorio
Enunciado
1. Obtener una lista de los pedidos con la descripción del producto y el nombre del cliente
clasificados por el número del cliente.
2. Obtener los nombres de los empleados y los nombres de sus departamentos, para
aquellos empleados que no son del departamento VENTAS y que entraron en la
empresa después del 1 de enero de 82.
3. Obtener una lista de los apellidos de los vendedores con el importe acumulado de
sus pedidos.
4. Obtener los nombre de los empleados del departamento 30 que son jefes directos
de algún empleado de la empresa, indicando de cuantos empleados son jefes.
5. Realizar un listado de los empleados cuyo oficio es EMPLEADO, que incluirá los
números de empleado, los apellidos y los salarios anuales, sabiendo que el salario
anual es el salario multiplicado por 14, e incluyendo en este listado el nombre del
director del empleado.
6. Visualizar los productos con el número total de pedidos, las unidades totales vendidas, y el
precio unidad de cada uno de ellos incluyendo los que no tienen pedidos (en este caso se
mostrará un 0 en el total unidades vendidas)

10.15.Parte I, Capitulo 5
10.15.1. Actualización de tablas
Obligatorio NOTA: si se quiere hacer pruebas y que las actualizaciones de las tablas no sean validadas, se puede
trabajar con el parámetro AUTOCOMMIT = 0. Así, en cualquier momento, tendremos la posibilidad de hacer ROLLBACK
para deshacer los cambios o COMMIT paravalidarlos.
Enunciado
Para poder trabajar con las tablas creadas en el tema anterior vamos a insertaralgunos valores.
Estas inserciones son indispensables para poder realizar lossiguientes ejercicios
1. Realizar las inserciones de las siguientes filas:

2. Insertar un nuevo artículo con valores
Hacer un listado de las filas de la tabla ARTICULOS (SELECT * FROM articulos;) e

indicar que ha sucedido con las columnas descripcion_articulo y existencias_actuales
razonando la respuesta.
3. Hacer una rebaja del IVA en un punto para cada artículo
4. Modificar la descripción del artículo de referencia 01-LANA para que el nuevovalor sea
LANA 90%NATURAL 10%ACRILICO.
5. Indicar los pasos necesarios para modificar el articulo de referencia 01-LANApara que la
nueva referencia sea 01-LANA90/10.
6. Borrar de la tabla FACTURAS la factura con el valor de factura_no igual a 2.Observar que ha
sucedido en las tablas facturas y líneas de factura. Paracomprobarlo hacer un listado de las filas
10.16."Evaluación I"
10.16.1. Marca la casilla con la respuesta correcta





10.17."Evaluación II"
10.17.1. Marca la casilla con la respuesta correcta






10.18.1. Creación de tablas
Obligatorio
NOTA: No se pueden crear tablas con el mismo nombre que otras ya existentes en la misma base de datos. Si
estuviesen ya creadas con ese nombre, es necesario borrarlas previamente
Definición de las tablas
Enunciado
1. Creación de las tablas con las restricciones.

a. Crear la tabla COMPRADORES con la columna de columna cif_comprador como clave
primaria con nombre PK_COMPRADORES_CIF, y la columna nombre_social única con
nombre UQ_COMPRADORES_NOMBRE_SOCIAL. La columna telefono debe ser obligatoria.
b. Crear la tabla ARTICULOS, con referencia_articulo como PRIMARY KEY con el nombre
PK_ARTICULOS, la columna IVA con valores entre 5 y 25 inclusive y la columna existecias_actuales
con valor por defecto 0.
c. Crear la tabla FACTURAS con la columna factura_no como clave primaria con el nombre
PK_FACTURAS, y la columna fecha_factura tendrá como valor por defecto la fecha 1 de enero de
2005.
d. Crear la tabla LINEAS_FACTURAS con las columnas factura_no y referencia_articulo como

PRIMARY KEY con nombre PK_LINEAS_FACTURA, la columna factura_no como FOREIGN KEY con
nombre FK_LINEAS_FACTURAS referenciando la columna factura_no de la tabla facturas con
borrado en cascada y la columna referencia_articulo como FOREIGN KEY con nombre
FK_LINEAS_ARTICULOS referenciando la columna referencia_articulo de la tabla artículos
2. Añadir a la tabla FACTURAS la columna cod_oficina de tipo numérico de 4 posiciones, con el

número de oficina
3. Añadir en la tabla FACTURAS la columna cif_cliente como FORIEGN KEY con nombre
FK_FACTURA_COMPRADORES referenciando a la columna cif_comprador de la tabla compradores
4. Cambiar en la tabla COMPRADORES el nombre de la columna c_postal por texto_codigo_postal
5. Añadir a la columna cod_oficina de la tabla FACTURAS la comprobación de estar entre 1 y
1000.
10.19.Parte 2, Capitulo 4, Capitulo 5, Capitulo 6, Capitulo 7

10.19.1. Consultas dentro de otras sentencias
Obligatorio
Enunciado
1. Añadir 100 euros de comisión a los empleados tengan una comisión menor de 500 euros o
nula

2. Crear una tabla clientes_producto_20 con las columnas cliente_no y nombre_cliente,

equivalentes a las de la tabla clientes, y unidades_20 equivalente a la de la tabla pedidos, que
contenga las filas de la tabla pedidos correspondientes al producto con número 20.
3. Se quiere borrar al empleado MARTINEZ. Para poder hacerlo sin errores, previamente (en
otra sentencia aparte ejecutada anteriormente) se habrán modificado aquellos empleados de
los que sea jefe MARTINEZ poniéndole como jefe al jefe supremo REY.
4. Actualizar la columna debe de la tabla clientes incluyendo en ella el importe total de los
pedidos realizados por cada cliente
5. Crear la vista EMPLEADOS_GARRIDO que incluirá los datos empleado_no, apellido, salario_anual
de los empleados cuyo jefe es GARRIDO
6. Crear una vista RESUMEN_DEP de los departamentos, incluyendo todos los departamentos
hasta los que no tengan ningún empleado, que permita mostrar la información que se detalla:
Nombre del departamento

Número de empleados
Suma de sus salarios
Suma de sus comisiones
10.20.Parte I, Capitulo 1, Capitulo 2, Capitulo 3

10.20.1. Administración de SQL
Obligatorio
Enunciado
Este ejercicio consiste en hacer una simulación de un error de actuación sobre una base de
datos que obliga al Administrador del servidor de base de datos SQL a iniciar un proceso de
recuperación de los datos a partir de la última copia de seguridad realizada y posteriormente
ejecutar las sentencias almacenadas en el fichero de log para dejar la base de datos
exactamente como se encontraba inmediatamente antes de producirse el error.
Pasos a dar para la ejecución de la práctica.
1. Crea una base de datos para nuestra prueba llamado por ejemplo PRUEBACOPIA y cárgala
con dos tablas a partir del script siguiente:

CREATE DATABASE PRUEBACOPIA;
GO
USE PRUEBACOPIA;
GO
CREATE TABLE DEPARTAMENTOS ( DEP_NO INT(2),DNOMBRE VARCHAR(14),LOCALIDAD
VARCHAR(10),CONSTRAINT PK_DEPARTAMENTOS_DEP_NO PRIMARY KEY (DEP_NO));
INSERT INTO DEPARTAMENTOS VALUES (10, 'CONTABILIDAD','BARCELONA'); INSERT INTO
DEPARTAMENTOS VALUES(20, 'INVESTIGACION','VALENCIA'); INSERT INTO DEPARTAMENTOS
VALUES(30, 'VENTAS', 'MADRID');INSERT INTO DEPARTAMENTOS VALUES(40, 'PRODUCCION',
'SEVILLA');
CREATE TABLE EMPLEADOS (EMP_NO INT (4),APELLIDO VARCHAR(8),

OFICIO VARCHAR(10),DIRECTOR INT(4),FECHA_ALTA DATE,SALARIO FLOAT(6,2),COMISION
FLOAT(6,2),DEP_NO INT (2),CONSTRAINT PK_EMPLEADOS_EMP_NO PRIMARY KEY
(EMP_NO),CONSTRAINT FK_EMP_DIRECTOR FOREIGN KEY (DIRECTOR)REFERENCES
EMPLEADOS(EMP_NO),CONSTRAINT FK_EMP_DEP_NO FOREIGN KEY (DEP_NO)REFERENCES
DEPARTAMENTOS(DEP_NO));
INSERT INTO EMPLEADOS VALUES (7839,'REY','PRESIDENTE',NULL,'1981-11-17',6000.00, NULL,

10);INSERT INTO EMPLEADOS VALUES (7698,'GARRIDO', 'DIRECTOR',7839,'1981-5-1',3850.00, NULL,
30);INSERT INTO EMPLEADOS VALUES (7782,'MARTINEZ','DIRECTOR',7839,'1981-6-1',2450.00, NULL,
10);INSERT INTO EMPLEADOS VALUES(7499,'ALONSO', 'VENDEDOR', 7698,'1981-2-
20',1400.00,400.00,30); INSERT INTO EMPLEADOS VALUES (7521,'LOPEZ', 'EMPLEADO',7782,'1981-5-
8',1350.00, NULL,10);INSERT INTO EMPLEADOS VALUES (7654,'MARTIN', 'VENDEDOR',7698,'1981-9-
28',1500.00, 1600.00, 30);INSERT INTO EMPLEADOS VALUES(7844,'CALVO', 'VENDEDOR', 7698,'1981-9-
8',1800.00, 0, 30);INSERT INTO EMPLEADOS VALUES (7876,'GIL', 'ANALISTA',7782,'1982-5-6',3350.00,
NULL, 20);INSERT INTO EMPLEADOS VALUES (7900,'JIMENEZ', 'EMPLEADO',7782,'1983-3-24',1400.00,
NULL, 20);
2. Crear la copia de seguridad completa de la base datos PRUEBACOPIA del servidor. (Lee
detenidamente el punto DE SEGURIDAD de la Documentación del material).
4. Añadimos algunos cambios a nuestra base de datos de prueba para la comprobación

posterior. (Por ejemplo borramos determinadas filas de una tabla y creamos una tabla nueva
en la base de datos PRUEBACOPIA).

11. Contenido bibliografico
https://angaroasoft.wordpress.com/2011/05/05/instalando-sql-server-2008/
http://vyanez-combas-sca.blogspot.com/2011/09/distintas-ediciones-de-sql-server-2008.html
https://technet.microsoft.com/es-es/library/ms143506(v=sql.100).aspx
http://www.adrformacion.com/cursos/sqls2008/leccion1/tutorial5.html
https://technet.microsoft.com/es-es/library/hh213248(v=sql.110).aspx
https://carlosariash.wordpress.com/2015/01/29/habilitar-conexiones-remotas-en-sql-server-
2012/
http://www.blogdemegastar.com/2010/09/pasos-para-configurar-sql-server-2008.html
http://cjaliaga.net/2012/03/16/tutorial-instalar-sql-server-2008-management-studio/
http://www.adrformacion.com/cursos/sqls2008/leccion2/tutorial1.html
http://www.aulaclic.es/sql/t_5_2.htm
https://sqltitan.com/2013/02/08/limitar-lista-de-bases-de-datos-en-sql-server/
http://www.devjoker.com/contenidos/Tutorial-de-Transact-SQL/238/Procedimientos-
almacenados-en-Transact-SQL.aspx
https://msdn.microsoft.com/es-es/library/aa337545(v=sql.120).aspx

Material Gestion y Consulta en Base de Datos Relacionales

Cargado por

Información del documento

Descripción original:

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

Material Gestion y Consulta en Base de Datos Relacionales

Cargado por

Copyright:

Formatos disponibles

Elaborado por:

Lic. Elvin German

Gota a Gota en las Bases de Datos

Elaborado por: Elvin German

6.1. BASE DE DATOS...................................................................................................................17

6.2. SISTEMA DE GESTIÓN DE BASES DE DATOS.................................................................................17

6.3. GESTOR DE LA BASE DE DATOS.................................................................................................17

6.3.1. DICCIONARIO DE LA BASE DE DATOS.............................................................................................17

6.3.3. LENGUAJE DE DEFINICIÓN DE DATOS (DDL)...................................................................................18

6.3.4. LENGUAJE DE MANIPULACIÓN DE DATOS (DML)............................................................................18

6.3.5. LENGUAJE DE CONTROL DE DATOS (DCL)......................................................................................18

6.3.6. ADMINISTRADOR DE LA BASE DE DATOS........................................................................................18

6.4. USUARIOS DE LA BASE DE DATOS.............................................................................................18

6.5. ESTRUCTURA FISICA..............................................................................................................18

6.5.1. ARCHIVO DE DATOS..................................................................................................................18

6.5.2. NOMBRE DE ARCHIVOS..............................................................................................................19

6.5.3. TAMANO DE LA BASE DE DATOS..................................................................................................19

Elaborado por: Elvin German

6.8. CAMPOS Y REGISTROS...........................................................................................................21

6.10. CONSTRAINTS O RESTRICCIONES.............................................................................................22

6.13. PROCEDIMIENTOS ALMACENADOS..........................................................................................23

6.14. PROGRAMACIÓN CON TRANSACT SQL.....................................................................................23

7. INSTALACIÓN DE SQL SERVER...............................................................................................24

7.2. INSTALANDO SQL SERVER......................................................................................................26

7.3. PROCESO DE INSTALACIÓN......................................................................................................27

8. SQL SERVER CONFIGURATION MANAGER.............................................................................40

9. PLANIFICACION DEL DISEÑO DE LA BASE DE DATOS.............................................................41

9.1. ESTUDIO DE NECESIDADES......................................................................................................42

9.6. INTEGRIDAD DE ENTIDAD........................................................................................................47

9.7. INTEGRIDAD DE DOMINIO.......................................................................................................48

9.8. INTEGRIDAD REFERENCIAL.......................................................................................................49

Elaborado por: Elvin German

9.10. FORMAS DE NORMALIZACIÓN................................................................................................50

9.10.1. FORMA NORMAL A.................................................................................................................51

9.10.2. FORMA NORMAL B.................................................................................................................53

9.11.1. FORMA NORMAL C.................................................................................................................56

9.11.2. CONCLUSIÓN DEL PROCESO DE NORMALIZACIÓN..........................................................................56

9.12.1. HERRAMIENTAS PARA LA NORMALIZACIÓN..................................................................................57

9.14. INTEGRIDAD EN RELACIONES..................................................................................................58

9.14.1. PRIMARY KEY........................................................................................................................58

9.14.2. FOREIGN KEY.........................................................................................................................58

9.14.3. INTEGRIDAD REFERENCIAL EN CASCADA......................................................................................59

9.15. DESENCADENADORES (TRIGUERS)...........................................................................................60

9.16. EJERCICIO 1.......................................................................................................................60

9.17. EJECICIO 2........................................................................................................................60

CAPITULO 2. INICIACIÓN A LA ADMINISTRACIÓN Y DEFINICIÓN DE LA BASE DE DATOS. ............61

2.2. SQL SERVER MANAGEMENT STUDIO........................................................................................61

Elaborado por: Elvin German

2.2.2. REGISTRO DE SERVIDORES..........................................................................................................70

2.2.3. AGRUPAR SERVIDORES..............................................................................................................72

2.2.4. EXPLORADOR DE OBJETOS..........................................................................................................74

2.3. CONECTAR A UN SERVIDOR.....................................................................................................75

2.3.1. CARPETAS DEL EXPLORADOR DE OBJETOS......................................................................................77

2.3.2. PESTAÑA RESUMEN..................................................................................................................79

2.3.3. CARPETAS PRINCIPALES.............................................................................................................80

2.3.4. CARPETA DE BASES DE DATOS.....................................................................................................80

2.3.5. EJERCICIO 1............................................................................................................................82

2.4. DEFINIR LA BASES DE DATOS (CREACIÓN)...................................................................................83

2.5. CÓMO FUNCIONA EL REGISTRO DE TRANSACCIONES......................................................................85

2.6. CONFIGURACIÓN DE LAS OPCIONES DE BASE DE DATOS..................................................................86

2.7. RECUPERACIÓN DE INFORMACIÓN DE LA BASE DE DATOS...............................................................88

2.8. ADMINISTRACIÓN DEL CRECIMIENTO DE LOS ARCHIVOS DE DATOS Y DE REGISTRO................................89