Manuals Ql

El texto est diseado para programadores, analistas o tcnicos de sistemas que deseen conocer la mecnica de trabajo de las bases de datos a travs del uso de una de ellas en concreto: Microsoft SQL Server 2000. Aspectos que se revisan: 1- Conceptos tericos sobre Bases de Datos. 2- Diseo y modelizacin de datos tomando como base el modelo Entidad/Relacin 3- Generalidades de SQL Server 2000 4- Lenguaje SQL a travs de la implementacin del mismo en SQL Server 2000 (Transact SQL) 5- Ejemplos de diseo utilizando una herramienta CASE: Power Designor Se requiere como mnimo tener conocimientos del sistema operativo Windows a nivel de usuario. No es imprescindible, aunque si recomendable, conocer fundamentos de programacin.

BBAASSEESS DDEE DDAATTOOSS CCOONN SSQQLL SSEERRVVEERR 22000000.. TTRRAANNSSAACCTT SSQQLL

JJOORRGGEE MMOORRAATTAALLLLAA

Desarrollo de software

ADVERTENCIA LEGAL

Todos los derechos de esta obra estn reservados a Grupo EIDOS Consultora y Documentacin Informtica, S.L.

El editor prohbe cualquier tipo de fijacin, reproduccin, transformacin, distribucin, ya sea mediante venta y/o alquiler y/o prstamo y/o cualquier otra forma de cesin de uso, y/o comunicacin pblica de la misma, total o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio mecnico o electrnico, incluido el tratamiento informtico de la misma, en cualquier lugar del universo.

El almacenamiento o archivo de esta obra en un ordenador diferente al inicial est expresamente prohibido, as como cualquier otra forma de descarga (downloading), transmisin o puesta a disposicin (an en sistema streaming).

La vulneracin de cualesquiera de estos derechos podr ser considerada como una actividad penal tipificada en los artculos 270 y siguientes del Cdigo Penal.

La proteccin de esta obra se extiende al universo, de acuerdo con las leyes y convenios internacionales.

Esta obra est destinada exclusivamente para el uso particular del usuario, quedando expresamente prohibido su uso profesional en empresas, centros docentes o cualquier otro, incluyendo a sus empleados de cualquier tipo, colaboradores y/o alumnos.

Si Vd. desea autorizacin para el uso profesional, puede obtenerla enviando un e-mail [email protected] o al fax (34)-91-5017824.

Si piensa o tiene alguna duda sobre la legalidad de la autorizacin de la obra, o que la misma ha llegado hasta Vd. vulnerando lo anterior, le agradeceremos que nos lo comunique al e-mail [email protected] o al fax (34)-91-5012824). Esta comunicacin ser absolutamente confidencial.

Colabore contra el fraude. Si usted piensa que esta obra le ha sido de utilidad, pero no se han abonado los derechos correspondientes, no podremos hacer ms obras como sta.

Jorge Moratalla, 2001 Grupo EIDOS Consultara y Documentacin Informtica, S.L., 2000

ISBN 84-88457-24-3

Bases de datos con SQL Server 2000. Transact SQL Jorge Moratalla

Responsable editorial Paco Marn ([email protected]) Autoedicin Magdalena Marn ([email protected]) Jorge Moratalla ([email protected])

Coordinacin de la edicin Antonio Quirs ([email protected])

Grupo EIDOS C/ Tllez 30 Oficina 2 28007-Madrid (Espaa) Tel: 91 5013234 Fax: 91 (34) 5017824 www.grupoeidos.com/www.eidos.es www.LaLibreriaDigital.com

ndice

NDICE................................................................................................................................................... 5 INTRODUCCIN ................................................................................................................................. 9

DEFINICIN DE BASE DE DATOS........................................................................................................... 9 CONCEPTOS BSICOS ......................................................................................................................... 10 DEL ENFOQUE TRADICIONAL A LOS SISTEMAS DE BASES DE DATOS ................................................. 10 ARQUITECTURA ANSI/X3/SPARC ................................................................................................... 12 EL MODELO RELACIONAL .................................................................................................................. 12

VISIN GENERAL SOBRE EL DISEO DE BASES DE DATOS.............................................. 15 FASES DEL DISEO ............................................................................................................................. 15 DISEO CONCEPTUAL ........................................................................................................................ 17 DISEO LGICO.................................................................................................................................. 17 DISEO FSICO.................................................................................................................................... 21

DISEO CONCEPTUAL................................................................................................................... 23 INTRODUCCIN .................................................................................................................................. 23 ETAPAS DEL DISEO CONCEPTUAL .................................................................................................... 24 EL MODELO ENTIDAD / RELACIN ..................................................................................................... 24 EJEMPLOS PRCTICOS DE DISEO CONCEPTUAL................................................................................ 29

DISEO LGICO............................................................................................................................... 35 INTRODUCCIN .................................................................................................................................. 35 PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA LGICO ESTNDAR ............................................... 36 ETAPAS EN EL DISEO LGICO........................................................................................................... 37 PARTICIONAMIENTO HORIZONTAL DE RELACIONES .......................................................................... 38

PARTICIONAMIENTO VERTICAL DE RELACIONES ............................................................................... 41 PARTICIONAMIENTO MIXTO............................................................................................................... 44 TEORA DE LA NORMALIZACIN ........................................................................................................ 45 EJEMPLOS PRCTICOS DE NORMALIZACIN ...................................................................................... 49 PROCESO DE DESNORMALIZACIN .................................................................................................... 55

DISEO FSICO ................................................................................................................................. 57 INTRODUCCIN .................................................................................................................................. 57 ESTRATEGIAS EN EL DISEO FSICO................................................................................................... 58 CONCEPTOS BSICOS SOBRE GESTIN DE FICHEROS ......................................................................... 58 ORGANIZACIN DE FICHEROS............................................................................................................ 59 TCNICAS PARA EL AUMENTO DE EFICIENCIA ................................................................................... 59

INTRODUCCIN A SQL SERVER ................................................................................................. 63 QU ES SQL SERVER?...................................................................................................................... 63 ORGENES........................................................................................................................................... 64 SQL SERVER E INTERNET.................................................................................................................. 64

LO NUEVO EN SQL-SERVER 2000 ................................................................................................ 65 INTRODUCCIN .................................................................................................................................. 65 NUEVAS CARACTERSTICAS............................................................................................................... 65 SOPORTE PARA XML ......................................................................................................................... 66 PARTICIONAMIENTO HORIZONTAL DE RELACIONES Y GESTIN DE VISTAS DISTRIBUIDAS ............... 67 SOPORTE PARA VIRTUAL INTERFACE ARCHITECTURE (VIA) ........................................................... 67 FUNCIONES DE USUARIO .................................................................................................................... 67 INDEXACIN DE VISTAS ..................................................................................................................... 67 NUEVOS TIPOS DE DATOS................................................................................................................... 67 NUEVOS TRIGGERS............................................................................................................................. 68 REGLAS DE INTEGRIDAD REFERENCIAL EN CASCADA ....................................................................... 68 NUEVAS CARACTERSTICAS DE INDEXACIN .................................................................................... 68 SOPORTE PARA CONSULTAS DISTRIBUIDAS ....................................................................................... 68 CARACTERSTICAS DE SEGURIDAD Y CIFRADO DE DATOS ................................................................. 68

INSTALACIN DE SQL SERVER 2000 ......................................................................................... 69 EL MODELO E/R EN SQL-SERVER 2000 ..................................................................................... 75

INTRODUCCIN .................................................................................................................................. 75 CREAR UN NUEVO DIAGRAMA ........................................................................................................... 77 RESTRICCIONES E INTEGRIDAD REFERENCIAL................................................................................... 79 MODIFICACIN DEL ESQUEMA........................................................................................................... 81 CREAR UNA NUEVA RELACIN .......................................................................................................... 82

EL ANALIZADOR DE CONSULTAS.............................................................................................. 85 INTRODUCCIN .................................................................................................................................. 85 LAS OPCIONES DE MEN .................................................................................................................... 85 LA BARRA DE HERRAMIENTAS........................................................................................................... 91 EJECUTANDO UNA CONSULTA ........................................................................................................... 92

EL LENGUAJE DE DEFINICIN DE DATOS (DDL).................................................................. 97 INTRODUCCIN .................................................................................................................................. 97 TIPOS DE DATOS................................................................................................................................. 97 CREACIN DE TABLAS ....................................................................................................................... 99 MODIFICACIN DE TABLAS.............................................................................................................. 100 BORRADO DE TABLAS ...................................................................................................................... 101 CREACIN Y BORRADO DE NDICES ................................................................................................. 101

7

EJEMPLOS PRCTICOS DE USO DEL DDL............................................................................. 103 INTRODUCCIN ................................................................................................................................ 103 LA SENTENCIA CREATE TABLE ................................................................................................... 103 LA SENTENCIA ALTER TABLE...................................................................................................... 107 LA SENTENCIA DROP TABLE ........................................................................................................ 111 LA SENTENCIA CREATE INDEX.................................................................................................... 112 LA SENTENCIA DROP INDEX......................................................................................................... 112

EL LENGUAJE DE MANIPULACIN DE DATOS (DML) ....................................................... 115 INTRODUCCIN ................................................................................................................................ 115 LA SENTENCIA SELECT .................................................................................................................... 115 LA CLUSULA WHERE ..................................................................................................................... 117 LA CLUSULA GROUP BY ................................................................................................................ 118 LA CLUSULA HAVING.................................................................................................................... 119 LA CLUSULA ORDER BY ................................................................................................................ 119 FUNCIONES ESCALARES PARA SELECT ............................................................................................ 119 LA SENTENCIA INSERT ..................................................................................................................... 122 LA SENTENCIA UPDATE ................................................................................................................... 123 LA SENTENCIA DELETE.................................................................................................................... 123

OPERADORES BSICOS Y CONSIDERACIONES DEL LENGUAJE ................................... 125 INTRODUCCIN ................................................................................................................................ 125 OPERADOR PROYECCIN ................................................................................................................. 125 OPERADOR UNION ........................................................................................................................... 127 OPERADOR JOIN ............................................................................................................................... 128 OPERADORES PROPIOS DE TRANSACT SQL ..................................................................................... 132 VARIABLES GLOBALES..................................................................................................................... 135 SENTENCIAS CONDICIONALES.......................................................................................................... 137 SENTENCIAS ITERATIVAS................................................................................................................. 138

LA SENTENCIA INSERT................................................................................................................ 139 INTRODUCCIN ................................................................................................................................ 139 SINTAXIS.......................................................................................................................................... 139 EJEMPLOS......................................................................................................................................... 140 CARGA DE LA BASE DE DATOS DE EJEMPLO..................................................................................... 143

LA SENTENCIA SELECT............................................................................................................... 147 INTRODUCCIN ................................................................................................................................ 147 LA CLASULA WHERE ................................................................................................................... 148 EL OPERADOR JOIN .......................................................................................................................... 149 LAS FUNCIONES DE AGREGADO ....................................................................................................... 151 LA CLASULA GROUP BY ............................................................................................................. 154

LA SENTENCIA UPDATE.............................................................................................................. 157 INTRODUCCIN ................................................................................................................................ 157 EJEMPLOS......................................................................................................................................... 157

LA SENTENCIA DELETE .............................................................................................................. 163 INTRODUCCIN ................................................................................................................................ 163 LA INTEGRIDAD REFERENCIAL......................................................................................................... 164 LA SENTENCIA TRUNCATE TABLE.............................................................................................. 165 EJEMPLOS......................................................................................................................................... 166

PROCEDIMIENTOS ALMACENADOS Y TRIGGERS ............................................................. 169 INTRODUCCIN ................................................................................................................................ 169

PARMETROS POR REFERENCIA....................................................................................................... 170 PROCEDIMIENTOS ALMACENADOS DE SISTEMA............................................................................... 172 EXTENDED STORED PROCEDURES.................................................................................................... 173 TRIGGERS......................................................................................................................................... 174

EJEMPLOS PRCTICOS DE USO DE PROCEDIMIENTOS ALMACENADOS .................. 177 INTRODUCCIN ................................................................................................................................ 177 LA SENTENCIA IF ... ELSE............................................................................................................... 177 LA SENTENCIA CASE ...................................................................................................................... 179 EJECUCIN DINMICA DE SENTENCIAS: LA INSTRUCCIN EXEC ................................................... 180 CONVERSIN DE TIPOS..................................................................................................................... 181 LA SENTENCIA WHILE.................................................................................................................... 182

TRIGGERS EN SQL-SERVER 2000 .............................................................................................. 183 INTRODUCCIN ................................................................................................................................ 183 LAS TABLAS DELETED E INSERTED .................................................................................................. 184 TIPOS DE DESENCADENADORES....................................................................................................... 184 LIMITACIONES DE LOS TRIGGERS..................................................................................................... 184 RESOLUCIN DIFERIDA DE NOMBRES .............................................................................................. 185 EJEMPLOS......................................................................................................................................... 185

SEGURIDAD ..................................................................................................................................... 189 INTRODUCCIN ................................................................................................................................ 189 CONCESIN DE PRIVILEGIOS............................................................................................................ 189 REVOCACIN DE PRIVILEGIOS ......................................................................................................... 191 DENEGACIN DE PERMISOS ............................................................................................................. 193 MANTENIMIENTO DE VISTAS ........................................................................................................... 193 RECOMENDACIONES ........................................................................................................................ 194

EJEMPLO PRCTICO DE IMPLEMENTACIN...................................................................... 195 INTRODUCCIN ................................................................................................................................ 195 LENGUAJE DE DEFINICIN DE DATOS............................................................................................... 196 LENGUAJE DE MANIPULACIN DE DATOS ........................................................................................ 198

PRESENTE Y FUTURO DE LAS BASES DE DATOS ................................................................ 203 DISEO CONCEPTUAL CON POWER DESIGNOR................................................................. 207

INTRODUCCIN ................................................................................................................................ 207 CREACIN DE UNA ENTIDAD............................................................................................................ 208 CREACIN DE RELACIONES.............................................................................................................. 213 LA RELACIN DE HERENCIA............................................................................................................. 215

DISEO FSICO CON POWER DESIGNOR............................................................................... 217 PASO DEL ESQUEMA CONCEPTUAL AL ESQUEMA FSICO ................................................................. 217 MODIFICACIN DE LAS TABLAS....................................................................................................... 218 COLUMNAS ...................................................................................................................................... 219 INDICES ............................................................................................................................................ 219 ATRIBUTOS EXTENDIDOS................................................................................................................. 221 TRIGGERS......................................................................................................................................... 221 RESTRICCIONES................................................................................................................................ 222 CREACIN DE VISTAS....................................................................................................................... 222

EJEMPLO DE DISEO CON POWER DESIGNOR................................................................... 225

Introduccin

Definicin de base de datos La primera pregunta que surge a la hora de comenzar este curso es la siguiente: Qu es una Base de Datos?. Existen varias definiciones para responder a esta pregunta:

"Coleccin de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una aplicacin o ms, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean mtodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados". (Martin, 1975).

"Coleccin o depsito de datos, donde los datos estn lgicamente relacionados entre s, tienen una definicin y descripcin comunes y estn estructurados de una forma particular. Una base de datos es tambin un modelo del mundo real y, como tal, debe poder servir para toda una gama de usos y aplicaciones". (Conference des Statisticiens Europens, 1977).

"Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por numerosas personas y cuya organizacin est regida por un modelo de datos". (Flory, 1982).

"Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador para satisfacer simultneamente a varios usuarios de forma selectiva y en tiempo oportuno". (Delobel, 1982).

"Coleccin no redundante de datos que son compartidos por diferentes sistemas de aplicacin". (Howe, 1983).

Bases de datos con SQL Server 2000 Transact SQL Grupo EIDOS

10

"Coleccin integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios". (Deen, 1985).

"Conjunto de ficheros maestros, organizados y administrados de una manera flexible de modo que los ficheros puedan ser fcilmente adaptados a nuevas tareas imprevisibles". (Frank, 1988).

"Coleccin de datos interrelacionados". (Elsmari y Navathe, 1989).

Como se ha visto, el concepto de base de datos ha ido cambiando a lo largo del tiempo. En la actualidad podemos establecer la definicin de base de datos como sigue.

"Coleccin o depsito de datos integrados, almacenados en soporte secundario (no voltil) y con redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su definicin (estructura de la base de datos) nica y almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualizacin y recuperacin, comunes y bien determinados, facilitarn la seguridad del conjunto de los datos".

Conceptos bsicos Sistema de Gestin de Base de Datos (SGBD): Conjunto de programas que permiten la

implantacin, acceso y mantenimiento de la base de datos. El SGBD, junto con la base de datos y con los usuarios, constituyen el Sistema de Base de Datos.

Modelo de datos: Conjunto de conceptos que permiten describir, a distintos niveles de abstraccin, la estructura de una base de datos, a la cual denominamos esquema.

Sistema de Informacin: Coleccin de personas, procedimientos y equipos diseados, construidos, operados y mantenidos para recoger, registrar, procesar, almacenar y recuperar esa informacin.

Esquema de una Base de Datos: Estructura de la Base de Datos.

Ocurrencia del esquema: Conjunto de datos que se encuentran almacenados en el esquema en un momento determinado. El esquema no vara mientras no vare el mundo real que ste describe, mientras que una ocurrencia del esquema es distinta en el transcurso del tiempo.

Del enfoque tradicional a los sistemas de bases de datos Para comprender mejor las diferencias entre los sistemas tradicionales basados en ficheros y los sistemas de bases de datos, pongamos un ejemplo. Supngase que disponemos de un archivo maestro de clientes con la siguiente informacin: nombre, direccin, ciudad, provincia y telfono. Si adems de esto, aadimos dos ficheros, uno para la emisin de facturas, y otro para la emisin de informes, podemos encontrarnos con los siguientes problemas:

Produccin de inconsistencias o incoherencias, debido a la replica de informacin (la misma informacin puede estar almacenada en distintos ficheros).

Grupo EIDOS 1. Introduccin.

11

Malgasto de memoria secundaria (por el mismo motivo).

Si en este momento se quiere aadir en nmero de fax, se hace necesario una completa reestructuracin de dicho fichero, sin mencionar el rediseo del cdigo de la aplicacin, para dar cabida a este cambio.

En cambio, en un sistema de gestin de bases de datos, estos problemas no tienen cabida, ya que el control de la informacin es inherente al propio sistema.

Algunas de las ventajas que ofrece utilizar un Sistema de Bases de Datos son las siguientes:

1. Independencia entre datos y tratamientos. El cambio en los programas no influye en la disponibilidad de los datos, as como la modificacin de stos no afecta a la reprogramacin de las aplicaciones que los usan.

2. Coherencia de resultados: Debido a que los datos son almacenados una sola vez, se evitan los problemas que puede ocasionar la redundancia. Ms adelante veremos cmo se permite una cierta duplicidad de datos, con el fin de conseguir una mayor eficiencia, controlada por el sistema y que no afecta a la redundancia lgica.

3. Mejor disponibilidad de datos para los usuarios: Los datos son compartidos por un conjunto de usuarios, que accede a ellos de forma concurrente, siempre que estn autorizados a ello.

4. Mayor valor informativo: El conjunto de los datos almacenados en la BD ofrece un mayor valor informativo, que la suma de ellos independientemente.

5. Mayor eficiencia en la recogida, validacin e introduccin de los datos en el sistema: Al no existir redundancia, los datos se recogen y validan una sola vez, aumentando as la eficiencia.

6. Reduccin del espacio de almacenamiento: La desaparicin (o disminucin) de redundancias, unido a las tcnicas de compactacin, implica una menor ocupacin de almacenamiento secundario.

A pesar de todas estas ventajas, los Sistemas de Bases Datos no estn exentos de inconvenientes. Aqu se detallan los ms importantes:

1. Instalacin costosa: La implantacin de un sistema de base de datos puede implicar un coste elevado, tanto en el equipo fsico (adquisicin de nuevas instalaciones, o ampliaciones de las existentes) como en el lgico (sistemas operativos, programas, compiladores, etc.), as como el coste de adquisicin o mantenimiento del SGBD.

2. Implantacin larga y difcil: Debido a las causas mencionadas anteriormente, la implantacin de un sistema de base de datos puede convertirse en una tarea larga y complicada.

3. Falta de rentabilidad a corto plazo: Los amplios costes que conlleva la implantacin, implica una rentabilidad no a corto, sino a medio, o incluso largo plazo.

4. Escasa estandarizacin: Esto supone una dificultad aadida a los usuarios de la base de datos.

5. Desfase entre teora y prctica: Los constantes avances tericos en al mbito de las bases de datos, que muchas veces no se ven traducidos en la prctica, hacen llevarse a engao a muchos usuarios, creyendo que constituyen ya una realidad, cuando no han sido todava plasmados.


12

Arquitectura ANSI/X3/SPARC ANSI/X3/SPARC es un grupo de estudio del Standard Planning and Requirements Commitee (SPARC) del ANSI (American National Standars Institute), dentro del Comit X3 que se ocupa de ordenadores e informtica. En sus estudios acerca de los SGBD, propugnaron una arquitectura basada en tres niveles de abstraccin:

1. Nivel Externo: Es el nivel ms cercano a los usuarios, y en el se definen los datos tal y como los va a ver este. Cada usuario puede tener su propio modelo externo, con aquellos datos e interrelaciones que dicho usuario necesite. En este nivel, tambin debern definirse las restricciones de uso, como por ejemplo el derecho a insertar o borrar determinados datos, o poder acceder a ellos.

2. Nivel Conceptual: Proporciona una descripcin global del esquema independiente de la estructura fsica de la base de datos, es decir, cuales son los datos, como estn organizados, las relaciones entre ellos y las restricciones de integridad y confidencialidad. El modelo conceptual, que es nico, establece el modelo terico sobre el que estn asentados los modelos externos.

3. Nivel Interno: Nivel ms bajo en la abstraccin. Describe la estructura almacenamiento fsico de los datos, las estrategias de acceso a los datos, etc. As mismo especifica todos los aspectos relacionados con el hardware, como por ejemplo dispositivos de memoria a usar (tamao de pginas, nmero de stas, tamao de los buffers, etc.), tcnicas de compresin de datos, criptografiado, etc. El modelo interno, que es nico, corresponde a la implementacin del modelo conceptual.

El modelo relacional El modelo ms usado, y por lo tanto el que se estudiar en este curso, es el modelo relacional. El motivo de que sea ste el modelo ms extendido, radica en la facilidad y en su amplia base matemtica, lo que permitir, como ya se ver ms adelante, el poder estructurar o reestructurar las relaciones, para evitar cierto tipo de anomalas, o acelerar las consultas / actualizaciones. Dicho modelo se basa en la representacin de la informacin por medio de estructuras tipo tabla, denominadas relaciones, y que almacenan informacin para una determinada entidad. Cada una de estas relaciones representa en sus columnas los valores significativos, es decir, de los que interesa conocer su valor, para cada entidad. Dichas columnas se denominan atributos, y para cada uno de ellos existir un valor (cabe la posibilidad de que existan atributos en los que no aparezca ningn valor). Cada fila representa la informacin para cada ocurrencia de una determinada entidad. La informacin se descompondr, como ya se ha dicho, en dar valores para cada uno de los atributos de la entidad. A dichas filas tambin se las denomina tuplas. Cada atributo o conjunto de atributos que identifica unvocamente a cada tupla de la relacin se denomina clave. Las claves se representan subrayando el / los atributo/s que forman parte de ella.

El siguiente ejemplo (Figura 1) representa una relacin denominada empleado, que almacena informacin sobre los empleados de una empresa. La informacin que se desea saber de cada empleado es su cdigo, su nombre y apellidos, su sueldo y su categora. Por lo tanto, los atributos son cod_empleado, nombre, apellidos, sueldo y categora. Adems, el atributo cod_empleado es clave de la relacin, ya que si se sabe el valor de dicho atributo, se puede saber a que empleado nos estamos refiriendo.

Grupo EIDOS 1. Introduccin.

13

Figura 1

Visin general sobre el diseo de bases de datos

Fases del diseo El diseo de una base de datos suele descomponerse en tres grandes fases (diseo conceptual, lgico y fsico), lo que permite reducir la complejidad que entraa el diseo, a la vez que ayuda a alcanzar los dos principales objetivos que tienen las bases de datos:

Ser una representacin fidedigna del mundo real,

Ser un servidor operacional y eficiente de los datos.

El diseo conceptual parte de la especificacin de requerimientos, y produce como resultado el esquema conceptual de la base de datos. Un esquema conceptual es una descripcin a alto nivel de la estructura de la base de datos, independientemente de la eleccin del equipamiento y del Sistema Gestor de Base de Datos (en adelante referido como SGBD) que se usen para la implementacin de la base de datos.

El diseo lgico parte del esquema conceptual y genera el esquema lgico. Un esquema lgico es la descripcin de la estructura de la base de datos que puede procesarse por un SGBD. Una vez elegido el modelo lgico, pueden existir un conjunto de esquemas lgicos equivalentes al mismo esquema conceptual. La meta del diseo lgico es producir el esquema lgico ms eficiente con respecto a las operaciones de consulta y actualizacin.


16

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

Figura 2. Diseo de una base de datos

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

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

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

17

La Figura 3 muestra la correspondencia existente entre las fases de diseo y los niveles de la arquitectura ANSI/X3/SPARC. El diseo conceptual es una etapa previa al diseo lgico. A su vez, el diseo lgico se corresponde con los niveles externo (donde se definen las vistas de usuario, es decir, conjunto de informacin que puede ser accedida por un usuario) y lgico (estructura de tablas y restricciones) de la arquitectura ANSI/X3/SPARC. El diseo fsico se corresponde con el nivel fsico de dicha arquitectura.

Diseo conceptual El objetivo del diseo conceptual, tambin denominado modelo conceptual, y que constituye la primera fase de diseo, es obtener una buena representacin de los recursos de informacin de la empresa, con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador. Consta de dos fases:

Anlisis de requisitos: Es en esta etapa donde se debe responder a la pregunta: qu representar?. Se pretende en esta etapa elaborar un esquema descriptivo del mundo real, mediante distintas tcnicas, aunque la ms usada es la de entrevistas a los usuarios, lo que implica una descripcin de los datos mediante el uso del lenguaje natural. Los problemas que presenta esta primera especificacin, se irn refinando hasta obtener el esquema conceptual.

Conceptualizacin: En esta etapa se intenta responder a la pregunta: cmo representar?. Consiste en ir refinando sucesivamente el primer esquema descriptivo, para conseguir pasar del mundo real al esquema descriptivo y de ste al esquema conceptual, que deber ser expresado sin tener en consideracin cuestiones de implementacin, es decir, debe ser independiente del SGBD a usar.

Diseo lgico El objetivo del diseo lgico es transformar el esquema conceptual obtenido en la fase anterior, adaptndolo al modelo de datos en el que se apoya el SGBD que se va a utilizar.

El modelo relacional es el nico modelo que ha permitido abordar la fase de diseo lgico aplicando una teora formal: el proceso de normalizacin.

Sin embargo, la normalizacin no cubre toda esta fase, mostrndose insuficiente para alcanzar todos los objetivos de la misma. En la prctica a veces es preciso proceder a una reestructuracin de las relaciones.

La Figura 4, resume la fase de diseo lgico, en la que una vez estructurado el esquema origen, analizando diferentes factores como las distintas dependencias o la posibilidad de existencia de valores nulos, se obtiene un esquema relacional, al que se aaden las claves ajenas y otras restricciones de integridad. Ahora bien, si se tiene en cuenta el segundo de los objetivos mencionados anteriormente, el de que la base de datos ha de ser un servidor operacional y eficiente de los datos, se hace necesaria una reestructuracin de relaciones, con el fin de mejorar la eficiencia de la base de datos.

Esta reestructuracin toma como entrada el esquema relacional estructurado obtenido anteriormente, as como el anlisis de los requisitos de determinadas vistas o aplicaciones crticas, obteniendo de esta manera un esquema relacional resultante, en el que priman las consideraciones de eficiencia.

En la Figura 4, se detallan las dos etapas en las que se divide la fase de diseo lgico. La primera, consistente en la estructuracin de las relaciones atendiendo a consideraciones de tipo lgico, incluye


18

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

Figura 4. Estructuracin y reestructuracin de relaciones

El objetivo de la estructuracin de relaciones es obtener un esquema relacional estructurado, tomando como entrada un esquema relacional origen con todas sus dependencias, valores inaplicables, etc.

En esta etapa de estructuracin se conseguir, por razones lgicas, un esquema normalizado, en el cual se han eliminado los valores nulos (inaplicables) mediante un particionamiento horizontal basado en la seleccin, seguido de la proyeccin.

Las herramientas para llevar a cabo este objetivo son dos:


19

El proceso de normalizacin

El particionamiento horizontal de relaciones

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

Figura 5. Normalizacin de relaciones

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

Figura 6. Particionamiento horizontal de relaciones

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


20

datos ha de ser un servidor operacional y eficiente de los datos, por lo que se hace necesaria esta segunda etapa en el diseo lgico. Para lograr este objetivo existen diversos mtodos o formas de organizar los datos, considerando esta idea de mejora de la eficiencia, que son:

El proceso de desnormalizacin

El particionamiento de relaciones

El proceso de desnormalizacin es justamente el proceso inverso al de normalizacin. La Figura 7, muestra un ejemplo en el que dos tablas previamente normalizadas, dan origen a una tabla ms grande (que es justamente la tabla que se tena antes de realizar la normalizacin), mediante un proceso de desnormalizacin.

Figura 7. Desnormalizacin de relaciones

El particionamiento de relaciones es otra forma de conseguir una mayor eficiencia en la base de datos. El objetivo de este proceso es dada una relacin, dividirla en otras relaciones de forma horizontal, o vertical, o mixta (incluye ambas). A cada una de estas formas de particionamiento se la denomina, respectivamente, particionamiento horizontal, particionamiento vertical y particionamiento mixto.

El particionamiento horizontal de relaciones consiste en la divisin de las tuplas de una relacin en subconjuntos. Esto es muy til cuando existen consultas que acceden slo a determinada parte de la informacin dependiendo del valor de algn atributo, o en bases de datos distribuidas, ya que cada subconjunto puede ubicarse en distintos nodos de la red, acercndose al lugar de su tratamiento.

En el particionamiento vertical, los atributos de una relacin R son distribuidos en grupos no solapados y la relacin R se proyecta en relaciones fragmentarias de acuerdo a estos grupos de atributos. Estos fragmentos se colocan en diferentes localizaciones de la base de datos distribuida. Por ello, el objetivo del particionamiento vertical es crear fragmentos verticales de una relacin de manera que minimice el coste de acceso a los elementos de datos durante el procesamiento de la transaccin. Si los fragmentos se ajustan bien a los requisitos del conjunto de transacciones facilitado, entonces el coste de proceso de las transacciones podra ser minimizado. El particionamiento vertical tambin puede usarse en la particin de tablas individuales en bases de datos centralizadas, y en la divisin de datos entre diferentes niveles de jerarquas de memoria, etc. En el caso de bases de datos distribuidas, el coste de proceso de transacciones se minimiza incrementando el proceso local de las transacciones (en un "nodo") as como reduciendo el nmero de accesos a objetos de datos que no son locales.


21

Como su propio nombre indica, el particionamiento mixto engloba a ambos tipos de particionamiento (horizontal y vertical). Consiste en aplicar un particionamiento vertical a uno o ms de los fragmentos obtenidos mediante un particionamiento horizontal, o viceversa.

Diseo fsico El objetivo del diseo fsico, que es la ltima fase del proceso de diseo, es conseguir una instrumentacin lo ms eficiente posible del esquema lgico. Aqu se tienen en cuenta aspectos del hardware, requisitos de procesos, caractersticas del SGBD, del SO y en general, cualquier factor cercano a la "maquina". Con ello se persigue:

disminuir los tiempos de respuesta

minimizar espacio de almacenamiento

evitar las reorganizaciones

proporcionar la mxima seguridad

optimizar el consumo de recursos

El principal problema que se plantea en la fase de diseo fsico es el debido a la poca flexibilidad de los actuales SGBD, los cuales obligan a trasladar a la fase de diseo lgico, aspectos de carcter fsico, que deberan ser ajenos a dicha fase. Esto obliga a iterar desde la fase de diseo fsico a la de diseo lgico, y viceversa, hasta obtener conseguir los objetivos anteriormente expuestos, lo que explica la obligacin de la etapa de reestructuracin en el diseo lgico.

Como resultado del diseo fsico se genera un esquema fsico, que es una descripcin de la implementacin de la base de datos en memoria secundaria; describe las estructuras de almacenamiento y los mtodos de acceso para acceder a los datos de una manera eficiente. Por ello el diseo fsico se genera para un SGBD y un entorno fsico determinado.

Diseo conceptual

Introduccin Como ya se ha visto en el tema anterior, el diseo conceptual, que constituye la primera etapa en el diseo de una base de datos, consiste en obtener una buena representacin de los recursos de informacin de la empresa, con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador. Puesto que no se corresponde con ningn nivel de la arquitectura ANSI/X3/SPARC, sino que es un paso previo, tiende a ser no tenido en cuenta a la hora de proceder al diseo de una base de datos. Esto no es aconsejable, ya que el diseo lgico parte del esquema conceptual y, si ste no es correcto, o no representa fielmente la informacin del mundo real, el esquema de la base de datos no ser estable, vindonos obligados a reajustarlo constantemente debido a las deficiencias arrastradas desde esta etapa de diseo. De ah la importancia de realizar un buen esquema conceptual, que represente fielmente las caractersticas del mundo real.

Otro error que se suele cometer en esta etapa de diseo es el de considerar aspectos tales como la eficiencia del equipo hardware en el que se vaya a montar la base de datos, o SGBD's concretos. Como ya se ha dicho, el esquema conceptual debe representar la informacin fuera de consideraciones sobre hardware y sobre el SGBD sobre el que se implementar. Por lo tanto, se pueden establecer las siguientes caractersticas que debe cumplir un buen esquema conceptual:

Debe representar fielmente la informacin del mundo real

Es independiente del SGBD

Es independiente del Hardware


24

Conviene no olvidar, por lo tanto, que un buen diseo del esquema conceptual, influir positivamente en el resto de etapas.

Etapas del diseo conceptual La fase de diseo conceptual, puede subdividirse a su vez en dos etapas:

1. Etapa de anlisis de requisitos: En esta etapa se debe responder a la pregunta "Qu representar?". El objetivo es elaborar un esquema descriptivo de la realidad, en el que se provean detalles de los datos a representar. Dicho esquema se obtiene mediante el estudio u observacin del mundo real (estudio de las reglas de la empresa, entrevista a los usuarios, etc.). Aunque existen muchas respuestas sobre el modo de recoger dicha informacin, la ms utilizada es el lenguaje natural que, aunque carece del formalismo que pueden infligir otros mtodos, permite una mejor y ms fcil comprensin de la informacin por parte del usuario, y le permite especificar los requisitos sin la intervencin de formalismos. Este primer esquema percibido bruto (como lo llaman Benci y Rolland), se ira refinando sucesivamente, hasta llegar al esquema conceptual.

2. Etapa de conceptualizacin: En esta etapa se debe responder a la pregunta "Cmo representar?". En ella se transforma el esquema obtenido en la primera, mediante refinaciones sucesivas. Se deber obtener el esquema conceptual mediante una representacin normalizada, que se apoye en un modelo de datos que cumpla determinadas propiedades (segn Piattini y De Miguel): coherencia, plenitud, no redundancia, simplicidad, fidelidad, etc. El modelo que se estudiar es el Modelo Entidad / relacin (en adelante referido como ME/R o modelo E/R), que es el ms utilizado hoy en da.

El modelo entidad / relacin El modelo E/R fue propuesto por Peter P. Chen en dos artculos que public en los aos 1976 y 1977. En ellos define dicho modelo como una vista unificada de los datos, centrndose en la estructura lgica y abstracta de los datos, como representacin del mundo real, con independencia de consideraciones de tipo fsico. Posteriormente se fueron proponiendo nuevas aportaciones al modelo, lo cual explica que no exista uno slo, sino distintos modelos segn los autores.

Los objetivos que debe cumplir un esquema conceptual son los siguientes (Piattini y De Miguel):

1. Captar y almacenar el universo del discurso mediante una descripcin rigurosa.

2. Aislar la representacin de la informacin de los requisitos de mquina y exigencias de cada usuario en particular

3. Independizar la definicin de la informacin de los SGBD en concreto.

A continuacin se describir el proceso de creacin de un esquema conceptual, siguiendo el modelo E/R. ste se basa en una representacin grfica de una serie de entidades relacionadas entre s. Al utilizar una representacin de este tipo, el modelo E/R permite distinguir fcilmente y a simple vista, las relaciones existentes entre las distintas entidades. Existen muchas formas de representarlo, como ya se ha comentado; la que se utilizar aqu no es, por supuesto, la nica forma de hacerlo. Los elementos de los que se componen son los siguientes:

Grupo EIDOS 3. Diseo conceptual

25

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

Figura 8

2. Atributos: Un atributo es cualquier caracterstica que describe a una entidad. Los atributos

de una entidad se colocan dentro del rectngulo que representa dicha entidad, justo debajo del nombre de sta. Por ejemplo, se puede decir que un automvil tiene las siguientes caractersticas: n de matricula, marca, modelo y color, lo cual se muestra en la Figura 9.

Figura 9

3. Clave: La clave de una entidad es un atributo o conjunto de atributos de dicha entidad, que

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

Figura 10

4. Relacin: Una relacin representa, como su propio nombre indica, una correspondencia

entre dos entidades. Si tenemos dos entidades automvil y persona, podemos tener una relacin entre ellas. Dicha relacin se puede establecer en ambos sentidos:

una persona posee un automvil, y Un automvil pertenece a una persona.


26

5. Cardinalidad de una relacin: La cardinalidad de una relacin representa el nmero de ocurrencias que se pueden dar de una relacin. Puede ser de tres tipos:

Cardinalidad 1-1: cada ocurrencia de una entidad se relaciona con una ocurrencia de otra entidad. Ej.: una persona posee un automvil. Se representa como indica la Figura 11.

Figura 11

Cardinalidad 1-N: tambin llamada uno a muchos. Cada ocurrencia de una entidad

puede relacionarse con varias ocurrencias de otra entidad. Ej.: una persona posee varios automviles. Se representa como muestra la Figura 12.

Figura 12

Cardinalidad N-M: tambin llamada muchos a muchos. Cada ocurrencia de una

entidad puede relacionarse con varias ocurrencias de otra entidad y viceversa. Ej.: una persona posee varios automviles y un automvil puede pertenecer a varias personas. Se representa como aparece en la Figura 13.

Figura 13

6. Cardinalidad mxima de una relacin: representa el nmero mximo de ocurrencias de

una entidad con las que se puede relacionarse otra entidad. Ej.: una persona puede tener como mximo tres automviles.

7. Cardinalidad mnima de una relacin: representa el nmero mnimo de ocurrencias de una entidad con las que se puede relacionarse otra entidad. Ej.: un automvil debe pertenecer como mnimo a una persona.

8. Entidad dbil: se dice que una entidad es dbil, o es dependiente de otra, cuando no somos capaces de conocer a que ocurrencia de entidad nos estamos refiriendo, ni siquiera conociendo su clave, sino que debemos conocer el valor de algn otro atributo de otra


27

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

Figura 14

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

Cardinalidad mxima 1, cardinalidad mnima 1.

Cardinalidad mxima 1, cardinalidad mnima 1.

Cardinalidad mxima N, cardinalidad mnima 0.

Cardinalidad mxima N, cardinalidad mnima 1.

Figura 15

Veamos a continuacin unos ejemplos para comprender mejor las cardinalidades mxima y mnima. Como se podr comprobar, las cardinalidades de una relacin se ponen en la ltima relacin a la que se hace referencia, por ejemplo, si se tienen las entidades alumno y asignatura, la cardinalidad de la relacin un alumno cursa asignaturas, se pondr al lado de la entidad asignatura.

En el siguiente ejemplo(Figura 16), se tiene una relacin 1-1 en la que un automvil pertenece a una nica persona (cardinalidad mxima 1), sin la posibilidad de que exista un automvil que no tenga dueo (cardinalidad mnima 1). Esto significa que en el modelo no interesa tener informacin de aquellas personas que no tengan automvil.

Figura 16

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


28

Figura 17

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

Figura 18

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

Figura 19

Para concluir esta seccin se ver un ejemplo completo que representar todos los conceptos vistos hasta ahora. Supongamos que se desea establecer un modelo conceptual para la gestin de una biblioteca. Se desean tener almacenados todos los libros que la componen.

Para cada libro interesa conocer el ISBN, el ttulo, el autor o autores, la editorial, el ao de publicacin y la materia. De cada autor se quiere conocer su nombre, apellidos y nacionalidad.

Un autor podr haber escrito varios libros, de la misma forma que en un libro pueden participar varios autores. De la editorial se desea conocer el nombre y la ciudad.

A dicha biblioteca podrn estar suscritos varios usuarios. De ellos se quiere saber su DNI, nmero de socio, nombre, apellidos, direccin y telfono. Por cuestiones directivas, se limita el nmero de ejemplares prestados a cada usuario a uno.

Se dispone, a su vez, de un nico ejemplar de cada libro, por lo que un libro prestado a un usuario, no podr ser prestado a otro hasta que se devuelva. Deber quedar constancia de la fecha de prstamo de cada ejemplar.


29

Figura 20

Lo ms destacable del anterior ejemplo es la entidad prstamo. Es una entidad dbil que depende de libro y de socio, ya que para diferenciar un prstamo de otro, se necesita saber no slo el libro, sino el socio al cual se ha prestado. Tambin se pueden observar que las cardinalidades mnimas son 1. Esto quiere decir que slo se guardar informacin de las entidades cuando exista, al menos, una ocurrencia de la entidad. Las nicas relaciones que tienen cardinalidad opcional, son las que tienen como origen o destino a la entidad prstamo, lo cual es lgico, ya que tendremos informacin de todas las entidades, aunque todava no se haya realizado ningn prstamo.

Ejemplos prcticos de diseo conceptual A continuacin resolveremos unos problemas de diseo conceptual, para ir familiarizando al lector con los conceptos vistos hasta ahora. Para realizarlos se utilizar la S-Designor, que es una herramienta CASE que abarca gran parte del ciclo de vida de las aplicaciones, incluyendo el diseo de esquemas conceptuales. No se preocupe si no conoce la herramienta, ya que se ver en detalle en prximos temas, simplemente qudese con la idea general de la construccin del esquema.

El problema que nos planteamos es el siguiente. Supngase que se desea informatizar una tienda de discos. Para ello se desean tener almacenados los nombres de todos los discos disponibles, adems de sus cantantes y canciones. As mismo se desean almacenar los clientes que han comprado en dicha tienda. Pues bien, empezaremos identificando las entidades, entendiendo por entidad un grupo de caractersticas que tienen entidad propia. Como primera entidad, podemos establecer los discos que se venden, ya que se desea conocer informacin de ellos, como puede ser un cdigo que lo identifique dentro de la estantera. Por otro lado se desea almacenar todos los artistas que intervienen en los discos de nuestra tienda, y para cada uno de ellos se desea conocer su nombre y apellidos, por lo tanto ya tenemos identificada una segunda entidad. Adems, se desea conocer todas las canciones que estn disponibles en los discos, identificada cada una de ellas por un cdigo de cancin, y que adems tendrn sus propias letras. Pues ya tenemos la tercera entidad. La cuarta estar formada por los clientes, de los cuales se desea almacenar su nombre, apellidos, direccin y telfono, y que podrn estar identificados internamente por un cdigo de cliente.

Figura 21


30

Una vez establecidas las entidades, slo nos queda relacionarlas. Podemos observar las siguientes relaciones:

1. Entre disco y cancin: en un disco pueden aparecer varias canciones, y cada cancin puede estar en varios discos (N-M).

2. Entre cantante y cancin: un cantante puede componer varias canciones, y una cancin puede estar compuesta por varios cantantes (N-M).

3. Entre cliente y disco: un cliente puede comprar varios discos, pero un disco slo puede ser comprado por un cliente 1-N.

Por lo tanto, el esquema conceptual es que muestra la Figura 22

Figura 22

Vamos a plantearnos otro problema. Supongamos que se desea tener almacenados todos los datos de los profesores de una empresa dedicada a impartir cursos, as como una breve descripcin de stos, y los alumnos a los cuales se les ha impartido. Empezamos identificando entidades.

De un profesor se desea conocer su nombre y apellidos, direccin y despacho, por lo tanto establece una entidad. Otra entidad podra ser el alumno, del cual se desea conocer su nombre, apellidos, direccin y telfono.

Ni que decir tiene que el curso describe otra entidad, de la cual se desea conocer su descripcin. Sin embargo, podemos recurrir a un procedimiento muy usual, denominado tipificacin de estados, muy usado en el diseo conceptual, y que consiste en tener una entidad que tipifique los posibles estados que puede tomar un atributo.

La principal ventaja de este procedimiento radica en que muchas veces supone un ahorro de espacio de almacenamiento (por ejemplo al identificar nombres de ciudades largas con un solo nmero) adems de una estandarizacin de los datos almacenados (el estado slo se almacena una vez).

Por ejemplo podemos tipificar las ciudades, para lo cual creamos una nueva entidad ciudad, donde se almacenar un cdigo y la descripcin de la ciudad. Cuando almacenemos la ciudad de un alumno, slo deberemos especificar el cdigo de la ciudad.


31

Figura 23

Una vez establecidas las entidades, vamos a definir las relaciones entre ellas.

1. Profesor y Curso: un profesor puede impartir varios cursos, pero un curso slo puede ser impartido por un profesor (1-N).

2. Alumno y Curso: un alumno puede asistir a varios cursos, y a un curso pueden asistir varios alumnos (N-M).

3. Alumno y Ciudad: un alumno vive en una ciudad, y una ciudad puede tener varios alumnos (1-N).

Por lo tanto, el esquema conceptual es el mostrado en la Figura 24.

Figura 24

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


32

Vamos a ver un ltimo ejemplo. Supngase un banco que desea almacenar todos sus clientes, adems de los productos que puede ofrecer a stos. Cada cliente podr escoger entre todos estos productos el o los que ms le plazcan (crditos, fondos de inversin, libretas de ahorro, etc.).

De la misma forma, dicho banco tiene intereses en otras empresas, por lo que desea conocer en todo momento la situacin de dichas empresas, para poder mejorar su poltica de inversiones.

Puesto que dicho banco esta constituido como sociedad annima, desea almacenar todos los componentes de su consejo de administracin (actuales y ex-miembros) as como todas las actas de las reuniones ordinarias y extraordinarias.

Las decisiones de inversin en estas empresas saldrn como resultado de dichas reuniones, as como la oferta de nuevos productos.

Como habr podido observar, este ejemplo es un poco ms complejo, pero no desespere, el proceso es similar al de los dems ejemplos. Empezaremos definiendo entidades y las veremos representadas en la Figura 25.

1. Cliente: se desea conocer su nombre, apellidos, direccin y NIF, y estar identificado por un cdigo interno cod_cliente.

2. Producto: del cual queremos saber su descripcin y estar identificado por un cdigo interno cod_producto.

3. Empresa: identifica las empresas en las cuales el banco ha invertido. De ellas se desea conocer su cdigo, nombre y CIF.

4. Consejo: establece los componentes del consejo de administracin. Para ello se almacenar el nombre, apellidos y cdigo de cargo de cada uno de sus componentes, y si el cargo es vigente o no. Podremos utilizar una nueva entidad que tipifique los tipos de cargo.

5. Tipo_cargo: describe los posibles cargos que puede tomar una persona en el consejo de administracin, y esta compuesto por un cdigo de tipo de cargo, y una descripcin del mismo (secretario, presidente, etc.).

6. Reunin: entidad encargada de describir la informacin de las actas de las reuniones. Sus atributos son cod_reunin, fecha, extraordinaria, que especifica si la reunin ha sido ordinaria o extraordinaria y una descripcin.

Figura 25


33

Identifiquemos ahora las relaciones. Su representacin grfica aparece en la Figura 23.

1. Cliente y producto: cada cliente puede escoger varios productos, y cada producto puede ser ofrecido a varios clientes.

2. Consejo y cargo: un miembro del consejo slo tiene un cargo, y cada cargo puede pertenecer a ms de un miembro.

3. Reunin y consejo: a cada reunin pueden asistir varios miembros del consejo de administracin, y cada miembro puede asistir a ms de una reunin.

4. Reunin y producto: de cada reunin puede salir la oferta de mas de un nuevo producto pero cada producto nuevo slo puede salir de una reunin.

5. Reunin y empresa: de cada reunin pueden salir decisiones de invertir en ms de una empresa, y cada decisin de inversin slo sale de una reunin.

Diseo lgico

Introduccin Como ya se ha sealado, el diseo lgico de una base de datos consta de dos etapas: el diseo lgico estndar y el diseo lgico especfico. En el diseo lgico estndar, se toma el esquema conceptual resultante de la fase de diseo conceptual, y teniendo en cuenta los requisitos de proceso, de construye un esquema lgico estndar (ELS), que se apoya en un modelo lgico estndar (MLS), que ser el mismo modelo de datos soportado por el SGBD a utilizar (relacional, jerrquico, etc.), pero sin las restricciones de ningn producto comercial en concreto. En nuestro caso se utilizar el MLS relacional. Una buena forma de describir el ELS es utilizando el lenguaje estndar del MLS (por ejemplo SQL).

Una vez obtenido el ELS, y considerando el modelo lgico especfico (MLE) propio del SGBD a usar (ORACLE, INFORMIX, SQL-SERVER, etc.), se elabora el esquema lgico especfico (ELE). Al igual que en el caso anterior, una buena forma de describirlo es utilizando el lenguaje de definicin de datos (LDD) del producto especifico utilizado (en el caso de SQL-SERVER, se usar el TRANSACT SQL). El diseo lgico especfico est muy ligado a la fase de diseo fsico, ya que ambos dependen mucho del SGBD que se utilice.

En la fase de diseo lgico, adems de las herramientas ya descritas (MLS, MLE, lenguajes SQL), se disponen de otras que permiten establecer un buen diseo lgico, como por ejemplo la normalizacin, la desnormalizacin, etc., que ya se vern mas adelante en este tema.


36

Paso del esquema conceptual al esquema lgico estndar Lo primero que hay que realizar en la fase de diseo lgico, es obtener el esquema lgico estndar, a partir del esquema conceptual obtenido en la primera fase. Las reglas que permiten pasar del modelo E/R al esquema lgico, son las que a continuacin se explican:

Cada entidad se transforma en una relacin: esto es, cada entidad genera una tabla, con sus mismos atributos, incluyendo las claves.

Cada relacin N-M genera una tabla: las relaciones entre entidades con cardinalidad N-M generan una tabla, con los atributos clave de ambas entidades.

Cada relacin 1-N importa las claves de la entidad con las que se relaciona: cada relacin con cardinalidad 1-N importa los atributos clave que contiene la entidad con cardinalidad N.

Cada relacin dependiente, importa la clave de la otra entidad, como clave.

Para entender mejor el funcionamiento de este mtodo, veamos el paso a tablas del ejemplo visto en el tema anterior acerca de la gestin de una biblioteca. La entidad libro est relacionada con la entidad editorial con cardinalidad 1-N, por lo tanto importa la clave de la entidad con cardinalidad 1. A su vez, esta relacionada con la entidad con la entidad autor, pero en este caso, la cardinalidad es N-M, lo que implica que se generar una tabla intermedia, en la que se almacenarn las claves de ambas entidades. Esta tabla, a la que denominaremos Libro_autor mantiene la informacin de los cdigos de libros junto con los cdigos de autores. Posteriormente, si se desea extraer ms informacin, tanto del libro como del autor, se deber acceder a sendas tablas. Por ltimo se dispone de la entidad Prstamo, que es dependiente tanto de la entidad Libro como de la entidad Usuario, lo que quiere decir que se generar una tabla, con los atributos de la entidad Prstamo adems de las claves de las entidades de las que es dependiente, es decir, ISBN y Num_socio, que entrarn como claves en dicha tabla. Esta ltima relacin obtenida, mantiene informacin de qu libros han sido prestados a qu usuarios y en qu fecha. El esquema de las tablas resultantes es el que se muestra en la Figura 26

Figura 26

Veamos ahora el paso a tabla de otro ejemplo visto en el tema anterior, cuyo esquema conceptual es el que muestra la Figura 27.

Empezaremos identificando las relaciones, y concretando las tablas que generarn:

1. Cliente-Disco: puesto que es una relacin 1-N, la entidad disco generar una tabla con sus atributos, e importar el atributo clave de la entidad con cardinalidad 1, es decir, cod_cliente. A su vez, la entidad cliente generar su propia tabla, con sus propios atributos, es decir, cod_cliente, nombre, apellidos y telefono.

Grupo EIDOS 4. Diseo lgico

37

2. Disco-Cancin: es una relacin 1-N, a si que, siguiendo el mismo razonamiento anterior, la tabla cancin generada importar el cod_disco de la entidad disco.

3. Cancin-Cantante: en este caso se tiene una relacin N-M, es decir, se generar una tabla intermedia, con los atributos claves de las entidades que relaciona, es decir, cod_cancin y cod_cantante.

4. Disco_Cantante: siguiendo el mismo razonamiento, al ser una relacin N-M, se generar una tabla intermedia, con los atributos cod_cantante y cod_disco.

Figura 27

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

Figura 28

Etapas en el diseo lgico Como ya se ha comentado, la fase de diseo lgico de una base de datos consiste en dos etapas:

Etapa de estructuracin: donde el objetivo primordial es encontrar un esquema que sea una representacin fidedigna del mundo real. La forma de lograrlo es mediante el particionamiento horizontal, para evitar valores nulos, y el proceso de normalizacin.

Etapa de reestructuracin: donde se tienen en cuenta aspectos ms ligados con el nivel fsico, y que consiste el modificar el esquema obtenido en la fase anterior para adaptarlo a las consideraciones de eficiencia. Esta etapa, que debera ser ajena al diseo lgico, se considera aqu debido a la falta de flexibilidad de los SGBD, obligando a trasladar a esta etapa aspectos


38

mas relacionados con el nivel fsico. La forma de lograrlo es mediante la desnormalizacin, y el particionamiento, bien sea horizontal, vertical o mixto.

Comenzaremos por estudiar el particionamiento horizontal de relaciones, usado tanto en la etapa de estructuracin como en la de reestructuracin, para dar paso posteriormente al proceso de normalizacin, dejando para el final el particionamiento vertical, mixto y la desnormalizacin.

Particionamiento horizontal de relaciones Como su propio nombre indica, el particionamiento horizontal consiste en dividir longitudinalmente las filas que forman una tabla, esto es, separar las filas que conforman una relacin, para llevarlas a otra. Para entenderlo mejor, supngase el siguiente ejemplo en el que se tiene la tabla publicacin, con los siguientes campos: cod_publicacin, ttulo, autor, editorial.

En un momento dado, la informacin que tenemos en la tabla es la mostrada en la Tabla 1.

Cod_publicacin Ttulo Autor Editorial

123BB3-3 El Quijote Miguel de Cervantes Ibrica

113ZD3-0 El impacto de las TI Francisco Hierves

2322-DD Rimas y Leyendas G. A. Becquer Alcal

Tabla 1

Tenemos informacin sobre dos libros, con su autor y su editorial correspondiente, y un artculo (El impacto de las TI) que, como es obvio, no tiene editorial. En este caso, podra ser conveniente "partir" dicha tabla horizontalmente en otras dos, es decir llevar parte de la informacin a una tabla, y parte a otra.

Aqu la diferenciacin se establece entre aquellas filas que tienen editorial, es decir, libros, y aquellas que no tienen editorial, o artculos. Por lo tanto, se crean dos tablas: una para albergar los libros y otra para ubicar los artculos.

La Tabla 2 posee la tabla de libros, mientras que la Tabla 3 contiene los artculos.

Cod_publicacin Ttulo Autor Editorial

123BB3-3 El Quijote Miguel de Cervantes Ibrica

2322-DD Rimas y Leyendas G. A. Becquer Alcal

Tabla 2


39

Cod_publicacin Ttulo Autor

113ZD3-0 El impacto de las TI Fco. Hierves

Tabla 3

Con esto, lo que hemos conseguido es eliminar la existencia de valores nulos no aplicables. Un valor nulo es aquel que representa informacin desconocida, inexistente o no vlida (en nuestro caso el valor del atributo editorial en el artculo). Los valores nulos pueden ser aplicables o no aplicables. Mientras los no aplicables no cambian, es decir, permanecen nulos, los aplicables pueden dejar de serlo en algn momento.

Esto que acabamos de realizar, es el primer paso que se debe seguir en el proceso de estructuracin de relaciones. Sin embargo, el particionamiento horizontal no slo se utiliza aqu, sino que tambin puede usarse en la fase de reestructuracin para conseguir una mayor eficiencia. Por ejemplo, si se dispone de una base distribuida (para entendernos, una base de datos con distintos nodos, situados en distintas localizaciones, con determinada informacin en cada uno) con informacin acerca de clientes, y suponiendo que se dispone de dos nodos, uno en Madrid y otro en Barcelona, lo lgico sera pensar en situar la informacin de aquellos clientes que residen en Barcelona en dicho nodo, y ubicar nicamente la informacin de los clientes que viven en Madrid en dicho nodo. Los motivos son los siguientes:

Si se sita toda la informacin en un nico nodo, el coste del acceso remoto aumenta (si toda la informacin est en Madrid, una consulta de un cliente que vive en Barcelona se debera realizar al nodo de Madrid, con el coste que ello supone).

Si se sita toda la informacin en ambos nodos, el coste de almacenamiento aumenta al tener toda la informacin duplicada.

En este caso, pues, lo que se deber realizar en un particionamiento horizontal, para situar aquellas filas que correspondan a clientes de Madrid, en el nodo de Madrid, y aquellas filas que correspondan a clientes de Barcelona, en el nodo de Barcelona.

Supongamos, por ejemplo, que tenemos el siguiente esquema lgico, correspondiente a una base de datos para gestionar los alumnos de una empresa de educacin a distancia.

Figura 29

Sobre el esquema de la Figura 29, nos podemos plantear varias cuestiones:

1. Se dispone de dos tablas, alumno y profesor. La tabla alumno guarda sus datos personales, y las calificaciones obtenidas en cada una de las asignaturas, mientras que la tabla profesor


40

almacena, adems de sus datos personales, las aulas donde dicho profesor imparte cada una de las clases.

2. La base de datos se encuentra distribuida, es decir, se dispone de un nodo en cada una de las provincias, donde se almacena la informacin relevante a sta.

3. Los alumnos pueden optar por dos ramas, ciencias o letras, y para cada una de ellas se imparten dos asignaturas, arte y latn en letras, y matemticas y ciencias en la rama de ciencias.

Nos planteamos, entonces, aumentar la eficiencia de la base de datos, para adecuarla a las necesidades de cada una de las provincias donde se encuentra ubicada la base de datos.

Puesto que en cada nodo slo precisa informacin relevante a ste, podemos optar por tres opciones:

Opcin 1: colocar la base de datos en un slo nodo (centralizado), al que accedern los dems.

Opcin 2: colocar la parte de informacin relevante a cada nodo en cada uno de ellos.

Opcin 3: colocar una copia de toda la base de datos en cada nodo.

En la Tabla 4 se analizan las ventajas e inconvenientes de cada una de la anteriores opciones.

Ventajas inconvenientes

Opcin 1

Se disminuye el espacio de almacenamiento (una sola copia de la informacin), y en la provincia donde se encuentre la base de datos se disminuir el tiempo de acceso

El resto de las provincias deber acceder a la provincia donde se encuentre la base de datos, con el trfico de red y aumento de tiempo de acceso que esto supone.

Opcin 2

Cada provincia tendr la parte de informacin que le interesa en su propio nodo, lo que aumenta la eficiencia en las consultas / actualizaciones, al evitar el acceso por red a otras provincias.

Si se precisa acceder a otras provincias distintas, se aumenta el tiempo de acceso (trfico de red)

Opcin 3

Cada provincia tendr toda la informacin de todas las provincias en su propio nodo, disminuyendo el tiempo de acceso.

Se aumenta el espacio de almacenamiento, de forma directamente proporcional al nmero de provincias.

Tabla 4

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

Paso 1: Realizar una consulta para separar las filas correspondientes a cada provincia, en cada una de las tablas.


41

Paso 2: Ubicar la informacin obtenida en cada uno de los nodos correspondientes a dichas provincias.

Como ejemplo, supngase que se desean ubicar las filas de las tablas alumno y profesor en el nodo provincial de Madrid. Para ello se realizar una "criba" en ambas tablas donde el campo provincia sea Madrid. La sentencia SQL que realiza se ve en el Cdigo fuente 1.

SELECT * FROM alumno WHERE provincia = "Madrid"SELECT * FROM profesor WHERE provincia = "Madrid"

Cdigo fuente 1

No se preocupe demasiado si no entiende las anteriores sentencias, ya que se vern en detalle ms adelante. Qudese simplemente con la idea de su funcionamiento, que es el de obtener de ambas tablas solamente aquellas filas que corresponden a la provincia de Madrid. De esta manera es preciso proceder para el resto de las provincias.

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

Figura 30

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


42

cod_ proveedor

cod_ cliente

cod_ material

nombre_ proveedor

nombre_ cliente

ciudad_ proveedor

ciudad_ cliente cantidad

123 113 112 Pepe Juan Sevilla Sevilla 10

128 114 118 Luis Paco Madrid Cuenca 29

837 998 128 Antonio ngel Barcelona Manresa 12

Tabla 5

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

nombre_proveedor ciudad_proveedor

Pepe Sevilla

Luis Madrid

Antonio Barcelona

Tabla 6

nombre_cliente ciudad_cliente

Juan Sevilla

Paco Cuenca

ngel Manresa

Tabla 7

cod_proveedor cod_cliente cod_material cantidad

123 113 112 10

128 114 118 29

837 998 128 12

Tabla 8


43

El resultado es que tenemos el mismo nmero de filas en todas las tablas, pero ms tablas con menos atributos. Este proceso se realiza en la reestructuracin, ya que las ventajas que ofrece estn relacionadas con la eficiencia. Entre ellas destacan:

Aumento de la concurrencia: cada vez que un usuario accede a una fila de la tabla, sta se bloquea, es decir, no puede ser accedida por otro usuario. Al dividir un tabla en ms, la concurrencia aumenta, es decir, si un usuario accede a una fila de una tabla, otro podr acceder a la misma fila en otra tabla.

Aumento de la velocidad de consulta / actualizacin: al ser las tablas ms pequeas, una consulta o actualizacin podr realizarse en un menor tiempo, ya que se necesitarn menos accesos a disco para completar la accin.

Disminucin de tiempos de consulta de informacin irrelevante: si se quiere consultar un solo atributo de una tabla, se deber acceder a toda la fila, con lo que ello supone. En cambio, al reducir el tamao de las filas, la informacin a la que accedemos tendr ms probabilidad de ser utilizada.

Por contra, la principal desventaja que tiene este mtodo es el aumento del tiempo de consulta / actualizacin si se desea acceder a dos o ms tablas. Es por ello por lo que hay que realizar un estudio pormenorizado de la probabilidad de consultas que se va a realizar. Para ello existen varios algoritmos, por ejemplo el de Navathe y Ra, en los que no entraremos, ya que escapan del objetivo del presente curso.

Por ejemplo, supngase que se dispone un esquema lgi

Manuals Ql

Documents

Transcript of Manuals Ql