Apuntes BDC PDF

Apuntes de
Bases de Datos
Cartográficas
Laura Sebastiá
Departamento de Sistemas Informáticos y Computación
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.
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
Práctica 3. Manipulación de la base de datos 111
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
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.
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).
Inserción Recuperación
Actualización BD Tratamiento
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.
10
! 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.
11
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
12
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.
! Compartición de datos.
13
! 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
14
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.
15
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.
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
18
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
Nacion Ciudad
Es_capital
Nombre Num_hab Nombre
2. Relación realiza_pedido
Realiza_pedido
Cliente Pedido
NIF Nombre Fecha Numero
19
3. Relación vive
Persona Vivienda
Vive
DNI Nombre Direccion
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.
Pertenece
Libro Ejemplar
ID
Codigo Titulo Numero Ubicación
20
6.2 Tipos especiales de relación
- Relación reflexiva: relaciona una entidad consigo misma. Ejemplo: empleados que
pueden ser jefes de otros empleados.
Es_jefe
Empleado
- 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.
Proyectos
Actual Historico
Empleado
- 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).
21
Libro Autor
paginas
año
ISBN
Publica
Editorial
- 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.
Persona
(0,1) (0,1)
(1,1) (1,1)
Hombre Mujer
- 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.
22
Pero en la universidad también hay por ejemplo, técnicos o PAS, por lo que la
relación es parcial.
Universitario
(0,1) (0,1)
(1,1) (1,1)
Estudiante Profesor
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:
Dom={agr_regadio, agr_secano,
Pertenece industria, turismo, …}
Provincia Población N
Pples_ingresos
ID
Nombre Nombre Num_hab
L/m2
Nombre
Meses
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?
23
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.
24
- 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.
25
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.
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).
VISTA
Nivel
lógico
Nivel
físico TABLAS
Nivel de
almace-
namiento
FICHERO
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
28
! 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.
! En una tabla no es obligatoria la existencia de claves ajenas.
29
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:
Pertenece
Libro Ejemplar
ID
Codigo Titulo Numero Ubicación
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.
30
! 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.
Realiza_pedido
Cliente Pedido
NIF Nombre Fecha Numero
Tabla: CLIENTE
CP={NIF}
Atr={Nombre}
CAj={}
Tabla: PEDIDO
CP={Numero}
Atr={fecha, NIF_cliente}
CAj={NIF_cliente}
31
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.
Nacion Ciudad
Es_capital
Nombre Num_hab Nombre
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.
32
4.1.3 Relación vive

En este caso, tenemos una relación muchos a muchos entre dos entidades fuertes
(Persona y Vivienda).
Persona Vivienda
Vive
DNI Nombre Direccion
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
33
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.
34
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.
Dom={agr_regadio, agr_secano,
Pertenece industria, turismo, …}
Provincia Población N
Pples_ingresos
ID
Nombre Nombre Num_hab
L/m2
Nombre
Meses
35
Dado el siguiente diagrama entidad-relación, obtener el modelo relacional

correspondiente.
DNI
Nombre
Num.S.S. N.factura
Calibr_campo Fecha_ini
Fecha_fin
Descripción
Realiza
Personal Trabajo
Solicita
Mantenimiento
NIF
Utiliza
Fecha_ult_rev
Aparato Cliente
Numserie
Modelo
Se alquila
Alquila
N.factura
Fecha_ini
Fecha_fin
Alquiler
Descripción
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.
36
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.
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 )
38
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.
La solución es descomponer esta relación en las siguientes:
39
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:
40
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
Comprobar si los modelos relacionales generados en el tema 3 están en FNBC.
41
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
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
Los comandos DML se resumen en:

Comando Descripción
Utilizado para consultar registros de la base de datos que satisfagan un
SELECT
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
Utilizada para especificar la tabla de la cual se van a seleccionar los
FROM
registros
Utilizada para especificar las condiciones que deben reunir los registros que
WHERE
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
Utilizada para ordenar los registros seleccionados de acuerdo con un orden
ORDER BY
específico
4 Operadores Lógicos
Los operadores lógicos que se pueden utilizar en las cláusulas son:

Operador Uso
Es el "y" lógico. Evalua dos condiciones y devuelve verdadero sólo si
AND
ambas son ciertas.
Es el "o" lógico. Evalúa dos condiciones y devuelve verdadero si alguna de
OR
las dos es cierta.
NOT Negación lógica. Devuelve el valor contrario de la expresión.
46
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
Utilizada para devolver la suma de todos los valores de un campo
SUM
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
47
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:
Lago Abis C2
Abis
C1
C3
Abiside Lago Bernacle

C5
C4
Bernacle
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)
48
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)
NOMBRE NOT NULL VARCHAR2(30)
49
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)
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).
50
• Tabla LAGO
------------------------------ -------- ----
CODIGO NOT NULL CHAR(10)
Indica el código de lago y su descripción (CODIGO y DESCRIPCION) así como un polígono

que representa su geometría (GEOMETRIA).
En el anexo I se listan todos los datos que contienen las tablas.
51
Tema 6: Lenguaje de Manipulación de Datos
1 Introducción
El lenguaje de manipulación de datos comprende las consultas de selección y las

operaciones de inserción, borrado y modificación de datos de las tablas.
Las consultas de selección se utilizan para indicar al motor de datos que devuelva
información de las bases de datos. Esta información es devuelta en forma de conjunto de
registros.
Las consultas de acción son aquellas que no devuelven ningún registro, son las encargadas
de acciones como añadir y borrar y modificar registros.
2 Consultas de selección
2.1 Consultas básicas

La sintaxis básica de una consulta de selección es la siguiente:
SELECT Campos
FROM Tabla;
donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los
mismos. Por ejemplo:
SELECT duenyo, telefono
FROM casa_rural;
Esta consulta devuelve un conjunto de registros con el campo duenyo y teléfono de la
tabla casa_rural.
2.2 Ordenar los registros

Adicionalmente se puede especificar el orden en que se desean recuperar los registros de
las tablas mediante la claúsula ORDER BY Lista de Campos, donde Lista de campos
representa los campos a ordenar. Ejemplo:
SELECT duenyo, direccion, telefono
FROM casa_rural
ORDER BY duenyo;
Esta consulta devuelve los campos duenyo, direccion, telefono de la tabla
casa_rural ordenados por el campo duenyo.
Tema 6. Lenguaje de Manipulación de Datos
Se pueden ordenar los registros por más de un campo, como por ejemplo:
FROM casa_rural
ORDER BY duenyo, precio;
Incluso se puede especificar el orden de los registros: ascendente mediante la claúsula
(ASC -se toma este valor por defecto) ó descendente (DESC)
FROM casa_rural
ORDER BY duenyo ASC, precio DESC;
2.3 Consultas con Predicado

El predicado se incluye entre la claúsula y el primer nombre del campo a recuperar, los
posibles predicados son:
Predicado Descripción
ALL Devuelve todos los campos de la tabla
TOP Devuelve un determinado número de registros de la tabla
DISTINCT Omite los registros cuyos campos seleccionados coincidan totalmente
2.3.1 ALL
Si no se incluye ninguno de los predicados se asume ALL. Se seleccionan todos los
registros que cumplen las condiciones de la instrucción SQL. No es conveniente abusar de
este predicado ya que obligamos al motor de la base de datos a analizar la estructura de la
tabla para averiguar los campos que contiene, es mucho más rápido indicar el listado de
campos deseados.
SELECT ALL FROM habitacion;
SELECT * FROM habitacion;
2.3.2 TOP
Devuelve un cierto número de registros a partir del principio o del final de un rango
especificado por una cláusula ORDER BY. Supongamos que queremos recuperar los
dueños de las 5 casas más caras:
SELECT TOP 5 duenyo
FROM casa_rural
ORDER BY precio DESC;
54
Si no se incluye la cláusula ORDER BY, la consulta devolverá un conjunto arbitrario de 25
registros de la tabla casa_rural. El predicado TOP no elige entre valores iguales. En el
ejemplo anterior, si la casa número 5 y la 6 tienen el mismo precio, la consulta devolverá 6
registros. Se puede utilizar la palabra reservada PERCENT para devolver un cierto
porcentaje de registros que caen al principio o al final de un rango especificado por la
cláusula ORDER BY. Supongamos que en lugar de las 5 casas más caras deseamos el 10
por ciento de las casas:
SELECT TOP 10 PERCENT duenyo
FROM casa_rural
ORDER BY precio DESC;
El valor que va a continuación de TOP debe ser un entero sin signo.
2.3.3 DISTINCT
Omite los registros que contienen datos duplicados en los campos seleccionados. Para que
los valores de cada campo listado en la instrucción SELECT se incluyan en la consulta
deben ser únicos.
Por ejemplo, varias casas de la tabla casa_rural pueden tener el mismo dueño. Si
ejecutamos la siguiente instrucción SQL, devolverá un único registro por cada dueño
diferente:
SELECT DISTINCT duenyo
FROM casa_rural;
En otras palabras, el predicado DISTINCT devuelve aquellos registros cuyos campos
indicados en la cláusula SELECT posean un contenido diferente.
2.4 Alias
En determinadas circunstancias es necesario asignar un nombre a alguna columna
determinada del resultado de una consulta. Para ello, podemos utilizar la palabra reservada
AS que se encarga de asignar el nombre que deseamos a la columna indicada. Tomando
como referencia el ejemplo anterior podemos hacer que la columna devuelta por la
consulta, en lugar de llamarse duenyo (igual que el campo devuelto) se llame Persona de
contacto. En este caso procederíamos de la siguiente forma:
SELECT DISTINCT duenyo AS “Persona de contacto”
FROM casa_rural;
Se consigue el mismo efecto utilizando la siguiente consulta:
SELECT DISTINCT duenyo “Persona de contacto”
FROM casa_rural;
55
2.5 Criterios de Selección

En el apartado anterior se vio la forma de recuperar registros de las tablas. Sin embargo, se
devolvían todos los registros de la mencionada tabla. A lo largo de este apartado se
estudiarán las posibilidades de filtrar los registros con el fin de recuperar solamente
aquellos que cumplan unas condiciones preestablecidas.
Antes de comenzar el desarrollo de este apartado hay que recalcar que:
! cada vez que se desee establecer una condición referida a un campo de texto la
condición de búsqueda debe ir encerrada entre comillas simples; se tiene en cuenta la
diferencia entre mayúsculas y minúsculas
! las fechas se deben escribir siempre en formato dd/mm/aa donde dd representa el día,
mm el mes y aa el año, se puede utilizar la barra (/) o el guión (-) y además la fecha
debe ir encerrada entre comillas simples (‘). Por ejemplo si deseamos referirnos al día
3 de Septiembre de 1995 deberemos hacerlo de la siguiente forma; ‘09-03-95’ ó ‘9-3-
95’ ó ‘9/3/95’.
2.5.1 La cláusula WHERE

La cláusula WHERE puede usarse para determinar qué registros de las tablas enumeradas
en la cláusula FROM aparecerán en los resultados de la instrucción SELECT. Después de
escribir esta cláusula se deben especificar las condiciones que se expondrán en los
apartados siguientes. Si no se emplea esta cláusula, la consulta devolverá todas las filas de
la tabla. WHERE es opcional, pero cuando aparece debe ir a continuación de FROM.
2.5.2 Operadores de comparación

Como ya comentamos, los operadores de comparación disponibles en SQL son: =, <, >, <=,
>=, <> (distinto). Veamos algunos ejemplos:
Obtener el dueño y el precio de las casas que valgan menos de 300
euros
SELECT duenyo, precio
FROM casa_rural
WHERE precio < 300;
Obtener el código de las casas y el código de las habitaciones que

tengan más de dos plazas
SELECT cod_casa, codigo
FROM habitacion
WHERE num_plazas > 2;
Obtener el dueño y la dirección de las casas cuya fecha de

construcción sea posterior a 01/10/1994
SELECT duenyo, direccion
56
FROM casa_rural
WHERE fecha_construccion > ‘01/10/94’;
Obtener el código de la casa y de las habitaciones que tengan baño

SELECT cod_casa, codigo
FROM habitacion
WHERE banyo = 'S';
2.5.3 Operadores Lógicos

Los operadores lógicos soportados por SQL son, entre otros: AND, OR, NOT. A excepción
de NOT todos poseen la siguiente sintaxis:
<expresión1> operador <expresión2>
donde expresión1 y expresión2 son las condiciones a evaluar. El resultado de la operación
varía en función del operador lógico. La tabla adjunta muestra los diferentes posibles
resultados para AND y OR:
<expresión1> Operador <expresión2> Resultado
Verdad AND Falso Falso

Verdad AND Verdad Verdad
Falso AND Verdad Falso
Falso AND Falso Falso
Verdad OR Falso Verdad
Verdad OR Verdad Verdad
Falso OR Verdad Verdad
Falso OR Falso Falso
Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado

de la operación será el contrario al devuelto sin el operador NOT. Veamos algunos
ejemplos.
Obtener el código de las casas cuyo precio oscila entre 200 y 300
euros
SELECT codigo
FROM casa_rural
WHERE precio > 200 AND precio < 300;
57
Obtener el código de las casas cuyo precio oscila entre 200 y 300
euros o su fecha de construcción es posterior al año 1994.
SELECT codigo
FROM casa_rural
WHERE (precio > 200 AND precio < 300) OR
fecha_construccion >= ‘01/01/95’;
Obtener todos los datos de los tipo de servicio diferentes a

Supermercado.
SELECT *
FROM tipo_servicio
WHERE NOT descripcion=’Supermercado’;
Obtener todos los datos de las habitaciones cuyo precio por noche
esté entre 50 y 60 euros o cuyo precio con descuento esté entre 40 y
50 euros.
SELECT *
FROM habitacion
WHERE (precio_noche > 50 AND precio_noche < 60) OR
(precio_dto_3 > 40 AND precio_dto_3 < 50);
2.5.4 Intervalos de Valores

Para indicar que deseamos recuperar los registros según el intervalo de valores de un
campo emplearemos el operador Between cuya sintaxis es:
campo [Not] Between valor1 And valor2 (la condición Not es opcional)
En este caso la consulta devolvería los registros que contengan en "campo" un valor
incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condición Not
devolverá aquellos valores no incluidos en el intervalo. Veamos algunos ejemplos:
Obtener las casas cuyo precio oscila entre 200 y 300 euros
SELECT codigo
FROM casa_rural
WHERE precio BETWEEN 200 AND 300;
Obtener el nombre y el código postal de los municipios cuyo nombre

está entre Ab y As
58
SELECT nombre, codigo_postal
FROM municipio
WHERE nombre BETWEEN ‘Ab’ AND ‘As’;
Obtener las casas cuya fecha de construcción oscila entre los años
1989 y 1992
SELECT codigo
FROM casa_rural
WHERE fecha_construccion BETWEEN ‘01/01/89’ AND ‘31/12/92’;
2.5.5 El Operador Like

Se utiliza para comparar una expresión de cadena con un modelo en una expresión SQL.
Su sintaxis es:
expresión Like modelo
donde expresión es un campo y modelo es una cadena contra la que se compara
expresión. Se puede utilizar el operador Like para encontrar valores en los campos que
coincidan con el modelo especificado. Por modelo puede especificar un valor completo (Ana
María), o se pueden utilizar caracteres comodín como los reconocidos por el sistema
operativo para encontrar un rango de valores (Like An%).
El operador Like se puede utilizar en una expresión para comparar un valor de un campo
con una expresión de cadena. Por ejemplo, si introduce Like C% en una consulta SQL, la
consulta devuelve todos los valores de campo que comiencen por la letra C.
El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido de cualquier
letra entre A y F y de tres dígitos:
Like 'P[A-F]###'
Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la A a la D
seguidas de cualquier cadena.
Like '[A-D]%'
En la tabla siguiente se muestra cómo utilizar el operador Like para comparar expresiones
con diferentes modelos.
Tipo de coincidencia Modelo Planteado Coincide No coincide

Varios caracteres 'a%a' 'aa', 'aBa', 'aBBBa' 'aBC'
Carácter especial 'a[%]a' 'a%a' 'aaa'
Varios caracteres 'ab%' 'abcdefg', 'abc' 'cab', 'aab'
Un solo carácter 'a?a' 'aaa', 'a3a', 'aBa' 'aBBBa'
Un solo dígito 'a#a' 'a0a', 'a1a', 'a2a' 'aaa', 'a10a'
59
Rango de caracteres '[a-z]' 'f', 'p', 'j' '2', '&'

Fuera de un rango '[!a-z]' '9', '&', '%' 'b', 'a'
Distinto de un dígito '[!0-9]' 'A', 'a', '&', '~' '0', '1', '9'
Combinada 'a[!b-m]#' 'An9', 'az0', 'a99' 'abc', 'aj0'
Obtener el dueño de las casas que disponen de frigorifico

SELECT duenyo
FROM casa_rural
WHERE descripcion LIKE '%frigorifico%';
2.5.6 El Operador In
Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de los
incluidos en una lista. Su sintaxis es:
expresión [Not] In(valor1, valor2, . . .)
Por ejemplo, la siguiente consulta devuelve el nombre de los municipios cuyo código postal
pertenezca al conjunto {99991, 99993}:
SELECT nombre
FROM municipio
WHERE codigo_postal IN (99991, 99993);
2.6 Agrupamiento de Registros
2.6.1 GROUP BY
Combina los registros con valores idénticos en la lista de campos especificados, en un
único registro. Para cada registro se crea un valor sumario si se incluye una función SQL
agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo
GROUP BY es opcional. Los valores de resumen se omiten si no existe una función SQL
agregada en la instrucción SELECT. Los valores Null en los campos GROUP BY se
agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de las
funciones SQL agregadas.
Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la cláusula
HAVING para filtrar los registros una vez agrupados.
Un campo de la lista de campos GROUP BY puede referirse a cualquier campo de las
tablas que aparecen en la cláusula FROM, incluso si el campo no esta incluido en la
instrucción SELECT, siempre y cuando la instrucción SELECT incluya al menos una función
SQL agregada.
60
Todos los campos de la lista de campos de SELECT deben incluirse en la cláusula GROUP
BY o como argumentos de una función SQL agregada. Por ejemplo, la siguiente consulta
obtiene para cada casa, el número total de plazas de todas sus habitaciones:
SELECT cod_casa, SUM(num_plazas)
FROM habitacion
GROUP BY cod_casa;
Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro
agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING.
HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los
registros se han agrupado utilizando GROUP BY, HAVING determina cuáles de ellos se van
a mostrar. Por ejemplo, la siguiente consulta obtiene los mismos datos que la consulta
anterior, pero sólo de aquellas casas en las que haya al menos 6 plazas y el máximo a
pagar por noche de una habitación sean 90 euros:
FROM habitacion
GROUP BY cod_casa
HAVING SUM(num_plazas) > 6 AND MAX(precio_noche)<90;
2.6.2 AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo especificado
de una consulta. Su sintaxis es la siguiente
Avg(expr)
donde expr representa el campo que contiene los datos numéricos para los que se desea
calcular la media o una expresión que realiza un cálculo utilizando los datos de dicho
campo. La media calculada por Avg es la media aritmética (la suma de los valores dividido
por el número de valores). La función Avg no incluye ningún campo Null en el cálculo. Por
ejemplo, la siguiente consulta calcula el precio medio de las casas rurales:
SELECT AVG(precio) AS Promedio
FROM casa_rural;
2.6.3 COUNT
Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente
Count(expr)
donde expr contiene el nombre del campo que desea contar. Puede contar cualquier tipo
de datos incluso texto. Aunque expr puede realizar un cálculo sobre un campo, Count
simplemente cuenta el número de registros sin tener en cuenta qué valores se almacenan
en los registros. La función Count no cuenta los registros que tienen campos null a menos
que expr sea el carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el
número total de registros, incluyendo aquellos que contienen campos null.
61
Por ejemplo, la siguiente consulta obtiene el número total de casas rurales existentes en la
base de datos:
SELECT Count(*) AS Total
FROM casa_rural;
2.6.4 MAX, MIN

Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo
especifico de una consulta. Su sintaxis es:
Min(expr)
Max(expr)
donde expr es el campo sobre el que se desea realizar el cálculo. Veamos un par de
ejemplos.
Obtener el precio mínimo de las casas cuya fecha de construcción es

anterior al año 1994.
SELECT MIN(precio) AS “El Minimo”
FROM casa_rural
WHERE fecha_construccion < ‘01/01/94’;
Obtener el precio máximo de las casas cuya fecha de construcción es

anterior al año 1994.
SELECT MAX(precio) AS “El Maximo”
FROM casa_rural
2.6.5 SUM
Devuelve la suma del conjunto de valores contenido en un campo especifico de una
consulta. Su sintaxis es:
Sum(expr)
donde expr representa el nombre del campo que contiene los datos que desean sumarse o
una expresión que realiza un cálculo utilizando los datos de dichos campos. Por ejemplo, la
siguiente consulta obtiene para cada casa, el número total de plazas de todas sus
habitaciones:
FROM habitacion
GROUP BY cod_casa;
62
2.6.6 StDev, StDevP
Devuelve estimaciones de la desviación estándar para la población (el total de los registros
de la tabla) o una muestra de la población representada (muestra aleatoria) . Su sintaxis es:
StDev(expr)
StDevP(expr)
donde expr representa el nombre del campo que contiene los datos que desean evaluarse
o una expresión que realiza un cálculo utilizando los datos de dichos campos.
StDevP evalúa una población, y StDev evalúa una muestra de la población. Si la consulta
contiene menos de dos registros (o ningún registro para StDevP), estas funciones
devuelven un valor Null (el cual indica que la desviación estándar no puede calcularse). Por
ejemplo:
SELECT StDev(precio) AS Desviacion
FROM casa_rural
SELECT StDevP(precio) AS Desviacion

FROM casa_rural
2.6.7 Var, VarP

Devuelve una estimación de la varianza de una población (sobre el total de los registros) o
una muestra de la población (muestra aleatoria de registros) sobre los valores de un campo.
Su sintaxis es:
Var(expr)
VarP(expr)
VarP evalúa una población, y Var evalúa una muestra de la población. Expr es el nombre
del campo que contiene los datos que desean evaluarse o una expresión que realiza un
cálculo utilizando los datos de dichos campos. Si la consulta contiene menos de dos
registros, Var y VarP devuelven Null (esto indica que la varianza no puede calcularse).
Puede utilizar Var y VarP en una expresión de consulta o en una Instrucción SQL. Por
ejemplo:
SELECT Var(precio) AS Desviacion
FROM casa_rural
SELECT VarP(precio) AS Desviacion

FROM casa_rural
63
2.7 Consultas sobre más de una tabla
Normalmente los datos que se desean extraer a través de una consulta no están en una
única tabla. En estos casos, hemos de incluir en la cláusula FROM todas las tablas de las
que deseamos extraer algún dato. Por ejemplo, si quisiéramos obtener para cada casa su
código, su dirección y el municipio donde se encuentran, deberíamos escribir:
SELECT casa_rural.codigo, direccion, nombre
FROM casa_rural, municipio;
Se debe indicar que el código es de la casa rural porque existe otro campo código en la
tabla municipio y podría resultar ambiguo. La ejecución de esta consulta nos devuelve la
siguiente información:
CODIGO DIRECCION NOMBRE
---------- ------------------------------ ------------------------------
1001 Monje 27 Abis
1001 Monje 27 Abiside
1001 Monje 27 Bernacle
2001 Fca Almadraba,Almendro Blanco Abis
2001 Fca Almadraba,Almendro Blanco Abiside
2001 Fca Almadraba,Almendro Blanco Bernacle
2002 Mayor 18 Abis
2002 Mayor 18 Abiside
2002 Mayor 18 Bernacle
...
Se observa que cada casa aparece tres veces, una vez con cada municipio. Esto es debido
a que cuando se ponen dos tablas en la cláusula FROM se une cada fila de la primera tabla
con cada fila de la segunda tabla. Para obtener la consulta correcta, se debe indicar en la
cláusula WHERE la relación existente entre ambas tablas a través de sus claves ajenas. En
este caso, la tabla casa_rural tiene una clave ajena sobre la tabla municipio. Por tanto, la
consulta correcta sería:
SELECT casa_rural.codigo, direccion, nombre
FROM casa_rural, municipio
WHERE casa_rural.municipio = municipio.codigo;
Así, obtendríamos los siguientes datos:
---------- ------------------------------ ------------------------------
1001 Monje 27 Abis
...
Cuando se utilizan varias tablas, es frecuente que haya nombres de campos repetidos en
ellas. Hemos visto que la solución pasa por escribir delante del campo en cuestión el
nombre de la tabla a la que pertenece, lo que en ocasiones puede resultar tedioso,
64
sobretodo si los nombres de las tablas son largos. Por esta razón, se suelen utilizar alias
para reducir el nombre de las tablas. Por ejemplo:
SELECT c.codigo, direccion, nombre
FROM casa_rural c, municipio m
WHERE c.municipio = m.codigo;
2.8 Consultas de Unión Externas
Se utiliza la operación UNION para crear una consulta de unión, combinando los resultados
de dos o más consultas o tablas independientes. Su sintaxis es:
[TABLE] consulta1 UNION [ALL] [TABLE] consulta2
[UNION [ALL] [TABLE] consultan [ ... ]]
donde consulta1, consulta2, consultan son instrucciones SELECT, el nombre de una
consulta almacenada o el nombre de una tabla almacenada precedido por la palabra clave
TABLE.
Puede combinar los resultados de dos o más consultas, tablas e instrucciones SELECT, en
cualquier orden, en una única operación UNION. El ejemplo siguiente combina una tabla
existente llamada Otras_casas_lujo y una instrucción SELECT:
TABLE Otras_casas_lujo
UNION ALL
SELECT * FROM casa_rural
WHERE precio > 100;
Si no se indica lo contrario, no se devuelven registros duplicados cuando se utiliza la
operación UNION, no obstante puede incluir el predicado ALL para asegurar que se
devuelven todos los registros. Esto hace que la consulta se ejecute más rápidamente.
Todas las consultas en una operación UNION deben pedir el mismo número de campos, no
obstante los campos no tienen porqué tener el mismo tamaño o el mismo tipo de datos.
Se puede utilizar una cláusula GROUP BY y/o HAVING en cada argumento consulta para
agrupar los datos devueltos. Puede utilizar una cláusula ORDER BY al final del último
argumento consulta para visualizar los datos devueltos en un orden específico.
3 SubConsultas
Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT,
SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta.
Puede utilizar tres formas de sintaxis para crear una subconsulta:
- comparación [ANY | ALL | SOME] (instrucción sql)
65
- expresión [NOT] IN (instrucción sql)
- [NOT] EXISTS (instrucción sql)
donde:
! comparación: es una expresión y un operador de comparación que compara la
expresión con el resultado de la subconsulta.
! expresión: es una expresión por la que se busca el conjunto resultante de la
subconsulta.
! instrucción sql: es una instrucción SELECT, que sigue el mismo formato y reglas que
cualquier otra instrucción SELECT. Debe ir entre paréntesis.
Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos de una
instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta, se utiliza
una instrucción SELECT para proporcionar un conjunto de uno o más valores especificados
para evaluar en la expresión de la cláusula WHERE o HAVING.
3.1 ANY, SOME

Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para recuperar
registros de la consulta principal, que satisfagan la comparación con cualquier otro registro
recuperado en la subconsulta. El ejemplo siguiente devuelve el código de todas las casas
rurales en las que hay una habitación cuyo precio sea mayor que el precio total de cualquier
casa cuya fecha de construcción sea posterior al año 1992:
SELECT DISTINCT cod_casa
FROM habitacion
WHERE precio_noche > ANY (SELECT precio
FROM casa_rural
WHERE fecha_construccion >= ‘01/01/1993’);
3.2 ALL
El predicado ALL se utiliza para recuperar únicamente aquellos registros de la consulta
principal que satisfacen la comparación con todos los registros recuperados en la
subconsulta. Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolverá
únicamente aquellas casas en las que haya una habitación cuyo precio sea mayor que el de
todas las casas construidas después de 1992. Esto es mucho más restrictivo.
3.3 IN
El predicado IN se emplea para recuperar únicamente aquellos registros de la consulta
principal para los que algunos registros de la subconsulta contienen un valor igual. El
ejemplo siguiente obtiene el nombre del dueño de las casas que tienen alguna habitación
con baño:
SELECT duenyo
FROM casa_rural
WHERE codigo IN (SELECT cod_casa
66
FROM habitacion
WHERE banyo='S');
Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos registros de la

consulta principal para los que no hay ningún registro de la subconsulta que contenga un
valor igual.
3.4 EXISTS
El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en comparaciones
de verdad/falso para determinar si la subconsulta devuelve algún registro.
Se puede utilizar también el alias del nombre de la tabla en una subconsulta para referirse a
tablas listadas en la cláusula FROM fuera de la subconsulta. El ejemplo siguiente
corresponde a la misma consulta anterior:
SELECT duenyo
FROM casa_rural c
WHERE EXISTS (SELECT cod_casa
FROM habitacion
WHERE banyo='S' AND cod_casa=c.codigo);
3.5 Ejemplos
Obtener el código de la casa (ordenado y sin repetir) de las
habitaciones cuyo precio por noche sea mayor de 90 euros
FROM habitacion
WHERE precio_noche>90
ORDER BY cod_casa;
Obtener el código de la casa y de la habitación de todas las

habitaciones con baño
FROM habitacion
WHERE banyo='S'
ORDER BY cod_casa;
Obtener el nombre del dueño de las casas construidas antes de 1990

SELECT duenyo
67
FROM casa_rural
WHERE fecha_construccion<'01/01/90';
Obtener el código de la casa y la suma del precio de todas sus

habitaciones
SELECT cod_casa, SUM(precio_noche) as Suma
FROM habitacion
GROUP BY cod_casa;
Obtener el código de la casa y la media del número de plazas de

todas sus habitaciones
SELECT cod_casa, AVG(num_plazas) AS Media
FROM habitacion
GROUP BY cod_casa;

todas sus habitaciones con baño
SELECT cod_casa, AVG(num_plazas) AS media
FROM habitacion
WHERE banyo='S'
GROUP BY cod_casa;

todas sus habitaciones con baño, de las casas cuya dicha media
supera el 3
SELECT cod_casa, AVG(num_plazas) AS Media
FROM habitacion
WHERE banyo='S'
GROUP BY cod_casa
HAVING AVG(num_plazas)>3;
Obtener el código y la descripción de todos los servicios junto con

la descripcion de su tipo
SELECT s.codigo, s.descripcion, t.descripcion
FROM servicio s, tipo_servicio t
WHERE s.tipo=t.tipo;
68
Obtener el código de las casas de los municipios que empiezan por

‘A’
SELECT codigo
FROM casa_rural
WHERE municipio IN (SELECT codigo
FROM municipio
WHERE nombre LIKE 'A%')
ORDER BY codigo;
Obtener la dirección y el teléfono de contacto de las casas que

tienen habitaciones con capacidad para más de 3 personas
SELECT direccion, telefono
FROM casa_rural
WHERE codigo IN (SELECT cod_casa
FROM habitacion
WHERE num_plazas>3);
Obtener el dueño, el precio y el código postal de las casas que

valgan menos de 300 euros
SELECT duenyo, precio, codigo_postal
WHERE c.municipio=m.codigo AND
precio<300;
Obtener el código de las casas y el código de las habitaciones que

tengan más de dos plazas y cuya fecha de construcción sea posterior
al año 1993
SELECT cod_casa, h.codigo
FROM casa_rural c, habitacion h
WHERE c.codigo=h.cod_casa AND
num_plazas > 2 AND
fecha_construccion > ‘1/1/94’;
Obtener el código, el dueño, la dirección con el nombre del

municipio de las casas cuyo precio oscila entre 200 y 300 euros o su
fecha de construcción es posterior al año 1994.
69
SELECT c.codigo, duenyo, direccion, m.nombre
WHERE c.municipio=m.codigo AND
((precio > 200 AND precio < 300) OR
fecha_construccion >= ‘01/01/95’);
Obtener el código y el total de plazas de las casas en las que haya

al menos 6 plazas, frigorífico y el máximo a pagar por noche en una
habitación sean 120 euros.
FROM casa_rural c, habitacion h
WHERE c.codigo=h.cod_casa AND
c.descripcion LIKE ‘%frigorifico%’
GROUP BY cod_casa
HAVING SUM(num_plazas) > 6 AND MAX(precio_noche)<120;
Obtener el nombre del dueño de las casas que tienen frigorífico y

alguna habitación con baño
SELECT duenyo
FROM casa_rural
WHERE descripcion LIKE ‘%frigorifico%’ AND
codigo IN (SELECT cod_casa
FROM habitacion
WHERE banyo='S');
Obtener el nombre del dueño de las casas tales que todas las
habitaciones valgan menos de 60 euros.
SELECT duenyo
FROM casa_rural c
WHERE NOT EXISTS (SELECT cod_casa
FROM habitacion
WHERE precio_noche > 60 AND
cod_casa=c.codigo);
70
4 Consultas de Acción
4.1 DELETE
Crea una consulta de eliminación que elimina los registros de una o más de las tablas
listadas en la cláusula FROM que satisfagan la cláusula WHERE. Su sintaxis es:
DELETE FROM Tabla WHERE criterio
Ejemplo: Con la siguiente instrucción, eliminamos de la tabla
casa_rural aquellas casas en las que el dueño se llama Manuel
delete from casa_rural
where duenyo like 'Manuel%';
DELETE es especialmente útil cuando se desea eliminar varios registros. Si desea eliminar
todos los registros de una tabla, eliminar la propia tabla es más eficiente que ejecutar una
consulta de borrado.
Una consulta de borrado elimina los registros completos, no únicamente los datos en
campos específicos. Si desea eliminar valores en un campo especificado, crear una
consulta de actualización que cambie los valores a Null.
Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede
deshacer la operación. Para saber qué registros se eliminarán, primero se pueden examinar
los resultados de una consulta de selección que utilice el mismo criterio y después ejecutar
la consulta de borrado.
4.2 INSERT INTO

Agrega un registro en una tabla. Se la conoce como una consulta de datos añadidos. Esta
consulta puede ser de dos tipos: insertar un único registro o insertar en una tabla los
registros contenidos en otra tabla.
4.2.1 Para insertar un único registro:

En este caso la sintaxis es la siguiente:
INSERT INTO Tabla (campo1, campo2, .., campoN)
VALUES (valor1, valor2, ..., valorN)
Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así sucesivamente.
Hay que prestar especial atención a acotar entre comillas simples (') los valores literales
(cadenas de caracteres) y las fechas que además hay que indicar en formato dd-mm-aa.
Cuando no se especifica valor para un campo, se inserta el valor predeterminado o Null.
Los registros se agregan al final de la tabla.
Ejemplos:
71
INSERT INTO casa_rural values (1001 , 'Manuel Martinez Garcia',
'Monje 27', '927561119', 'caminoreal@retemail.com', 80000,
'20/12/98', NULL, 1, 'comedor,desayuno y cena opcional');
INSERT INTO topo1.municipio values (2, 29610, 'Ojen', 29);
INSERT INTO topo1.serv_casa values (1001, 1, 0.3);
4.2.2 Para insertar registros de otra tabla:

En este caso la sintaxis es:
INSERT INTO Tabla [IN base_externa] (campo1, campo2, ..., campoN)
SELECT TablaOrigen.campo1, ..., TablaOrigen.campoN
FROM TablaOrigen
En este caso se seleccionarán los campos 1,2, ..., n de la tabla origen y se grabarán en los
campos 1,2,.., n de la Tabla. La condición SELECT puede incluir la cláusula WHERE para
filtrar los registros a copiar. Si Tabla y TablaOrigen poseen la misma estrucutra podemos
simplificar la sintaxis a:
INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen
De esta forma los campos de TablaOrigen se grabarán en Tabla, para realizar esta
operación es necesario que todos los campos de TablaOrigen estén contenidos con igual
nombre en Tabla. Con otras palabras que Tabla posea todos los campos de TablaOrigen
(igual nombre e igual tipo).
Por ejemplo: si quisiéramos generar una tabla de casas rurales “de lujo” utilizaríamos:
INSERT INTO casa_rural_lujo
SELECT casa_rural.* FROM casa_rural WHERE precio>600;
4.3 UPDATE
Crea una consulta de actualización que cambia los valores de los campos de una tabla
especificada basándose en un criterio específico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, ... CampoN=ValorN
WHERE Criterio;
UPDATE es especialmente útil cuando se desea cambiar un gran número de registros o
cuando éstos se encuentran en múltiples tablas. Puede cambiar varios campos a la vez. El
ejemplo siguiente incrementa los valores del campo Precio_Noche en un 10 por ciento y los
valores del campo Precio_Dto_3 en un 3 por ciento para las habitaciones que tienen baño:
UPDATE Habitacion
SET Precio_Noche = Precio_Noche * 1.1,
Precio_Dto_3 = Precio_Dto_3 * 1.03
WHERE banyo = 'S';
72
UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar, hay que
examinar primero el resultado de una consulta de selección que utilice el mismo criterio y
después ejecutar la consulta de actualización.
Si en una consulta de actualización suprimimos la cláusula WHERE todos los registros de la
tabla señalada serán actualizados.
UPDATE Habitacion
SET Precio_Noche = Precio_Noche * 1.1,
Precio_Dto_3 = Precio_Dto_3 * 1.03;
5 Ejercicios
5.1 Consultas básicas
1. Obtener el código de la casa (ordenado y sin repetir) de las habitaciones cuyo precio
por noche sea mayor de 15000
COD_CASA
----------
1001
2001
2002
3001
3002
5003
2. Obtener el código de la casa y de la habitación de todas las habitaciones con baño

COD_CASA
----------
1001
2001
2002
2003
3002
5001
5002
5003
73
3. Obtener el nombre del dueño de las casas construidas antes de 1990

DUENYO
----------------------------------------
Manuel Martinez Garcia
Vicenta Duque Moreira
Ricardo Olmos Garcia
Rodrigo Gracia Andres
5.2 Consultas con agrupamiento de registros
4. Obtener el código de la casa y la suma del precio de todas sus habitaciones

COD_CASA SUMA
---------- ----------
1001 68000
2001 37000
2002 70000
2003 48000
3001 36000
3002 34000
5001 32000
5002 17000
5003 49000
5. Obtener el código de la casa y la media del número de plazas de todas sus

habitaciones
COD_CASA MEDIA
---------- ----------
1001 2,5
2001 1,66666667
2002 4
2003 2
3001 4
3002 2,66666667
74
5001 2,66666667
5002 2
5003 2,5

habitaciones con baño
COD_CASA MEDIA
---------- ----------
1001 2,66666667
2001 2
2002 4
2003 2
3002 4
5001 2,66666667
5002 2
5003 2,66666667

habitaciones con baño, de las casas cuya dicha media supera el 3.
COD_CASA MEDIA
---------- ----------
2002 4
3002 4
5.3 Consultas de unión de tablas
8. Obtener el código, dirección y nombre del municipio de todas las casas

---------- ------------------------------ --------------------------
1001 Monje 27 Abis
3001 Plz Calixto III Bernacle
5001 La Barra 30 Abis
5002 Plz La Iglesia 5 Abis
75
5003 Alta 7 Abis
3002 Sta Ana 20 Bernacle
9. Obtener el código y la descripción de todos los servicios junto con la descripcion de su

tipo.
CODIGO DESCRIPCION DESCRIPCION
---------- ----------------------------------- ---------------------
1 Ultramarinos Peña Supermercado
2 Garcia Comestibles Supermercado
3 Tienda Martinez Supermercado
4 Hospital de Abis Hospital
5 Farmacia Abis Farmacia
6 Ambulancias Montes Ambulancia
7 Centro de Salud de Bernacle Centro de Salud
8 Comestibles Mora Supermercado
5.4 Consultas con subconsultas
10. Obtener el nombre del dueño de las casas que tienen alguna habitación con baño
DUENYO
----------------------------------------
Amalia Gomez Tormes
Monica Fernandez Gil
76
11. Obtener el código de las casas de los municipios que empiezan por ‘A’
CODIGO
----------
1001
2001
2002
2003
5001
5002
5003
12. Obtener la dirección y el teléfono de contacto de las casas que tienen habitaciones con
capacidad para más de 3 personas
DIRECCION TELEFONO
------------------------------ ---------
Monje 27 927561119
Mayor 18 695672356
Plz Calixto III 902209900
Sta Ana 20 656723322
La Barra 30 962523689
Alta 7 603457689
77
Manual del SQLWorksheet
1 Introducción
ORACLE es un sistema gestor de bases de datos relacionales. Actualmente acaba de

lanzar su versión 9, pero utilizaremos la versión 8.1 en las prácticas.
En este sistema, no existe el concepto de esquema de base de datos tal y como lo hemos
entendido hasta ahora, sino que, asociado a cada usuario definido en el sistema, se crea
una base de datos en la que se almacenarán todos los objetos (tablas, vistas,
procedimientos, etc.) creados por él.
En el sistema ORACLE pueden definirse los siguientes objetos del estándar SQL:
relaciones básicas, vistas y privilegios de acceso. Además, pueden definirse algunos
detalles relativos a la representación interna de los datos (índices, tablespace, cluster, etc.);
disparadores para modelar comportamiento activo (triggers), así como elementos de
programación (funciones y procedimientos, paquetes de procedimientos, etc.).
Está compuesto por varios módulos. Los que utilizaremos en las sesiones de prácticas son
la aplicación Schema Manager, para la gestión de tablas (se verá en prácticas posteriores)
y SQL worksheet, para la ejecución de sentencias SQL.
2 SQL Worksheet
Se trata de una herramienta que nos permite ejecutar sentencias SQL de forma interactiva.
Mantiene un historial de los comandos introducidos, de forma que podemos utilizar esta
aplicación para editar y ejecutar de nuevo un comando anterior sin tener que teclearlo otra
vez. Es posible tener varias SQL Worksheet abiertas al mismo tiempo, cada una es
independiente de las otras.
SQL Worksheet se encuentra en Inicio -> Oracle Enterprise Manager -> SQL Worksheet.
Inmediatamente aparece un cuadro de diálogo para conectarse a la base de datos. Los
datos a introducir son: username (topo2, por ejemplo), password (topo2) y service (topo).
Una vez se valida con el servidor, entramos en la aplicación, que consta de los siguientes
elementos (ver figura):
• Panel de entrada: en la parte inferior de la pantalla, nos permite introducir los
comandos SQL a ejecutar.
• Panel de salida: situado en la parte superior de la pantalla, muestra el resultado de la
ejecución de dicha sentencia.
• Barra de división: divide ambos paneles, si se pincha y arrastra sobre ella se puede
modificar el tamaño de éstos.
• Barra de herramientas del panel de entrada
• Nueva worksheet: borra el panel de entrada para introducir una nueva sentencia SQL,
si no había sido guardado, indica la posibilidad de hacerlo.
• Abrir worksheet: muestra un cuadro de diálogo para abrir una sentencia SQL
almacenada previamente.
• Guardar worksheet: muestra un cuadro de diálogo para guardar el contenido del panel
de entrada.
• Ejecutar: ejecuta el comando SQL presente en el panel de entrada.
• Historial de comandos: muestra una ventana con las sentencias ejecutadas
últimamente y permite recuperar una (botón Get) para ser editada.
• Comando anterior y Siguiente comando: permiten la navegación por el historial de
comandos.
• Barra de herramientas del panel de salida: sólo tiene un botón, que nos permite
guardar la información del panel de salida en un fichero.
• Menús desplegables: aparecen en la parte superior de la pantalla. Sus principales
funciones se resumen a continuación.
2.1 Menú File

• Change Database Connection: Muestra el cuadro de diálogo de conexión a una
instancia de una base de datos.
80
• New, Open, Save: Realizan las mismas funciones que los botones de la barra del panel
de entrada.
• Save As: Guarda el contenido del panel de entrada en un fichero distinto del que está
abierto actualmente.
• Print: Imprime el contenido del panel de entrada.
• Save Output As: Guarda el contenido del panel de salida en un fichero.
• Print Output: Imprime el contenido del panel de salida.
• Print Setup: Muestra el cuadro de diálogo de configuración de la impresión.
• Exit: Sale de SQL Worksheet.
2.2 Menú Edit

Realiza las funciones habituales en el panel activo.
2.3 Menú Worksheet

• Execute: Ejecuta el comando del panel de entrada.
• Run Script: Permite la selección y ejecución de un script.
• Spool: Escribe dinámicamente la salida en un fichero.
• Command History, Previous Command y Next Command: Realizan las mismas
funciones que los botones del panel de entrada.
81
Práctica 1. Consultas alfanuméricas
Consiste en realizar las consultas que se proponen a continuación. Deben aparecer los
mismos títulos de columnas y los datos en el mismo orden.
1. Código y descripción de todas las carreteras de la región que van al sur (es decir, que
en su descripción aparece la palabra ‘Sur’).
CODIGO DESCRIPCION
---------- --------------------------------------------------
C1 Carretera 1 - Noreste-Suroeste
C2 Carretera 2 - Norte-Sur
C5 Carretera 5 - Este-(Norte-Sur)
2. Supermercados de todos los municipios.

CODIGO DESCRIPCION
---------- --------------------------------------------------
1 Ultramarinos Peña
2 Garcia Comestibles
3 Tienda Martinez
8 Comestibles Mora
3. Nombre del dueño y dirección completa (con el nombre del municipio) de todas las
casas rurales de la región, ordenado por el nombre del municipio.
DUENYO DIRECCION MUNICIPIO
----------------------- ------------------------------ -------------
Manuel Martinez Garcia Monje 27 Abis
Vicenta Duque Moreira La Barra 30 Abis
Vicenta Duque Moreira Plz La Iglesia 5 Abis
Ricardo Olmos Garcia Alta 7 Abis
Amalia Gomez Tormes Fca Almadraba,Almendro Blanco Abiside
Monica Fernandez Gil Mayor 18 Abiside
Monica Fernandez Gil Mayor 16 Abiside
Amparo Molins Lopez Plz Calixto III Bernacle
Rodrigo Gracia Andres Sta Ana 20 Bernacle
4. Precio medio de las casas que hayan sido construidas o rehabilitadas después del año
90.
MEDIA
----------
39285,7143
5. Precio de la habitación más cara de cada casa ordenado por código de casa.
CODIGO MAX_HABIT
---------- ----------
1001 24000
2001 16000
2002 25000
2003 12000
3001 18000
3002 16000
5001 14000
5002 10000
5003 20000
6. Código de la casa y diferencia de precio entre alquilar una casa completa y alquilarla
por habitaciones (sin descuentos) ordenado por código de casa.
CODIGO DIFERENCIA
---------- ----------
1001 8000
2001 2000
2002 6000
2003 8000
3001 3000
3002 4000
5001 4000
5002 2000
5003 6000
7. Código, dirección y total de plazas de las casas en las que caben al menos 10
personas en total.
CODIGO DIRECCION TOTAL
---------- ------------------------------ ----------
1001 Monje 27 10
2002 Mayor 18 12
5003 Alta 7 10
8. Nombre del dueño de las casas que tienen TV en todas las habitaciones.
DUENYO
----------------------------------------
84
9. Código y dirección de las casas en las que hay al menos 8 plazas en habitaciones con
baño.
CODIGO DIRECCION
---------- ------------------------------
1001 Monje 27
2002 Mayor 18
2003 Mayor 16
5001 La Barra 30
5003 Alta 7
85
Tema 7: Lenguaje de Definición de Datos
1 Tipos de Datos
Los tipos de datos SQL se clasifican en 12 tipos de datos primarios:
Tipo de Datos Longitud Descripción

Para consultas sobre tabla adjunta de productos de bases
BINARY 1 byte
de datos que definen un tipo de datos Binario.
BIT 1 byte Valores Si/No ó True/False
BYTE 1 byte Un valor entero entre 0 y 255.
COUNTER 4 bytes Un número incrementado automáticamente (de tipo Long)
Un entero escalable entre 922.337.203.685.477,5808 y
CURRENCY 8 bytes
922.337.203.685.477,5807.
DATETIME 8 bytes Un valor de fecha u hora entre los años 100 y 9999.
Un valor en punto flotante de precisión simple con un
38 -45
rango de -3.402823*10 a -1.401298*10 para valores
SINGLE 4 bytes -45 38
negativos, 1.401298*10 a 3.402823*10 para valores
positivos, y 0.
Un valor en punto flotante de doble precisión con un rango
308 -324
de -1.79769313486232*10 a -4.94065645841247*10
DOUBLE 8 bytes -324
para valores negativos, 4.94065645841247*10 a
308
1.79769313486232*10 para valores positivos, y 0.
SHORT 2 bytes Un entero corto entre -32,768 y 32,767.
LONG 4 bytes Un entero largo entre -2,147,483,648 y 2,147,483,647.
1 byte por
TEXT De cero a 255 caracteres.
caracter
1 byte por
LONGTEXT De cero a un máximo de 1.2 gigabytes.
carácter
2 Estructuras de las Tablas
2.1 Creación de Tablas Nuevas
La sintaxis de la instrucción para crear bases de datos es:

CREATE TABLE tabla (campo1 tipo (tamaño) índice1 ,
campo2 tipo (tamaño) índice2 , ...,
índice multicampo , ... )
donde:
Parte Descripción
tabla Es el nombre de la tabla que se va a crear.
campo1 Es el nombre del campo o de los campos que se van a crear en la nueva
campo2 tabla. La nueva tabla debe contener, al menos, un campo.
tipo Es el tipo de datos de campo en la nueva tabla. (Ver Tipos de Datos)
tamaño Es el tamaño del campo sólo se aplica para campos de tipo texto.
índice1 Es una cláusula CONSTRAINT que define el tipo de indice a crear. Esta
índice2 cláusula en opcional.
Es una cláusula CONSTRAINT que define el tipo de índice multicampos a
índice
crear. Un índice multi campo es aquel que está indexado por el contenido
multicampos
de varios campos. Esta cláusula en opcional.
2.2 La cláusula CONSTRAINT
Se utiliza la cláusula CONSTRAINT en las instrucciones ALTER TABLE y CREATE TABLE

para crear o eliminar índices. Existen dos sintaxis para esta cláusula dependiendo si desea
crear o eliminar un índice de un único campo o si se trata de un campo multiíndice.
Para los índices de campos únicos:
CONSTRAINT nombre {PRIMARY KEY |
UNIQUE |
REFERENCES tabla_externa [(campo externo1,
campo externo2,...)]}
Para los índices de campos múltiples:
CONSTRAINT nombre {PRIMARY KEY (primario1[, primario2 [, ...]]) |
UNIQUE (único1[, único2 [, ...]]) |
FOREIGN KEY (ref1[, ref2 [, ...]])
REFERENCES tabla_externa [(campo_externo1...)]}
Parte Descripción
nombre Es el nombre del índice que se va a crear.
primarioN Es el nombre del campo o de los campos que forman el índice primario.
88
Es el nombre del campo o de los campos que forman el índice de clave

únicoN
única.
Es el nombre del campo o de los campos que forman el índice externo
refN
(hacen referencia a campos de otra tabla).
Es el nombre de la tabla que contiene el campo o los campos
tabla externa
referenciados en refN
campos Es el nombre del campo o de los campos de la tabla externa especificados
externos por ref1, ref2, ..., refN
Si se desea crear un índice para un campo cuando se esta utilizando las instrucciones
ALTER TABLE o CREATE TABLE la cláusula CONTRAINT debe aparecer inmediatamente
después de la especificación del campo indexado.
Si se desea crear un índice con múltiples campos cuando se está utilizando las
instrucciones ALTER TABLE o CREATE TABLE la cláusula CONSTRAINT debe aparecer
fuera de la cláusula de creación de tabla.
Tipo de índice Descripción

Genera un índice de clave única. lo que implica que los registros de la
UNIQUE
tabla no pueden contener el mismo valor en los campos indexados.
Genera un índice primario el campo o los campos especificados. Todos
PRIMARY KEY los campos de la clave principal deben ser únicos y no nulos, cada
tabla sólo puede contener una única clave principal.
Genera un índice externo (toma como valor del índice campos
contenidos en otras tablas). Si la clave principal de la tabla externa
consta de más de un campo, se debe utilizar una definición de índice
de múltiples campos, listando todos los campos de referencia, el
FOREIGN KEY
nombre de la tabla externa, y los nombres de los campos referenciados
en la tabla externa en el mismo orden que los campos de referencia
listados. Si los campos referenciados son la clave principal de la tabla
externa, no tiene que especificar los campos referenciados.
Ejemplos:
Crear una nueva tabla llamada Casa_rural con los campos que hemos
definido anteriormente. Además, indica que la clave primaria es el
campo CODIGO y establece una clave ajena sobre el campo MUNICIPIO al
campo CODIGO de la tabla Municipio.
CREATE TABLE casa_rural
( codigo char(10) not null,
duenyo varchar2(40) not null,
direccion varchar2(30) not null,
telefono varchar2(9) not null,
89
email varchar2(30) null,
precio number(4,2) not null,
fecha_construccion date not null,
fecha_rehabilitacion date null,
municipio char(10) not null,
descripcion varchar2(100),
CONSTRAINT primaria PRIMARY KEY (codigo),
FOREIGN KEY (municipio) REFERENCES municipio(codigo));
Crear una nueva tabla Habitacion con los campos definidos

anteriormente. Se define una clave primaria con dos campos: codigo,
cod_casa. Se define una clave ajena sobre el campo cod_casa que
referencia al campo codigo de la tabla casa_rural. Se define una
restricción de valor: el campo banyo debe tomar valores en el
conjunto (‘S’,’N’).
create table habitacion
num_plazas number(2) not null,
banyo char(1) not null,
precio_noche number(6) not null,
precio_dto_3 number(6),
descripcion varchar2(100),
cod_casa char(10) not null,
primary key (codigo, cod_casa),
foreign key (cod_casa) references casa_rural(codigo),
constraint dom_banyo check (banyo in ('S','N')));
2.3 Creación de Índices
La sintaxis para crear un índice en una tabla ya definida en la siguiente:

CREATE [UNIQUE] INDEX índice ON tabla
(campo [ASC|DESC][, campo [ASC|DESC], ...])
[WITH { PRIMARY | DISALLOW NULL | IGNORE NULL }]
Donde:
90
Parte Descripción
índice Es el nombre del índice a crear.
tabla Es el nombre de una tabla existentes en la que se creará el índice.
campo Es el nombre del campo o lista de campos que consituyen el índice.
Indica el orden de los valores de lso campos ASC indica un orden
ASC|DESC
ascendente (valor predeterminado) y DESC un orden descendente.
UNIQUE Indica que el indice no puede contener valores duplicados.
DISALLOW
Prohibe valores nulos en el índice
NULL
IGNORE Excluye del índice los valores nulos incluidos en los campos que lo
NULL componen.
Asigna al índice la categoría de clave principal, en cada tabla sólo puede
PRIMARY existir un único indice que sea "Clave Principal". Si un índice es clave
principal implica que que no puede contener valores nulos ni duplicados.
Ejemplos:
Crea un índice llamado MiIndice en la tabla Casa_rural con los
campos Duenyo y Telefono.
CREATE INDEX MiIndice ON Casa_rural (Duenyo, Telefono);
Crea un índice en la tabla Casa_rural utilizando el campo CODIGO,

obligando que el campo CODIGO no contenga valores nulos ni
repetidos.
CREATE UNIQUE INDEX MiIndice ON Casa_rural (CODIGO) WITH DISALLOW
NULL;
2.4 Modificar el Diseño de una Tabla
Modifica el diseño de una tabla ya existente, se pueden modificar los campos o los índices
existentes. Su sintaxis es:
ALTER TABLE tabla
{ADD {COLUMN tipo de campo[(tamaño)]
[CONSTRAINT índice] CONSTRAINT índice multicampo} |
DROP {COLUMN campo I CONSTRAINT nombre del índice} }
Donde:
91
Parte Descripción
Tabla Es el nombre de la tabla que se desea modificar.
Campo Es el nombre del campo que se va a añadir o eliminar.
Tipo Es el tipo de campo que se va a añadir.
Tamaño El el tamaño del campo que se va a añadir (sólo para campos de texto).
Es el nombre del índice del campo (cuando se crean campos) o el nombre
Índice
del índice de la tabla que se desea eliminar.
índice Es el nombre del índice del campo multicampo (cuando se crean campos) o
multicampo el nombre del índice de la tabla que se desea eliminar.
Operación Descripción
ADD Se utiliza para añadir un nuevo campo a la tabla, indicando el nombre, el
COLUMN tipo de campo y opcionalmente el tamaño (para campos de tipo texto).
ADD Se utliza para agregar un índice de multicampos o de un único campo.
DROP Se utliza para borrar un campo. Se especifica únicamente el nombre del
COLUMN campo.
Se utiliza para eliminar un índice. Se especifica únicamente el nombre del
DROP
índice a continuación de la palabra reservada CONSTRAINT.
Ejemplos:
Modifica la definición de los campos duenyo y descripcion.

alter table casa_rural
modify(duenyo char(10), descripcion varchar2(200));
Elimina la restricción de dominio impuesta sobre el campo banyo.

alter table habitacion drop constraint dom_banyo;
2.5 Eliminación de tablas

Se utiliza la siguiente instrucción:
DROP TABLE nombre_relación;
Ejemplo: borrar la relación habitación:

drop table habitacion;
92
Unidad temática 3:
Bases de Datos Espaciales
Objetivos
• Comprender el concepto de base de datos espacial
• Ser capaces de seleccionar el modelo de datos espacial que más se ajusta a los datos
• Ser capaces de insertar datos espaciales en una base de datos Oracle
• Ser capaces de realizar consultas sobre datos espaciales en Oracle 8i
Contenidos
Tema 8. Modelado de datos espaciales
Tema 9. Gestión de datos espaciales en Oracle 8i
Tema 10. Consultas espaciales en Oracle 8i
Tema 8: Modelado de datos espaciales
1 Introducción
Como ya hemos comentado, la tendencia actual de los SIG es la de utilizar SGBD

extendidos para aprovechar las ventajas de una visión integrada de los datos. El concepto
básico consiste en la habilidad de añadir nuevos tipos y operaciones al sistema relacional.
En el caso de aplicaciones geoespaciales, la tendencia actual es la extensión de SGBD
relacionales de la siguiente forma:
1. El lenguaje de consulta SQL se extiende para manipular datos espaciales así como
datos descriptivos. Los nuevos datos espaciales (punto, línea, región) se manejan
como los tipos alfanuméricos básicos.
2. Muchas otras funciones del SGBD, como optimización de consultas, se adaptan para
manejar datos espaciales eficientemente.
Muchos SGBD ofrecen esta extensión espacial. Oracle 8i es uno de ellos y es el que
estudiaremos en temas posteriores.
2 Definiciones
En un SIG la información geoespacial correspondiente a un aspecto en particular se conoce

como tema (o entidad). Un tema es similar a una relación como se define en el modelo
relacional. Por ejemplo, rios, ciudades y países son temas. Cuando un tema se muestra en
papel o sobre la pantalla, lo que el usuario ve es un mapa.
Los mayores objetos a considerar en el nivel conceptual son los objetos geográficos. Un
tema es una colección de objetos geográficos. Un objeto geográfico corresponde con una
entidad del mundo real y tiene dos componentes:
- Una descripción. El objeto es descrito por un conjunto de atributos descriptivos.
Por ejemplo, el nombre y el número de habitantes de una ciudad constituyen su
descripción. También son conocidos como atributos alfanuméricos.
- Un componente espacial, el cual puede estar compuesto por la geometría
(localización en el espacio, forma, etc.) y la topología (relaciones espaciales entre
objetos existentes, como la adyacencia). Por ejemplo, una ciudad puede tener
como valor geométrico un polígono en 2D.
Dada la inherente complejidad de las entidades geográficas en el mundo real y las
relaciones de composición existentes entre muchas de estas entidades, introducimos la
noción de objeto geográfico atómico y objeto geográfico complejo. Los objetos
geográficos complejos se componen de otros objetos geográficos, que pueden a su vez, ser
atómicos o complejos. Por ejemplo, en el tema que corresponde a las comunidades
autónomas españolas, el objeto geográfico (complejo) “Comunidad Valenciana” se
compone de otros objetos geográficos (que podemos considerar atómicos) “Provincias de la
Comunidad Valenciana”. Un tema es, por tanto, un conjunto homogéneo de objetos
geográficos (es decir, de objetos que tienen la misma estructura o tipo).
El atributo espacial es un objeto geográfico no se corresponde con ningún tipo de dato

estándar, como entero o cadena. La representación de la geometría y de la topología
requiere un modelado potente al nivel de tema u objeto, que nos lleva a los modelos de
datos espaciales. Normalmente, los siguientes tipos de datos básicos son utilizados en los
modelos de datos espaciales:
- point (punto): objeto de dimensión 0
- line (línea): objeto de dimensión 1
- region (región): objeto bidimensional
Por ejemplo, el objeto espacial asociado a un río es una línea, mientras que el objeto
asociado con una ciudad es una región (o polígono).
3 Operaciones simples sobre temas
Supongamos que hemos definido los siguientes temas:

1. Países, con los atributos descriptivos nombre, capital, número de habitantes y con un
atributo espacial denominado geo.
2. Idiomas, que representa la distribución de los principales idiomas hablados (o familias
de idiomas), con el atributo descriptivo idioma y el atributo espacial geo.
Es decir:
1. Países (nombre, capital, num_habitantes, geo:region)
2. Idiomas (idioma, geo:region)
Las siguientes son operaciones comunes sobre estos temas, basadas en el álgebra
relacional:
- proyección, consiste en la operación de seleccionar uno o varios campos para
mostrar su contenido. Por ejemplo, dado el tema Paises, podemos proyectar sobre
el campo num_habitantes y obtendremos la siguiente tabla:
Paises Num_habitantes
Portugal 10.500.000
Francia 58.000.000
... ...
Alemania 78.500.000
96
- selección, consiste en la operación de seleccionar una o varias tuplas de un tema.

Por ejemplo, dado el tema Paises podemos seleccionar aquellos países con más
de 50 millones de habitantes y obtendremos la siguiente tabla:
Paises Num_habitantes
Francia 58.000.000
... ...
Alemania 78.500.000
- superposición, consiste en superponer dos o más temas para obtener uno nuevo.
Por ejemplo, si tomamos los temas Paises e Idiomas y los superponemos,
obtendremos los paises donde se habla cada idioma.
- selección geométrica, por ejemplo:
- windowing: consiste en definir una ventana y seleccionar todos aquellos
elementos de un tema que la ventana superpone, aunque sea parcialmente
- clipping: consiste en definir una ventana y seleccionar sólo la parte de los
elementos de un tema que la ventana superpone
97
Tema 9: Gestión de datos espaciales en Oracle 8i
En este tema veremos los distintos modos en los que los datos espaciales pueden ser
modelados en Oracle 8i, así como las distintas relaciones que se pueden establecer entre
objetos geográficos. También estudiaremos el modelo objeto-relacional de Oracle 8i y cómo
se insertan datos de tipo espacial en las tablas.
1 Modelado del espacio geográfico
En el tema anterior definimos un objeto geográfico como dos partes: una descripción y una
componente espacial. Para distinguir un objeto geográfico de otro, debemos asignarle una
identidad. El conjunto de (identidad, componente espacial, descripción) se conoce como
entidad.
La interpretación del espacio depende de la semántica asociada con el territorio geográfico.
Consideremos, por ejemplo, a España. Si adoptamos un punto de vista administrativo,
España se divide en comunidades autónomas. Desde un punto de vista geológico,
obtenemos una organización totalmente distinta del espacio, en área geológicas. Si
estamos interesados en el control de tráfico, nos fijaremos en la red de carreteras. En cada
caso, elegimos una nueva interpretación del espacio y definimos un nuevo conjunto de
entidades que describen este espacio. En Oracle 8i, podemos utilizar los siguientes tipos
básicos de objetos espaciales:
a) punto (point). Se utilizan para representar la localización de entidades cuya forma no
se considera útil o cuando el área es bastante pequeña comparada con el espacio
total. Ciudades, iglesias y cruces son ejemplos de entidades tipo punto.
b) línea (line string). Se suelen usar para representar redes (carreteras, hidrográficas,
etc.). El tipo básico considerado es la polyline, que se define como un conjunto finito de
segmentos de líneas o bordes, tal que cada punto de final de un segmento es
compartido por exactamente dos segmentos, excepto los puntos finales de la polyline.
c) polígono (polygon). Se utilizan para representar entidades con áreas grandes, tales
como parcelas o áreas administrativas. Un polígono es una región del plano acotada
por una polyline cerrada, llamada frontera.
Es importante destacar el hecho de que la elección de uno u otro tipo de objeto espacial es
arbitraria. Depende del futuro uso que se le va a dar a la colección de entidades. Muchos
factores pueden influir en esta elección, pero uno de los más determinantes es la escala.
Por ejemplo, un aeropuerto puede ser visto como un punto (si estamos interesados en
enlaces aéreos) o como un polígono, si el objetivo es la organización del aeropuerto.
2 La extensión Spatial de Oracle 8i
El modelo de datos Spatial es una estructura jerárquica que consiste en:

- elementos: un elemento es el bloque básico de una geometría. Los tipos de
elementos básicos son el punto, la línea y el polígono. Por ejemplo, un elemento
puede modelar una constelación (conjunto de puntos), una carretera (polyline) o
los límites de una comarca (polígono).
- geometrías: una geometría es la representación de una característica espacial,
modelada como un conjunto ordenado de elementos. Por ejemplo, una geometría
puede describir el suelo edificable de una población.
- capas: una capa es un conjunto heterogéneo de geometrías que tienen el mismo
conjunto de atributos. Por ejemplo, una capa puede recoger las características
topográficas de una zona, mientras que otra capa puede describir la densidad de
población de la misma región.
Las relaciones espaciales que se pueden establecer entre dos entidades de la base de
datos son las siguientes:
- DISJOINT: los contornos y los interiores de las entidades no intersectan
- TOUCH: los contornos intersectan pero los interiores no
- OVERLAPBDYDISJOINT: el interior de un objeto intersecta con el contorno y el
interior del otro objeto pero los contornos no intersectan. Esto ocurre, por ejemplo,
cuando una línea comienza fuera de un polígono y termina dentro del polígono.
- OVERLAPBDYINTERSECT: los contornos y los interiores de los dos objetos
intersectan.
- EQUAL: los dos objetos tienen el mismo contorno y el mismo interior.
- CONTAINS: el interior y el contorno de un objeto está completamente contenido en
el interior del otro objeto
- COVERS: el interior de un objeto está completamente contenido en el interior del
otro y sus contornos intersectan
- INSIDE: el contrario de CONTAINS. A INSIDE B implica B CONTAINS A.
- COVEREDBY: el contrario de COVERS. A COVEREDBY B implica B COVERS A
- ANYINTERACT: los objetos intersectan de algún modo.
100
3 El modelo Objeto-relacional de Spatial
Veamos, ahora, una descripción de las tablas específicas que son necesarias en Oracle 8i
para manejar los datos espaciales.
En primer lugar, la información de una geometría asociada a una entidad se almacena

como un objeto en una de las columnas de la tabla que contiene el resto de datos
alfanuméricos. Por ejemplo, si definimos la tabla MUNICIPIO:
MUNICIPIO = {codigo, nombre, codigo_postal, geometria}.
Este nuevo campo geometria es de tipo SDO_GEOMETRY. Los componentes de este tipo
indican el tipo de geometría y los datos concretos que va a tener la fila correspondiente.
Estos componentes son:
- SDO_GTYPE: Define el tipo de geometría. Los tipos básicos se definen con los
siguientes valores: 1 para puntos, 2 para líneas y 3 para polígonos. Se compone
un número de cuatro cifras, donde la primera indica el número de dimensiones en
las que se representa el objeto. Así, si hablamos de dos dimensiones, se asignará
2001 para puntos, 2002 para líneas y 2003 para polígonos.
- SDO_SRID: No se utiliza en esta versión, por lo que su valor debe ser NULL.
- SDO_POINT: Define las coordenadas del punto, si SDO_GTYPE es 1.
- SDO_ELEM_INFO: Permite interpretar los valores contenidos en el campo
SDO_ORDINATES. Cada tripleta de elementos proporciona información de un
elemento de la geometría y una geometría puede contener varios elementos. De
momento, sólo vamos a tratar con geometrías simples, por lo que
SDO_ELEM_INFO contendrá únicamente tres elementos:
- SDO_STARTING_OFFSET: indica el desplazamiento dentro de
SDO_ORDINATES donde está almacenada la primera coordenada de este
elemento.
- SDO_ETYPE: indica el tipo del elemento, es decir, 1, 2 ó 3.
- SDO_INTERPRETATION: indica si se trata de un elemento compuesto.
- SDO_ORDINATES: almacena los valores de las coordenadas que configuran el
contorno del objeto espacial.
Por ejemplo, la entidad municipio la podemos modelar en la tabla MUNICIPIO como un

punto o como un polígono. Veamos cuáles serían los valores que se asignarían a cada una
de las componentes de SDO_GEOMETRY en cada caso:
- si modelamos el municipio como un punto:
SDO_GTYPE = 2001
SDO_SRID = NULL
SDO_POINT = (5.5, 3.2, NULL)
SDO_ELEM_INFO = NULL
101
SDO_ORDINATES = NULL
- si modelamos el municipio como un polígono:
SDO_GTYPE = 2003
SDO_SRID = NULL
SDO_POINT = NULL
SDO_ELEM_INFO = (1,3,1)
SDO_ORDINATES = (3,3,4,5,6,5,6,3,3,3)
4 Creación de tablas con datos espaciales
El primer paso cuando se desean asociar atributos espaciales a entidades “alfanuméricas”

en Oracle 8i consiste en crear un nuevo campo en la tabla de tipo SDO_GEOMETRY. De
esta forma, se indica que en este campo se almacenarán datos de tipo espacial.
Por ejemplo, podemos crear la tabla MUNICIPIO con un campo espacial:
CREATE TABLE municipio
nombre varchar2(40) not null,
codigo_postal varchar2(5) not null,
geometria MDSYS.SDO_GEOMETRY,
CONSTRAINT primaria PRIMARY KEY (codigo));
Cuando se introduce un campo de tipo SDO_GEOMETRY en una tabla, es necesario

insertar las características de esta geometría en la tabla SDO_GEOM_METADATA. Esta
tabla almacena la información concerniente a la escala de los elementos que se guardarán
en la nueva columna. Esta información se consultará más adelante cuando se desee
realizar consultas espaciales sobre la tabla. Concretamente, el esquema de la tabla
SDO_GEOM_METADATA es el siguiente:
------------------------------ -------- ----
TABLE_NAME VARCHAR2(30)
COLUMN_NAME VARCHAR2(30)
DIMINFO MDSYS.SDO_DIM_ARRAY
Por ejemplo, veamos cómo se debe dar de alta la columna geometria de la tabla
MUNICIPIO:
INSERT INTO SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO)
102
VALUES ('municipio', 'geometria',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', -180.00, 180.00, 0.000000050),
MDSYS.SDO_DIM_ELEMENT('Y', -90.00, 90.00, 0.000000050)
));
5 Inserción de datos espaciales
Insertar los valores de una entidad de la tabla SERVICIO. Cada

entidad se representa con un punto.
insert into servicio
values (8, 1, 'Comestibles Mora', mdsys.sdo_geometry(2001, NULL,
mdsys.sdo_point_type(4.75,6.75,NULL), NULL, NULL))
Insertar los valores de una entidad de la tabla CARRETERA. Cada

entidad se representa con una polyline.
insert into carretera values ('C1','Carretera 1 - Norte-Sur',
mdsys.sdo_geometry(2002, NULL, NULL,
mdsys.sdo_elem_info_array(1,2,1),
mdsys.sdo_ordinate_array(6,6.6, 4.5,5.5, 4.5,3.5, 3.25,3.5, 2,2.2)))
Insertar los valores de una entidad de la tabla LAGO. Cada entidad

se representa con un polígono.
insert into lago values ('L2','Lago Bernacle',
mdsys.sdo_geometry(2003, NULL, NULL,
mdsys.sdo_elem_info_array(1,3,1),
mdsys.sdo_ordinate_array(3,2, 6,2, 6,3, 4.5,3, 4.5,3.8, 3,3.8, 3,2))
)
103
1 Introducción
En este tema vamos a ver algunas funciones de Spatial que nos permiten realizar consultas
sencillas sobre datos espaciales en Oracle 8i. Estas funciones son:
• SDO_GEOM.RELATE: permite evaluar o conocer la relación espacial entre dos
entidades
• SDO_GEOM.SDO_DISTANCE: permite conocer la mínima distancia euclídea entre dos
entidades
• SDO_GEOM.SDO_AREA: permite conocer el área de una entidad
• SDO_GEOM.SDO_LENGTH: permite conocer la longitud o el perímetro de una entidad
2 SDO_GEOM.RELATE
Obtiene o evalúa la relación existente entre dos entidades.

Su sintaxis es:
SDO_GEOM.RELATE (campo1, metadata1, mascara, campo2, metadata2)
donde:
- campo1 es el nombre del primer campo espacial a relacionar
- metadata1 son los datos que aparecen en la tabla SDO_GEOM_METADATA
referidos al campo1
- mascara es el nombre de la relación que se quiere comprobar si se establece
entre ambos campos. Puede ser cualquiera de las vistas o DETERMINE cuando lo
que se pretende es conocer qué relación existe.
- campo2 es el nombre del segundo campo espacial a relacionar
- metadata2 son los datos que aparecen en la tabla SDO_GEOM_METADATA
referidos al campo2
La función devuelve tres tipos de respuesta:
- Si se pasa el nombre de una o varias relaciones como máscara, la función
devuelve el nombre de la relación de las indicadas que más se ajusta para este
par de geometrías. Si todas las relaciones indicadas son falsas, la función
devuelve FALSE.
- Si se pasa como máscara DETERMINE, la función devuelve la relación que mejor
se ajusta. Sólo se puede utilizar DETERMINE si la función SDO_GEOM.RELATE
se encuentra en la cláusula SELECT.
- Si se pasa ANYINTERACT, la función devuelve TRUE si las dos geometrías no
son disjuntas.
Ejemplos:
Obtener la descripción de las carreteras que pasan por el municipio
de Bernacle:
SELECT descripcion
FROM carretera c, municipio m, sdo_geom_metadata g1,
sdo_geom_metadata g2
WHERE m.nombre=’Bernacle’ AND
g1.table_name=’CARRETERA’ AND
g2.table_name=’MUNICIPIO’ AND
SDO_GEOM.RELATE (c.geometria,g1.diminfo,‘OVERLAPBDYDISJOINT’,
m.geometria,g2.diminfo)=‘OVERLAPBDYDISJOINT’;
SELECT descripcion
SDO_GEOM.RELATE (c.geometria,g1.diminfo,‘ANYINTERACT’,
m.geometria,g2.diminfo)=‘TRUE’;
Obtener el nombre del dueño y la dirección de las casas de Bernacle:

FROM casa_rural c, municipio m, sdo_geom_metadata g1,
g1.table_name=’CASA_RURAL’ AND
SDO_GEOM.RELATE (c.localizacion,g1.diminfo,‘INSIDE’,
106
m.geometria,g2.diminfo)=‘INSIDE’;

SDO_GEOM.RELATE (m.geometria,g2.diminfo,‘CONTAINS’,
c.localizacion,g1.diminfo)=‘CONTAINS’;

SDO_GEOM.RELATE (c.localizacion,g1.diminfo,‘ANYINTERACT’,
m.geometria,g2.diminfo)=‘TRUE’;
Obtener la relación existente entre el municipio de Bernacle y cada

carretera
SELECT descripcion,
SDO_GEOM.RELATE (c.geometria,g1.diminfo,‘DETERMINE’,
m.geometria,g2.diminfo)
g2.table_name=’MUNICIPIO’;
3 SDO_GEOM.SDO_DISTANCE
Obtiene la mínima distancia euclídea entre dos entidades.
107
La sintaxis de esta función es:
SDO_GEOM.SDO_DISTANCE(campo1, metadata1, campo2, metadata2)
donde:
- campo1 y campo2 son los campos entre los cuales se desea calcular la distancia
- metadata1 y metadata2 es la información de la tabla SDO_GEOM_METADATA de
cada campo
Ejemplos:
Obtener la distancia desde el lago Abis a cada carretera:
SELECT c.descripcion,
SDO_GEOM.SDO_DISTANCE(l.geometria, g1.diminfo,
c.geometria, g2.diminfo)
FROM lago l, carretera c, sdo_geom_metadata g1, sdo_geom_metadata g2
WHERE l.descripcion=’Lago Abis’ AND
g1.table_name=’LAGO’ AND
g2.table_name=’CARRETERA’;
Obtener la distancia desde el lago Abis a cada carretera cuando esta

distancia es inferior a 1.5:
SELECT c.descripcion,
c.geometria, g2.diminfo)
FROM lago l, carretera c, sdo_geom_metadata g1, sdo_geom_metadata g2
WHERE l.descripcion=’Lago Abis’ AND
g1.table_name=’LAGO’ AND
c.geometria, g2.diminfo)<1.5;
4 SDO_GEOM.SDO_AREA
Obtiene el área de la entidad indicada.

Su sintaxis es:
SDO_GEOM.SDO_AREA(campo1, metadata1)
108
donde:
- campo1 es el campo del cual se desea calcular el área
- metadata1 es la información de la tabla SDO_GEOM_METADATA de este campo
Ejemplo:
Obtener el área de todos los municipios:
SELECT m.nombre,
SDO_GEOM.SDO_AREA(m.geometria, g1.diminfo)
FROM municipio m, sdo_geom_metadata g1
WHERE g1.table_name=’MUNICIPIO’;
Obtener el área de todos los municipios cuya área sea superior a 2:

SELECT m.nombre,
SDO_GEOM.SDO_AREA(m.geometria, g1.diminfo)
WHERE g1.table_name=’MUNICIPIO’ AND
SDO_GEOM.SDO_AREA(m.geometria, g1.diminfo)>2;
5 SDO_GEOM.SDO_LENGTH
Obtiene la longitud si la entidad indicada es una polilínea o el perímetro si la entidad

indicada es un polígono.
Su sintaxis es:
SDO_GEOM.SDO_LENGTH(campo1, metadata1)
donde:
- campo1 es el campo del cual se desea calcular la longitud o el perímetro
- metadata1 es la información de la tabla SDO_GEOM_METADATA de este campo
Ejemplo:
Obtener el perímetro de todos los municipios:
SELECT m.nombre,
SDO_GEOM.SDO_LENGTH(m.geometria, g1.diminfo)
109
WHERE g1.table_name=’MUNICIPIO’;
Obtener el perímetro de todos los municipios cuyo perímetro sea

superior a 5:
SELECT m.nombre,
SDO_GEOM.SDO_LENGTH(m.geometria, g1.diminfo)
WHERE g1.table_name=’MUNICIPIO’ AND
SDO_GEOM.SDO_LENGTH(m.geometria, g1.diminfo)>5;
110
Práctica 2. Consultas espaciales
Consiste en realizar las consultas siguientes.
1. Nombre y área de todos los lagos.
DESCRIPCION AREA
-------------------------------------------------- ----------
Lago Abis 3,9
Lago Bernacle 4,2
2. Código de la casa y nombre del dueño de las casas situadas en Abis.
CODIGO DUENYO
---------- ----------------------------------------
1001 Manuel Martinez Garcia
5001 Vicenta Duque Moreira
5002 Vicenta Duque Moreira
5003 Ricardo Olmos Garcia
3. Código y descripción de las carreteras que pasan por Abiside.
CODIGO DESCRIPCION
---------- --------------------------------------------------
C3 Carretera 3 - Este-Oeste
C4 Carretera 4 - Circular
4. Nombre de los municipios donde hay más de un supermercado.
NOMBRE
------------------------------
Abis
5. Nombre de los municipios cuya distancia a un hospital es menor de 3.
NOMBRE
------------------------------
Abis
Abiside
6. Distancias entre cada lago y cada carretera.
LAGO CARRETERA DISTANCIA

--------------- --------------------------------- ----------
Lago Abis Carretera 1 - Noreste-Suroeste ,9
Lago Abis Carretera 2 - Norte-Sur 3,4
Lago Abis Carretera 3 - Este-Oeste 1
Lago Abis Carretera 4 - Circular 0
Lago Abis Carretera 5 - Este-(Norte-Sur) 1,92937814
Lago Bernacle Carretera 1 - Noreste-Suroeste 0
Lago Bernacle Carretera 2 - Norte-Sur 1
Lago Bernacle Carretera 3 - Este-Oeste ,7
Lago Bernacle Carretera 4 - Circular 0
Lago Bernacle Carretera 5 - Este-(Norte-Sur) 0
7. Código, dueño y fecha de construcción de las casas en las que caben entre 5 y 10
personas en el total de habitaciones y cuya distancia al lago Abis sea menor de 3.
CODIGO DUENYO FECHA_CONSTRUCCION

---------- ----------------------------------- --------------------
1001 Manuel Martinez Garcia 21/10/80
2001 Amalia Gomez Tormes 01/04/98
2003 Monica Fernandez Gil 01/02/95
5001 Vicenta Duque Moreira 01/08/78
5003 Ricardo Olmos Garcia 08/08/88
112
8. Código de las casas rurales cuyo precio total es inferior a 50000 y cuya distancia a un
supermercado es inferior a 0.6, sabiendo que el tipo de servicio de un supermercado es
1. Mostrar también la distancia correspondiente.
CODIGO DISTANCIA
---------- ----------
2001 ,559016994
3001 ,55
3002 ,2
5001 ,5
9. Código y longitud de la carretera más corta.
CODIGO LONGITUD
---------- ----------
C5 4,15138782
10. Código y descripción de las carreteras que pasan por todos los municipios.
CODIGO DESCRIPCION
---------- --------------------------------------------------
C4 Carretera 4 - Circular
113
Práctica 3: Manipulación de la base de datos
1. Insertar la información correspondiente a la siguiente casa rural:
Municipio: Bernacle
Dueño: Mónica Rodríguez Campos
Dirección: Calle Lago Bernacle, 3
Teléfono: 650673256
Precio: 22000
Fecha construcción: enero-1994
Descripción: amplio salón con chimenea, cocina office
Coordenadas: 5.1, 1.2
Habitación 1:
- número de plazas: 2
- baño: Sí
- precio noche: 12000
- precio descuento: 10000
- descripción: cama matrimonio, teléfono
Habitación 2:
- número de plazas: 4
- baño: Sí
- precio noche: 25000
- precio descuento: 20000
- descripción: dos camas matrimonio, teléfono
2. Modificar el precio de la casa anterior de 22000 a 32000.

3. Obtener las distancias de esta casa al supermercado y al centro de salud de Bernacle.
4. Eliminar toda la información de esta casa.

Apuntes BDC PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apuntes BDC PDF

Cargado por

Copyright:

Formatos disponibles

Apuntes de

- entender los conceptos básicos del diseño de bases de datos

La bibliografía consultada para elaborar estos apuntes es:

Unidad temática 1: Bases de datos relacionales

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

Unidad temática 3: Bases de datos espaciales

Bases de datos relacionales

Hace unas décadas, la principal forma de sintetizar y representar información geográfica

Una Base de datos consiste en una colección de datos persistentes e independientes

3 Objetivos de las Bases de Datos

El objetivo principal de todo sistema de base de datos es proporcionar a la organización la

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

Para ilustrar el concepto de abstracción de datos, consideremos un grupo de programas de

Un modelo de datos se puede definir como un conjunto de herramientas conceptuales útiles

4.1 Modelos de diseño

4.2 Modelos de representación

5 Facilidades del SGBD

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

6 Ventajas y desventajas de un SGBD

7 Introducción a las bases de datos espaciales

Un objeto geográfico tiene dos componentes:

3.1 Cardinalidad de una relación

El concepto de clave permite diferenciar las entidades y relaciones individuales en términos

5 Diagrama entidad – relación

Nombre Num_hab Nombre

NIF Nombre Fecha Numero

6.1 Entidades fuertes y débiles

Codigo Titulo Numero Ubicación

6.2 Tipos especiales de relación

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

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

- La entidad universitario (representando a las personas que pertenecen a la

La cardinalidad en las relaciones de especialización es siempre (1,1) en el extremo de

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

Nombre Nombre Num_hab

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

Dadas las entidades:

Se desea generar una base de datos para almacenar información respecto la

2 Estructura de las bases de datos relacionales

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

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

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

Codigo Titulo Numero Ubicación

La entidad fuerte Libro se representa mediante la siguiente tabla:

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

4.1.1 Relación realiza_pedido

NIF Nombre Fecha Numero

4.1.2 Relación es_capital

Nombre Num_hab Nombre

4.1.3 Relación vive

El modelo relacional de datos contempla tres tipos de restricciones:

En este caso se produce una violación de la integridad referencial, ya que el

4.3 Problemas con las restricciones durante las operaciones

4.3.1 Inserción de una nueva tupla en una tabla

4.3.3 Borrado de una o varias tuplas de una tabla.

Nombre Nombre Num_hab

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

Obtener el modelo relacional correspondiente al diagrama entidad-relación del

Obtener el modelo relacional correspondiente al diagrama entidad-relación del último

La teoría de la Normalización es un método objetivo y riguroso que se aplica en el diseño

2 Ejemplos de anomalías que se pueden presentar

Analicemos la siguiente relación: ESCRIBE

AUTOR NACIONALIDAD COD_LIBRO TITULO EDITORIAL AÑO