Bases de Datos

Apuntes
21/02/2008

ANDREA SIERRA LOUZN & ALBERTO SUREZ LPEZ

Bases de Datos
21 de febrero de 2008

Contenido
Parte 1: Introduccin....................................................................................................................4
Tema 1: Introduccin ...............................................................................................................4
1.1.

Definiciones ..............................................................................................................4

1.2.

Sistemas de BBDD frente a Sistemas de Archivos .....................................................5

1.3.

Visin de los datos ....................................................................................................6

1.4.

Modelos de datos .....................................................................................................7

1.5.

Lenguajes de Bases de Datos ....................................................................................9

1.6.

Arquitectura de un SGBD ........................................................................................10

Parte 2: Ciclo de vida y modelos de datos ..................................................................................14

Tema 2: Modelos de datos .....................................................................................................14
2.1.

Definiciones ............................................................................................................14

2.2.

Aspectos de un modelo de datos ...........................................................................14

Tema 3: Ciclo de vida de las Bases de Datos ..........................................................................16

3.1.

Diseo dirigido por procesos y diseo dirigido por datos .......................................16

3.2.

Ciclo de vida en cascada .........................................................................................16

3.3.

Aplicacin del ciclo de vida .....................................................................................16

Parte 3: Diseo conceptual: Modelo Entidad Relacin............................................................21

Tema 4: Modelo Entidad - Relacin .......................................................................................21
4.1.

Introduccin y elementos fundamentales ..............................................................21

4.2.

Restricciones de integridad ....................................................................................22

4.3.

Reduccin de diagramas E-R en tablas ...................................................................25

4.4.

Construcciones avanzadas ......................................................................................26

Tema 5. Modelo Entidad- Relacin extendido .......................................................................30

5.1.

Relaciones ternarias ...............................................................................................30

5.2.

Caractersticas extendidas ......................................................................................31

5.3.

Restricciones que afectan a las relaciones .............................................................32

Parte 4: Diseo lgico: Modelo relacional ..................................................................................34

Tema 6. Modelo relacional .....................................................................................................34
6.1.

Introduccin ...........................................................................................................34

6.2.

Estructura de las BBDD relacionales ......................................................................34

6.3.

Lenguajes de consulta formales: lgebra relacional ...............................................36

6.4.

Clculo relacional ...................................................................................................39

6.5.

Las 12 reglas de codd..............................................................................................40

Pgina 2

Bases de Datos
21 de febrero de 2008
Ejercicios (E-R y paso a tablas) ...............................................................................................45
1.

Ejercicio 1 ...................................................................................................................45

Pgina 3

Bases de Datos
21 de febrero de 2008

Parte 1: Introduccin
Tema 1: Introduccin
1.1.

Definiciones
Banco de Datos: Conjunto de datos relacionados entre s. Ejemplo: ficheros con la
informacin acadmica.
Base de Datos: Cuando el banco de datos en vez de almacenarse en soportes
tradicionales se guardan en medios informticos.
A veces lo dibujaremos as:
. Es necesaria una forma de acceder a los datos y
gestionarlos. En el primer caso (banco de datos) podra ser una persona, pero usando
programas; en el caso del sistema informtico (B.D.) se necesitan programas: SGBD.
SGBD: Dada una o varias BBDD es el conjunto de programas que permite tener acceso
a los datos almacenados.
El acceso a los datos implica consulta y modificacin de los datos. Acceder tambin
se conoce con el nombre de gestionar. Tambin debe proporcionar:
Comodidad (conveniencia): que sea cmodo de acceder a los datos, fcil de
utilizar.
Ejemplo:
SELECT nota
FROM alumno
WHERE nombre = Borja Flecha
AND asignatura = BBDD
Eficiencia: Que de los resultados en un tiempo razonable. Hay que buscar
equilibro entre ellas: se intenta ir aumentado la comodidad y mejorando, si es
posible, la eficiencia; o que al menos no se resienta.
Hay que gestionar grandes cantidades de informacin por lo que las
estructuras de almacenamiento tienen que ser especficas y los algoritmos
asociados hay que disearlos adecuadamente.

Seguridad/control de acceso: No todo el mundo puede hacer cualquier cosa,

hay que restringir el acceso. Tambin hay que tener en cuenta otras cosas
derivadas de la utilizacin.
Concurrencia: qu pasa si hay 10 o 100 o X usuarios que quieren modificar
algo en la BD? Hay que considerar los casos en que haya ms de un usuario
accediendo simultneamente.
Los SGBD ms conocidos:
Oracle: tiene una cuota de mercando muy grande.
IBM DB2: en sistemas profesionales sobre todo Unix.

Pgina 4

Bases de Datos
21 de febrero de 2008

Informix: comprado por IBM hace unos aos.

Sybase
Ingress: de cdigo abierto.
MS SQL server
MS Acess
MySQL: el ms conocido y tambin el peor.
Postgres

1.2.

Sistemas de BBDD frente a Sistemas de Archivos

Para ver los objetivos de las BBDD vamos a ver primero los problemas de los sistemas
de procesamiento de fichero.
Los datos se almacenan en un fichero formado por diversos registros con la
informacin para acceder al fichero. Para acceder al fichero se realiza un programa especfico
para la funcin deseada. Si se necesita acceder a otra cosa debe hacerse otro programa o
modificar uno ya existente. Y si necesitan incluirse nuevos datos se utiliza otro fichero.
Todo esto evoluciona a lo largo del tiempo aumentando en complejidad y tamao. Y
produce:
Redundancia en los datos: Al haber varios ficheros puede haber datos repetidos (por
ejemplo: nombre de cliente. La redundancia es la inconsistencia debido a que al estar
los datos repetidos es necesario cambiar dichos datos en todos los ficheros; y para
ello, deben modificarse todos los programas que modifican datos.
Dificultad de acceso: no es cmodo acceder a los datos. Generalmente implica crear
un programa especfico para dicho acceso.
Aislamiento de datos: Con el paso del tiempo se cambian los SSOO, los lenguajes de
programacin, etc. Y todos esos cambios hacen que coexistan ficheros con distintos
formatos. Si pasado el tiempo se necesita acceder a un fichero antiguo es mucho ms
difcil adems de no encontrar el necesario.
Concurrencia: Como los SSOO no tienen demasiada proteccin de datos habra que
rehacer os programas para que no hubiera problemas. Tambin podra ponerse un
monitor de transacciones entre los programas y los ficheros de transacciones.
Seguridad: Con un SO puedes controlar que usuario lea o no un fichero completo, pero
no puedes hacer cosas ms complejas como acceder a unos campos s y a otros no. As
que hay que programar con muchas condiciones; aunque eso no proporciona la
suficiente seguridad ya que el fichero, al ser accesible por el usuario, puede ser
consultado totalmente.
Integridad: Adems de almacenar los datos los valores tienen que respetar unas
restricciones e integridad (por ejemplo, no vale que la edad sea -5). De nuevo hay que
programarlo, aunque se realiza mediante bibliotecas, si hay cambios, adems de la
complejidad hay que cambiarlo todo.
La idea de las BBDD es meter inteligencia a las propias BBDD, no slo datos. Con los
datos meteremos informacin adicional a la que llamaremos metadatos. Antes la inteligencia
estaba en los programas ahora se la meteremos al sistema.

Pgina 5

Bases de Datos
21 de febrero de 2008
La nica forma de acceder a la BD es mediante los SGBD. Por ello, como hay un punto
centralizado se puede controlar la concurrencia, la integridad, la seguridad
Lo ideal es que el programa tenga la lgica del programa y todo lo dems para las
BBDD. Pero no es as ya que algunas cosas habr que hacerlo en las aplicaciones y se hacen
cambios habr que tocar cdigo de las aplicaciones y recompilar pero ahora es ms sencillo
que antes.
1.3.

Visin de los datos

1.3.1. Niveles de abstraccin

En el mundo de las BBDD se establecen 3 niveles de abstraccin:
Fsico: indica cmo se van a guardar los datos. No llega al disco duro, sino que se
refiere a rboles, tablas hash
Conceptual: Qu datos hay que cmo estn relacionados entre s. Se indica con
estructuras de alto nivel.
De visin o vistas: en lugar de ensear todo el nivel conceptual, enseamos
subconjuntos de este adaptadas a cada usuario segn las restricciones.
Qu estructuras vamos a tener en cada nivel? Las que se definen en cada nivel se
llaman esquemas; en una BD tendremos un esquema conceptual, un esquema fsico y unos
esquemas de vistas o subesquemas.
1.3.2. Instancias y esquemas
Esquemas: Representacin de los datos que necesitamos para cada capa. Ejemplo:
nivel conceptual.

Instancia: Datos que hay almacenados en un momento dato. Si se aade, elimina o

modificar algo de la BD la instancia cambia. Manejaremos las instancias cuando
hablemos de consultas. Nosotros trataremos ms con el esquema.
1.3.3. Independencia de datos
En dos niveles:
-

Fsica: Es independiente. Podemos cambiar la representacin en el esquema fsico

sin tocar nada en el nivel conceptual.
Lgica: igual que la fsica podemos cambiar el esquema conceptual sin tocar las
aplicaciones.

Con el nivel conceptual es ms difcil puesto que las aplicaciones dependen o se basan
en el esquema conceptual. Para ello utilizamos el nivel de visin.
En definitiva, podemos hacer cambios en un nivel sin afectar a otros y por ello a las
aplicaciones.

Pgina 6

Bases de Datos
21 de febrero de 2008
1.4.

Modelos de datos
Hay que decidir, en el nivel conceptual por ejemplo, qu tipo de estructuras se va a
utilizar para mostrar a los usuarios.
Cada nivel est relacionado y el sistema debe conocer la correspondencia entre
niveles. De igual modo que el sistema operativo abstrae al disco duro del usuario mediante
ficheros, de forma que no tiene que preocuparse de escribir bloques ni nada similar; en los
SGBD se abstrae de la BD mediante tablas.
Modelo de datos es la herramienta que se utiliza para describir lo que hay en cada
nivel adems de describir informacin adicional. Los hay de dos tipos: lgicos y fsicos. Estos
ltimos en la prctica no estn desarrollados.
Dependiendo de la estructura usada en cada nivel se usa uno u otro modelo.
Generalmente el modelo conceptual (lgico) es muy importante ya que es el nivel que usa el
usuario. En funcin de nuestra aplicacin hay que elegir la organizacin fsica que mejor nos
venga.
1.4.1. Modelos lgicos
Los hay de dos tipos:
-

Basados en objetos
o Entidad relacin (el que ms se usa)
o Orientado a objetos
Basados en registros
o Relacional (usado por el 99% de las BBDD)
o Red (en desuso)
o Jerrquico (en desuso)

Primero se trabaja con un modelo basado en objetos y luego se pasa a relacional, que
es lo comercial. Nosotros realizaremos los mismos pasos con el objetivo de que funcione en
Oracle.
Veremos un ejemplo con cada modelo aunque hay que tener en cuenta que los
modelos de datos no son totalmente expresivos y puede haber cosas que no se puedan
expresar, no como en los lenguajes de programacin.
E-R
Es un modelo estricto de datos. Se basa en que las estructuras de las que dispone para
representar los datos son entidades y relaciones. Entidad es un objeto que existe por s mismo,
y las relaciones asocian entidades.
Ejemplo:

Pgina 7

Bases de Datos
21 de febrero de 2008

Orientado a objetos
En este modelo tambin se explica el comportamiento. Cada elemento del conjunto
cliente se denomina ejemplar u ocurrencia. Mediante las categoras podemos asignar
responsabilidades y capacidades a sus elementos. Adems pueden establecerse relaciones
entre dos categoras. Las relaciones se pueden establecer entre elementos individuales de las
categoras y las relaciones pueden agruparse.
Ejemplo:

La principal diferencia entre OO y E-R es que en E-R slo se definen los datos mientras
que en O tambin se define el comportamiento.
Relacional
Organizamos los datos en forma de tablas, con columnas a las que llamamos
atributos.
DNI y Nm. Cuenta estn subrayados ya que los usaremos como clave.
Cliente

DNI
1
2
222

Nombre
Paco
Carmen
Eddie

Cuenta

Nm. Cuenta
1
2

Saldo
100
200

Lo que nos falta ahora es la relacin, es decir, quin es el dueo de cada cuenta. En el
modelo relacional no hay relaciones ni asociaciones por lo que hay que relacionarlos mediante
tablas.
Posee

DNI
1
2
222

Pgina 8

Nm. Cuenta
1
1
2

Bases de Datos
21 de febrero de 2008
En este caso utilizamos claves, id que no se pueden repetir: DNI y nm. Cuenta. Para
expresar que un cliente es propietario de ms de una cuenta sera necesario introducir otra
fila. Si cada cliente slo puede tener una cuenta podramos ahorrarnos esta tabla y poner
donde DNI y Nombre como otra columna la cuenta asociada.
Este modelo no es perfecto, funciona muy bien con nmeros y letras y con pocos tipos.
En red
Tenemos registros y enlaces, punteros entre los registros. La diferencia principal con ER es que en E-R son punteros abstractos, mientras que en el modelo de datos en red son a bajo
nivel (se ven, se puede quitar la referencia...).
Ejemplo:

Para poder ir de uno a otro hay que tener un puntero, ya que no se puede utilizar el
mismo que nos llev al ltimo registro. Es una forma de programar a muy bajo nivel. Se
utilizaba en los aos 70 antes de la existencia del modelo relacional.
Jerrquico
Es el predecesor del modelo en red, surgido en torno a los aos 50.
Ejemplo:

Si se ponen 2 punteros a punto deja de ser un rbol por lo que se utilizaron una
especie de registros fantasma, que lo que hacen realmente es redireccionarlo. Este modelo de
datos es malo para cosas que se compartieran; aqu se prima un sentido de navegacin (en
este ejemplo, de clientes a cuentas).
1.5.

Lenguajes de Bases de Datos

Necesitamos lenguajes de bases de datos para comunicarnos con el SGBD.

1.5.1. Lenguaje de definicin de datos (DDL)

Nos permite definir el esquema a nivel conceptual y, en ocasiones, fsico. Genera los
metadatos del sistema.

Pgina 9

Bases de Datos
21 de febrero de 2008
Ejemplo:
CREATE TABLE Cliente
(
DNI INTEGER,
nombre CHAR(20)
)

Es importante tener en cuenta el diccionario de datos el cual tiene metadatos. Se

modifica al compilar el cdigo como el ejemplo. Aade la inteligencia de la BD que nosotros
introduzcamos.
1.5.2. Lenguaje de Manejo de datos (DML)
De la misma forma que podemos definir las estructuras, tenemos que poder trabajar a
nivel de instancia. El manejo de las instancias nos va a permitir dos cosas:
-

Consulta
Modificar / insertar / eliminar / actualizar.

Es importante que sea en un lenguaje cmodo, aunque hay muchos tipos de LDM.
Bsicamente hay dos tipos:
-

Declarativos: se indica la forma que tiene el resultado, declaramos la definicin, no

se indica cmo obtenerlo.
Ejemplo:

>

)} Notacin de lgica de 1er orden

Procedimentales: Hay que indicar los pasos que hay que dar, cmo manipular la
informacin para llegar al resultado que queremos.
Ejemplo:

Tambin podemos dividir los lenguajes por el aspecto externo:

- Comerciales: Pensados para el usuario final, con una sintaxis ms atractiva y fcil.
Ejemplo: SQL (sabiendo ste podemos manejar todas las BBDD ya que todas traen
una interfaz SQL.

SELECT DNI, nombre

FROM cliente, cuenta
WHERE [Link] = [Link]
AND ciudad = 'OVD'
AND saldo > 100
-

Formales: Los lenguajes puros, como los que vimos antes.

1.6.

Arquitectura de un SGBD
En este punto veremos diferentes elementos que intervienen en un SGBD, tanto
humanos como de otro tipos.

Pgina 10

Bases de Datos
21 de febrero de 2008
GESTOR BBDD
Parte del sistema que se encarga de hacer de interfaz entre consultas de alto nivel y
datos de bajo nivel. Centraliza los accesos. Tiene una serie de funciones:
-

Interactuar con el HW (o con SO o sistema de ficheros)

GESTOR DE
ALMACENAMIENTO.
Gestionar o implantar la integridad de los datos GESTOR DE INTEGRIDAD.
Controlar la seguridad GESTOR DE AUTORIZACIONES.
Ordenar el acceso concurrente a los datos GESTOR DE TRANSACCIONES.
Utilidades de respaldo y recuperacin Suelen tener una forma de volcar todo
esto ya que tienen a un soporte de seguridad y luego poder recuperarlo.

GESTOR DE TRANSACCIONES
Una transaccin es una unidad de trabajo con el sistema. Son un conjunto de
operaciones que ejecutan de forma atmica. Son lgicas y forman una unidad. Deben tener:
-

Atomidad: O se efectan todas las operaciones de transacciones o ninguna.

Consistencia: No se pueden dejar las BBDD en estado inconsistente.
Durabilidad: Una vez finaliza una transaccin, sus efectos son permanentemente
persistentes y accesibles.
Aislamiento: Cuando una transaccin se est efectuando es como si estuviera ella
sola.

Una transaccin se puede abortar no slo por razones de consistencia sino tambin de
concurrencia adems tambin hay que dar soporte para la atomicidad.
GESTOR DE AUTORIZACIONES E INTEGRIDAD
Controla los permisos de cada usuario. Por l pasan todos los accesos a datos. Para su
funcionamiento tambin necesita el gestor de almacenamiento, el gestor de archivos y el
gestor de memoria intermedia.
Hay 2 tipos de permisos de forma general:
-

Administrador de la BD: Es la persona que tiene el control central sobre el sistema,

tanto sobre los datos como sobre los programas que acceden a esos datos. Sus
funciones son las siguientes:
o Definiciones de los esquemas, tanto a nivel conceptual como a nivel fsico
(que, gracias a la independencia de datos, no afectan a las aplicaciones).
o Modificaciones oportunas al esquema.
o Concesiones de permisos, autorizaciones. En este caso el trabajo con los
permisos no es como los ficheros de tipo rwx sino del tiempo: consultar,
actualizar, etc. En SQL la forma de realizarlo est estandarizada.
o Definicin de restricciones de integridad. Tambin estandarizado en SQL.
o Monitorizacin del sistema: en general, vigilar cmo va el sistema. Para
monitorizarlo necesita herramientas que le permitan ver determinados

Pgina 11

Bases de Datos
21 de febrero de 2008

parmetros, para ello o las realiza el administrador o las proporciona los

SGBD.
Usuarios: Hay 3 tipos:
o Programadores/Desarrolladores de aplicaciones: Son los que desarrollan
las aplicaciones, normalmente usando lenguajes de manejo de datos. Para
ello, incrustan sentencias SQL en el cdigo de un lenguaje de los habituales
(Java, C++).
Ejemplo:
---int _saldo, _ncuenta;
----

$UPDATE cuenta
SET saldo = saldo + _saldo
WHERE ncuenta =:_ncuenta

Tal y como est, en un compilador normal no compilara, normalmente

se usa un preprocesador que transforma el cdigo en SQL en algo que el
compilador comprenda, para ello se utiliza la directiva $ antes del cdigo
para indicar al procesador que trabajamos con SQL. Este tipo de lenguajes
se denominan lenguajes de programacin inmersa. El uso de estos
lenguajes es una manera de trabajar con ellos en el desarrollo ya que son
lenguajes de manejo de datos pero no son de propsito general.
Otra tcnica para su uso, que es la que utilizaremos nosotros, es con
bibliotecas de acceso, es decir, bibliotecas del lenguaje para acceder a la
Base de Datos. Es a lo que recurren los preprocesadores.
Ejemplo de bibliotecas: Ambos son independientes del sistema de gestin.
Java JDBC
Windows ODBC
Para explicar cmo funcionan antes de la introduccin de bibliotecas:

Partiendo de esto, lo que hacen JDBC y ODBC es introducir un nivel de

direccin en medio:

Al cargar le decimos al controlador que cargar con qu BBDD. Es

importante hacer las cosas lo ms independiente posible de las BBDD,
porque si no dependeramos de una marca concreta. Para ello estn los std

Pgina 12

Bases de Datos
21 de febrero de 2008

o
o

en las API, la cual contiene toda la informacin que tiene que ser comn a
todos los sistemas.
La tercera de las tcnicas es la utilizacin de un lenguaje de 4
generacin (L4G) aunque ahora est en desuso. Lo que hace es coger un
lenguaje de marcado de datos y lo extiende para que sea un lenguaje
completo, es decir, en un lenguaje de programacin que pueda hacer de
forma nativa el acceso a las BBDD para que fuese todo ms rpido.
Usuarios avanzados: Los que saben manejar las consultas.
Usuarios normales: Los que manejan los programaciones de aplicaciones
(que estn usando una Base de Datos pero no ven cmo).

Pgina 13

Bases de Datos
21 de febrero de 2008

Parte 2: Ciclo de vida y modelos de datos

Tema 2: Modelos de datos
2.1.

Definiciones

2.1.1. Evolucin y definicin

Al principio no existan los modelos de datos, por ello, la informacin se agrupaba en
ficheros dependientes de la aplicacin. Posteriormente, intentaron hacerse ms genricos; y
con la aparicin de las BBDD ya se comenz a trabajar con modelos, es decir, representaciones
de la realidad.
La clave est en la abstraccin: modelador consiste en abstraer la realidad y obtener
una representacin. El modelo es la herramienta que nos permite obtener la representacin;
el esquema es el resultado de aplicar el modelo a un caso concreto, es decir, la
representacin.
2.1.2. Universo del discurso/mundo real
Habitualmente al problema se le llama universo del discurso. Es, del mundo real, lo
que el diseador considera relevante para un problema en un caso concreto. Como dijimos
antes, el modelo es una herramienta de representacin. El esquema son los elementos
relevantes obtenidos del universo del discurso mediante el modelo. Dependiendo del
universo del discurso habr unos u otros elementos relevantes; por ello, puede haber varios
esquemas con el mismo universo del discurso a partir de varios modelos.
2.1.3. Objetivos de un modelo de datos
Bsicamente hay dos objetivos:
2.2.

Formalizar (razonar).
Disear (construir).

Aspectos de un modelo de datos

El modelo de datos tiene una serie de propiedades:
-

Estticas: elementos que siempre pertenecen, como las estructuras de datos.

Representados por el lenguaje de definicin de datos.
Dinmicas: representan la evolucin de los datos, es decir conjunto de
instrucciones para manejar las estructuras.

2.2.1. Esttica
Dentro de las propiedades estticas nos encontramos con:
-

Objetos permitidos: los elementos representados por el modelo (dependen de l).

Objetos prohibidos: Hay elementos que no se pueden representar.
Ejemplo: En el modelo relacional los elementos deben tener un nico valor. No
sera vlido por ejemplo:
aficin
{ftbol,cine,teatro}

Pgina 14

Bases de Datos
21 de febrero de 2008
2.2.2. Dinmica:
- Seleccin
o Conjunto
o Ocurrencia individual
- Accin
o Consulta
o Modificar
Altas = Inserciones
Bajas = Borrados
Actualizaciones
Necesitamos lenguajes para niveles:
-

Lgico / Conceptual:
o Conceptuales: mayor nivel de abstraccin (ms potente)
o Convencionales: implantacin (SGBD)
Fsico

2.2.3. Restricciones de integridad

Hay dos tipos de restricciones:
-

Restricciones inherentes al modelo.

Restricciones de usuario: hay casos que no pueden ocurrir en el mismo universo
del discurso.
o Reconocidas: el sistema permite definir esa restriccin.
o No reconocidas: el sistema no puede definir algunas cosas, por lo que hay
que programar las restricciones a mano.

Pgina 15

Bases de Datos
21 de febrero de 2008

Tema 3: Ciclo de vida de las Bases de Datos

3.1.

Diseo dirigido por procesos y diseo dirigido por datos

A la hora de representar los datos del sistema hay dos diseos:
-

Dirigido por procesos: El esquema de la BD se deriva directamente de las

necesidades que tengan los procesos.
Dirigido por datos: Los datos se organizan a partir de los propios datos que existen
y se necesitan, independientemente de cmo debe trabajarse con ellos. Se deriva
la estructura de la Base de Datos de la semntica de los datos.

Los problemas de uno son las ventajas del otro: si la estructura de datos est
organizada por los procesos que tenemos es muy eficiente, si bien, si cambian los procesos, la
estructura ya no es vlida.
Generalmente se utiliza el diseo dirigido por datos (primero miras qu hay y luego
qu hay que hacer), ya que los procesos es normal que cambien. El diseo dirigido por
procesos se utiliza en lugares en los que la eficiencia es esencial, como en los sistemas en
tiempo real o en aquellos en que los procesos no suelen cambiar.
3.2.
Ciclo de vida en cascada
Se compone de las siguientes fases:
1.
2.
3.
4.

Anlisis de requisitos.
Diseo (estructura) conceptual.
Diseo lgico.
Refinamiento por el uso: se adapta la estructura de la Base de Datos de forma limitada
para mejorar el rendimiento.
5. Diseo fsico: conocida la estructura de la Base de Datos hay que disear la estructura
fsica que tendr (rboles, ndices)
6. Implementacin: Usando el lenguaje de definicin de datos se definen los datos; luego
se definen los procesos.
7. Prueba: Nada garantiza que la implementacin est bien hecha, as que hay que
realizar pruebas para comprobar que se cumplen los requisitos (por ahora no hay
forma de que esto se haga de forma automtica). Se realizan dos tareas:
a. Monitorizacin: Comprobar qu est pasando para tomar las decisiones
adecuadas.
b. Mantenimiento: Una vez terminado e instalado, puede necesitarse cambiar
procesos o mismamente datos.
3.3.

Aplicacin del ciclo de vida

Realizaremos un ejemplo con todas las fases para entenderlas mejor. El universo del
discurso es una empresa con clientes, vendedores y pedidos. Los clientes hacen pedidos a los
vendedores.

Pgina 16

Bases de Datos
21 de febrero de 2008
3.3.1. Anlisis de requisitos
Mediante entrevistas con el cliente tenemos que averiguar los requisitos. Es una labor
muy difcil, a partir de la cual se obtendr el documento de requisitos.
Habr un diccionario de datos en el que lo nombres de las cosas estarn descritos para
evitar ambigedad de la siguiente forma:

3.3.2. Diseo conceptual

Debemos dar una especificacin en el modelo conceptual del universo del discurso.
Generalmente no se puede abordar todo el sistema de un golpe por ser demasiado grande,
sino que se divide en subsistemas para tratarlo ms fcil; de esta forma se obtienen diferentes
vistas que debern ser integradas:
-

Vista Cliente:

Vista producto:

Integracin de las vistas:

3.3.3. Diseo lgico

Transformamos lo anterior en modelo relacional (dentro de lo posible, ya que lo
anterior tiene ms semntica).
Cliente

DNI
1

Vendedor

n-vend
666
777

nombre_cliente
Paco

nombre-vend
Eddie
Melndez

Pgina 17

n-vend
777

Bases de Datos
21 de febrero de 2008
Pedido

n-ped
1

fecha-ped
10/10/1980

Producto

total-ped
1000

n-prod

des-prod

DNI
1

n-vend
666

Cmo asociamos cada pedido con un cliente? Introduciendo en la columna Pedido la

clave primaria del cliente, en este caso DNI; y de igual manera con el n-vend. De igual forma
para saber qu vendedor gestion el pedido.
Otro aspecto que nos surge es decir qu productos tiene un pedido; pero para esto no
sirve aadir columnas para cada producto de forma que n_prod, n_pro2 Para las relaciones
entre pedidos y productos: 1 fila por cada producto de la siguiente forma:
Incluye

n-ped
1
1

n-prod
A
B

Son las claves externas. La clave es la unin de las dos claves externas.
En esta fase tambin hay una etapa de normalizacin, para lo que por ahora nos vale
con eliminar la redundancia del modelo. Tal y como est ahora el ejemplo no tenemos
redundancia as que aadiremos atributos para explicar lo que es la redundancia y cmo se
elimina.
Vendedor

n-vend
666
222

Categoria
C1
C1

dias_vac
30
30

Hay repeticin de innecesaria de informacin, lo que implica un desperdicio de

espacio. Para eliminarlo el proceso de normalizacin crea lo siguiente:
Vendedor

n-vend
666
222

Convencio
vacaciones

Categoria
C1
C1

Categoria

dias_vac

C1
C2

30
45

3.3.4. Refinamiento por el uso

En esta etapa nos centraremos en los procesos, adaptndolo de forma limitada
teniendo en cuenta las necesidades de los procesos para mejorar el rendimiento. A la hora de
realizar la adaptacin habr que favorecer unos procesos sobre otros, y para ello evaluamos la

Pgina 18

Bases de Datos
21 de febrero de 2008
prioridad de dichos procesos. Para obtener esa prioridad debemos realizar la evaluacin
teniendo en cuenta los siguientes criterios:
-

Volumen de datos: A mayor volumen, mayor prioridad.

Frecuencia del proceso: A mayor frecuencia, mayor prioridad.
Complejidad del proceso, aunque tiene ms importancia el volumen.
Importancia para el negocio

Ejemplo: el proceso que controla la temperatura del reactor: poco volumen, pocos datos,
frecuencia nula muy importante.
3.3.5. Diseo fsico
Compone dos tareas principales: la definicin de ndices y el agrupamiento (clustering).
Los ndices son algo que tienen todos los productos por lo que hay que realizarlo para
todos. Son por donde buscamos: las claves y las claves externas. Aunque tambin se pueden
definir ndices por otros campos pero ocupan espacio y ralentizan las modificaciones por lo
que hay que mirar si compensa. Esta tarea tambin est estandarizada en SQL.
El agrupamiento (clustering) consiste en agrupar los datos que muy probablemente se
pretende acceder juntos. Ejemplo: dado un cliente, es posible que quieras saber qu cuentas
tiene por lo que agruparemos en la misma zona de disco el cliente y sus cuentas.
3.3.6. Implementacin
La implementacin mediante el lenguaje de definicin de datos creamos el esquema.
Ejemplo:
CREATE TABLE Cliente
(
DNI INTEGER,
nombre_cuenta CHAR(30),

n-vend,

FOREIGN KEY n-vend

REFERENCES vendedor
);
Con FOREIGN KEY podemos hacer restricciones de integridad al aadir una clave
externa. Ya que con la implementacin tambin podemos implementar las restricciones. Por
ejemplo: al intentar aadir un vendedor inexistente a un cliente, el motor de evaluacin
consultar el diccionario de datos, ver que n-vend es una clave externa, ir a la tabla de
vendedor, buscar, no lo encontrar y por ello no lo dejar aadir.

3.3.7. Pruebas
Lo probaremos con las dos tcnicas que nombramos anteriormente:
-

Monitorizacin: realizar cambios a nivel fsico de forma que no haya que tocar las
aplicaciones para mejorar el funcionamiento.

Pgina 19

Bases de Datos
21 de febrero de 2008
-

Mantenimiento: si lo hemos hecho todo bien el mantenimiento ser mucho ms

barato.

Pgina 20

Bases de Datos
21 de febrero de 2008

Parte 3: Diseo conceptual: Modelo Entidad Relacin

Tema 4: Modelo Entidad - Relacin
4.1.

Introduccin y elementos fundamentales

Tiene sus orgenes en los aos 70 con Peter Chen. Es un modelo lgico basado en
objetos, destinado a la fase de diseo lgico, pero en general es un modelo conceptual para
realizar diseo conceptual. Dispone de notacin grfica; si bien no est estandarizada, de alto
nivel, de forma que se puede entender los grficos sin necesidad de demasiados
conocimientos.
4.1.1. Entidades y conjuntos de entidades
Una entidad es una cosa que existe por s misma y se puede distinguir de otras.
Pueden ser concretas o abstractas. Las entidades deben pertenecer a un conjunto de
entidades (clases).
Las entidades del universo de discurso tienen atributos que las describen, aquellos que
tienen sentido en el universo del discurso al que pertenecen. Todas las entidades
pertenecientes a un conjunto de entidades tienen los mismos atributos. Estos atributos tienen
un dominio de valores. Ejemplo: conjunto: {{(DNI, 1), (nombre-cli, Paco)-, ,(DNI, 2), (nombrecli, Pepe)--. Aunque el orden de los atributos no importa se designa un orden por omisin
definido en algn sitio.
Aunque los trminos correctos son conjunto de entidades y entidades, en
ocasiones se usa entidades y ocurrencias. Y a veces se mezclan varias. Tambin es
importante tener en cuenta que puede haber conjuntos varios de un mismo esquema
La notacin es la siguiente:
-

Conjunto de entidades:

Atributos:

Atributos identificativos (claves):

Ejemplo:

4.1.2. Relaciones y conjunto de relaciones

Las entidades pueden asociarse mediante una relacin. Varias relaciones con el mismo
significado forman un conjunto de relaciones.
Entre dos conjuntos de entidades no tiene por qu haber un nico conjunto de
relaciones, sino tantas como asociaciones de distinto tipo existan. El mximo de relaciones

Pgina 21

Bases de Datos
21 de febrero de 2008
entre dos conjuntos de entidades es el producto cartesiano de las entidades. El grado es el
nmero de conjuntos que asocia una relacin. Segn el grado, las relaciones pueden ser:
-

Binarias:

relaciones

entre

Ternarias:

N-arias: relaciones entre n entidades (muy infrecuente).

Unarias/reflexivas: asocian a la misma entidad:

relaciones

entre

dos

entidades

tres

entidades

(lo

ms

(poco

usado):
frecuente):

Del mismo modo que las entidades tienen atributos, las relaciones tambin pueden
tenerlo. Pero el valor de cada atributo depender de la relacin concreta. Por ejemplo: en la
relacin es titular de, el atributo ltima fecha de acceso: Si Juan y Pepe son titulares de la
misma cuenta cada uno tendr su propia ltima fecha de acceso; si se quisiera disponer
nicamente de la ltima fecha de acceso general se quitara de la relacin y se pondra en
cuenta.
4.2.

Restricciones de integridad

4.2.1. Restricciones de cardinalidad: uno / muchos

Indica, dentro de un mismo conjunto de relaciones con cuntas entidades se relaciona
del conjunto destino. Generalmente la cardinalidad es de 1 a n. La representacin:
-

N: Se representa con:
1: Se representa con:

. No hay restriccin
. Hay restriccin, mximo 1.

Slo un cliente cada cuenta, cardinalidad 1.

Los diferentes tipos de relaciones son las siguientes:
-

Relacin muchos-a-muchos:

Relacin muchos-a-uno:

Relacin uno-a-uno:

Relaciones uno-a-muchos:

La cardinalidad depende tambin segn el universo del discurso. Cuando no se dice

nada, interpretamos la cardinalidad como mxima. Tambin hay cardinalidad mnima:

Pgina 22

Bases de Datos
21 de febrero de 2008
-

0: Ninguna, no hay restriccin. En el ejemplo, un cliente no tiene porqu tener

cuenta:

1: Tiene que haber al menos una, restriccin. En el ejemplo, toda cuenta debe
tener al menos un cliente (titular).

Combinando los dos obtenemos la relacin en que cada cliente podr ser titular de
entre 0 y 1 cuenta. A su vez, las cuentas pertenecern a un nico cliente, y toda
cuenta pertenecer a un cliente, al menos.

Rangos: En el caso de querer poner valores diferentes se utilizan rangos (m,n):

Tambin hay que tener en cuenta que pueden tener papel o rol que es la etiqueta que
se puede poner en un extremo de una relacin para describirla mejor. Se utiliza para aclarar
bien una relacin que podra no ser del todo clara sin ella, como por ejemplo, en relaciones
reflexivas (sobre la propia entidad).

Ejemplo:
4.2.2. Superclaves, claves candidato y clave primaria
Una clave es el conjunto de atributos que permiten identificar de forma nica una
entidad en un conjunto de entidades.
-

Superclave: No se puede repetir. Ejemplo: {DNI} o {DNI, ciudad}.

Clave candidato: Superclave en la que no hay atributos superfluos. Ejemplo: {DNI}
lo es. {DNI, ciudad} no lo es.
Clave primaria: De todas las claves candidato se escoge una para hacer de forma
primaria o principal de identificacin. En este caso DNI.

4.2.3. Clave primaria de un conjunto de relaciones

Ser igual la relacin que sin ellas, pero dependiendo del universo del discurso el
atributo puede formar parte de la clave. Si perteneciese, permitira asociar dos entidades con
la misma clave.
El atributo de una relacin es un dato que describe la relacin. Ejemplo: si la relacin
entre cuenta y cliente tuviese un atributo fecha_acceso considerado como la ltima fecha en
la que se accedi a la cuenta no contara (se sobrescribira). En cambio, si se registrasen todos
los accesos, s pertenecera a la clave.

Pgina 23

Bases de Datos
21 de febrero de 2008
[Cl P (E1) Cl P (E2) {A1, A2,, An}

es una Superclave]

DNI

N cuenta
1
2
2

fecha
1 10/01/2005
2 11/11/2002
3 05/05/2005

Puede haber diferentes relaciones:

-

N-n: La clave candidato es DNI N cuenta. No puede haber repetidos

ClP(E1)
ClP(E2).
1-n: La clave candidato es n cuenta. Ya que slo puede tener un cliente cada
cuenta, por tanto, cada cuenta slo puede salir una vez: clave. Cada vez que haya
1-n el n es la clave candidato.
1-1: Salen dos claves candidato: cliente y n cuenta. Las dos unidas son Superclave:
un clave candidato por entidad.

COMO MNIMO SIEMPRE HAY UNA CLAVE PRIMARIA.

4.2.4. Dependencia por existencia.
Sucede cuando la existencia de una entidad depende de la existencia de otra entidad.
Por ejemplo:

La existencia del paso a nivel depende de la existencia de la va. Parecido a la herencia.

Cuando se borre la va se debera borrar el paso a nivel. Grficamente se indica con la lnea que
une las une ms gruesa de lo normal.
4.2.5. Entidades fuertes y entidades dbiles
Las entidades dbiles son entidades que por s mismas no tienen atributos suficientes
para formar claves. Para distinguirlas se utiliza un discriminador, que es la clave que permite
distinguir entre entidades de un conjunto de entidades dbiles. La clave primaria de un
conjunto de entidades dbiles est formada por la clave primaria de la entidad de la entidad
de la que depende y su discriminador.
Los conjuntos de entidades dbiles s tienen clave primaria por, si bien se construye de
forma diferente que las entidades fuertes. Ejemplo:

Pgina 24

Bases de Datos
21 de febrero de 2008
Para distinguir los pasos a nivel (ya que como vemos hay dos (1,3)) se necesita acudir a
entidades externas, ya que aunque se forme la clave primaria con todos los atributos no se
podra distinguir entre algunas debido a que Paso a Nivel es una entidad dbil.
Ahora bien, dentro del conjunto de pasos a nivel de una va pueden distinguirse por ser
discriminador el nmero de paso a nivel

De esta manera observamos: n va es la clave primaria de la entidad a la que

pertenece. N paso es el discriminador. A la relacin se llama bitcora, es un nombre genrico
para las relaciones entre entidades dbiles y fuertes.
Hay que tener en cuenta que las entidades dbiles dependen de otras, que a su vez
puede ser dbil o fuerte.
Pasando a tablas el ltimo ejemplo quedara de la siguiente forma:
Paso a Nivel

n va
1
1
1

n paso
1
2
3

p. Km.
3
6
3

Por otra parte, las entidades fuertes no dependen de otra entidad para tener clave.
Partiendo del ejemplo anterior tendramos:
Va

n va
1

ruta
"OVD-SS"
"OVD-SANT"

La bitcora no hace falta ponerla, la informacin ya est en la tabla de la entidad dbil.

4.3.

Reduccin de diagramas E-R en tablas

Cada conjunto del diagrama generar una tabla con igual nombre. A continuacin del
nombre la clave primaria y el resto de atributos.

Partiendo de este ejemplo lo pasaremos a tablas.

Pgina 25

Bases de Datos
21 de febrero de 2008
Cliente

DNI
1
2

nombre
Paco
Carmen

Cuenta

n cuenta
1
2
3
4

Saldo
100
200
300
400

DNI
1
1
2
-

Fecha
10/10/2004
11/11/2005
11/10/2002
-

Si no fuera obligatorio que una cuenta tuviera un titular (relacin 0-N) se dejan nulos
los campos del duelo de la cuenta. Aadiendo fecha en la cuenta, no es necesario poner la
tabla de titular. Esto sucede cuando se da relacin con final en: .
4.4.

Construcciones avanzadas

4.4.1. Generalizacin
Es como la herencia de Java. Cada entidad de un nivel ms alto debe pertenecer a un
conjunto de entidades ms bajo; en el ejemplo: puede existir una Cuenta Corriente o una
Cuenta de Ahorro pero no una Cuenta, slo sus hijos.

La relacin con Cuenta e ISA tiene que ser con un trazo grueso. Es de tipo TOTAL.
4.4.2. Especializacin
Es parecido a la generalizacin pero en este caso es de tipo PARCIAL; eso significa que
algunas entidades de nivel ms alto pueden no pertenecer a algn conjunto de entidades de
nivel ms bajo. Para representarlo la lnea se dibuja ms fina.

Los conjuntos de entidades de nivel ms bajo pueden ser:

Pgina 26

Bases de Datos
21 de febrero de 2008
-

Disjuntos: una entidad no puede pertenecer a ms de un conjunto de entidades de

nivel ms bajo. Es decir o es B o es C. (Como el ejemplo)
Solapados: La misma entidad puede pertenecer a ms de un conjunto de entidades de
nivel ms bajo en una generalizacin simple. Se representa:

4.4.3. Paso a tablas de especializacin y generalizacin

A tablas sera algo como:
-

Cuenta(n cuenta, saldo)

CuentaAhorro(n cuenta, inters)
CuentaCorriente(n cuenta, puntos)

Vale tanto para generalizacin como para especificacin pero hace falta explicar cmo
interpretarlo ya que se pierde informacin al pasar a tablas.
Si slo hay CuentaAhorro y CuentaCorriente y no hay cuentas a secas (generalizacin)
podra hacerse lo siguiente:
-

CuentaAhorro (n cuentasaldo, inters)

CuentaCorreinte(n cuenta, saldo, puntos)

Otra forma sera hacer una sola tabla con todo y valores nulos para indicar qu tipo de
cuenta es con algo as:
-

Cuenta (n cuenta, inters, puntos). Si puntos es nulo, no es una CuentaCorriente. Si

inters es nulo, no es una CuentaAhorro y si ambos son nulos es una Cuenta.

Esta ltima opcin tiene la ventaja de que no hay buscar en varias tablas si no todo en
la misma pero tambin es un gran inconveniente ya que si hay muchos valores nulos hay una
mala gestin del espacio.
Si usamos tres tablas, para saber qu tipo de cuenta es habra que buscar por nmero
de cuenta especficos para ver dnde estn. Una solucin a este problema podra ser
introducir un atributo discriminador tipoCuenta en cuenta para que nos diga de qu tipo es;
el problema es que hay que mantener la coherencia con el resto de la clase.
4.4.4. Agregacin
El modelo E-R prohbe relaciones entre relaciones pero puede haber casos en los que
convenga. Para ello surge la agregacin. Para entenderlo, un ejemplo:

Pgina 27

Bases de Datos
21 de febrero de 2008
Es una relacin de grado variable, segn el nmero de mquinas que se use; y eso no
es vlido.
En la situacin actual, Cmo podemos asociar ms de una mquina? Asociaramos
una nueva mquina a la relacin? Dejara de ser genrico y necesitamos tener una relacin
ternaria para evitar, otra alternativa sera una relacin ternaria pero Cmo representaramos
si no se usa una mquina? No se le pueden quitar enlaces a la relacin ternaria siempre tiene
que haber. Podra ponerse con una mquina cualquiera y valor 0 o nulo, pero uno es malo
diseo. Pero ninguna de las anteriores posibles soluciones nos vale por lo que es necesario la
agregacin.
La agregacin consiste en convertir un conjunto de relaciones en un conjunto de
entidades. As:

Para ello, tendramos dos opciones:

Pasando a tablas el ejemplo:

empleado (dni);
proyecto(c_proyecto, );
mquina(c_maquina,);
trabaja(dni, c-proyecto, n_h);
usa(dni,c-proyecto,c-maquina, n_unidades);

En caso de que un empleado slo pudiera trabajar en un nico trabajo:

trabaja(dni, c_proyecto, n_h);
usa(dni,c_maquina, n_unidades);

Vamos a ver un ejemplo de cmo representar lo mismo con agregacin y con

entidades con relaciones:

Pgina 28

Bases de Datos
21 de febrero de 2008

Ambas opciones son vlidas aunque algunas metodologas recomiendan alguna ms

que otra.

Pgina 29

Bases de Datos
21 de febrero de 2008

Tema 5. Modelo Entidad- Relacin extendido

5.1.

Relaciones ternarias
Asocian tres entidades. Se utiliza cuando las tres relaciones son necesarias. Si una de
las patas de la relacin slo aparece a veces no es una relacin ternaria. Se podra usar una
agregacin en la direccin principal (las dos entidades siempre relacionadas).
En ocasiones tenemos cosas como las siguientes (ejemplo):
css

cliente
Pepe
Pepe
Juan

cuenta
1
1
1

sucursal
A
B
C

Cmo sera la cardinalidad?

-

Una pareja cliente-cuenta slo se puede asociar a una nica sucursal.

Una pareja cliente-sucursal slo se puede asociar con una nica cuenta.
Habra cardinalidades mnimas?

No tiene sentido indicarlas en las relaciones ternarias ya que son casos tan
degenerados que casi nunca se darn.
Se podra obligar a unas entidades a salir en una relacin?

El punto indica que toda entidad cuenta debe participar al menos una vez en la
relacin, es decir, estar asociada a un cliente y a una sucursal. Como consecuencia, en
relaciones binarias tenemos la siguiente equivalencia:

Como consecuencia de ello, en las tablas no se permitira ninguna de las dos opciones:
nombreCliente
Pepe
Pepe
Pepe

n_cuenta
1
1
2

n_suc
A
B
A

Todo esto, debido a que Pepe slo puede tener una cuenta en una sucursal. Por lo que
no puede repetirse el nmero de cuenta ni el nombre de sucursal con el nombre de cliente.

Pgina 30

Bases de Datos
21 de febrero de 2008
5.2.

Caractersticas extendidas

5.2.1. Atributos multivaluados

Los atributos en un diagrama E-R generalmente se asocian directamente en columnas
para las tablas apropiadas. Sin embargo, los atributos multivaluados son una excepcin ya que
para estos atributos se crean tablas nuevas.
Ejemplo: aficin = {ftbol, cine, teatro} a tablas:
Persona

DNI
1
1

Nombre
Pepe
Pepe

Aficin
ftbol
cine

No est permitido ya que repetimos datos como por ejemplo el DNI 1 y el nombre
Pepe para las dos aficiones. Por lo que debera ser as:
pers/afici

DNI
1
1

aficin
ftbol
cine

En entidad-relacin, una forma de representarlo menos compacta y que se lee peor es

la siguiente:

La forma en la que lo representaremos nosotros es la siguiente:

As damos la idea de que la "aficin" slo interesa

con respecto a las personas. De la otra forma, tambin
interesara por si slo

5.2.2. Atributos compuestos

Un atributo compuesto sera por ejemplo fecha que le componen: da, mes y ao. En
las BBDD relacionales no existen los atributos compuestos. Aunque s hay por compatibilidad
hacia atrs al no poder hacer [Link] se pierde mucho la relacin, por lo que no se utilizan.
5.2.3. Atributos derivados
Se trata de atributos que se calculan a partir de otros. Tambin se puede documentar
la frmula usada. Ejemplo de las formas de representarlo:

Estrictamente no hace falta guardar el valor ya que se calcula sobre la marcha. En caso
de que la frmula sea muy compleja (si hay que mirar muchas tablas para ello) se pre calcula,
se guarda en la BD y, si cambian los datos, se recalcula; si se solicita se da la de la BD, que

Pgina 31

Bases de Datos
21 de febrero de 2008
acta como una memoria cach. Hacerlo de una u otra forma depender de la tasa de
actualizacin del atributo, de la complejidad de la frmula, etc.
El problema de pre calcular es la inconsistencia, porque el atributo que usaste para
calcular puede no estar actualizado correctamente o cualquier otro problema. De la otra
forma, siempre es correcto.
Tambin podra haber relaciones derivadas e incluso hasta entidades. Ejemplo:

Por ejemplo: si por las caractersticas del proyecto tienes que vivir en la ciudad, la
relacin vive se puede calcular indirectamente por otro lado. Puede ser interesante reflejarlo
para que se vea que existe la relacin. Tambin es interesante representar en el diagrama los
atributos y dems derivados para que se sepa que existen, que tienen un nombre, que estn
en el diccionario de datos... y que sea derivado o no tambin depende de la semntica del
atributo (por ejemplo: si no tiene nada que ver que trabajar en un proyecto y vivir en una
ciudad no puede ser una relacin derivada.
5.3.

Restricciones que afectan a las relaciones

Veremos restricciones que se establecen entre un conjunto de entidades denominado
raz y un conjunto de entidades denominado hoja y con relaciones entre ellos.
5.3.1. Exclusin

Con el ejemplo anterior no se pueden mezclar entre ellos elementos de un mismo

pedido, es decir, si pides tanques, slo puede haber tanques en el pedido. Por ello, si sale una
relacin por tanques no puede por las otras. Se representa con el crculo entre las relaciones
involucradas. Slo uno de los conjuntos puede tener elementos.
5.3.2. Subconjunto
Ejemplo: en los colegios de economistas hay colegiados economistas, y adems son
asesorados por asesores financieros. Los asesores van a ser economistas y queremos poner
como restriccin que han de estar colegiados. Por tanto, el conjunto de asesores ha de ser un
subconjunto de los economistas colegiados.

Pgina 32

Bases de Datos
21 de febrero de 2008

Se fija una entidad raz fija arriba y se calculan las relaciones con los de abajo.

Pgina 33

Bases de Datos
21 de febrero de 2008

Parte 4: Diseo lgico: Modelo relacional

Tema 6. Modelo relacional
6.1.

Introduccin
E.F. Codd el ao 1969 invent el modelo relacional.

El modelo relacional es un modelo lgico / conceptual orientado a registros, de ms

bajo nivel que el E-R. Desbanc a los anteriores modelos (jerrquico y en red) gracias a:
-

Comodidad de uso: para los usuarios es fcil entender el concepto de tabla.

Eficiencia: Llevan 30 aos de optimizacin. Aunque al principio no hubo demasiada con
el tiempo se ha logrado mucha.
Fundamento matemtico muy slido. Est mucho ms formalizado que otros modelos.

El modelo relacional suele coger los datos y organizarlos mediante tablas que nosotros
llamaremos relaciones; los atributos, columnas; y las filas, tuplas.
6.2.

Estructura de las BBDD relacionales

Primero haremos la relacin:
Tablas = relaciones
Atributos = columnas
Filas = tuplas
Ejemplo:
Cliente

DNI
1
2

nom_cli
Paco
Carmen

Las tablas se llaman relaciones porque lo que hacen es asociar, relacionan los
atributos; esto proviene del concepto matemtico de relacin.
Las tuplas no tienen un orden, al igual que los atributos.
Hay que distinguir entre el esquema y las relaciones individuales: de un mismo
esquema pueden declararse varias relaciones individuales. Ejemplo:
E_cliente=(DNI,nom_cli)
cliente(E_cliente)
cliente_moroso(E_cliente)

Tambin debera especificarse el dominio de un atributo (aunque aqu podramos

deducirlo ya que est dentro del dominio de los dnis en general: un nmero de 10 cifras). En
caso de que no lo conociramos:
Dom_DNI = N
E_cliente=(DNI:Dom_DNI, nom_cli)

Pgina 34

Bases de Datos
21 de febrero de 2008
En las ltimas versiones de SQL se pueden definir dominios, pero la mayora lo sigue
definiendo manualmente.
Las columnas deben tener un dominio, que debera especificarse. Aunque lo ideal es
que el dominio sea gestionado por el sistema en ocasiones no se puede. Por ejemplo: los
nombres de clientes podemos decir que son cadenas pero no podemos rechazar nombre como
vx36. Esto es labor del operario humano controlarlo. Los dominios restringen los valores
posibles, es una restriccin de integridad.
Las columnas de las tuplas no son multivaluadas.
6.2.1. Restricciones de las relaciones
1. Integridad de entidad: Garantiza que no hay elementos repetidos en un conjunto,
es decir, que no existen tuplas repetidas en una relacin, para ello no hay que
meter claves repetidas.
2. Integridad referencial: Las claves externas slo pueden tomar valores que estn en
la tabla de la que son claves primarias. Siempre se cumple que el sistema rechaza
las claves externas inexistentes.
Si estas dos relaciones NO se cumplen NO es una base de datos relacional.
Ejemplo:
cuenta (nc, saldo, DNI)
cliente (DNI, nombre_cli, )

DNI relaciona las dos entidades.

Ahora veremos un ejemplo de modelo relacional con una base de datos:
sucursal (num_suc, nombre_suc, activo, ciudad);
deposito(num_suc, nombreCH, num_cuenta, saldo);
prestamo(num_prestamo,num_suc, nombreCH, importe);
cuentaHabiente(nombreCH, calle, ciudadCH);

Este ejemplo es el que usaremos en todos los ejemplos a partir de ahora.

-

LMD:

Pgina 35

Bases de Datos
21 de febrero de 2008

o Consulta
o Modificacin
Lenguajes formales
o Procedimentales
o Declarativos

6.3.

Lenguajes de consulta formales: lgebra relacional

Es un lenguaje algebraico: operadores y operandos. Aqu los operandos sern las
relaciones.
6.3.1. Operaciones fundamentales
Las operaciones bsicas son:
-

Seleccin
Proyeccin
Producto cartesiano
Unin
Diferencia
Renombramiento
Iremos describiendo una a una cada operacin:

[Link].

Seleccin ( )
Devuelve un subconjunto de una relacin. Es un filtro.

Ejemplo: (ciudad=Oviedo^DNI>9.200.000)(cuentaHabiente)
que se aplica a cada tupla.
[Link].

Como subndice, la condicin

Proyeccin ( )
Para quedarte con las columnas, los atributos que se quieran.
Ejemplo:

nombreCH,calle(cuentahabiente)

resultado

obtenemos:

nombreCH
Pepe
Juan

calle
Ura
Valdes Sals

[Link].

Producto cartesiano (x)

Haciendo el producto cartesiano de dos conjuntos se obtiene otro con todas las
posibles combinaciones de los elementos de los dos conjuntos concatenados.
Ejemplo. Dadas estas 2 tablas:
CH

nombreCH
calle
Pepe
Ura
Juan
Valds Sals

Pgina 36

ciudad
Oviedo
Gijn

Bases de Datos
21 de febrero de 2008
depsito

num_suc
A
B
A

nombreCH num_cuenta
Pepe
1
Juan
2
Juan
1

saldo
100
200
100

El resultado del proyecto cartesiano:

Chxdepsito [Link]
Pepe
Pepe
Pepe
Juan

calle
Ura
Ura
Ura
VS

ciudad
Oviedo
Oviedo
Oviedo
Gijn

num_cuenta n_suc [Link] saldo

1
A
Pepe
100
2
B
Juan
200
1
A
Juan
100
1
A
Pepe
100

Los atributos son la concatenacin de los dos.

Es la operacin ms importante porque es la que nos permite relacionar dos tablas.
Cuando hay ambigedad en los nombres de las columnas se prefija: [Link].
Es imposible hacer una seleccin de un producto cartesiano.
[Link].

Renombramiento ( )
Se utiliza para dar nombre a los resultados del lgebra relacional y as referirse a ellos.
Como las relaciones se consideran expresiones se pueden usar para darles un nuevo nombre.
Ejemplo: Sacar los nombre de los que viven donde los que se llaman pepe.
CH(nCH, calle, ciudadCH)
[Link]=Pepe(CH x CH). Se hace producto de una tabla consigo misma, as que para
distinguir entre una tabla y la segunda tabla por lo que hay que renombrar adems de repetir
datos. La consulta debera ser:
[Link]=[Link] ^ [Link]=[Link]( [Link]=Pepe)(CH

CHPepe(CH)))

Ahora sacamos los nombres de las personas que viven donde pepe. Si no queremos
sacar los nombres de Pepes debemos aadir al primer ^[Link] [Link] Pepe.
[Link].

Unin ( )
Las dos tablas a unir deben tener mismo nmero y mismo tipo de atributos; tienen que
ser relaciones compatibles.
Ejemplo: sacar las personas que tienen cuenta, prstamo o ambos en una sucursal
llamada Perryridge.
nCH ( nsuc=Perryridge

(prstamo))

Pgina 37

nCH

nsuc=Perryridge(depsito))

Bases de Datos
21 de febrero de 2008
[Link].

Diferencia ( )
Permite buscar las tuplas que estn en una relacin pero no en la otra.
Ejemplo: sacar la gente que tiene cuenta pero no prstamo
nCH ( nsuc=Perryridge

(prstamo))

nCH

nsuc=Perryridge(depsito))

6.3.2. Operaciones adicionales

Son aquellas que se pueden expresar en base a operaciones fundamentales:
[Link].

Interseccin
Producto natural
Divisin
Asignacin
Interseccin ( )
A (A B). Al igual que en la unin, las relaciones tienen que ser compatibles.
Ejemplo: sacar nombres de clientes de Oviedo con saldo > 100
[Link]

[Link].

[Link]= OVD [Link] > 100

[Link]=[Link](CH

x deposito)))

Producto natural (|><|).

A |><| B
A B( A.a=B.a^A.b=B.b^.(A x B)). Hace el producto cartesiano, se queda
con las filas cuyos atributos comunes son iguales (generalmente, y si la BD est bien
diseada, segn la clave primaria y la externa) y elimina las columnas repetidas).
Ejemplo: sacar nombres de clientes de Oviedo con saldo > 1000 (ltima
consulta).
[Link]( [Link]=OVD ^ [Link] >1000

(CH |><| deposito))

Ejemplo: encontrar clientes con cunetas con saldo > 1000 en sucursales de
Pekn y que el cliente sea de Oviedo.
[Link]( [Link]=OVD ^ [Link]>1000 ^ [Link]=Pekin

(CH |><| deposito |><|

sucursal))
[Link].

Divisin ( )
Permite conocer, por ejemplo, los clientes que tienen cuentas en todas las sucursales
de una ciudad.
Ejemplo: Encontrar clientes que tienen cuenta en al menos una sucursal de Oviedo.
nCH

[Link] = OVD

(deposito |><| sucursal)

Ejemplo 2: Encontrar clientes que tienen cuenta en todas las sucursales de Brooklyn.

Pgina 38

Bases de Datos
21 de febrero de 2008
nCH,nsuc(deposito)

nsuc ( [Link]= Brooklyn (sucursal)

[Link].

Asignacin ( )
Hace lo mismo que la asignacin en los lenguajes de programacin. Su evaluacin no
muestra ningn resultado
Ejemplo:
r

nCH,nsuc(deposito)

nsuc ( [Link]= Brooklyn (sucursal)

6.3.3. Conclusin
Hay consultas en AR que no se pueden hacer, como por ejemplo: consultas recursivas,
despieces (sacar todos los hijos de un nodo de un rbol, etc.). En estos casos, el SQL suele
complementarse con un programa escrito en C, por ejemplo.
6.4.

Clculo relacional
Se da la definicin o declaracin del resultado. En este lenguaje tenemos:
Tuplas: t. Las variables toman valores de tuplas.
Dominios: x. Toman valores en dominios: nombre, calle

6.4.1. Clculo relacional de tuplas

Ejemplo: = es de COMPARACIN, no de asignacin
t CH
t [nCH] = "Pepe"
t [nCH] = c [nCH]

Las consultas, en el clculo relacional de tuplas se expresan como: {t /P (t)}, es decir,

son el conjunto de todas las tuplas para que el predicado P es cierto.
Ejemplo: encontrar los clientes que viven en Oviedo:
{t(nCH) / t CH ^ t*ciudadCH+ = OVDSi slo quisiramos el nombre:
{t(nCH) / c CH ( c*nCH+ = t *nCH+ ^ c*ciudadCH+ = OVD) Ejemplo: encontrar los clientes que viven en Oviedo y tienen saldo > 1000)
{t (nCH) / c CH ( c*nCH+ = t *nCH+ ^ c*ciudadCH+ = OVD) ^ d deposito (d*nCH+ = c*nCH+ ^
d[saldo] > 1000)) }
Este ltimo ejemplo en lgebra relacional sera:

Pgina 39

Bases de Datos
21 de febrero de 2008
nCH ( [Link] = OVD ^ [Link] > 1000)

(CH |><| depsito))

En general encadenar dos existen ( ) suele desembocar en producto cartesiano

(|><|).
Casi lo mismo que se puede hacer con lgebra relacional se puede hacer en
clculo relacional, y viceversa. Seguimos con ejemplos:
Ejemplo: Clientes con cuenta o prstamo en Perryridge o con las dos cosas:
{ t(nCH) / d deposito (t*nCH+ = d*nCH+ ^ d*nSuc+ = Perryridge) V
(t[nCH] = p[nCH] ^ p*nSuc+ = Perryridge))

p prestamo

Ejemplo: Clientes con cuenta y prstamo. Igual que el ejemplo anterior pero
con V en vez de ^.
Ejemplo: Clientes con cuenta pero sin prstamo
{ t / d deposito () ^ ~ p prstamo ())Para todo ( ) e implica
Ejemplo: Clientes que tienen cuenta en todas las sucursales de Brooklyn.
{ t (nCH) /

s sucursal (s*ciudad_suc+ = Brooklyn ( d deposito (d*nsuc+ =

s[nsuc] ^ d[nCH] = t[nCH]))}

Ejemplo 2: Clientes (y ciudad) que tienen cuenta en todas las sucursales de su

ciudad.
{t (nCH)(ciudadCH) / c CH (c*nCH+ = t*nCH+ ^ c*ciudadCH+ = t*ciudadCH+) ^ s sucursal
((s[ciudad_suc] = c[ciudad_suc])
d deposito (d*nsuc] = s[nsuc] ^ d[nCH] =
t[nCH])))
Con el clculo relacional podemos obtener infinitas tuplas si ponemos una
condicin que cumplan infinitas cumplas, como por ejemplo: cuentas que no estn en
prstamo. Lo que vamos a hacer es restringir las expresiones que mira a expresiones
SEGURAS: evaluables por el ordenador (si se pueden evaluar siendo valores que estn
en la BD solamente) y terminan siempre.
6.5.

Las 12 reglas de codd

En la dcada de los 80 comenzaron a aparecer numerosos SGBD que se anunciaban
como relacionales. Sin embargo estos sistemas carecan de muchas caractersticas que se
consideran importantes en un sistema relacional, perdiendo muchas ventajas del modelo
relacional. Como ejemplo externo de esto sistemas relacionales eran simplemente sistemas
que utilizaban tablas para almacenar la informacin, no disponiendo de elementos como
claves primarias, etc.

Pgina 40

Bases de Datos
21 de febrero de 2008
En 1984 Codd public 12 reglas que un verdadero sistema relacional debera cumplir.
En la prctica algunas de ellas son difciles de realizar. Un sistema podra considerarse ms
relacional cuanto ms siga esas reglas.
La regla 0 es aquella que dice: Para que un sistema se denomine sistema de gestin de
bases de datos relacionales, este sistema debe usar (exclusivamente) sus capacidades
relacionales para gestionar la base de datos.
6.5.1. Regla de la informacin
Toda la informacin en una base de datos relacional se representa explcitamente en
el nivel lgico exactamente de una manera: con valores en tablas.
-

Por tanto, los metadatos (diccionario, catlogo) se representan exactamente igual que
los datos de usuario.
Puede usarse el mismo lenguaje (como SQL) para acceder a los datos y a los metadatos
(regla 4)
Un valor posible es el valor nulo, con sus dos interpretaciones:
o Valor desconocido (ejemplo: direccin desconocida)
o Valor no aplicable (ejemplo: empleado soltero no tiene esposa)

6.5.2. Regla del acceso garantizado

Para todos y cada uno de los datos (valores atmicos) de una Base de Datos
Relacional se garantiza que son accesibles a nivel lgico utilizando una combinacin de nombre
de tabla, valor de clave primaria y nombre de columna
-

Cualquier dato almacenado en una Base de Datos Relacional tiene que poder ser
direccionado unvocamente. Para ello hay que indicar: en qu tabla est, cul es la
columna y cul es la fila (mediante la clave primaria).
Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas
implementaciones. En estos casos, para lograr un efecto similar se puede hacer lo
siguiente:
o Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL)
o Crear un ndice nico sobre la clave primaria.
o No eliminar nunca el ndice.

6.5.3. Tratamiento sistemtico de valores nulos

Los valores nulos (que son distintos a la cadena vaca, blancos, 0,) se soportan en los
SGBD totalmente relacionales para representar informacin desconocida o no aplicable de
manera sistemtica, independientemente del tipo de datos.
-

Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento

sistemtico de los mismos.
Hay problemas para soportar los valores nulos en las operaciones relacionales,
especialmente en las operaciones lgicas.
Lgica trivaluada: Es una posible solucin. Existen tres (no dos) valores de verdad:
Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones
lgicas:

Pgina 41

Bases de Datos
21 de febrero de 2008

o Null Y null= null

o Verdadero Y null = null
o Falso Y null = Falso
o Verdadero O null = Verdadero
o Etc.
Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se
complica pues es ms difcil de entender.

6.5.4. Catlogo dinmico en lnea basado en el modelo relacional

La descripcin de la base de datos se representa a nivel lgico a la misma manera que
los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje
relacional a su consulta, igual que lo aplican a los datos normales.
-

En consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se

almacenan usando el modelo relacional, con todas sus consecuencias.

6.5.5. Regla del sublenguaje de datos completo

Un sistema relacional debe soportar varios lenguajes y varios modos de uso de
terminal (ejemplo: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje
cuyas sentencias sean expresables, mediante una sintaxis bien definida, con cadenas de
caracteres y que sea completo, soportando:
-

Definicin de datos
Definicin de vistas
Manipulacin de datos (interactiva y por programa)
Limitantes de integridad
Limitantes de transacciones (iniciar, realizar, deshacer) (Begin, commit, rollback).

Adems de poder tener interfaces ms amigables para hacer consultas, etc. Siempre
debe de haber una manera de hacerlo todo de manera textual, que es tanto como
decir que pueda ser incorporado en un programa tradicional.

Un lenguaje que cumple esto en gran medida es SQL.

6.5.6. Regla de actualizacin de vistas

Todas las vistas que son tericamente actualizables se pueden actualizar por el
sistema.
-

El problema es determinar cules son las vistas tericamente actualizables, ya que no

est muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son
actualizables.

Pgina 42

Bases de Datos
21 de febrero de 2008
6.5.7. Insercin, actualizacin y borrado de alto nivel
La capacidad de manejar una relacin base o derivada como un solo operando se
aplica no slo a la recuperacin de datos (consultas), sino tambin a la insercin, actualizacin
y borrado de datos.
-

Esto es, el lenguaje de manejo de datos tambin debe ser de alto nivel (de conjuntos).
Algunas bases de datos inicialmente slo podan modificar las tuplas de las bases de
datos de una en una (un registro de cada vez).

6.5.8. Independencia fsica de datos

Los programas de aplicacin y actividades del terminal permanecen inalterados a
nivel lgico cuandoquiera que se realice cambios en las representaciones de almacenamiento o
mtodos de acceso.
-

El modelo relacional es un modelo lgico de datos, y oculta las caractersticas de su

representacin fsica

6.5.9. Independencia lgica de datos

Los programas de aplicacin y actividades del terminal permanecen inalterados a
nivel lgico cuandoquiera que se realicen cambios a las tablas base que preserven la
informacin.
-

Cuando se modifica el esquema lgico preservando informacin (no valdra por

ejemplo eliminar un atributo) no es necesario modificar nada en niveles superiores.
Ejemplos de cambios que preservan la informacin:
o Aadir un atributo a una tabla base.
o Sustituir dos tablas base por la unin de las mismas. Usando vistas de la unin
puedo recrear las tablas anteriores.

6.5.10. Indepedencia de integridad

Los limitantes de integridad especficos para una determinada base de datos
relacional deben poder ser definidos en el sublenguaje de datos relacional, y almacenables en
el catlogo, no en los programas de aplicacin.
-

El objetivo de las bases de datos no es slo almacenar los datos, sino tambin sus
relaciones y evitar que estas (limitantes) se codifiquen en los programas. Por tanto en
una base de datos relacional se debe poder definir limitantes de integridad.
Cada vez se van ampliando ms los tipos de limitantes de integridad que se pueden
utilizar en los SGBDR, aunque hace poco eran muy escasos.
Como parte de los limitantes inherentes al modelo relacional (forman parte de su
definicin) estn:
o Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una tabla
primaria.
o Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe
existir en la relacin donde es primaria.

Pgina 43

Bases de Datos
21 de febrero de 2008
6.5.11. Independencia de distribucin
Una BDR tiene independencia de distribucin.
-

Las mismas rdenes y programas se ejecutan igual en una BD centralizada que en una
distribuida.
Las BDR son fcilmente distribuibles:
o Se parten las tablas en fragmentos que se distribuyen.
o Cuando se necesitan las tablas completas se recombinan usando operaciones
relacionales con los fragmentos.
o Sin embargo se complica ms la gestin interna de la integridad, etc.
Esta regla es responsable de tres tipos de transparencia de distribucin:
o Transparencia de localizacin. El usuario tiene la impresin de que trabaja con
una BD local (aspecto de la regla de independencia fsica).
o Transparencia de fragmentacin. El usuario no se da cuenta de que la relacin
con qu trabaja est fragmentada (aspecto de la regla de independencia lgica
de datos).
o Transparencia de replicacin. El usuario no se da cuenta de que pueden existir
copias (rplicas) de una misma relacin en diferentes lugares.

6.5.12. Regla de la no subersin

Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese
bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes
expresados en los lenguajes relacionales de ms alto nivel (una relacin (conjunto de registros)
de cada vez).
-

Algunos problemas no se pueden solucionar directamente con el lenguaje de alto

nivel.
Normalmente se usa SQL inmerso en un lenguaje anfitrin para solucionar estos
problemas. Se utiliza el concepto de cursos para tratar individualmente las tuplas de
una relacin. En cualquier caso no debe ser posible saltarse los limitantes de
integridad impuestos al tratar tuplas a ese nivel.

Pgina 44

Bases de Datos
21 de febrero de 2008

Ejercicios (E-R y paso a tablas)

1. Ejercicio 1
La secretaria del centro quiere una BD de gestin acadmica con datos sobre alumnos,
asignaturas, profesores y sesiones de clase.
-

Profesores: n registro, DNI, nombre.

Alumnos: DNI, nombre, n matrcula (expediente)
Asignatura: nmero de matriculados, cdigo Asignatura, descripcin.
Ha que saber nota del alumno en cada asignatura y qu profesor da cada asignatura.

Sesiones: hora inicio, duracin, lugar, da.

En primer lugar, cuando el enunciado dice cosas del estilo la secretaria del centro no
hay que poner una entidad para secretara puesto que no va a haber ms de una por lo que
todo lo que hagamos se va a referir a la misma.
Asignatura es una entidad ya que es interesante hace consultas sobre ella, hay
informacin descriptiva lo que, por el momento, hace pensar que es una entidad.

Pgina 45