Bases de Datos Cartográficas

(1)

Apuntes de

Bases de Datos

Cartográficas

Laura Sebastiá

(2)

(3)

Objetivos

El objetivo principal de esta asignatura consiste en introducir los conceptos básicos de los sistemas gestores de bases de datos actuales, por un lado, y por otro, la utilización de las extensiones para el manejo de datos espaciales que proporcionan estos sistemas como parte de un sistema de información geográfica. Para ello deberemos ser capaces de:

- entender los conceptos básicos del diseño de bases de datos - ser capaces de interpretar y criticar diseños de bases de datos

- entender los conceptos de las bases de datos espaciales y su implantación e integración en sistemas gestores de bases de datos “tradicionales”

- ser capaces de realizar consultas mediante el lenguaje SQL a una base de datos general y a una base de datos que integre datos de negocio y datos espaciales

Bibliografía

La bibliografía consultada para elaborar estos apuntes es:

- Bases de datos relacionales. Matilde Celma Giménez, Juan Carlos Casamayor

Ródenas, Laura Mota Herranz. Servicio de Publicaciones de la Universidad Politécnica de Valencia, 1997.

- Introducción a los sistemas de bases de datos. C.J. Date, Addison Wesley, 1998

- Spatial databases : with application to GIS. Philippe Rigaux, Michel Scholl, Agnés

Voisard, Morgan Kaufmann, 2002. - Manual de usuario de Oracle 8i.

(4)

(5)

Indice

Unidad temática 1: Bases de datos relacionales

Tema 1. Introducción a las bases de datos 9

Tema 2. El modelo Entidad-Relación 17

Tema 3. El modelo relacional 27

Tema 4. Teoría de la normalización 37

Unidad temática 2: Gestión de bases de datos relacionales

Tema 5. Introducción al lenguaje SQL 45 Tema 6. Lenguaje de manipulación de datos 53

Manual del SQLWorksheet 75

Práctica 1. Consultas alfanuméricas 79

Tema 7. Lenguaje de definición de datos 83

Unidad temática 3: Bases de datos espaciales

Tema 8. Modelado de datos espaciales 91 Tema 9. Gestión de datos espaciales en Oracle 8i 95 Tema 10. Consultas espaciales en Oracle 8i 101

Práctica 2. Consultas espaciales 107

(6)

(7)

UNIDAD TEMÁTICA 1

Bases de datos relacionales

Objetivos

• Comprender el concepto de SGBD

• Conocer cómo se organizan los datos alfanuméricos en una base de datos

• Ser capaces de interpretar un diagrama entidad-relación

• Ser capaces de generar un diseño de base de datos que cumpla los principios básicos del modelo relacional

Contenidos

Tema 1. Introducción a las bases de datos Tema 2. El modelo Entidad-Relación Tema 3. El modelo relacional Tema 4. Teoría de la normalización

(8)

(9)

Tema 1. Introducción a las Bases de Datos

1 Introducción

Hace unas décadas, la principal forma de sintetizar y representar información geográfica eran los mapas de papel. Desde entonces, el rápido desarrollo de nuevas tecnologías para recoger y digitalizar datos geográficos junto con una creciente demanda de manipulación y análisis interactivo de estos datos, ha dado lugar a la necesidad de software dedicado, concretamente de sistemas de información geográfica (SIG). Un SIG almacena datos geográficos, recupera y combina estos datos para crear nuevas representaciones del espacio, proporciona herramientas para realizar análisis espacial, etc. Debido al creciente volumen de los datos geográficos, una de las tareas principales de los SIG es la manipulación eficiente de grandes cantidades de información compleja. En sistemas tradicionales, esta gestión la realizan sistemas gestores de bases de datos (SGBD). La gran mayoría de estos sistemas se basan en el modelo relacional. Actualmente se están realizando esfuerzos para extender la tecnología de los SGBD de manera que sean capaces de gestionar también información geográfica. La principal ventaja de estos sistemas es que permiten al usuario manipular los datos espaciales y temáticos de forma conjunta, pudiendo construir consultas complejar relacionando ambos tipos de datos. En este tema, veremos en primer lugar, qué es un SGBD, sus objetivos y funciones. También comentaremos brevemente los distintos modelos de datos utilizados en SGBD relacionales y por último, introduciremos las bases de datos espaciales.

2 Definiciones

Una Base de datos consiste en una colección de datos persistentes e independientes usados por una organización determinada (Date, 1995).

Un Sistema de base de datos es una colección integrada de ficheros relacionados, junto con los detalles de la interpretación de los datos que contienen.

El software que gestiona el acceso a los datos contenidos en la base de datos es lo que se llama sistema de gestión de base de datos, SGBD (DBMS, Database Management System). La misión de un SGBD es proporcionar métodos eficientes para definir, almacenar y recuperar la información contenida en la base de datos.

Los SGBD se diseñan para manejar grandes cantidades de información. Esta gestión de los datos incluye tanto la definición de las estructuras para el almacenamiento como los mecanismos de acceso a los datos. Además debe cuidar la seguridad de la información almacenada en la base de datos, tanto contra las caídas del sistema como contra los intentos de acceso no autorizado. Programas de distintas aplicaciones interactúan con el SGBD y el sistema debe evitar la posibilidad de obtener resultados anómalos.

(10)

Tema 1. Introducción a las Bases de Datos

3 Objetivos de las Bases de Datos

El objetivo principal de todo sistema de base de datos es proporcionar a la organización la gestión y control centralizado de los datos.

En los sistemas de ficheros tradicionales no existía un modelo normalizado que regulase los distintos tipos de objetos que se almacenaban así como las relaciones entre ellos y la forma en que debían ser gestionados; existen por lo general múltiples ficheros y muchas aplicaciones que los gestionan, dando lugar a múltiples vías para acceder a la información. Los SGBD proporcionan un único cauce para acceder y gestionar la información, que es precisamente el que posibilita el control centralizado de toda la información al servicio de la organización. Este cauce único, además está controlado por una de las figuras esenciales en el SBD que es el administrador de la base de datos (ABD).

Los objetivos básicos de una base de datos son:

! Disminuir la redundancia de datos y evitar la inconsistencia. En los sistemas

tradicionales de almacenamiento de la información, debido a la falta de un modelo normalizado es posible que un objeto se represente en distintos ficheros. Esta redundancia aumenta los costes de almacenamiento y, lo que es peor, puede provocar inconsistencia de datos, es decir, que existan dos copias de un dato con valores diferentes. El control centralizado en los SBD permite eliminar o al menos controlar cualquier redundancia. Podemos decir que una norma básica en todo sistema de BD puede ser: un objeto se almacena una sola vez en un solo lugar.

! Hacer posible la compartición de datos. Distintos programas de aplicación pueden

estar accediendo a los mismos datos, que están almacenados en un sólo lugar para distintos fines.

! Mantener la integridad de los datos. El concepto integridad de los datos significa que

los datos almacenados en la base de datos son correctos. El control centralizado también permite la posibilidad de mantener controles que garanticen la integridad de todos los datos almacenados en la BD.

! Garantizar la seguridad de los datos. En toda organización existen datos que son

confidenciales y no pueden ser accedidos por usuarios no autorizados. El ABD debe asegurar que se siguen los procedimientos adecuados en el acceso a los datos, incluyendo esquemas de autentificación y validaciones adicionales. Los SBD permiten implantar distintos niveles de seguridad para distintos tipos de usuarios y operaciones.

Inserción

Actualización BD

Recuperación

(11)

Tema 1. Introducción a las Bases de Datos ! Proporcionar independencia de datos. Este concepto hace referencia a la necesidad

de establecer una desconexión entre los programas de aplicación y los datos almacenados. Los usuarios interactuan con una representación de los datos independientemente de la representación que estos datos tienen en los dispositivos físicos, y es el SGBD el encargado de traducir las consultas y modificaciones del usuario en operaciones eficientes sobre las estructuras de datos físicas. Esto es muy diferente del tratamiento de ficheros tradicional, donde la estructura de un fichero junto con las operaciones sobre él están embebidas en un programa de acceso.

Este mecanismo es alcanzable a través del uso de diferentes niveles de abstracción. Se distinguen tres niveles de abstracción:

- El nivel físico trabaja sobre las estructuras de almacenamiento

- El nivel lógico o conceptual define la representación de los datos propuesta por el usuario

- El nivel externo corresponde a una vista parcial de la base de datos proporcionada por una determinada aplicación.

Para ilustrar el concepto de abstracción de datos, consideremos un grupo de programas de aplicación que se utilizan en un ayuntamiento. Cada aplicación puede tener necesidad de percibir el mundo real de manera diferente. Fijemonos, por ejemplo, en el objeto PARCELA y en las aplicaciones de IMPUESTOS y AYUDAS_AGRARIAS.

La aplicación de IMPUESTOS recauda cada trimestre el impuesto correspondiente a la parcela, por lo que necesita conocer su localización y su extensión.

Por otro lado, la aplicación de AYUDAS_AGRARIAS debe conocer el tipo de cultivo de la parcela y su extensión para conceder una ayuda u otra.

Un SGBD, a diferencia de los sistemas tradicionales de ficheros, permite que los datos puedan ser compartidos por ambas aplicaciones; por ello es necesario mantener una versión de los datos que integre las distintas percepciones de los diferentes usuarios (en nuestro caso las dos aplicaciones) sobre un mismo objeto (PARCELA).

Esta visión integrada es lo que se llama visión conceptual del objeto PARCELA. Sin embargo, del mismo objeto PARCELA existen distintas visiones externas, una para cada aplicación. Los SGBD permiten la coexistencia de ambas percepciones del mismo objeto debido a que pueden deducirse a partir de la visión conceptual, sin más que realizar una adecuada transformación, que en nuestro caso no es más que ocultar los atributos innecesarios para cada aplicación. Podemos decir entonces que la visión conceptual de

un objeto es la descripción global de dicho objeto tal y como se registra en la BD. Ya

que esta descripción global no incluye detalles tales como métodos de acceso, estructura de almacenamiento de los datos, etc, los usuarios no podrán incluir estos detalles en sus aplicaciones, que es lo que se pretende. Los detalles de almacenamiento a nivel físico se describen en un nuevo nivel de abstracción que es la visión interna del objeto tal y como se almacena en el sistema de ordenador que soporta la base de datos.

En cada uno de los niveles la visión de los datos se describe mediante lo que se llama

esquema. El objetivo fundamental de esta arquitectura en tres niveles es conseguir que el

esquema conceptual sea una descripción estable de los datos de la organización e independiente de las vistas y de la forma de almacenamiento de los datos.

(12)

Tema 1. Introducción a las Bases de Datos

4 Modelos de Datos

Un modelo de datos se puede definir como un conjunto de herramientas conceptuales útiles para describir los datos, las relaciones entre ellos y la semántica asociada a los datos. Dependiendo de la fase de construcción del SBD podemos distinguir dos tipos de modelos: modelos de diseño y modelos de representación. Ambos servirán para describir los datos en los niveles conceptual y externo.

4.1 Modelos de diseño

Los modelos de diseño son herramientas para captar y describir la información del mundo real, pero no nos aportan información sobre qué tipo de estructuras se utilizarán para almacenar los datos, qué tipo de operaciones pueden realizarse sobre los mismos, etc. Estos modelos no pueden implementarse directamente en los sistemas comerciales conocidos; deben transformarse previamente en un modelo de representación. Uno de los más conocidos es el modelo entidad/relación, que veremos en el tema 2.

4.2 Modelos de representación

Los modelos de representación además de permitirnos describir los datos del mundo real cumplen otra serie de requisitos que hacen que puedan implementarse posteriormente en alguno de los sistemas comerciales conocidos (describen la implementación en alto nivel): - Aportan las estructuras necesarias para almacenar los datos.

- Imponen tipos de operaciones y la forma de llevarlas a cabo.

Diferentes modelos llevan asociados diferentes lenguajes para la definición de las estructuras de datos y la manipulación de los datos. El modelo que más se utiliza actualmente es el modelo relacional, que veremos en el tema 3. Los datos y las relaciones entre ellos se representan por medio de una serie de tablas, cada una de las cuales tiene un número de columnas con nombres únicos. Entre los SGBD relacionales comerciales podemos destacar: DB2, INGRES, ORACLE, INFORMIX y para ordenadores personales NOMAD, DBASE IV, FOXBASE, ACCESS. Otros modelos son el modelo en red y el

modelo jerárquico.

5 Facilidades del SGBD

! Proporciona el interfaz entre los datos almacenados y los programas de aplicación o

las consultas hechas al sistema. Para ello, facilita dos herramientas básicas: LDD (DDL) y LMD (DML).

! LDD es el lenguaje de definición de datos; permite definir el esquema

conceptual y aportar detalles de cómo se implementará el esquema físicamente. Esta definición incluye los objetos, los datos sobre cada objeto, las relaciones entre ellos, así como también restricciones en determinados campos etc. El resultado de la compilación de este lenguaje son las estructuras de datos y además una información sobre el esquema que se almacenará en el diccionario de

(13)

Tema 1. Introducción a las Bases de Datos datos (o catálogo); es decir, el diccionario de datos contiene metadatos, datos acerca de los datos.

! LMD es el lenguaje de manipulación de datos; permite realizar la recuperación y

actualización (inserción, actualización y borrado) de los datos almacenados en la base de datos. La primera de estas operaciones es lo que se llama normalmente query y a la parte del LMD que permite esta operación lenguaje de query; sin embargo suelen usarse indistintamente los término lenguaje de query y LMD. Puede ser procedimental, si los usuarios tienen que especificar las operaciones que desean hacer y la manera de hacerlas (BD jerárquicas y en red) o no procedimental, si el usuario sólo el indica el tipo de operación que desea hacer pero no cómo hacerla. Los comandos para hacer estas operaciones pueden usarse interactivamente o embebidos en un lenguaje de programación convencional (lenguaje huésped).

Veremos el LDD y LMD que proporciona el lenguaje SQL en la unidad temática 2. ! Interactúa con el gestor de ficheros del S.O para almacenar los datos de forma

segura y eficiente. Las diferentes sentencias LMD son traducidas a comandos de bajo nivel para gestionar ficheros; así el SGBD se encarga realmente del almacenamiento, la recuperación y actualización de la BD.

! Implanta el control de seguridad e integridad. El ABD puede haber establecido

determinadas restricciones para algunos datos (rangos, controles de seguridad, etc) y el SGBD verifica si, en algún caso, los accesos a la BD violan estas restricciones y realiza las acciones apropiadas.

! Lleva a cabo copias de seguridad y recuperación de datos. Cualquier sistema está

sujeto a fallos o errores; si se pierde la información de la BD por algún motivo, es responsabilidad del SGBD detectar estos fallos y arrancar los procedimientos de recuperación.

! Realiza el control de concurrencia. En un entorno de multiprogramación, varios

usuarios pueden estar accediendo a los datos concurrentemente; el SGBD controla las acciones de los distintos usuarios para preservar la consistencia de los datos.

Algunos SGBD, diseñados para ejecutarse en ordenadores personales pequeños, no cuentan con parte de las funciones mencionadas: por ejemplo, son monousuario, con lo que no tienen que realizar el control de concurrencia, o dejan al usuario las tareas de respaldo, recuperación y seguridad. Aunque esto puede ser aceptable para las bases de datos personales, no es de ninguna manera adecuado para cumplir con los requerimientos de una empresa de tamaño mediano o grande.

6 Ventajas y desventajas de un SGBD

Sobre las ventajas ya hemos hablado suficientemente a lo largo de este tema. Resumiendo podemos decir que un SGBD proporciona:

! Gestión y control centralizado de los datos. ! Reducción de redundancias.

(14)

Tema 1. Introducción a las Bases de Datos ! Integridad.

! Seguridad.

! Control de concurrencia.

! Independencia de datos, permitiendo cambios y crecimiento.

Con respecto a las desventajas (relacionadas sobre todo con SGBD grandes), debemos citar las siguientes:

! Coste de software y hardware: Además del coste de comprar el software,

probablemente haya que ampliar o subir de versión el hardware (upgrade) para que el programa pueda almacenarse y funcione correctamente; además, si no, el sistema podría degradarse y los tiempos de respuesta subir drásticamente por la sobrecarga que añade el SGBD al tener que implementar la seguridad, integridad y datos compartidos. Recordemos que estamos hablando de SGBD grandes, no por supuesto de los de ordenadores personales.

! Coste de migración de aplicaciones: Un coste adicional, también, es la migración de

las aplicaciones para pasar a un entorno integrado.

! Las operaciones de respaldo y recuperación de los datos en caso de fallo son

complejas, debido al acceso concurrente de múltiples usuarios.

! Criticidad del SGBD: La centralización también significa que los datos de la

organización, están almacenados en un único lugar, en la base de datos, con lo que cualquier fallo de seguridad u operación del SGBD puede afectar a toda la organización (sistemas distribuidos y compartidos) .

7 Introducción a las bases de datos espaciales

Un objeto geográfico tiene dos componentes:

! La componente espacial o geométrica, que describe la localización, forma, orientación y tamaño del objeto en el espacio 2D o 3D.

! La componente no espacial, es decir, los atributos temáticos o descriptivos.

Tradicionalmente, los datos espaciales o geodatos, han sido almacenados en bases de datos especializadas, es decir, los datos se almacenan y gestionan en una base de datos totalmente específica y dedicada a ello, donde sólo se almacenan datos espaciales para su posterior gestión y manipulación. Los datos temáticos son tratados de una manera totalmente independiente a los datos espaciales, sin existir ningún tipo de relación entre ambos tipos de datos en cuanto a su almacenamiento y gestión, por lo que se pierden las capacidades de análisis de consultas espaciales, se infrautiliza la BD, se derrocha espacio de almacenamiento, y lo que es peor, tiempo y dinero en la mala gestión de la información. Actualmente, la tecnología ha evolucionado, y con ella, ha aparecido la posibilidad del almacenamiento y la gestión conjunta de cualquier tipo de datos dentro de una misma BD, gracias a la incorporación de extensiones espaciales a los propios motores de la BD. Con ello, datos temáticos y datos espaciales pueden ser combinados en una misma consulta, aumentando así de una forma hasta ahora inimaginable, las posibilidades de nuevas

(15)

Tema 1. Introducción a las Bases de Datos consultas y aplicaciones, lo que supone una auténtica revolución en el mundo de las tecnologías SIG. Estos sistemas cambian la orientación de los SIG desde SIG céntricos a Sistemas Gestores de la Base de Datos céntricos, en los cuales, los datos espaciales son simplemente otro tipo de datos dentro del entorno del Sistema Gestor de la Base de Datos. Ejemplos de SGBD que actualmente permiten el análisis espacial integrado en la misma BD son DB2 (IBM), Informix, Oracle 8i, Sybase, etc.

El objetivo es una completa integración de los datos espaciales dentro de la BD. Para llegar a este tipo de estructuras es necesario un sistema gestor de la base de datos así como extensiones S.Q.L estandar que soporten la definición, almacenamiento, gestión y actualización de datos que poseen tanto atributos espaciales como atributos no espaciales. Un SGBD debe tener la capacidad de entender los datos y operadores espaciales y de acceder eficientemente a la base de datos espacial. Para ello necesitamos, un soporte para un tipo de datos “abstractos”, así como funciones e índices definidos por el usuario. De esta forma se consigue que los usuarios puedan ejecutar consultas integradas sobre cualquier tipo de datos (tanto espaciales como datos de negocio) usando el lenguaje S.Q.L.

El tratamiento de datos espaciales requiere una extensión de las funcionalidades del SGBD. Entre ellas podemos destacar la extensión de los métodos de almacenamiento de datos y de búsqueda de los datos implicados en una determinada consulta, del tipo de operadores utilizables en una consulta (operadores espaciales y operadores de análisis avanzado que permiten la creación de nuevas geometrías).

Ante esta revolución, como es lógico, ha surgido la necesidad del establecimiento de una normativa, para que los usuarios puedan acceder y procesar los datos desde una gran variedad de fuentes. Para ello, se crea el OGC (Open Gis Consortium) que especifica el camino que deben seguir las BD espaciales para la consecución de unos objetivos comunes con el fin de obtener la máxima eficacia en la gestión de la información.

(16)

(17)

Tema 2. El modelo Entidad-Relación

1 Introducción

El modelo Entidad-Relación fue propuesto por Chen a mediados de los años setenta como medio de representación conceptual de los problemas y para representar la visión de un sistema de forma global. Físicamente adopta la forma de un gráfico escrito en papel al que se denomina diagrama Entidad-Relación. Sus elementos fundamentales son las entidades y las relaciones.

2 Entidades

Entidad: Una entidad es una cosa u objeto distinguible de todos los demás, y tiene un

conjunto de propiedades que identifican la identidad. Ejemplo: PARCELA

Atributo: Los atributos describen propiedades que posee cada entidad, y cada atributo

tiene un conjunto de valores permitidos, llamados dominio o conjunto de valores. Ejemplo: tipo_cultivo, cuyo dominio puede ser (cítricos, viña, olivo, ...).

Los atributos se distinguen en:

- Simples y compuestos: los simples no están subdivididos en subpartes mientras que los compuestos se pueden dividir en otros atributos. Ejemplo: el atributo dirección se puede subdividir en (calle, número, piso, puerta,...)

- Univalorados y multivalorados: los univalorados tienen un solo valor para una entidad concreta y los multivalorados tienen un conjunto de valores para una entidad específica. Ejemplo: al atributo teléfono se le pueden asignar varios valores correspondiendo al teléfono particular, al del trabajo, al móvil, ...

- Nulos: se usa cuando una entidad no tiene un valor para un atributo, o el valor es desconocido.

- Derivado: el valor del atributo se puede derivar de los valores de otros atributos. Ejemplo: el atributo edad se puede derivar del atributo fecha_nacimiento.

3 Relaciones

Relación: Una relación es una asociación entre diferentes entidades. Ejemplo: las

entidades parcela y propietario se asocian a través de la relación pertenece.

Una relación puede tener también atributos descriptivos. Ejemplo: en la relación pertenece puede aparecer como atributo la fecha de adquisición.

(18)

Tema 2. El modelo Entidad-Relación

El grado de la relación es el número de entidades que participan en una relación; normalmente son relaciones binarias aunque también podemos encontrar relaciones ternarias.

Depende de la estructura del desarrollo del mundo real que se esté modelando la decisión de qué cosas consideramos como entidades y qué cosas como atributos, y tampoco hay una norma exacta para decidir si es mejor expresar un objeto mediante una entidad o mediante una relación. Una posible guía es designar una relación para describir una acción que ocurre entre entidades.

3.1 Cardinalidad de una relación

Cada entidad interviene en una relación con una determinada cardinalidad. Es decir, la cardinalidad es el número de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad relacionada. La cardinalidad se representa mediante una pareja de datos de la forma (cardinalidad mínima, cardinalidad máxima). Son posibles las siguientes cardinalidades: (0,1), (1,1), (0,n), (1,n) y (n,m).

Ejemplos:

! Las entidades nacion y ciudad participan en la relación es_capital. La entidad nacion tiene una cardinalidad (1,1) al igual que la entidad ciudad.

! Las entidades cliente y pedidos participan en la relación realiza_pedido. La entidad cliente tiene una cardinalidad (1,n) mientras que la entidad pedidos tiene una cardinalidad (1,1).

! Las entidades persona y vivienda participan en la relación vive. Ambas entidades tienen una cardinalidad (0,n).

El tipo de relación se define tomando los máximos de las cardinalidades que intervienen en la relación. Hay tres tipos posibles:

- Una a una (1:1). En este tipo de relación, una vez fijado un elemento de una entidad se conoce el elemento de la otra entidad con el que está relacionado. Por ejemplo, nación y ciudad a través de la relación es_capital.

- Una a muchas (1:N). Por ejemplo, cliente y pedidos en la relación realiza_pedido. - Muchas a muchas (N:N). Por ejemplo, personas y viviendas en la relación vive.

4 Claves

El concepto de clave permite diferenciar las entidades y relaciones individuales en términos de sus atributos. Una clave es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades. Existe un conjunto de claves candidatas, es decir, se pueden formar distintos conjuntos de atributos que identifiquen una entidad. Es decir, se puede incluir atributos innecesarios en una clave candidata, de forma que subconjuntos propios de ella no son clave. Se usa el

(19)

Tema 2. El modelo Entidad-Relación término de clave primaria para denotar una clave candidata que es elegida por el diseñador como elemento principal para identificar las entidades (preferiblemente, no debe contener atributos innecesarios).

Ejemplo: entidad Persona = {dni, num_seg_social, nombre, direccion}

Claves candidatas = { {dni, nombre}, {dni, num_seg_social}, {dni}, {num_seg_social} } Clave primaria = {dni} – También podría haberse elegido {num_seg_social}.

5 Diagrama entidad – relación

Es un gráfico en el que se representan entidades, atributos y relaciones utilizando un conjunto de símbolos:

- rectángulos: representan entidades. En el interior se escribe el nombre de la entidad representada.

- elipses: representan atributos. En el interior se escribe el nombre del atributo representado y se unen a la entidad a la que describen mediante una línea. Si este atributo pertenece a la clave primaria, se subraya. Si un atributo es multivalorado se indica mediante una “n” sobre la línea que lo une a la entidad.

- rombos: representan relaciones binarias. La cardinalidad de una relación se representa sobre el rombo de la relación. Este rombo se divide en dos y se sombrea aquella parte que corresponde a una relación N.

- líneas: unen atributos a entidades y entidades a relaciones.

Ejemplos: 1. Relación es_capital 2. Relación realiza_pedido Nacion Ciudad Es_capital Num_hab Nombre Nombre Cliente Pedido Realiza_pedido

(20)

3. Relación vive

6 Características avanzadas

6.1 Entidades fuertes y débiles

Una entidad fuerte existe por sí misma sin depender de la existencia de ninguna otra entidad. Por el contrario, la existencia de una instancia de una entidad débil depende de la existencia previa de otra entidad. Si la entidad débil puede ser identificada sin necesidad de identificar previamente la entidad de cuya existencia depende, diremos que la entidad débil lo es por existencia únicamente. Si la entidad débil no puede ser identificada independientemente, sino que previamente es necesario identificar a la entidad de cuya existencia depende, diremos que la entidad débil lo es por identificación. Es decir, esta entidad débil no tiene suficientes atributos para formar una clave primaria. Para que tenga sentido, debe formar parte de una relación uno a muchos. El discriminante (clave parcial), de una entidad débil es un conjunto de atributos que permite distinguir las entidades que dependen de una entidad particular fuerte. La clave primaria de una entidad débil se forma con la clave primaria de la entidad fuerte de cuya existencia depende, más el discriminante. La relación que asocia el conjunto de entidades débil con un propietario se llama relación

de identificación. Una entidad débil se indica con un doble rectángulo, y la

correspondiente relación de existencia mediante una “E” sobre la línea que une la entidad débil a la relación con la entidad fuerte. Si la relación es de identificación, se indicará mediante “ID”. El discriminante se subraya con una línea discontinua.

Por ejemplo, dado un libro del que se han editado muchos ejemplares, la entidad Ejemplar (que se identifica mediante un número dentro de la edición) es débil con respecto a la entidad Libro.

Persona Vivienda

Vive

DNI Nombre Direccion

Libro Ejemplar

Pertenece

ID

Numero Ubicación

(21)

6.2 Tipos especiales de relación

- Relación reflexiva: relaciona una entidad consigo misma. Ejemplo: empleados que pueden ser jefes de otros empleados.

- Dos relaciones entre las mismas entidades. Muy útil en el caso de necesitar

almacenar información histórica completa. Ejemplo: proyectos en los que trabaja actualmente un empleado y proyectos en los que ha trabajado anteriormente.

- Relación ternaria. Asociación de tres entidades. La forma de hallar cardinalidades en

las relaciones ternarias es fijar una combinación de elementos en dos de los extremos de la relación y obtener lógicamente las cardinalidades mínima y máxima en el otro extremo libre. Ejemplo: el título de un libro, un autor y una editorial se relacionan las tres mediante la acción de publicar el libro (en un año concreto, con un ISBN y con un determinado número de páginas en la edición). Para determinar las cardinalidades hay que preguntarse por:

- Cuántos autores puede tener un determinado libro publicado en una determinada editorial (cardinalidad en el extremo de la entidad autor).

- Cuántos libros puede tener un determinado autor publicados en una determinada editorial (cardinalidad en el extremo de la entidad libro).

- En cuántas editoriales puede un determinado autor publicar un mismo libro (cardinalidad en el extremo de la entidad editorial).

Empleado Es_jefe Empleado Historico Proyectos Actual

(22)

- Relación de especialización (ES-UN). Se trata de una tipificación de una entidad en

subtipos en número finito y conocido. Cada subtipo puede poseer atributos propios. Además heredan los atributos que pudiera tener la entidad general. Este tipo de relación puede clasificarse de dos maneras distintas. La primera según si una instancia o elemento concreto de la entidad puede ser de más de un subtipo a la vez. En caso afirmativo se dice que la relación es inclusiva o con solapamiento mientras que en caso contrario será exclusiva o sin solapamiento. La segunda clasificación se basa en si obligatoriamente cada instancia o elemento concreto debe ser obligatoriamente de alguno de los subtipos especificados, es decir, si no pueden existir elementos de la entidad que no pertenezcan a ninguno de los subtipos. Si es así la relación se dice

total y en caso contrario parcial. La situación más corriente en una relación de

especialización es que sea exclusiva y total. Ejemplos:

- Una entidad persona tiene los subtipos hombre y mujer. Una misma persona no puede ser hombre y mujer a la vez por lo que la relación es exclusiva. No puede existir una persona que no sea hombre ni mujer, por lo que también es total.

- La entidad universitario (representando a las personas que pertenecen a la comunidad universitaria) tiene los subtipos estudiante y profesor. Un mismo universitario puede ser ambas cosas a la vez por lo que la relación es inclusiva.

Editorial Publica Libro Autor año ISBN paginas (1,1) Persona Hombre Mujer (0,1) (0,1) (1,1)

(23)

Tema 2. El modelo Entidad-Relación Pero en la universidad también hay por ejemplo, técnicos o PAS, por lo que la relación es parcial.

La cardinalidad en las relaciones de especialización es siempre (1,1) en el extremo de la entidad que se especializa en subtipos y (0,1) en el extremo de los subtipos si la relación es exclusiva o ({0,1},1) si es inclusiva.

7 Ejercicios

Dado el siguiente diagrama entidad-relación, contestar a las siguientes preguntas:

a) ¿Cuántas poblaciones pertenecen a una misma provincia?

b) ¿Hay algún problema porque exista una población llamada Orihuela en Alicante y en Teruel? Universitario Estudiante Profesor (0,1) (0,1) (1,1) (1,1) Provincia Población Pertenece ID Nombre Num_hab Nombre Pples_ingresos Dom={agr_regadio, agr_secano, industria, turismo, …} Meses L/m2 Nombre N

(24)

c) ¿Se puede almacenar que los principales ingresos de una población provienen de la agricultura de regadío y del turismo?

d) Para una misma población, ¿cuántos datos acerca de los l/m2 recogidos podemos almacenar?

e) En un mes, ¿se puede almacenar información sobre las precipitaciones caídas en varias poblaciones?

Dadas las entidades:

- TRAMO (código_tramo)

- CALLE (código, nombre, longitud) - MANZANA (número)

- BARRIO (nombre)

1. Dibujar el diagrama E-R que expresa que:

a) un barrio está formado por muchas manzanas b) una manzana sólo pertenece a un barrio c) un tramo de una calle pertenece sólo a una calle d) una calle está compuesta de varios tramos

e) un tramo contiene varias manzanas y una manzana contiene varios tramos f) dos tramos se pueden cruzar

2. ¿Cómo se podría contestar a las siguientes preguntas? a) Calles a las que pertenece una manzana

b) Barrio al que pertenece una calle

c) Con cuántos tramos cruza un tramo en particular

3. ¿Se podría conocer la longitud de cada tramo? ¿Y la longitud total de una calle si almacenamos la longitud de cada tramo?

Se desea generar una base de datos para almacenar información respecto la geografía española. En concreto, queremos almacenar información sobre ríos, mares,

ciudades, provincias y comunidades autónomas.

- De cada ciudad queremos saber su nombre, cuántos habitantes tiene y en qué provincia se encuentra. Hay que tener en cuenta que dos ciudades de distintas provincias pueden tener el mismo nombre.

- De cada provincia, nos interesa conocer su nombre y qué ciudad es su capital.

- De cada comunidad autónoma, es interesante conocer su nombre, el número de provincias que pertenecen a ella y cuáles son estas provincias.

(25)

Tema 2. El modelo Entidad-Relación - En cuanto a cada mar, queremos almacenar su nombre y a qué provincias baña,

indicando además cuántos kilométros de la costa de esa provincia es bañada por este mar.

- La información de los ríos será la más completa: además del nombre, nos interesa conocer en qué provincia nace, por qué ciudades pasa y en qué mar desemboca. Por otro lado, también queremos saber qué ríos son afluentes de otros ríos.

(26)

(27)

Tema 3. Modelo Relacional

1 Introducción

La teoría del modelo de datos relacional fue presentada por el investigador Edgar Codd en 1970 y es el último modelo en el que se ha basado una gran familia de SGBD, imponiéndose en la década de los ochenta sobre los modelos previos. Actualmente es el modelo elegido para la construcción de casi todos los SGBD comerciales existiendo ya muchos disponibles como son ORACLE, INFORMIX, etc.

A grandes rasgos, el modelo relacional se caracteriza por disponer que: - toda la información debe estar contenida en tablas

- las relaciones entre datos deben ser representadas explícitamente en esos mismos datos

2 Estructura de las bases de datos relacionales

La relación es el elemento básico del modelo relacional y se representa por una tabla. Informalmente, los términos y sus equivalentes son:

Relación Tabla

Tupla Fila

Atributo Columna

Número de tuplas Cardinalidad Número de atributos Grado

Dominio Colección de valores, de los cuales uno o más atributos obtienen sus valores reales

Clave primaria Identificador único para la tabla, es decir, una columna o combinación de columnas con la propiedad de que nunca existen dos filas de la tabla con el mismo valor en esa columna o combinación de columnas

Es importante señalar que la tabla es plana en el sentido de que el cruce entre una fila y una columna sólo puede dar un valor, es decir, no se admiten atributos multivaluados. A cada una de las tablas se le asigna un nombre exclusivo.

(28)

Tema 3. El modelo Relacional

Desde el punto de vista de los niveles de una base de datos, la estructura de una base de datos relacional es la siguiente:

- Nivel lógico.

- Está compuesto por las distintas vistas que tienen los usuarios de la BD total - Lenguajes: DML

- Nivel físico.

- Está compuesto por las tablas que componen la BD - Lenguajes: DDL

- Nivel de almacenamiento.

- Está compuesto por los ficheros donde se almacenan las tablas del nivel anterior - Lenguajes: comandos del sistema operativo, DSDL (lenguaje de definición del

almacenamiento de datos).

3 Tablas

! Representan tanto las entidades como las relaciones del modelo E-R. ! Tienen la forma de una matriz rectangular bidimensional (filas y columnas).

! Cada elemento o casilla de la matriz es un ítem de datos elemental. Es el mínimo elemento lógico de acceso y modificación.

! Una columna representa un atributo de la entidad: ! Debe tener un nombre único en cada tabla

! Cada atributo tiene asociado un espacio de valores o dominio Nivel lógico VISTA Nivel físico Nivel de almace-namiento TABLAS FICHERO

(29)

Tema 3. El modelo Relacional ! Un valor nulo indica valor desconocido o no aplicable

! Su captura puede ser opcional (puede tomar valores nulos) u obligatoria ! Su número es fijo a priori

! Una fila o tupla representa un objeto del mundo real: ! Nunca pueden estar duplicadas

! Es la mínima unidad de borrado ! Representa un registro lógico

! Su número varía según se realicen operaciones de inserción y borrado en la tabla ! Pueden estar dispuestas en cualquier orden

3.1 Claves

Aparecen debido a la necesidad de identificar de forma unívoca y no ambigua los datos de la base de datos.

! Clave candidata: agrupación de atributos (quizás uno solo) que identifican sin

ambigüedad y de forma unívoca todas las posibles tuplas de una tabla.

! Como mínimo, una clave debe tener un atributo. Como máximo, los que tenga la tabla.

! No debe haber atributos inútiles o superfluos. La idea es que si se elimina algún atributo de la clave candidata, ya no lo es.

! Siempre hay seguro al menos una clave candidata (la agregación de todos los atributos).

! Puede haber varias claves candidatas.

! Clave primaria: se escoge de entre las claves candidatas. Usualmente se prefiere la

de menor tamaño.

! Claves alternativas: el resto de claves candidatas no escogidas como clave primaria.

! Atributo primo: aquel que forma parte de la clave primaria.

! Clave ajena: un atributo de una tabla (o agregación de ellos) puede ser clave primaria

de otra tabla.

! Mecanismo de relación y enlace de información.

! Los atributos de una clave ajena pueden o no formar parte de la clave primaria de la tabla a la que pertenecen.

(30)

4 Reducción de un esquema E-R a tablas

! Representación tabular de las entidades fuertes: una entidad fuerte se representa

mediante una tabla con varias columnas distintas cada una de las cuales corresponde a uno de los atributos de la entidad.

! Representación tabular de las entidades débiles: una entidad débil, dependiente de

una entidad fuerte, se representa mediante una tabla con una columna por cada uno de los atributos de la clave primaria de la entidad fuerte de la que depende más los atributos propios de la entidad débil.

Ejemplo:

La entidad fuerte Libro se representa mediante la siguiente tabla: Tabla: LIBRO

CP={codigo} Atr={titulo} CAj={}

La entidad débil Ejemplar se representa mediante la siguiente tabla: Tabla: EJEMPLAR

CP={numero, codigo} Atr={ubicación} CAj={codigo}

! Representación tabular de las relaciones: se representa mediante una tabla con una

columna por cada atributo formado por la unión de las claves primarias de las entidades que relaciona más los atributos descriptivos de la relación (si los tiene). ! Redundancia de tablas: en general, la tabla para la relación que une una entidad

débil con su correspondiente entidad fuerte es redundante y no necesita ser representada en una representación tabular de un diagrama E-R.

Libro Ejemplar

Pertenece

ID

Numero Ubicación

(31)

Tema 3. El modelo Relacional ! Combinación de tablas: si una entidad es dependiente de otra, se pueden

combinar para formar una única tabla consistente en la unión de las columnas de ambas tablas.

! Atributos multivalorados: para un atributo multivalorado se crea una tabla con una

columna que corresponde a la clave primaria de la entidad o de relaciones al que pertenece el atributo multivalorado.

! Representación tabular de la especialización: hay dos formas; la primera es crear

una tabla para la entidad de nivel más alto y para cada entidad de nivel más bajo, crear una tabla que incluya una columna para cada uno de los atributos de esa entidad más una columna por cada atributo de la clave primaria de la entidad de nivel más alto; la segunda, para especializaciones exclusivas y totales, se crea para cada entidad de nivel más bajo, una tabla que incluya una columna para cada atributo de la entidad más una columna por cada atributo de la entidad de nivel más alto.

4.1 Ejemplos

4.1.1 Relación realiza_pedido

En esta relación binaria participan las entidades Cliente y Pedido. Se indica que un cliente puede realizar muchos pedidos, mientras que un pedido concreto corresponde a un cliente. Ambas entidades son fuertes.

Tabla: CLIENTE CP={NIF} Atr={Nombre} CAj={} Tabla: PEDIDO CP={Numero} Atr={fecha, NIF_cliente} CAj={NIF_cliente} Cliente Pedido Realiza_pedido

(32)

En este caso, se debería haber generado una tabla para la entidad PEDIDO y otra para la relación. Sin embargo, serían redundantes y por ello se unen en una sola.

La diferencia entre la representación tabular de una entidad débil y de una relación 1:N es que, mientras en la entidad débil la clave de la entidad fuerte pasa a formar parte de la clave de la entidad débil, en el caso de relaciones 1:N, la clave de la entidad que forma parte de la relación pasa a ser un atributo de la tabla.

4.1.2 Relación es_capital

En esta relación, encontramos dos entidades (Nación y Ciudad) que se relacionan 1 a 1. Ambas son fuertes.

Tabla: NACION CP={nombre_nacion } Atr={} CAj={} Tabla: CIUDAD CP={nombre_ciudad } Atr={num_hab} CAj={} Tabla: ES_CAPITAL CP={nombre_nacion, nombre_ciudad} Atr={} CAj={nombre_nacion, nombre_ciudad}

En este caso, tenemos esta posibilidad de generar dos tablas, sobretodo si hay otras entidades con las que también se relacionan. También se podría haber generado una única tabla conteniendo todos los datos de ambas entidades.

Nacion Ciudad

Es_capital

Num_hab Nombre

(33)

4.1.3 Relación vive

En este caso, tenemos una relación muchos a muchos entre dos entidades fuertes (Persona y Vivienda). Tabla: PERSONA CP={DNI} Atr={nombre} CAj={} Tabla: VIVIENDA CP={direccion} Atr={} CAj={} Tabla: VIVE CP={DNI, direccion} Atr={} CAj={DNI, direccion}

4.2 Restricciones

El modelo relacional de datos contempla tres tipos de restricciones:

1. Integridad de la clave. Ningún atributo de una clave candidata puede tomar valores

nulos. Lógicamente, los atributos que forman la clave candidata han de tomar siempre valores distintos para cada posible tupla.

2. Integridad de referencia o referencial. Sea T1.a un atributo de la tabla T1 que forma

parte de una clave ajena para la tabla T2. Es decir, que en T2 existe un atributo

Persona Vivienda

Vive

(34)

definido con el mismo dominio, aunque no obligatoriamente con igual nombre, y que es parte de su clave primaria. Entonces, T1.a debe ser siempre igual a algún valor ya contenido en el atributo referenciado en la tabla T2, o bien tomar un valor nulo. Ejemplo: en la relación entre clientes y pedidos que realiza cada cliente, podemos encontrar las siguientes tablas:

PEDIDO CLIENTES

Numero Fecha NIF_cliente NIF Nombre

1 1/3/00 24680246 23456789 Sara Redó Corell 2 4/3/00 23456789 13579135 Marta Planells Garcia 3 5/3/00 98765432 24680246 Eduardo Garcia Algarra 4 5/3/00 01234567 98765432 Luis Tarin Paula

En este caso se produce una violación de la integridad referencial, ya que el NIF_cliente en negrita NO corresponde a ninguna tupla de la tabla de CLIENTES.

3. Otras restricciones de acuerdo con la semántica concreta del problema. Pueden ser

sencillas, como la especificación de valores mínimos o máximos que puede tomar un atributo numérico, lista de valores permitidos de un atributo, o más complejas como condiciones sobre valores de los atributos en función de valores de otros atributos de esa u otras tablas. Ejemplos:

! La restricción “el número de la Seguridad Social debe ser un entero positivo menor de 100.000.000” establece una restricción sobre el dominio del atributo.

! La restricción “el nombre de empleado siempre se ha de conocer” restringe al atributo a no tomar un valor nulo.

4.3 Problemas con las restricciones durante las operaciones

4.3.1 Inserción de una nueva tupla en una tabla

! Sólo se puede insertar una tupla si todos los atributos de la clave primaria tienen valor no nulo.

! Sólo se puede insertar una tupla si el conjunto de todos los atributos que forman la clave primaria toma un valor único e inédito hasta el momento en la tabla.

! Sólo se puede insertar una tupla si todos los atributos que son claves ajenas de otras tablas toman valores ya presentes en dichas tablas o bien nulos.

! Sólo se puede insertar una tupla si todos los valores de los atributos satisfacen todas las restricciones adicionales que pudieran concernirles.

(35)

4.3.2 Modificación del valor de algún atributo de una o varias tuplas de una tabla

! Si el atributo a modificar forma parte de la clave primaria, su valor no puede modificarse a nulo

! Si el atributo a modificar forma parte de la clave primaria, su valor no puede modificarse a otro tal que la nueva clave primaria ya no sea única en la tabla.

! Sólo puede modificarse el valor de un atributo si el nuevo valor satisface todas las restricciones adicionales que puedan afectarle.

! Si el atributo a modificar es parte de una clave ajena en otra tabla, entonces hay que modificar automáticamente el viejo valor que tomaba en dicha tabla por el nuevo valor. Por ejemplo: si el NIF de Sara Redó Corell cambia, deberá cambiar en la tabla Pedido.

4.3.3 Borrado de una o varias tuplas de una tabla.

Al borrar una tupla hay que tener en cuenta que se deben verificar las restricciones de integridad referencial. Es decir, dadas dos relaciones R y S, tal que R tiene una clave ajena CA que hace referencia a S, el borrado de una tupla de S causará una violación de la integridad referencial si existe alguna tupla de R que hace referencia a ella. En este caso, es necesario restaurar la integridad referencial y puede realizarse de dos formas, dependiendo de si existe una relación de entidad débil por existencia:

! Propagar la operación en cascada sobre las tuplas de R que hacen referencia a la tupla de S afectada. Es decir, borrar estas tuplas de R.

! Modificar a nulo el valor de la clave ajena CA de las tuplas de R que hacen referencia a la tupla de S afectada.

5 Ejercicios

Dado el siguiente diagrama entidad-relación, obtener el modelo relacional correspondiente. Provincia Población Pertenece ID Nombre Num_hab Nombre Pples_ingresos Dom={agr_regadio, agr_secano, industria, turismo, …} Meses L/m2 Nombre N

(36)

Dado el siguiente diagrama entidad-relación, obtener el modelo relacional correspondiente.

Obtener el modelo relacional correspondiente al diagrama entidad-relación del segundo ejercicio del tema anterior.

Obtener el modelo relacional correspondiente al diagrama entidad-relación del último ejercicio del tema anterior.

Personal Trabajo Realiza Aparato Numserie Modelo Utiliza Mantenimiento Alquiler Se alquila Cliente NIF Alquila Solicita DNI Nombre Num.S.S. Calibr_campo Fecha_ult_rev N.factura Fecha_ini Fecha_fin Descripción N.factura Fecha_ini Fecha_fin Descripción

(37)

Tema 4. Teoría de la normalización

1 Introducción

Cuando se diseña una base de datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales y no todos son equivalentes, ya que algunos van a representar la realidad mejor que otros. Es necesario conocer qué propiedades debe tener un esquema relacional para representar adecuadamente una realidad y cuáles son los problemas que se pueden derivar de un diseño inadecuado.

El esquema relacional puede obtenerse de dos formas distintas:

! Directamente a partir de la observación de nuestro universo del discurso, donde especificamos conjuntos de atributos, relaciones y restricciones que corresponden a los observados en el mundo real.

! Realizando el proceso de diseño en dos fases, primero el diseño conceptual (E/R) obteniendo el esquema conceptual y posteriormente transformar éste a un esquema relacional, siguiendo algunas reglas generales, que fueron dadas anteriormente.

La teoría de la Normalización es un método objetivo y riguroso que se aplica en el diseño de bases de datos relacionales y que nos permite detectar y corregir posibles errores de diseño. Algunos problemas que se pueden presentar son:

! Incapacidad para almacenar ciertos hechos

! Redundancias y por tanto, posibilidad de incoherencias ! Ambigüedades

! Pérdida de información

! Pérdida de dependencias funcionales, es decir, ciertas restricciones de integridad que dan lugar a interdependencias entre los datos.

! Aparición en la BD de estados no válidos, es decir, anomalías de inserción, borrado y modificación.

En conclusión, el esquema relacional obtenido debe ser analizado para comprobar que no presenta los problemas anteriores. Para ello, veremos en primer lugar, algunos ejemplos de anomalías que se pueden presentar. Después, introduciremos las formas normales y las aplicaremos en un ejemplo.

(38)

Tema 4. Teoría de la Normalización

2 Ejemplos de anomalías que se pueden presentar

Analicemos la siguiente relación: ESCRIBE

AUTOR NACIONALIDAD COD_LIBRO TITULO EDITORIAL AÑO

Date, C. Norteamericana 98987 Database Addison 1990 Date, C. Norteamericana 97777 SQL Stan Addison, W. 1986 Date, C. Norteamericana 98987 Guide for Addison, W. 1988 Codd,E. Norteamericana 7890 Relational Addison,W. 1990 Gardarin Francesa 12345 Basi Dati Paraninfo 1986 Gardarin Francesa 67890 Comp BD Eyrolles 1984 Valduriez Francesa 67890 Comp BD Eyrolles 1984 Kim,W. Norteamericana 11223 BD OO ACM 1989

Lochovsky Canadiense 11223 BD OO ACM 1989

Esta relación almacena datos de autores y de libros. Algunos problemas son:

! Redundancia, ya que la nacionalidad del autor se repite por cada ocurrencia del mismo. Lo mismo sucede cuando un libro tiene más de un autor, se repite la editorial y el año de publicación.

! Anomalías de modificación, es fácil cambiar el nombre de una editorial en una tupla sin modificar el resto de las que corresponden al mismo libro, lo que da lugar a incoherencias.

! Anomalías de inserción, ya que si queremos añadir información de algún autor, del que no hubiera ningún libro en la base datos, no sería posible, ya que cod_libro es parte de la clave primaria de la relación (regla de integridad de la entidad). La inserción de un libro, que tiene dos autores obliga a insertar dos tuplas en la relación.

! Anomalías de borrado, ya que si queremos eliminar un cierto libro, deberíamos perder los datos de su autor y viceversa.

En los casos anteriores, se deja en manos del usuario manejar la integridad de la base de datos.

En el ejemplo anterior, el conjunto de las siguientes relaciones no presenta estos problemas:

LIBRO( cod_libro, titulo, editorial, año ) AUTOR( nombre, nacionalidad )

(39)

ESCRIBE( cod_libro, nombre )

La normalización introduce una técnica formal para diseñar bases de datos relacionales, y permite mecanizar parte del proceso al disponer de algoritmos de normalización. Una observación importante es que las anomalías antes descritas se producen en procesos de actualización y no en procesos de consulta. La normalización penaliza las consultas, al disminuir la eficiencia, ya que la normalización aumenta el número de relaciones presentes en la base de datos, por lo que una determinada consulta puede llevar consigo el acceso a varias tablas, lo que aumenta el costo de ésta.

3 Noción intuitiva de las formas normales

La normalización tiene como objetivo obtener esquemas relacionales que cumplan determinadas condiciones, a través de las formas normales.

! Primera Forma Normal (1FN) fue introducida por Codd, en su primer trabajo. Es una restricción inherente al modelo relacional por lo que su cumplimiento es obligatorio. Consiste en la prohibición de que en una relación existan grupos repetitivos, es decir, un atributo no puede tomar más de un valor del dominio subyacente.

Si tenemos la relación AMIGO(nombre, direccion, fecha_cumpleaños, num_telefono), siendo el atributo num_telefono multivaluado, esta relación no está en 1FN. Sin embargo, este conjunto de relaciones sí está en 1FN:

AMIGO(nombre, direccion, fecha_cumpleaños) TELEFONOS(nombre, num_telefono)

! Segunda Forma Normal (2FN), fue introducida por Codd. Una relación está en 2FN, si además de estar en 1FN, todos los atributos que no forman parte de ninguna clave candidata suministran información acerca de la clave completa.

Para la relación PRESTAMO (num_socio, nombre_socio, cod_libro, fec_prest, editorial, país) las claves candidatas son:

(num_socio, cod_libro) y (nombre_socio, cod_libro)

Se puede observar que ciertos atributos que no forman parte de las claves candidatas, tal como la editorial, constituye información acerca del libro, pero no acerca de la clave completa. Luego, la relación PRESTAMO no se encuentra en 2FN.

(40)

PRESTAMO1( num_socio, nombre_socio, cod_libro, fec_prest ) LIBRO( cod_libro, editorial, país )

En la relación PRESTAMO1, el único atributo que no forma parte de las claves candidatas es fec_prest, pero suministra información acerca de la clave completa. Por lo que está en 2FN.

En la relación LIBRO, la clave es cod_libro y los dos atributos editorial y país suministran información de la clave completa. Por lo tanto, está en 2FN.

Una relación que está formada por un único atributo está en 2FN.

! Tercera Forma Normal (3FN), propuesta por Codd. Una relación está en 3FN, si además de estar en 2FN, los atributos que no forman parte de ninguna clave candidata facilitan información sólo acerca de la(s) clave(s) y no acerca de otros atributos.

En la relación PRESTAMO1, el atributo fec_prest facilita información acerca de las claves, ya que no existen más atributos. Por tanto, está en 3FN.

En la relación LIBRO, el atributo país entrega información acerca de la editorial que publica el libro, por lo que no está en 3FN.

La solución es descomponerla en:

LIBRO1( cod_libro, editorial ) EDITORIAL( editorial, país ),

que están en 3FN, ya que todo atributo no clave facilita información acerca de la clave.

! Forma Normal de Boyce y Codd (FNBC). La relación PRESTAMO1, que está en 3FN, todavía presenta anomalías, ya que num_socio y nombre_socio, se repiten innecesariamente por cada cod_libro. Una relación está en FNBC si y solo si, todos los atributos de las claves candidatas informan acerca del resto de claves candidatas completas.

En la relación PRESTAMO1, num_socio es información acerca de nombre_socio y viceversa. Ninguno de estos atributos son clave (aunque formen parte de la clave). Para solucionarlo la descomponemos:

SOCIO( num_socio, nombre_socio )

PRESTAMO2( num_socio, cod_libro, fec_prest ),

que están en FNBC.

Hasta ahora nuestro esquema relacional está compuesto por las siguientes relaciones en FNBC:

(41)

LIBRO1( cod_libro, editorial ) EDITORIAL( editorial, país ) SOCIO( num_socio, nombre_socio )

PRESTAMO2( num_socio, cod_libro, fec_prest )

La teoría de la normalización se basa en restricciones definidas sobre los atributos de una relación. que son conocidas como dependencias funcionales, relacionadas con la 2FN y

3FN y FNBC. Sean a y b atributos de una misma tabla o relación T. Se dice que b es

funcionalmente dependiente de a y se denota como T.a->T.b si todo posible valor de a tiene asociado un único valor de b, es decir, en todas las tuplas de T en las que el atributo a toma el mismo valor v1, el atributo b toma también un mismo valor v2.

4 Ejercicios

Dada la relación R(estudiante, nro_matricula, curso, centro, profesor, texto) con las siguientes restricciones:

a) Un estudiante puede estar matriculado de varios cursos

b) Un estudiante tiene un número de matricula distinto para cada curso en el que está matriculado

c) Un curso se imparte en un solo centro

d) El número de matricula identifica al centro en el que se imparte el curso y al curso mismo

e) Un curso es impartido por un solo profesor, pero un profesor puede impartir varios cursos

f) Un curso de apoya en distintos textos y un mismo texto puede servir de soporte a varios cursos

Reducir el esquema anterior a un conjunto equivalente de relaciones en FNBC

(42)

(43)

Unidad temática 2:

Gestión de Bases de Datos

Relacionales

Objetivos

- Conocer las principales características del lenguaje SQL

- Ser capaces de realizar consultas sobre datos alfanuméricos utilizando SQL - Ser capaces de crear tablas sencillas con SQL

Contenidos

Tema 5. Introducción al lenguaje SQL Tema 6. Lenguaje de manipulación de datos Tema 7. Lenguaje de definición de datos

(44)

(45)

Tema 5: Introducción al lenguaje SQL

1 Introducción

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por muchos sistemas de bases de datos relacionales. Sus principales características son las siguientes:

- SQL es un lenguaje declarativo, es decir, el usuario expresa el resultado que desea obtener sin especificar cómo el sistema debe operar para calcular este resultado. El lenguaje es sencillo y es accesible a usuarios no expertos.

- SQL se basa en fundamentos matemáticos. El conjunto de operaciones que se pueden realizar con los datos están definidas por dos lenguajes formales equivalentes: el cálculo relacional y el álgebra relacional.

- La simplicidad de SQL presenta un inconveniente que consiste en que, en ocasiones, su expresividad no es suficiente para obtener el resultado que el usuario desea.

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos. En este tema veremos estos elementos de forma general para profundizar en ellos en los próximos temas.

2 Comandos

Existen dos tipos de comandos SQL:

• los DDL (Data Definition Language) o LDD que permiten crear y definir nuevas bases de datos, campos e índices.

• los DML (Data Manipulation Language) o LMD que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Los comandos DDL son:

Comando Descripción

CREATE Utilizado para crear nuevas tablas, campos e índices DROP Empleado para eliminar tablas e índices

ALTER Utilizado para modificar las tablas agregando campos o cambiando su definición

(46)

Tema 5. Introducción al lenguaje SQL

Los comandos DML se resumen en:

Comando Descripción

SELECT Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado

INSERT Utilizado para insertar nuevos datos en la base de datos

UPDATE Utilizado para modificar los valores de los campos y registros especificados DELETE Utilizado para eliminar registros de una tabla de una base de datos

3 Cláusulas

Las cláusulas son condiciones de modificación utilizadas en los comandos para definir los datos que se desea seleccionar o manipular. Un resumen de las clausulas disponibles en SQL son:

Cláusula Descripción

FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros

WHERE Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar

GROUP BY Utilizada para separar los registros seleccionados en grupos específicos HAVING Utilizada para expresar la condición que debe satisfacer cada grupo

ORDER BY Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

4 Operadores Lógicos

Los operadores lógicos que se pueden utilizar en las cláusulas son:

Operador Uso

AND Es el "y" lógico. Evalua dos condiciones y devuelve verdadero sólo si ambas son ciertas.

OR Es el "o" lógico. Evalúa dos condiciones y devuelve verdadero si alguna de las dos es cierta.

(47)

5 Operadores de Comparación

Los operadores de comparación son:

Operador Uso

< Menor que > Mayor que <> Distinto de <= Menor o Igual que >= Mayor o Igual que

= Igual que

BETWEEN Utilizado para especificar un intervalo de valores. LIKE Utilizado en la comparación de un modelo

IN Utilizado para especificar registros de una base de datos

6 Funciones de Agregado

Las funciones de agregado se usan dentro de una cláusula SELECT donde se han agrupado los registros para devolver un único valor por cada grupo de registros. Las más usuales son:

Función Descripción

AVG Utilizada para calcular el promedio de los valores de un campo determinado COUNT Utilizada para devolver el número de registros de la selección

SUM Utilizada para devolver la suma de todos los valores de un campo determinado

MAX Utilizada para devolver el valor más alto de un campo especificado MIN Utilizada para devolver el valor más bajo de un campo especificado

7 Esquema a utilizar

En este apartado daremos la definición de las tablas a utilizar, tanto en los ejemplos de los próximos temas como en las prácticas de laboratorio. Este esquema está compuesto por 7 tablas que representan una zona rural con dos lagos y tres municipios, en los que se encuentran diversas casas rurales y servicios como hospital, supermercados, etc., todo ello

(48)

comunicado a través de distintas carreteras. A continuación se presenta un croquis de la región a la que se refieren los datos de la base de datos:

Seguidamente, se muestra la descripción de las tablas, que también podemos obtener mediante el comando DESCRIBE <nombre_tabla>.

• Tabla CASA_RURAL

Nombre de Columna ¿Nulo? Tipo

-

----CODIGO NOT NULL CHAR(10) Clave primaria

DUENYO NOT NULL VARCHAR2(40)

DIRECCION NOT NULL VARCHAR2(30)

TELEFONO NOT NULL VARCHAR2(9)

EMAIL VARCHAR2(30)

PRECIO NOT NULL NUMBER(4,2)

FECHA_CONSTRUCCION NOT NULL DATE

FECHA_REHABILITACION DATE

MUNICIPIO NOT NULL CHAR(10) Clave ajena->MUNICIPIO

DESCRIPCION VARCHAR2(100)

C1

C2

C3

C4

C5

Lago Abis

Lago Bernacle

Abis

Abiside

Bernacle

(49)

LOCALIZACION MDSYS.GEOMETRY

CODIGO es un identificador de cada casa. DUENYO almacena el nombre del dueño de la casa. DIRECCION indica la dirección de la casa. TELEFONO y EMAIL son los puntos de contacto para poder realizar una reserva. PRECIO indica lo que cuesta el alquiler de la casa completa. FECHA_CONSTRUCCION y FECHA_REHABILITACION son las fechas de construcción y de la última rehabilitación (si ha lugar) de la casa. MUNICIPIO es el código del municipio donde está la casa. DESCRIPCION almacena las características de la casa, como por ejemplo, la disponibilidad de garaje, cocina totalmente equipada, etc. Por último, LOCALIZACION indica las coordenadas de la casa.

Es importante comentar el hecho de que en esta tabla se ha representado su relación con el municipio donde se encuentra cada casa de forma explícita, a través de una clave ajena. También podría extraerse esta relación a través de una consulta de tipo espacial, como se hará, por ejemplo, para saber si una carretera pasa por un municipio.

• Tabla HABITACION

-

NUM_PLAZAS NOT NULL NUMBER(2)

BANYO NOT NULL CHAR(1) IN ('S','N')

PRECIO_NOCHE NOT NULL NUMBER(4,2)

PRECIO_DTO_3 NUMBER(4,2)

COD_CASA NOT NULL CHAR(10) Clave primaria

Clave ajena->CASA_RURAL

CODIGO es el identificador de cada habitación dentro de la casa COD_CASA. NUM_PLAZAS indica el número de plazas de esta habitación. BANYO indica si la habitación tiene baño ('S') o no ('N'). PRECIO_NOCHE da el precio de esta habitación por noche y PRECIO_DTO_3 indica el precio en el caso de que la estancia supere los tres días. DESCRIPCION, como en el caso anterior, almacena las características de una habitación.

• Tabla MUNICIPIO

-

CODIGO_POSTAL NOT NULL NUMBER(5)

(50)

GEOMETRIA MDSYS.GEOMETRY

CODIGO es el identificador de cada municipio. CODIGO_POSTAL indica su código postal y NOMBRE, su nombre. GEOMETRIA describe un polígono que representa al municipio.

• Tabla TIPO_SERVICIO

-

----TIPO NOT NULL CHAR(15) Clave primaria

Esta tabla recoge los servicios que puedan resultar necesarios. Por ejemplo, supermercado, centro de salud, hospital, farmacia, etc. A cada uno de ellos, se le asigna un código.

• Tabla SERVICIO

----CODIGO NOT NULL NUMBER(3)

TIPO CHAR(15) Clave ajena->TIPO_SERVICIO

LOCALIZACION MDSYS.GEOMETRY

Indica el tipo (TIPO) y descripción (DESCRIPCION) de un servicio, así como sus coordenadas (LOCALIZACION).

• Tabla CARRETERA

--

----CODIGO NOT NULL CHAR(10)

GEOMETRIA MDSYS.GEOMETRY

Indica el código de carretera y su descripción (CODIGO y DESCRIPCION) así como un conjunto de líneas que representan su geometría (GEOMETRIA).