Desarrollo de software

El texto está diseñado para programadores, analistas o técnicos de sistemas que deseen conocer la mecánica de trabajo de las bases de datos a través del uso de una de ellas en concreto: Microsoft SQL Server 2000. Aspectos que se revisan: 1- Conceptos teóricos sobre Bases de Datos. 2- Diseño y modelización de datos tomando como base el modelo Entidad/Relación 3- Generalidades de SQL Server 2000 4- Lenguaje SQL a través de la implementación del mismo en SQL Server 2000 (Transact SQL) 5- Ejemplos de diseño utilizando una herramienta CASE: Power Designor Se requiere como mínimo tener conocimientos del sistema operativo Windows a nivel de usuario. No es imprescindible, aunque si recomendable, conocer fundamentos de programación.

BASES DE DATOS CON SQL SERVER 2000. TRANSACT SQL
JORGE MORATALLA

ADVERTENCIA LEGAL
Todos los derechos de esta obra están reservados a Grupo EIDOS Consultoría y Documentación Informática, S.L. El editor prohíbe cualquier tipo de fijación, reproducción, transformación, distribución, ya sea mediante venta y/o alquiler y/o préstamo y/o cualquier otra forma de cesión de uso, y/o comunicación pública de la misma, total o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio mecánico o electrónico, incluido el tratamiento informático de la misma, en cualquier lugar del universo. El almacenamiento o archivo de esta obra en un ordenador diferente al inicial está expresamente prohibido, así como cualquier otra forma de descarga (downloading), transmisión o puesta a disposición (aún en sistema streaming). La vulneración de cualesquiera de estos derechos podrá ser considerada como una actividad penal tipificada en los artículos 270 y siguientes del Código Penal. La protección de esta obra se extiende al universo, de acuerdo con las leyes y convenios internacionales. Esta obra está destinada exclusivamente para el uso particular del usuario, quedando expresamente prohibido su uso profesional en empresas, centros docentes o cualquier otro, incluyendo a sus empleados de cualquier tipo, colaboradores y/o alumnos. Si Vd. desea autorización para el uso profesional, puede obtenerla enviando un e-mail fmarin@eidos.es o al fax (34)-91-5017824. Si piensa o tiene alguna duda sobre la legalidad de la autorización de la obra, o que la misma ha llegado hasta Vd. vulnerando lo anterior, le agradeceremos que nos lo comunique al e-mail fmarin@eidos.es o al fax (34)-915012824). Esta comunicación será absolutamente confidencial. Colabore contra el fraude. Si usted piensa que esta obra le ha sido de utilidad, pero no se han abonado los derechos correspondientes, no podremos hacer más obras como ésta. © Jorge Moratalla, 2001 © Grupo EIDOS Consultaría y Documentación Informática, S.L., 2000 ISBN 84-88457-24-3

Bases de datos con SQL Server 2000. Transact SQL Jorge Moratalla
Responsable editorial Paco Marín (fmarin@eidos.es) Autoedición Magdalena Marín (mmarin@eidos.es) Jorge Moratalla (jmoratalla@eidos.es) Grupo EIDOS C/ Téllez 30 Oficina 2 28007-Madrid (España) Tel: 91 5013234 Fax: 91 (34) 5017824 www.grupoeidos.com/www.eidos.es www.LaLibreriaDigital.com Coordinación de la edición Antonio Quirós (aquiros@eidos.es)

........................................................................................... 12 VISIÓN GENERAL SOBRE EL DISEÑO DE BASES DE DATOS................................................................................................................................................................................... 15 FASES DEL DISEÑO ................ 29 DISEÑO LÓGICO.......................................................................................................................................................................... 9 DEFINICIÓN DE BASE DE DATOS .................................................................................................................................................... 35 PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA LÓGICO ESTÁNDAR .......................................................................................................................................................................................................................................... 35 INTRODUCCIÓN ..................................................................................................................................................................................................................................................................................................................................................................................................................... 24 EL MODELO ENTIDAD / RELACIÓN ................... 36 ETAPAS EN EL DISEÑO LÓGICO.............................. 10 ARQUITECTURA ANSI/X3/SPARC ................................................................................................................................................................................................................................................................................................................................................................. 17 DISEÑO FÍSICO.......................................... 23 INTRODUCCIÓN ............................................................................ 37 PARTICIONAMIENTO HORIZONTAL DE RELACIONES .................................................. 10 DEL ENFOQUE TRADICIONAL A LOS SISTEMAS DE BASES DE DATOS .......... 9 CONCEPTOS BÁSICOS ................... 24 EJEMPLOS PRÁCTICOS DE DISEÑO CONCEPTUAL........................... 12 EL MODELO RELACIONAL ..... 17 DISEÑO LÓGICO...................................... 21 DISEÑO CONCEPTUAL ..... 5 INTRODUCCIÓN ........................................................................................................................................................... 23 ETAPAS DEL DISEÑO CONCEPTUAL ................... 38 ......Índice ÍNDICE............................ 15 DISEÑO CONCEPTUAL ..............................................................................................................................................................................................................

....................... 65 SOPORTE PARA XML ....... 85 INTRODUCCIÓN ........................................... 68 NUEVAS CARACTERÍSTICAS DE INDEXACIÓN .............. 66 PARTICIONAMIENTO HORIZONTAL DE RELACIONES Y GESTIÓN DE VISTAS DISTRIBUIDAS ......................................................................................................................... 79 MODIFICACIÓN DEL ESQUEMA .......................................... 58 CONCEPTOS BÁSICOS SOBRE GESTIÓN DE FICHEROS ................. 67 INDEXACIÓN DE VISTAS ......................................................................................................................................................................................................................................................................................................................................................................................................................................................................... 81 CREAR UNA NUEVA RELACIÓN ...... 97 TIPOS DE DATOS ......................................... 41 PARTICIONAMIENTO MIXTO ........................................................................................... 58 ORGANIZACIÓN DE FICHEROS ........................................................................................ 67 SOPORTE PARA VIRTUAL INTERFACE ARCHITECTURE (VIA) ................................................ 55 DISEÑO FÍSICO .......... 82 EL ANALIZADOR DE CONSULTAS.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................. 68 REGLAS DE INTEGRIDAD REFERENCIAL EN CASCADA ...................PARTICIONAMIENTO VERTICAL DE RELACIONES .................................................................................................................................................................................................. 63 ORÍGENES...................................................................... 64 SQL SERVER E INTERNET ................................................ 91 EJECUTANDO UNA CONSULTA ................................................................................................................................................................................................................ 69 EL MODELO E/R EN SQL-SERVER 2000 ................................................................................. 75 CREAR UN NUEVO DIAGRAMA ........................................................................................................................................................................................................................................................ 77 RESTRICCIONES E INTEGRIDAD REFERENCIAL ...... 45 EJEMPLOS PRÁCTICOS DE NORMALIZACIÓN ..... 100 BORRADO DE TABLAS .................................................................................................................................................................................................................. 57 ESTRATEGIAS EN EL DISEÑO FÍSICO ....................................... 64 LO NUEVO EN SQL-SERVER 2000 ...................................................................................................................... 67 NUEVOS TIPOS DE DATOS ........................................................................................................................................................ 68 SOPORTE PARA CONSULTAS DISTRIBUIDAS .................................................................................................. 101 CREACIÓN Y BORRADO DE ÍNDICES ................................ 49 PROCESO DE DESNORMALIZACIÓN ............ 68 INSTALACIÓN DE SQL SERVER 2000 ................................................................................................................................................................................................................................................................. 65 NUEVAS CARACTERÍSTICAS ......................................................................................................... 92 EL LENGUAJE DE DEFINICIÓN DE DATOS (DDL) ....................................................................... 99 MODIFICACIÓN DE TABLAS ............................................................................................................................. 67 NUEVOS TRIGGERS ......................................................................................................................................... 59 TÉCNICAS PARA EL AUMENTO DE EFICIENCIA .............. 67 FUNCIONES DE USUARIO .. 101 .......................... 63 ¿QUÉ ES SQL SERVER?......................................... 59 INTRODUCCIÓN A SQL SERVER ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... 68 CARACTERÍSTICAS DE SEGURIDAD Y CIFRADO DE DATOS ............................................................................................................................................................................... 44 TEORÍA DE LA NORMALIZACIÓN ........................................... 57 INTRODUCCIÓN ......................... 75 INTRODUCCIÓN ......................................... 97 CREACIÓN DE TABLAS ...................... 85 LA BARRA DE HERRAMIENTAS .............................................................. 97 INTRODUCCIÓN .................... 85 LAS OPCIONES DE MENÚ ............................................................................................................................................................................. 65 INTRODUCCIÓN .................

.................................................................................................................................... 137 SENTENCIAS ITERATIVAS ......................................................................................................... 139 SINTAXIS ........................................................... 149 LAS FUNCIONES DE AGREGADO ........... 122 LA SENTENCIA UPDATE .................................................................................................................................................................................................................................................................................................. 112 LA SENTENCIA DROP INDEX................................................................ 123 LA SENTENCIA DELETE .................................................................................................................................................................................................... 103 INTRODUCCIÓN .................................................................................................................................................................................................................................................................. 135 SENTENCIAS CONDICIONALES.................................................... 139 EJEMPLOS.................................................. 119 LA SENTENCIA INSERT .................................................................................................................................................................................................. 157 INTRODUCCIÓN ..................................................................................................... 125 INTRODUCCIÓN ................................................................................ 111 LA SENTENCIA CREATE INDEX............................................... 117 LA CLÁUSULA GROUP BY ............ 125 OPERADOR PROYECCIÓN ......................................................................... 119 FUNCIONES ESCALARES PARA SELECT .............................................................................................................................................................................................. 151 LA CLAÚSULA GROUP BY ..................................................................................................... 140 CARGA DE LA BASE DE DATOS DE EJEMPLO ................................................. 157 LA SENTENCIA DELETE .............................................................................................................................................................. 165 EJEMPLOS.............................................................................. 103 LA SENTENCIA ALTER TABLE ................................. 163 INTRODUCCIÓN .............. 166 PROCEDIMIENTOS ALMACENADOS Y TRIGGERS .......................................................................... 147 LA CLAÚSULA WHERE ........................................................................................ 127 OPERADOR JOIN ............................................................................................................................................................................................................. 123 OPERADORES BÁSICOS Y CONSIDERACIONES DEL LENGUAJE ... 125 OPERADOR UNION ........................................................................................................ 139 INTRODUCCIÓN .................................................................................................................................................................................................... 164 LA SENTENCIA TRUNCATE TABLE............................................................................................................................................................................................................................... 119 LA CLÁUSULA ORDER BY ................................... 112 EL LENGUAJE DE MANIPULACIÓN DE DATOS (DML) ........................................................................................ 132 VARIABLES GLOBALES.............................................................................................. 103 LA SENTENCIA CREATE TABLE ...................... 118 LA CLÁUSULA HAVING ........................................ 163 LA INTEGRIDAD REFERENCIAL........................................................................ 157 EJEMPLOS................................................................................................................................................................................................................................................................................................................................................................................................................................................ 147 INTRODUCCIÓN .........................................................EJEMPLOS PRÁCTICOS DE USO DEL DDL.............................................. 143 LA SENTENCIA SELECT.............................................................. 128 OPERADORES PROPIOS DE TRANSACT SQL ................................................................................................ 115 LA SENTENCIA SELECT ...................................................................................................................................................................................... 115 INTRODUCCIÓN .............................................................................................................................................................................. 169 7 .......................................................................................................................................................................................................................................................................................... 154 LA SENTENCIA UPDATE .............. 138 LA SENTENCIA INSERT............................................................................... 148 EL OPERADOR JOIN .............................................. 169 INTRODUCCIÓN ...................................................................................................................... 115 LA CLÁUSULA WHERE .............................................................................................. 107 LA SENTENCIA DROP TABLE ............

............................. 208 CREACIÓN DE RELACIONES .................................................... 179 EJECUCIÓN DINÁMICA DE SENTENCIAS: LA INSTRUCCIÓN EXEC ............................. 173 TRIGGERS .......................................................................................................... 219 ATRIBUTOS EXTENDIDOS .......................................................................................... 182 TRIGGERS EN SQL-SERVER 2000 ............. 184 RESOLUCIÓN DIFERIDA DE NOMBRES .................................................................................................................................................................................................................................................... 183 INTRODUCCIÓN ... 189 CONCESIÓN DE PRIVILEGIOS ............................ 180 CONVERSIÓN DE TIPOS..................................................................................................................................................................................... 207 INTRODUCCIÓN ......................................................................................................... 193 MANTENIMIENTO DE VISTAS .................................................................................... 183 LAS TABLAS DELETED E INSERTED .................................................................................................................................................................................................. 221 TRIGGERS ....................................................................................... 195 INTRODUCCIÓN .................................................................. 222 EJEMPLO DE DISEÑO CON POWER DESIGNOR............................................................................................................................................................................................... 184 LIMITACIONES DE LOS TRIGGERS ................................................................. 189 INTRODUCCIÓN ....................................................................................................................................................................................................................................................................................................................................................................................................... 225 ........................................... 196 LENGUAJE DE MANIPULACIÓN DE DATOS ............................................................................... 177 LA SENTENCIA CASE .................................................... 174 EJEMPLOS PRÁCTICOS DE USO DE PROCEDIMIENTOS ALMACENADOS ..................................................... 198 PRESENTE Y FUTURO DE LAS BASES DE DATOS .......................................................................... 189 REVOCACIÓN DE PRIVILEGIOS ................................................. 218 COLUMNAS .............................................................................................................................. ELSE................................................................ 217 MODIFICACIÓN DE LAS TABLAS ........................ 191 DENEGACIÓN DE PERMISOS ....................................................................................................................................................................................................................................................................................... 177 INTRODUCCIÓN ...................................................................................................................................................................................... 177 LA SENTENCIA IF ......................................... 195 LENGUAJE DE DEFINICIÓN DE DATOS.............................................................................PARÁMETROS POR REFERENCIA ........................................ 181 LA SENTENCIA WHILE..................................... 217 PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA FÍSICO .......................................................................... 194 EJEMPLO PRÁCTICO DE IMPLEMENTACIÓN........................................................................................................................................................................................ 203 DISEÑO CONCEPTUAL CON POWER DESIGNOR................................................... 215 DISEÑO FÍSICO CON POWER DESIGNOR .......................................................................................................... 185 SEGURIDAD ...................................................................................................................................................................................................................................................... 213 LA RELACIÓN DE HERENCIA............. 170 PROCEDIMIENTOS ALMACENADOS DE SISTEMA.................................................................... 184 TIPOS DE DESENCADENADORES ............ 219 INDICES ................................................................................................................................................................................................................ 193 RECOMENDACIONES .................................... 185 EJEMPLOS........................................................................................................................................................................................................................................................................................ 222 CREACIÓN DE VISTAS ..................................................... 207 CREACIÓN DE UNA ENTIDAD .......................................................... 221 RESTRICCIONES........................................................................................................ 172 EXTENDED STORED PROCEDURES ..........................

(Howe. de la mejor manera posible. 1977). "Conjunto de datos de la empresa memorizado en un ordenador. que es utilizado por numerosas personas y cuya organización está regida por un modelo de datos". debe poder servir para toda una gama de usos y aplicaciones". (Conference des Statisticiens Européens. Existen varias definiciones para responder a esta pregunta: • "Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias. (Martin. tienen una definición y descripción comunes y están estructurados de una forma particular. "Colección no redundante de datos que son compartidos por diferentes sistemas de aplicación". como tal.Introducción Definición de base de datos La primera pregunta que surge a la hora de comenzar este curso es la siguiente: ¿Qué es una Base de Datos?. (Flory. 1975). "Colección o depósito de datos. 1982). (Delobel. su finalidad es servir a una aplicación o más. "Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador para satisfacer simultáneamente a varios usuarios de forma selectiva y en tiempo oportuno". • • • • . Una base de datos es también un modelo del mundo real y. donde los datos están lógicamente relacionados entre sí. 1983). los datos se almacenan de modo que resulten independientes de los programas que los usan. 1982). se emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados".

el concepto de base de datos ha ido cambiando a lo largo del tiempo. se ha de apoyar en un modelo de datos. podemos encontrarnos con los siguientes problemas: • Producción de inconsistencias o incoherencias. • • • • Del enfoque tradicional a los sistemas de bases de datos Para comprender mejor las diferencias entre los sistemas tradicionales basados en ficheros y los sistemas de bases de datos. uno para la emisión de facturas. añadimos dos ficheros. En la actualidad podemos establecer la definición de base de datos como sigue. a la cual denominamos esquema. construidos. "Colección de datos interrelacionados". El esquema no varía mientras no varíe el mundo real que éste describe. (Elsmari y Navathe. junto con la base de datos y con los usuarios. y su definición (estructura de la base de datos) única y almacenada junto con los datos. Ocurrencia del esquema: Conjunto de datos que se encuentran almacenados en el esquema en un momento determinado. "Conjunto de ficheros maestros. "Colección o depósito de datos integrados. 1989). y otro para la emisión de informes. procesar. Modelo de datos: Conjunto de conceptos que permiten describir. Sistema de Información: Colección de personas. estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios". registrar. debido a la replica de información (la misma información puede estar almacenada en distintos ficheros).Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • "Colección integrada y generalizada de datos. procedimientos y equipos diseñados. (Frank. ciudad. Esquema de una Base de Datos: Estructura de la Base de Datos. deben mantenerse independientes de ellos. almacenados en soporte secundario (no volátil) y con redundancia controlada. constituyen el Sistema de Base de Datos. Los procedimientos de actualización y recuperación. pongamos un ejemplo. comunes y bien determinados. a distintos niveles de abstracción. almacenar y recuperar esa información. Conceptos básicos • Sistema de Gestión de Base de Datos (SGBD): Conjunto de programas que permiten la implantación. mientras que una ocurrencia del esquema es distinta en el transcurso del tiempo. acceso y mantenimiento de la base de datos. dirección. organizados y administrados de una manera flexible de modo que los ficheros puedan ser fácilmente adaptados a nuevas tareas imprevisibles". Supóngase que disponemos de un archivo maestro de clientes con la siguiente información: nombre. 1985). la estructura de una base de datos. facilitarán la seguridad del conjunto de los datos". • • Como se ha visto. 10 . Si además de esto. (Deen. que han de ser compartidos por diferentes usuarios y aplicaciones. el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. 1988). Los datos. operados y mantenidos para recoger. provincia y teléfono. El SGBD.

5. Implantación larga y difícil: Debido a las causas mencionadas anteriormente. 2. Independencia entre datos y tratamientos. o ampliaciones de las existentes) como en el lógico (sistemas operativos. implica una menor ocupación de almacenamiento secundario. creyendo que constituyen ya una realidad. Instalación costosa: La implantación de un sistema de base de datos puede implicar un coste elevado. los Sistemas de Bases Datos no están exentos de inconvenientes. hacen llevarse a engaño a muchos usuarios. Desfase entre teoría y práctica: Los constantes avances teóricos en al ámbito de las bases de datos. etc. sino a medio.). 4. Mayor eficiencia en la recogida. 2.© Grupo EIDOS 1. se hace necesario una completa reestructuración de dicho fichero. Más adelante veremos cómo se permite una cierta duplicidad de datos. 6. • • Malgasto de memoria secundaria (por el mismo motivo). tanto en el equipo físico (adquisición de nuevas instalaciones. Reducción del espacio de almacenamiento: La desaparición (o disminución) de redundancias. El cambio en los programas no influye en la disponibilidad de los datos. implica una rentabilidad no a corto. se evitan los problemas que puede ocasionar la redundancia. Introducción. sin mencionar el rediseño del código de la aplicación. controlada por el sistema y que no afecta a la redundancia lógica. la implantación de un sistema de base de datos puede convertirse en una tarea larga y complicada. Coherencia de resultados: Debido a que los datos son almacenados una sola vez. Mayor valor informativo: El conjunto de los datos almacenados en la BD ofrece un mayor valor informativo. A pesar de todas estas ventajas. o incluso largo plazo. En cambio. estos problemas no tienen cabida. para dar cabida a este cambio. que muchas veces no se ven traducidos en la práctica. 3. los datos se recogen y validan una sola vez. compiladores. Algunas de las ventajas que ofrece utilizar un Sistema de Bases de Datos son las siguientes: 1. unido a las técnicas de compactación. programas. siempre que estén autorizados a ello. Falta de rentabilidad a corto plazo: Los amplios costes que conlleva la implantación. Aquí se detallan los más importantes: 1. así como el coste de adquisición o mantenimiento del SGBD. Mejor disponibilidad de datos para los usuarios: Los datos son compartidos por un conjunto de usuarios. en un sistema de gestión de bases de datos. Escasa estandarización: Esto supone una dificultad añadida a los usuarios de la base de datos. que accede a ellos de forma concurrente. Si en este momento se quiere añadir en número de fax. 11 . cuando no han sido todavía plasmados. que la suma de ellos independientemente. 3. validación e introducción de los datos en el sistema: Al no existir redundancia. con el fin de conseguir una mayor eficiencia. aumentando así la eficiencia. así como la modificación de éstos no afecta a la reprogramación de las aplicaciones que los usan. 5. ya que el control de la información es inherente al propio sistema. 4.

Dicho modelo se basa en la representación de la información por medio de estructuras tipo tabla. Por lo tanto. El modelo conceptual. o poder acceder a ellos. nombre. número de éstas. técnicas de compresión de datos. ya que si se sabe el valor de dicho atributo. Cada fila representa la información para cada ocurrencia de una determinada entidad. como ya se verá más adelante. cuales son los datos. se puede saber a que empleado nos estamos refiriendo. o acelerar las consultas / actualizaciones. en dar valores para cada uno de los atributos de la entidad. Nivel Externo: Es el nivel más cercano a los usuarios. Cada usuario puede tener su propio modelo externo. En este nivel. apellidos. radica en la facilidad y en su amplia base matemática. Nivel Interno: Nivel más bajo en la abstracción. La información que se desea saber de cada empleado es su código. como por ejemplo el derecho a insertar o borrar determinados datos. es decir. 2. tamaño de los buffers. las estrategias de acceso a los datos. Cada atributo o conjunto de atributos que identifica unívocamente a cada tupla de la relación se denomina clave. es el modelo relacional. como por ejemplo dispositivos de memoria a usar (tamaño de páginas. criptografiado. también deberán definirse las restricciones de uso. Las claves se representan subrayando el / los atributo/s que forman parte de ella. dentro del Comité X3 que se ocupa de ordenadores e informática. de los que interesa conocer su valor. y en el se definen los datos tal y como los va a ver este. etc. y para cada uno de ellos existirá un valor (cabe la posibilidad de que existan atributos en los que no aparezca ningún valor). como están organizados. que almacena información sobre los empleados de una empresa. El modelo relacional El modelo más usado. 12 . con aquellos datos e interrelaciones que dicho usuario necesite.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Arquitectura ANSI/X3/SPARC ANSI/X3/SPARC es un grupo de estudio del Standard Planning and Requirements Commitee (SPARC) del ANSI (American National Standars Institute). que es único. Describe la estructura almacenamiento físico de los datos. La información se descompondrá. Además. El modelo interno. corresponde a la implementación del modelo conceptual. Nivel Conceptual: Proporciona una descripción global del esquema independiente de la estructura física de la base de datos. es decir. 3. las relaciones entre ellos y las restricciones de integridad y confidencialidad. su sueldo y su categoría. para evitar cierto tipo de anomalías. denominadas relaciones. y que almacenan información para una determinada entidad. propugnaron una arquitectura basada en tres niveles de abstracción: 1. los atributos son cod_empleado. El motivo de que sea éste el modelo más extendido. El siguiente ejemplo (Figura 1) representa una relación denominada empleado. para cada entidad. Cada una de estas relaciones representa en sus columnas los valores significativos. el atributo cod_empleado es clave de la relación. lo que permitirá. y por lo tanto el que se estudiará en este curso.). su nombre y apellidos. En sus estudios acerca de los SGBD. A dichas filas también se las denomina tuplas. etc. que es único. Así mismo especifica todos los aspectos relacionados con el hardware. sueldo y categoría. etc. como ya se ha dicho. el poder estructurar o reestructurar las relaciones. Dichas columnas se denominan atributos. establece el modelo teórico sobre el que están asentados los modelos externos.

Figura 1 13 . Introducción.© Grupo EIDOS 1.

.

Ser un servidor operacional y eficiente de los datos. lógico y físico). .Visión general sobre el diseño de bases de datos Fases del diseño El diseño de una base de datos suele descomponerse en tres grandes fases (diseño conceptual. Una vez elegido el modelo lógico. lo que permite reducir la complejidad que entraña el diseño. Un esquema conceptual es una descripción a alto nivel de la estructura de la base de datos. y produce como resultado el esquema conceptual de la base de datos. a la vez que ayuda a alcanzar los dos principales objetivos que tienen las bases de datos: • • Ser una representación fidedigna del mundo real. Un esquema lógico es la descripción de la estructura de la base de datos que puede procesarse por un SGBD. El diseño lógico parte del esquema conceptual y genera el esquema lógico. independientemente de la elección del equipamiento y del Sistema Gestor de Base de Datos (en adelante referido como SGBD) que se usen para la implementación de la base de datos. El diseño conceptual parte de la especificación de requerimientos. La meta del diseño lógico es producir el esquema lógico más eficiente con respecto a las operaciones de consulta y actualización. pueden existir un conjunto de esquemas lógicos equivalentes al mismo esquema conceptual.

Correspondencia entre el diseño y la arquitectura ANSI/X3/SPARC 16 . esquema que proporciona una descripción estable de la base de datos (independiente del SGBD) que se vaya a utilizar. Diseño de una base de datos En la Figura 2 se resumen las tres grandes fases del diseño de una base de datos: primero se diseña el esquema conceptual (que se realiza con un modelo conceptual de datos). Figura 2. describe las estructuras de almacenamiento y los métodos de acceso para acceder a los datos de una manera eficiente. por último se eligen las estructuras de almacenamiento. posteriormente se pasa del esquema conceptual al modelo de datos propio de SGBD elegido (diseño lógico). Figura 3. los caminos de acceso (índices). Un esquema físico es una descripción de la implementación de la base de datos en memoria secundaria. y todos los aspectos relacionados con el diseño físico.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS El diseño físico toma como punto de partida el esquema lógico y como resultado produce el esquema físico. Por ello. el diseño físico se genera para un SGBD y un entorno físico determinado.

Conceptualización: En esta etapa se intenta responder a la pregunta: ¿cómo representar?. Visión general sobre el diseño de bases de datos. si se tiene en cuenta el segundo de los objetivos mencionados anteriormente. consistente en la estructuración de las relaciones atendiendo a consideraciones de tipo lógico. en el que priman las consideraciones de eficiencia. La Figura 4. Diseño conceptual El objetivo del diseño conceptual. mediante distintas técnicas. En la Figura 4. conjunto de información que puede ser accedida por un usuario) y lógico (estructura de tablas y restricciones) de la arquitectura ANSI/X3/SPARC. Esta reestructuración toma como entrada el esquema relacional estructurado obtenido anteriormente. A su vez. y que constituye la primera fase de diseño. lo que implica una descripción de los datos mediante el uso del lenguaje natural. que deberá ser expresado sin tener en consideración cuestiones de implementación. en la que una vez estructurado el esquema origen. El diseño conceptual es una etapa previa al diseño lógico. con el fin de mejorar la eficiencia de la base de datos. al que se añaden las claves ajenas y otras restricciones de integridad. Consiste en ir refinando sucesivamente el primer esquema descriptivo. En la práctica a veces es preciso proceder a una reestructuración de las relaciones. El diseño físico se corresponde con el nivel físico de dicha arquitectura. se hace necesaria una reestructuración de relaciones. La Figura 3 muestra la correspondencia existente entre las fases de diseño y los niveles de la arquitectura ANSI/X3/SPARC. es decir. Se pretende en esta etapa elaborar un esquema descriptivo del mundo real. también denominado modelo conceptual. con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador.© Grupo EIDOS 2. aunque la más usada es la de entrevistas a los usuarios. • Diseño lógico El objetivo del diseño lógico es transformar el esquema conceptual obtenido en la fase anterior. se detallan las dos etapas en las que se divide la fase de diseño lógico. se obtiene un esquema relacional. el de que la base de datos ha de ser un servidor operacional y eficiente de los datos. obteniendo de esta manera un esquema relacional resultante. analizando diferentes factores como las distintas dependencias o la posibilidad de existencia de valores nulos. incluye 17 . La primera. se irán refinando hasta obtener el esquema conceptual. debe ser independiente del SGBD a usar. la normalización no cubre toda esta fase. resume la fase de diseño lógico. así como el análisis de los requisitos de determinadas vistas o aplicaciones críticas. Sin embargo. Ahora bien. Consta de dos fases: • Análisis de requisitos: Es en esta etapa donde se debe responder a la pregunta: ¿qué representar?. Los problemas que presenta esta primera especificación. adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar. mostrándose insuficiente para alcanzar todos los objetivos de la misma. el diseño lógico se corresponde con los niveles externo (donde se definen las vistas de usuario. para conseguir pasar del mundo real al esquema descriptivo y de éste al esquema conceptual. es decir. El modelo relacional es el único modelo que ha permitido abordar la fase de diseño lógico aplicando una teoría formal: el proceso de normalización. es obtener una buena representación de los recursos de información de la empresa.

los cuales no ofrecen los adecuados instrumentos de diseño físico. tomando como entrada un esquema relacional origen con todas sus dependencias. mientras que en la segunda se reestructuran las relaciones teniendo en cuenta consideraciones de tipo físico que pueden llevar a la desnormalización.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS la normalización. así como el particionamiento horizontal de las mismas cuando sea necesario. vertical o mixto. etc. obligando a trasladar a la fase de diseño lógico consideraciones de eficiencia que deberían ser ajenas a dicha fase. un esquema normalizado. Las herramientas para llevar a cabo este objetivo son dos: 18 . valores inaplicables. o al particionamiento horizontal. La razón de esta etapa de reestructuración se encuentra en la falta de flexibilidad de la estructura interna de los actuales SGBD. por razones lógicas. Figura 4. En esta etapa de estructuración se conseguirá. Estructuración y reestructuración de relaciones El objetivo de la estructuración de relaciones es obtener un esquema relacional estructurado. seguido de la proyección. en el cual se han eliminado los valores nulos (inaplicables) mediante un particionamiento horizontal basado en la selección.

Figura 6. Sin embargo. Normalización de relaciones El particionamiento horizontal de relaciones. mediante un proceso de normalización. en varias relaciones en las que los valores nulos inaplicables no tienen cabida. esto no quiere decir que las relaciones que se vayan a almacenar en la base de datos sean las resultantes de estos procesos. Particionamiento horizontal de relaciones El objetivo de la reestructuración es el de mejorar la eficiencia de la base de datos. seguido de proyecciones sobre las relaciones resultantes. que representan la misma información que la relación origen.© Grupo EIDOS 2. pero puede que no el segundo: el de que la base de 19 . como se muestra en la Figura 5. El resultado de este particionamiento horizontal será la división de una relación en la que existen o pueden existir valores nulos. así como eliminar los valores nulos mediante un proceso de particionamiento horizontal. permite eliminar valores nulos inaplicables que pueden aparecer en las relaciones mediante un proceso de selección. Visión general sobre el diseño de bases de datos. En la primera etapa de estructuración de relaciones. normalizar el esquema. • • El proceso de normalización El particionamiento horizontal de relaciones El proceso de normalización consiste en sustituir una relación por un conjunto de esquemas equivalentes. se ha propugnado por razones lógicas. en la que una relación origen ha sido sustituida por otras dos. ya que se ha logrado el primero de los objetivos de las bases de datos (ser una representación fidedigna del mundo real). pero que no presentan cierto tipo de anomalías a la hora de realizar operaciones sobre ella. Figura 5.

mediante un proceso de desnormalización. Desnormalización de relaciones El particionamiento de relaciones es otra forma de conseguir una mayor eficiencia en la base de datos. el coste de proceso de transacciones se minimiza incrementando el proceso local de las transacciones (en un "nodo") así como reduciendo el número de accesos a objetos de datos que no son locales. ya que cada subconjunto puede ubicarse en distintos nodos de la red. y en la división de datos entre diferentes niveles de jerarquías de memoria. El particionamiento vertical también puede usarse en la partición de tablas individuales en bases de datos centralizadas. Por ello. o mixta (incluye ambas). considerando esta idea de mejora de la eficiencia. dividirla en otras relaciones de forma horizontal. A cada una de estas formas de particionamiento se la denomina. Estos fragmentos se colocan en diferentes localizaciones de la base de datos distribuida. el objetivo del particionamiento vertical es crear fragmentos verticales de una relación de manera que minimice el coste de acceso a los elementos de datos durante el procesamiento de la transacción. acercándose al lugar de su tratamiento. que son: • • El proceso de desnormalización El particionamiento de relaciones El proceso de desnormalización es justamente el proceso inverso al de normalización. muestra un ejemplo en el que dos tablas previamente normalizadas. etc. 20 . o vertical. los atributos de una relación R son distribuidos en grupos no solapados y la relación R se proyecta en relaciones fragmentarias de acuerdo a estos grupos de atributos. Si los fragmentos se ajustan bien a los requisitos del conjunto de transacciones facilitado. En el caso de bases de datos distribuidas. particionamiento vertical y particionamiento mixto. La Figura 7. particionamiento horizontal. respectivamente. El particionamiento horizontal de relaciones consiste en la división de las tuplas de una relación en subconjuntos. Para lograr este objetivo existen diversos métodos o formas de organizar los datos. Esto es muy útil cuando existen consultas que acceden sólo a determinada parte de la información dependiendo del valor de algún atributo. Figura 7. dan origen a una tabla más grande (que es justamente la tabla que se tenía antes de realizar la normalización). entonces el coste de proceso de las transacciones podría ser minimizado.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS datos ha de ser un servidor operacional y eficiente de los datos. En el particionamiento vertical. por lo que se hace necesaria esta segunda etapa en el diseño lógico. El objetivo de este proceso es dada una relación. o en bases de datos distribuidas.

Como su propio nombre indica. es conseguir una instrumentación lo más eficiente posible del esquema lógico. Esto obliga a iterar desde la fase de diseño físico a la de diseño lógico. Por ello el diseño físico se genera para un SGBD y un entorno físico determinado. Diseño físico El objetivo del diseño físico.© Grupo EIDOS 2. describe las estructuras de almacenamiento y los métodos de acceso para acceder a los datos de una manera eficiente. lo que explica la obligación de la etapa de reestructuración en el diseño lógico. hasta obtener conseguir los objetivos anteriormente expuestos. el particionamiento mixto engloba a ambos tipos de particionamiento (horizontal y vertical). que es la última fase del proceso de diseño. que deberían ser ajenos a dicha fase. o viceversa. Como resultado del diseño físico se genera un esquema físico. requisitos de procesos. del SO y en general. Visión general sobre el diseño de bases de datos. aspectos de carácter físico. características del SGBD. y viceversa. Con ello se persigue: • • • • • disminuir los tiempos de respuesta minimizar espacio de almacenamiento evitar las reorganizaciones proporcionar la máxima seguridad optimizar el consumo de recursos El principal problema que se plantea en la fase de diseño físico es el debido a la poca flexibilidad de los actuales SGBD. Consiste en aplicar un particionamiento vertical a uno o más de los fragmentos obtenidos mediante un particionamiento horizontal. los cuales obligan a trasladar a la fase de diseño lógico. cualquier factor cercano a la "maquina". 21 . Aquí se tienen en cuenta aspectos del hardware. que es una descripción de la implementación de la base de datos en memoria secundaria.

.

tiende a ser no tenido en cuenta a la hora de proceder al diseño de una base de datos. De ahí la importancia de realizar un buen esquema conceptual. que represente fielmente las características del mundo real. el diseño conceptual. se pueden establecer las siguientes características que debe cumplir un buen esquema conceptual: Debe representar fielmente la información del mundo real • • Es independiente del SGBD Es independiente del Hardware . sino que es un paso previo. o no representa fielmente la información del mundo real. que constituye la primera etapa en el diseño de una base de datos. el esquema de la base de datos no será estable. Puesto que no se corresponde con ningún nivel de la arquitectura ANSI/X3/SPARC. ya que el diseño lógico parte del esquema conceptual y. el esquema conceptual debe representar la información fuera de consideraciones sobre hardware y sobre el SGBD sobre el que se implementará. si éste no es correcto. Como ya se ha dicho. Otro error que se suele cometer en esta etapa de diseño es el de considerar aspectos tales como la eficiencia del equipo hardware en el que se vaya a montar la base de datos. Por lo tanto. consiste en obtener una buena representación de los recursos de información de la empresa. viéndonos obligados a reajustarlo constantemente debido a las deficiencias arrastradas desde esta etapa de diseño. Esto no es aconsejable. o SGBD's concretos.Diseño conceptual Introducción Como ya se ha visto en el tema anterior. con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador.

A continuación se describirá el proceso de creación de un esquema conceptual. En ellos define dicho modelo como una vista unificada de los datos. Aunque existen muchas respuestas sobre el modo de recoger dicha información. en el que se provean detalles de los datos a representar. las relaciones existentes entre las distintas entidades. la más utilizada es el lenguaje natural que. simplicidad. etc. Dicho esquema se obtiene mediante el estudio u observación del mundo real (estudio de las reglas de la empresa. centrándose en la estructura lógica y abstracta de los datos. siguiendo el modelo E/R. entrevista a los usuarios. Posteriormente se fueron proponiendo nuevas aportaciones al modelo. puede subdividirse a su vez en dos etapas: 1. que es el más utilizado hoy en día. lo cual explica que no exista uno sólo. la única forma de hacerlo. que un buen diseño del esquema conceptual. Al utilizar una representación de este tipo. 2. Los objetivos que debe cumplir un esquema conceptual son los siguientes (Piattini y De Miguel): 1. En ella se transforma el esquema obtenido en la primera. Los elementos de los que se componen son los siguientes: 24 . Aislar la representación de la información de los requisitos de máquina y exigencias de cada usuario en particular 3.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Conviene no olvidar. hasta llegar al esquema conceptual. 2. con independencia de consideraciones de tipo físico. que se apoye en un modelo de datos que cumpla determinadas propiedades (según Piattini y De Miguel): coherencia.). El modelo que se estudiará es el Modelo Entidad / relación (en adelante referido como ME/R o modelo E/R). Existen muchas formas de representarlo. fidelidad. Captar y almacenar el universo del discurso mediante una descripción rigurosa. permite una mejor y más fácil comprensión de la información por parte del usuario. Chen en dos artículos que publicó en los años 1976 y 1977. influirá positivamente en el resto de etapas. Etapas del diseño conceptual La fase de diseño conceptual. no redundancia. como representación del mundo real. etc. Se deberá obtener el esquema conceptual mediante una representación normalizada. mediante refinaciones sucesivas. sino distintos modelos según los autores. El objetivo es elaborar un esquema descriptivo de la realidad. plenitud. por lo tanto. El modelo entidad / relación El modelo E/R fue propuesto por Peter P. Etapa de análisis de requisitos: En esta etapa se debe responder a la pregunta "¿Qué representar?". el modelo E/R permite distinguir fácilmente y a simple vista. Independizar la definición de la información de los SGBD en concreto. Éste se basa en una representación gráfica de una serie de entidades relacionadas entre sí. aunque carece del formalismo que pueden infligir otros métodos. por supuesto. la que se utilizará aquí no es. Este primer esquema percibido bruto (como lo llaman Benci y Rolland). y le permite especificar los requisitos sin la intervención de formalismos. Etapa de conceptualización: En esta etapa se debe responder a la pregunta "¿Cómo representar?". se ira refinando sucesivamente. como ya se ha comentado.

En el modelo E/R. Los atributos de una entidad se colocan dentro del rectángulo que representa dicha entidad. cosa. un atributo clave se representa subrayando dicho atributo. podemos tener una relación entre ellas. En nuestro ejemplo. Clave: La clave de una entidad es un atributo o conjunto de atributos de dicha entidad. de interés para la empresa" (ANSI 1977). seremos capaces de identificar de que automóvil estamos hablando. modelo o color. con el nombre de dicha entidad escrito en la parte superior. justo debajo del nombre de ésta. Relación: Una relación representa. con sólo conocer el valor del atributo matrícula. Diseño conceptual 1. se puede decir que un automóvil tiene las siguientes características: nº de matricula. Por ejemplo. si conocemos el valor de dichos atributos. 25 . Atributos: Un atributo es cualquier característica que describe a una entidad. una correspondencia entre dos entidades. lugar. que son capaces de identificar unívocamente una ocurrencia de una entidad. hace referencia. Dicha relación se puede establecer en ambos sentidos: una persona posee un automóvil. real o abstracto. Por ejemplo. Es decir. Entidades: Una entidad es "una persona. Si tenemos dos entidades automóvil y persona. lo cual se muestra en la Figura 9.© Grupo EIDOS 3. y Un automóvil pertenece a una persona. se representa por un rectángulo. Figura 10 4. ya que no existe una misma matrícula para dos automóviles distintos. seremos capaces de conocer a que ocurrencia de entidad. Figura 9 3. modelo y color. entre todas las posibles. concepto o suceso. la Figura 8 representa la entidad automóvil. Los atributos marca. Esto implica que los valores de los atributos clave no se pueden repetir para dos ocurrencias de la misma entidad. ya que pueden existir dos automóviles distintos de la misma marca. como su propio nombre indica. Figura 8 2. En el modelo E/R. modelo o color no identifican unívocamente una ocurrencia de la entidad. marca.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS 5. Figura 12 Cardinalidad N-M: también llamada muchos a muchos.: una persona posee varios automóviles y un automóvil puede pertenecer a varias personas. Cardinalidad máxima de una relación: representa el número máximo de ocurrencias de una entidad con las que se puede relacionarse otra entidad. cuando no somos capaces de conocer a que ocurrencia de entidad nos estamos refiriendo.: una persona posee un automóvil. Figura 11 Cardinalidad 1-N: también llamada uno a muchos. Figura 13 6. 8. o es dependiente de otra. Cada ocurrencia de una entidad puede relacionarse con varias ocurrencias de otra entidad y viceversa. Se representa como aparece en la Figura 13. Cardinalidad de una relación: La cardinalidad de una relación representa el número de ocurrencias que se pueden dar de una relación. Entidad débil: se dice que una entidad es débil. Cardinalidad mínima de una relación: representa el número mínimo de ocurrencias de una entidad con las que se puede relacionarse otra entidad. Se representa como indica la Figura 11. Ej. sino que debemos conocer el valor de algún otro atributo de otra 26 .: una persona puede tener como máximo tres automóviles. Se representa como muestra la Figura 12. Ej. Ej. Ej. Cada ocurrencia de una entidad puede relacionarse con varias ocurrencias de otra entidad.: una persona posee varios automóviles. ni siquiera conociendo su clave. Ej.: un automóvil debe pertenecer como mínimo a una persona. 7. Puede ser de tres tipos: Cardinalidad 1-1: cada ocurrencia de una entidad se relaciona con una ocurrencia de otra entidad.

© Grupo EIDOS 3. Por ejemplo. cardinalidad mínima 1. Diseño conceptual entidad. aunque no tengan automóvil. (nos fijaremos sólo en un sentido de la relación. es decir. Esto significa que el modelo interesa tener información de todas las personas. o puede no tener ninguno (cardinalidad mínima 0). por ejemplo. si tenemos las entidades edificio (con el atributo clave codigo_edificio) y planta (con el atributo codigo_planta). Cardinalidad máxima N. ya que no somos capaces de identificar una planta con sólo conocer el código de la planta. Figura 14 En general. cardinalidad mínima 0. para determinar la planta dentro del edificio. cardinalidad mínima 1. En los anteriores casos no se han considerado las cardinalidades mínimas. ésta última es una entidad débil. Esto significa que en el modelo no interesa tener información de aquellas personas que no tengan automóvil. Cardinalidad máxima N. Figura 15 Veamos a continuación unos ejemplos para comprender mejor las cardinalidades máxima y mínima. se tiene una relación 1-1 en la que un automóvil pertenece a una única persona (cardinalidad máxima 1). Éstas vienen a representar la opcionalidad de la ocurrencia de una entidad en una relación. sin la posibilidad de que exista un automóvil que no tenga dueño (cardinalidad mínima 1). En el siguiente ejemplo(Figura 16). 27 . sino que además se necesita conocer el código del edificio al que se hace referencia. en una relación se suele representar conjuntamente las cardinalidades máxima y mínima. Los tipos de cardinalidades son los que aparecen en la Figura 15. se pondrá al lado de la entidad asignatura. si se tienen las entidades alumno y asignatura. se tiene una relación 1-1 en la que una persona puede tener un automóvil como mucho (cardinalidad máxima 1). si dicha ocurrencia se debe dar obligatoriamente. Cardinalidad máxima 1. Figura 16 En la Figura 17. Cardinalidad máxima 1. el de la izquierda). cardinalidad mínima 1. Como se podrá comprobar. las cardinalidades de una relación se ponen en la última relación a la que se hace referencia. o si por el contrario se puede obviar. la cardinalidad de la relación un alumno cursa asignaturas.

nombre. 28 . apellidos. en la que un profesor puede dar clase a muchos alumnos (cardinalidad máxima N). el autor o autores. a su vez. el título. Figura 18 En el siguiente ejemplo. pero puede que no tenga ninguno (cardinalidad mínima 0). Figura 19 Para concluir esta sección se verá un ejemplo completo que representará todos los conceptos vistos hasta ahora. aunque no tengan automóvil. De ellos se quiere saber su DNI. Un autor podrá haber escrito varios libros. Esto significa que en el modelo interesa tener información de todas las personas. Deberá quedar constancia de la fecha de préstamo de cada ejemplar. De cada autor se quiere conocer su nombre. Por cuestiones directivas. la editorial.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 17 En el siguiente ejemplo (Figura 18). dirección y teléfono. en la que una persona puede tener varios automóviles (cardinalidad máxima N). Para cada libro interesa conocer el ISBN. no podrá ser prestado a otro hasta que se devuelva. por lo que un libro prestado a un usuario. A dicha biblioteca podrán estar suscritos varios usuarios. se tiene una relación 1-N. Supongamos que se desea establecer un modelo conceptual para la gestión de una biblioteca. de un único ejemplar de cada libro. Se dispone. De la editorial se desea conocer el nombre y la ciudad. pero como mínimo debe hacerlo a uno (cardinalidad mínima 1). el año de publicación y la materia. número de socio. de la misma forma que en un libro pueden participar varios autores. se tiene una relación N-N. apellidos y nacionalidad. Se desean tener almacenados todos los libros que la componen. Esto significa que en el modelo no interesa tener información de aquellos profesores que no dan clase. se limita el número de ejemplares prestados a cada usuario a uno.

son las que tienen como origen o destino a la entidad préstamo. Para ello se desean tener almacenados los nombres de todos los discos disponibles. El problema que nos planteamos es el siguiente. para ir familiarizando al lector con los conceptos vistos hasta ahora. Pues ya tenemos la tercera entidad. y que además tendrán sus propias letras. Ejemplos prácticos de diseño conceptual A continuación resolveremos unos problemas de diseño conceptual. se necesita saber no sólo el libro. Diseño conceptual Figura 20 Lo más destacable del anterior ejemplo es la entidad préstamo. aunque todavía no se haya realizado ningún préstamo. podemos establecer los discos que se venden. dirección y teléfono. ya que se desea conocer información de ellos. como puede ser un código que lo identifique dentro de la estantería. Además. sino el socio al cual se ha prestado. Las únicas relaciones que tienen cardinalidad opcional. que es una herramienta CASE que abarca gran parte del ciclo de vida de las aplicaciones. Es una entidad débil que depende de libro y de socio. simplemente quédese con la idea general de la construcción del esquema. lo cual es lógico. ya que para diferenciar un préstamo de otro. se desea conocer todas las canciones que están disponibles en los discos. por lo tanto ya tenemos identificada una segunda entidad. ya que se verá en detalle en próximos temas. Pues bien. empezaremos identificando las entidades. incluyendo el diseño de esquemas conceptuales. de los cuales se desea almacenar su nombre. y para cada uno de ellos se desea conocer su nombre y apellidos. además de sus cantantes y canciones. ya que tendremos información de todas las entidades. También se pueden observar que las cardinalidades mínimas son 1.© Grupo EIDOS 3. Así mismo se desean almacenar los clientes que han comprado en dicha tienda. Para realizarlos se utilizará la S-Designor. Supóngase que se desea informatizar una tienda de discos. La cuarta estará formada por los clientes. y que podrán estar identificados internamente por un código de cliente. apellidos. Esto quiere decir que sólo se guardará información de las entidades cuando exista. al menos. Como primera entidad. Por otro lado se desea almacenar todos los artistas que intervienen en los discos de nuestra tienda. una ocurrencia de la entidad. No se preocupe si no conoce la herramienta. identificada cada una de ellas por un código de canción. entendiendo por entidad un grupo de características que tienen entidad propia. Figura 21 29 .

muy usado en el diseño conceptual. Supongamos que se desea tener almacenados todos los datos de los profesores de una empresa dedicada a impartir cursos. de la cual se desea conocer su descripción. y que consiste en tener una entidad que tipifique los posibles estados que puede tomar un atributo. Por ejemplo podemos tipificar las ciudades. 3. apellidos. Cuando almacenemos la ciudad de un alumno. 2. y los alumnos a los cuales se les ha impartido. dirección y teléfono. sólo nos queda relacionarlas. Empezamos identificando entidades. Por lo tanto. Ni que decir tiene que el curso describe otra entidad. Podemos observar las siguientes relaciones: 1. 30 . y una canción puede estar compuesta por varios cantantes (N-M). De un profesor se desea conocer su nombre y apellidos. Entre cantante y canción: un cantante puede componer varias canciones. La principal ventaja de este procedimiento radica en que muchas veces supone un ahorro de espacio de almacenamiento (por ejemplo al identificar nombres de ciudades largas con un solo número) además de una estandarización de los datos almacenados (el estado sólo se almacena una vez). del cual se desea conocer su nombre. denominado tipificación de estados. Entre cliente y disco: un cliente puede comprar varios discos. donde se almacenará un código y la descripción de la ciudad. sólo deberemos especificar el código de la ciudad. para lo cual creamos una nueva entidad ciudad. Otra entidad podría ser el alumno. por lo tanto establece una entidad. Entre disco y canción: en un disco pueden aparecer varias canciones. dirección y despacho.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Una vez establecidas las entidades. podemos recurrir a un procedimiento muy usual. y cada canción puede estar en varios discos (N-M). pero un disco sólo puede ser comprado por un cliente 1-N. así como una breve descripción de éstos. el esquema conceptual es que muestra la Figura 22 Figura 22 Vamos a plantearnos otro problema. Sin embargo.

3. Figura 24 Cabe destacar que el atributo calificación se da como consecuencia de la relación entre las entidades curso y alumno. Por lo tanto. Alumno y Ciudad: un alumno vive en una ciudad. el esquema conceptual es el mostrado en la Figura 24. vamos a definir las relaciones entre ellas. y una ciudad puede tener varios alumnos (1-N). y a un curso pueden asistir varios alumnos (N-M). Alumno y Curso: un alumno puede asistir a varios cursos. 2. pero un curso sólo puede ser impartido por un profesor (1-N). 1. 31 . Diseño conceptual Figura 23 Una vez establecidas las entidades. Profesor y Curso: un profesor puede impartir varios cursos.© Grupo EIDOS 3. Por lo que podrá ser introducido en la entidad intermedia que surja cuando se haga el paso a tablas (véase siguiente capítulo).

Figura 25 32 . y esta compuesto por un código de tipo de cargo. así como la oferta de nuevos productos. Sus atributos son cod_reunión. 1. dirección y NIF. y estará identificado por un código interno cod_cliente.). etc.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Vamos a ver un último ejemplo. extraordinaria. 4. libretas de ahorro. para poder mejorar su política de inversiones. Puesto que dicho banco esta constituido como sociedad anónima. apellidos. De ellas se desea conocer su código. Las decisiones de inversión en estas empresas saldrán como resultado de dichas reuniones. el proceso es similar al de los demás ejemplos. Cada cliente podrá escoger entre todos estos productos el o los que más le plazcan (créditos. Empresa: identifica las empresas en las cuales el banco ha invertido. Para ello se almacenará el nombre. dicho banco tiene intereses en otras empresas. Reunión: entidad encargada de describir la información de las actas de las reuniones. Empezaremos definiendo entidades y las veremos representadas en la Figura 25. 2. Consejo: establece los componentes del consejo de administración. que especifica si la reunión ha sido ordinaria o extraordinaria y una descripción. y una descripción del mismo (secretario. apellidos y código de cargo de cada uno de sus componentes. presidente. etc. De la misma forma. fecha. pero no desespere. Supóngase un banco que desea almacenar todos sus clientes. desea almacenar todos los componentes de su consejo de administración (actuales y ex-miembros) así como todas las actas de las reuniones ordinarias y extraordinarias. y si el cargo es vigente o no. fondos de inversión. además de los productos que puede ofrecer a éstos. Como habrá podido observar. 6. nombre y CIF. Producto: del cual queremos saber su descripción y estará identificado por un código interno cod_producto. 5. Tipo_cargo: describe los posibles cargos que puede tomar una persona en el consejo de administración.). por lo que desea conocer en todo momento la situación de dichas empresas. 3. Podremos utilizar una nueva entidad que tipifique los tipos de cargo. este ejemplo es un poco más complejo. Cliente: se desea conocer su nombre.

Consejo y cargo: un miembro del consejo sólo tiene un cargo. Reunión y producto: de cada reunión puede salir la oferta de mas de un nuevo producto pero cada producto nuevo sólo puede salir de una reunión. y cada cargo puede pertenecer a más de un miembro. 2. Reunión y empresa: de cada reunión pueden salir decisiones de invertir en más de una empresa. 33 . Su representación gráfica aparece en la Figura 23. 4. y cada decisión de inversión sólo sale de una reunión.© Grupo EIDOS 3. 5. y cada miembro puede asistir a más de una reunión. 1. Diseño conceptual Identifiquemos ahora las relaciones. 3. Cliente y producto: cada cliente puede escoger varios productos. y cada producto puede ser ofrecido a varios clientes. Reunión y consejo: a cada reunión pueden asistir varios miembros del consejo de administración.

.

Una vez obtenido el ELS.). En el diseño lógico estándar. además de las herramientas ya descritas (MLS. ya que ambos dependen mucho del SGBD que se utilice. MLE. En la fase de diseño lógico. En nuestro caso se utilizará el MLS relacional. que se apoya en un modelo lógico estándar (MLS).Diseño lógico Introducción Como ya se ha señalado. El diseño lógico específico está muy ligado a la fase de diseño físico. el diseño lógico de una base de datos consta de dos etapas: el diseño lógico estándar y el diseño lógico específico. se toma el esquema conceptual resultante de la fase de diseño conceptual. pero sin las restricciones de ningún producto comercial en concreto. se elabora el esquema lógico específico (ELE). que ya se verán mas adelante en este tema..). lenguajes SQL). SQL-SERVER. que será el mismo modelo de datos soportado por el SGBD a utilizar (relacional. se disponen de otras que permiten establecer un buen diseño lógico. Al igual que en el caso anterior. Una buena forma de describir el ELS es utilizando el lenguaje estándar del MLS (por ejemplo SQL). una buena forma de describirlo es utilizando el lenguaje de definición de datos (LDD) del producto especifico utilizado (en el caso de SQL-SERVER. . etc. etc. como por ejemplo la normalización. etc. de construye un esquema lógico estándar (ELS). INFORMIX. y considerando el modelo lógico específico (MLE) propio del SGBD a usar (ORACLE. la desnormalización. y teniendo en cuenta los requisitos de proceso. se usará el TRANSACT SQL). jerárquico.

Cada relación dependiente. apellidos y telefono. con sus propios atributos. si se desea extraer más información. cada entidad genera una tabla. importa la clave de la otra entidad. nombre. mantiene información de qué libros han sido prestados a qué usuarios y en qué fecha. Para entender mejor el funcionamiento de este método. son las que a continuación se explican: • • • • Cada entidad se transforma en una relación: esto es. Empezaremos identificando las relaciones. a la que denominaremos Libro_autor mantiene la información de los códigos de libros junto con los códigos de autores. A su vez. e importará el atributo clave de la entidad con cardinalidad 1.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Paso del esquema conceptual al esquema lógico estándar Lo primero que hay que realizar en la fase de diseño lógico. Cada relación 1-N importa las claves de la entidad con las que se relaciona: cada relación con cardinalidad 1-N importa los atributos clave que contiene la entidad con cardinalidad N. Esta última relación obtenida. en la que se almacenarán las claves de ambas entidades. Cliente-Disco: puesto que es una relación 1-N. cuyo esquema conceptual es el que muestra la Figura 27. Las reglas que permiten pasar del modelo E/R al esquema lógico. La entidad libro está relacionada con la entidad editorial con cardinalidad 1-N. que es dependiente tanto de la entidad Libro como de la entidad Usuario. la cardinalidad es N-M. se deberá acceder a sendas tablas. Por último se dispone de la entidad Préstamo. 36 . con los atributos de la entidad Préstamo además de las claves de las entidades de las que es dependiente. con sus mismos atributos. Posteriormente. incluyendo las claves. y concretando las tablas que generarán: 1. lo que implica que se generará una tabla intermedia. como clave. veamos el paso a tablas del ejemplo visto en el tema anterior acerca de la gestión de una biblioteca. a partir del esquema conceptual obtenido en la primera fase. con los atributos clave de ambas entidades. es decir. El esquema de las tablas resultantes es el que se muestra en la Figura 26 Figura 26 Veamos ahora el paso a tabla de otro ejemplo visto en el tema anterior. A su vez. es decir. que entrarán como claves en dicha tabla. esta relacionada con la entidad con la entidad autor. tanto del libro como del autor. Esta tabla. por lo tanto importa la clave de la entidad con cardinalidad 1. la entidad disco generará una tabla con sus atributos. es obtener el esquema lógico estándar. cod_cliente. cod_cliente. Cada relación N-M genera una tabla: las relaciones entre entidades con cardinalidad N-M generan una tabla. ISBN y Num_socio. la entidad cliente generará su propia tabla. pero en este caso. es decir. lo que quiere decir que se generará una tabla.

La forma de lograrlo es mediante el particionamiento horizontal. 4. se generará una tabla intermedia. obligando a trasladar a esta etapa aspectos 37 • . Disco_Cantante: siguiendo el mismo razonamiento. para evitar valores nulos. Canción-Cantante: en este caso se tiene una relación N-M. y el proceso de normalización. la fase de diseño lógico de una base de datos consiste en dos etapas: • Etapa de estructuración: donde el objetivo primordial es encontrar un esquema que sea una representación fidedigna del mundo real. queda como aparece en la Figura 28. siguiendo el mismo razonamiento anterior. la tabla canción generada importará el cod_disco de la entidad disco. Etapa de reestructuración: donde se tienen en cuenta aspectos más ligados con el nivel físico. al ser una relación N-M. el esquema lógico resultante del esquema conceptual anterior.© Grupo EIDOS 4. Figura 27 Con todo esto. es decir. se generará una tabla intermedia. Esta etapa. con los atributos cod_cantante y cod_disco. y que consiste el modificar el esquema obtenido en la fase anterior para adaptarlo a las consideraciones de eficiencia. a si que. Figura 28 Etapas en el diseño lógico Como ya se ha comentado. cod_canción y cod_cantante. 3. es decir. Diseño lógico 2. se considera aquí debido a la falta de flexibilidad de los SGBD. que debería ser ajena al diseño lógico. Disco-Canción: es una relación 1-N. con los atributos claves de las entidades que relaciona.

Becquer Editorial Ibérica Alcalá 38 . es decir. para llevarlas a otra. y aquellas que no tienen editorial. En este caso. para dar paso posteriormente al proceso de normalización. y el particionamiento. podría ser conveniente "partir" dicha tabla horizontalmente en otras dos. supóngase el siguiente ejemplo en el que se tiene la tabla publicación. Particionamiento horizontal de relaciones Como su propio nombre indica. el particionamiento horizontal consiste en dividir longitudinalmente las filas que forman una tabla. es decir llevar parte de la información a una tabla. editorial. A. y un artículo (El impacto de las TI) que. la información que tenemos en la tabla es la mostrada en la Tabla 1. o artículos. Cod_publicación 123BB3-3 2322-DD Título El Quijote Rimas y Leyendas Tabla 2 Autor Miguel de Cervantes G. A. autor. se crean dos tablas: una para albergar los libros y otra para ubicar los artículos. usado tanto en la etapa de estructuración como en la de reestructuración. separar las filas que conforman una relación. vertical o mixto. como es obvio. esto es. mientras que la Tabla 3 contiene los artículos. bien sea horizontal. Por lo tanto. dejando para el final el particionamiento vertical. mixto y la desnormalización. libros. título. Becquer Tabla 1 Editorial Ibérica Alcalá Tenemos información sobre dos libros. Aquí la diferenciación se establece entre aquellas filas que tienen editorial. con su autor y su editorial correspondiente. La Tabla 2 posee la tabla de libros. Para entenderlo mejor. no tiene editorial. Cod_publicación Título 123BB3-3 113ZD3-0 2322-DD El Quijote El impacto de las TI Rimas y Leyendas Autor Miguel de Cervantes Francisco Hierves G. con los siguientes campos: cod_publicación. y parte a otra.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS mas relacionados con el nivel físico. La forma de lograrlo es mediante la desnormalización. Comenzaremos por estudiar el particionamiento horizontal de relaciones. En un momento dado.

el particionamiento horizontal no sólo se utiliza aquí. el coste de almacenamiento aumenta al tener toda la información duplicada. Hierves Con esto. Sin embargo. Los valores nulos pueden ser aplicables o no aplicables. Se dispone de dos tablas. La tabla alumno guarda sus datos personales. Supongamos. y aquellas filas que correspondan a clientes de Barcelona. en el nodo de Barcelona. • En este caso. para situar aquellas filas que correspondan a clientes de Madrid. nos podemos plantear varias cuestiones: 1. lo que hemos conseguido es eliminar la existencia de valores nulos no aplicables. es el primer paso que se debe seguir en el proceso de estructuración de relaciones. Un valor nulo es aquel que representa información desconocida. Por ejemplo. Mientras los no aplicables no cambian. permanecen nulos. lo que se deberá realizar en un particionamiento horizontal. pues. Si se sitúa toda la información en ambos nodos. que tenemos el siguiente esquema lógico. correspondiente a una base de datos para gestionar los alumnos de una empresa de educación a distancia. si se dispone de una base distribuida (para entendernos. uno en Madrid y otro en Barcelona. y suponiendo que se dispone de dos nodos. en el nodo de Madrid. los aplicables pueden dejar de serlo en algún momento. lo lógico sería pensar en situar la información de aquellos clientes que residen en Barcelona en dicho nodo. una base de datos con distintos nodos. inexistente o no válida (en nuestro caso el valor del atributo editorial en el artículo). Esto que acabamos de realizar. Los motivos son los siguientes: • Si se sitúa toda la información en un único nodo. sino que también puede usarse en la fase de reestructuración para conseguir una mayor eficiencia. Figura 29 Sobre el esquema de la Figura 29. con el coste que ello supone). es decir. una consulta de un cliente que vive en Barcelona se debería realizar al nodo de Madrid. el coste del acceso remoto aumenta (si toda la información está en Madrid. y las calificaciones obtenidas en cada una de las asignaturas. alumno y profesor. y ubicar únicamente la información de los clientes que viven en Madrid en dicho nodo. situados en distintas localizaciones. Diseño lógico Cod_publicación 113ZD3-0 Título El impacto de las TI Tabla 3 Autor Fco.© Grupo EIDOS 4. por ejemplo. mientras que la tabla profesor 39 . con determinada información en cada uno) con información acerca de clientes.

podemos optar por tres opciones: Opción 1: colocar la base de datos en un sólo nodo (centralizado). Puesto que en cada nodo sólo precisa información relevante a éste. pues bien. es decir. entonces. las aulas donde dicho profesor imparte cada una de las clases. Tabla 4 Opción 3 Analizando la anterior tabla. en su nodo local. arte y latín en letras. disminuyendo el tiempo de número de provincias. al que accederán los demás. y matemáticas y ciencias en la rama de ciencias. ciencias o letras. lo que aumenta la eficiencia en las distintas. Cada provincia tendrá toda la Se aumenta el espacio de almacenamiento. además de sus datos personales. y en la provincia donde se encuentre la base de datos se disminuirá el tiempo de acceso inconvenientes El resto de las provincias deberá acceder a la provincia donde se encuentre la base de datos. Ventajas Se disminuye el espacio de almacenamiento (una sola copia de la información). Opción 1 Opción 2 Cada provincia tendrá la parte de información que le interesa en su propio Si se precisa acceder a otras provincias nodo. La base de datos se encuentra distribuida. La pregunta que surge ahora es ¿cómo se puede realizar?. información de todas las provincias en su de forma directamente proporcional al propio nodo. con el tráfico de red y aumento de tiempo de acceso que esto supone. en cada una de las tablas. se dispone de un nodo en cada una de las provincias. aumentar la eficiencia de la base de datos. 40 . Los alumnos pueden optar por dos ramas. la respuesta es bastante simple: mediante el particionamiento horizontal. 2. acceso. Opción 3: colocar una copia de toda la base de datos en cada nodo. se aumenta el tiempo de acceso (tráfico de red) consultas / actualizaciones. 3. y teniendo la premisa expuesta de que cada provincia trabajará de manera aislada.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS almacena. En la Tabla 4 se analizan las ventajas e inconvenientes de cada una de la anteriores opciones. y para cada una de ellas se imparten dos asignaturas. Opción 2: colocar la parte de información relevante a cada nodo en cada uno de ellos. Nos planteamos. Para ello se deben seguir los siguientes pasos: Paso 1: Realizar una consulta para separar las filas correspondientes a cada provincia. al evitar el acceso por red a otras provincias. la opción que más nos interesa es ubicar cada parte de información relevante a cada una de éstas. donde se almacena la información relevante a ésta. para adecuarla a las necesidades de cada una de las provincias donde se encuentra ubicada la base de datos.

Quédese simplemente con la idea de su funcionamiento. aquellos que han optado por la rama de ciencias.© Grupo EIDOS 4. pero manteniendo intacta la información correspondiente a las filas. pero no por ambas. Otra de las cuestiones que hemos planteado es la referente a las ramas por las que puede optar un alumno: letras o ciencias. ya que se verán en detalle más adelante. Las tablas quedarían entonces como muestra la Figura 30. La información que tenemos de dicha tabla (Tabla 5) es: cod_proveedor. cod_material. respectivamente. al menos. Supóngase que tenemos la tabla reparto con la información de todos los repartos realizados por los proveedores a los clientes. cod_cliente. y en la tabla alumno_ciencias. ciudad_cliente y cantidad. ya que un alumno puede optar por una de las dos ramas. en la tabla alumno_letras. SELECT * FROM alumno WHERE provincia = "Madrid" SELECT * FROM profesor WHERE provincia = "Madrid" Código fuente 1 No se preocupe demasiado si no entiende las anteriores sentencias. en dividir las tablas de forma transversal. dos valores nulos inaplicables en cada fila de la tabla. La forma de proceder es. Podemos observar como en la tabla alumno. crear nuevas tablas con la información correspondiente a un subconjunto de los atributos de las mismas. Para ello se realizará una "criba" en ambas tablas donde el campo provincia sea Madrid. con el objetivo de eliminar estos valores nulos no aplicables. que es el de obtener de ambas tablas solamente aquellas filas que corresponden a la provincia de Madrid. Veamos un ejemplo para comprenderlo mejor. lo que supone que siempre se darán. 41 . ciudad_proveedor. al contrario que en el caso del particionamiento horizontal. se encuentran atributos que hacen referencia a las calificaciones obtenidas en ambas ramas. cada una de ellas almacenando los atributos correspondientes a cada una de estas ramas. Figura 30 Particionamiento vertical de relaciones El particionamiento vertical de relaciones consiste. La sentencia SQL que realiza se ve en el Código fuente 1. Diseño lógico Paso 2: Ubicar la información obtenida en cada uno de los nodos correspondientes a dichas provincias. denominadas alumno_ciencias y alumno_letras. nuevamente. es decir. mediante un particionamiento horizontal. De esta manera. estarían solamente las filas o tuplas correspondientes a alumnos que han escogido la rama de letras. supóngase que se desean ubicar las filas de las tablas alumno y profesor en el nodo provincial de Madrid. nombre_proveedor. podremos decidir separar las filas de dicha tabla entre otras dos. nombre_cliente. Como ejemplo. De esta manera es preciso proceder para el resto de las provincias. Llegados a este punto.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS cod_ cod_ proveedor cliente 123 128 837 113 114 998 cod_ material 112 118 128 nombre_ proveedor Pepe Luis Antonio nombre_ cliente Juan Paco Ángel Tabla 5 ciudad_ proveedor Sevilla Madrid Barcelona ciudad_ cliente Sevilla Cuenca Manresa cantidad 10 29 12 Dada la Tabla 5. cod_material y cantidad. podría interesarnos tener varias tablas: una que contenga la información del proveedor. nombre_proveedor ciudad_proveedor Pepe Luis Antonio Sevilla Madrid Barcelona Tabla 6 nombre_cliente Juan Paco Ángel ciudad_cliente Sevilla Cuenca Manresa Tabla 7 cod_proveedor 123 128 837 cod_cliente 113 114 998 Tabla 8 cod_material 112 118 128 cantidad 10 29 12 42 . otra con la información del cliente con los atributos nombre_cliente y ciudad_cliente y otra con la información de los repartos con los atributos cod_proveedor. con los atributos nombre_proveedor y ciudad proveedor. Para ello realizamos un particionamiento vertical. sobre estos atributos. cod_cliente.

ya que escapan del objetivo del presente curso. es decir. Puesto que la única transacción (consulta) que se va a realizar (de momento) es la consulta del sueldo de un empleado. Nos plantemos entonces un particionamiento vertical. existen muchos atributos. supóngase que se dispone un esquema lógico con una sola tabla. Entre ellas destacan: • Aumento de la concurrencia: cada vez que un usuario accede a una fila de la tabla. con lo que ello supone. por ejemplo el de Navathe y Ra. • • Por contra. la principal desventaja que tiene este método es el aumento del tiempo de consulta / actualización si se desea acceder a dos o más tablas. Aumento de la velocidad de consulta / actualización: al ser las tablas más pequeñas. En cambio. ya que se necesitarán menos accesos a disco para completar la acción. la información a la que accedemos tendrá más probabilidad de ser utilizada. normalmente. a los que deberemos acceder en cada consulta. para extraer un solo atributo con todos los inconvenientes que esto supone. Esto es debido a que. si un usuario accede a una fila de una tabla. Disminución de tiempos de consulta de información irrelevante: si se quiere consultar un solo atributo de una tabla. por ejemplo. ésta se bloquea. un mayor consumo de memoria (por el mismo motivo). y debamos realizar más accesos a la base de datos). es decir. Figura 30 Si nos damos cuenta. como por ejemplo una disminución de la concurrencia (otro usuario no podrá acceder simultáneamente a esa fila. Para ello existen varios algoritmos. el acceso (o bloqueo de tupla) se realiza al nivel de fila o tupla. ya que las ventajas que ofrece están relacionadas con la eficiencia. otro podrá acceder a la misma fila en otra tabla. en la que se almacenan los datos personales de los empleados de una empresa. Al dividir un tabla en más. una consulta o actualización podrá realizarse en un menor tiempo. se deberá acceder a toda la fila. etc. un aumento del tiempo de proceso (debemos procesar toda la fila para extraer un solo atributo). sin únicamente deseamos obtener el sueldo de un empleado. se puede separar esta tabla en 43 . Diseño lógico El resultado es que tenemos el mismo número de filas en todas las tablas.© Grupo EIDOS 4. es decir. ya que deberemos obtener toda la fila correspondiente a ese empleado. se accede a toda la fila de la tabla. Por ejemplo. en los que no entraremos. ni siquiera para consultar el valor de otro atributo). no puede ser accedida por otro usuario. la concurrencia aumenta. al reducir el tamaño de las filas. Es por ello por lo que hay que realizar un estudio pormenorizado de la probabilidad de consultas que se va a realizar. aunque no nos interese su valor. Puede que esto no nos sea útil. pero más tablas con menos atributos. un aumento del número de operaciones de Entrada / salida (puede que la fila entera no quepa en el buffer de memoria. Este proceso se realiza en la reestructuración.

igual para cada fila en ambas tablas. como campo unión entre ambas tablas. de hecho si valdría.Utilizar un atributo clave. en este caso. Pues bien. pero no sería demasiado eficiente). por ejemplo para ubicar las distintas filas de una tabla en distintos nodos de una base distribuida (como el ejemplo visto anteriormente). y asociarlas a las filas de la tabla homóloga. para obtener ambos valores. La solución.Utilizar un identificador de fila. De esta manera solventamos los anteriores inconvenientes que se presentaban. sino también la categoría de un empleado?. y 44 . se pueden usar dos métodos: 1. Por lo tanto. o bien se aplica un particionamiento horizontal a una tabla particionada verticalmente. quedando el esquema lógico particionado verticalmente de la como indica la Figura 31. utilizando el DNI. el esquema obtenido no nos valdría (bueno. existen dos opciones: • Realizar primero un particionamiento horizontal. o 2. y otra con el resto. ¿que pasaría si ahora se necesita saber no sólo el sueldo. ya que ahora se necesitaría realizar una operación de join o unión entre ambas tablas. Figura 32 Particionamiento mixto El particionamiento mixto consiste en un híbrido entre ambos tipos de particionamiento. Figura 31 Sin embargo.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS otras dos: una con el atributo sueldo. pasaría por añadir el campo categoría a la tabla anteriormente extraída. similar para filas iguales en ambas tablas. Destacar que la operación de join es bastante costosa en tiempo de ejecución. Para identificar unívocamente cada una de estas filas. En esta caso optamos por la segunda opción. O bien se aplica un particionamiento vertical a una tabla previamente particionada horizontalmente.

para que cumpla el primero de los objetivos de las bases de datos. El particionamiento mixto se usa en la etapa de reestructuración. Las anomalías que puede presentar una relación son de tres tipos: • Anomalías de inserción: son producidas por la pérdida de información. para conseguir un mayor ajuste de los tiempos de acceso a datos (evitar acceder a datos irrelevantes). pero que no presenten cierto tipo de anomalías a la hora de realizar operaciones sobre ella. para conseguir disminuir los tiempos de acceso y posteriormente realizar un particionamiento horizontal sobre dichas tablas. La Figura 33 nos muestra como la relación original R se ha particionado de forma horizontal en otras dos R2 y R1. al no poder insertar filas en una relación. ya que es el encargado de modificar el esquema conceptual obtenido en la fase anterior. se ha particionado verticalmente en otras dos R3 y R4. Diseño lógico posteriormente realizar un particionamiento vertical sobre las tablas obtenidas. ésta última. Por ejemplo. correspondiente a los repartos realizados por distintos proveedores. La forma de representar el particionamiento mixto se denomina árbol de particionamiento. y a su vez. • Realizar primero un particionamiento vertical. Cod_proveedor Cod_material 1 1 A234 B298 Ciudad Madrid Madrid Categoría 2 2 Cantidad 122 100 45 . La normalización se puede definir como el proceso de sustituir una relación o tabla. el de que ha de representar fielmente la realidad. y se corresponde con la etapa de estructuración. supóngase que se dispone de la siguiente relación. por un conjunto de esquemas equivalentes que representen la misma información. ya que se tiene en cuenta aspectos relacionados con el nivel físico (eficiencia). Figura 33 Teoría de la normalización El proceso de normalización consiste en la aplicación de un conjunto de reglas. La normalización se podría considerar prácticamente como el grueso de la fase de diseño lógico. con el objeto de verificar que el esquema relacional obtenido en esta fase cumple un cierto conjunto de reglas. e indica los distintos tipos de particionamiento por los que va atravesando una determinada relación. ya que no se conoce el valor de algún atributo no principal (que no es clave). después de la eliminación de valores nulos no aplicables (particionamiento horizontal).© Grupo EIDOS 4. Por lo tanto es el segundo paso a realizar dentro de la fase de diseño lógico.

Anomalías de modificación o actualización: vienen impuestas por la necesidad de propagar actualizaciones. Por estos motivos. en 3FN. supóngase el caso anterior. su ciudad y su categoría. perderemos toda la información relacionada con él. 46 . una relación que esté en 2FN estará en 1FN. la segunda forma normal (2FN) y la tercera (3FN). definidas por Codd. Evidentemente esto es muy peligroso. sino que se deberán recorrer todas las filas correspondientes a todos los repartos de dicho proveedor. es decir. lo que se busca con el proceso de normalización es eliminar estos tres tipos de anomalías. ya que si nos olvidamos de actualizar dicho valor en una fila. existirán dos valores distintos de ciudad para un mismo proveedor. y la cuarta y quinta forma normal (4FN y 5FN). como muestra la Figura 34. y modificar el valor de atributo ciudad en todas ellas. es decir. Si se desea modificar la ciudad de un proveedor. distintas formas normales. y eso sin contar el tiempo que se pierde en realizar dicha actualización. no se puede reflejar en la relación. definidas por Fagin.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS 2 2 3 G344 G392 F893 Sevilla Sevilla 3 3 200 310 400 Valencia 1 Tabla 9 Si en este momento se desea añadir un nuevo proveedor. al eliminar una fila de una relación. se debe modificar el mismo atributo en más de un sitio. al existir únicamente una fila con dicho proveedor. Por ejemplo. al menos. la forma normal de Boyce-Codd (FNBC). no bastará con hacerlo en un sitio. es decir. ya que dicho proveedor todavía no ha realizado ningún reparto. Sigamos con el ejemplo anterior. • Anomalías de borrado: vienen determinadas por la perdida de información que no se desea. • Por lo tanto. una que este en 3FN estará en 1FN y 2FN. Dichas formas normales son la primera forma normal (1FN). la base de datos quedará inconsistente. es decir. Si se desea borrar el reparto realizado por el proveedor 3. definida por Boyce y Codd. Figura 34 Una esquema relacional estará normalizado cuando esté. mediante varios pasos. Son debidas a un diseño redundante. se pueden establecer dos conclusiones: el diseño es redundante y el esquema no está normalizado. La principal característica que cumple cada una de estas formas normales es que la de nivel superior incluye a la de nivel inferior. Se dice que un esquema de relación esta en una determinada forma normal si satisface un determinado conjunto de restricciones. Consiste en conseguir.

cada valor de X tiene asociado en todo momento un único valor de Y. Sea la relación R compuesta por los atributos X. De la misma forma. Sea X un descriptor compuesto por X1 y X2 (X1 y X2 atributos de X). nombre. (varios empleados pueden cobrar lo mismo). mientras que el mismo libro se puede prestar varios días (2) y un mismo socio puede tomar prestado uno o varios libros más de un día (3). veamos el concepto de dependencia funcional. Diseño lógico Para comprender mejor el proceso de normalización y la obtención de las formas normales. si se tiene la relación Empleado. ya que para un mismo salario pueden existir varios nombres de empleados. Por estos motivos. o que X determina o implica a Y si. Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. se puede concluir que Fecha_préstamo tiene dependencia funcional completa de ISBN y socio. se tiene: ISBN. etc. para un mismo DNI no pueden existir más de un nombre. Y.. se puede concluir que entre Salario y Nombre no existe dependencia funcional. y se representa X ---> Y. si se tiene la relación Libro con los atributos ISBN. se dice que Y tiene dependencia funcional plena o completa de X si depende funcionalmente de X pero no depende de ningún subconjunto del mismo.© Grupo EIDOS 4. Se dice que Y depende funcionalmente de X. en la que se tiene: X --------> Y Y --------> Z Y ----/---> X 47 . se puede asegurar que DNI ---> Nombre . veamos la Tabla 10. Cod_socio ------------> ISBN ----/------> Cod_socio -----/---------> Fecha_préstamo Fecha_préstamo Fecha_préstamo Tabla 11 (1) (2) (3) ya que para un libro y un socio sólo existe una fecha de préstamo (1). y sólo si. compuesta por los atributos DNI. La dependencia funcional plena o completa es un caso particular de dependencia funcional. Otro caso particular de dependencia funcional es el de dependencia funcional transitiva. Cod_socio y Fecha_préstamo. salario. X -------> Y X1 --/--> Y X2 --/--> Y (Y depende funcionalmente de X) (Y no depende funcionalmente de X1) (Y no depende funcionalmente de X2) Tabla 10 Por ejemplo. ya que por cada DNI tenemos un nombre. Por ejemplo. es decir. Z.

si se tiene la relación Empleado. Cod_alumno 10 Nombre L. Veamos a continuación las distintas formas normales. de los cuales los atributos clave son ISBN y Cod_socio. además de estar en 1FN. y se tiene la dependencia funcional que sigue: 48 . tiene un sólo valor en cada fila. Cod_alumno 10 10 20 Nombre L. ya que la primera fila tiene dos valores para el atributo asignatura. Fernández Asignatura Matemáticas Lenguaje 20 P. Primera forma normal (1FN): Una relación está en 1FN si cada atributo de dicha relación. todos los atributos que no forman parte de ninguna clave candidata suministran información acerca de la clave completa. cada atributo no principal (que no forma parte de la clave) tiene dependencia funcional completa respecto de cada una de las claves. y cada dirección sólo tiene un código postal (2). Fernández P. que Z tiene una dependencia transitiva respecto de X a través de Y. es crear una fila por cada valor del atributo repetido. con los atributos Nombre. Por lo tanto Nombre --. Cod_socio y Editorial. Por ejemplo.---> Cod_postal. por ejemplo.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS se dice. Por ejemplo. Alonso Tabla 12 Ciencias La forma de transformar esta relación a otra que sea 1FN sin pérdida de información. La siguiente relación. de la forma que indica la Tabla 13. y se representa X -------> Z. Alonso Tabla 13 Asignatura Matemáticas Lenguaje Ciencias Segunda forma normal (2FN): Una relación está en 2FN cuando. entonces. Dirección y Cod_postal. O lo que es lo mismo. mientras que varios empleados pueden vivir en una misma dirección (3). si se tiene la relación Libro con los atributos ISBN. no de una parte de la clave. no está en 1FN. se tiene: Nombre ----------> Dirección (1) Dirección --------> Cod_postal (2) Dirección ---/----> Nombre (3) cada empleado sólo tiene una dirección (1). Fernández L.

denominadas multivaluadas y de unión respectivamente. se descompone dicha relación en otras dos: R1 = {ISBN. La cuarta y quinta forma normal dependen de un tipo especial de dependencias. veremos algún ejemplo sobre cómo normalizar un esquema lógico dado. es decir. Para transformarla a otro esquema equivalente. Las formas normales que se verán ahora no son muy utilizadas. Editorial} Este es un esquema equivalente al anterior. referente a los repartos realizados por varios proveedores en una empresa. se descompone dicha relación en otras dos equivalentes. con las siguientes dependencias funcionales: Nombre ----------> Dirección Dirección --------> Cod_postal (1) (2) dicha relación no se encuentra en 3FN. que esté en 2FN. así que simplemente se mencionarán. Tercera forma normal (3FN): Una relación esta en 3FN cuando. además de estar en 2FN. dicho esquema se encuentra en 3FN. Se dice que una relación esta en forma normal de Boyce-Codd cuando se tiene que para toda dependencia funcional se tiene que el implicante (la parte derecha de la dependencia) es clave. que cumplan la tercera forma normal: R1 = {Nombre. Cod_postal} Ahora las nuevas dependencias que tenemos son (1) en R1 y (2) en R2. cosa que puede no interesar en la mayoría de los casos. por lo que se ha eliminado la transitividad. no existe ningún atributo no principal que dependa transitivamente de alguna de las claves de la relación. con los atributos Nombre. Dirección y Cod_postal. ya visto anteriormente. no de toda ella. ya que el atributo no principal editorial. Ejemplos prácticos de normalización Para comprender mejor el proceso más importante en la fase de diseño lógico de una base de datos.© Grupo EIDOS 4. Cod_proveedor 1 1 Cod_material A234 B298 Ciudad Madrid Madrid Categoría 2 2 Cantidad 122 100 49 . Por ejemplo. es decir. ya que ahora la dependencia (1) es completa. supongamos que tenemos la instancia que aparece en la Tabla 14 de un esquema lógico. Por ejemplo. ya que supone que el esquema este muy fuertemente normalizado. Para transformarla a 3FN. pero cumpliendo la segunda forma normal. para satisfacer este requisito. depende funcionalmente de una parte de la clave. representa la misma información. Nótese que la relación original se ha descompuesto en otras dos. cuya clave es el atributo nombre. si tenemos la relación Empleado. Dirección} R2 = {Dirección. Diseño lógico ISBN ---------------> Editorial (1) dicha relación no esta en 2FN. Cod_socio} R2 = {ISBN. al tener que el atributo no principal cod_postal depende transitivamente de la clave nombre.

ya que la combinación de estos valores no se repiten para más de una fila en la tabla. tenemos un valor distinto del atributo categoría. o para las dos siguientes en que el valor 2 para el atributo cod_proveedor implica la ciudad Sevilla. hasta que no haya realizado algún reparto. con el objeto de eliminar las anteriores anomalías. La respuesta es no. es decir. Lo primero es identificar las dependencias del esquema: Para cada valor del atributo cod_proveedor. en las que el valor 1 para el código del proveedor implica la ciudad Madrid. tenemos un único valor del atributo ciudad. normalmente. estamos en disposición de asegurar la ciudad del mismo. estaría formada por los atributos cod_proveedor y cod_material. ya que en cada fila tenemos un único valor para cada atributo. tenemos un valor distinto para el atributo cantidad. debemos propagar esta modificación a dos filas. 2FN: el esquema no está en 2FN. Conociendo la ciudad. Tabla 15 cod_proveedor ciudad ciudad categoría cod_proveedor. al menos. En nuestro caso. con la posibilidad de la consiguiente inconsistencia del esquema. nos encontramos con la siguiente dependencia: 50 . hasta lograr que este normalizado. Actualización: si actualizamos la ciudad del proveedor 1. • • 1FN: el esquema está en 1FN. ya que. Conociendo el código del proveedor y del material. ya que se producen anomalías: • • • Inserción: no podemos almacenar un proveedor. cod_material cantidad Lo siguiente es encontrar una clave para la tabla. podemos saber la cantidad abastecida. conociendo el valor del código del proveedor. Es decir. un atributo o conjunto de atributos que identifiquen unívocamente cada tupla de la relación. Borrado: si borramos el reparto del proveedor 3. está por defecto en 1FN. como podemos comprobar en las dos primeras filas. perdemos la información referente a dicho proveedor. El atributo ciudad implica el atributo categoría. Un esquema lógico.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS 2 2 3 A234 G392 F893 Sevilla Sevilla Valencia Tabla 14 3 3 1 200 310 400 Lo primero que cabe preguntarse es ¿está normalizado?. conocemos la categoría Para cada valor distinto del conjunto de atributos cod_proveedor y cod_material. En la Tabla 15 iremos modificando el anterior esquema. aunque está en 1FN. Para cada valor del atributo ciudad.

deberemos descomponer dicha relación en otras dos. • 3FN: Hasta aquí el esquema está en 1FN y 2FN. ya que en una ciudad puede haber varios proveedores. esto es. ya que el atributo categoría en la relación 2 depende transitivamente de la clave de dicha relación. Por lo tanto. para cada valor de ciudad. de manera tal que se evite la dependencia funcional transitiva entre ambos atributos. es decir. ahora la dependencia anterior ya es completa con respecto la clave. puede ser llevar el atributo ciudad junto con la parte de clave de la que depende (cod_proveedor) a otra relación.© Grupo EIDOS 4. que depende funcionalmente de una parte de la clave (cod_proveedor). puede haber distintos valores de cod_proveedor: ciudad --/ cod_proveedor tenemos que categoría depende transitivamente de la clave cod_proveedor: cod_proveedor categoría Por lo tanto deberemos descomponer la relación 2 en otras dos. no de toda ella.cod_material cantidad cod_proveedor ciudad categoría Tabla 16 ciudad cod_proveedor De esta manera. Una posible forma. junto con las dependencias funcionales que le afectan. ya que en la segunda relación la clave es ahora cod_proveedor. Otra forma de proceder es dejar en una relación aquellos atributos que forman parte de la dependencia. y llevar los demás a otra relación. tenemos que hay un atributo no principal (ciudad). pero no en 3FN. Atributos cod_proveedor. nos quedan las relaciones que muestra la Tabla 16. Por lo tanto.cod_material cod_proveedor. Relación 1 cod_maerial cantidad Cod_proveedor Relación 2 ciudad categoría Dependencias Clave Cod_proveedor. por lo que el atributo ciudad depende de toda la clave. Esto se puede conseguir llevándonos cada dependencia a una relación distinta. cod_proveedor ciudad ciudad categoría Como cod_proveedor no depende funcionalmente de ciudad. Diseño lógico cod_proveedor --------> ciudad Puesto que la clave de la relación esta formada por los atributos cod_proveedor y cod_material. de tal forma que el atributo ciudad dependa de toda la clave. 51 . que es cod_proveedor.

ya que ésta se almacena en la relación 2 Actualización: si cambiamos la categoría de una ciudad. 28 C/Alcala. De este modo hemos conseguido eliminar las dependencias que se nos planteaban en la relación original: • • • Inserción: si queremos insertar un nuevo proveedor. Borrado: si borramos un reparto.000 Domicilio C/ Alcala.34 C/Caimán. Supongamos esta vez que tenemos el esquema lógico de la Tabla 18. no hace falta cambiarla en todas las filas. Veamos ahora otro ejemplo de normalización. ya que al existir una sola dependencia. junto con su fecha. 389 C/Remanso.cod_material cod_proveedor cantidad cod_proveedor Ciudad Tabla 17 ciudad cod_material Ciudad categoría De esta manera se ha eliminado la dependencia transitiva. es imposible que esta dependa de otra. que representa los cursos impartidos por un profesor. 28 Tabla 18 Este esquema no está normalizado. mediante la descomposición de una relación inicial en otras tres.000 20. y domicilio de éste.000 10. Cod_post al 28027 28190 28027 28007 28190 Profesor Juan Pedro Juan Luis Pedro Fecha 01/02/99 03/02/99 03/02/99 01/02/99 03/03/99 Curso Windows 95 Visual Basic Windows 95 Delphi Windows 98 Precio 10. Por lo tanto hemos conseguido obtener un esquema normalizado en 3FN.000 25. ya que bastará con insertarlo en la relación 2. sino sólo una vez en la relación 3.000 15. 389 C/Caimán.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Atributos Relación 1 Relación 2 Relación 3 cod_proveedor cod_material cantidad Cod_proveedor ciudad ciudad categoría Dependencias Clave cod_proveedor. ya que se producen las siguientes anomalías: • Inserción: No podemos insertar los datos de un profesor hasta que éste no haya impartido un curso. no perdemos la información referente al proveedor. 52 . no hace falta que haga ningún reparto.

cada domicilio tiene un código postal. ya que tenemos la siguiente dependencia: curso -----> precio es decir. y en la otra las demás. que en nuestro caso está compuesta por los atributos profesor.© Grupo EIDOS 4. Tabla 19 Curso precio Profesor Domicilio domicilio cod_postal Ahora debemos comprobar si dicha relación cumple las reglas de cada una de las formas normales: • • 1FN: Puesto que para cada fila existe un solo valor para cada atributo. Atributos Profesor Fecha Curso Domicilio Cod_postal Curso Precio Dependencias Profesor domicilio Clave Relación 1 domicilio Profesor. El atributo profesor identifica unívocamente el atributo domicilio. 2FN: Dicha relación no se encuentra en 2FN. perdemos los datos de dicho curso. el atributo precio no tiene dependencia funcional completa con respecto a la clave. fecha y curso. Procedemos de igual forma que en el ejemplo anterior. Lo primero es identificar la clave. podemos existe un valor diferente para el atributo precio. debemos hacerlo en dos filas y si modificamos el precio de un curso o el código postal de un domicilio. cod_postal curso Relación 2 Curso Tabla 20 precio curso Ya hemos eliminado la dependencia no completa de la clave para la anterior dependencia funcional. es decir. El atributo domicilio identifica el atributo cod_postal. la relación se encuentra en 1FN. y del profesor que lo imparte. identifica de manera unívoca cada fila de la relación. también. El siguiente paso es identificar las dependencias funcionales. el atributo curso identifica el atributo precio. fecha. Actualización: Si modificamos la dirección del profesor Juan. Pero todavía tenemos un atributo que depende de parte de la clave en la relación 1: 53 . Para cada valor diferente del atributo curso. Cada profesor vive en su domicilio. Por lo tanto. Diseño lógico • • Borrado: Si borramos la impartición del curso de Delphi. ya que el conjunto de estos tres atributos. sino sólo a una parte. dejando en una dicha dependencia junto con sus atributos. desglosamos esta relación en otras dos.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS profesor domicilio Por lo tanto. fecha curso Relación 2 precio Relación 3 Esta relación ya se encuentra en 2FN. no tiene dependencias no completas de ningún atributo no principal con respecto de la clave. una que contenga los atributos referentes a dicha dependencia y otra con los demás. Atributos Relación 1 Profesor Domicilio Cod_postal Curso Precio Profesor Fecha Curso Tabla 21 Dependencias profesor domicilio curso Clave domicilio profesor cod_postal curso Profesor. tenemos una dependencia transitiva del atributo cod_postal con respecto de la clave: profesor cod_postal Por lo tanto. • 3FN: El anterior esquema no se encuentra en 3FN. ya que. además de estar en 1FN. podemos llevar cada una de ellas a una nueva relación. desglosamos la relación 1 en otras dos. para romper esta dependencia. ya que en un mismo domicilio pueden vivir varios profesores. Ahora podemos asegurar que el esquema se encuentra normalizado hasta la tercera forma normal. con lo que nos queda lo que indica la Tabla 22. ya que la relación 1 tiene una dependencia transitiva con respecto de la clave: profesor domicilio domicilio cod_postal Como domicilio no depende de profesor. Atributos Relación 1 Relación 2 Profesor Domicilio Curso Precio Dependencias profesor curso domicilio precio Clave profesor curso 54 .

Si tenemos que no se van a realizar prácticamente actualizaciones. Esto supone que puede que el esquema resultante de la normalización sea lo suficientemente eficiente como para que no sea preciso reestructurarlo. o que simplemente no nos interese que el esquema sea eficiente. el lector puede preguntarse que para qué se procede a normalizar un esquema. pero que no presenta las anomalías que se daban en el original: • • • Inserción: si queremos dar de alta un nuevo curso lo haremos en la relación 2 y si queremos insertar un nuevo profesor. Destacar. La respuesta es simple. que no se queden dependencias en el camino. fecha curso domicilio Relación 4 Tabla 22 Lo que hemos conseguido es sustituir un esquema en el que sólo existía una relación. se puede proceder a realizar una reestructuración del esquema. interesará que el nivel de normalización sea bajo. se procurará que el esquema esté siempre normalizado al nivel de 3FN. es decir. por último. no perdemos la información de dicho curso. En definitiva. para que el esquema original y el normalizado tengan la misma información. o el domicilio de un profesor. En estos momentos. en otro con cuatro. parte de la cual supone la desnormalización del mismo. o del profesor que lo imparte.© Grupo EIDOS 4. cuando posteriormente se va a desnormalizar. puede que normalicemos hasta un cierto nivel. y que solo interese desnormalizar hasta otro determinado nivel. ya que el diseño será redundante. que mantiene la misma información. domicilio y cod_postal. lo haremos en la relación 1. y debido a aspectos de eficiencia. Posteriormente. si el número de consultas es alto con relación al de actualizaciones. a medida que disminuya el nivel de normalización. es decir. ya que se evitarán las anomalías expuestas. Como norma general. a dejarlo como estaba. Un último detalle a tener en cuenta es el de la descomposición sin perdida de dependencias. Sin embargo. sólo se hará una vez. es frecuente que el número de relaciones disminuya. nos encontramos que para realizarla necesitamos acceder a dos 55 . lo cual implica que se tardará menos en buscar la información. primero se procede a estructurar el esquema. esto es. Además. el proceso de desnormalización supone la unión de varias relaciones en un número menor de ellas. Actualización: si cambiamos el precio de un curso. Proceso de desnormalización El proceso de desnormalización hace referencia justo al proceso inverso de normalización que se acaba de ver. supóngase el ejemplo de los cursos visto en el apartado anterior. Diseño lógico Relación 3 Profesor Fecha Curso Domicilio Cod_postal Domicilio cod_postal Profesor. Por ejemplo. en la relación correspondiente. si no que se van a realizar consultas sobre los atributos profesor. y una parte de esta estructuración es la normalización de relaciones. Borrado: si borramos la impartición de un curso. que interesa tener un nivel fuerte de normalización cuando el número de actualizaciones sea alto con relación al de consultas.

hasta 2FN. se deberá realizar un join.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS tablas (relación 1 y relación 4). fecha curso Relación 2 precio Relación 3 Tabla 23 56 . donde para acceder a dicha información. Atributos Relación 1 Profesor Domicilio Cod_postal Curso Precio Profesor Fecha Curso Dependencias profesor domicilio curso Clave domicilio profesor cod_postal curso Profesor. simplemente se precisa consultar la relación 1. puede interesar en este caso desnormalizar dicho esquema un nivel. con el aumento de tiempo de proceso que ello supone. Por lo tanto. es decir.

del Sistema Operativo y del hardware. . debido a la carencia de un modelo formal. existen características que son comunes a la mayoría de los productos. es decir. y que pueden ser utilizadas para definir un esquema físico. pretendiendo los siguientes objetivos: • • • • • Disminuir los tiempos de respuesta Minimizar espacio de almacenamiento Evitar las reorganizaciones Proporcionar la máxima seguridad Optimizar el consumo de recursos Como ya se ha comentado. lo que significa que se debe iterar desde el diseño lógico específico al físico y viceversa. considerando los aspectos más cercanos al hardware. es preciso llevar a cabo a cabo en muchas ocasiones un proceso de reestructuración de relaciones para conseguir una mayor eficiencia. equivalente al relacional que permita una definición formal de esa fase de diseño. características del SGBD. hasta obtener un esquema aceptable. debido a la falta de flexibilidad de los actuales SGBD.Diseño físico Introducción El diseño físico busca conseguir una instrumentación lo más eficiente posible del esquema lógico. Sin embargo. los requisitos de procesos. que optimice el ratio coste / beneficios. El diseño físico es fuertemente dependiente del producto comercial que se vaya a usar.

a la par que se mantiene la independencia. Flexibilidad. el esquema interno resultará más ineficiente. lo cual supone un aumento de la eficiencia. Las tuplas (en el caso del modelo relacional) se almacenan en dichos registros. está compuesto por varios factores: • • • • Tiempo de arranque: tiempo que tarda el disco en empezar a mover las cabezas. deben ser accedidos por el SGBD utilizando los mecanismos de gestión de ficheros que provee el sistema operativo. El SGBD impone una estructura interna. los recursos lógicos (SO. que es la unidad mínima que puede tratarse en una operación de Entrada / salida. Tiempo de transferencia: tiempo necesario para transferir la información. Los bloques. 2. oscilando éste entre 2 y 4 Kbytes. a memoria principal. El tiempo en acceder a un sector del disco. también denominado página o bloque. por el bus de datos. Del mismo modo. que se encuentran almacenados en los sectores del disco. Híbrido entre ambos. Destacar que esta es la estrategia más utilizada en los actuales SGBD. 3. que es bastante elevado. Entre las ventajas que supone utilizar esta técnica estriba la de que la BD puede empezar a funcionar de inmediato al disponer del esquema interno opcional.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Se podría considerar el diseño físico como una caja negra. pudiendo almacenar cada uno de éstos varias de aquellas. Inflexibilidad. si los datos son muy grandes. con la posibilidad de ir mejorando sucesivamente la eficiencia al ir realizando ajustes. junto con unas normas de seguridad y unas especificaciones para el ajuste. Tiempo de seek: tiempo necesario para mover las cabezas al cilindro (conjunto de pistas del mismo diámetro) requerido. 58 . aunque por contra. aunque también de la dependencia físico / lógica.). El tamaño de los bloques depende del producto comercial y del sistema operativo. impidiendo y dejando al administrador pocas opciones de cambiarlo. información sobre las aplicaciones que se ejecutarán en la máquina así como los objetivos que se plantean en esta fase. en la que se toman como entradas los recursos de la máquina. la forma de iterar entre la etapa de diseño lógico específico y la fase de diseño físico. el esquema lógico obtenido en la fase anterior. y se obtienen como salidas una estructura interna. Estrategias en el diseño físico Existen tres tipos de estrategias que los fabricantes de SGBD imponen en sus productos comerciales: 1. Implica que el administrador de la base de datos pueda diseñar la estructura interna. que representa la implementación del esquema lógico en un hardware específico. Conceptos básicos sobre gestión de ficheros La unidad básica de las estructuras físicas (ficheros) es el registro físico. un registro lógico puede estar almacenado en varios registros físicos. El SGBD proporciona una estructura interna opcional que el diseñador puede cambiar con el fin de mejorar la eficiencia. La principal ventaja de esta estrategia es la independencia físico / lógica del esquema. De aquí podemos definir el factor de bloqueo para un fichero como el número de registros lógicos (o tuplas) por bloque para dicho fichero. Es el contrapunto al anterior caso. Tiempo de latencia: tiempo que debe esperar hasta que el sector para por debajo de las cabezas. es decir. etc.

© Grupo EIDOS 5. el tiempo de acceso será instantáneo. Un índice se puede 59 . los datos que han sido usados más recientemente. un índice (ya se verá más adelante lo que es) estorbaría. ya que soporta búsquedas por valores de clave. • • Organización de ficheros Existen varias formas de organizar los ficheros. Árbol B+: Es una estructura que soporta búsquedas dicotómicas (el número de búsquedas es menor que log2 n). entre la que la más usada es la LRU (Least Recently Used). Porcentaje de utilización de cada bloque. Es útil cuando las filas se recuperan por el valor de la clave. los datos próximos tienen mayor probabilidad de ser referenciados. ISAM: Es una opción más amplia que la anterior. • • • Técnicas para el aumento de eficiencia Existen varias técnicas para aumentar la eficiencia del esquema: • Índices: Se puede definir un índice como una estructura que sirve para mejorar la eficiencia de las consultas a una base de datos. Se pueden agrupar determinado número de bloques contiguos en unidades llamadas extensiones. Este dispositivo es gestionado por el sistema operativo. es decir. Diseño físico Para acelerar este proceso. utilizando diversas políticas. Es conveniente usar esta forma de organización cuando existe una carga masiva de datos. Hash: Es una forma de organizar los ficheros teniendo como base una tabla indexada que apunta a la información. Algunos SGBD permiten especificar las características de los registros físicos. Los parámetros que se pueden especificar son: • El porcentaje de espacio libre que se deja en cada bloque para albergar posteriores actualizaciones de los registros lógicos. De esta forma se evita la concatenación de bloques. tienen una alta probabilidad de que sean usados en un futuro cercano. Número de bloques que se asignan a las extensiones. Al modificar un valor de un atributo. las tablas son pequeñas o cuando se accede a casi todas las filas. un registro detrás de otro. cuyo cometido es el de almacenar los datos más usados. que incide en un menor tiempo de respuesta. aprovechando de este modo la ley de proximidad temporal. son candidatos a desalojar la caché para albergar otros bloques. La ventaja con respecto al caso anterior es que crece de forma dinámica. Otra política es aprovechar la ley de proximidad referencial. Un índice se define sobre uno o varios atributos. ya que de todas maneras se necesita acceder a todas las filas. puede que éste no quepa en el espacio reservado. denominado caché o buffer. es decir. además de por parte de ella o usando patrones de búsqueda. A la hora de acceder a dichos atributos. es decir. se suele usar un dispositivo de almacenamiento intermedio. evitando de este modo accesos extra a disco. los bloques que se han usado hace más tiempo. es decir. es decir. de forma que el acceso a los mismos se realice de una y otra forma: • Secuencial: El método de acceso es secuencial. que en este caso actúa como función para determinar la posición donde se encuentra la información.

si se dispone de un índice por el atributo Nombre. o aquellos atributos que no vayan a ser modificados. La siguiente lista resume una serie de consejos a la hora de indexar campos: • • • • • 60 Indexar la clave primaria con un índice único Indexar las claves ajenas. Madrid At. encontrándose dos jugadores que cumplen este requisito.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS comparar con el índice de un libro. supóngase que tenemos la relación que muestra la Tabla 24. pero se debería acceder a dos. los accesos serían inmediatos a las dos únicas filas que cumplen este requisito. la de nombre Rafael y equipo Deportivo. solo se realizaría un acceso. ya que cuanto mayor sea esta estructura. se han realizado siete accesos. Sin embargo. podemos acceder a la página del libro de forma inmediata. que no permita valores repetidos). se deberá acceder a todas las filas. Cod_jugador 10 20 25 30 49 80 90 Nombre Adrián Fernando José Claudio Fernando Rafael Rafael Apellido Illie Redondo Guardiola López Hierro Alkorta M. es decir. deberemos ir mirando hoja por hoja hasta encontrar la página deseada. y que no van a ser alterados No indexar tablas pequeñas No indexar tablas que se van a recorrer secuencialmente . y que pertenezcan al Deportivo. es decir los atributos de una tabla que son clave que otras tablas Indexar aquellos atributos que se van a consultar con más frecuencia. las filas cuyo nombre es Rafael. Si ahora se desea buscar todas las filas con el nombre de Rafael. Sin embargo no todo son ventajas. se realizarían siete accesos (toda la tabla). se encontraría una única fila. mientras que si no lo tenemos. Ya se ha visto entonces la ventaja de usar este tipo de estructuras para acceder rápidamente a la información. Bilbao Deportivo Si en este momento se desea hacer una consulta sobre todos los jugadores que se llamen Fernando. Sin embargo si tuviésemos un índice combinado para los atributos Nombre y Equipo. Por ejemplo. sin contar el tiempo que se pierde en actualizar el índice cuando se modifica algún valor de los atributos que forman parte de él. reduciéndose en este caso el número de accesos a dos. es decir. Si tuviésemos un índice por el atributo Nombre. mayor espacio de almacenamiento será necesario. se suele indexar la clave primaria (mediante un índice único. Vázquez Tabla 24 Equipo Valencia R. si disponemos de dicho índice. es decir. Por este motivo. Madrid Barcelona Valencia R.

que se encuentran físicamente agrupadas. pero que lógicamente siguen siendo dos tablas independientes. es decir. Sin embargo. pero empeora cuando se recorren de forma separada. La técnica de compresión más utilizada es la de compresión diferencial. • Redundancia de datos: La redundancia de datos consiste en duplicar el valor de ciertos atributos de una tabla en otra. esta redundancia debe ser controlada. • Compresión de datos: Por un lado. que cambien el valor de todos los atributos duplicados. se requiere un mayor tiempo de proceso debido a la necesidad de descomprimir los datos que se recuperan. por lo que el agrupamiento será transparente al usuario. Diseño físico • • No indexar atributos de tipo carácter muy largos Agrupamiento o "clustering": Se entiende por "clustering" de tablas la agrupación de tablas cuyas filas comparten un grupo de atributos llamado clave de agrupamiento.© Grupo EIDOS 5. lo que radica en un menor número de operaciones de Entrada / salida. se debe garantizar la consistencia de la base de datos. cuando cambia uno de éstos. Esta técnica supone una desnormalización física de las tablas. Sin embargo. con el fin de evitar accesos a tablas consultadas frecuentemente. La Figura 35 muestra un agrupamiento de dos relaciones Empleado y Departamento. 61 . La forma más segura de controlarlo es mediante disparadores o triggers. que consiste en almacenar la diferencia entre el valor de un atributo y el que le precede. la compresión de datos permite reducir el espacio requerido para almacenar la información. Figura 35 Con este método se consigue mejorar la eficiencia en la consulta simultanea de ambas tablas.

.

actualización y borrado de tuplas de tablas. y se llama Server porque dispone de una parte servidora que se encarga de atender a los procesos clientes. que permite. índices. tanto el área de diseño. modificación y eliminación de bases de datos. desarrollado por Microsoft. y que son específicas para este producto. es decir. así como la consulta. atributos. . etc. tablas. Esto quiere decir que soporta el SQL de ANSI. proporcionando un interfaz bastante amigable con el usuario. como la de administración. pero además se le han añadido ciertas funciones adicionales. la gestión de un entorno de bases de datos relacional. que se denomina Transact SQL. no contempladas en el estándar. soporta la definición.Introducción a SQL Server ¿Qué es SQL Server? SQL Server es un Sistema de Gestión de Bases de Datos Relacionales (SGBDR). es decir. SQL Server utiliza una extensión al SQL estándar. que son los que realizan las peticiones a éste. ¿Por qué se llama SQL Server?. SQL Server abarca. el lenguaje de definición de datos (DDL). sigue una arquitectura cliente/servidor. el lenguaje de manipulación de datos (DML). El Transact SQL. éste no la entendería. como su propio nombre indica. Pues bien.. si ejecutamos una sentencia del conjunto adicional (Transact SQL) en otro SGBRD. se llama SQL porque utiliza este lenguaje para la definición y manejo de los datos. es decir. es decir.

llamado JDBC. Sin embargo. Por aquel entonces. SQL Server e Internet El impacto que.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Orígenes Como podemos comprobar. que fue la primera base de datos relacional en utilizar el lenguaje SQL. ante el boom del PC. a la vez que han ido apareciendo otros nuevos. se pueden mostrar datos en un navegador de Internet. pero en este caso se ofrecen una serie de funcionalidades especiales para adaptarlo al lenguaje Java. A su vez. se decidió cancelar el proyecto. La verdad es que las interfaces de acceso a bases de datos. pero ni por asomo podían ser utilizadas en los PCs. RSI lanzó al mercado la versión 2 de ORACLE. principios de los ochenta. A su vez. y le dieron el nombre de OS/2. Microsoft y Sybase. dirigido a las bases de datos. SQL Server fue avanzando. ha venido sufriendo el uso de Internet. Sin embargo. Mediante esta forma. Fue un poco más tarde cuando RSI decidió cambiar su nombre por el de su producto estrella. ante la falta de resultados positivos. la aparición de dBase. (RSI). ofrece una potente forma de unir SQL e Internet. los SGBD relacionales más vendidos resultan ser ORACLE y SQL Server. ODBC ofrece una serie de métodos encapsulados. originando una batalla para ganar posiciones en este mercado. supuso el nacimiento de un nuevo interfaz. En 1979. deciden aliarse para sacar un nuevo producto al mercado: una base de datos relacional. otra forma de acceder a una base de datos desde Internet es la ofrecida por un producto llamado Microsoft Internet Information Server (IIS). y venderlo a Relational Software Inc. Su cometido es el mismo que ODBC. La aparición de Internet. sobre todo con ORACLE. destinado a investigar el modelo relacional. para PC. Desde entonces y hasta hoy. Sin embargo. La combinación de éste con SQL Server. IBM y Microsoft se comprometieron a desarrollar un nuevo entorno. que significa Open Database Connection (Conexión abierta a Bases de Datos). ha sido siempre ODBC. IBM. adecuado al lenguaje Java. por aquel entonces algo utópico. adaptándose a las nuevas tendencias del mercado. ORACLE. El interfaz de acceso a bases de datos por excelencia. Cuando surgió aquella maquina que hoy denominamos PC. los cuales hacen todo el trabajo de traducción. el mercado de la informática ha ido cambiando sorprendentemente desde hace unos pocos años. y que supone la abstracción por parte del usuario que quiere acceder a la base de datos. obtenidos de una base de datos SQL. sobre todo durante estos últimos años. por ejemplo. también han ido experimentado un largo y constante cambio. Este hecho supuso el nacimiento de SQL-Server. En el año 1988. empezaban a implantarse las bases de datos relacionales. capaz de soportar SQL-Server. nadie podía imaginar que iba a desbancar de su puesto a las grandes plataformas como el Sistema 36 de IBM o el VAX de Digital. 64 . con el fin de adecuarse a las necesidades cambiantes del mercado. Fue entonces cuando la aparición de Windows NT reemplazó a OS/2 como soporte para SQL Server. Ashton-Tate. obliga a pensar si SQL Server puede ser útil para manejar y/o obtener datos de la red de redes. que no tiene por qué saber las características de ésta. supuso una revolución en el mundo de las bases de datos para PC. de Ashton-Tate. ORACLE fue el nombre que se le dio a un proyecto.

Lo nuevo en SQL-Server 2000 Introducción Como decíamos. Indexación de vistas. mejoras que pasamos a detallar a continuación. cabe destacar las siguientes: • • • • • Soporte para XML. Nuevas características Entre las nuevas características que ofrece SQL-Server 2000. Veremos en este capítulo las mejoras que ha sufrido esta nueva versión. La Figura 36 muestra la arquitectura general de este SGBD. La apuesta de Microsoft por este SGBD ha sido (y es) bastante fuerte. lo cual ha hecho posible la mejora y adaptación del mismo. con respecto a las anteriores. Soporte para Virtual Interface Architecture (VIA). SQL-Server ha ido evolucionando a lo largo de los últimos años. Particionamiento horizontal de relaciones y gestión de vistas distribuidas. Funciones de usuario. . sobre todo al entorno remoto y distribuido.

Bases de datos con SQL Server 2000 – Transact SQL

© Grupo EIDOS

• • • • • •

Nuevos tipos de datos. Nuevos triggers. Reglas de integridad referencial en cascada. Nuevas características de indexación. Soporte para consultas distribuidas. Características de seguridad y cifrado de datos.

Figura 36

Soporte para XML
El Extensible Markup Language, más conocido como XML es un metalenguaje, es decir, un lenguaje utilizado para definir lenguajes, y que se usa sobre todo para el intercambio de datos. Su sintaxis es similar a la que nos ofrece el HTML, es decir, un conjunto de etiquetas que definen la estructura de los datos. El Código fuente 2 define un posible formato de intercambio.
<cliente> <nombre>Pepe</nombre> <apellidos>Lopez</apellidos> <telefono>912345678</telefono> </cliente> Código fuente 2

66

© Grupo EIDOS

7. Lo nuevo de SQL - Server 2000

SQL-Server 2000 ofrece la posibilidad de devolver un conjunto de resultados utilizando para ello este tipo de formato, facilitando así el intercambio de datos.

Particionamiento horizontal de relaciones y gestión de vistas distribuidas
Otra de la características nuevas que nos ofrece SQL-Server 2000 es la posibilidad de particionar horizontalmente los datos de una relación. Ya se ha comentado lo útil que es este tipo de reestructuración de relaciones, sobre todo en el ambiente distribuido, en el cual se pueden colocar las tuplas en los servidores que se supongan más posibilidades tengan de consultarlas en forma local. Del mismo modo, se pueden definir vistas distribuidas que accedan a estos datos, en cada uno de los servidores que nos interese, de manera que la ejecución de la misma dé la impresión de estar interactuando sobre un conjunto completo de resultados.

Soporte para Virtual Interface Architecture (VIA)
SQL-Server 2000 introduce nuevas librerías de red, que permiten definir un entorno distribuido de forma eficiente, posibilitando una gran conectividad, tanto de servidores como de aplicaciones, en este tipo de entornos.

Funciones de usuario
Una funcionalidad nueva que aparece en esta versión del SGBD es la de permitir al usuario definir sus propias funciones. De esta forma se pueden definir funciones que oculten parte de la complejidad que puede entrañar una consulta, no sólo para la posterior reutilización de la misma, sino también teniendo en cuenta la abstracción para otros programadores que puedan precisar su uso.

Indexación de vistas
Esta funcionalidad permite optimizar la ejecución de vistas que actúan sobre la base de datos, creando índices sobre los resultados de ejecución de la misma, que son almacenados en la base de datos. El usuario no debe preocuparse de la actualización de los datos, sino que éstos son indexados automáticamente cada vez que se actualicen.

Nuevos tipos de datos
SQL-Server 2000 soporta tres nuevos tipos de datos con respecto a la anterior versión, la 7, que son el bigint o entero de 8 bytes, sql_variant, que soporta el almacenamiento de valores de distintos tipos, y table, que permite el almacenamiento temporal de resultados para su uso posterior.

67

Bases de datos con SQL Server 2000 – Transact SQL

© Grupo EIDOS

Nuevos triggers
Un trigger o desencadenador es un código especial que se ejecuta cuando se cumple una determinada condición, como por ejemplo al modificar o borrar datos (se verá en detalle en un capítulo posterior). SQL-Server 2000 soporta dos nuevos tipos de triggers, que son INSTEAD OF y que sustituye el comportamiento de ciertos comandos, como por ejemplo insert, update o delete, y AFTER, que se ejecuta una vez concluida la acción que lo ha desencadenado.

Reglas de integridad referencial en cascada
Las reglas de integridad referencial son la base del mantenimiento de la consistencia en la base de datos, y hacen referencia a información que esta relacionada entre si, como por ejemplo el departamento de un empleado cuyo código se especifica. La forma más usual de mantenerlo es usando claves foráneas, y especificando el comportamiento de las inserciones, borrados y actualizaciones de este tipo de datos.

Nuevas características de indexación
Las nuevas características de indexación permiten crear índices sobre campos calculados (no existen como tal en la base de datos, sino que se calculan a partir de otros valores), así como especificar si se desea construir estos índices de manera paralela, lo que aumenta la velocidad de procesado.

Soporte para consultas distribuidas
El optimizador de consultas ofrece la funcionalidad de ubicar datos en servidores distribuidos, dependiendo de valores tales como el nivel de carga, el tráfico de red, etc., de manera que las consultas pueden acceder a distintos servidores para obtener el resultado final.

Características de seguridad y cifrado de datos
SQL-Server 2000 utiliza Kerberos como servidor de autenticación, para acreditar el acceso al servidor que se realiza desde el cliente, así como diversas técnicas de seguridad.

68

Instalación de SQL Server 2000
En este capítulo, veremos como instalar SQL Server 2000, y las distintas opciones que plantea. Para empezar, introduzca el CD-ROM que contiene el programa. Si no arranca automáticamente, utilice el explorador para ejecutar el fichero autorun contenido en el CD-ROM. Tenemos dos opciones, la standard o la personal. La primera de ellas realiza una instalación completa, incluyendo los componentes servidor, mientras que la segunda es útil en el caso de que no dispongamos de un servidor. La primera pantalla que aparece es la que se muestra en la Figura 37.

Figura 37

Figura 38 Pulsamos el botón Next. visualizándose la pantalla que se muestra en la Figura 39. únicamente se instalarán los componentes cliente). pulsamos la opción SQL Server 2000 Components. apareciéndonos la pantalla que muestra la Figura 38.5 del navegador WEB Microsoft Internet Explorer. Para proseguir la instalación.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS En nuestro caso instalaremos la opción standard (si no disponemos de un servidor. en el cual se haya instalado la versión 5. el único requisito que se necesita es disponer de un equipo con al menos 64 Mb de memoria RAM (recomendable 128 Mb) y sistema operativo Windows 98/NT/2000. Figura 39 70 . En principio.

puesto que queremos instalar los componentes cliente en nuestro equipo local. donde se nos insta a poner nuestro nombre y compañía. Figura 41 71 . Pulsando el botón Next. Instalación de SQL . sólo nos permite la selección de esta opción. sólo se nos permite seleccionar la opción de crear una nueva instancia de SQL Server. Si pulsamos el botón Next.© Grupo EIDOS 8.Server 2000 En este caso. obtendremos la pantalla que se muestra en la Figura 41. al estar instalando la versión standard en un equipo con Windows 98. visualizaremos la siguiente pantalla que muestra la Figura 40 Figura 40 Nuevamente.

Figura 42 Figura 43 Seleccionando la opción de instalación de las herramientas cliente y pulsando el botón Next. accederemos a la pantalla de la Figura 44. cuyo cometido es el de mostrarnos las condiciones de uso de la licencia. pulsamos Yes para pasar a la siguiente pantalla que se indica en la Figura 43. podremos visualizar la pantalla que se muestra en la Figura 42. 72 . en la que podemos seleccionar los componentes y subcomponentes a instalar.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Si pulsamos nuevamente el botón Next.

Instalación de SQL . como muestra la Figura 46. Figura 45 73 . tras la cual el sistema empezará a instalar los componentes seleccionados y. tras unos minutos. mostrará la pantalla final en la cual se nos informa de la conclusión del proceso de instalación.Server 2000 Figura 44 Dejamos marcados los que vienen por defecto y pulsamos el botón Next.© Grupo EIDOS 8. para acceder a la página de la Figura 45.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 46 74 .

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

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 47 Figura 48 76 .

como la de la Figura 49. que se muestra en la Figura 50. para lo cual actuamos como se acaba de comentar. Nos aparecerá entonces una ventana.© Grupo EIDOS 9. El modelo E/R en Sql-Server 2000 Crear un nuevo diagrama Vamos a crear ahora un nuevo diagrama. Figura 49 Figura 50 77 . que no es más que la primera página de un asistente que nos guiará durante el resto del proceso de creación del diagrama. Pulsamos el botón Siguiente para avanzar al siguiente paso.

Esta opción es muy útil para chequear restricciones de una tabla que no sabemos con cuales se relaciona. y dándole un nombre coherente. Figura 51 Este es el último paso. tablas relacionadas de tablas relacionadas. en el que se nos muestran las tablas que hemos seleccionado. junto con el nombre de sus atributos. las claves (que aparecen con un icono en forma de llave). 78 . que se muestra en la Figura 51. mientras que en la derecha tenemos las tablas que nosotros seleccionaremos para pasar a formar parte de nuestro diagrama. La caja de selección que aparece en la parte inferior bajo el nombre Add related tables automatically permite añadir todas las tablas relacionadas con las seleccionadas de manera automática. Estas relaciones muestran las dependencias existentes entre ellas. Vamos a guardar nuestro diagrama. titleauthor y titles). habremos de pulsar el botón Remove. pudiendo además especificar el número de niveles que se incluirán. y las relaciones entre ellas. En el podemos observar las tablas que hemos seleccionado. La forma de añadir una tabla al diagrama es seleccionándola y pulsando el botón Add. pulsando el icono en forma de disco de la barra de herramientas. Una vez seleccionadas todas la tablas que deseamos pasen a formar parte del diagrama (en nuestro caso escogemos las tablas authors. que tendrá un aspecto similar al mostrado en la Figura 52. pulsamos el botón Siguiente para avanzar al próximo paso.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS En la parte izquierda nos aparecen todas las tablas disponibles. es decir. como el lector ya habrá podido adivinar. para trabajar posteriormente con el. y ya tenemos nuestro diagrama. mientras que para eliminarla del mismo. Pulsamos el botón Finalizar.

arrastrarlo hasta la tabla que contiene la clave primaria con la cual se relaciona. para establecer este tipo de reglas. En la pestaña Indexes/Keys es donde se especifican aspectos referentes a los índices que van a hacer referencia a los atributos de la tabla.© Grupo EIDOS 9. y cuyo aspecto es el mostrado en la Figura 54. apareciéndonos una pantalla similar a la de la Figura 53. Sin embargo. Para visualizar este tipo de características. 79 . Para ello debemos indicar el atributo que actúa como clave primaria dentro de la tabla origen. El modelo E/R en Sql-Server 2000 Figura 52 Restricciones e integridad referencial Una de las principales utilidades que nos ofrece esta herramienta es la de establecer las restricciones y las reglas de integridad referencial de una manera fácil y visual. que es seleccionar con el ratón el atributo que es clave ajena dentro de una tabla y. sin soltarlo. Dentro de la pestaña Relationship se pueden especificar restricciones y características tales como la integridad referencial. pulsamos con el botón derecho del ratón en la opción Propiedades (Properties) del menú contextual. dentro de la tabla o relación deseada. existe otra manera mucho más cómoda. y el atributo que actúa como clave ajena dentro de la tabla destino y le damos un nombre a dicha restricción.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 53 Figura 54 80 .

Para ello. especificando mediante una expresión regular que dicho atributo deberá ser rellenado con 9 dígitos. aunque también podemos especificar otro tipo de índices. en la Figura 55 se especifica una restricción sobre el atributo clave de la tabla. de tipo ascendente o descendente (se refiere a la ordenación). cluster.© Grupo EIDOS 9. crear nuevas relaciones. El modelo E/R en Sql-Server 2000 En esta pantalla podemos crear o borrar índices. Por ejemplo. como de tipo único. definidos sobre uno o varios atributos. etc. Figura 55 Modificación del esquema Aparte de definir restricciones. la herramienta de diagramas también nos da la posibilidad de realizar modificaciones del esquema. como muestra la Figura 56. esto es. El índice primario hará referencia a la clave primaria de la relación. nuevamente habrá que escoger la opción correspondiente haciendo click con el botón derecho del ratón. añadir o borrar tablas o atributos del diagrama (existentes o nuevas). 81 . y que se aplicará en las replicaciones. inserciones y actualizaciones. cambiar el tipo o el nombre de los mismos. etc. Dentro de la pestaña Check Constraints podemos indicar las restricciones sobre los atributos de la tabla.

como muestra la Figura 57. Si hacemos click derecho y escogemos la opción propiedades sobre la nueva relación creada. es pulsando sobre el y escribiendo directamente el nuevo sobre la tabla.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 56 Otra de las formas de modificar. mostradas en la Figura 60 Figura 57 82 . sólo tendremos que confirmarlo ante la pantalla que nos aparece en la Figura 58. Crear una nueva relación Una vez vistos los principales conceptos en la creación de diagramas. podemos observar las restricciones y las reglas de integridad aplicables a la misma. y escoger la pestaña Columns. vamos ahora a crear una nueva relación con una tabla existente. vamos a añadir la relación con una existente. Lo primero es seleccionar la opción Add Table del menú contextual y seleccionar la tabla existente en el esquema que deseamos añadir al diagrama. nos movemos a la tabla stores. Ya tenemos la relación entre ambas tablas. el nombre de un atributo. para practicar lo aprendido hasta ahora. sin soltarlo. Una vez que aparezca la tabla seleccionada en el diagrama. El diagrama resultante es el mostrado en la Figura 59. por ejemplo. o cambiar el tipo haciendo click derecho en el atributo y escogiendo la opción de propiedades. Para ello pulsamos con el ratón el atributo stor_id en la tabla authors y.

© Grupo EIDOS 9. El modelo E/R en Sql-Server 2000 Figura 58 Figura 59 83 .

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 60 84 .

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

Figura 61 Figura 62 En el menú Edit podemos encontrar las siguientes opciones: 86 . pero para todas las ventanas abiertas en el editor. Save all queries: Idem que el anterior.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • • • • • Save as: Idem que el anterior. Exit: Cierra el analizador de consultas. pero con la posibilidad de indicar un nombre de archivo. Recent file list: Muestra una lista con los archivos más recientemente usados. Print: Imprime la ventana en uso del editor.

etc. etc. El analizador de consultas • • • • • • • • • • • • Undo: Deshace el último cambio realizado en el texto de la ventana en uso del editor. rellenarla con las tablas. campos.© Grupo EIDOS 10. Select all: Selecciona todo el texto de la ventana en uso del editor. para cada uno de los casos más representativos (creación de vistas. Clear window: Borra todo el contenido de la ventana en uso del editor. Replace template parameters: Permite al usuario cambiar los parámetros dentro de una plantilla.). Replace: Reemplaza un texto por otro. Go to line: Mueve el cursor a una línea determinada. ahorrando al programador la mayor parte del trabajo. Paste: Pega el contenido del portapapeles a la ventana en uso del editor. es dccir. Además SQL-Server nos ofrece plantillas predeterminadas. pero para buscar varias coincidencias. procedimientos almacenados. o marcas dentro del texto de las sentencias a ejecutar. • • Figura 63 87 . muy util para sentencias repetitivas. que se ajusten a sus necesidades. Repeat last find: Idem que el anterior. Advanced: Opciones avanzadas de edición. dentro de la ventana en uso del editor. Find: Busca un texto determinado dentro de la ventana en uso del editor. Cut: Corta el texto seleccionado al portapapeles. Copy: Copia el texto seleccionado al portapapeles. para su mejor identificación. dentro de la ventana en uso del editor. Insert template: permite añadir una plantilla de una sentencias. Bookmarks: Permite manejar los bookmarks.

Current connection properties: Muestra información acerca de la actual conexión a la base de datos. etc. se muestran estadísticas de ejecución de la consulta. La Figura 65 indica un posible plan de ejecución para una consulta concreta. esta opción arranca un asistente para realizarlo. etc. en mosaico. Results to file: Si está marcada esta opción. esta opción muestra. navegar entre ellas. Cancel executing query: En el caso de que se esté ejecutando una consulta. Results in text: Si está marcada esta opción.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Dentro del menú Query nos encontramos con las opciones disponibles. Si la opción display estimated execution plan nos enseñaba el plan estimado. los resultados de la consulta serán mostrados en formato textual. La opción Window permite manejar las ventanas que se encuentran dentro del editor. Show server trace: Si esta opción está marcada. número de lecturas/escrituras. Index tunning wizard: Permite realizar el ajuste o “tunning” (cuyo concepto ya ha sido visto en los primeros capítulos) de los índices de una base de datos concreta. la opción de menú Tools muestra opciones referentes a herramientas que se pueden usar para configurar diversas opciones referentes al editor o ejecución de consultas. y mostrando errores si no cumple con ésta. La Figura 66 muestra una posible traza de ejecución en el servidor de una sentencia select de ejemplo. pasos de la ejecución. desglosando en pasos cómo se ejecutará la consulta. se muestra información acerca de la traza de ejecución de la consulta en el servidor. vista desde la parte cliente. relacionadas con la edición y ejecución de consultas: • • • • • Change Database: Permite cambiar la actual conexión a una base de datos por otra. como cuestiones diversas sobre T-SQL. verificando su sintaxis. Results in grid: Si está marcada esta opción. consumo de procesador. para colocarlas en cascada. 88 . Show execution plan: Si esta opción esta marcada. Una posible estadística es la mostrada en la Figura 67. Por último la opción Help ofrece una completa ayuda tanto del editor. Parse: Compila la consulta del editor. se muestra el plan de ejecución de la consulta. es decir. Execute: Ejecuta la consulta del editor. el plan real de ejecución de ésta. permite detenerla. En particular. los resultados de la consultas serán enviados a un archivo. los resultados de la consulta serán mostrados en una rejilla o grid. separados por filas y columnas. junto con los resultados. Display estimated execution plan: Muestra el plan previsto. una vez realizada. Show client statistics: Si esta opción está marcada. • • • • • • • • Por su parte.

El analizador de consultas Figura 64 Figura 65 89 .© Grupo EIDOS 10.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 66 Figura 67 90 .

Muestra el plan estimado de ejecución de la consulta Muestra una lista de los objetos del sistema Permite realizar una búsqueda de los objetos del sistema Muestra información acerca de la actual conexión Muestra el panel de resultados de la ejecución de la consulta 91 . trazas de servidor y estadísticas de cliente). rejilla o archivo) y la información adicional (plan de ejecución. Permite seleccionar la base de datos. Ejecuta la consulta. Abre una consulta existente en un archivo Guarda la consulta del editor en un archivo Introduce una plantilla de consulta en el editor Corta el texto seleccionado al portapapeles Copia el texto seleccionado al portapapeles Pega el texto almacenado en el portapapeles Borra el contenido de la ventana del editor Busca un texto determinado en la consulta del editor Deshace el último cambio realizado en la consulta del editor Permite seleccionar la forma en que se mostrarán los resultados (en texto. El analizador de consultas La barra de herramientas Crea un nueva consulta. pudiendo utilizar para ello una plantilla.© Grupo EIDOS 10. Compila la consulta para verificar su sintaxis. Detiene la ejecución de una consulta.

Para ello accederemos al analizador de consultas. SELECT * FROM titles Código fuente 3 A continuación ejecutamos la sentencia. Escogemos una de ellas. o tecleando F5. y dentro del editor tecleamos el Código fuente 3. En ella podemos apreciar como se nos ha dividido el editor en dos partes. La de arriba contiene la sentencia a ejecutar. y lo que nos aparece ahora es una ventana como la que muestra la Figura 70. Ejecutamos nuevamente.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Ejecutando una consulta Pongamos ahora en práctica los conceptos aprendidos ejecutando una consulta sencilla (no debe preocuparse si todavía no entiende nada de código. mientras que la de abajo muestra los resultados de la ejecución de la misma. Probemos ahora a mostrar los resultados en forma de tabla. tecleando el servidor (si no se pone nada se accederá al servidor local) y el login y password. por ejemplo pubs. 92 . Lo que nos aparecerá será una ventana como la de la Figura 69. Figura 68 Una vez hecho esto. como muestra la Figura 68. Para ello seleccionamos la opción Results in grid del menú Query. cuyo cometido es mostrar todos los valores de todos los atributos de la tabla titles. haciendo click en el botón en forma de flecha verde de la barra de herramientas. ya que entraremos en detalle en posteriores capítulos). ya tenemos acceso a todas las bases de datos existentes en el servidor. escogiendo la opción Execute del menú Query.

© Grupo EIDOS 10. con una salvedad. Esta pestaña no sólo sirve para visualizar el 93 . nombrada como Messages. el mensaje que indicaba el número de registros devueltos aparece ahora en otra pestaña en la parte inferior. ahora nos aparece en un grid. El analizador de consultas Figura 69 Figura 70 En ella podemos observar como lo que antes nos aparecía en forma de texto.

tal como se puede observar en la Figura 71. y escogiendo un nombre para el mismo. Figura 72 94 . como muestra la Figura 72. Figura 71 Por último. sino muestra otro tipo de mensajes.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS número de registros seleccionados. para lo cual seleccionaremos la opción Save as del menú File. como por ejemplo los de error. guardaremos nuestra pequeña consulta en un archivo.

El analizador de consultas Otra de las posibilidades que nos ofrece SQL-Server es la de exportar los datos que hayamos obtenido en una consulta.© Grupo EIDOS 10. seleccionamos con el ratón el rango de resultados que deseemos exportar y hacemos clic con el botón derecho del ratón para seleccionar la opción Save as. Figura 73 95 . y la forma de exportación y separación de campos. Para ello. Nos aparecerá una ventana como la de la Figura 73. en la que deberemos dar un nombre al archivo. y estando en el modo de Results in grid.

.

Tipos de datos Existe una amplia variedad de tipos de datos que podemos utilizar en Transact SQL. añadir. o borrar información. actualizar. con diferente cometido. existen dos tipos de sentencias. que permiten mantener dicho esquema: • • Lenguaje de Manipulación de Datos (DML): permite manipular los datos del esquema relacional. tablas. dejando el primero para otro posterior. En este capítulo se verá este último. . Si el lector encuentra alguna terminología un tanto desconocida. no se preocupe. etc. es decir. La Tabla 25 muestra una descripción de éstos. Estos tipos de datos serán utilizados a la hora de definir los atributos de una tabla.El lenguaje de definición de datos (DDL) Introducción Como ya se vio en la anterior parte acerca del diseño de esquemas relacionales. es decir. consultar. Lenguaje de Definición de Datos (DDL): permite establecer y/o modificar el esquema relacional. borrar o actualizar atributos. ya que en un próximo capítulo se describirán con detalle los operadores básicos que ofrece Transact SQL. así como algunas consideraciones acerca del lenguaje. índices.

147.23E-308 hasta -1.647 Tamaño 4 bytes 8 bytes Desde -32.18E-38 hasta -3. 8 bytes real numérico de coma flotante con redondeo.5508 cuatro decimales. 4 bytes char(n) Alfanumérico de longitud fija Alfanumérico de longitud variable Moneda. Precisión positiva: desde 2. Espacio consumido fijo. Declarable hasta un máximo 1 byte por carácter de 255 caracteres declarado. Números con Desde una precisión de 922.685.5507 4 bytes 98 .767 2 bytes 1 byte de 2 a 17 bytes dependiendo de la precisión especificada Entero minúsculo (sin Desde 0 hasta 255 signo) decimal exacto sin redondeo Enteros y decimales desde 1.40E38 hasta +3.447.18E-38 hasta 3.447.s) Descripción Entero Entero largo Entero corto Rango de valores Desde -2.685. Precisión positiva: desde 1.483.79E308 hasta +1. Doble precisión. donde n está comprendido entre 1 y 7.40E38.79E308 en donde p es el número de dígitos de la parte entera (precisión) y s es el de la parte decimal (escala) Redondeos de números desde -1. Simple precisión. hasta 922.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Identificador en SQL Server Int bigint Smallint Tinyint numeric(p.79E308 Redondeos de números desde -3.s) decimal(p.40E38 Precisión negativa: desde 1.768 hasta 32. donde n está comprendido entre 8 y 15.483. Declarable hasta un máximo 1 byte por carácter de 255 caracteres usado. Números con una precisión de cuatro decimales. Espacio consumido variable 8 bytes varchar(n) money smallmoney Moneda.23E-308 hasta 1.79E308.337.648 hasta +2.79E308 hasta +1.203.147.79E308 Precisión negativa: desde 2.40E38 float(n) numérico de coma flotante con redondeo.203.337.

Tabla 25 Creación de tablas Una de las principales sentencias de definición de datos es la de creación de una tabla. Su sintaxis es la siguiente: CREATE TABLE tabla (atributo tipo) La ejecución de esta sentencia. El lenguaje de definición de datos (DDL) datetime Fecha y hora para fechas históricas Desde 1-enero-1753 hasta 8 bytes 31-diciembre-9999. El nombre de la tabla debe ir después de la palabra TABLE. genera como resultado una nueva tabla. El nombre de los 99 . El dato horario se guarda como número de milisegundos desde la medianoche del día en cuestión Desde 1-enero-1900 hasta 4 bytes 06-junio-2079.© Grupo EIDOS 11. El dato horario se guarda como número de milisegundos desde la medianoche del día en cuestión Máximo de 255 bytes de longitud Máximo de 255 bytes de longitud Máximo de 2 Gigabytes de longitud Máximo de 2 Gigabytes de longitud n bytes. Campo para guardar imágenes de hasta 2 Gigas Sql_variant table bit Tipo bit 0ó1 Almacena datos de distintos tipos Almacena datos temporales Desde 1 bit mínimo reutilizado a partir del espacio de otra columna hasta 1 byte máximo si la columna fuera única. en la base de datos en la que estemos conectados. sean usados todos o no n bytes como máximo Máximo 2 GB Máximo 2 GB smalldatetime Fecha y hora para uso corriente binary(n) varbinary(n) text image Campo binario de longitud fija Campo binario de longitud variable Campo para texto largo de tipo Memo.

el propietario de la base de datos. al crearse los campos de la tabla con este valor. ALTER TABLE tabla ADD atrib tipo NULL Código fuente 6 Nótese que el nuevo atributo añadido debe ser de tipo NULL. a la tabla tabla1. 100 . es necesario modificar un parámetro de SQL Server. ya que si no se permiten valores nulos. deberemos ejecutar el Código fuente 5. añadir atributos. o cambiar la definición. ALTER TABLE tabla1 ADD atributo1 varchar(30) NULL Código fuente 7 Sólo pueden modificar las tablas el administrador. true Código fuente 5 Modificación de tablas Entendemos por modificar una tabla. si queremos añadir un atributo atributo1 de tipo varchar(30). y el propietario de la tabla. deberíamos ejecutar el Código fuente 7.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS atributos deberá ir entre paréntesis. sp_dboption base_datos. SELECT * INTO tabla1 FROM tabla2 Código fuente 4 La anterior sentencia. es decir. especificando el tipo. Otra opción nos permite cargar un número de filas de otra tabla. La sentencia que permite modificar una tabla es la que muestra el Código fuente 6. Si existe más de un atributo. se produciría un error. Por ejemplo. se deberán separar por comas. Para ello. cargando su estructura. para poder utilizar esta opción. borrarlos. lo que haría sería volcar el contenido de la tabla tabla2 en la tabla tabla1. Sin embargo. 'select into/bulkcopy'. La sentencia encargada de esto la vemos en el Código fuente 4. cambiar su estructura.

por el campo cod_cliente. o el propietario de la misma. ésta no debe estar siendo usada. se debe realizar junto con la creación de la estructura de las tablas. Creación y borrado de índices La creación de índices en SQL Server. aunque la base de datos esté cargada. SQL Server permite la creación de índices. El lenguaje de definición de datos (DDL) Borrado de tablas La sentencia que borra una tabla aparece en el Código fuente 8. CREATE UNIQUE INDEX codigo ON todos (cod) WITH IGNORE_DUP_KEY Código fuente 11 101 . cod2) Código fuente 9 Esta sentencia permite añadir una clave primaria en tabla. ALTER TABLE tabla ADD CONSTRAINT K1 PRIMARY KEY (cod1. denominado Código. si creamos un índice único por un campo. se debe ejecutar el Código fuente 11. Para poder borrar una tabla. Por ejemplo. Además sólo podrá borrar una tabla el administrador. se debe especificar el Código fuente 10. esto es no puede admitir duplicados. Para crear un índice en la tabla todos. De este modo se evitan posibles colisiones que pueden surgir al crear índices cuando la tabla ya tiene datos. la generación del índice daría un error. debe ir a continuación de la palabra reservada TABLE.© Grupo EIDOS 11. En este caso deberemos hacer un SELECT de otra tabla para liberarla. DROP TABLE tabla Código fuente 8 El nombre de la tabla que se borra. y se encuentran valores no únicos. CREATE INDEX codigo ON todos (cod_cliente) Código fuente 10 Sí además queremos que el índice no admita valores nulos. Sin embargo. así como en la mayoría de los SGBDR existentes. por los campos cod1 y cod2.

se muestra en el Código fuente 12.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS La sentencia que se encarga de borrar un índice. Esta sentencia se encarga de borrar el índice código creado anteriormente. DROP INDEX codigo Código fuente 12 102 .

Interesará almacenar por cada una de las ofertas la siguiente información: un código de identificación. plasmado en el analizador de consultas de SQL-Server 2000. si se encuentra en venta o alquiler y el precio del mismo. La sentencia SQL que nos permite crear esta tabla se muestra en el Código fuente 14: .Ejemplos prácticos de uso del DDL Introducción Se verán en este capítulo una serie de ejemplos para poner en práctica los conceptos aprendidos en el anterior. la definición de estos esquemas nos servirá como base para utilizar el lenguaje de manipulación de datos en próximos capítulos. la provincia y el domicilio donde se encuentra. se procederá a continuación a crear una tabla destinada a contener información acerca de las ofertas disponibles en una agencia inmobiliaria. Recordamos su sintaxis en el Código fuente 13. Además. CREATE TABLE tabla (atributo tipo) Código fuente 13 Por ejemplo. La sentencia CREATE TABLE Esta sentencia es la que permite la creación de nuevas tablas dentro de una base de datos. para afianzar al lector en el uso del lenguaje de definición de datos. el tipo de bien inmueble al que pertenece.

[OF_Tipo] [varchar] (50) NOT NULL . El diagrama de la Figura 74 mostraría el esquema resultante. la tabla que hemos creado más arriba puede dar problemas. Figura 74 DROP TABLE Oferta GO CREATE TABLE [dbo].Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS CREATE TABLE [dbo].[Oferta] ( 104 . [OF_Provincia] [varchar] (50) NOT NULL . por ejemplo. [OF_Precio] [int] NOT NULL ) ON [PRIMARY] Código fuente 14 Sin embargo.[ComunidadAutonoma] ( [CA_ID] [int] NOT NULL PRIMARY KEY. no podremos crear un tipo de bien inmueble nuevo hasta que no dispongamos de un bien con esas características. y el Código fuente 15 las sentencias a ejecutar para conseguirlo. Por lo tanto procederemos a crear una tabla para los tipos de bienes y otra para las provincias (que a su vez se relacionará con una tabla de comunidades autónomas). [OF_Direccion] [varchar] (50) NOT NULL . utilizando la sentencia drop table (aprenderemos como modificar un esquema en el siguiente epígrafe).[Oferta] ( [OF_ID] [int] NOT NULL PRIMARY KEY . [CA_Nombre] [varchar] (50) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo]. Para ello primero borramos el esquema creado anteriormente. [OF_Transaccion] [varchar] (50) NOT NULL . ya que no esta normalizada.

[Cliente] ( [Cli_NIF] [char] (10) NOT NULL PRIMARY KEY. provincia. CREATE TABLE [dbo]. [Com_Nombre] [varchar] (50) NOT NULL . teléfono y sus datos bancarios (nos bastará con el CCC de la cuenta bancaria). código postal. [Cli_Direccion] [varchar] (50) NOT NULL . [OF_Transaccion] [varchar] (50) NOT NULL . [OF_Direccion] [varchar] (50) NOT NULL . para cada uno de ellos. [Prv_ID] [int] NOT NULL . se necesitará también conocer los datos personales de los clientes que están suscritos a nuestra agencia. [Com_Telefono] [char] (9) NOT NULL . CREATE TABLE [dbo]. [Com_Categoria] [varchar] (10) NOT NULL ) ON [PRIMARY] GO Código fuente 16 Al igual que para los comerciales. [Com_Direccion] [varchar] (50) NOT NULL . [TB_Nombre] [varchar] (50) NOT NULL ) ON [PRIMARY] GO Código fuente 15 Supongamos ahora que se desea tener constancia de los datos personales de los comerciales que trabajan en dicha agencia. conociendo por cada uno de ellos su NIF. teléfono y categoría. [Com_Apellidos] [varchar] (50) NOT NULL . [Prv_Nombre] [varchar] (50) NOT NULL ) ON [PRIMARY] GO CREATE TABLE [dbo]. la siguiente información: NIF (que de momento hará las veces de clave primaria de la tabla).[Provincia] ( [Prv_ID] [int] NOT NULL PRIMARY KEY. [Cli_CodPostal] [char] (5) NOT NULL . [CA_ID] [int] NOT NULL . [Cli_CCC] [varchar] (30) NOT NULL 105 . nombre y apellidos. como muestra el Código fuente 16 . [Prv_ID] [int] NOT NULL . dirección. Ejemplos prácticos de uso del DLL [OF_ID] [int] NOT NULL PRIMARY KEY.[Comercial] ( [Com_NIF] [char] (10) NOT NULL PRIMARY KEY. [Com_CodPostal] [char] (5) NOT NULL . [Cli_Nombre] [varchar] (50) NOT NULL . [Cli_Apellidos] [varchar] (50) NOT NULL . [OF_Precio] [int] NOT NULL ) GO CREATE TABLE [dbo]. código postal. provincia. [Prv_ID] [int] NOT NULL . necesitando almacenar.© Grupo EIDOS 12. siendo en NIF la clave primaria de la tabla. nombre y apellidos. como muestra el Código fuente 17. [Cli_Telefono] [char] (9) NOT NULL .[TipoBien] ( [TB_ID] [int] NOT NULL PRIMARY KEY. dirección. [TB_ID] [int] NOT NULL .

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS ) ON [PRIMARY] GO Código fuente 17 Hasta el momento. y que son los transportes públicos más cercanos de los cuales dispone.[TipoTransporte] ( [TT_ID] [int] NOT NULL PRIMARY [TT_Nombre] [varchar] (30) NOT ON [PRIMARY] GO CREATE TABLE [dbo]. podemos darnos cuenta de que falta una cosa bastante importante para ubicar el inmueble. que almacenará las estaciones o paradas para cada tipo de los mencionados (por ejemplo Legazpi y Pacífico para metro y Fanjul y Móstoles para cercanías). Nos podemos plantear esta información como dos tablas: una de tipos de transporte (por ejemplo metro y cercanías RENFE) y otra de transportes en sí. NULL. como muestra el diagrama de la Figura 76 y el Código fuente 18. el diagrama de la Figura 75 muestra la situación actual en la que se encuentra nuestro esquema relacional: Figura 75 Sin embargo. CREATE TABLE [dbo].[Transporte] ( [Tr_ID] [int] NOT NULL PRIMARY [Tr_Nombre] [varchar] (30) NOT [TT_ID] [int] NOT NULL ) ON [PRIMARY] GO KEY. NULL ) KEY. Código fuente 18 106 .

© Grupo EIDOS 12. e importa la clave de esta última tabla). necesitando los siguientes atributos: el código postal (que actuará como clave primaria de la tabla) y la provincia (ya que una misma provincia dispondrá de distintos códigos postales. [CP_Codigo] [char] (5) NOT NULL PRIMARY KEY ) ON [PRIMARY] GO Código fuente 19 La sentencia ALTER TABLE Como ya se explicó. así que daremos también de alta esta tabla. para posibles clasificaciones de inmuebles o futuras estadísticas. Ejemplos prácticos de uso del DLL Figura 76 En un momento dado nos puede interesar la posibilidad de tener almacenados en la base de datos todos los códigos postales. Su sintaxis es la descrita en el Código fuente 20: ALTER TABLE tabla ADD atrib tipo NULL Código fuente 20 107 . esta sentencia permite la modificación del esquema o la estructura de una tabla ya creada.[CodigosPostales] ( [Prv_ID] [int] NOT NULL. como nos indica el Código fuente 19 CREATE TABLE [dbo]. es una relación 1-N.

los comerciales aparecen desconectados de las ofertas de bienes. lo que hace que se importe el atributo clave de la tabla de comerciales como muestra el diagrama de la Figura 77. para de este modo conocer qué comerciales han intervenido en la compra/alquiler de qué inmuebles. ALTER TABLE [dbo]. podemos darnos cuenta de varios aspectos del esquema que no son del todo correctos. Pero ya que tenemos esa tabla y. por lo que no mucho sentido. Esto puede ser muy útil a la hora de calcular comisiones o prever promociones. etc.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Volviendo sobre el ejemplo de la agencia desarrollado en el anterior epígrafe. por ejemplo. la relación entre tablas. y que se podrían mejorar. Para conseguir esta característica adicional en nuestro esquema. pero un inmueble sólo puede ser gestionado por un comercial). Esto es así debido a la relación 1-N que existe entre ambas tablas (un comercial interviene en la transacción de muchos inmuebles. podremos conseguir información de valor añadido si conectamos la tabla de ofertas a la de comerciales. será necesario añadir un atributo más a la tabla de ofertas que la relacione con el comercial. Figura 77 Sin embargo esto nos obliga a modificar el esquema.[Oferta] ADD [Com_NIF] [char] (10) GO Código fuente 21 108 . Así. a no ser que sólo nos interesen dichos datos a título informativo. con objeto de añadir este nuevo atributo a la tabla de ofertas existente como muestra el Código fuente 21. puesto que el modelo relacional es eso.

[Oferta] ADD [Cli_NIF] [char] (10) GO ALTER TABLE [dbo]. El caso de la tabla de transportes es algo especial. [Tr_ID] [int] NOT NULL ) ON [PRIMARY] GO Código fuente 24 Sin embargo esta tabla dispone de una clave primaria compuesta. se necesita modificar el esquema de la base de datos. así que se utilizará. Si recordamos lo que ocurría con este tipo de relaciones. Ejemplos prácticos de uso del DLL Sin embargo nos encontramos con un problema. así que deberemos ejecutar una segunda sentencia. La conexión entre ambas tablas es similar al caso anterior. se creaba una tabla intermedia que importaba las claves de ambas. que a su vez puede estar próxima a otros inmuebles. formada por ambos atributos. para controlar los pagos. ALTER TABLE [dbo]. haremos lo mismo con la tabla de códigos postales. es un claro ejemplo de relación N-M. nos interesaría saber qué clientes han comprado/alquilado qué inmuebles. El Código fuente 24 muestra la forma de hacerlo: CREATE TABLE [dbo].[OfertaTransporte] WITH NOCHECK ADD CONSTRAINT [PK_OfertaTransporte] PRIMARY KEY NONCLUSTERED ( [Of_ID]. que modifique el atributo añadido para que no pueda tomar valores nulos (ya que es una clave ajena): ALTER TABLE [dbo].[OfertaTransporte] ( [Of_ID] [int] NOT NULL .© Grupo EIDOS 12. de un modo similar.[Oferta] alter column [Cli_NIF] [char] (10) not null GO Código fuente 23 Siguiendo el mismo razonamiento. enviarles facturas. así que se deberá ejecutar el Código fuente 25 para modificar el esquema de forma que se añada una restricción en forma de clave primaria a dicha tabla: ALTER TABLE [dbo]. ya que para un mismo inmueble pueden existir más de una estación de metro cercana. [Tr_ID] ) ON [PRIMARY] GO Código fuente 25 109 . etc. y es que no podemos añadir un nuevo atributo con la propiedad not null. la sentencia alter table (véase el Código fuente 23).[Oferta] alter column [Com_NIF] [char] (10) not null GO Código fuente 22 Igual que para los comerciales. Y al igual que en el anterior caso también.

[Oferta] ( [OF_ID] ).[Provincia] ( [Prv_ID] ).[Transporte] ADD CONSTRAINT [FK_Transporte_TipoTransporte] FOREIGN KEY ( [TT_ID] 110 .[Provincia] ADD CONSTRAINT [FK_Provincia_ComunidadAutonoma] FOREIGN KEY ( [CA_ID] ) REFERENCES [dbo].[Oferta] ADD CONSTRAINT [FK_Oferta_Cliente] FOREIGN KEY ( [Cli_NIF] ) REFERENCES [dbo].[ComunidadAutonoma] ( [CA_ID] ) GO ALTER TABLE [dbo].[Transporte] ( [Tr_ID] ) GO ALTER TABLE [dbo]. CONSTRAINT [FK_Oferta_Provincia] FOREIGN KEY ( [Prv_ID] ) REFERENCES [dbo].[TipoBien] ( [TB_ID] ) GO ALTER TABLE [dbo]. o insertar tipos que no estén dados de alta en las tablas maestras que los tipifican.[Cliente] ( [Cli_NIF] ). CONSTRAINT [FK_OfertaTransporte_Transporte] FOREIGN KEY ( [Tr_ID] ) REFERENCES [dbo]. CONSTRAINT [FK_Oferta_Comercial] FOREIGN KEY ( [Com_NIF] ) REFERENCES [dbo]. Ejecutando el Código fuente 26 podremos estar seguro de esto: ALTER TABLE [dbo].Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Sin embargo no debemos olvidarnos de un aspecto muy importante. que es el de las claves ajenas y las restricciones.[Comercial] ( [Com_NIF] ). para no tener problemas de borrar una tupla de una tabla que sea clave ajena en otra relación. CONSTRAINT [FK_Oferta_TipoBien] FOREIGN KEY ( [TB_ID] ) REFERENCES [dbo]. Deberemos relacionar todas las tablas de manera que se establezca una relación entre las claves ajenas que unen las relaciones.[OfertaTransporte] ADD CONSTRAINT [FK_OfertaTransporte_Oferta] FOREIGN KEY ( [Of_ID] ) REFERENCES [dbo].

Ejemplos prácticos de uso del DLL ) REFERENCES [dbo]. Con todo esto. seguido de las palabras foreign key y a continuación las referencias a los atributos que son clave en sus relaciones.[TipoTransporte] ( [TT_ID] ) GO Código fuente 26 Como podemos ver. obtenemos el esquema relacional que se muestra en el diagrama de la Figura 78: Figura 78 La sentencia DROP TABLE Permite el borrado de una tabla existente en la base de datos. poniendo el nombre de la tabla donde se encuentra el atributo que es clave ajena.© Grupo EIDOS 12. la forma de introducir claves ajenas en la base de datos es mediante restricciones. y su sintaxis es la que se muestra en el Código fuente 27: DROP TABLE tabla Código fuente 27 111 .

como será el caso. 112 . por contra. Es más. Sin embargo y. Pues bien.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Retomando el ejemplo que nos lleva en este capítulo. puede dificultarnos la gestión de la base de datos. o crear dos por separado. ya que un índice es una estructura que si bien acelera las consultas. Si suponemos que la mayoría de las consultas se realizarán por ambos criterios. depende de las consultas que se vayan a realizar. Veamos que índices podemos crear en el ejemplo que nos lleva este capítulo. podemos adivinar que la tabla crítica para realizar consultas será la de ofertas. como muestra el Código fuente 28: Drop table CodigosPostales Código fuente 28 La sentencia CREATE INDEX La sintaxis que permite la creación de índices sobre tablas es la especificada en el Código fuente 29: CREATE [UNIQUE] INDEX indice ON tabla (atributos) Código fuente 29 Recordemos cual es el cometido de un índice. ya que la información que se precisa para un inmueble. La siguiente decisión es considerar si crear un único índice con estos dos atributos. de momento. podemos intuir que la mayoría de las consultas de dicha tabla involucrarán a los atributos precio y tipo de transacción (alquiler o venta). y su sintaxis es la que se muestra en el Código fuente 31. Sin embargo. la mayoría de las consultas se realizaran por precio o por tipo de transacción. no recoge este dato como algo necesario. Por ejemplo. conviene crearlos por separado de la siguiente forma: CREATE INDEX oferta1 ON Oferta (Of_Transaccion) GO CREATE INDEX oferta2 ON Oferta (Of_Precio) GO Código fuente 30 La sentencia DROP INDEX Permite el borrado de un índice creado para una tabla. es una decisión del diseñador el establecer los índices oportunos para que el rendimiento de la misma no se vea afectado. convendría crear un único índice con ambos atributos. podemos observar que la tabla de código postales. que no es otro que el de acelerar las consultas que se realizan sobre una base de datos. así que procederemos a su borrado. no nos aporta nada. puede llegar a ralentizar las actualizaciones de datos.

Ejemplos prácticos de uso del DLL DROP INDEX codigo Código fuente 31 Si en nuestro caso deseáramos borrar el índice oferta2 creado anteriormente.oferta2 Código fuente 32 La salvedad es que debemos indicar el código del índice de la forma tabla.© Grupo EIDOS 12. para evitar ambigüedades. 113 .indice. deberíamos ejecutar: drop index Oferta.

.

y lo encerrado entre corchetes es opcional. Su sintaxis es la siguiente: SELECT <atributos> FROM <tablas> [WHERE <condicion>] [GROUP BY <atributos>] [HAVING <condición>] [ORDER BY <atributos>] Donde las mayúsculas representan palabras reservadas. que es el que permite definir y modificar la estructura de un esquema. que nos permite. el de manipulación de datos.El lenguaje de manipulación de datos (DML) Introducción Ya se ha visto en un capítulo anterior el lenguaje de definición de datos (DDL). La sentencia Select La sentencia Select es una sentencia SQL. que pertenece al conjunto del Lenguaje de Manipulación de Datos. vamos a detenernos en la sintaxis de la sentencia Select. Una vez vista la anterior forma de representación. de una o varias bases de datos. Veremos a continuación el otro lenguaje. puede ser omitido. como su propio nombre indica. Se compone de tres partes: . y que sirve para recuperar registros de una o varias tablas. manejar los datos contenidos en el esquema.

será conveniente denotar los campos de la cláusula SELECT precedidos por el nombre de la tabla donde se encuentra y un punto. éstas irán separadas por comas. WHERE <condición>: permite establecer una condición de recuperación de las filas de la/s tabla/s. Sólo se obtendrán aquellas tuplas que verifiquen dicha condición. Si se especifica más de una tabla. deberíamos escribir el Código fuente 34. SELECT title. ORDER BY <atributos>: permite obtener el resultado de la consulta ordenado por los atributos especificados. GROUP BY <atributos>: permite establecer una selección de campos cuando se utilizan funciones escalares o de conteo (ya se verá más adelante lo que significa. price FROM titles Código fuente 33 De esta manera. se recuperarán todas las filas. en la cláusula FROM. 116 . Si se especifica el símbolo *. se sepa en cada momento a cual de ellos nos estamos refiriendo. SELECT * FROM titles Código fuente 34 Puesto que hemos especificado el literal * dentro de la cláusula SELECT. es decir. Si por ejemplo. deseamos obtener todos los atributos de dicha tabla. obtenemos todas las filas. FROM <tablas>: permite especificar la tabla de la cual se desean obtener los datos. seleccionar los campos que deseamos recuperar de la base de datos. En el caso de que se omita esta parte. deseamos obtener todos los valores de los atributos title y price de la tabla titles. para que. la anterior sentencia nos devuelve todos los atributos de todas las filas de la tabla titles. es decir. nos devuelve toda la información almacenada en ella. Si por el contrario.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • SELECT <atributos>: permite hacer una proyección de las tablas. HAVING <condición>: establece una condición para los atributos obtenidos como resultado de la aplicación de funciones escalares. separados por comas. deberíamos escribir el Código fuente 33. en el caso de que dicho campo exista en más de una tabla. de la tabla titles (especificada en la cláusula FROM). ya que no hemos dado ninguna condición. que será opcional. de las cuales sólo visualizaremos los valores de los atributos title y price (especificados en la cláusula SELECT). evitando en este caso el problema de ambigüedad. • • • • • En el caso de que se especifiquen varias tablas. se obtendrán todos los campos de la tabla.

A continuación de esta palabra reservada. pero básicamente son los siguientes: • • • • • • • • • : compara si una expresión es mayor que otra < : compara si una expresión es menor que otra >= : compara si una expresión es mayor o igual que otra <= : compara si una expresión es menor o igual que otra <>: compara si una expresión es distinta que otra LIKE : compara todas las cadenas que verifican un patrón de búsqueda NOT LIKE : compara todas las cadenas que no verifican un patrón de búsqueda BETWEEN : compara todas las cadenas que están comprendidas en un rango de valores IN : compara todas las cadenas que están contenidas en una lista Por ejemplo. y que a continuación tenga el literal 'urry'. El lenguaje de manipulación de datos (DML) La cláusula Where La forma de usar el Transact SQL para realizar consultas realizando una proyección horizontal (es decir. Para expresar una expresión lógica se pueden emplear cualquiera de los operadores de Transact SQL cuyo resultado devuelva un valor lógico. seleccionando las filas). si queremos obtener todos los títulos cuyo precio no supere los 2$. ejecutaremos el Código fuente 36. si queremos obtener los títulos cuyos derechos de autor sean mayores del 10 %. SELECT * FROM titleauthor WHERE royaltyper > 10 Código fuente 35 SELECT * FROM titles WHERE price <= 2 Código fuente 36 Si queremos obtener el nombre de los autores cuya primera letra este comprendida entre la C y la H. Estos operadores serán vistos en detalle en el siguiente capítulo. aunque también se pueden utilizar operadores de cadena.© Grupo EIDOS 13. para obtener aquellas filas que la cumplen. SELECT au_fname FROM authors WHERE au_fname LIKE '[C-H]urry' Código fuente 37 117 . ejecutamos el Código fuente 37. De la misma forma. es mediante la opción WHERE. se debe especificar la condición lógica que se debe evaluar. teclearemos el Código fuente 35.

y a continuación mostrar los grupos.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS O si queremos obtener la ciudad de todos los autores. 118 . ejecutamos el Código fuente 40. filas que tienen el mismo valor para un atributo. que se corresponda con San Francisco o con Salt Lake City. sino de los grupos obtenidos a partir de la cláusula GROUP BY. ejecutaremos el Código fuente 39. se muestran dos filas iguales para este apellido. SELECT city FROM authors WHERE city in ('San Francisco'. tenemos que existen dos autores. en lugar de las filas. pero no de las filas de la tabla. una por cada autor que se apellida Ringer. detrás de esta cláusula se debe determinar el atributo au_lname. ejecutaremos el Código fuente 38. SELECT au_lname FROM autors Código fuente 40 Si nos fijamos en el resultado obtenido. Ringer. Supongamos ahora. se resume en una sentencia. lo que se hace es simplemente un select. Esto que parece tan complicado. garantizando así que todas las filas cuyo valor de este atributo sea igual. ya que sólo mostramos una fila del grupo. usando la cláusula GROUP BY. Por ejemplo. SELECT au_lname FROM authors GROUP BY au_lname Código fuente 41 En ella. cuyo apellido es el mismo. Con esto garantizamos que sólo se mostrará una fila por cada apellido distinto. en lugar de todas. que lo único que nos interesa es obtener todos los apellidos que sean distintos. Puesto que deseamos agrupar por el apellido. SELECT title FROM titles WHERE price BETWEEN 1 AND 2 Código fuente 39 La cláusula Group by La cláusula GROUP BY agrupa. como su propio nombre indica. Para ello deberemos agrupar los autores cuyo apellido sea el mismo en un único grupo. Por lo tanto. irán al mismo grupo.'Salt Lake City') Código fuente 38 Si se desea conocer todos los títulos cuyo precio oscila entre 1 y 2 dólares. en grupos distintos. si queremos obtener el apellido de todos los autores.

en este caso alfabéticamente por el apellido. Las funciones que soporta la sentencia SELECT en el Transact SQL son las siguientes: • SUM: Realiza una suma acumulativa de un atributo para todas las filas accedidas mediante una consulta SQL. etc. Por ejemplo. Por lo tanto el funcionamiento es similar al ya visto para WHERE. SELECT au_lname. si queremos mostrar el nombre y apellido de todos los autores de nuestra base de datos pubs. deseamos que sólo se muestre el autor cuyo apellido sea Ringer. au_fname FROM authors ORDER BY au_lname Código fuente 43 Funciones escalares para Select Entendemos por funciones escalares. con los atributos cod_cliente. ejecutaremos el Código fuente 42. determina cómo se ordenarán las filas que se mostrarán. si dada la anterior sentencia de agrupación. salvo que aquella se usa como condición de búsqueda cuando se especifica la cláusula GROUP BY. todas aquellas que permiten realizar operaciones de conteo de filas. suma de atributos. obtención de medias.© Grupo EIDOS 13. bastará con ejecutar la sentencia que aparece en el Código fuente 43 donde el atributo especificado a continuación de la cláusula ORDER BY. como la que vemos en el Código fuente 44. Dichas funciones se especifican a continuación de la palabra reservada SELECT. La única diferencia es que HAVING se aplica a condiciones de grupo. au_lname. A continuación de dicha palabra reservada. Por ejemplo. es decir. bastará con realizar una función de tipo SUM. Si queremos obtener la suma del precio de todos los pedidos almacenados. cod_material y precio. Por ejemplo. supongamos que tenemos una tabla de pedidos. SELECT sum(precio) FROM pedido Código fuente 44 119 . se debe especificar el atributo o los atributos por los cuales se ordenará el resultado obtenido en la consulta. SELECT au_lname FROM authors GROUP BY au_lname HAVING au_lname = 'Ringer' Código fuente 42 La cláusula Order by La cláusula ORDER BY determina el orden de visualización de las filas obtenidas en la sentencia SELECT. El lenguaje de manipulación de datos (DML) La cláusula Having La cláusula HAVING es similar a la cláusula WHERE.

si tenemos una tabla cliente. apellidos. Por ejemplo. con todos los clientes de una empresa de servicios. al existir el mismo número de filas. se suele escribir el Código fuente 47. para obtener todas el número de filas de la tabla ejecutamos el Código fuente 46. deberemos realizar un count. debemos realizar la misma consulta. con los atributos DNI. pero especificando una condición para obtener únicamente las filas cuyo cod_cliente es "R12CE": SELECT sum(precio) FROM pedido WHERE cod_cliente = "R12CE" Código fuente 45 • COUNT: Cuenta todas las filas de las tablas accedidas mediante una consulta SQL. En general. SELECT count(*) FROM titles Código fuente 49 120 .Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS La anterior consulta obtiene la suma del precio para todas las filas de la tabla pedido. nombre. y queremos saber todos los clientes que tenemos. SELECT count(*) FROM cliente WHERE poblacion = "Madrid" Código fuente 48 Si queremos saber cuantos títulos tenemos nuestra base de datos. Si ahora queremos obtener la suma total de todos los pedidos realizados por el cliente cuyo código es "R12CE". SELECT count(*) FROM cliente Código fuente 47 Si ahora queremos saber el número de clientes que viven en Madrid. SELECT count(DNI) FROM cliente Código fuente 46 En el anterior ejemplo. deberemos realizar un conteo de todas las filas con la condición de que el atributo población sea Madrid. sea cual sea el atributo que seleccionemos. teclearemos el Código fuente 49. ya que no hemos especificado ninguna condición en la cláusula WHERE. dirección y población. podríamos haber escogido cualquier otro.

y queremos saber la cantidad media pedida de todos los materiales. deberemos ejecutar el Código fuente 52. y a continuación la divide por el número total de filas accedidas. deberemos realizar un SELECT con la cláusula max. descripción. precio y cantidad_pedida. es decir. SELECT avg(price) media FROM titles Código fuente 52 • MAX: Obtiene el máximo valor del atributo especificado. si queremos saber cual es el libro más caro. por ejemplo. con los atributos cod_material. Si queremos saber el material mas caro. Al resultado de la búsqueda le llamaremos caros. ejecutaremos el Código fuente 53. El lenguaje de manipulación de datos (DML) Y si queremos saber cuantos títulos tenemos. internamente. de entre todas las filas seleccionadas mediante la sentencia SQL. Para nuestro ejemplo. deberemos realizar lo mismo. realiza primero una suma de todos los valores. Supóngase.© Grupo EIDOS 13. realiza la media aritmética. teniendo en cuenta todas las filas de la tabla: SELECT avg(cantidad_pedida) FROM material Código fuente 51 La anterior sentencia. cuyo precio es mayor de 20 $. que tenemos la tabla de materiales descrita anteriormente. deberemos realizar una media aritmética. Volviendo a nuestra cultural base de datos pubs. pero especificando esta condición en la cláusula WHERE. Si por ejemplo tenemos una tabla de materiales. SELECT count(*) caros FROM titles WHERE price > 20 Código fuente 50 • AVG: Realiza una media aritmética de los atributos para todas las filas accedidas mediante la consulta SQL. si queremos saber la media del precio de los títulos que tenemos disponibles. SELECT max(price) caro FROM titles Código fuente 53 121 . que obtenga el mayor valor para el atributo precio de todas las filas.

obtenemos el siguiente error: Server: Msg 515.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • MIN: Obtiene el mínimo valor del atributo especificado. Si SELECT nos permitía recuperar datos. en cuyo caso deberemos especificar un valor para éste. y valores especifica los valores que se darán para estos atributos.authors'. Level 16. por lo que la información se añadirá a una tabla en forma de filas. 'Pepe'. State 2. Si queremos saber cual es el libro más barato de nuestra base de datos. para dar un valor al Código fuente 56. au_fname. 'Pepe'. deberá ir encerrado entre comillas. Recordemos que estamos en el modelo relacional. Sin embargo. cuando el atributo esté definido como NO NULO. au_lname. deberemos ejecutar el Código fuente 55. Por lo tanto. au_lname. si ejecutamos la anterior sentencia. 1) Código fuente 56 122 . Line 1 Cannot insert the value NULL into column 'contract'.dbo. Por ejemplo. con esta sentencia podemos añadir información a la base de datos. contract) VALUES ('409-99-9876'. SELECT min(price) barato FROM titles Código fuente 54 La sentencia Insert La otra gran sentencia de manipulación de datos es INSERT. La sintaxis de este sentencia es: INSERT INTO tabla (atributos) VALUES (valores) donde tabla especifica la tabla en la cual se añadirá la fila. mientras que si es numérico no. INSERT INTO authors (au_id. deberemos ejecutar el Código fuente 54. rectificamos el Código fuente 55. The statement has been terminated. column does not allow nulls. 'Perez'. si queremos añadir un nuevo autor a nuestra base de datos. habrá ciertas ocasiones en que esto no será posible. La razón es que no hemos dado valor al atributo contract. 'Perez') Código fuente 55 Destacar que si el valor a introducir es alfanumérico. separados por comas. el resto de los de la tabla deberá contener el valor nulo (NULL). table 'pubs. INSERT fails. es decir. atributos es una lista de atributos separados por comas que determinan los atributos para los cuales se darán valores. de entre todas las filas seleccionadas mediante la sentencia SQL. au_fname) VALUES ('409-99-9876'. INSERT nos va a permitir añadirlos al esquema. que ha sido definido como no nulo. Si sólo queremos insertar un valor para un atributo. Pues bien. INSERT INTO authors (au_id.

Por lo tanto se actualizarán todas las filas que cumplan la condición especificada. WHERE condicion donde tabla especifica la tabla donde se encuentran las filas que queremos actualizar. es decir. El lenguaje de manipulación de datos (DML) El valor que hemos dado al atributo contract es un 1. obtenemos el resultado: (1 row(s) affected) lo que quiere decir que la fila ha sido actualizada con éxito.. deberemos escribir el Código fuente 58. sin necesidad de borrarla e insertarla de nuevo. La sintaxis es la siguiente: UPDATE tabla SET atributo1 = valor1 . ya que está definido como tipo binario. Para poder borrar filas en una tabla se deben cumplir las condiciones de seguridad determinadas por el administrador (se verán en un 123 . obtenemos como resultado (1 row(s) affected) lo que nos indica que la fila se ha insertado con éxito. 0 para especificar que no está contratado. atributo2 = valor2. por el código (condición where). y lo que viene a continuación de SET especifica la asignación de los nuevos valores a los atributos. Si ejecutamos la anterior sentencia. UPDATE authors SET au_fname = 'Pepito' WHERE au_id = '409-99-9876' Código fuente 58 Lo que hacemos con la anterior sentencia es buscar el autor insertado. Podemos comprobarlo ejecutando el Código fuente 59. Si queremos cambiar el nombre al autor que hemos insertado en el anterior apartado.© Grupo EIDOS 13.. Podemos comprobarlo ejecutando un SELECT sobre dicha fila. sólo admite dos valores. SELECT * FROM authors WHERE au_id = '409-99-9876' Código fuente 57 La sentencia Update El objetivo de la sentencia UPDATE es actualizar los valores de una o varias filas de una tabla. SELECT * FROM authors WHERE au_id = '409-99-9876' Código fuente 59 La sentencia Delete El objeto de la sentencia DELETE es el de borrar filas de una tabla. condición especifica la condición que se debe cumplir para actualizar las filas. Al ejecutar esta sentencia. y a continuación actualizar el valor del atributo nombre de la fila obtenida a Pepito. y 1 para el caso contrario. .

si queremos borrar la fila que hemos creado en la tabla autores. cuyo resultado es: (0 row(s) affected). y condición especifica la condición que se debe cumplir para que se borren las filas. ejecutamos la sentencia que muestra el Código fuente 62. y deben de cumplirse también las reglas de integridad referencial. DELETE authors Código fuente 60 Por ejemplo. deberemos ejecutar el Código fuente 61. lo que quiere decir que la fila no se encuentra en la tabla.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS próximo capítulo). es decir. Para comprobarlo. La sintaxis es la siguiente: DELETE FROM tabla WHERE condicion donde tabla especifica la tabla sobre la cual queremos borrar las filas. obteniendo el siguiente resultado: (1 row(s) affected) DELETE FROM authors WHERE au_id = '409-99-9876' Código fuente 61 lo que viene a decir que la fila se ha borrado. la sentencia que aparece en el Código fuente 60 borra todas las filas de la tabla authors. se borrarán todas las filas de la tabla. SELECT * FROM authors WHERE au_id = '409-99-9876' Código fuente 62 124 . ha sido borrada. es decir. Si omitimos la condición.

Operador proyección El operador de proyección es muy usado. es decir. comparaciones lógicas. . Entendemos por operadores. aquellas palabras reservadas o símbolos delimitadores que nos permiten aplicar las diversas técnicas del álgebra relacional. Dicho operador consiste en restringir la cantidad de información que obtenemos de una o varias tablas. etc.Operadores básicos y consideraciones del lenguaje Introducción En este capítulo se describirán con detalle los operadores básicos. unión de cadenas. con los que ofrece SQL Server. así como algunas apreciaciones acerca del lenguaje que ofrece Transact SQL. Las principales que veremos aquí son: • • • Proyección Unión Join o combinación No confundir los anteriores operadores propios del álgebra relacional. los que permiten la evaluación de expresiones. sobre todo para acotar la consulta de tablas.

es decir. que son los alias que les hemos dado respectivamente. aunque también se puede acotar el resultado de ésta. se deberán especificar después de la palabra reservada FROM. se recuperarán todas las filas de la tabla titles. Veamos ahora como realizar una proyección utilizando Transact SQL. tabla2 Código fuente 64 En el anterior ejemplo se ha proyectado sobre dos campos de dos tablas distintas. en realizar una criba sobre aquellos atributos que nos interesen para todas las filas de una tabla. A este nombre se le denomina alias y sirve para que el atributo obtenido aparezca con otro nombre. campo2 FROM tabla1 Código fuente 63 El método no varia si queremos realizar la proyección sobre más de una tabla. SELECT tabla1. Una vez abierto. type tipo FROM titles Código fuente 65 Nótese como después de cada atributo hemos tecleado otro nombre. Para especificar los atributos de la tabla o tablas que deseamos que aparezcan en la consulta. se precede el nombre de la tabla al del campo. y separados por comas. seleccionándola en la lista desplegable de la parte superior derecha.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Aquí veremos la proyección vertical. especificando una condición. pero como podemos observar en el resultado mostrado en la Figura 79. Así. se deberán proporcionar éstos a continuación de la palabra reservada SELECT. el Código fuente 63 realiza una proyección de los atributos campo1 y campo2 de la tabla tabla1: SELECT campo1. Para distinguir el campo1 de tabla1. nos conectamos a la base de datos pubs.campo1. tabla2. para que el resultado se aplique únicamente a las tuplas que la cumplan. y tecleamos el Código fuente 65.campo1 FROM tabla1. en nuestro ejemplo. Probemos ahora con el query analyzer. 126 . y realizaremos una proyección sobre los atributos title y type. Así. SELECT title título. del campo1 de tabla2. seguido por un punto. dichos atributos aparecen bajo los nombre título y tipo. Para especificar las tablas sobre las cuales se desea realizar la proyección.

El Código fuente 66 constituye un ejemplo de unión de las tablas tabla1 y tabla2: SELECT * FROM tabla1. sino junto con el de proyección. escribiremos el Código fuente 67. Probemos ahora en el query analizer. 127 . tecleando el Código fuente 68. en unir campos de más de una tabla. que todas las filas de las tablas titles y titleauthor. Operadores básicos y consideraciones del lenguaje Figura 79 Operador Union El operador unión consiste. Por ejemplo. si queremos obtener la unión de las dos consultas a dos tablas.© Grupo EIDOS 14. El resultado obtenido contendrá entonces campos de las tablas especificadas en la cláusula FROM. es utilizar la palabra reservada UNION. Pulsamos ahora el botón de ejecución. y obtenemos el resultado mostrado en la Figura 80. y quedarnos luego sólo con la información relevante. que no es ni más ni menos. tabla2 Código fuente 66 Otra forma de realizar una unión entre el resultado de dos consultas. Este operador casi nunca se utiliza por separado. o F5. como su propio nombre indica. para obtener el resultado consultando en varias tablas.

titleauthor Código fuente 68 Operador join El operador de join es uno de los más usados en el álgebra relacional. La forma de realizarlo en Transact SQL es especificando en la cláusula WHERE los atributos por los cuales se va a realizar el join entre ambas tablas.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 80 SELECT * FROM tabla1 UNION SELECT * FROM tabla2 Código fuente 67 SELECT * FROM titles.campo1 Código fuente 69 128 . utilizando un atributo común. con todas las filas de la tabla con la que se hace el join. Lo que se realiza es una unión de cada fila de una tabla. Sirve para combinar dos tablas entre sí. SELECT * FROM tabla1.campo1 = tabla2. tabla2 WHERE tabla1. cuyos atributos comunes coincidan.

y deseamos hacer un join por el atributo campo1 de ambas. hay dos filas en la Tabla 27 cuyo atributo campo1 es igual. pero incluyendo todas las filas de ambas tablas. Dentro de este tipo de join. Operadores básicos y consideraciones del lenguaje El Código fuente 69 realiza un join entre las tablas tabla1 y tabla2. aunque éstas no tengan correspondencia en su homóloga. Campo1 1 2 3 4 Tabla 26 Campo2 10 9 4 1 Campo1 1 1 2 Campo2 5 3 8 Tabla 27 Lo primero que se realiza al hacer un join es una unión de ambas tablas.campo1 1 1 2 tabla2. la tercera fila de la tabla 1. El otro tipo de join.© Grupo EIDOS 14. para la primera fila de la Tabla 26. cuyo valor es 3. Por ejemplo. por el campo1 de ambas tablas. Veamos un ejemplo de como funciona un join. existen dos categorías: 129 . Supóngase que tenemos las dos siguientes tablas. copiar las filas de la segunda tabla.campo2 5 3 8 Como hemos podido comprobar.campo1 1 1 2 Tabla 28 tabla2. no aparece en el join. A este tipo de join se le denomina inner join. consiste en realizar el join. no existe en el atributo campo1 de la tabla 2. y para cada fila cuyo campo común sea igual en ambas tablas. copiando cada fila de la primera tabla. Esto es debido a que el valor del atributo por el que se hace el join (campo1).campo2 10 10 9 tabla1. El join de estas dos tablas queda como muestra la Tabla 28 tabla1. denominado outer join.

aunque éstas no tengan correspondencia en la primera.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • Left join: incluyen todas las filas de la primera tabla.campo2 10 10 9 ? tabla1. SELECT * FROM tabla1 rigth join tabla2 on tabla1.campo1 1 1 2 ? tabla2.campo1 1 1 2 4 tabla2. la sentencia para realizar este left join se muestra en el Código fuente 70.campo2 10 10 9 4 tabla1.campo1 1 1 2 3 Tabla 29 tabla2. la sentencia para realizar este rigth join aparece en el Código fuente 71. por los campos comunes campo1 y campo2.campo2 5 3 8 1 En Trasact SQL. tabla1. SELECT * FROM tabla1 left join tabla2 on tabla1.campo2 Código fuente 71 También se puede realizar un join por más de un campo.campo = tabla2.campo1 1 1 2 ? Tabla 30 tabla2.campo2 Código fuente 70 • Rigth join: incluyen todas las filas de la segunda tabla. Los campos de la segunda tabla se rellenan con interrogantes.campo = tabla2. aunque éstas no tengan correspondencia en la segunda. 130 .campo2 5 3 8 ? En Trasact SQL. El Código fuente 72 realiza un join entre las tablas Tabla 26 y Tabla 27. Tabla1. Los campos de la primera tabla se rellenan con interrogantes.

junto con el nombre de su autor. ejecutaremos la misma sentencia que antes.au_id = authors. que es que el atributo price de la tabla titles no supere los 20$. una de las operaciones más usuales es precisamente la de join de varias tablas.price FROM titles.campo1 AND tabla1.title.title_id = titleauthor.title_id = titleauthor.au_lname FROM titles. Si se desea obtener el título de cada obra.campo2 Código fuente 72 En el lenguaje de manipulación de datos. titles. aunque de éstas no se muestre ningún atributo.au_id = authors.© Grupo EIDOS 14. titleauthor. authors WHERE titles. authors WHERE titles. que es el código del autor. tabla2 WHERE tabla1. titleauthor. podemos acceder a los autores.campo1 = tabla2. SELECT titles. realizando un join de la tabla titleauthor con la tabla authors.au_id Código fuente 73 Analicemos la anterior sentencia. realizamos un join de esta tabla. podremos especificar otro tipo de condiciones. Veamos un ejemplo de implementación de join en Transact SQL. junto con sus autores.campo2 = tabla2. si queremos obtener una relación de todos los títulos cuyo precio no supere los 20 $. A continuación. con la tabla intermedia titleauthor. authors. la cláusula WHERE realiza los dos join necesarios para acceder a las tres tablas. deberemos ejecutar el Código fuente 73.title_id AND titleauthor. junto con los autores que lo han escrito (recuérdese que en las relaciones N-M.title_id AND titleauthor. que es la que almacena el código de cada título. pero añadiendo ahora una nueva condición. Deberemos acceder a la tabla de títulos. en la cláusula FROM se deben especificar todas las tablas que serán accedidas.price < 20 Código fuente 74 131 . authors. A partir de esta tabla.au_lname. Como se puede observar. Por ejemplo. se genera una tabla intermedia con la clave de cada tabla).au_id AND titles. En la cláusula WHERE. además de las condiciones de join. Por lo tanto. precisamente por el campo au_id. Operadores básicos y consideraciones del lenguaje SELECT * FROM tabla1.title. que es donde se encuentra el título de cada obra. SELECT titles. El resultado es el mostrado en la Figura 81.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 81 Figura 82 Operadores propios de Transact SQL Los operadores que nos proporciona SQL Server se dividen en varios grupos: 132 .

etc. búsqueda. La Tabla 31 muestra un resumen de los principales operadores con que nos podemos encontrar en Transact SQL. etc.: comparaciones. De cadena: realizan operaciones que afectan a strings o cadenas de caracteres.© Grupo EIDOS 14. Ej. Operadores básicos y consideraciones del lenguaje • • • • Aritméticos: realizan operaciones aritméticas. etc. etc.:concatenación. Ej.1 SELECT 3 * 2 SELECT 6 / 2 SELECT 4 % 3 RESULTADO 6 2 6 3 1 11 & 10 = 10 >2 11 | 10 = 11 -> 3 11 ^ 10 = 01 -> 1 ~10 = 01 -> 1 & SELECT 3 & 2 | Operadores nivel de bit ^ OR binario (1 si el bit de alguno de los dos SELECT 3 | 2 operandos es 1) OR exclusivo binario (1 si el bit de los SELECT 3 ^ 2 operandos es distinto) NOT binario (cambia el bit) SELECT ~ 2 ~ Operadores lógicos = < > >= <= Igual Menor Mayor Mayor o igual Menor o igual SELECT 1 = 2 SELECT 1 < 2 SELECT 1 > 3 SELECT 1 >= 1 SELECT 10 <= 1 FALSO VERDADERO FALSO VERDADERO FALSO 133 .: suma. multiplicación. DESCRIPCIÓN + Operadores Aritméticos * / % Suma Resta Multiplicación División Módulo o resto de la división entera AND binario (1 si los bits de ambos operandos son 1) EJEMPLO SELECT 2 + 4 SELECT 3 . Lógicos: realizan operaciones que devuelven un resultado lógico. De nivel de bit: realizan operaciones transformando los operandos a bits.: AND al nivel de bit. división. Ej. Ej.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS <> != !> !< + Distinto Distinto No mayor No menor Concatenación Cadenas coincidentes. NOT: negación de la expresión LIKE: búsqueda por patrón Tabla 31 SELECT 1 <> 2 SELECT 1 != 1 SELECT 1 !> 3 SELECT 1 !<1 SELECT 'A' + 'B' SELECT * FROM tabla WHERE atributo1 LIKE '[CH]urry' SELECT + FROM tabla WHERE atributo1 NOT LIKE '[^I-Z]' VERDADERO FALSO VERDADERO VERDADERO AB [] Curry Hurry Operadores de Cadena [^] J. si queremos obtener todos los títulos cuyo precio oscile entre los 30 y los 50 dólares.L. La sintaxis es: expresion BETWEEN expresion AND expression Por ejemplo. La sintaxis es: expresion IN lista Por ejemplo.K. ejecutamos el Código fuente 76. NOT: negación de la expresión LIKE: búsqueda por patrón Cadenas no coincidentes. NOT: negación de la expresión LIKE: búsqueda por patrón Cadena con ese carácter coincidente.M _ SELECT * FROM tabla WHERE atributo2 like '_urry' Hurry Otros operadores importantes aplicables a expresiones son los siguientes: • BETWEEN: Verifica los valores comprendidos dentro del rango especificado. si queremos obtener el nombre de todos los autores que vivan en San Francisco o en Salt Lake City. 134 . SELECT * FROM titles WHERE price BETWEEN 10 AND 50 Código fuente 75 • IN: Verifica si el valor especificado está contenido dentro de una lista de ellos. escribimos el Código fuente 75.

© Grupo EIDOS 14. si queremos obtener el nombre de los autores. Esta variables se pueden distinguir porque comienzan por dos arrobas @@. -2: filas no disponibles) identificador de la última operación realizada número de ticks de tiempo ocioso de CPU desde que se ejecutó SQL Server número de ticks de tiempo empleado en realizar operaciones de entrada/salida desde que se ejecutó SQL Server lenguaje local actual seleccionado 135 . el resultado de otra consulta. Operadores básicos y consideraciones del lenguaje SELECT au_lname FROM authors where city in ('San Francisco'. Variables globales Existe un conjunto de variables globales. SELECT au_lname FROM authors where city IN (SELECT city FROM authors WHERE state = 'CA') Código fuente 77 En la anterior consulta. y luego se aplica el valor obtenido para la evaluación del operador IN. Por ejemplo. o del resultado de una consulta. que viven en ciudades pertenecientes al estado de California (CA). que informan en cada momento del estado del sistema.'Salt Lake City') Código fuente 76 También se puede especificar como lista. La Tabla 32 muestra un resumen con las variables globales que nos pueden resultar de utilidad: @@connections @@cpu_busy @@cursor_rows @@datefirst @@error @@fetch_status @@identity @@idle @@io_busy @@LANGID número de conexiones realizadas desde que se ejecutó SQL Server número de ticks (3. es decir. escribimos el Código fuente 77. la forma de evaluación es desde dentro hacia fuera. etc.33 milisegundos) de ocupación de la CPU ejecutando instrucciones SQL Server desde que éste fue ejecutado número de filas seleccionadas en la última selección número del primer día de la semana número del último error producido en la ejecución de una sentencia. -1: preselección erronea. 0 si no ha habido error estado de la preselección (0: preselección satisfactoria. primero se evalúa la sentencia que está entre paréntesis.

Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS @@language @@lock_timeout @@max_connectio ns @@max_precision @@nestlevel @@options @@pack_received @@pack_sent @@packet_errors @@procid @@remserver @@rowcount @@servername @@servicename @@spid @@textsize @@timeticks @@total_errors @@total_read @@total_write @@trancount @@version descripción del lenguaje especificado para SQL server tiempo de time-out (tiempo hasta el cual se intenta dar por válida la transacción) en milisegundos para bloqueo número máximo de conexiones simultaneas que permite SQL Server nivel de precisión usado por los tipos de datos decimal y numeric nivel de anidamiento del actual procedimiento almacenado información sobre las opciones de usuario número de paquetes recibidos por SQL Server desde que se inicializó número de paquetes enviados por SQL Server desde que se inicializó número de paquetes erróneos desde que SQL Server se inicializó identificador del actual procedimiento almacenado nombre del servidor remoto número de filas afectadas por una sentencia de selección nombre del servidor local nombre de la clave de registro para SQL Server identificador del proceso actualmente en ejecución tamaño máximo para los tipos de datos texto e imágenes número de milisegundos por tick de CPU número total de errores producidos desde que se inicializó SQL Server número de lecturas de disco desde que se inicializó SQL Server número de escrituras en disco desde que se inicializó SQL Server número de transacciones activas por el usuario en curso versión. fecha y tipo de procesador actualmente en uso para SQL Server Tabla 32 136 .

y el número de ellos cuando no lo superen. se ejecutará la sentencia 2. correspondiente a la parte ELSE (opcional).. en lugar de una sola. ejecutaremos el Código fuente 78. IF (SELECT count(*) FROM titles) > 10 BEGIN SELECT title FROM titles END ELSE BEGIN SELECT count(*) FROM titles END Código fuente 78 En definitiva. Si se desea especificar un conjunto de sentencias. La sintaxis es la siguiente: CASE expresion1 WHEN expresion2 THEN resultado1 WHEN expresion3 THEN resultado2 . En otro caso. SELECT state = CASE state WHEN 'CA' THEN 'California' WHEN 'OR' THEN 'Oregon' ELSE 'Otro' 137 . corresponde a la sentencia CASE.© Grupo EIDOS 14.. que devuelve el número de títulos almacenados en la tabla titles. Existen dos tipos de sentencias condicionales. [ELSE resultado3] La anterior sentencia compara la expresión 1. La primera de ellas tiene la siguiente sintaxis: IF expresion_logica sentencia1 [ELSE sentencia2] La sentencia 1 sólo se ejecutará si el resultado de la evaluación de la expresión lógica es verdadera. se devolverá el resultado especificado a continuación del ELSE. la sentencia SELECT title FROM titles sólo se ejecuta cuando se cumple la condición (SELECT count(*) FROM titles) > 10. éstas deberán ir encerradas entre las palabras reservadas BEGIN y END. no ha verificado ninguna de las expresiones. en lugar de las iniciales. Otra forma de ejecutar sentencias de forma condicional. Por ejemplo. Si deseamos obtener los títulos almacenados cuando éstos superen las 10 unidades. se ejecutará la rama ELSE. Operadores básicos y consideraciones del lenguaje Sentencias condicionales Las sentencias condicionales son aquellas que permiten discriminar entre diversas sentencias. Si alguna de estas expresiones se cumple. con el resto de expresiones especificadas a continuación de la palabra reservada WHEN. Si llegados al final. En otro caso. si queremos saber el nombre de los estados de los autores. se devolverá el resultado correspondiente especificado a continuación de la palabra reservada THEN. según se cumpla el valor de una expresión lógica. podemos ejecutar el Código fuente 79.

y en otro caso se devolverá el literal 'Otro'. La sentencia que permite realizarlo es WHILE. mientras se cumpla una condición lógica.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS END FROM authors Código fuente 79 En este caso se comprueba el valor del atributo state. y abandonarlo. mientras se cumpla la expresión lógica. y su sintaxis WHILE expresion_logica sentencia [BREAK] [CONTINUE] La sentencia especificada se ejecuta de forma iterativa. mientras que CONTINUE permite ejecutar de nuevo las sentencias desde el comienzo del bucle. se devolverá California. ignorando aquellas que vienen a continuación del CONTINUE. aunque se cumpla la expresión lógica. Sentencias iterativas Una sentencia iterativa es aquella que permite ejecutar una o varias sentencias de manera repetida. La cláusula BREAK. si es OR se devolverá Oregon. 138 . y si este es igual a CA. permite romper el bucle.

y los valores para dichos atributos. y <valores> es una lista de valores separados por comas. se producirá un error y la fila no será insertada. . La palabra reservada INTO es opcional y se puede omitir en la sentencia. Si insertamos un valor nulo para un atributo que no acepta ese tipo de valores. Su sintaxis. y así sucesivamente. especifica el nombre de una tabla. Sintaxis La sintaxis de la sentencia insert es la siguiente INSERT INTO <tabla> (<atributos>) VALUES (<valores>) donde <atributos> es una lista de atributos separados por comas. Existe una correspondencia unívoca entre los atributos y los valores. es decir.La sentencia INSERT Introducción La sentencia insert permite la introducción de nuevos registros dentro de un esquema. que ya se ha visto. los atributos que se van a insertar. al atributo especificado en primer lugar se le asignará el valor indicado en primer lugar. o si no especificamos un valor concreto para este tipo de columnas.

como indica el Código fuente 80. SELECT * FROM ComunidadAutonoma Código fuente 81 140 .Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Ejemplos Para comenzar veremos un ejemplo sencillo de inserción de tuplas en la tabla del ejemplo de la agencia inmobiliaria que venimos manejando. ‘Catalunya’) INSERT INTO ComunidadAutonoma (CA_ID. ‘Madrid’) Código fuente 80 Figura 83 Para ver si efectivamente se han insertado ambos registros. Insertaremos dos Comunidades Autonomas en la tabla de comunidades. INSERT INTO ComunidadAutonoma (CA_ID. ejecutamos una sentencia select como muestra el Código fuente 81 (véase la Figura 83). CA_Nombre) VALUES (1. CA_Nombre) VALUES (2.

© Grupo EIDOS

15. La sentencia INSERT

Como decíamos, si ahora intentamos insertar otra provincia si especificar el atributo CA_ID, que es clave, se producirá un error, como podemos observar en la Figura 84 al ejecutar el Código fuente 82.

INSERT INTO ComunidadAutonoma (CA_Nombre) VALUES (‘Andalucía’) Código fuente 82

O si por el contrario introducimos un valor duplicado para la clave, también obtendremos el error de la Figura 85 al ejecutar el Código fuente 83.

INSERT INTO ComunidadAutonoma (CA_ID, CA_Nombre) VALUES (1, ‘Andalucía’) Código fuente 83

Figura 84

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

141

Bases de datos con SQL Server2000 – Transact SQL

© Grupo EIDOS

Figura 85

INSERT INTO ComunidadAutonoma VALUES (3, 'Andalucía') Código fuente 84

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

INSERT INTO Provincia (Prv_Nombre, Prv_ID, CA_ID) VALUES ('Madrid’, 1, 2) Código fuente 85

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

INSERT INTO tabla DEFAULT VALUES Código fuente 86

142

© Grupo EIDOS

15. La sentencia INSERT

Esto insertaría una nueva fila en la tabla, con los valores establecidos por defecto. Otra forma de insertar filas es a partir del resultado de una consulta. Por ejemplo, el Código fuente 87 insertaría en la tabla 2, los valores de la tabla 1. Ni que decir tiene que ambos esquemas deben coincidir. También se puede especificar un filtro en la claúsula where para la consulta.

INSERT INTO tabla2 SELECT * FROM tabla1 Código fuente 87

Carga de la base de datos de ejemplo
Para concluir este capítulo, se ofrecen las sentencias necesarias para cargar las tablas de la base de datos del ejemplo de la agencia inmobiliaria que venimos utilizando.

INSERT INTO Provincia VALUES (2, 1, 'Barcelona') INSERT VALUES INSERT VALUES INSERT VALUES INTO TipoBien (1, 'Piso') INTO TipoBien (2, 'Chalet') INTO TipoBien (3, 'Solar')

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

143

Bases de datos con SQL Server2000 – Transact SQL

© Grupo EIDOS

INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES

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

144

© Grupo EIDOS

15. La sentencia INSERT

INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES

INTO OfertaTransporte (8, 9) INTO OfertaTransporte (8, 10) INTO OfertaTransporte (8, 11) INTO OfertaTransporte (9, 1) INTO OfertaTransporte (9, 8) INTO OfertaTransporte (10, 3) INTO OfertaTransporte (10, 10) INTO OfertaTransporte (10, 11) INTO OfertaTransporte (10, 12) INTO OfertaTransporte (10, 5) Código fuente 88

145

La sentencia SELECT
Introducción
La sentencia select es la principal manera que tiene el usuario de consultar información de la base de datos. Veremos aquí algunos ejemplos de utilización, basándonos en los ejemplos que hemos visto en el capítulo acerca del DDL. La forma más simple de utilización es especificando una lista de atributos de una tabla. Así el Código fuente 89 mostraría todos los datos referentes a comerciales

SELECT * FROM Comercial Código fuente 89

y el Código fuente 90 mostraría el nombre y apellidos de todos los clientes

SELECT Cli_Nombre, Cli_Apellidos FROM Cliente Código fuente 90

Bases de datos con SQL Server2000 – Transact SQL

© Grupo EIDOS

La claúsula WHERE
La forma de especificar una condición dentro de una sentencia select es mediante la claúsula WHERE, que especifica una condición lógica que devolverá únicamente aquellos registros que la cumplan. Por ejemplo, para obtener todos los inmuebles de la tabla de ofertas que se encuentran en venta, deberíamos teclear el Código fuente 91.

SELECT * FROM Oferta WHERE Oferta.Of_Transaccion = ‘V’ Código fuente 91

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

SELECT * FROM Oferta WHERE Oferta.Of_Precio >= 100 and Oferta.Of_Precio <= 2000 Código fuente 92

Esta sentencia equivaldría a esta otra:

SELECT * FROM Oferta WHERE Oferta.Of_Precio BETWEEN 100

and 2000

Código fuente 93

Si además deseamos especificar un orden, habrá que utilizar la claúsula ORDER BY. Por ejemplo, el Código fuente 94 muestra el precio de todos los inmuebles de 100 a 2.000 euros, ordenado de más caro a más barato, como muestra la Figura 86.

SELECT Oferta.Of_Precio FROM Oferta WHERE Oferta.Of_Precio BETWEEN 100 ORDER BY Oferta.Of_Precio

and 2000

Código fuente 94

148

deberemos ejecutar el Código fuente 95. Si por ejemplo deseamos obtener todas las viviendas que no 149 . el operador join es el más usado para obtener información de tablas relacionadas. La diferencia entre ambos ya se ha comentado en un capítulo anterior. deberemos utilizar este operador para obtener la información contenida en ambas. Prv_Nombre FROM Oferta Inner join Provincia on Oferta. que se encuentra en otra tabla distinta de la de ofertas. SELECT Of_Direccion. En el anterior ejemplo se ha utilizado un inner join. y que se encuentra relacionada con ésta mediante la clave ajena Prv_ID. Si deseamos obtener datos de dos tablas que están relacionadas por un atributo.© Grupo EIDOS 16. Por ejemplo. para obtener una información detallada de en que provincias se encuentran los inmuebles. como pueden ser el left outer y el rigth outer. pero también existen otros tipos de join.Prv_ID Código fuente 95 De esta manera obtenemos la información de la provincia.Prv_ID = Provincia. La sentencia SELECT Figura 86 El operador join Si la sentencia select es la más utilizada para consulta de información. así que no se entrará en detalle.

TB_ID and TipoBien. Prv_Nombre.Of_Direccion. y nos pregunta por todos los inmuebles. SELECT Of_Direccion. obtendremos ese atributo a nulo.Prv_ID INNER JOIN TipoBien ON Oferta. Habría que ejecutar el Código fuente 97. TipoBien.Prv_Nombre = ‘Madrid’ inner join TipoBien on Oferta. hubiese sido más cómodo crear una vista como la siguiente: CREATE VIEW dbo. Supongamos que ahora nos viene un cliente.TB_ID = TipoBien. Provincia. o que han sido asignadas a clientes erróneos deberemos ejecutar el Código fuente 96.Prv_ID Left outer join Cliente on Oferta.vInmuebles SELECT Oferta.Of_Transaccion = ‘A’ Código fuente 97 Aunque el anterior código es válido.TB_ID = TipoBien.Cli_NIF = Cliente.Prv_ID = Provincia. Puesto que se ha utilizado una claúsula where que nos devuelve únicamente los clientes que tienen dicho atributo a nulo.TB_Nombre = ‘Piso’ WHERE Oferta. SELECT * FROM Oferta Inner join Provincia on Oferta. primero realizamos un inner join para obtener la provincia (caso de que no exista no aparecería nada). Oferta.TB_Nombre FROM Oferta INNER JOIN Provincia ON Oferta. y a continuación un left outer join con la tabla de clientes para obtener el cliente que tiene asignado la oferta.Cli_NIF FROM Oferta Inner join Provincia on Oferta. si dicho cliente no existe en la base de datos.Cli_NIF is null Código fuente 96 En el anterior ejemplo.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS han sido compradas todavía por ningún cliente.Prv_Nombre.Of_Transaccion.Prv_ID = Provincia. que sean pisos.Prv_ID and Provincia.TB_ID Código fuente 98 Ya continuación hacer un select de la vista como si de una tabla se tratase: SELECT * FROM vInmuebles 150 . que se encuentren en alquiler y que pertenezcan a la provincia de Madrid. Cliente. obtendremos los clientes que no tienen correspondencia con las ofertas.Cli_NIF WHERE Cliente.Prv_ID = Provincia.

como muestra el Código fuente 103 y podemos apreciar en la Figura 87.Tr_ID = Transporte.Of_ID Transporte on OfertaTransporte. el anterior código podría haberse simplificado de la siguiente manera: SELECT Cli_NIF FROM Cliente WHERE Cli_NIF not in (SELECT Cli_NIF FROM Oferta) Código fuente 102 Las funciones de agregado Imaginemos ahora que deseamos obtener el inmueble más caro de todos.Cli_Nombre FROM Cliente Left outer join Oferta on Oferta. y cogiendo el primer registro de todos (utilizando la claúsula TOP 1). El código sería el siguiente: SELECT Of_Precio FROM Oferta Inner join Inner join Inner join And OfertaTransporte on Oferta. SELECT top 1 Of_Direccion. Supóngase que se desea saber cuanto valen todos los pisos que están próximos a una estación de cercanías o de metro.TT_Nombre = ‘Cercanias’) Código fuente 100 Incluso podemos seleccionar todos los clientes que no han comprado ningún inmueble: SELECT Cliente.TT_Nombre = ‘Metro’ or TipoTransporte.Cli_NIF = Cliente. Ordenando por precio de manera descendente. La sentencia SELECT WHERE Of_Transaccion = ‘A’ and TB_Nombre = ‘Piso’ and Prv_Nombre = ‘Madrid’ Código fuente 99 Vamos ahora a por un ejemplo con los transportes.TT_ID = TipoTransporte.Cli_NIF WHERE Oferta.© Grupo EIDOS 16.TT_ID (TipoTransporte.Of_ID = Transporte. obtenemos el inmueble cuyo precio es máximo. Of_Precio FROM Oferta ORDER BY Of_Precio desc Código fuente 103 151 . lo cual se obtiene mediante la claúsula ORDER BY <atributo> DESC.Cli_NIF is null Código fuente 101 Sin embargo.Tr_ID TipoTransporte on Transporte.

como muestra el siguiente código equivalente: SELECT max(Of_Precio) FROM Oferta Código fuente 104 Además de este función de agregado.Prv_ID = Oferta. T-SQL nos ofrece una forma más sencilla de realizar esta consulta. dentro de la consulta especificada. encontramos la función min. utilizando una función de agregado que se denomina max. Por ejemplo. encargada de devolver el registro cuyo valor es el mínimo. De esta manera obtenemos el máximo valor para el atributo que especificamos para dicha función. SELECT min(Of_Precio) FROM Oferta Inner join Provincia on Provincia. y análogamente a max.Prv_ID and Provincia. SQL-SERVER nos ofrece otras muchas. que veremos en más detalle a continuación. El Código fuente 105 devolvería el inmueble más barato de la provincia de Madrid.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Figura 87 Sin embargo.Prv_Nombre = ‘Madrid’ Código fuente 105 152 .

Prv_ID = Provincia.Prv_Nombre = ‘Barcelona’ Código fuente 109 153 . lo más usual es poner el comodín *. SQL-SERVER nos ofrece la función avg. SELECT sum(Of_Precio) FROM Oferta inner join Cliente on Oferta. En este caso. como muestra el Código fuente 108. aunque se puede especificar un atributo entre paréntesis.Prv_ID And Provincia.Cli_NIF = Cliente. pero ahora filtrando por el código de provincia que.Cli_NIF and Cliente. Por ejemplo. El Código fuente 107 serviría para contar el número de filas de la tabla Oferta. Si queremos obtener el dinero gastado por un cliente del que sabemos que su apellido empieza por “Marti”. SELECT count(*) FROM Oferta Inner join Provincia on Oferta. La sentencia SELECT Otra función muy usual es la de suma. será necesario obtener por medio de un join que contenga dicho nombre. es decir. el código que nos muestra la media del precio de los inmuebles de Barcelona. volveremos a utilizar esta sentencia. ya que el número de filas es similar es para todos los atributos.Prv_ID = Provincia.Cli_Apellidos like 'Marti%' Código fuente 106 En el anterior código nos basamos en utilizar un join con la tabla de clientes utilizando el atributo común Cli_NIF. como no conocemos a priori. bastaría ejecutar el Código fuente 106. para un atributo determinado dentro de una consulta.© Grupo EIDOS 16. el número total de ofertas almacenadas en la base de datos. cuya misión es contar es numero de filas que devuelve la consulta. SELECT count(*) FROM Oferta Código fuente 107 Y si queremos obtener el número de ofertas existentes en la provincia de Barcelona. seria equivalente al código que realiza los cálculos por separado.Prv_Nombre = ‘Barcelona’ Código fuente 108 Para obtener media aritméticas.Prv_ID And Provincia. SELECT avg(Of_Precio) FROM Oferta Inner join Provincia on Oferta. dentro de la consulta especificada. expresada por sum. restringiendo en ésta última tabla por aquellos clientes cuyo atributo apellidos comience por Marti (claúsula like). No menos importante es la función count. y cuyo cometido es devolver como resultado la suma del atributo especificado entre paréntesis.

y Prv_Nombre puede que no sea único. Provincia.Prv_Nombre = ‘Barcelona’ Código fuente 110 El funcionamiento es similar para las funciones encargadas de calcular la desviación típica (stdev).Prv_ID GROUP BY Provincia. lo lógico sería ejecutar el código.Prv_ID And Provincia. SELECT avg(Of_Precio).000 euros. Para entendernos. Modificamos el código para utilizar esta cláusula. debemos utilizar es la claúsula group by. si ejecutamos este código.Prv_ID GROUP BY Provincia.Prv_Nombre Código fuente 112 Paralelamente al uso de group by se suele utilizar la claúsula having.Prv_Nombre FROM Oferta Inner join Provincia on Oferta.Prv_Nombre WHERE avg(Of_Precio) > 100000 Código fuente 113 154 . Provincia.Prv_Nombre FROM Oferta Inner join Provincia on Oferta.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS SELECT sum(Of_Precio) / count(Of_Precio) as media FROM Oferta Inner join Provincia on Oferta. Para evitar esto. entonces tendremos un avg por cada grupo que obtengamos. en principio deberíamos ejecutar el Código fuente 111.Prv_ID = Provincia.Prv_ID = Provincia. La claúsula GROUP BY Si deseamos obtener agrupaciones dentro de una consulta. deberemos utilizar esta claúsula. SELECT avg(Of_Precio).Prv_ID = Provincia. Provincia. la varianza estadística (var) y la varianza de llenado (varp). es como un where pero que se aplica a grupos de registros. por lo que SQL SERVER se hace “un lio”. SELECT avg(Of_Precio). y obtenemos algo como la Figura 88.Prv_ID = Provincia. en lugar de a registros por si solos. ya que avg devuelve un registro. la desviación típica de la población (stdevp).Prv_Nombre FROM Oferta Inner join Provincia on Oferta. nos mostraría un error. Si modificamos la anterior consulta para que sólo se devuelvan aquellas provincias cuya media de precio supera los 100. Si por ejemplo deseamos obtener la media del precio de los pisos por provincias.Prv_ID Código fuente 111 Sin embargo. para obtener los resultados agrupados.

Prv_ID Código fuente 115 155 .Prv_ID = Provincia. La sentencia SELECT Figura 88 Sin embargo esto nos devuelve un error.© Grupo EIDOS 16. Sustituimos el where por having en el Código fuente 114.Prv_ID = Provincia. para obtener cuales son las provincias en las cuales tenemos algún inmueble. SELECT Prv_Nombre FROM Oferta inner join Provincia on Oferta.Prv_Nombre HAVING avg(Of_Precio) > 100000 Código fuente 114 Otra utilidad que ofrece la cláusula group by es la de obtener los valores distintos que aparecen para uno o varios atributos. Por ejemplo. Provincia. SELECT avg(Of_Precio).Prv_Nombre FROM Oferta Inner join Provincia on Oferta. ya que el where se aplica a registros y. podríamos ejecutar el código.Prv_ID GROUP BY Provincia. al estar utilizando group by deberemos especificar una función de agregado.

como muestra el Código fuente 117. Prv_Nombre FROM Oferta inner join Provincia on Oferta.Prv_ID = Provincia. como sigue.Prv_ID = Provincia. con los consiguientes duplicados. esto nos devuelve un registro por cada oferta que se encuentre. por ejemplo contar el número de inmuebles por provincia. SELECT count(Prv_Nombre) Cantidad.Prv_ID GROUP BY Prv_Nombre Código fuente 117 156 . SELECT distinct(Prv_Nombre) FROM Oferta inner join Provincia on Oferta.Prv_ID Código fuente 116 Sin embargo esto no es válido si queremos realizar algún tipo de información adicional. Para evitar esto. podemos utilizar la función dinstinct. que sí se resolvería utilizando la claúsula group by.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Sin embargo.

La claúsula FROM se puede omitir. que se muestra en el Código fuente 118 donde se actualiza la dirección del comercial cuyo NIF es 11323K. UPDATE Comercial SET Com_Direccion = 'C/Esplandiu. 5' . la sentencia update se utiliza para modificar la información existente. Su sintaxis es la siguiente. UPDATE <tabla> SET <atributo> = <valor> FROM <tablas> WHERE <condicion> Si se especifica más de una asignación de un valor a un atributo. en el caso de sólo se necesite acceder a una tabla. Ejemplos Para comenzar veremos un ejemplo sencillo.La sentencia UPDATE Introducción Esta sentencia es la que permite la actualización de la información almacenada en la base datos. Si la sentencia insert se utilizaba para añadir nueva información. éstas se deberán separar por comas. que será la misma que la que se actualice.

Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS WHERE Com_NIF = '11323K' Código fuente 118 Para comprobar que efectivamente el cambio ha tenido efecto. vamos a consultar los datos de este comercial. ejecutando el Código fuente 119.Prv_ID and Prv_Nombre = 'Madrid' Código fuente 120 158 . Com_Direccion FROM Comercial WHERE Com_NIF = '11323K' Código fuente 119 Figura 89 Pero no simplemente se puede actualizar una fila cada vez. obteniendo el resultado de la Figura 89. Provincia WHERE Comercial. para la cual se deberá ejecutar el Código fuente 120. SELECT Com_NIF. UPDATE Comercial SET Com_Categoria = '4' FROM Comercial.Prv_ID = Provincia. sino que se pueden actualizar todas las filas que coincidan con un criterio de búsqueda. Por ejemplo. se puede hacer subir a la categoría 4 a todos los comerciales de Madrid.

aunque no sea ésta la que se actualice. La sentencia UPDATE En este caso hemos tenido que especifica la claúsula from para acceder a la tabla de provincias. Provincia WHERE Comercial. Para comprobar si se han actualizado los datos. es posible actualizar más de uno simultáneamente. ejecutamos el Código fuente 121.Prv_ID Código fuente 121 Figura 90 Hasta ahora sólo hemos actualizado un atributo. Prv_Nombre FROM Comercial. y sólo los correspondientes a la provincia de Madrid.Prv_ID = Provincia. pero como hemos dicho.© Grupo EIDOS 17. Por ejemplo. Cli_Telefono = '912237887' WHERE Cli_Nombre = 'Juan Jose' and Cli_Apellidos = 'Martinez' Código fuente 122 159 . SELECT Com_Categoria. ya que necesitábamos conocer el identificador correspondiente a la provincia de Madrid. el Código fuente 122 muestra como actualizar la dirección y el teléfono del cliente Juan Jose Martinez. UPDATE Cliente SET Cli_Direccion = 'C/Apache 35'.

Prv_Nombre FROM Oferta inner join Provincia on Provincia.Prv_ID where Prv_Nombre = 'Barcelona' Código fuente 124 Ahora ejecutamos el Código fuente 125 para actualizar su precio a un 5% más de su valor actual. Primero ejecutaremos el Código fuente 124 para comprobar cual es el precio de estos inmuebles. podemos subir el precio de todos los inmuebles de Barcelona un 5%. sino que se puede indicar una expresión. ejecutamos el Código fuente 123.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Para comprobar que se ha actualizado correctamente el registro. obteniendo el resultado de la Figura 91. 160 . Por ejemplo. SELECT Of_Precio. no hace falta especificar un valor a la hora de actualizar uno o varios atributos. SELECT * FROM Cliente WHERE Cli_Nombre = 'Juan Jose' and Cli_Apellidos = 'Martinez' Código fuente 123 Figura 91 Del mismo modo.Prv_ID = Oferta.

Provincia WHERE Provincia.Prv_ID = Oferta.Com_Nombre Código fuente 127 Por lo tanto vemos que la asignación de categorías sería 1 para Juan Alberto y Pedro. SELECT count(*) cantidad.Com_NIF)) Código fuente 128 161 . Prv_Nombre FROM Oferta inner join Provincia on Provincia. UPDATE Comercial SET Com_Categoria = ((SELECT count(*) / 2 FROM Oferta where Comercial. entre 5 y 6 será 3. Ejecutemos ahora el Código fuente 128 que nos permite hacer esto.05) FROM Oferta.Prv_ID = Oferta. Para calcular dicha categoría podemos aplicar la siguiente fórmula: Categoria = (nº inmuebles vendidos / 2) + (nº inmuebles vendidos módulo 2) El operador de módulo o resto de la división entera se representa en T-SQL como %. y 4 para Luis. entre 3 y 4 será 2. ejecutamos nuevamente el Código fuente 126. La sentencia UPDATE UPDATE Oferta SET Of_Precio = Of_Precio + (Of_Precio * 0.Prv_ID where Prv_Nombre = 'Barcelona' Código fuente 126 De la misma forma que para la sentencia select. Com_Nombre FROM Comercial left outer join Oferta on Oferta.Prv_ID and Prv_Nombre = 'Barcelona' Código fuente 125 Y para comprobar que efectivamente se han actualizado estos registros. la categoría a asignar será de 1.Com_NIF) + (SELECT count(*) % 2 FROM Oferta where Comercial. Por ejemplo.© Grupo EIDOS 17. y así sucesivamente.Com_NIF = Oferta. update nos permite la utilización de las funciones de agregación. primero veamos cuantos inmuebles ha vendido cada comercial. Si ha vendido entre 0 y 2. para el cálculo de expresiones.Com_NIF GROUP BY Comercial. Vayamos paso a paso. ejecutando la sentencia del Código fuente 127.Com_NIF = Oferta.Com_NIF = Comercial. SELECT Of_Precio. actualizaremos la categoría del comercial dependiendo del número de inmuebles que haya vendido cada uno.

Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Lo primero que se ha hecho es para cada comercial calcular el número de ofertas que tiene relacionado. para dividirlo por 2. SELECT Com_Nombre. Si ejecutamos una selección. como la que se muestra en el Código fuente 129 para comprobar que efectivamente la actualización se ha realizado con éxito. Com_Categoria FROM Comercial Código fuente 129 162 . calcular su módulo 2 y luego sumarlo y asignarlo al campo categoría. nos encontraríamos con lo siguiente.

podemos obtener el máximo valor para el atributo Of_ID.La sentencia DELETE Introducción La sentencia delete es la que nos permite borrar tuplas almacenadas en la base de datos. podemos hacer una select completa de la tabla y verificar que falta dicho registro aunque. lo más sencillo. Su sintaxis es la siguiente. Si ésta se omite. Si por ejemplo ejecutamos el Código fuente 130. y comprobar que no es superior a 10. y conociendo que el registro que hemos borrado era el último introducido. se borrarán todas las filas de la tabla especificada (mucho cuidado con esto). . nos encontraremos con que se borrará la oferta cuyo código es 11 de la tabla de ofertas. ejecutando el Código fuente 130. DELETE FROM tabla WHERE condicion Donde tabla especifica el nombre de la tabla de donde se desean borrar las filas que cumplen la condición especificada en la claúsula where. DELETE FROM Oferta WHERE Of_ID = 11 Código fuente 130 Para comprobar si se ha borrado dicho registro.

las reglas de integridad nos permiten olvidarnos a la hora de borrar un registro. cuando pretendamos borrar una tupla de estas características. primero deberemos borrar todas las ofertas en las que haya participado dicho comercial. que hacen referencia a dicha oferta. Esto supondría que tendríamos ofertas inconsistentes. Para comprender mejor esto. ejecutando el Código fuente 133. Es decir. Por lo tanto. hacen referencia a comerciales que ya no existen en la base de datos. Si lo hemos hecho bien. nos da un error. el SGBD nos advertirá de ello y no nos dejará borrarla.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS SELECT max(Of_ID) FROM Oferta Código fuente 131 La integridad referencial Un aspecto a tener en cuenta es el no violar las reglas de integridad referencial que sostienen la base de datos. Para evitar esto. como muestra el Código fuente 134. DELETE FROM Oferta FROM Comercial 164 . ejecutaremos el Código fuente 132.Com_NIF and Com_Nombre = 'Luis' and Com_Apellidos = 'Canto' Código fuente 133 Sin embargo. supongamos que borramos todos los comerciales de la base de datos. si por ejemplo queremos borrar el comercial Luis Canto. al ejecutar este código nos encontramos en la misma situación. para evitar posibles inconsistencias que pudieran surgir al eliminar atributos que son clave ajena en otra relación. De esta manera. evitando esta pérdida de información. Recordemos al lector que estas reglas son las que permiten mantener la información de la base de datos en un estado coherente. como cabía esperar.Com_NIF = Comercial. si éste esta relacionado con alguna otra tabla. primero deberemos borrar éstas. DELETE FROM Comercial Where Com_Nombre = 'Luis' and Com_Apellidos = 'Canto' Código fuente 132 que. DELETE FROM Oferta FROM Comercial Where Oferta. ya que resulta que existen filas en la tabla que relaciona las ofertas y los transportes. es decir.

pero permanece la estructura y sus columnas. ejecutando el Código fuente 135.Com_NIF = Comercial. con el Código fuente 136. TRUNCATE TABLE quita los datos al cancelar la asignación de las páginas de datos utilizadas para almacenar los datos de la tabla y sólo se graba en el registro de transacciones la página de asignaciones quitadas. Pero TRUNCATE TABLE es más rápida y utiliza menos recursos de los registros de transacciones y de sistema que delete.Com_NIF and Com_Nombre = 'Luis' and Com_Apellidos = 'Canto' Código fuente 134 Una vez borradas las filas de OfertaTransporte.Com_NIF = Comercial. El contador utilizado por una identidad para las nuevas filas se restablece al valor de inicialización de la columna.© Grupo EIDOS 18. restricciones. Por ejemplo. etc. índices. La instrucción DELETE quita una a una las filas y graba una entrada en el registro de transacciones por cada fila eliminada. el Código fuente 137 borraría todos los datos de la tabla Cliente TRUNCATE TABLE Cliente Código fuente 137 165 . TRUNCATE TABLE quita todas las filas de una tabla.Com_NIF and Com_Nombre = 'Luis' and Com_Apellidos = 'Canto' Código fuente 135 Y una vez borradas las ofertas de dicho comercial. volvemos atrás para borrar las filas de Oferta. ya le podemos eliminar de la base de datos. DELETE FROM Comercial Where Com_Nombre = 'Luis' and Com_Apellidos = 'Canto' Código fuente 136 La sentencia TRUNCATE TABLE Esta sentencia funciona de la misma forma que la instrucción delete sin especificar una cláusula WHERE: ambas quitan todas las filas de la tabla. DELETE FROM Oferta FROM Comercial Where Oferta. La sentencia DELETE Where Oferta. sin preocuparnos de posibles inconsistencias. se debe utilizar delete en su lugar. Si desea conservar el valor del contador.

CA_ID = Provincia. Provincia WHERE ComunidadAutonoma. una vez borradas todos los transportes disponibles para la oferta. Para ello ejecutamos el Código fuente 138 DELETE FROM OfertaTransporte WHERE Of_ID in (SELECT Of_ID FROM Oferta WHERE Prv_ID in (SELECT Prv_ID FROM ComunidadAutonoma. el Código fuente 140 mostraría como borrar las dos primeras ofertas.CA_Nombre = 'Catalunya' and ComunidadAutonoma. podemos utilizar una subconsulta que nos devuelva los identificadores de las provincias pertenecientes a dicha comunidad.CA_ID)) Código fuente 138 De esta manera y. para lo cual podemos volver a ejecutar una subconsulta en un segundo nivel para obtener dichas filas. se puede indicar una consulta. Provincia WHERE ComunidadAutonoma. DELETE Oferta FROM (SELECT top 2 * FROM Oferta) as t Código fuente 140 Puesto que esto devuelve un error debido a la integridad referencial. se puede utilizar el resultado de una subconsulta para borrar un conjunto de registros. Por ejemplo. si queremos borrar todas las ofertas de la Catalunya. primero habrá que borrar todas las filas de OfertaTransporte que estén relacionadas con éstas. Por ejemplo. borraremos las ofertas como era nuestra pretensión.CA_Nombre = 'Catalunya' and ComunidadAutonoma.CA_ID) Código fuente 139 Además de especificar una tabla en una sentencia delete. DELETE FROM Oferta WHERE Prv_ID in (SELECT Prv_ID FROM ComunidadAutonoma. para a continuación efectuar el borrado de toda las ofertas que contengan dicho identificador. Sin embargo. deberemos ejecutar primero el Código fuente 141que elimine las filas de OfertaTransporte relacionadas. y al igual que hacíamos con la sentencia select.CA_ID = Provincia. ejecutando el Código fuente 139. Por ejemplo.Bases de datos con SQL Server2000 – Transact SQL © Grupo EIDOS Ejemplos Veamos ahora algunos ejemplos para afianzar al lector en el uso de esta sentencia. utilizando para ello el operador de contenido (in). 166 .

En este código. especificando para la misma un alias (t).Of_ID = OfertaTransporte. que nos servirá para luego hacer referencia a dicha subconsulta en la claúsula where. 167 .© Grupo EIDOS 18. por ejemplo. se ha utilizado una subconsulta como tabla. especificando para la misma un alias (t). se ha utilizado una subconsulta como tabla. que permita borrar dichas filas. que nos servirá para luego hacer referencia a dicha subconsulta en la claúsula where. Aquí. Aquí.Of_ID Código fuente 141 En este código. por ejemplo. se utiliza para hacer un join con la tabla OfertaTransporte. La sentencia DELETE DELETE OfertaTransporte FROM (SELECT top 2 * FROM Oferta) as t WHERE t. se utiliza para hacer un join con la tabla OfertaTransporte. que permita borrar dichas filas.

.

etc. También se pueden compilar procedimiento escritos en lenguaje C. al que se le pasa un parámetro. bucles. Los procedimientos almacenados de SQL Server. CREATE PROCEDURE ObtenerNombre @au_id varchar(11) AS SELECT au_name FROM author WHERE author. llamado @au_id. introducir saltos. podemos crear un procedimiento para recuperar el nombre de un autor.au_id = @au_id Código fuente 142 Con esta sentencia. si queremos obtener el nombre del autor cuyo código sea '123'.Procedimientos almacenados y triggers Introducción Los procedimientos almacenados son conjuntos de sentencias en leguaje Transact SQL que pueden almacenarse en el propio servidor. cuyo código se pasa por parámetro. se crea un procedimiento almacenado. son más potentes. Por ejemplo. de nombre ObtenerNombre. que realiza una consulta para obtener el nombre de la tabla author. para ampliar su potencia modularmente. de tipo varchar(11). cuyo código coincida con el parámetro. De esta forma. porque permiten almacenar funciones y procedimientos compuestos por varias instrucciones. deberemos ejecutar el procedimiento pasándole como argumento este valor: .

obtendremos el resultado directamente en la ventana que tengamos abierta en SQL Server. realizando un SELECT * FROM Authors. Detrás de la palabra reservada PROCEDURE damos el nombre del procedimiento almacenado. queremos obtener el número de autores y el número de libros que tenemos en la base de datos. Básicamente es similar al anterior. CREATE SELECT SELECT SELECT SELECT RETURN PROCEDURE num_autores_libros @autores int OUTPUT. Si por ejemplo. en cuyo caso especificamos la palabra reservada OUTPUT a continuación. Primero contamos todas las filas de la tabla authors. y diremos sin éstos son de salida. ObtenerNombre '123' Código fuente 143 • Pasando los argumentos nombrados. La función @@ROWCOUNT devuelve el número de filas que se han seleccionado. La solución para este caso es utilizar la palabra reservada OUTPUT para los argumentos de salida. como resultado de la ejecución del procedimiento?. @libros int OUTPUT AS * FROM Authors @autores = @@ROWCOUNT * FROM Titles @libros = @@ROWCOUNT (0) Código fuente 145 Vamos a estudiar el anterior ejemplo. y a continuación proporcionamos los parámetros. Nótese como la forma de asignar un valor a un atributo es mediante una sentencia SELECT.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Las llamadas a procedimientos almacenados se pueden realizar de las siguientes formas: • Pasando los argumentos en el mismo orden que en el que se han declarado. Acto seguido se realiza lo mismo para la tabla titles. Es equivalente a la sentencia que aparece en el Código fuente 146 170 . ObtenerNombre @au_id = '123' Código fuente 144 Parámetros por referencia Si ejecutamos las anteriores sentencias. junto con su tipo (que en este caso es entero). Tras la palabra reservada AS se codifica el cuerpo del procedimiento. A continuación devolvemos en el parámetro @autores el valor obtenido. utilizando @@ROWCOUNT. Pero ¿que pasa si queremos obtener un parámetro de salida. crearemos el procedimiento almacenado que muestra el Código fuente 145. En este caso no hace falta que los parámetros vayan en el mismo orden. igualando el parámetro al valor.

Mostrar los resultados. Ejecutar el procedimiento. La sintaxis es utilizar la palabra reservada EXEC. seguiremos los siguientes pasos: 1. DECLARE @num_autores int DECLARE @num_libros int Código fuente 148 2. por lo tanto. CREATE SELECT SELECT RETURN PROCEDURE num_autores_libros @autores int OUTPUT. se podría sustituir por Código fuente 147. especificando si son de retorno. obtendremos como resultado el siguiente listado: autores libros ----------------------------23 18 (1 row(s) affected) 171 .© Grupo EIDOS 19. Procedimientos almacenados y triggers SELECT COUNT(*) FROM Authors Código fuente 146 El Código fuente 146. La sintaxis para declarar una variable es utilizar la palabra reservada DECLARE. @num_libros OUTPUT Código fuente 149 3. seguido del nombre de la variable y el tipo. seguida del nombre del procedimiento. SELECT autores = @num_autores. EXEC num_autores_libros @num_autores OUTPUT. separados por comas. y los parámetros. libros = @num_libros Código fuente 150 Tras ejecutar las anteriores sentencias. @libros int OUTPUT AS @autores = (SELECT COUNT(*) FROM Authors) @libros = (SELECT COUNT(*) FROM Authors) (0) Código fuente 147 Para ejecutar el anterior procedimiento. Declarar las variables que vamos a utilizar para llamar al procedimiento.

deberemos ejecutar sp_columns seguido del nombre de la tabla. si deseamos conocer todos los atributos de una tabla. disponemos de otro procedimiento almacenado denominado sp_tables. si deseamos saber los usuarios conectados a nuestro sistema. Del mismo modo. seguido del nombre del procedimiento. Por ejemplo. escribiremos el Código fuente 151 DROP PROCEDURE num_autores_libros Código fuente 151 Procedimientos almacenados de sistema SQL Server nos ofrece una serie de procedimientos almacenados ya implementados. Figura 92 Así. Por ejemplo.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Si queremos borrar un procedimiento almacenado. ejecutaremos la sentencia DROP PROCEDURE. podemos elaborar una consulta SELECT sobre la tabla de sistema que contiene los usuarios conectados. si queremos borrar el procedimiento almacenado. es decir. como podemos observar en la Figura 92. listos para ejecutar. o ejecutar el procedimiento almacenado sp_who. cada uno con su propio objetivo o fin. creado en el anterior ejemplo. si escribimos sp_who. obtendremos una lista con todos los usuarios conectados. 172 . Si queremos obtener una lista con todas las tablas del sistema.

© Grupo EIDOS

19. Procedimientos almacenados y triggers

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

Figura 93

Extended stored procedures
Una de las principales ventajas que ofrece SQL Server es que permite la ejecución de procedimientos almacenados escritos en otro lenguaje de programación, como por ejemplo C, aprovechando de este modo toda la potencia que ofrece un compilador de este estilo. De todos es conocida la potencia que ofrece el lenguaje C, ya que es un compilador a bajo nivel. Esto es, permite interaccionar con el hardware, obtener datos del Sistema Operativo, etc. La técnica que permite el aprovechamiento de un lenguaje externo a SQL Server, para el diseño de procedimientos almacenados se denomina Extended Stored Procedures. Este es un caso un poco más complicado que el manejo de procedimientos almacenados intrínsecos al propio SQL Server. Los Extended Stored Procedures se implementan como DLLs, que serán privadas a SQL Server, y cuya gestión del espacio de memoria corresponde a éste. Una DLL (Dinamic Link Library) es un conjunto de funciones, que se cargan dinámicamente en memoria, esto es, se cargan en memoria cuando vayan a ser usadas, y se descargan cuando no se necesiten. Si por ejemplo, uno de estos procedimientos intenta acceder a una dirección que cae fuera del espacio de

173

Bases de datos con SQL Server 2000 – Transact SQL

© Grupo EIDOS

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

sp_addextendedproc nombre_función, nombre_DLL Código fuente 152

Para ejecutar una de estas funciones en una base de datos distinta de aquella en la que se ha registrado, se deberá preceder el nombre de la base de datos al nombre de la función. Hay que destacar que estos procedimientos únicamente podrán ser ejecutados y registrados por el administrador del sistema. Si éste desea permitir la ejecución a los demás usuarios, deberá ejecutar el Código fuente 153.

GRANT EXEC ON procedimiento TO PUBLIC Código fuente 153

Esta sentencia SQL otorga (GRANT) privilegios de ejecución (EXEC) sobre el procedimiento especificado, a todos los usuarios de la base de datos. Si sólo deseamos otorgar este privilegio a un usuario, deberemos especificar su identificador de usuario tras TO.

Triggers
Los disparadores de procedimiento, más comúnmente conocidos como triggers, son una especie de procedimientos almacenados, a diferencia que se ejecutan cuando ocurre un evento sobre alguna tabla. Entendemos por evento, cualquier acción del tipo: • • • Inserción Borrado Actualización

La sintaxis de la sentencia de creación de triggers es la siguiente: CREATE TRIGGER nombre ON tabla FOR accion AS codigo donde acción especifica el evento que debe ocurrir para que se dispare el trigger, y que puede ser: • • •
174

UPDATE: actualización. INSERT: inserción. DELETE: borrado.

© Grupo EIDOS

19. Procedimientos almacenados y triggers

Por ejemplo, si queremos crear un trigger llamado modificación_autor, sobre la tabla Authors, que muestre un mensaje cada vez que se actualiza una fila de la tabla, deberemos escribir el Código fuente 154.

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

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

UPDATE authors SET au_fname

= 'Miguel' WHERE au_id = '267-41-2394' Código fuente 155

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

DROP TRIGGER modificacion_autor Código fuente 156

175

como pueden ser las de control de flujo. Para ello se comprueba que el número de filas que devuelve el select sea cero. y se ejecutará el insert.. Por ejemplo. La sentencia IF . siendo el servidor el encargado de realizar las operaciones. dependiendo de que la condición sea verdadera o falsa. descargando de trabajo al cliente. . que permite al usuario que los usa abstraerse de la complejidad interna que puede encerrar.. las de iteración. ELSE Esta sentencia permite evaluar una expresión y provocar la entrada o ejecución de un bloque u otro.. que veremos en detalle mediante algunos ejemplos prácticos.Ejemplos prácticos de uso de procedimientos almacenados Introducción Los procedimientos almacenados es una de las principales funcionalidades que ofrece SQL-Server. con los parámetros adecuados. en cuyo caso la condición es verdadera. El Código fuente 157 muestra un procedimiento almacenado encargado de insertar un nuevo tipo de transporte si no está dado de alta en la base de datos. pueden ser llamados desde otras aplicaciones. etc. Los procedimientos almacenados suelen utilizar sentencias de diverso tipo de T_SQL.

. 'Metro' exec sp_Insertar_TipoTransporte 4. Para ello ejecutamos el Código fuente 158. 'Tranvía' Código fuente 158 Para comprobar lo que ha ocurrido en la tabla de tipos de transporte. @TT_Nombre varchar(40) AS if (select count(*) from TipoTransporte where TT_ID = @TT_ID) = 0 insert into TipoTransporte values (@TT_ID. necesitamos un parámetro más de llamada. para comprobar como funciona.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS CREATE PROCEDURE sp_Insertar_TipoTransporte @TT_ID int. que devolverá ‘S’ si se ha producido error. CREATE PROCEDURE sp_Insertar_TipoTransporte @TT_ID int. @TT_Nombre) Código fuente 157 Probemos a insertar un tipo de transporte que exista. @TT_Nombre varchar(40). y devolver un parámetro que nos indique si ha habido error o no. y es que se ha encerrado entre las palabras begin. ejecutamos el siguiente código. exec sp_Insertar_TipoTransporte 1. Para ejecutar ahora el procedimiento. 178 . y ‘N’ si se ha insertado el registro con éxito. SELECT * FROM TipoTransporte Código fuente 159 Y como podemos comprobar. además del uso de la sentencia set para asignar un valor a un parámetro o variable..end el bloque que deseamos se ejecute cuando se cumple la condición. @error char(1) output AS if (select count(*) from TipoTransporte where TT_ID = @TT_ID) = 0 begin set @error = 'N' insert into TipoTransporte values (@TT_ID. Podemos hacerlo un poco más elegante. @TT_Nombre) end else set @error = 'S' Código fuente 160 Podemos observar una novedad. sólo se ha insertado el último registro. cuyo tipo debe coincidir con el tipo del parámetro de salida declarado en el procedimiento. y otro que no exista.

© Grupo EIDOS 20.else. al no existir todavía en la base de datos.Prv_ID and Provincia. 'Metro'. exec sp_Hay_Comerciales 'Barcelona' Código fuente 164 La sentencia CASE Una variante a la instrucción if. Sin embargo.. equivaldría al siguiente. 179 . querrá decir. lo que indica que el registro se ha insertado correctamente. Ejemplos prácticos de uso de procedimientos almacenados declare @error char(1) exec sp_Insertar_TipoTransporte 1.. el código expuesto antes utilizando if. @error output select @error Código fuente 161 Al ejecutar este código. Ejecutemos el procedimiento para comprobar si existen comerciales para la provincia de Barcelona. al ser un inner join. utilizando case.Prv_Nombre = @Prv) > 0 print 'Hay comerciales asociados a la provincia de ' + @Prv else print 'No hay comerciales asociados a la provincia de ' + @Prv Código fuente 163 En este código podemos comprobar como se obtiene el número de registros de un inner join. para obtener el identificador de la provincia que coincide con el nombre que se pasa como parámetro.else es la sentencia case. muy útil sobre todo cuando tenemos muchos if anidados. que o bien no existe la provincia. efectivamente. Por ejemplo. mostramos el parámetro de salida y vemos como. 'Aeropuerto'. Si dicho atributo es nulo.. si ejecutamos este otro código. se devuelve una ‘S’. CREATE PROCEDURE sp_Hay_Comerciales @Prv varchar(40) AS if (select count(*) from Provincia inner join Comercial on Comercial. o bien no existe ningún comercial asociado a ella. @error output select @error Código fuente 162 Otro ejemplo nos muestra como comprobar si existen filas para un parámetro determinado. se devolverá una ‘N’. lo que indica que se ha producido un error. con el fin de mostrar un mensaje determinado. declare @error char(1) exec sp_Insertar_TipoTransporte 5..Prv_ID = Provincia.

Exec (‘select * from Provincia’) Código fuente 166 Esto puede resultar muy útil para montar sentencias en tiempo de ejecución. sino que además sirve para evaluar una expresión de tipo carácter.Prv_ID' end -.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS CREATE PROCEDURE sp_Hay_Comerciales2 @Prv varchar(40) AS select case (select count(*) from Provincia inner join Comercial on Comercial.La variable condicion almacena la claúsula where y la variable join los join declare @condicion varchar(255) declare @join varchar(255) set @condicion = '' set @join = '' -. Por ejemplo.Prv_Nombre = @Prv) when 0 then 'No hay comerciales asociados a la provincia de ' + @Prv else 'Hay comerciales asociados a la provincia de ' + @Prv end Código fuente 165 Ejecución dinámica de sentencias: la instrucción EXEC Como hemos visto. @CP varchar(5) AS -. el siguiente código muestra como ejecutar un select de todas las provincias. mientras que si especifica el código postal. concatenar la condición if not @CP is null begin if @condicion <> '' set @condicion = @condicion + ' and ' 180 . por este atributo. o para los cuales deseamos realizar un tratamiento distinto dependiendo de los valores que tomen. se realizará una búsqueda. pero no sólo eso. montar la condicion y el join if not @Prv is null begin set @condicion = ' Provincia. CREATE PROCEDURE sp_Clientes @Prv varchar(40). Recibe dos parámetros. cuyos valores no conocemos a priori. la instrucción exec se utiliza para ejecutar un procedimiento almacenado. se realizará una búsqueda de todos los clientes que sean de esta provincia.Prv_ID = Cliente. además.Prv_Nombre = ' + '''' + @Prv + '''' set @join = ' inner join Provincia on Provincia.Si se ha especificado la variable @Prv. uno es la provincia y otro es el código postal.Prv_ID = Provincia. El siguiente código mostraría un procedimiento almacenado que se encarga de realizar búsquedas de clientes.Prv_ID and Provincia.Si se ha especificado el cod postal. Si se especifica únicamente la provincia.

Convert (tipo. Es entonces cuando intervienen dos instrucciones que nos permiten realizar esto. para evaluar la expresión resultante. en el caso de que se especifique como parámetro el nombre de la provincia. Dichas instrucciones son cast y convert. Si ejecutamos el anterior procedimiento almacenado. obtendremos lo siguiente. exec sp_Clientes 'Madrid'. dependiendo de los parámetros que se indiquen. obtendremos todos los clientes exec sp_Clientes null. sin especificar ninguno de los parámetros. una almacenará la condición. y otra almacenará el join que se deberá realizar con la tabla de provincia. null Código fuente 168 Si especificamos el parámetro provincia = Madrid.© Grupo EIDOS 20. Ejemplos prácticos de uso de procedimientos almacenados set @condicion = @condicion + ' Cli_CodPostal = ' + '''' + @CP + '''' end if @condicion <> ‘’ set @condicion = ‘ where ‘ + @condicion exec ('select * from cliente ' + @join + @condicion) Código fuente 167 Manejamos dos variables. Cast (expresion as tipo) y la de convert. se ejecuta la sentencia exec. obtendremos todos los clientes de la provincia de Madrid exec sp_Clientes ‘Madrid’. que se ira concatenando. Una vez montadas estas cadenas. 28023 Código fuente 170 Conversión de tipos Muchas veces nos encontraremos la necesidad de convertir un valor de un tipo a otro tipo para operar con él. La sintaxis de la expresión cast es la siguiente. null Código fuente 169 Si además especificamos el parámetro codigo postal. expresion) 181 .

hasta que deje de cumplirse la condición boleana. Su sintaxis es la siguiente. CREATE PROCEDURE sp_ActualizaComercial AS WHILE (SELECT Com_Categoria FROM Comercial) <> '6' BEGIN UPDATE Comercial SET Com_Categoria = cast(Com_Categoria as int) * 2 IF (SELECT MAX(Com_Categoria) FROM Comercial) > 6 BREAK ELSE CONTINUE END Código fuente 173 182 . WHILE expresion sentencias [BREAK] [CONTINUE] La claúsula break es optativa y indica al bucle que deje de ejecutarse. mientras que la claúsula continue. se recorre los comerciales. hasta que alguno supera el valor de 6. En el siguiente ejemplo. mientras que la categoría sea distinta de 6. indica al bucle que se reinicie.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Por ejemplo. que también es optativa. y va duplicando la misma. Cast (‘01/01/01’ as datetime) Código fuente 171 O un carácter a entero cast (‘3’ as int) Código fuente 172 La sentencia WHILE La instrucción while permite iterar un numero de veces que no conocemos a priori. podemos utilizarlo para convertir un tipo de datos carácter a fecha.

El bloque de sentencias permite prácticamente cualquier tipo de ellas dentro del lenguaje T-SQL. actualizar o borrar. sino que simplemente se ejecuta para cambiar o comprobar los datos que se van a insertar. si por ejemplo se ejecuta una inserción. una actualización. Recordamos cual es su sintaxis: CREATE TRIGGER nombre ON tabla FOR [DELETE | INSERT | UPDATE] AS sentencias Las palabras reservadas DELETE. se ejecutarían las sentencias definidas para el trigger en concreto de esa tabla específica. que se ejecutan cuando ocurre una acción dentro de la base de datos. no se podrá utilizar la sentencia select. ya que un trigger no puede devolver datos al usuario. los triggers o desencadenadores son una especie de procedimientos almacenados. Por ejemplo. o un borrado de una tabla. . pero con ciertas limitaciones.Triggers en SQL-Server 2000 Introducción Como ya se ha comentado. Así. INSERT y UPDATE corresponden a cada una de las acciones para las cuales se puede definir un desencadenador dentro de la tabla especificada.

si a su vez vuelve a modificar otra tabla. puede provocar la ejecución de otro trigger. dentro del trigger. Si se supera el nivel de anidamiento permitido. Así. se pueden definir distintos triggers para la misma acción. y así sucesivamente. cuya estructura es similar a la tabla donde se esta ejecutando el trigger. y resulta que dicha tabla ya tenía definido un trigger para esa misma acción. si queremos recuperar los datos de la tabla que estamos borrando. • • Limitaciones de los triggers Aunque ya se han comentado algunas de las limitaciones a la hora de programar triggers. es decir. precisamente. bien de forma indirecta. veamos en detalle las restricciones que implica la definición de triggers: • • • • Un trigger sólo se puede aplicar a una tabla Aunque un trigger se defina dentro una sola base de datos. Desencadenadores recursivos: se permite la recursividad entre las llamadas a los triggers. los datos que van a ser añadidos o borrados. es decir. se cancelará la ejecución de los triggers. si definimos un trigger para insert. y que contiene. Desencadenadores anidados: si un trigger cambia una tabla en la que se encuentra definido otro trigger. entre los cuales cabe destacar los siguientes: • Desencadenadores múltiples: para una misma tabla. se ejecutarán ambos triggers cuando ocurra dicho evento sobre la tabla. por ejemplo. puede hacer referencia a objetos que se encuentran fuera de la misma La misma acción del desencadenador puede utilizarse para definir más de un trigger sobre la misma tabla La opción SET elegida dentro de la ejecución de un desencadenador. volverá a su estado previamente definido una vez concluya la ejecución del mismo 184 . La utilidad de estas dos tablas es la de realizar comprobaciones entre los datos antiguos y los nuevos. se deberá ejecutar el siguiente código: SELECT * FROM deleted Código fuente 174 Tipos de desencadenadores SQL-Server permite la definición de varios tipos de triggers.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Las tablas deleted e inserted Dentro de la definición de un trigger. podemos hacer referencia a un par de tablas lógicas. es una copia de la tabla en la cual se van a insertar o borrar los datos. es decir. un trigger puede llamar a su vez a otro. se provoca la llamada de este último que. bien de forma directa.

el siguiente código hace referencia a una tabla x. que no existe en el momento de escribir el trigger.xp_sendmail 'Pepe'. Por ejemplo. DROP TRIGGER enviar_correo GO CREATE TRIGGER enviar_correo ON Oferta FOR INSERT. UPDATE.. CREATE TRIGGER trigger1 on authors FOR INSERT. 'Tenemos una nueva oferta en nuestra base de datos.au_id = x. 185 .xp_sendmail 'Pepe'. a. muestra la forma de enviar un mensaje de correo electrónico a una persona. no se permite la utilización de las sentencias del DDL dentro de la definición de un trigger En una vista no se puede utilizar un desencadenador Resolución diferida de nombres La resolución diferida de nombres es una utilidad que permite escribir triggers que hagan referencia a tablas que no existen en el momento de la compilación.au_lname. x.© Grupo EIDOS 21. cuando se añade una nueva oferta.' GO Código fuente 176 Sin embargo.. si queremos que se envíe el mensaje cada vez que se cambia algo en la tabla de ofertas. deberemos reescribir el trigger para las acciones update y delete. El siguiente código.au_id GO Código fuente 175 Ejemplos Veamos a continuación algunos ejemplos que complementen lo visto hasta ahora. CREATE TRIGGER enviar_correo ON Oferta FOR INSERT AS EXEC master. UPDATE. Triggers en SQL – Server 2000 • • Así mismo.au_fname. como se muestra en el siguiente código. DELETE AS EXEC master. DELETE AS SELECT a.info FROM authors a INNER JOIN x ON a.

@job_id = i.emp_id JOIN jobs j ON j. Ahora se comprueba si el trabajo que estamos asignando es el 1. que almacenará el nivel para el empleado. y la tabla de empleados tal y como quedaría después de ejecutarlo (en otras palabras. 16. @max_lvl = max_lvl. @emp_lvl tinyint. UPDATE AS /* Obtener el nivel para el trabajo actual */ DECLARE @min_lvl tinyint. 1. Para ello comprobamos esta situación mediante un if y. y job_id que almacena el identificador del trabajo que se va a actualizar. si el nivel del trabajo no está dentro de los valores permitidos. 1) ROLLBACK TRANSACTION END ELSE IF NOT (@emp_lvl BETWEEN @min_lvl AND @max_lvl) BEGIN RAISERROR ('El nivel para el trabajo:%d debe estar entre %d y %d. @max_lvl tinyint. @min_lvl. utilizando la tabla inserted para comprobar los valores que se van a añadir o modificar.job_lvl. A continuación realizamos un join entre la tabla de empleados y la tabla inserted o. @job_id smallint SELECT @min_lvl = min_lvl.job_id = i. entre la antigua y la nueva). 186 .Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS 'La tabla de ofertas ha cambiado' GO Código fuente 177 En el Código fuente 178. emp_lvl. que almacenarán los valores mínimo y máximo permitidos para un trabajo. en cuyo caso el valor para el nivel debería ser 10. y a continuación con la tabla de trabajos.job_id IF (@job_id = 1) and (@emp_lvl <> 10) BEGIN RAISERROR ('Debe especificar el nivel 10 para el trabajo 1'. posibilite la cancelación de la acción.'. y se cancela la transacción con ROLLBACK TRANSACTION. @job_id. 16. @max_lvl) ROLLBACK TRANSACTION END Código fuente 178 Primero declaramos las variables min_lvl y max_lvl.job_id FROM employee e INNER JOIN inserted i ON e. @emp_lvl = i. se muestra como crear un trigger que. Todo esto sirve para encontrar los valores de la tabla de trabajos que corresponden al trabajo que vamos a asignar al empleado.emp_id = i. entre la tabla de empleados tal y como está antes de ejecutar el trigger. lo que es lo mismo. se lanza un error con la sentencia RAISERROR. CREATE TRIGGER empleado_modificar ON employee FOR INSERT. en caso de que sea verdadero.

© Grupo EIDOS 21. Para los desconocedores del lenguaje C. quizá la última sentencia RAISERROR no les sea demasiado clara. que cada %d que aparece dentro de la cadena de texto será sustituido respectivamente por el valor de cada una de las tres últimas variables que aparecen dentro de dicha sentencia. simplemente. 187 . Destacar. y se cancelará la transacción. Si esto no se cumple se volverá a lanzar un error. Triggers en SQL – Server 2000 En otro caso se comprueba que el nivel de la tarea esté dentro de los límites permitidos para el empleado.

.

Seguridad lógica: la seguridad lógica afecta a la protección de los datos de accesos u operaciones no deseados. una consulta a información no autorizada por parte de un usuario. y puede realizar "casi" cualquier operación. para la protección de la información. en el que la principal división se establece entre el administrador del sistema y el resto de usuarios. ya que la seguridad física afecta a aspectos de administración (copias de seguridad. El administrador del sistema actúa al nivel de superusuario. sobre todo en entornos grandes. • En este capítulo nos centraremos en la seguridad lógica. o parte de sus atributos. etc. etc. el borrado de una tabla.) que escapan a los objetivos del presente curso. donde la amenaza de potenciales accesos indebidos es muy grande. mientras que un usuario corriente sólo podrá . mantenimientos de dispositivos duplicados con mirror.Seguridad Introducción El de la seguridad es un tema muy importante. Podemos hablar de seguridad a dos niveles: • Seguridad física: entendemos por seguridad física aquella que persigue salvaguardar los datos de agresiones externas. Concesión de privilegios SQL Server mantiene un sistema de perfiles. debido a aspectos físicos. como por ejemplo la destrucción de la base de datos. como por ejemplo. como por ejemplo un incendio o una inundación.

Del mismo modo se pueden establecer privilegios sobre los objetos. a unos determinados usuarios. bases de datos. . GRANT SELECT ON authors TO PUBLIC Código fuente 181 190 . Por ejemplo. CREATE TABLE TO Pepe Código fuente 179 Si queremos otorgar todos los permisos a todos los usuarios. si queremos otorgar el permiso de crear bases de datos y tablas al usuario Pepe. sino también en el ámbito de vista. que normalmente suele ser el superusuario. borrado. un usuario puede dar permiso a otro usuario. En principio. En este caso. La sentencia que permite otorgar privilegios es la siguiente: GRANT sentencia TO usuarios Por ejemplo. o procedimientos almacenados. en lugar de sobre las acciones. este control corresponde al administrador del sistema. deberemos escribir la sentencia que aparece en el Código fuente 180. Los permisos se pueden establecer en el ámbito de un usuario (conceder un privilegio a un usuario) o en el ámbito de grupo o público (accesible por todos).Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS realizar operaciones que afecten a sus objetos. Los objetos de SQL Server (tablas..) tienen un propietario. No sólo se pueden conceder permisos en el ámbito de tabla. esto es.. la sintaxis es la mostrada GRANT permisos (columnas) ON tabla TO usuario La sentencia GRANT permite establecer los permisos deseados (inserción. De todas maneras. GRANT ALL TO PUBLIC Código fuente 180 Cuidado con esta sentencia ya que es muy peligroso dejar que cualquier usuario haga lo que quiera. o el usuario que lo haya creado. no podrá hacerlo. a menos que el propietario o el administrador le dé permiso. actualización) sobre una serie de atributos de una tabla. Del mismo modo. si deseamos que todos los usuarios puedan consultar la tabla de autores. para que éste a su vez pueda dar permiso a otros. si otro usuario desea acceder a dicho objeto. los permisos pueden ser propagados en cascada. deberemos escribir lo que indica el Código fuente 181. deberemos escribir la sentencia que muestra Código fuente 179 GRANT CREATE DATABASE. o a los objetos que le permita el administrador u otro usuario.

Seguridad Con esto lo que hacemos es conceder el permiso SELECT sobre la tabla Authors. deberemos ejecutar el Código fuente 182. debemos escribir la sentencia mostrada en el Código fuente 184. GRANT SELECT (au_lname) ON authors TO PUBLIC Código fuente 182 Y si deseamos que además de consultar se pueda actualizar. GRANT EXECUTE ON procedure TO usuario WITH GRANT OPTION Código fuente 184 Revocación de privilegios La sentencia homóloga a la concesión de privilegios es REVOKE. Para revocar todos los permisos. La sintaxis para quitar permisos sobre la ejecución de sentencias es la siguiente: REVOKE sentencia FROM usuarios donde sentencia especifica aquellas cuyos permisos se revocan.© Grupo EIDOS 22. y que éste a su vez pueda conceder este privilegio a otros usuarios. Si queremos restringir el SELECT al campo au_lname. a todos los usuarios. GRANT SELECT. Con esta sentencia podemos quitar permisos a los usuarios sobre un objeto. la sentencia en cuestión es la que muestra el Código fuente 183. REVOKE CREATE DATABASE FROM alberto Código fuente 185 Estamos impidiendo al usuario alberto la posibilidad de crear bases de datos. Por ejemplo. 191 . o para ejecutar ciertas sentencias. y usuarios establece una lista de usuarios a los cuales se les aplicará dicha sentencia. si queremos conceder el privilegio de ejecución de un procedimiento almacenado a un usuario. UPDATE ON authors TO PUBLIC Código fuente 183 Si queremos propagar los privilegios. Por ejemplo. si ejecutamos el Código fuente 185. deberemos especificar ALL como sentencia a aplicar. debemos adjuntar la opción WITH GRANT OPTION.

al usuario Pepe. es decir. éstos conservarán los suyos. el Código fuente 186 revoca todos los permisos a todos los usuarios. REVOKE ALL FROM PUBLIC Código fuente 186 La sentencia para aplicar revocación de permisos a objetos aparece en el Código fuente 187. la sentencia a ejecutar aparece en el Código fuente 189. escribimos lo que indica el Código fuente 188. o tiene varios perfiles. para que la sentencia tenga efecto para todos los usuarios de la base de datos. deberemos establecer public en la lista de usuarios. Por último. au_fname) ON authors FROM Pepe Código fuente 189 Y si queremos revocar dicho permiso no sólo al usuario Pepe. Por ejemplo. REVOKE INSERT ON authors FROM Pepe Código fuente 188 Si no queremos que dicho usuario consulte los atributos au_lname y au_fname de dicha tabla. y permite revocar la propagación en cadena de permisos a usuarios. pero no podrán autorizar a terceros. si queremos revocar los permisos de inserción de filas en la tabla autores. sino también a todos los usuarios a los que éste a otorgado dicho permiso. es decir. pudiendo restringirlos a una serie de atributos o a una o varias tablas. ejecutaremos el Código fuente 190. y a todos los que éstos concedieron permisos. y permite revocar privilegios en cascada. la opción papel permite eliminar la ambigüedad que se puede originar cuando un usuario pertenece a varios grupos. REVOKE [GRANT OPTION FOR] permisos [(atributos)] ON tabla FROM usuarios [CASCADE] AS papel Código fuente 187 La opción GRANT OPTION FOR es opcional. La opción CASCADE es opcional. La opción permisos permite especificar los permisos que se revocarán. Por ejemplo.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Así mismo. au_fname) ON authors FROM Pepe CASCADE Código fuente 190 192 . REVOKE SELECT (au_lname. a los usuarios especificados. REVOKE SELECT (au_lname.

au_fname) ON authors TO conflictivo Código fuente 192 Mantenimiento de vistas Otro método para controlar la seguridad y el acceso indebido a los datos almacenados. El lector se preguntará ¿por qué una vista impide realizar accesos indebidos?. hasta que no se revoque dicha denegación. Pero el problema surge cuando el administrador del sistema se olvida de este detalle y. Si por ejemplo. lo recomendable es denegar el permiso a dicho usuario. lo que nos lleva a pensar que la base de datos puede mantener varias vistas a la vez.© Grupo EIDOS 22. consiste en mantener vistas de la base de datos. es decir la porción de la base de datos que es accesible a los usuarios. la respuesta es fácil. Corresponde al administrador en este caso el estudio de las consultas que se pueden realizar con relación a los usuarios del sistema. mientras no se revoque dicha denegación. La sintaxis del comando para la creación de vistas es la siguiente: 193 . le concede dicho permiso. Puesto que una vista se puede contemplar como una consulta a una parte de la información. Para evitar que esto suceda. si queremos que un usuario no acceda a determinados datos. bastará con revocarle el privilegio a hacerlo. las vistas se corresponden con el esquema externo de la base de datos. Lo que permite es que dichos usuarios no obtengan privilegios. Una vista es un conjunto de información que es accesible por uno o varios usuarios. Del mismo modo podemos actuar para denegarle el permiso de acceder a determinados campos de una tabla. como por ejemplo a los atributos au_lname y au_fname de la tabla de autores. por error. También se dijo que podía haber más de un esquema externo. le daremos vistas que no consulten dicha información. y otorgar permisos sobre las vistas a éstos. tenemos un usuario de la base de datos un tanto conflictivo. DENY SELECT (au_lname. y no queremos que cree bases de datos. Como ya se vio en la parte anterior sobre diseño de bases de datos. no se le podrán conceder privilegios para la creación de bases de datos a dicho usuario. DENY CREATE DATABASE TO conflictivo Código fuente 191 De esta manera. Pues bien. Seguridad Denegación de permisos Otra opción es la de denegar un permiso a uno o varios usuarios. La sintaxis para denegar permisos es la siguiente: DENY sentencia TO usuarios Y para objetos: DENY permisos [(atributos)] ON tabla TO usuarios [CASCADE] El funcionamiento es similar al ya visto en las anteriores sentencias.

de forma jerárquica incluso. ya que permite controlar mejor los usos indebidos de estas sentencias. escribimos el Código fuente 193. existen una serie de recomendaciones. el código de la vista.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS CREATE VIEW vista [(atributos)] [WITH ENCRYPTION] AS sentencia [WITH CHECK OPTION] La opción WITH ENCRYTION permite encriptar. ocultar. Usar triggers para evitar ciertas operaciones no deseadas. es decir. deberá ejecutar la vista. Establecer perfiles y grupos de usuarios. 194 . actualización y/o borrado de filas. escribiendo la sentencia que muestra el Código fuente 194 SELECT * FROM autores Código fuente 194 Recomendaciones Por último. para de esta manera saber en todo momento quien está haciendo qué. ya que permite establecer más fácilmente los niveles de seguridad. que todo administrador que se precie debe tener en cuenta a la hora de implementar la seguridad de una base de datos: • • • • Proporcionar un único identificador a cada usuario. Por ejemplo. CREATE VIEW autores (au_lname) AS SELECT au_lname FROM authors Código fuente 193 Si un usuario quiere consultar ahora los autores de la base de datos. Proporcionar a los usuarios procedimientos almacenados para la inserción. si queremos crear una vista sobre el atributo au_lname de la tabla authors. mientras que la opción WITH CHECK OPTION permite hacer visibles las modificaciones realizadas tras la ejecución de la vista.

y en un árbol pueden anidar varias especies (N-M). tipo_hoja región: cod_region. De cada especie se quiere conocer el nombre de la misma. desc_region Las relaciones que tenemos son las siguientes: • • ave-árbol: un ave puede anidar en varios tipos de árboles. la clase a la que pertenece y el tipo de árbol en el que anida. para recopilar los conocimientos aprendidos a lo largo del curso. y la región de la cual es autóctono. Se desea almacenar la información de cada una de las especies del país. nombre. observaciones árbol: cod_arbol. De cada clase de árbol. estudiaremos un ejemplo. se desea conocer su nombre. así como si es un ave migratoria o no. clase. el tipo de hoja. migratoria. . El problema en sí es mantener una base de datos de ornitología (ciencia que estudia las aves). y en una región puede haber distintas clases de árboles (N-M). Por consiguiente. nom_cientifico.Ejemplo práctico de implementación Introducción En este capítulo. el nombre científico. árbol-región: un árbol puede ser autóctono de varias regiones. nombre. tenemos las siguientes entidades: • • • ave: cod_ave.

nos queda el esquema lógico que muestra la Figura 95. al usar un SGBD concreto para la implementación. Figura 94 Una vez realizado el diseño conceptual. nos conectamos a ella. Destacar que lo que aquí entendemos por diseño físico. con las claves de ambas entidades como atributos. Lenguaje de definición de datos Lo primero que haremos será crear la base de datos. Cada entidad genera una tabla. para obtener el esquema físico. también engloba al diseño lógico específico. Figura 95 El siguiente paso en el diseño es realizar el diseño físico. podemos obtener el diagrama entidad-relación que vemos en la Figura 94. a la que denominaremos ornitología. utilizaremos el Query Analizer de SQL Server. con sus atributos. cuya primera etapa es el paso a tablas.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Con la anterior información. Lo que realizaremos es codificar las instrucciones necesarias en Transact SQL. Para implementar el esquema en Transact SQL. y las relaciones N-M generan también tabla. 196 . CREATE DATABASE ornitologia Código fuente 195 Una vez creada la base de datos. Con esto. el siguiente paso es realizar el diseño lógico. seleccionándola de la lista desplegable que aparece en la parte superior derecha del Query Analizer. ya que en nuestro caso no se aplicarán métodos de normalización o particionamiento. para lo cual escribimos el Código fuente 195.

el siguiente paso es crear los índices para ellas. cod_arbol smallint NOT NULL) CREATE TABLE arbol_region ( cod_arbol smallint NOT NULL. 197 .© Grupo EIDOS 23. Para especificar si un ave es migratoria o no. Análogamente. no se podrá insertar filas que no tengan valores nulos para dichos atributos. Empezaremos por crear un índice único que será la clave de la tabla ave. CREATE TABLE arbol ( cod_arbol smallint NOT NULL. que son ave_arbol. se utilizará un campo bit. es decir. Ejemplo práctico de implementación A continuación crearemos las tablas obtenidas en el esquema lógico. CREATE TABLE region ( cod_region smallint NOT NULL. nombre varchar(30) NOT NULL. Empezaremos por crear la tabla ave. y un 1 si lo es. y arbol_region: CREATE TABLE ave_arbol ( cod_ave smallint NOT NULL. migratoria bit) Código fuente 196 En la anterior sentencia cabe destacar que los atributos cod_ave y nombre han sido declarados como no nulos. nombre varchar(30) NOT NULL. y que utilizará el campo cod_ave. cod_region smallint NOT NULL) Código fuente 199 Una vez creadas las tablas. es decir. al que llamaremos clave. tipo_hoja varchar(10)) Código fuente 197 Seguimos con la tabla de regiones. CREATE TABLE ave ( cod_ave smallint NOT NULL. creamos la tabla arbol. nom_cientifico varchar(30). un 0 para indicar que el ave no es migratoria. desc_region varchar(30) NOT NULL) Código fuente 198 Y por último las tablas que las relacionan. clase varchar(10).

nos hemos olvidado de definir un atributo para la tabla ave. y para realizar algunas consultas. para introducir un nuevo campo.arbol_region. Nosotros. por cod_arbol y cod_region para la tabla. donde los índices de clave única serán por cod_arbol para la tabla arbol. crearemos una vista para consultar todas las aves que son migratorias CREATE VIEW migratorias AS SELECT nombre FROM ave WHERE migratoria = 1 Código fuente 203 Lenguaje de manipulación de datos Hasta ahora hemos estado utilizando el Lenguaje de Definición de Datos. Empezaremos añadiendo los siguientes datos: • Tabla ave Cod_ave Nombre 1 2 Flamenco Pato salvaje Nom_cientifico Clase Zancuda Migratoria Observaciones Si Migran en grupo hacia lugares cálidos Palmípedo No 198 .cod_arbol) arbol_region ADD CONSTRAINT clave_ar PRIMARY KEY (cod_arbol. Pero eso no es problema.cod_region) Código fuente 201 Oh. ya que podemos modificar cómodamente el esquema de dicha tabla. para definir el esquema. y por cod_ave y cod_arbol para la tabla ave_arbol: ALTER ALTER ALTER ALTER TABLE TABLE TABLE TABLE arbol ADD CONSTRAINT clave_ab PRIMARY KEY (cod_arbol) region ADD CONSTRAINT clave_re PRIMARY KEY (cod_region) ave_arbol ADD CONSTRAINT clave_aa PRIMARY KEY (cod_ave. es labor del administrador el decidir a quien y sobre que objetos otorga qué permisos. ALTER TABLE ave ADD observaciones text NULL Código fuente 202 Por último. A continuación utilizaremos el Lenguaje de Manipulación de Datos para introducir información en el esquema. por cod_región para la tabla región. de momento.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS ALTER TABLE ave ADD CONSTRAINT clave_av PRIMARY KEY (cod_ave) Código fuente 200 Análogamente hacemos con las demás tablas. !vaya!. mediante la sentencia ALTER.

nombre. 'Palmipedo'. 'Golondrina común'. 'Mirlo Blanco'. observaciones) VALUES (1. 'Zancuda'. 'Migran en grupo hacia lugares cálidos') INSERT INTO ave (cod_ave. migratoria) VALUES (2. 'Naranjo'. 'Pino'. 1. 1. 'Caduca') INTO arbol (cod_arbol. (1. (3. 'Caduca') INTO arbol (cod_arbol. 'Famosas por los versos de Becquer') Código fuente 204 • Tabla árbol Cod_arbol Nombre Tipo_hoja 1 2 3 4 Encina Roble Naranjo Pino Caduca Perenne Caduca Perenne Tabla 34 INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INTO arbol (cod_arbol. nombre. 'Perenne') INTO arbol (cod_arbol. 'Pato salvaje'. migratoria. clase. migratoria. 'Encina'. nombre. observaciones) VALUES (3.© Grupo EIDOS 23. 'Flamenco'. nombre. Ejemplo práctico de implementación 3 4 Mirlo Blanco Golondrina Golondrina común Tabla 33 Si Si Emite un sonido muy peculiar Famosas por los versos de Becquer INSERT INTO ave (cod_ave. (4. 'Perenne') tipo_hoja) tipo_hoja) tipo_hoja) tipo_hoja) Código fuente 205 199 . nom_cientifico. nombre. 'Emite un sonido muy peculiar') INSERT INTO ave (cod_ave. observaciones) VALUES (4. (2. migratoria. 0) INSERT INTO ave (cod_ave. nombre. 'Golondrina'. 'Roble'. nombre. clase. 1. nombre.

'Pirineos') INTO region (cod_region. cod_region) (cod_arbol. 1) INTO arbol_region (1. con los valores correspondientes a cada código de arbol y región. naranjos en la región Levante. 3) INTO arbol_region (4. sur y nor-noroeste y robles en la región centro. encinas en las regiones centro. (2. cod_region) Código fuente 207 200 . cod_region) (cod_arbol. 4) INTO arbol_region (3. cod_region) (cod_arbol. cod_region) (cod_arbol. INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INTO arbol_region (4. cod_region) (cod_arbol. cod_region) (cod_arbol. 'Levante') desc_region) desc_region) desc_region) desc_region) desc_region) Código fuente 206 Supongamos ahora que nos dicen que puede haber pinos en las regiones centro. 3) INTO arbol_region (2. 'Centro') INTO region (cod_region. 5) INTO arbol_region (1. (5. nor-noroeste y Pirineos. 'Sur') INTO region (cod_region. 1) (cod_arbol. 2) INTO arbol_region (1. (1. Lo que tenemos que hacer es dar de alta estas filas en la tabla arbol_region.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • Tabla región Cod_region Desc_region 1 2 3 4 5 Centro Sur Nor-noroeste Pirineos Levante Tabla 35 INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INSERT VALUES INTO region (cod_region. (3. 1) INTO arbol_region (4. cod_region) (cod_arbol. 'Nor-noroeste') INTO region (cod_region. (4.

arbol_region.cod_arbol Código fuente 210 Lo que hace la anterior sentencia es obtener el atributo desc_arbol de la tabla arbol. UPDATE ave SET nombre = 'Mirlo común' WHERE nombre = 'Mirlo blanco' Código fuente 209 Supongamos ahora que queremos realizar las siguientes consultas. Para ello deberemos contar todas las filas de la tabla ave. hacemos un join contra la tabla arbol_region. Para ello debemos actualizar la fila correspondiente. Para ello. Lo que hay que hacer es crear las filas correspondientes a cada uno de los códigos en la tabla ave_arbol. primero se pone la condición de que la región debe ser centro. cuyas sentencias se especifican a continuación: • Todos los árboles de la región centro: SELECT nombre FROM arbol. INSERT VALUES INSERT VALUES INTO ave_arbol (cod_ave. Ejemplo práctico de implementación Supongamos ahora que nos dicen que el mirlo blanco anida en los naranjos y en los pinos. encina y roble. 3) INTO ave_arbol (cod_ave.cod_region = arbol_region. Con las filas obtenidas. y que los patos salvajes anidan en los estanques donde preferentemente haya encinas.cod_arbol = arbol. El resultado obtenido son los árboles pino. cod_arbol) (3. 1) Código fuente 208 Puesto que de momento no hemos encontrado ningún mirlo blanco. • El número de aves que son migratorias.cod_region AND arbol_region. 4) INSERT INTO ave_arbol (cod_ave. cod_arbol) VALUES (2.© Grupo EIDOS 23. Si ahora queremos obtener la descripción del árbol. deberemos realizar otro join contra la tabla árbol. 201 . cambiaremos este ave por el mirlo común. cuyo atributo migratoria tenga el valor true. region WHERE region. para obtener el código de los árboles cuya región es centro. con la sentencia que aparece en el Código fuente 209. cod_arbol) (3.desc_region = 'centro' AND region.

Lo que debemos hacer es seleccionar primero todas las filas cuyo atributo tipo_hoja para luego hacer el join de estas filas con la tabla ave_arbol por el campo cod_arbol. ave WHERE arbol. ave_arbol.cod_arbol = ave_arbol. SELECT ave. con la tabla ave.tipo_hoja = 'caduca' AND arbol. podemos aprovechar la vista anterior. obtenemos que dichas aves corresponden al mirlo blanco y al pato salvaje Si ahora queremos consultar todas las aves que son migratorias. deberemos realizar un join de las filas obtenidas.nombre FROM arbol. La anterior explicación se resume en la sentencia mostrada en el Código fuente 212. SELECT * FROM migratorias Código fuente 213 202 . para obtener así el código de las aves que anidan en dichos árboles. por el atributo cod_ave y proyectar sobre nombre. Acto seguido. • El nombre de las aves que anidan en árboles de hoja caduca ordenados alfabéticamente. para hacerlo ejecutamos el Código fuente 213.cod_ave ORDER BY ave.cod_arbol AND ave_arbol.cod_ave = ave.nombre Código fuente 212 Como resultado del Código fuente 212. si queremos obtener el nombre de las aves.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS SELECT count(*) FROM ave WHERE migratoria = 1 Código fuente 211 El resultado obtenido es el de 3 aves.

que permitía navegar entre ellos para obtener la información que se necesitaba. la evolución de estos modelos.. ha permitido el afianzamiento de un modelo que se ha tomado como base de la práctica totalidad de los SGBD existentes en la actualidad. . El primero nació como una conceptualización de la forma de entender las relaciones entre los objetos. Sería algo del estilo “empresa – empleado – empresa . sino grafos. la realidad es que en la actualidad su uso no supera el 5% de la cuota de mercado con respecto al modelo relacional. mediante referencias a los mismos. una clasificación natural. no ha sido sino hasta hace unos pocos años cuando este modelo vio la luz. es decir. Sin embargo. el modelo relacional. los primeros modelos que surgieron fueron el jerárquico y el modelo en red. Como ya se ha comentado. era una especie de clasificación del modo “pais – comunidad – provincia – localidad” o “empresa – departamento – empleado”.. lo cual dificulta ampliamente la definición y el manejo del esquema. como consecuencia de una necesidad de simplificación de los primeros modelos que se usaron como base. El modelo en red nació como una ampliación del modelo jerárquico. A pesar de ello. Aunque fueron muchos los que apostaron por éstas. el relacional. la evolución siguió otra rama alternativa.”. cuya simplicidad y potencia revolucionaron el mercado de las bases de datos.Presente y futuro de las bases de datos La evolución de las bases de datos en los últimos años. dieron lugar a uno nuevo. en el cual ya no se tienen árboles. Sin embargo. Para que el lector lo comprenda mejor. Las relaciones entre los objetos se establecían de una manera natural. dando lugar a las denominadas bases de datos orientadas a objetos.

tediosa y difícil. Como el lector ya habrá podido comprobar.) información de una manera más útil. consiste en la navegación a través de los datos para inferir conocimiento mediante técnicas de Inteligencia Artificial. 204 . Como su propio nombre indica. que implica una carga. o personalizar el tipo de información que un cliente puede recibir. y puede no tener relación ninguna entre sí (cada departamento manejaría únicamente la información relevante al mismo). Por ejemplo. como por ejemplo alto. proveedores. además de incorporar sus propios métodos. ROLAP. para evitar incoherencias. con la peculiaridad que el acceso se realiza en varias dimensiones de una forma más eficaz (por ejemplo las ventas por proveedores en cada región). y se resume en la Figura 96. Así por ejemplo. que en un principio es gestionada desde ámbitos distintos. este proceso. Además. es una tarea ardua. Así por ejemplo. clientes. posibles clientes potenciales para una campaña comercial.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Debido a lo anterior. el concepto de data warehousing (en lo sucesivo DW) se refiere a la posibilidad de integrar toda esta información. Pues bien. y que ya disponen de su propio lenguaje). joven. Por otro lado. en un futuro no muy lejano. cuyos atributos pueden ser a su vez referencias a objetos. Así nace el modelo objeto-relacional. por ejemplo. caro. De esta forma se puede obtener. por ejemplo. Una de las técnicas más importantes de extracción de información es la denominada data minning o minería de datos (en lo sucesivo DM). que se ejecutaría cada vez que se da de alta un nuevo domicilio. una empresa que dispone de cantidades ingentes de información (empleados. compras). lo cual desbarata prácticamente todo el proceso de normalización. que tendría el método alta(). que son una especie de vistas con la información que interesa obtener. cabe imaginar. En cambio. filtrado y proceso de los datos. podemos encontrar bases de datos espaciales (para manejo de información en tres dimensiones). Una vez que se tiene el DW. provincia y localidad. duplicidades e información irrelevante. Sin embargo. lo que más expectación esta suscitando actualmente. Por data warehousing se entiende el almacenamiento masivo de los datos que gestiona una empresa. une a éste la funcionalidad que ofrece la orientación a objetos. que no se encuentra de manera explícita. se pueden utilizar los denominados data marts. que debido al avance y mejora de los SGBD actuales. de una forma más eficaz y eficiente. Esta técnica es muy útil sobre todo en el ámbito del marketing y publicidad. se puede tener el atributo domicilio que se puede descomponer en calle. De esta forma se tienen relaciones en forma de tablas. es el data warehousing y el data mining. fueron muchos los que pensaron que no sería mala idea unir lo mejor de ambos modelos: el relacional y el orientado a objetos. Por ejemplo. y que se prevé tenga un mayor impacto si cabe. mediante herramientas específicas (OLAP. se pueden aplicar procesos que permitan una obtención de información añadida. no paran de surgir nuevos estudios y propuestas de modelos que amplían los ya existentes. bases de datos fuzzy (o que manejan información imprecisa. que aparece dispersa en el ámbito del negocio. Tomando como base el relacional. de tal manera que dicha información pueda ser utilizada más provechosamente. como puede imaginar el lector. entre otras. ventas. y así un sinfín de posibilidades. que no aparece de manera explícita en el mismo. para su mejor gestión. en estos modelos ni siquiera se cumple la 1FN. se necesitará un lenguaje especial para definir y manejar la información. Surge entonces el SQL:1999 como lenguaje estándar para el acceso y definición de este tipo de esquemas. permite una mejor gestión de los mismos. para obtener. etc.

hacen que todavía sea un mercado que no se encuentre al alcance de todo el mundo. ofreciéndonos diversas posibilidades de las ya mencionadas. Figura 97 205 . pero que se espera crezca positivamente en un futuro no muy lejano.© Grupo EIDOS 24. Sin embargo. pero que. debido a su elevado precio. como resume la Figura 97. Presente y futuro de las bases de datos Figura 96 Ya existen en el mercado varios productos que soportan tanto el DW como el DM. SQL Server 2000 ya nos permite adentrarnos es este mundo.

.

Power Designor permite al usuario establecer el diseño de un esquema relacional. Y no solo esto. Los tipos de archivos manejables por Power Designor son dos: . evitándole tareas engorrosas. El diseño físico El diseño conceptual permite establecer la definición de las tablas. las claves. Además nos permite pasar fácilmente del esquema conceptual. sino que también se ofrece la posibilidad de generar un script (trozo de código) que es capaz de crear el esquema físico para una plataforma y un SGBD concreto. etc.Diseño conceptual con Power Designor Introducción Empezaremos dando respuesta a la pregunta "¿qué es Power Designor?". se puede decir que Power Designor es una herramienta CASE para el diseño de bases de datos. mientras que el diseño físico comprende la definición de índices. Una herramienta CASE es aquella que permite al usuario la realización de unas determinadas tareas de forma fácil y precisa. de forma clara y sencilla. los atributos y sus tipos. y en general todos los aspectos relacionados con esta fase de diseño. El diseño conceptual 2. obtener el esquema conceptual de una base de datos. y realizar ingeniería inversa. como el paso del diseño conceptual al físico. las relaciones entre éstas y su cardinalidad. En nuestro caso.. al esquema físico. etc. es decir. la redundancia controlada de datos. con sólo conocer su esquema físico. Power Designor abarca dos de las tres grandes etapas del diseño de un esquema relacional: 1. Pues bien.

es decir. MetaWorks: útil para el trabajo en red de varios diseñadores. ejecutar el módulo DataArchitect. Extensión PDM: contiene la definición del esquema físico (Physical Data Model) Power Designor se compone de cuatro módulos: • • • • Data Architect: se encarga de la definición de los esquemas conceptual y físico. Creación de una entidad Para entrar en la aplicación. las 208 . acceder al menú File-New. Acto seguido nos sale una pantalla en blanco. Para ello tenemos dos formas: pulsar el botón de definición de entidades y hacer click izquierdo sobre la entidad.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS 1. La pantalla que nos aparece se muestra en la Figura 99. su nombre. es decir. etc. Comprende la etapa de diseño del ciclo de vida del software. claves de la entidad. Extensión CDM: contiene la definición del esquema conceptual (Conceptual Data Model) 2. Para crear un nuevo esquema conceptual. o hacer doble click sobre dicha entidad. y se deberá especificar si la entidad generará tabla en el esquema físico. su apariencia se muestra en la Figura 98. se deberán definir sus propiedades. atributos y tipos. AppModeler: para la modelación del esquema físico. ProcessAnalist: para realizar el diseño de procesos. Figura 98 Para crear una nueva entidad. Una vez que tengamos creada la entidad. se deberá pulsar el botón de creación de entidades. Es en el que nos centraremos. Pulsando el botón Rules se podrán definir las Bussiness Rules o Reglas de Negocio. y hacer click con el botón izquierdo del ratón en cualquier parte de la pantalla. En ella se deberá teclear el nombre que le demos a la entidad. es decir. diagramas de flujo de datos. Nos aparecerá una pantalla en blanco junto con una barra de herramientas. un código que representará de manera unívoca a la entidad.

para hacerlo. Figura 99 Las reglas de negocio pueden ser de los siguientes tipos: • • • Validación: Especifican las restricciones que puede tener un valor en el esquema. Ej: la suma total de los pedidos realizados por un cliente. especificar el nombre y el código de la regla... Ej: el crédito de un cliente no puede superar el 20% de su compra. Hecho: Describen los hechos o forma de funcionar de la empresa. bastará con pulsar el Botón Add..© Grupo EIDOS Apéndice A. En este apartado también se definen las reglas de integridad referencial. Si todavía no se ha introducido ninguna. Definición: Especifican características o propiedades de un objeto en el sistema de información. y el tipo de ésta. Fórmula: Definen los cálculos a realizar en el sistema de información. "Un cliente no puede pedir un crédito superior a 1. será preciso pulsar el botón List. Diseño conceptual con Power Designor restricciones que determinar el comportamiento de las entidades y/o sus relaciones. Ej: un cliente puede realizar uno o más pedidos. y nos aparecerá una lista con todas las reglas definidas. Si queremos introducir una nueva regla. en la 209 . • La pantalla para la asignación de reglas de negocio a una entidad aparece en la Figura 100 Para añadir una regla. La pantalla que nos permite definir las reglas de negocio es la que se muestra en la Figura 101. Pulsando el botón Define se visualizará la siguiente pantalla.000 euros" o "un proveedor sólo puede atender a un cliente" son ejemplos de reglas de negocio.. habrá que pulsar el botón New. Ej: un cliente es una persona identificada por su DNI y por su nombre.

210 . Además se puede especificar si la expresión a evaluar se desea ejecutar en el cliente o en el servidor.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS que podremos teclear la descripción de la regla o la formula aplicable. aunque la mayor desventaja es. la probabilidad de cargar al servidor con demasiado trabajo. Figura 100 Figura 101 La principal ventaja de ejecutar una expresión en el servidor radica en la velocidad de ejecución de la misma. sin duda. dependiendo del tipo de regla que hayamos escogido. lo que implica una ganancia de tiempo no tan drástica.

código y tipo de dato. en la que podremos incluir nuevos atributos para dicha entidad.. Diseño conceptual con Power Designor Figura 102 Volvemos a la pantalla de definición de entidades para determinar los atributos de la entidad. Pulsar el botón Add. cuyo aspecto se muestra en la siguiente figura. Se mostrará entonces una nueva ventana.© Grupo EIDOS Apéndice A. para lo cual pulsamos el botón Atributtes. Pulsar el botón New e introducir el nombre. lo cual permitirá seleccionar un atributo de entre los ya existentes en el sistema de información. Figura 103 211 . Para ello se dispone de dos opciones: 1.. o 2.

La segunda es el tipo de atributo. es decir. En la carpeta de Validation Rules (Figura 106).. pulsando el botón . o como obligatorio (mandatory) en cuyo caso dicho campo deberá tener siempre un valor no nulo. Power Designor nos permite escoger entre una amplia gama de tipos de datos. simplemente es un valor que no tiene valor (valga la redundancia). e introducir otro tipo de restricciones como son el caso de las mayúsculas o minúsculas en los caracteres. entidades y otros. Dentro de esta pantalla también se puede especificar el dominio de un atributo. En nuestro caso se ha optado por la expresión ofrecida por defecto.999.000. Ésta tiene un aspecto muy parecido al de todas las pantallas de definición vistas hasta ahora.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS De esta pantalla cabe destacar dos cosas. es decir. es donde se permite la definición de restricciones mas especificas. La utilidad de ambos es la de disponer de un editor que permite la introducción de textos explicatorios y/o aclaratorios. como la Figura 105. Se ha visto hasta ahora que en la mayoría de las pantallas aparecen dos botones (o carpetas) con los nombres Description y Annotation. dejando al usuario la posibilidad de especificar su longitud y precisión. 212 . en las definiciones de atributos. En este caso se ha introducido un dominio para los números telefónicos. Recuérdese que un valor nulo no es ni el cero ni el espacio en blanco. también se puede introducir directamente la lista de valores que puede tomar. En la lista desplegable etiquetada como Domain se puede seleccionar el dominio que se va asignar a ese atributo. el rango de valores que puede tomar.000 (para los móviles) y 999.. La definición en si del dominio se establece al pulsar el botón Check en el que se mostrará una nueva pantalla. Una es la posibilidad de determinar un atributo como identificador (identifier).. o no permitir la modificación del atributo. Dichos atributos serán traducidos a los tipos específicos del SGBD con el que se vaya a trabajar (recordar que en la definición del esquema conceptual no se tiene por qué saber la implementación física que se va a realizar). ese atributo será clave para dicha entidad. código y tipo de dato de éste. En la carpeta de Standard Parameters es donde se especificará el rango que tomará el atributo. En el caso de que no tengamos definido ningún dominio todavía.999 (para los fijos). que variará entre 600. introduciéndolos en la lista de la derecha. Figura 104 Para incluir un nuevo dominio. que permite establecer las principales características del dominio. se deberá pulsar el botón New e introducir el nombre. se podrá acceder a la pantalla que permite hacerlo.

© Grupo EIDOS Apéndice A. Acto seguido haremos click derecho con el ratón en la entidad origen y. Para crear una relación entre dos entidades pulsaremos el botón de relación entre entidades de la paleta de herramientas. Diseño conceptual con Power Designor Figura 105 Figura 106 Creación de relaciones Se hablará en este apartado de las relaciones entendidas como la "unión" o relación entre dos entidades. 213 .

bajo 214 . un cliente sólo puede abastecerse de un proveedor. mientras que si se selecciona la opción Many. se dispone de otros botones de selección. La Figura 107 muestra la relación existente entre las entidades cliente y proveedor. Nuevamente. lo moveremos hasta la entidad destino. lo que implica cardinalidad mínima y máxima uno. Figura 107 Una vez definida la relación. podemos decir que un proveedor puede distribuir a uno o más clientes. Para establecer la cardinalidad máxima. estamos diciendo que la cardinalidad máxima será uno. cada ocurrencia de la entidad proveedor puede relacionarse con una (cardinalidad mínima) o varias (cardinalidad máxima) ocurrencias de la entidad cliente.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS sin soltarlo. Por ejemplo. Es decir. Para determinar la cardinalidad mínima. para obtener el cuadro de diálogo de definición de propiedades. obteniendo algo parecido a la Figura 108. se estará indicando que la cardinalidad máxima es muchos (o N). En el sentido contrario. el siguiente paso es establecer la cardinalidad de la misma. Figura 108 Es aquí donde se deberá establecer la cardinalidad máxima y mínima de la relación en ambos sentidos. Si escogemos la opción One. se dispone de unos botones de selección. bajo el nombre de Cardinality. haremos doble click sobre la relación.

la entidad motocicleta con los atributos marca. se deberá escoger en la paleta el botón relación de herencia. De esta forma se tendrá una relación vehículo con los atributos marca. El ejemplo se representa como indica la Figura 109. Un tipo especial de relación es la relación de dependencia. Por ejemplo. Ni que decir tiene. precio y cilindrada y la entidad bicicleta con los atributos marca. marca. podemos tener tres entidades: automóvil con los atributos marca. y a continuación pinchar en las demás relaciones llevándolas hasta el punto de unión. en el cual podremos establecer las reglas de negocio. una relación de este tipo indica que depende de otra relación para su identificación. quiere decir que la cardinalidad mínima es cero. que estas relaciones. suponiendo que estas son características básicas de cualquier vehículo. modelo. de las que heredarán las entidades automóvil con atributo num_puertas. modelo. precio y num_cambios. Como ya se estudio en anteriores temas. pinchar en la relación padre. precio y num_puertas. modelo y precio. Pero si nos damos cuenta. mientras que si se escoge la opción Mandatory se obliga a que la cardinalidad mínima será uno. Para indicar una relación de este tipo. con los detalles de cada pedido. ya que no se sabrá a que línea de pedido nos estamos refiriendo. Diseño conceptual con Power Designor el nombre Existence. con atributos privados o específicos a cada una. La relación de herencia Otro tipo especial de relación es la relación de herencia. Si por ejemplo se tiene la entidad pedido con los pedidos realizados por un cliente. Nuevamente nos encontramos en esta ventana con el botón Rules. heredan o importan los atributos de la entidad padre. Figura 109 Para establecer una relación de herencia. seleccionar una relación. modelo y precio. 215 . modelo. y la entidad linea_pedido. Si indicamos la opción Optional. bastará con seleccionar la caja de selección denominada Is dependent. esta última entidad tiene una relación de dependencia con aquella. Consiste en la propiedad que tienen algunas entidades de heredar el comportamiento de otras. además de disponer de otras dos carpetas para introducir cualquier descripción que se nos ocurra. Podemos aprovechar esta ventaja para definir una relación de herencia. sin saber a que pedido corresponde. motocicleta con atributo cilindrada y bicicleta con atributo num_cambios.© Grupo EIDOS Apéndice A. las tres relaciones tienen tres atributos en común.

.

permite especificar el nombre de los índices primarios y ajenos (campos que son clave en otras entidades) que se generarán para cada tabla. con extensión . En la parte superior se especifica el SGBD específico sobre el cual se generará el esquema físico. si algo ha . será preciso generar el esquema físico y cambiarlo según nuestras pretensiones y/o necesidades. También se puede decir si las reglas de actualización o de borrado se propagarán a todas las tablas o sólo a la que afecte. los tipos de datos del mismo. o las reglas de negocio. sino que ésta está divida entre las fases de diseño conceptual y diseño físico. Justo debajo se nos preguntará por el nombre del fichero en el que se guardará el modelo físico. etc. como por ejemplo los gráficos. Por ejemplo. el siguiente paso es obtener el esquema físico. etc.Generate Physical Model o pulsar las teclas Ctrl-G. para determinar las restricciones del SGBD. si queremos realizar un particionamiento vertical. sobre todo.Diseño físico con Power Designor Paso del esquema conceptual al esquema físico Una vez realizado el diseño del esquema conceptual. En la segunda carpeta se nos da la opción de preservar ciertos cambios. Cabe destacar que Power Designor no da la posibilidad de realizar la fase intermedia de diseño lógico. Una vez que estemos seguros de haber dado las opciones correctas. Automáticamente aparece una pantalla. Para generar el esquema físico a partir del conceptual. pulsaremos el botón OK y.PDM. Por ejemplo. las etiquetas. se puede seleccionar la opción de menú Dictionary . como la mostrada en la Figura 110. tras un breve período de tiempo nos aparecerá un mensaje con el resultado de la generación. En la carpeta Generation se nos sigue preguntando una serie de parámetros. Esto es importante.

se deberá revisar nuevamente el esquema conceptual.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS fallado. en otro caso tendremos el correspondiente esquema físico. Figura 110 Modificación de las tablas Figura 111 218 .

del número de actualizaciones. ante el cual aparece la Figura 112.. es decir. Otra funcionalidad que ofrece Power Designor es la definición de atributos extendidos. La forma de hacerlo es similar a la pantalla mostrada en el anterior tema acerca de la definición de atributos. para lo que será necesario hacer doble click sobre una de ellas. que permite la determinación de ciertas características correspondientes a los atributos de una tabla. De esta manera será preciso realizar un estudio detallado de las consultas que se realizarán a la base de datos. En ella podemos especificar varias características. cuyo cometido es el aumento de eficiencia a la hora de realizar las consultas. Columnas La edición de columnas consiste en borrar.© Grupo EIDOS Apéndice B. cabeceras. y las restricciones del SGBD. teniendo en cuentas las necesidades del sistema. comentarios que se mostrarán a la hora de visualizarlos. A esta funcionalidad se accede pulsando el botón Extended. etc. sin 219 . Podemos empezar modificando las características de las tablas. Diseño físico con Power Designor Una vez generado el esquema físico. etiquetas.). etc. salvo que en esta se puede determinar un atributo como clave ajena (atributo que es clave en otra tabla). editor. Recuérdese. apareciéndonos la Figura 111. conseguir una mayor eficiencia. En este caso ya podemos hablar de tablas. insertar y/o cambiar la definición uno o más atributos de las tablas. que estudiaremos a continuación en detalle. de la concreción física de las entidades diseñadas en el esquema conceptual. podremos adecuarlo a nuestro gusto. de la velocidad del hardware. el valor inicial o por defecto del mismo. para de esta forma. etc. Figura 112 Indices La definición de los índices de una tabla es otra de las características del diseño físico ya estudiadas. como pueden ser la forma de visualización (lista desplegable.

pulsaremos el botón New.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS embargo. Este es otro tipo de claves. se deberá pulsar el botón Indexes. es decir. Unique: índice único. En el botón Alternate Keys se pueden especificar claves alternativas o secundarias. a la hora de realizar actualizaciones. Dicha pantalla tiene la apariencia de la Figura 113. usado para recorrer los cluster de una base de datos (se remite al lector al capítulo de diseño físico). Foreign key: es el índice que hace referencia a campos de la tabla. se pulsará el botón Add y se seleccionarán los atributos que se desean añadir. Es el índice que se seguirá por defecto. Para añadir campos a un índice. Para acceder a la pantalla de definición de índices. que sirven para identificar una ocurrencia de una entidad en la base de datos. además de las primarias. 220 . teclearemos su nombre. es preciso realizar un estudio detallado de las transacciones que se darán en la base de datos. y define los atributos que son clave en la tabla. Además se puede especificar la ordenación del índice. Cluster: índice cluster. sus campos no pueden tener valores duplicados. Figura 113 Para definir un nuevo índice. que puede ser ascendente o descendente. Por lo tanto. la desventaja que supone el tener una tabla de índices demasiado extensa. de entre los siguientes: • • • • Primary key: índice por clave primaria. que son clave en otra tabla. y especificaremos su tipo.

ni valores iniciales. estilo. Sin embargo. 221 . pero cuya finalidad es la misma: modificar el aspecto de visualización de estos atributos. ni nada por el estilo. La Figura 115 muestra un ejemplo de definición de trigger. Diseño físico con Power Designor Atributos extendidos Como ya se ha visto. tamaño.© Grupo EIDOS Apéndice B. pulsando el botón Extended. se pueden determinar las acciones que tendrán lugar cuando ocurra un determinado evento. los triggers son disparadores. accesible mediante el botón Triggers. totalmente distinta a la mostrada anteriormente. Este código es dependiente del SGBD. trozos de código que se ejecutan cuando ocurre un determinado evento. como por ejemplo. al insertar una tupla en la base de datos. permite la modificación de ciertas características de éstos. pero nos permite establecer las fuentes (tipo de letra.) con las cuales se mostrarán las tablas. Triggers Como su propio nombre indica. la funcionalidad que ofrece Power Designor sobre atributos extendidos. etc. y cuyo aspecto es el mostrado en la Figura 114. Figura 114 Como se puede observar. nos podemos encontrar con otra pantalla. es decir. y define la acción que tendrá lugar ante ciertos eventos. En esta funcionalidad. en ella no se pueden definir formas de visualización de los atributos.

En ella podemos definir las tablas que implica. pulsando el botón con dicho nombre. Además se puede dar la opción de modificar el contenido de las tablas (opción Updatable) o simplemente consultar (opción Query Only). que afecten a un determinado número de tablas. y a continuación pincharemos en Para definir una vista en Power Designor. pulsando el botón Query. Si no queremos que un usuario acceda a una determinada tabla. se definirán consultas. y todas las reglas que debe verificar una tabla. Una vista permite la introducción de un nivel de seguridad. y nos aparecerá una pantalla como la que aparece en la Figura 116. pulsaremos el botón cualquier punto de la pantalla. ya que ya se ha estudiado en el capítulo sobre diseño conceptual. simplemente se le ofrecerán vistas que no impliquen dicha tabla. se agrupa todo un conjunto de funciones que define el rango de valores que puede tomar un determinado atributo.Bases de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Figura 115 Restricciones Bajo el nombre restricción. La query se podrá definir mediante el lenguaje SQL. Es decir. pulsando el botón Tables. y la query o consulta. y cuyo conjunto correspondía a la definición del nivel externo de la base de datos. No se ahondará más en este tema. bastará con hacer doble click sobre ella. y cuyo comportamiento es similar en el diseño físico. 222 . Creación de vistas Se entiende por vista. Recuérdese la definición de vista recogida en el capítulo de introducción. una porción de la base de datos. y cada una de ellas podrá ser accedida por uno o varios usuarios. accesible por un usuario. Para editarla.

© Grupo EIDOS Apéndice B. Diseño físico con Power Designor Figura 116 223 .

.

A su vez. Para ello abrimos la utilidad DataArchitect de S-Designar. descripción y existencias. cada vez que las existencias son inferiores a las 10 unidades de cada producto.Ejemplo de diseño con Power Designor Para irnos familiarizándonos con el uso de S-Designar. nombre. Cliente: de que se desea conocer su código de cliente. Para ello desea tener almacenados todos los pedidos. vamos a tratar de resolver un planteamiento utilizando esta herramienta. para realizar pedidos de forma automática. apellidos. ciudad y provincia. dirección. de cara al euro y al año 2000. NIF. y creamos un nuevo modelo conceptual (. Además desea conocer en todo momento la disponibilidad de productos en el almacén.CDM). . quiere informatizar su sistema. ciudad. El funcionamiento de Enterprise SL es el siguiente. desea simplificar el tema de la facturación. A continuación empezamos a definir entidades: • • • • Proveedor: nos interesa saber su código de proveedor. CIF. Pedido: código de pedido. Para ello nos ha encargado que diseñemos una base de datos que permita la introducción y recuperación eficiente de datos. de cara a Hacienda. dirección. Por otra parte. nombre. Existen una serie de proveedores que abastecen a dicha empresa. Enterprise SL es una empresa de venta al público. provincia y teléfono. Enterprise SL desea tener almacenados los datos de todos sus clientes. Lo primero realizar es un diseño del esquema conceptual. Producto: código de producto.

Ya tenemos creadas las seis entidades. Cruz Trfe.Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • • Linea_pedido: código de la línea de pedido y cantidad. Empezaremos por la entidad proveedor. El siguiente paso es definir los atributos de cada una de ellas. Empezamos creando las entidades. 226 .).. y acto seguido pulsamos el botón Attributes. A10). Así procederemos con el resto de atributos. Para crear un nuevo atributo pulsamos el botón New y le damos un nombre (CIF). o hacer click con el botón derecho del ratón. Para quitar la selección se puede pulsar el botón flecha en la paleta. Factura: IVA e importe en pesetas y euros. o 2. Sta. Ciudad: código de ciudad y descripción. por lo que tacharemos la caja de selección correspondiente a Identifier de dicho atributo. un código (que será también CIF) y un tipo de dato (tipo carácter de longitud 10. La definición completa es la mostrada en la Figura 117 Ahora se nos plantean dos opciones: 1. Para ello hacemos doble click sobre cualquiera de las entidades y. Dejar que el usuario introduzca la ciudad y la provincia como texto libre. Pulsamos el botón entidad en la paleta de componentes y acto seguido pulsamos seis veces en cualquier punto de la pantalla.: Sta. Etc. Santa Cruz de Tenerife. en la ventana que nos aparece teclearemos el nombre de la entidad (Proveedor). Cruz Tenerife. Tipificar las ciudades y provincias. ya que evitará el tener diferentes definiciones para una misma ciudad (Ej. Esto implica la creación de otras dos nuevas entidades: • • Provincia: código de provincia y descripción. Nos decantaremos por esta última opción. teniendo en cuenta que la clave de dicha entidad será el atributo cod_proveedor.

siguiendo el mismo proceso indicado anteriormente. Ejemplo de diseño con Power Designor Por lo tanto creamos dos entidades más. El atributo desc_provincia será un texto de 20 caracteres.© Grupo EIDOS Apéndice C. La definición de la entidad ciudad queda como indica la Figura 119. En la Figura 118 mostraremos como quedaría la pantalla de definición de la entidad provincia. y será de tipo numérico de dos dígitos. Figura 118 El atributo cod_provincia será la clave de la entidad. Figura 119 227 .

Figura 120 Lo único a destacar aquí es la clave de la entidad. Figura 121 Hacemos lo mismo con la entidad linea_pedido. que es el atributo cod_cliente. y los atributos obligatorios que son Nombre y Apellidos. En la Figura 121 definimos los atributos de la entidad Pedido.Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Seguimos definiendo entidades. y pasamos a ahora a hacerlo con cliente. 228 .

pulsamos el 229 . máxime cuando se sabe el cambio de pesetas a euros. con lo que ya tenemos una regla de negocio para la entidad factura.386. Lo único que se deberá realizar para calcularlo será dividir el importe en pesetas por 166. ya que ello supone un desperdicio de memoria. como se observa en la Figura 124 En esta última definición.© Grupo EIDOS Apéndice C. Ejemplo de diseño con Power Designor Figura 122 También definimos la entidad producto. cabe destacar que se ha optado por no almacenar el importe en euros en un nuevo campo. Para crearla. Figura 123 Y concluimos definiendo la entidad factura.

sólo nos queda añadirla a la entidad. y en la pantalla que nos aparece pulsamos List. Figura 124 Figura 125 Una vez definida. Para definirla. Le damos el nombre Pesetas_a_euros. pulsamos el botón Define y tecleamos lo que muestra la Figura 125. para lo que pulsaremos el botón Add en la pantalla y escogeremos dicha regla. 230 .Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS botón Rules. y decimos que es de tipo Formula.

y a continuación uniremos ambas entidades. obtenemos la pantalla de definición. que debe quedar como la Figura 127. pulsaremos el botón de relación en la paleta de componentes. La cardinalidad máxima es N y la mínima es 1. y un producto puede ser abastecido por varios proveedores: relación N-M. el siguiente paso es crear las relaciones entre ellas. Ejemplo de diseño con Power Designor Figura 126 Una vez definidas todas las entidades. Figura 127 231 . Podemos observar varias relaciones entre pares de entidades: • Un proveedor puede abastecer a la empresa de varios productos.© Grupo EIDOS Apéndice C. Para crear una relación entre ambas entidades. Haciendo doble click sobre la relación creada.

no se puede identificar una línea de pedido. si no se sabe el pedido al que corresponde. Figura 129 232 . es decir. Esto implica una relación 1-N. Además. la relación en el sentido de linea_pedido es dependiente. pero un pedido sólo puede ser realizado por un cliente. y la ventana queda como la Figura 128. Figura 128 • Un pedido puede tener muchas líneas de pedido.Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • Un cliente puede realizar muchos pedidos. pero una línea de pedido sólo puede corresponder a un pedido.

mientras que un producto puede estar en varias líneas de pedido. sin embargo una factura sólo puede corresponder a un cliente. Figura 131 233 .© Grupo EIDOS Apéndice C. Ejemplo de diseño con Power Designor • En una línea de pedido sólo puede haber un producto. Figura 130 • Un cliente puede tener varias facturas.

Figura 133 234 . pero como mínimo una. y una ciudad sólo puede pertenecer a una provincia. pero un proveedor sólo puede pertenecer a una ciudad. ya que no nos interesa tener almacenadas las ciudades sin proveedores. Figura 132 • Una ciudad puede tener varios proveedores.Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS • Una provincia puede tener muchas ciudades. La cardinalidad mínima es uno.

que queda como muestra la Figura 135. Obsérvese. podemos saber su provincia. ya tenemos el esquema conceptual. pero un cliente sólo puede pertenecer a una ciudad. ya que sabiendo la ciudad a la que pertenece el cliente. Ejemplo de diseño con Power Designor • Una ciudad puede tener varios clientes.© Grupo EIDOS Apéndice C. en la Figura 134 como no se ha incluido una relación entre provincia y cliente. Figura 135 235 . Figura 134 Pues bien.

y que almacena los productos que han sido abastecidos por cada proveedor. el siguiente paso es obtener el esquema físico. Para ello pulsamos Ctrl-G y escogemos un SGBD.Base de datos con SQL Server 2000 – Transact SQL © Grupo EIDOS Una vez obtenido el esquema conceptual. denominada RELATION_63. por ejemplo Microsoft Access 95. Figura 137 236 . Las flechas representan las operaciones de join que hay que realizar para obtener la información de una tabla. fruto de la relación N-M entre las entidades producto y proveedor. Figura 136 En él podemos observar como se ha añadido una nueva relación. El esquema físico queda como aparece la Figura 136. Pulsamos Ok.

Para definirla. ya que no queda muy estético. y añadiremos un nuevo atributo. pulsamos el botón Columns. Le daremos el nombre de Proveedor-Producto. Figura 138 No se preocupe demasiado si no entiende la anterior consulta. que será la fecha en la que se ha realizado la venta. Para ello hacemos doble click en dicha entidad. y tecleamos el nuevo atributo. lo que hace es recuperar todos los productos cuyo stock es menor de 10 unidades. 237 . compruebe el stock que queda. Crearemos ahora una vista. Ejemplo de diseño con Power Designor Lo primero que realizaremos será cambiar el nombre de la relación RELATION_63. ya que en la siguiente parte se estudiará a fondo la sintaxis de lenguaje SQL. y pinchamos en cualquier punto de la pantalla. Para ello pulsamos el botón vista en la paleta de componentes. para que la secretaria encargada de realizar los pedidos. Básicamente. hacemos doble click sobre ella. y establecemos una consulta SQL.© Grupo EIDOS Apéndice C. pulsamos el botón New.

.

tutorías.almagesto.com. con un profesor a su disposición. Este libro tiene soporte de formación virtual a través de Internet. Si quiere hacer algún comentario.Si quiere ver más textos en este formato.es . Si quiere información más precisa de las nuevas técnicas de programación puede suscribirse gratuitamente a nuestra revista Algoritmo en: http://www.eidos. envíelo a la dirección de correo electrónico lalibreriadigital@eidos. No deje de visitar nuestra reviata Alquimia en http://www.com.com. Si desea inscribirse en alguno de nuestros cursos o más información visite nuestro campus virtual en: http://www. © Grupo EIDOS http://www.es.eidos. exámenes y un completo plan formativo con otros textos. o tiene cualquier tipo de problema.algoritmodigital.es/alquimia donde podrá encontrar artículos sobre tecnologías de la sociedad del conocimiento.lalibreriadigital. sugerencia. visítenos en: http://www.

Sign up to vote on this title
UsefulNot useful