Apuntes Base de Datos

Diseo de bases de datos relacionales
Modelo Entidad-Relacin
Javier Garca Gmez

LICENCIA
Esta obra est bajo una Licencia CreativeCommons Atribucin

NoComercial - CompartirIgual 3.0 Unported.
http://creativecommons.org/licenses/by-nc-sa/3.0/deed.es_ES
Usted es libre de:
Copiar, distribuir y comunicar pblicamente la obra
Remezclar transformar la obra
Bajo las condiciones siguientes:
Reconocimiento Debe reconocer los crditos de la obra de la manera especificada por el

autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso
que hace de su obra).
No comercial No puede utilizar esta obra para fines comerciales.
Compartir bajo la misma licencia Si altera o transforma esta obra, o genera una obra
derivada, slo puede distribuir la obra generada bajo una licencia idntica a sta.
Entendiendo que:
Renuncia Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular
de los derechos de autor
Dominio Pblico Cuando la obra o alguno de sus elementos se halle en el dominio pblico
segn la ley vigente aplicable, esta situacin no quedar afectada por la licencia.
Otros derechos Los derechos siguientes no quedan afectados por la licencia de ninguna
manera:
Los derechos derivados de usos legtimos u otras limitaciones reconocidas por ley no se ven
afectados por lo anterior.
Los derechos morales del autor;
Derechos que pueden ostentar otras personas sobre la propia obra o su uso, como por
ejemplo derechos de imagen o de privacidad.
Aviso Al reutilizar o distribuir la obra, tiene que dejar bien claro los trminos de la licencia
de esta obra.
INDICE
Introduccin: ................................................................................................................................. 5
Modelo Entidad Relacin: ............................................................................................................. 5
Conceptos:................................................................................................................................. 5
Conceptos principales: .......................................................................................................... 5
Entidad .............................................................................................................................. 5
Atributo ............................................................................................................................. 6
Relacin ............................................................................................................................. 6
Conceptos secundarios: ........................................................................................................ 7
Instancia ............................................................................................................................ 7
Primary Key (sinnimos: clave primaria, UID Primario, PK, P, #) ...................................... 7
Tipo de datos ..................................................................................................................... 7
Estructura de tablas .......................................................................................................... 8
Relaciones ................................................................................................................................. 8
Relacin1:N ........................................................................................................................... 8
Varias relaciones 1:N entre dos entidades............................................................................ 9
Relacin 1:N Identificacin y Entidad dbil......................................................................... 10
Relacin 1:1 ......................................................................................................................... 10
RelacinM:N ........................................................................................................................ 11
Relacin recursiva ............................................................................................................... 13
Herencia .............................................................................................................................. 13
Arco exclusivo...................................................................................................................... 14
Herramientas: ......................................................................................................................... 15
Modelo lgico.......................................................................................................................... 19
Crear Entidades ................................................................................................................... 20
Creacin atributos ............................................................................................................... 22
Creacin de modelos ............................................................................................................... 24
Creacin de la relacin 1:N ................................................................................................. 24
Modelo lgico.................................................................................................................. 24
Modelo Relacional........................................................................................................... 27
Generacin del DDL ......................................................................................................... 29
Introducir datos en tablas de SQL Developer ................................................................. 35
Creacin de varias relaciones 1:N entre dos entidades ...................................................... 35
Modelo lgico y relacional .............................................................................................. 35
Creacin de una relacin 1:NIdentifying ............................................................................. 36
Modelo lgico .................................................................................................................. 36
Modelo relacional ........................................................................................................... 37
Creacin del DDL ............................................................................................................. 38
Creacin de una relacin 1:1 ............................................................................................... 39
Modelo lgico .................................................................................................................. 39
Modelo relacional y DDL ................................................................................................. 40
Creacin de una relacin M:N ............................................................................................. 41
Modelo lgico.................................................................................................................. 41
Del modelo relacional al modelo lgico .......................................................................... 44
Creacin de una relacin recursiva ..................................................................................... 44
Modelo lgico .................................................................................................................. 44
El modelo relacional ........................................................................................................ 45
Herencia .............................................................................................................................. 45
Modelo lgico .................................................................................................................. 45
Cmo hemos creado los diferentes modelos relacionales?.......................................... 47
Restricciones ....................................................................................................................... 50
Restricciones para 1 Tabla:.............................................................................................. 50
Modelo a tres tablas........................................................................................................ 55
Creacin de arco exclusivo .................................................................................................. 56
Instrucciones SQL .................................................................................................................... 58
Insert ................................................................................................................................... 58
Como exportar los insert ................................................................................................. 59
Update ................................................................................................................................. 61
Como realizar el Update .................................................................................................. 62
Usuarios y Conexiones ............................................................................................................ 63
Proyecto .................................................................................................................................. 68
Enunciado: ........................................................................................................................... 68
Modelo Lgico ..................................................................................................................... 68
Modelo relacional ............................................................................................................... 71
DDL ...................................................................................................................................... 72
Export .................................................................................................................................. 76
Introduccin:
En estos apuntes encontrars una gua para afrontar el primer parcial de base de datos
del mdulo de administracin de redes. Al final de ella debers ser capaz de entender el
modelo Entidad- Relacin. Adems aprenders a usar la herramienta SQL developer y
Data modeler para crear dicho modelo en el ordenador. La estructura de los apuntes
ser: primero el contenido terico, luego la instalacin del software y por ltimo como
hacer cada paso del modelo en el programa. Al final de cada contenido terico habr un
hipervnculo que nos lleve a como se har en el programa. Durante el desarrollo del
curso ambas cosas se irn alternando pero he credo que es ms clarificador tener toda la
teora y luego todo el desarrollo informtico. De esa forma creo que es ms rpido
encontrar el contenido. Por ltimo veremos un proyecto algo ms complejo donde
trabajaremos con las diferentes relaciones.
Modelo Entidad Relacin:
Un modelo es un esquema mental (conceptual) en el que se intenta reproducir las

caractersticas de una realidad especfica. Su finalidad es la de simbolizar una parte del
mundo real de forma que sea ms fcilmente manipulable.
El Modelo Entidad-Relacin es un modelo que sirve para crear esquemas conceptuales

de bases de datos. De hecho es prcticamente un estndar para crear esta tarea. Se le
llama modelo E/R e incluso EI (Entidad / Interrelacin). Sus siglas ms populares son
las E/R porque sirven para el ingls y el espaol.
Fue ideado por Peter Chen en los aos 1976 y 1977 a travs de dos artculos.
Inicialmente, en la propuesta de Chen, slo se incluan los conceptos de entidad,
relacin y atributos. Despus se aadieron otros conceptos (atributos compuestos,
generalizaciones...) que forman el llamado modelo entidad relacin extendido, el cual se
conoce con las siglas ERE1.
Conceptos:
Conceptos principales:
El modelo E/R est compuesto fundamentalmente por tres conceptos:
Entidad
Una entidad es la pieza de informacin ms relevante, en funcin de la temtica de la
informacin que queramos registrar en una base de datos.
EJEMPLO
Si vamos a informatizar una academia. Algunas de las entidades que tiene

sentido crear son Asignatura, Alumno, Trabajador, Clase, etc. No tiene sentido
usar como entidad nombre de alumno o Notas ya que eso sern conceptos
que dependen del elemento alumno.
1
Extrado del libro Diseo Conceptual de Bases de Datos gua de aprendizaje. Jorge Snchez. 2004
Atributo
Un atributo es una pieza de informacin vinculada a una entidad. Las entidades

almacenan la informacin en los atributos.
EJEMPLO
Para la entidad trabajador tiene sentido poner los atributos Nombre, Dni,
Sueldo,etc.
Relacin
Una relacin es un vnculo que establece una asociacin entre entidades. Se identifica
por una frase, un verbo. Las relaciones pueden ser:
1:1 = de uno a uno

1:N = de uno a muchos
M:N = de muchos a muchos
Es importante darse cuenta que dos entidades pueden tener varias relaciones que las
una. Algunas sern intuitivas pero otras sern fruto de lo que queremos construir.
Debemos ser conscientes que el ordenador slo va a entender que tipo de relacin
existe(1:N, M;N, etc) pero no que esta relacionando.
EJEMPLO
Vamos a suponer que estamos estudiando una cadena comercial como podra
ser Burger King. Es coherente tener una entidad que fuera local donde
guardaramos toda la informacin correspondiente a nuestros locales (Donde se
encuentran, metros cuadrados, horarios de apertura, etc). Tambin parece lgico
tener una entidad que fuera empleados. En ella tendramos todos los datos de
nuestros empleados (nombre, fecha de nacimiento, fecha de contrato, etc).
Cuando decimos que estas dos entidades se relacionan 1:1 podemos pensar en
que un empleado puede ser director de un local y a su vez un local debe tener
un director. Pero tambin podra ser que un empleado puede ser empleado del
mes de un local y un local debe tener un empleado del mes. Con esto debemos
ver claramente que dos entidades pueden tener varias relaciones entre si y que
al crearla somos nosotros quien decidimos cuales usamos y cuales necesitamos.
El ordenador sin embargo slo ve la relacin como algo que restringes los datos
que puede recibir una entidad.
Conceptos secundarios:
Instancia
Una instancia es una pieza o conjunto de piezas de informacin concreta, que responden
a los atributos de una entidad. Es cada una de las entradas de contenido real de la
entidad. En una visualizacin como tabla, donde la entidad es la tabla y los atributos son
las columnas, las instancias son cada una de las filas que contienen los datos concretos.
EJEMPLO
Para la entidad trabajador con los atributos nombre, dni, fecha de nacimiento,
sueldo. Una instancia podra ser: El trabajador Marco Rodrguez, con Dni
31727880L, nacido 20/08/1976 y cuyo sueldo son 700 euros.
Primary Key (sinnimos: clave primaria, UID Primario, PK, P, #)
La Primary Key es un atributo, o grupo de atributos, que identifica de forma nica a

cada instancia de una entidad. Cuando est compuesta por varios atributos no significa
que cada atributo tenga que ser nico, sino que es la combinacin de todos ellos la que
s tiene que ser nica. Hay veces que la primary Key sale de forma natural, como por
ejemplo usar el dni para los empleados o usar el ISBN de los libros por parte de una
librera. La mayora de las veces tendremos que crearla nosotros. Lo suyo es que sea
corta y fcil de usar.
EJEMPLO
Para la entidad trabajador, ademas de los atributos nombre, sueldo hay que crear
otro que identifique inequvocamente a cada instancia. ste podra ser por
ejemplo el dni, puesto que no puede haber dos trabajadores con el mismo DNI.
Para ver un ejemplo de PK formada por varios atributos podemos tomar el caso
de un bloque de viviendas. Si tenemos una entidad llamada vivienda, stas
pueden estar identificadas por el atributo escalera junto con planta y puerta.
Para cada combinacin de escalera + planta + puerta slo habr una vivienda.
Tipo de datos
Los atributos pueden contener informacin de muchos tipos. stos son algunos de ellos,
que pertenecen al conjunto de tipos de datos lgicos:
Varchar (Varchar2): dato con formato alfanumrico (textos con letras, nmeros,
espacios y smbolos) de tamao variable. Procede del ingls
VARiableCHARacter.
o Tamao: cantidad de caracteres que puede almacenar el campo como
mximo. Es obligatorio indicar un valor puesto que si no lo hacemos
obtendremos errores.
Number (Numeric): dato con formato de nmero. Conviene utilizar slo cuando
se van a realizar operaciones matemticas con dicho nmero. Por ejemplo, un
atributo de salarios o de poblaciones de ciudades debera ser del tipo number,
pero para guardar el DNI o nmeros de telfono podra ser simplemente
varchar.
o Precisin: cantidad de dgitos que pueden componer como mximo el
nmero.
o Escala: cantidad de dgitos, del total de la precisin, que estn reservados
para los decimales del nmero.
Date: fecha.
Estructura de tablas
Si queremos ver los conceptos de entidades, atributos e instancias como una estructura
de tablas, que es como trabajan las bases de datos, nos encontramos con que una entidad
corresponde a una tabla, los atributos de una entidad o campos son las columnas de esa
tabla, y las instancias de la entidad corresponden a las filas de la tabla, en las que se
guarda la informacin concreta de cada columna o atributo.
Relaciones
Vamos ahora a ver las diferentes relaciones que existen.
Relacin1:N
Una relacin uno a muchos se establece cuando una instancia de una entidad A se
relaciona con varias instancias de otra entidad B, pero cada instancia de B slo se
relaciona con una instancia de A.
EJEMPLO
La entidad vuelo y la entidad pasajero tendran este tipo de relacin. Dicha

relacin podra leerse de la siguiente forma:
Un vuelo puede tener uno o varios pasajeros.
Un pasajero debe viajar en un vuelo.

CONSEJOS Y BUENAS PRCTICAS
Cuando se establece una relacin 1:N entre la entidad A y la entidad B, la

Primary Key de A viaja a la entidad B y pasa a formar parte de la misma como
un nuevo atributo, que se conoce como Foreign Key.
Por tanto una Foreign Key es un atributo introducido en una entidad a travs de
una relacin. La Primary Key de la entidad origen es Foreing Key en la entidad
destino.
Las Foreign Key se pueden ver en el modelo relacional. Son atributos que
aparecen con la marca F a la izquierda. Casi siempre es conveniente llamarla
igual que la primary Key de la que viene.
Varias relaciones 1:N entre dos entidades
Entre dos entidades no tiene porquehaber solo una relacin, pueden crearse ms de una
si es necesario. En ese caso, en la entidad que recibe la PK como Foreign Key, habr
tantas Foreign Key procedentes de la otra entidad como relaciones haya, una por cada
relacin. En este caso no podemos dejarle el mismo nombre que la Primary Key de la
que viene ya que tendramos dos atributos con el mismo nombre. En este caso solemos
renombrar la FK dndole un nombre que identifique que relacin esta cumpliendo.
EJEMPLO
Si seguimos pensando en un aeropuerto. La entidad aeropuerto y la entidad

vuelo tendrn como mnimo dos relaciones 1:N que se leeran de la siguiente
forma.
Un vuelo debe tener un aeropuerto de origen.
Un aeropuerto es origen de uno o varios vuelos
Un vuelo debe tener un aeropuerto de destino.
Un aeropuerto es destino de uno o varios vuelos.
En este caso tenemos dos FK en la entidad vuelo que provienen de la entidad

aeropuerto. Aunque siempre es interesante que se llamen igual que la PK, en
este caso es inviable. De hecho, es ms coherente renombrarla de forma que se
entienda que funcin est cumpliendo. En nuestro ejemplo sera lgico ponerle
IdVueloOrigen e IdVueloDestino.
Relacin 1:N Identificacin y Entidad dbil
Una entidad dbil es una entidad estrechamente relacionada con otra. Por s misma, la
entidad dbil no tiene sentido.
La Primary Key de una entidad dbil normalmente estar formada por un atributo
propio de la entidad, y por la Primary Key de la entidad con la que est relacionada, que
actuar en la entidad dbil como Foreign Key y parte de la Primary Key a la vez. Esto
se hace mediante la relacin 1:N Identificacin.
Por tanto una relacin 1:N Identificacin es como una relacin 1:N, con la diferencia de
que la Primay Key que viaja de la entidad de origen a la entidad destino como Foreign
Key, es tambin Primay Key en esta ltima entidad. Es decir, la PK del origen es PK y
FK en el destino.
Debemos tener cuidado de no confundir dbil con irrelevante. En una academia puede
ser muy importante saber que actividades extraescolares tienen los alumnos. Pero la
entidad en si es dbil ya que no nos interesa que actividades extraescolares tienen o a
que se dedican en ella, nos interesan en relacin a nuestros alumnos. Nos interesa saber
que un alumno juega al ftbol de 17 a 18 pero que hace dentro de esa actividad nos da
igual. En general, esta relacin se usa cuando la entidad que creamos se enfoca en
funcin de otra y no como ella misma.
EJEMPLO
Si somos una empresa que vende coches y tenemos una entidad que guarda
todos los datos de nuestro coche. Tiene sentido crear una entidad que fuera
accesoriosdonde tendra guardado los tipos de accesorios que puedo montar.
Pero a su vez tendra sentido tener una entidad que fuera accesorios coche que
estuviera relacionada con los coches. De esa forma sabra que accesorios
concretos tendra cada coche.
Relacin 1:1
Una relacin 1:1 es una relacin en la que una instancia de una entidad A se relaciona
slo con otra instancia de otra entidad B, y cada instancia de B slo se relaciona
tambin con una instancia de A.
EJEMPLO
Ya hemos hablado de varias posibilidades. Por ejemplo, que una empresa tendr
un solo empleado que pueda ser Jefe y que toda empresa debe tener un jefe.
En una relacin 1:1 la PK de una entidad viaja a la otra como FK en funcin de cual de
las dos entidades sea la que tiene el rol dominante. Si una de las dos tiene el rol
dominante, ser esa la que enve su PK a la otra como FK. Si ninguna tiene rol
dominante, cada una de las dos enviar su PK, de tal modo que tambin cada una de las
dos recibir como FK la PK de la otra.
RelacinM:N
En una relacin muchos a muchos, cada instancia de una entidad A est relacionada con
una o varias instancias de otra entidad B, y viceversa, cada instancia de B est tambin
relacionada con muchas instancias de A.
EJEMPLO
Vamos a pensar en una empresa como Tussam. En ella tendremos una entidad
que ser trabajadores y otra que sern vehculos. Una relacin M:N sera:
Un trabajador puede actuar como chofer en uno o varios autobuses.

Un vehculo del tipo autobus puede ser conducido por uno o varios choferes.
Alguien podra argumentar que un autobs es conducido en cada instante por un

nico chofer. Que no son muchos los que lo conducen. Pero debemos pensar
que en la entidad autobs guardamos los datos del autobs a lo largo de su vida.
En su vida, lo ms normal es que sea conducido por distintas personas.
El mismo razonamiento ocurre cuando pensamos que un chofer no puede estar
conduciendo dos autobuses a la vez, la entidad trabajador guarda la informacin
de toda la vida que tenga dicho trabajador ergo es lgico pensar que conducir
diferentes autobuses en su vida.
Cuando creamos una relacin M:N, en realidad lo que creamos es una tercera entidad
que albergue cada una de las combinaciones que se produzcan entre las instancias de las
dos entidades originales.
La forma de enfocar la identificacin de esta nueva entidad depender de nuestra

realidad. Veamos las posibilidades.
1 Posibilidad
La Primary Key de esta nueva entidad estar formada por las PrimaryKey de las dos
entidades iniciales, que sern adems ForeignKey en la nueva entidad, ya que la
relacin entre cada una de las dos entidades iniciales y la nueva entidad es del tipo 1:N
Identificacin. Por tanto esta relacin M:N equivale a dos relaciones 1:N Identificacin
con esa nueva entidad.
2 Posibilidad
La Primary Key de esta nueva entidad estar formada por las PrimaryKey de las dos
entidades iniciales, que sern adems ForeignKeys en la nueva entidad, ya que la
relacin entre cada una de las dos entidades iniciales y la nueva entidad es del tipo 1:N
Identificacin. Pero aadimos un atributo adicional que tambin ser PrimaryKeys. Por
tanto esta relacin M:N equivale a dos relaciones 1:N Identificacin con esa nueva
entidad que a su vez tendr su propio identificador propio.
3 Posibilidad
La Primary Key de esta nueva entidad ser un atributo que nosotros aadamos y las dos
PrimaryKey de las entidades iniciales sern solo Foreign Key en la nueva entidad.
EJEMPLO
Imaginemos una flota de autobuses donde queremos recoger las reparaciones.

Aunque lo normal sera tener una entidad con todos los trabajadores y otra con
los vehculos por simplificar supondremos que tenemos la entidad Mecnico y
la entidad Autobs.
La relacin lgica se leera as:
Un mecnico puede estar presente en una o varias reparaciones.
Un autobs puede ser reparado por uno o varios mecnicos.
La nueva entidad que se crea podra llamarse reparacin. Esta no quedara

perfectamente identificada con las dos PK que llegan ya que un mismo autobs
puede ser reparado en el tiempo por el mismo mecnico. Para desempatar
necesitamos un nuevo campo que haga ayude. Si es mejor quitarle el papel de
PK al id del mecnico y al id del autobs y dejar solo un id de reparacin o
guardar los tres ser algo que decidamos segn nos comente el cliente. Depende
la opcin estaramos en el modelo 2 o 3.
El modelo 1 cuando generalizamos mucho, es complicado llevarlo a cabo ya
que es normal que las parejas se repitan en el tiempo.
Por otra parte, cuando montamos la relacin M:N como dos relaciones 1:N
Identificacin y una tercera entidad, esas relaciones podrn ser opcionales u obligatorias
en el origen, partiendo desde las entidades iniciales. En el destino, es decir en la nueva
entidad, sern siempre obligatorias, como todas las relaciones 1:N Identificacin.
La obligatoriedad u opcionalidad en el origen tendr consecuencias al hacer nuestro

modelo en el ordenador. Las comento brevemente aunque se ver con ms detalle en la
prctica.
Si la relacin es obligatoria, al trabajar con los datos y eliminar una instancia de la

entidad del origen, tambin se eliminarn automticamente todas las instancias
relacionadas en la entidad destino (en la nueva entidad). Esto se realiza debido a la
orden OnDeleteCascade que se introduce en el archivo DDL.
Si la relacin es opcional, al intentar eliminar una instancia de la entidad del origen

veremos que no podemos hacerlo, puesto que dejaramos a una o ms instancias
hurfanas en la entidad destino. Para poder eliminar la instancia debemos eliminar
primero todas las instancias relacionadas en el destino.
Es interesante darse cuenta que la nueva entidad que se ha creado al hacer una relacin
N:M puede a su vez relacionarse con otras entidades.
Relacin recursiva
Una relacin recursiva es una relacin que asocia a una entidad consigo misma, en lugar
de con otra entidad distinta.
EJEMPLO
Un equipo de ftbol puede tener uno o varios rivales mximos. Por ejemplo, el
Real Betis es el rival directo del Sevilla FC, o el Real Madrid es el rival directo
del Atltico de Madrid y del FC Barcelona. Pero todos son equipos de ftbol,
son instancias de la misma entidad EQUIPO. Se relacionan entre s unas
instancias con otras, de la misma entidad.
Herencia
Una herencia es una forma de organizar entidades que comparten una serie de atributos,
y que representan a subtipos de otro elemento de categora superior, tambin conocido
como supertipo. La herencia no es en si una relacin, es ms una clasificacin.
EJEMPLO
Si queremos introducir los ordenadores que vende una tienda de informtica.

Sera interesante conocer el fabricante, el microprocesador, el sistema
operativo. Pero que sucede con la batera, este campo no tiene sentido en los
sobremesa, al igual que el tipo de torre no tendr sentido en un porttil. Para
resolver este dilema, creamos la entidad Ordenador, la entidad Sobremesa y la
entidad Porttil. Estas dos ltimas entidades sern hijos de la entidad padre
Ordenador. As que un porttil tendr los atributos propios de su entidad ms
los atributos que hereda de su padre.
Estas subclases dentro de una clase mayor es lo que crea el concepto de herencia. En la
prctica tendremos una entidad Ordenador con los atributos que comparten todas las
subclases.
Dicho de forma ms tcnica: En una herencia, los campos compartidos por todos los
subtipos se colocan en el supertipo o entidad padre. De esta forma todos los subtipos
heredarn esos atributos, y son los campos concretos de cada subtipo los que se
colocarn en las entidades de los subtipos.
Aunque una instancia de una herencia tiene algunos de sus atributos en la entidad padre
y otros en la entidad del subtipo, la Primay Key de estas instancias estar ubicada en la
entidad padre.
Arco exclusivo
Un arco exclusivo es una restriccin que afecta a dos o ms relaciones que comparten la
entidad de destino, de tal forma que en cada instancia de la entidad de destino slo se
pueda producir una de las relaciones.
EJEMPLO
Una agencia de viajes ofreces paquetes de viaje. Estos paquetes tienen un punto de
salida. Por ejemplo Tenerife. La compaa puede ofrecer al cliente una posibilidad
para que adems del paquete pueda llegar al punto de salida. Para llegar dicho lugar
podr usar diferentes medios. En nuestro ejemplo, supongamos que puede llegar en
avin o en barco. Si la agencia tuviera inters en registrar este dato, tendramos que
asegurarnos que un cliente no haya usado dos formas de llegar. Ya que en la vida
real esto no suceder. El cliente o llegar en barco a Tenerife o lo har en Avin.
Esta eleccin es lo que conocemos como arco exclusivo.
Un arco exclusivo lo que hace en realidad es aadir una instruccin SQL al archivo
DDL que contiene la estructura de la base de datos. Dicha instruccin consiste en un
chequeo de las FK en la entidad de destino de las relaciones a las que afecta el arco
exclusivo, de tal forma que slo una de las FK puede contener informacin y las dems
deben estar vacas. O estar todas las FK implicadas vacas.
Herramientas:
Vamos a trabajar con Sqldeveloper4.1.1 que necesitar Oracle como programa de
servicio. En nuestro caso vamos usar la versinOracle 11g R2 Express Edition.
Si entramos en http://www.oracle.com/es/index.html, nos encontramos con laImagen 1.
Imagen 1
Pinchamos en la opcin remarcada en amarillo de la Imagen 1y dentro de ella elegimos

la opcin que nos interese dentro de laImagen 2.
Imagen 2
El nico inconveniente es que nos pedirn que nos registremos. Por suerte es gratuito.
Para descargar el sqldeveloper basta con pinchar en la opcin en rojo de la Imagen 1.

Saldr la Imagen 3donde escogeremos la versin que nos interese.
Imagen 3
Vemos que esta versin trae consigo una mquina virtual java. Existen versiones donde
la mquina virtual no viene integrada y es necesario tener una instalada en el ordenador.
Adems, vamos a ver que esta versin trae dentro dos programa. El propio
SQLdeveloper y otro llamadoDatamodeler. El primero nos servir para trabajar con los
datos y el segundo nos crear los modelos relacionales.
La instalacin de Oracle no tiene ningn misterio pero debemos recordar que clave le
hemos puesto a nuestro administrador ya que la necesitaremos ms adelante. La
contrasea que le pusimos este ao fue Admin2015. El puerto listener es el 1521.
Un fallo que nos podemos encontrar al utilizar SQLdeveloper es que alguno de los dos
servicios de Oracle no estn activos.
Imagen 4
Para llegar a la Imagen 4basta con pinchar en el logo de Windows, donde pone buscar
programas poner servicios y pinchar sobre servicios como podemos ver en la Imagen 5.
Imagen 5
El SQLdeveloper slo necesita ser descomprimido. Para ello es necesario tener un

programa capacitado para ello, como podra ser el winrar o el winzip.
Imagen 6
Dentro de la carpeta slo tenemos que hacer doble click en el archivo remarcado en
amarillo en la Imagen 6y se ejecutar el programa.
Como estamos dentro del grupo de bilinge vamos a trabajar con la herramienta en
ingles. Para ello necesitamos modificar el archivo ide.conf que esta dentro de
sqldeveloper\ide\bin\ . En la Imagen 6hemos remarcado en rojo el principio de la ruta.
Una vez lleguemos a la ruta, lo abrimos con el notepad. Y aadirmos al final del
documento.
AddVMOption -Duser.language=en
AddVMOption -Duser.country=US
Importante! Si tenamos un enlace en la barra de tareas tendremos que eliminarlo y

volver a crearlo para que pille le cambio de idioma.
En la Imagen 7podemos ver el SQLdeveloper con la apariencia con la que solemos

trabajar. He dividido la pantalla en zonas para poder hacer referencias en ellas durante
el manual. Veremos que la zona 4 no se ve directamente y debemos hacer una serie de
operaciones para obtenerla. La zona 5 es la de trabajo e irn apareciendo subventanas
donde poder hacerlo.
Imagen 7
Ahora vamos a distinguir entre SQLdeveloper y Datamodeler. Como hemos comentado,

son dos programas diferentes pero este ltimo esta integrado en la nueva versin de
SQLdeveloper. Muchos ordenadores tienen problema con esta versin, una solucin es
bajarse el datamodeler y el sqldeveloper por separado. Datamodeler va a dedicarse a
crear lo que llamaremos el modelo lgico y relacional de nuestros problemas. Mientras
que con SQLdeveloper vamos a introducir los datos dentro de nuestra base de datos.
Una vez instalada nuestras herramientas vamos a aprender a usarla para crear las
relaciones que hemos explicado tericamente. Adems, vamos a ver como se
implementa la relacin en el ordenador y que consecuencias crea. Es interesante ir
mirando la teora a medida que se sigue el ejemplo ya que es vital entender que se esta
haciendo.
Modelo lgico
Para empezar a crear un mdelo lgico lo ms intuitivo sera darle a file, new pero
debemos recorda que tenemos dos programas en uno, por lo que debemos buscar donde
esta data modeler que ser la herramienta que nos ayude a crear el modelo lgico y
relacional. Por tanto, en vez darle a file, new debemos ir a view, Data Modeler, browser
como se observa en laImagen 8.
Imagen 8
Gracias a esta operacin se nos ha creado la zona 4 que observbamos en laImagen 7.

En la Imagen 9podemos verla ms claramente.
Imagen 9
Si vemos la Imagen 9, podemos observar que al lado del untitled hay un + que nos
desplegar un men. Dentro de Logicalmodel le damos a Show como se ve en la
Imagen 10.
Imagen 10
Al darle se nos crea una subventana en la zona 5 con el nombre de logical (untitled).
Podemos observar la ventana en laImagen 11. Nota: Cuando guardemos el modelo, en
vez de untitled aparecer el nombre de nuestro modelo.
Imagen 11
Crear Entidades
Antes de poder crear relaciones, tenemos que tener entidades que relacionar. Vamos a
aprender como crear una entidad. Para ello pinchamos en el sobrecito con una rueda
dentada que pone New Entity. Luego pinchamos en cualquier lugar de la pgina. Todo
estos pasos podemos verlo en laImagen 12.
Imagen 12
Se nos abrir la subventana de la Imagen 13.

Imagen 13
Las entidades se nombran en singular. Los nombres deben ser cortos y claros.
No deben contener caracteres extraos o exclusivos del alfabeto espaol (,
tildes...).
Se debe establecer un criterio del uso de maysculas y minsculas, guiones y

dems al nombrar los distintos elementos (entidades, atributos, relaciones, etc.),
y mantener ese criterio en toda la base de datos. Por ejemplo, un criterio que se
puede utilizar es el de Java, en donde se comienzan los nombres en minsculas
y si hay ms de una palabra, se escriben todas juntas escribiendo la primera
letra de las siguientes palabras en maysculas. Ejemplo: UnoDosTres,
telefonoFijo.
A la hora de realizar varias prcticas es interesante aadir un identificador de

dicha prctica. Ejmplo: P1_Alumno. Sera la entidad alumno de la prctica 1.
Es aconsejable utilizar nombres generales para las entidades, para poder utilizar
la misma entidad para el mayor nmero de instancias posibles. Por ejemplo en
lugar 3 entidades: empleado + socio + directivo, se puede utilizar una sola:
persona.
Para nuestro proyecto vamos a seguir el criterio de Java salvo para las entidades que
siempre irn en maysculas.
Creacin atributos
Cada entidad va a tener una serie de atributos. Para crearlos nos vamos a la pestaa
attributes de la entidad. Podemos hacerlo cuando estamos creando la entidad o una vez
creada haciendo doble click sobre ella. En la Imagen 14podemos ver las opciones que
tenemos.
Imagen 14
Name: indicamos que nombre tendr nuestro atributo.
Data Type: Es el tipo de dato. Lo normal ser elegirlogical y dentro del logical el
varchar, date, numeric son los ms frecuente.
Primary UID: Si marcamos esta opcin estamos diciendo que dicho atributo ser parte
de la Primary Key de nuestra identidad.
Mandatory: Si marcamos dicho opcin estamos diciendo que es un campo obligatorio.

Si lo dejamos vacio ser opcional. Debemos entender que aunque algo sea necesario, no
siempre interesar hacerlo obligatorio. Cuando marcamos dicha opcin estamos
obligando que al introducir datos dentro de la entidad, todos esos campos no pueden
quedarse vacos. A veces interesa poder dejar parte de la informacin sin rellanar y
posteriormente tener un programita o aplicacin que nos diga que algunos campos estn
vacos por acelerar el proceso.
Las flechas nos permite reordenar los atributos.
Imagen 15
El atributo de la Imagen 15va a identificar la identidad alumno de nuestro ejercicio. Es
un varchar de tamao 9 (es decir, podr tener 9 caracteres alfanumricos).
El atributo de la Imagen 16es el nmero de asignaturas que tiene el alumno. Sera una
variable numrica. Donde la precisin indica el nmero de cifras y la scale nos dice
cuantas de esas cifras corresponden a los decimales. Por ejemplo: un 5,2 significa 5
cifras de las cuales dos son decimales. 134,32 servira pero 1000,1 no valdra. Ni
10,134.
Imagen 16
Los nombres deben ser cortos y claros. No deben contener caracteres extraos o
exclusivos del alfabeto espaol (, tildes...).
Todos los atributos de una entidad deben tener una relacin directa con la
entidad, deben referirse a ella exclusivamente. Por ejemplo, en una entidad
cuentaBancaria no debe haber atributos email, telefono... referidos al cliente, en
su lugar estos atributos deberan estar en otra entidad cliente.
El atributo que ser o los atributos que sern nuestra PK es interesante que no
sean muy genricos. Si por ejemplo es un cdigo y la entidad es alumno. Sera
interesante poner AluCod en vez de cdigo
No se debe tener redundancia de atributos, con varios atributos similares dentro

de una misma entidad. Cuando sucede, es una seal de que estamos diseando
la base de datos mal. Por ejemplo, no se debe tener en una entidad empleado los
atributos cnyuge, hijo1, hijo2, hijo3... En su lugar debera haber otra entidad
familiar relacionada con empleado.
La PK debe ser siempre el primer atributo de la entidad.
Cuando la PK est formada por ms de un atributo, aparece primero el atributo

ms general y luego los ms concretos, por orden. Por ejemplo, primero
edificio, despus planta y por ltimo puerta.
Tras crear los diferentes atributos le damos a ok y se nos crea la entidad. En pantalla nos
saldr laImagen 17.
Imagen 17
La # indica que ese atributo es la primarykey.
El * indica que dicho atributo es obligatorio.
0 Indica que dicho atributo es opcional.
Creacin de modelos
Vamos a ir viendo ahora como se crea cada una de las relaciones que hemos visto
tericamente. En general crearemos primero un modelo lgico, luego construiremos a
partir de este un modelo relacional. Este modelo terico sern tablas de datos en la
realidad. Para crear dichas tablas y trabajar con ellas crearemos un archivo dll que
contendr las instrucciones que debemos darle a SQLdeveloper para que las construya.
Luego veremos que instrucciones da internamente SQLdeveloper para introducir datos
en las tablas. Por ltimo, cuando tengamos datos introducidos aprenderemos a
exportarlos por si queremos llevarlos a algn otro lugar. Veremos adems, que fallos
nos indicar el programa en relacin con el tipo de relacin que estamos trabajando.
Para ello, observaremos que relaciones existen, y veremos las restricciones que se crean.
Creacin de la relacin 1:N

Modelo lgico
Lo primero que hacemos es crear la entidad vuelo y la entidad pasajero.
Imagen 18
Imagen 19
Hemos pinchado en el crculo naranja de laImagen 19. Luego pinchamos en una de las
entidades y nos movemos haca la otra. Observamos en la Imagen 19quese crea una
lnea negra. Al soltarla se nos abre una nueva ventana, Imagen 20, que interesa estudiar
a fondo.
Imagen 20
1. Indica el nombre que tendr la relacin. Al principio solemos dejar el nombre

por defecto pero en un proyecto grande, es interesante darle un nombre a cada
relacin de forma que sepamos cual es su funcin.
2. Indica la entidad origen. Vuelo.
3. Indica la entidad destino. Pasajero.
4. Marca si el origen puede contener uno o varios elementos de la entidad destino.
El smbolo que observamos significa uno o varios. Un vuelo puede tener uno o
varios pasajeros.
5. Marca si el destino puede contener uno o varios elementos de la entidad origen.
El smbolo que observamos significa uno. Un pasajero debe ir en un vuelo.
6. Indica si el origen puede o debe contener elementos de la otra entidad. Si esta
marcada significa puede.
7. Indica si el destino puede o debe contener elementos de la otra entidad. En este
caso al estar desmarcado, sera obligatorio.
8. Esta casilla convertira la relacin en una que veremos ms adelante. Ser la
relacin 1:N identificadora.
Cuando termines de marcar las opciones que nos interesen le damos a Ok. Al hacerlo se
nos crea la relacin que podemos observar en la Imagen 21 donde he remarcado los
elementos de inters. Si ms adelante vemos que la relacin es diferente podemos hacer
doble click en la relacin para cambiarla.
Imagen 21
Aunque en la realidad sea lgico que ambas relaciones sean un debe. Lo cierto
es que siempre usaremos puede para la entidad 1 y debe o puede para la N.
Esto no es un capricho ya que el programa no aadir nada si ponemos debe en

vez de puede en la entidad 1. Para poder controlar que un vuelo no puede ir
vaco. Es decir, que debe tener pasajeros necesitaremos un programa que haga
dicha comprobacin.
El programa no aade nada por un buen motivo. Cuando creemos las tablas y
vayamos a meter datos nos encontraramos en un bucle infinito. Si quiero aadir
vuelos necesito tener pasajeros para dicho vuelo as que tendra que crear
pasajeros que meter al vuelo. Pero cuando voy a introducir un pasajero tendr
que asignarle un vuelo que no he podido crear.
Modelo Relacional
Para crear el modelo relacional pinchamos en la doble flecha azul que vemos en la
Imagen 22y luego Engineer.
Imagen 22
Una vez creado se abrir una nueva hoja con el modelo relacional. Lo normal es que el
diagrama relacional no se vea completo.
Imagen 23 Redimensionar el modelo relacional

Si pinchamos en la pantalla con el botn derecho y nos vamos a Layour, ResizeObjects
to visible. Nos ajusta el diagrama para que se lea todo el texto. Ojo, si tenemos muchas
entidades, puede ocurrir que unas entidades se pisen con otras y debamos desplazarlas.
Basta con pinchar encima de una y mover el ratn.
Echemos un vistazo al modelo relacional.
Imagen 24
En la Imagen 24 hemos coloreado cada recuadro de un color para indicar que estamos
observando en cada uno.
Recuadro rosa: contiene el nombre de la entidad.
Recuadro verde:contiene los atributos que tiene cada entidad. Debemos observar que en
la entidad Pasajero se ha creado un nuevo atributo debido a la relacin. Dicho atributo
lleva una F para indicar que es una Foreignkey. Por tanto, hemos corroborado que
cuando creamos una relacin 1:N, la PK de 1 viaja a la entidad N.
Recuadro gris: indica el nombre de la restriccin o constrain que crea una primarykey.
Cuando estemos introduciendo datos, si pasamos por alto rellenar el nmero o el dni,
nos dar un error. En el primer caso aparecer vuelo_pkviolated y en el segundo saldr
pasajero_pkviolated.
Recuadro azul: indica el nombre de la restriccin o constrain que crea la relacin 1:N.
Que indica que el campo FK es un campo obligatorio (podra no serlo, depende las
opciones que hayamos puesto) y que adems lo que coloquemos en el recuadro debe
existir como PK en la entidad de origen. Es decir, si en FK ponemos 001. Es porque
existe el vuelo nmero 001.
Hemos dicho que es interesante que la FK tenga el mismo nombre que la PK, pero
hemos visto que al crear la relacin, esto no sucede de forma natural. Vamos a ver como
podemos cambiar este valor, adems del nombre de las restricciones.
Imagen 25
Si hacemos doble click en un recuadro se nos abre laImagen 25. Vamos a indicar que es
lo ms interesante que podemos hacer.
General: nos permitira cambiar el nombre de la entidad. Esta opcin no parece muy
interesante pero veremos que en la relacin N:M si es muy til.
Colums: nos permite ver los atributos. Aqu es donde cambiaremos el nombre a nuestra
Foreign Key para que coincida con el nombre de nuestra Primary Key.
Primary Key: Aqu podemos cambiar el nombre de la restriccin de la primarykey.

Cuando olvidemos escribir algo en la columna de la primarykey nos saltar un nombre
relacionado con el valor que pongamos.
ForeignKeys: Aqu podemos cambiar el nombre de la restriccin de la foreignkey. Es

interesante poner un valor que no sea excesivamente grande y que este relacionado con
la relacin que la ha creado. El lmite de caracteres es de 30. A veces, el programa
automticamente la crea con una extensin mayor, as que debemos estar atentos si nos
da un error al crearse el DDL, ya que el error podra venir de aqu.
El resto de opciones o no tienen inters o se escapan de nuestros dominios para este

curso.
Generacin del DDL
Un archivo SQL (StructuredQueryLanguage) es un fichero de texto que contiene

instrucciones para realizar operaciones en bases de datos relacionales.
Un archivo DDL (Data DefinitionLanguage) es un archivo SQL que contiene la

estructura de la base de datos.
Para pasar la base de datos que diseamos en Data Modeler a nuestra base de datos en
SQL Developer utilizaremos los archivos DDL.
Para crearlo pinchamos en el smbolo remarcado con un cuadro verde de la Imagen 26.
O pinchamos en File, data modeler, export, dll file. Se nos abre una nueva ventana.
Pinchamos en generateque abre una nueva ventana.
Dejamos todas las opciones de Createselection marcadas, es til irnos a la opcin

Dropselection y marcar todas las opciones. Le damos a ok y se genera un texto con las
instrucciones.
Imagen 26
Una vez que tenemos las instrucciones pinchamos en save. Elegimos la carpeta donde
queremos guardarlo y el nombre y le aadimos .sql.
Veamos las instrucciones que se han creado para este tipo de relacin y en que
consisten. Para ello vamos a copiar el contenido del ddl. Aqu nos encontramos con un
problema. Si pinchamos en el archivo ddl.sql y lo abrimos con el bloc de notas, veremos
que el contenido ha perdido los colores y es ms difcil entender las instrucciones. As
que es aconsejable bajarse un programa como notepad ++ para trabajar con este tipo de
archivos. Al abrirlo con este programa el archivo es ms visual.
Imagen 27 Abierto con notepad.

Imagen 28 Abierto con notepad ++
Ahora nos encontramos con otro problema. Si copiamos y pegamos directamente el

contenido, da igual que estemos usando el bloc de notas o el notepad ++. El contenido
se copia mal y se ver igual que en el bloc de notas. Para solucionar este problema
notepad++ tiene un plugin que te permite exportar el contenido con contenido
enriquecido. Si pinchamos en plugins, nppExport y copyrtfclipboard, podremos copiarlo
en un Word oOdt sin que se pierdan el contenido enriquecido. En laImagen 28, el
recuadro verde muestra como podemos hacer este proceso.
Texto pegado del DDL.

-- Generated by Oracle SQL Developer Data Modeler 4.1.1.888
-- at: 2015-11-07 20:01:40 CET
-- site: Oracle Database 11g
-- type: Oracle Database 11g
DROPTABLE Pasajero CASCADECONSTRAINTS;
DROPTABLE Vuelo CASCADECONSTRAINTS;
Estas dos rdenes borran las tablas vuelo y pasajero del usuario que ejecute la orden. Si
pusiera US1:Pasajero. Borrara la tabla pasajero del usuario 1 aunque la estuviera
ejecutando el usuario 2. Aunque el usuario 2 tendra que tener los permisos suficientes
para poder realizar dicha orden.
Cascadeconstraints permite poder borrar sin que se creen conflicto con las condiciones
que relacionen dichas entidades.
CREATETABLE Pasajero
(
DNI VARCHAR2(9)NOTNULL,
NOMBRE VARCHAR2(30)NOTNULL,
FECHANACIMIENTO DATE,
NUMERO VARCHAR2(10)NOTNULL
);
Crea una tabla llamada pasajero con los atributos que vemos. Notnull indica que dicho
campo no puede dejarse en blanco.
ALTERTABLE Pasajero ADDCONSTRAINTPasajero_PKPRIMARYKEY( DNI);
Alter table permite alterar el contenido de una tabla. En este caso aade una constraint
(restriccin) que indica que DNI es la PK y por tanto no podr estar vaca. Pasajero_PK
ser el nombre de referencia cuando se viole dicha restriccin.
CREATETABLE Vuelo
(
NUMERO VARCHAR2(10)NOTNULL,
DESTINO VARCHAR2(30)NOTNULL,
NUMMAXPASAJERO NUMBER(3),
FECHA DATENOTNULL
);
ALTERTABLEVueloADDCONSTRAINTVuelo_PKPRIMARYKEY( NUMERO);
Aqu hemos creado la tabla vuelo y aadido la restriccin de cual es su primarykey.

ALTERTABLE Pasajero
ADDCONSTRAINTPasajero_Vuelo_FKFOREIGNKEY(NUMERO)REFERENCES Vuelo (
NUMERO );
Aqu se aade una nueva restriccin. En este caso es aadir que numero es una
foreignkey en la tabla pasajero y que esta relacionada con el atributo numero de la tabla
vuelo.
Las lneas que vienen a continuacin podemos eliminarlas ya que no sirven para nada.
-- Oracle SQL Developer Data Modeler Summary Report:
--
-- CREATE TABLE 2
-- CREATE INDEX 0
-- ALTER TABLE 3
-- CREATE VIEW 0
-- ALTER VIEW 0
-- CREATE PACKAGE 0
-- CREATE PACKAGE BODY 0
-- CREATE PROCEDURE 0
-- CREATE FUNCTION 0
-- CREATE TRIGGER 0
-- ALTER TRIGGER 0
-- CREATE COLLECTION TYPE 0
-- CREATE STRUCTURED TYPE 0
-- CREATE STRUCTURED TYPE BODY 0
-- CREATE CLUSTER 0
-- CREATE CONTEXT 0
-- CREATE DATABASE 0
-- CREATE DIMENSION 0
-- CREATE DIRECTORY 0
-- CREATE DISK GROUP 0
-- CREATE ROLE 0
-- CREATE ROLLBACK SEGMENT 0
-- CREATE SEQUENCE 0
-- CREATE MATERIALIZED VIEW 0
-- CREATE SYNONYM 0
-- CREATE TABLESPACE 0
-- CREATE USER 0
--
-- DROP TABLESPACE 0
-- DROP DATABASE 0
--
-- REDACTION POLICY 0
--
-- ORDS DROP SCHEMA 0
-- ORDS ENABLE SCHEMA 0
-- ORDS ENABLE OBJECT 0
--
-- ERRORS 0
-- WARNINGS 0
Una vez creado el DDl, vamos a usarlo. Para ello nos vamos a file, open y buscamos el
fichero .sql que hemos creado.
Imagen 29
Debemos tener cuidado de no estar en el modelo relacional o en el modelo lgico como

es el caso de laImagen 29. Si nos fijamos Relational_1(vuelo1) esta en blanco,
indicando que es la ventana con la que estamos trabajando.
Imagen 30
En la Imagen 30podemos observar que slo podemos abrir archivos que tengan
extensin dmd, dmdz y xml. Por tanto, no podramos abrir nuestro *.sql
As que debemos tener cuidado y darle a open estando en start page o en la pgina de un
usuario.
Una vez que le damos a open, buscamos el archivo se nos abre una nueva ventana de
trabajo en la zona 5 como la de laImagen 31. Hemos remarcado en negro el botn que
comenzar la ejecucin de las instrucciones. Cuando pulsemos nos pedir que digamos
con que usuario queremos ejecutar las instrucciones. Una vez elegido, las instrucciones
se irn ejecutando. En la zona 3 hay un log donde se pueden ver lo que ha ocurrido. Es
interesante por si hay algn fallo. Para ejecutar las instrucciones voy a usar el usuario
USU1 que cree en su da. Como se crean usuarios est en otra zona del manual, como
vas a necesitar crear uno, pincha aqu si todava no lo tienes.
Imagen 31
Es aconsejable estar conectado solo con el usuario que queremos que ejecute las
ordenes. Cuando ejecutemos rdenes nos van a pedir que digamos con que
usuario vamos a ejecutarlas. Si la conexin esta activa, simplemente se
ejecutarn las ordenes. Sin embargo, si la conexin esta parada, nos pedir el
pasword para conectarse. Si nos hemos equivocado y no hemos dicho que se
ejecuten con el usuario que estamos conectado, que nos pida el pasword deber
ponernos sobre aviso y nos permitir cancelar la accin
Si al crear el DDL marcamos los drop, veremos que al ejecutarse por primera
vez darn error ya que no existen las tablas que queremos eliminar.
Introducir datos en tablas de SQL Developer
Iniciar la conexin correspondiente > Desplegar el elemento Tablas > Clic en

la tabla deseada > Clic en la pestaa Datos > Botn Insertar Fila >
Introducir los datos de los atributos (columnas) de la instancia (fila) que
queramos rellenar > Botn Confirmar
Si incumplimos alguna restriccin al introducir el dato, por ejemplo porque no hayamos

rellenado un atributo obligatorio, porque hayamos puesto letras en un campo numrico,
o porque no hayamos puesto un valor vlido en una Foreign Key (para que sea vlido, el
valor debe ser el mismo que el de la Primay Key correspondiente de alguna instancia en
la entidad (tabla) origen de la relacin que ha generado la Foreing Key), al Confirmar
obtendremos un error en el panel de Log que nos indicar la restriccin que est siendo
violada. Tendremos que corregir la fila para poder confirmarla y que queden
almacenados sus datos.
El tema de introduccin de datos, la exportacin de los datos y las ordenes internas las
veremos ms detalladamente cuando terminemos de ver todas las relaciones ya que
funcionan igual para cualquier tipo de relacin que hagamos. Incluso, veremos que
adems de las restricciones que crean las entidades por defecto podremos aadir
nuestras propias restricciones.
Creacin de varias relaciones 1:N entre dos entidades

Modelo lgico y relacional
Los pasos a seguir para crear varias relaciones son los mismos que para crear una sola
relacin. Ya dijimos que de normal es interesante tener el mismo nombre en la
foreignkey la primarykey, esta es la excepcin ya que no podemos tener dos atributos
con el mismo nombre. Por eso, en este caso le pondremos a la foreignkey un nombre
que este relacionado con la misin que cumple. En las imgenes vamos a ver como
queda el modelo lgico y el relacional y como se leeran las relaciones.
Imagen 32
Imagen 33
En nuestro ejemplo tenemos la entidad cuenta y la entidad transferencia.
Una transferencia tiene una cuenta destino.
Una cuenta puede ser destino de una o varias transferencias.
Una transferencia tiene una cuenta de origen.
Una cuenta puede ser origen de una o varias transferencias.
Si nos fijamos en el modelo relacional de laImagen 33. Hemos renombrado las

Foreignkey a IDCUENTAORIGEN y a IDCUENTADESTINO y no IDCUENTA que
es como se llama la primarykey. Adems, la clave que marca la violacin de dicha
relacin la hemos renombrado a TCUENTAORI y TCUENTADES para que sea ms
intuitiva.
No vamos a hablar ms sobre esta relacin porque realmente todo es igual que antes
salvo que tenemos dos en vez de una.
Creacin de una relacin 1:NIdentifying
Modelo lgico
Si observamos laImagen 34. Podemos observar el modelo lgico de una relacin

1:NIdentifying. Para crearlo los pasos han sido:
1. Crear las dos entidades.

2. Pinchar en el botn remarcado en negro en la Imagen 34.
3. Pulsa sobre la entidad trabajador.
4. Arrastrar la lnea hasta la entidad hijo.
Imagen 34
Si pinchamos sobre la relacin vemos la Imagen 35 que es igual a la Imagen 20.
Imagen 35
Como ya comentamos, si marcbamos la casilla 8 de la Imagen 20 obtenamos una

relacin 1:NIdentifying. Por ese motivo, cuando usamos la opcin crear 1:NIdentifying
la relacin que se crea tiene este campo marcado por defecto.
Modelo relacional
En el modelo relacional de la Imagen 36 podemos ver la diferencia principal entre una

relacin 1:N y una 1:N Identifying. Qu ha sucedido? Ahora la Primary Key de la
entidad trabajador no ha viajado solo como Foreign Key. Podemos observar que es a su
vez Primary Key, Foreign Key.
Imagen 36
Ya comentamos que el primer atributo debe ser la primarykey de la entidad. En

el caso de una relacin 1:NIdentifying ponemos la PF (primarykey, foreignkey)
como primer atributo. Para ello pinchamos en la tabla y en colum usamos
para desplazarlo arriba.
Creacin del DDL
Para crear el DDL seguimos los mismos pasos que para la relacin 1:N. Echemos un
vistazo al DDL del ejemplo y veamos que la diferencia de una relacin 1:N.
DROPTABLE P10_HIJO CASCADECONSTRAINTS;
DROPTABLE P10_TRABAJADOR CASCADECONSTRAINTS;
CREATETABLE P10_HIJO
(
IDHIJO VARCHAR2(4)NOTNULL,
APELLIDO VARCHAR2(50),
F_NACIMIENTO DATE
);
ALTERTABLE P10_HIJO ADDCONSTRAINT P10_HIJO_PK PRIMARYKEY( IDHIJO, DNI
);
Aqu esta la clave. Al aadir la restriccin de Primarykey pone IDHIJO y DNI. Este
ltimo campo era la PK de la entidad Trabajador que ahora identifica a la tabla hijo.
CREATETABLE P10_TRABAJADOR
(
APELLIDO VARCHAR2(50),
CARGO VARCHAR2(30),
SUELDO NUMBER(6,2)NOTNULL
);
ALTERTABLE P10_TRABAJADOR ADDCONSTRAINT P10_TRABAJADOR_PK PRIMARYKEY(
DNI);
ALTERTABLE P10_HIJO ADDCONSTRAINT HIJOTRABAJADOR_FK FOREIGNKEY(

DNI)REFERENCES P10_TRABAJADOR ( DNI );
Una vez creado el DDL.sql, seguiremos los mismos pasos que para la relacin 1:N.
Como ya dijimos antes, la introduccin de datos lo veremos al final de todas las
entidades.
Creacin de una relacin 1:1

Modelo lgico
En la Imagen 37 podemos ver el modelo lgico de una relacin 1:1.
Para crearlo los pasos han sido:

3. Pulsa sobre la entidad Personal.
4. Arrastrar la lnea hasta la entidad sucursal.
Imagen 37
La duda principal que nos debe surgir es que ocurre en este caso con las Primary Key.
Para responder vamos a mirar la Imagen 38. La clave para responder a esa pregunta
esta en el campo Dominant Role. Aqu podemos indicar si alguna de las dos entidades
juega un rol dominante en la relacin. El rol que pongamos como dominante mandar
su PK a la otra entidad como FK.
Si dejamos ese campo con none, es decir, que no indicamos un rol dominante. El
programa tomar como rol dominante la entidad que tiene el puede frente a la que tiene
un debe.
Pero qu sucede si ambas tienen debe o ambas tienen puede? En ese caso cada entidad
mandar su PK a la otra entidad.
Imagen 38
Modelo relacional y DDL
Vamos a ver como se muestra esto en el modelo relacional (Imagen 39,Imagen 40) y en
los DDL.
Imagen 39 Personal es la entidad dominante.
Imagen 40 Ninguna de las dos es dominante.

En el primer caso podemos observar en la Imagen 39 que tendremos lo mismo de
siempre. La entidad sucursal ha recibido la PK de la entidad personal como FK. En la
imagen 40 sin embargo vemos que cada uno ha enviado su PK como FK. Sin embargo,
el DDL de ambos casos es el mismo. El motivo es el mismo que vimos en un consejo y
buenas prcticas de las entidad 1:N, no crear un bucle infinito que no nos permita
introducir datos. As que en realidad, el programa dar un rol dominante a una de las
dos entidades al crear el DDL, lo hayamos indicado o no.
DROPTABLE PERSONAL CASCADECONSTRAINTS;
DROPTABLE SUCURSAL CASCADECONSTRAINTS;
CREATETABLE PERSONAL
(
IDPER VARCHAR2(4)NOTNULL,
NOMBRE VARCHAR2(40)NOTNULL
);
ALTERTABLE PERSONAL ADDCONSTRAINT PERSONAL_PK PRIMARYKEY( IDPER);
CREATETABLE SUCURSAL
(
IDSUC VARCHAR2(4)NOTNULL,
DIRECCION VARCHAR2(100),
IDPER VARCHAR2(4)NOTNULL
);
CREATEUNIQUEINDEX SUCURSAL__IDX ON SUCURSAL
(
IDPER ASC
)
Aqu esta la clave que nos introduce el 1:1. Gracias a esta instruccin cada elemento de
una entidad solo podr estar relacionado con uno de la otra entidad. En nuestro ejemplo,
distintas sucursales no podrn tener el mismo IDPER.
;
ALTERTABLE SUCURSAL ADDCONSTRAINT SUCURSAL_PK PRIMARYKEY( IDSUC);
ALTERTABLE SUCURSAL ADDCONSTRAINT SUCURSAL_PERSONAL_FK FOREIGNKEY(

IDPER)REFERENCES PERSONAL ( IDPER )
Creacin de una relacin M:N

Modelo lgico
En la Imagen 41 podemos ver el modelo lgico de una relacin N:M.
Para crearlo los pasos han sido:

3. Pulsa sobre la entidad Autobus.
4. Arrastrar la lnea hasta la entidad Conductor.
Imagen 41
Las opciones que vemos dentro de la entidad son las que ya hemos trabajado en las
anteriores relaciones. Lo nico que se suele cambiar es que sean ambas opcionales o no.
Sin embargo si nos fijamos en la Imagen 42 vemos que la relacin puede llevar
atributos. Hasta ahora hemos omitido esta opcin ya que no tena mucho sentido. Sin
embargo en este tipo de relacin puede ser til. Como ya hemos comentado en la teora,
esta relacin crea una nueva relacin que podr contener sus nuevos atributos. Una
opcin para crear esos atributos es aadirlos a la relacin. Luego cuando creemos el
modelo relacional veremos que la nueva relacin, llevar esos atributos.
En nuestro caso, he aadido un atributo que indique la fecha en la que el conductor

empez a usar ese autobs.
Imagen 42
Modelo relacional
Imagen 43
Vemos en la Imagen 43 que como habamos indicado, el modelo relacional ha creado

una nueva relacin, donde podemos observar un atributo que habamos colocado en la
relacin. Adems, por defecto nuestras dos entidades se relacionan con esta entidad con
una relacin 1:NIdentifying.
Si hacemos doble click en la relacin nueva y nos vamos a atributo, nos encontramos
con la Imagen 44. Aqu podemos tomar varias decisiones. Pero la ms importante es
cambiar si las dos FK que vienen de nuestras dos entidades son adems PK o no lo son.
Para ello basta con desmarcar la opcin PK. Adems, si queremos que alguno de los
nuevos atributos sea PK, basta con pinchar en el y marcar la opcin PK.
Imagen 44
Del modelo relacional al modelo lgico
Como ya hemos indicado esta nueva relacin podemos relacionarla con otras entidades
que creemos en el futuro. La pregunta es como podemos hacer esto, si la nueva relacin
ha aparecido en el modelo relacional. Los pasos a seguir son:
1. Irse al modelo lgico.

2. Darle a control A (seleccionar todo)
3. Darle a suprimir y aceptar. (Elimina el modelo lgico).
4. Irse al modelo relacional.
5. Pulsar
6. Darle a Engineer. Obtenemos la Imagen 45
Imagen 45
Ahora la entidad AutoConductor es una entidad ms con la que podemos trabajar. Las
PK no se observan en el modelo lgico ya que vienen de la relacin 1:NIdentifying que
tienen con Autobus y Conductor.
Creacin de una relacin recursiva

Modelo lgico
Para crear el modelo lgico basta con seguir los siguientes pasos:
1. Crear una entidad

2. Pinchar en el botn 1:N, podemos verlos en la Imagen 46.
3. Pulsar sobre la entidad Equipo
4. Dejarlo sobre la entidad Equipo.
El modelo relacional
Se crea pulsando y dndole a Engineer.
Imagen 46
La Foreignkey que se ha creado dentro de Equipo es la misma PK de Equipo. Hemos

cambiado el nombre para que indique que representa en las tablas. Si nos fijamos hemos
puesto que ambos extremos son opcionales. Esto puede parecer incoherente ya que la
relacin suele leerse como: Un equipo puede tener uno o varios rivales eternos y un
rival eterno debe ser de un equipo. Ejemplo: El Madrid tiene como rival eterno al
Barcelona y al Atltico de Madrid. El Sevilla tiene como rival eterno al Betis. Pero
como ya nos ha ocurrido en otras ocasiones. Cuando creo al real Madrid todava no
tengo rivales director que asignarle as que indistintamente la opcin que elijamos el
DDL no reflejar nada. Tan slo crear una FK en el campo equipo que ser opcional.
Herencia
Modelo lgico
En la Imagen 47 podemos observar el modelo lgico de dos entidades Portatil y

Sobremesa que reciben la herencia de Ordenador. Para conseguir este modelo. Hemos
seguido estos pasos:
1. Crear las tres entidades

2. Pinchado sobre la entidad Portatil.
3. En general, superuser, ordenador.
4. Pinchado sobre Sobremesa.
5. En general, superuser, ordenador.
Imagen 47
Modelo relacional
Como vemos en la Imagen 47 en el modelo lgico las herencias estn constituidas

siempre por una entidad padre y varias entidades de subtipos, pero al pasar al modelo
relacional podemos elegir entre varias estructuras. Esto es lo que se conoce como la
estrategia de ingeniera directa, y puede ser de 3 formas:
1. Estrategia de Tabla nica: la entidad padre y las entidades de los subtipos del
modelo lgico se convierten en el modelo relacional en una sola entidad con
todos los atributos.
Imagen 48
2. Estrategia de Tabla por Secundario (una tabla por cada subtipo): la entidad padre
y las entidades de los subtipos del modelo lgico se convierten en el modelo
relacional en una entidad por cada subtipo, en las que se repiten todos los
atributos de la entidad padre.
Imagen 49
3. Estrategia de Tabla para cada Entidad: la entidad padre y las entidades de los
subtipos del modelo lgico se convierten en el modelo relacional en una entidad
para cada subtipo y otra entidad para el supertipo. La entidad del supertipo est
relacionada con cada entidad subtipo mediante una relacin 1:1 Identificacin.
Imagen 50
Cmo hemos creado los diferentes modelos relacionales?
Tenemos dos formas de hacerlo. Cuando pulsamos nos sale la Imagen 51. En el
recuadro marrn podemos ver que la entidad padre est marcada y en el recuadro rojo
podemos ver que las dos entidades que heredan del padre tambin estn marcadas. As
es como nos lo da el programa por defecto y nos crear la estrategia de Tabla para cada
Entidad. Si desmarcamos la entidad padre se nos crear la estrategia de Tabla por
Secundario (una tabla por cada subtipo). Mientras que si dejamos marcado la entidad
padre y desmarcamos los subtipos de entidades se nos crear la estrategia de Tabla
nica.
La otra forma de conseguir el mismo efecto es pinchar sobre la entidad en el modelo
lgico. Irse a la opcin Enginer To y marcar o desmarcar que participe en la realizacin
del modelo relacional. Si la marcamos participa y si lo desmarcamos no participa.
Vemos que podramos incluso desmarcar algn subtipo y marcar otros. Esto creara una
sola tabla con los atributos de la entidad padre y la de los subtitpos no marcados y otra
tabla por cada entidad marcada.
La ltima posibilidad sera desmarcar la entidad padre y algunos subtipos. Se creara

una tabla nica por cada subtipo no desmarcado que tendra los atributos de la entidad
padre y las del subtipo correspondiente.
En la Imagen 50 vemos una especie de arco. Es el intento de crear un arco exclusivo que
impida que el mismo IdOrdenador aparezca en ambas tablas. Por desgracia, este no
funciona ya no tiene campos para gestionarlo por lo que no lo podra implementarse en
el DDL. Lo eliminaremos y veremos ms adelante como crear restricciones que nos
ayuden a evitar estos problemas.
Este sera el error que encontramos en el DDL.
-- ERROR: No Discriminator Column found in Arc FKArc_2 - constraint trigger for

Arc cannot be generated
-- ERROR: No Discriminator Column found in Arc FKArc_2 - constraint trigger for

Arc cannot be generated
Imagen 51
Cada estrategia de ingeniera directa de la herencia tiene sus ventajas y sus

inconvenientes.
La estrategia de tabla nica tiene sentido cuando el supertipo contiene la

mayora de los campos, y los atributos concretos de los subtipos van a ser
pocos. Esta estrategia permite que existan instancias que no pertenezcan a
ningn subtipo, para lo cual basta con dejar vacos los campos correspondientes
a los subtipos. Del mismo modo, una instancia tambin podra pertenecer a ms
de un subtipo, rellenando los campos correspondientes. Para evitar esto ltimo,
se puede introducir una instruccin SQL en el archivo DDL consistente en una
restriccin que impida que se rellenen los campos de ms de un subtipo
(veremos como se hace ms adelante).
La estrategia de tabla por secundario es ideal cuando el supertipo contiene

pocos atributos, y por el contrario, los subtipos tienen una gran cantidad de
ellos. De esta forma da igual que se repitan en cada tabla de subtipo todos los
atributos del supertipo, puesto que el nmero de atributos del supertipo es
reducido. Esta estrategia hace imposible la existencia de instancias que no
pertenezcan a ningn subtipo, puesto que los datos de una instancia debern
introducirse en una de las tablas, que corresponde cada una a un subtipo. Esta
inexistencia de instancias sin subtipo ser una ventaja o un inconveniente
dependiendo de la estructura que queramos construir en cada caso.
La estrategia de una tabla por entidad es la que ms tablas genera, pero cuando
hemos descartado la estrategia de una tabla nica, la estrategia de una tabla por
entidad es ms conveniente que la de una tabla por secundario cuando las
relaciones de la base de datos tienen como origen o destino a la entidad del
supertipo en lugar de a los subtipos, puesto que al pasar al modelo relacional,
cada relacin con el supertipo se convierte en tantas relaciones distintas como
subtipos haya, complicando la estructura general en exceso. La estrategia de
una tabla por entidad tambin permite que existan instancias que no pertenezcan
a ningn subtipo, cuando slo se rellenan los campos de la entidad del
supertipo, y se dejan vacos los de los subtipos.
Por otra parte, otro condicionante a la hora de elegir la estrategia de ingeniera

directa es la obligatoriedad de las relaciones que llegan a los subtipos. Si
necesito crear relaciones que tengan como destino algn subtipo, y quiero
hacerlas obligatorias en el destino, no puedo utilizar la estrategia de una tabla
nica, puesto que al estar todos los subtipos en la misma tabla, y al ser
obligatoria la relacin con uno de los subtipos, en realidad se convertira la
relacin en obligatoria para todas las instancias de la tabla, de tal manera que
todas las instancias perteneceran al subtipo que tiene la relacin obligatoria.
Restricciones
La herencia ha puesto de manifiesto la necesidad de crear nuestras propias restricciones.

Hasta ahora hemos visto que el programa crea una serie de restricciones para cada
modelo que hacen que funcionen acorde a la realidad. Esto no sucede en la herencia.
Vamos a ver este caso a travs de un ejemplo.
En la Imagen 52 vemos un modelo lgico simplificado. Hay una entidad padre

HOrdenador con 4 atributos ( IO ser la PK de dicha entidad). Vemos que existen dos
entidades que son hijas de la entidad HOrdenador. Son las entidades HS con dos
atributos (CS1 y CS2 donde el segundo es obligatorio) y HP con dos atributos (CP1 y
CP2 con CP1 obligatorio).
Imagen 52
Restricciones para 1 Tabla:
Imagen 53
Lo primero que podemos observar es que CP1 y CS2 han dejado de ser obligatorias.
Adems, ahora mismo nada nos impide rellenar un ordenador que tenga contenido en
todos los atributos.
Para evitar esto vamos a crear restricciones en una tabla. Esto podr hacerse en tres
niveles.
1. En el modelo relacional.
2. En el DDL.
3. En la tabla que crea tras ejecutar el DDL.
Si lo creamos en el primer nivel se implantar en los otros dos niveles. Si lo
implementamos en el segundo nivel, se generar tambin en el tercero. Lo normal, es
crearlo en el modelo relacional que nos permite si queremos no exportarlo al resto de
niveles.
Creacin en el modelo relacional:
Pinchamos sobre la tabla de la Imagen 53. Se nos abrir la Imagen 54.
Imagen 54
Si pinchamos sobre se aade una restriccin en la zona roja. En este caso hemos
creado 4. El name es el nombre que va a tener dicha restriccin. A la hora de introducir
datos, si no cumplen la restriccin este ser el nombre que salte. La validation Rule
indica que chequeo se esta haciendo. El contenido de este chequeo se introduce en la
zona azul y tras darle a apply se ver arriba. A la derecha vemos Generate in DLL. Si lo
desmarcamos es como sino hubiramos creado dicha restriccin ya que no trascender
al DDL y por tanto a las tablas.
Arco exclusivo en una Herencia
Lo primero que queremos controlar es que el usuario no pueda rellenar los campos CP1,
CP2 y a la vez CS1 y CS2.
Nombre: Arco
(TP = 'S' AND CP1 IS NULL AND CP2 IS NULL) OR (TP = 'P' AND CS1 IS
NULL AND CS2 IS NULL)
Esta regla nos dice que: el campo TP debe valer S y en ese caso CP1 y CP2 deben estar
vacos o que el campo TP debe valer P y en ese caso CS1 y CS2 deben estar vacos.
Podramos haber creado dos reglas?
Nombre Arco1:
TP = 'S' AND CP1 IS NULL AND CP2 IS NULL
Nombre Arco1:
TP = 'P' AND CS1 IS NULL AND CS2 IS NULL
Esto imposibilitara la introduccin de datos en SQL. El motivo es evidente. Cada

restriccin se chequea por separado. Por tanto, si en el campo TP pusiramos S, nos
dira que estamos incumpliendo la opcin P y viceversa.
Por eso es importante decir que ocurra una u otra. Esa opcin la de el OR.
Obligatoriedad de campos en la herencia:
Si observamos un un DDL vemos que para que un campo sea obligatorio basta con
decir con decir que dicho campo sea no nulo. EJ: CP1 is not null. Como podemos llevar
esto a la herencia. En nuestro ejemplo queremos que el campo CP1 sea obligatorio y
que el campo CS2 sea obligatorio.
Bastara con dar una orden de este estilo.
Nombre: CampoObligatorio
CP1 IS NOT NULL OR CS2 IS NOT NULL
Tambin podramos escribirla ms completa:

(TP = 'P' AND CP1 IS NOT NULL) OR (TP = 'S' AND CS2 IS NOT NULL)
Esta restriccin nos dice que tenemos dos opciones. O que el atributo CP1 tenga
contenido por fuerza o que tenga lo tenga CS2. Podramos entonces rellenar en un
porttil el campo CS2. Si solo existiera esta restriccin si, pero al existir tambin la
restriccin Arco. Sabemos que si el tipo es P, el campo CS2 no va a poder tener
contenido por lo que obligatoriamente tendr que cumplirse la otra condicin.
Forzar cierto contenido en un campo:
En la herencia vemos que es interesante que la primary key del padre empiece por S o
por P para indicar que hacen referencia a un porttil o a un sobremesa.
IO LIKE 'P%' OR IO LIKE 'S%'
O si queremos darle ms contundencia:
(IO LIKE 'P%' AND TP = 'P') OR (IO LIKE 'S%' AND TP = 'S')
Que adems de obligar a la PK a empezar por P o por S, indica que si empieza por P el
tipo debe ser P y si empieza por S el tipo debe ser S.
Qu sucede si no existe el campo TP? A priori no habra problema ya que podramos

haber usado IO LIKE 'P%' OR IO LIKE 'S%'.
Pero y si no pudiramos tampoco obligar esto ltimo. Si el cliente ya usa una PK,
seguramente no podamos obligarle a que la cambie. De hecho, a veces ser porque es
ilgico hacerlo. Si para colmo no podemos introducir un campo, nos encontramos con
un problema. Observemos el motivo:
Nombre: Arco
(CP1 IS NULL AND CP2 IS NULL) OR (CS1 IS NULL AND CS2 IS NULL)
Nombre: Campoobligatorio
CP1 IS NOT NULL OR CS2 IS NOT NULL
Arriba vemos como se quedaran nuestras dos restricciones al quitar el campo TP.
Yo podra poner un ordenador 01 (porttil) donde podra rellenar los campos CS1,CS2
solamente. Ya que no incumple Arco y tampoco Campoobligatorio. Es obvio que 01 no
debe ser porttil ya que tiene los campos rellenos de un sobremesa. En este caso, lo
normal es confiar en la buena fe del usuario que usa nuestra base de datos.
Tanto si existe el campo TP como sino, podramos haber creado una nica restriccin
que incluyera la obligatoriedad de campos y el arco. Esto no es aconsejable ya que si
algo falla es ms complicado encontrar el error. Aun as, un ejemplo sera:
(CP1 IS NULL AND CP2 IS NULL AND CS2 IS NOT NULL) OR (CS1 IS NULL AND
CS2 IS NULL AND CP1 IS NOT NULL)
Adems de estas restricciones podramos crear cualquier otra que se nos ocurra. Que un
atributo numrico no sea superior o inferior a una cifra. Que los valores de cierto
atributo tenga unos nombre prefijados.
Siempre que podamos debemos evitar que el usuario nos pueda introducir basura en
nuestra base de datos aunque siempre recordando que el usuario tambin es inteligente.
Creacin en el DDL
Veamos la estructura que toma una restriccin creada por nosotros en el DDL.
ALTER TABLE Ordenador ADD CONSTRAINT CampoObligatorio CHECK ((TP = 'P'
AND CP1 IS NOT NULL) OR (TP = 'S' AND CS2 IS NOT NULL)) ;
La orden Alter table que hemos reseado en Amarillo ya la conocamos. Indica la tabla
sobre la que vamos a introducir la restriccin o constraint.
La orden en rojo indica el nombre de la constraint o restriccin. A la hora de introducir

los datos si violamos la condicin nos dir que violet o violamos campoObligatorio.
Por ltimo dentro del Check escribimos la condicin en lenguaje SQL. Acabando en ;.
Sino hubiramos creado la restriccin en el modelo relacional e introdujramos esta

lnea en el ddl (obviamente despus de la orden que hubiera creado la tabla ordenador).
Al ejecutarse el DDL se creara la restriccin.
Creacin en las tablas
Imagen 55
En la Imagen 55 vemos estamos sobre la tabla Ordenador. Dentro de ella, en la zona 5 de

la tabla 7 nos vamos a Ordenador. All pinchamos sobre constraints. Al lado de
pinchamos en actions. Constraints, add check. Se nos abre la subventana que aparece a
la derecha de la Imagen 55.
Constraint name: Nombre de la restriccin que servir para dar el aviso si la violamos.
Check condition: Por ejemplo: IO LIKE 'P%' OR IO LIKE 'S%'
Le damos a Apply y se crear la restriccin para esa tabla.

Modelo a tres tablas
Imagen 56
Vamos a ver que restricciones son interesantes crear para el modelo 3 tres tablas. Lo que
queremos evitar es que en un ordenador que hemos dado de alta en HOrdenador con la
intencin de que sea HP, sea usado por HS y viceversa.
Para ello vamos a crear tres restricciones.
En la tabla Hordenador:
(TP = 'P' AND IO LIKE 'P%') OR (TP = 'S' AND IO LIKE 'S%')
En la tabla HP:
IO LIKE 'P%'
En la tabla HS:
IO LIKE 'S%'
Vemos que la nica forma de conseguir nuestro objetivo es introducir una condicin a
la Primary Key de la entidad padre ya que ser el nico campo presente en las dos
entidades hijos.
Creacin de arco exclusivo
Lo primero que debemos entender es que un arco exclusivo no es ms que una

restriccin. Por tanto, podramos crearlo por nosotros mismos. Lo que vamos a ver es
que la herramienta en este caso nos permite hacerlo de forma no automtica.
Pasos a seguir:
1. Creacin de las tres entidades (Viaje, Barco, Avin)

2. Creacin de las tres relaciones 1:N
3. Pincho sobre Viaje (1), luego con Ctrl (control) presionado pincho sobre ambas
relaciones (2 y 3).
4. Se me enciende la opcin de arco exclusivo (ver Imagen 57).
5. Al pinchar se crea la Imagen 58.
Imagen 57
Imagen 58
El modelo relacional podemos observarlo en la Imagen 59. Salvo el arco que se ha
creado, no tiene nada relevante. Lo ms interesante lo vamos a ver en el DDL.
Imagen 59
Restriccin en el DDL:
ALTER TABLE Viaje ADD CONSTRAINT Arc_1 CHECK ( ( (IdBarco IS NOT NULL)
AND (IdAvion IS NULL) ) OR ( (IdAvion IS NOT NULL) AND (IdBarco IS
NULL) ) ) ;
Podemos observar que la restriccin tiene la misma forma que las que creamos de forma
personalizada. En este caso, nos indica que la tabla Viaje solo podr tener contenido o
en la IdBarco o en la IdAvion.
Pero que sucede si el usuario ha ido al punto de salida del viaje por su cuenta. Ahora
mismo la compaa tendra un problema ya que debe tener relleno uno de los dos
campos. Lo primero, es que en este caso el modelo lgico estara mal ya que las
relaciones 1:N deberan haber sido opcionales en los dos extremos. Esto habra hecho
que las FK que han viajado no tuvieran que tener contenido obligatoriamente. Por tanto,
el primer paso para crear un arco que contemple esta posibilidad ser poner opcionales
las dos relaciones 1:N. El modelo relacional no cambia de apariencia. Pero sin embargo
al mirar la restriccin que se crea, vemos una diferencia.
ALTER TABLE Viaje ADD CONSTRAINT Arc_2 CHECK ( ( (Avion_IdAvion IS NOT
NULL) AND (Barco_IdBarco IS NULL) ) OR ( (Barco_IdBarco IS NOT NULL)
AND (Avion_IdAvion IS NULL) ) OR ( (Avion_IdAvion IS NULL) AND
(Barco_IdBarco IS NULL) ) ) ;
Ahora existe una opcin nueva, que es dejar ambos campos a cero.
Instrucciones SQL
En el modelo 1:N ya vimos que ordenes ejecuta SQL para crear tablas (crate), para
borrarlas (drop) , como alterar el contenido de la tabla (alter), aadir restricciones
(addconstrain). Ahora vamos a ver como insertar datos en la tabla o cambiarlos gracias
a las instrucciones insert y update.
Hay que tener en cuenta que estas dos instrucciones (insert y update) son transparente
para el usuario cuando estamos trabajando a travs del programa. Pero podemos crear
un fichero *.Sql que cargue las instrucciones y al ejecutarlo se introduzcan. Lo normal
es que los update se hagan en el programa directamente. Pero para llevarnos los datos,
solemos exportarlos como instrucciones insert que luego se ejecutaran donde queramos
tener esos datos. Veamos pues como insertar datos, actualizarlos y exportarlos.
Por ltimo veremos como aadir restricciones a una tabla para que no podamos aadir
los valores que queramos sino que estemos limitados.
Insert
Al igual que con los archivos DDL tenemos un conjunto de instrucciones SQL que
permiten definir la estructura de una base de datos, tambin surge la necesidad de poder
almacenar en un archivo los datos de dichas bases de datos. Para esto sirve la
instruccin INSERT, que es una instruccin de SQL con la que podemos guardar datos.
Creando un archivo SQL con distintas instrucciones INSERT podemos almacenar en

dicho archivo todos los datos de una base de datos, o una parte de los mismos.
Si tenemos relaciones entre tablas, de tal forma que haya campos en unas tablas que
sean ForeingKeys que procedan de otras tablas, a la hora de generar el archivo que
contenga todos los INSERT habr que colocar primero los de las tablas origen de las
relaciones (los que contienen las PK que luego sern FK en otras tablas) y despus se
colocarn los INSERT de las tablas destino (los que contienen las FK). Si no hace con
el orden adecuado, al intentar ejecutar el SQL en una base de datos para introducir los
datos, obtendremos errores.
Como exportar los insert
En laImagen 60 y la Imagen 61podemos ver en un recuadro rojo donde estn las

opciones que se indican abajo.
1. Conectarse con el usuario que tiene las tablas que buscamos.

2. Pinchar sobre la tabla.
3. Boton derecho, export.
4. Desmarcar Export DDL.
5. Seleccionar single file (viene por defecto).
6. Pinchar en Browse y buscar el directorio donde se quiere copiar.
7. Next,Next, Finished.
8. Pinchar en la siguiente tabla.
9. Boton derecho, export.
10. Desmarcar Export DDL.
11. Seleccionar clipboard en vez de single file.
12. Next,Next, Finished.
13. En la zona 5, Irse al export. Pegar al final del documento.
14. Repetir para cada tabla.
Imagen 60
Imagen 61
Debemos tener cuidado con la opcin insert

Insert into US1.P6_PROFESOR (P_DNI,NOMBRE,EDAD,ASIGNATURA) values
('78481843R','Adolfo',null,'GBD');
Esta orden significa que se inserte en la tabla del usuario US1 llamada P6_Profesor los
datos que le siguen.
Si la orden la ejecuta el usuario US1. No dar error si la tabla existe y los datos son
correctos.
Si la orden la ejecuta cualquier usuario seguramente de error ya que no tendrn permiso

para aadir contenido en las tablas de otro usuario.
Una forma de evitar esto es reescribir la orden de la siguiente forma:

Insert into P6_PROFESOR (P_DNI,NOMBRE,EDAD,ASIGNATURA) values
('78481843R','Adolfo',null,'GBD');
Al no indicar a que usuario pertenece P6_PROFESOR, el dato tratar de insertarse en la

tabla P6_PROFESOR del usuario que lo ejecuta.
Ambas cosas tienen sus pro y sus contras. En el primer caso, si queremos exportar los
datos a otro ordenador, debemos hacerlo con el mismo nombre de usuario para que los
datos se inserten bien. Si esto no ocurre, tendremos un error. Esto que puede parecer una
desventaja, tambin puede evitar que introduzcamos datos en una tabla de otro usuario
que sin querer. Supongamos que tenemos dos usuarios US1 y US2 con una tabla
P6_PROFESOR. Si ejecutamos la primer orden con US2 el dato no funcionar o se
introducir en la tabla P6_PROFESOR de US1. En el segundo caso el dato se
introducir en la tabla P6_PROFESOR de US2. Por tanto, si quitamos el usuario
tenemos que tener cuidado aunque de forma general parece ms interesante.
Update
A veces se puede dar el caso, al crear un archivo SQL mediante instrucciones INSERT
para guardar los datos de una base de datos, que a pesar de ordenar correctamente los
INSERT, no podamos introducir todos los datos, debido a que haya instancias que
necesiten ser introducidas en varios pasos.
EJEMPLO
Imaginamos que tenemos la entidad EQUIPO con los datos de los equipos de
ftbol, y que tenemos la entidad JUGADOR con los datos de todos los
jugadores. Entre ambas entidades existe una relacin 1:N con obligatoriedad en
el lado del JUGADOR, de tal forma que un equipo puede tener uno o ms
jugadores, y un jugador debe pertenecer a un equipo.
Si queremos registrar tambin qu jugador es el capitn de cada equipo,
podemos hacerlo estableciendo una nueva relacin entre ambas entidades del
tipo 1:1 con la opcionalidad activada y como rol dominante el JUGADOR, ya
que un equipo puede tener un capitn, y un jugador puede ser capitn de un
equipo. Nos encontraramos en un caso con dos entidades, y dos relaciones
entre esas dos entidades (1:N y 1:1).
Si queremos introducir datos en las tablas de la base de datos, no podramos
empezar introduciendo jugadores, puesto que necesitan pertenecer a un equipo
obligatoriamente, y los equipos todava no estn creados. Si por el contrario
introducimos primero los equipos no podramos establecer el capitn, puesto
que todava no existen los jugadores.
El orden correcto supone introducir primero los equipos, luego los jugadores, y
por ltimo modificar los equipos para establecer los capitanes. En un archivo
SQL que contenga esos datos, el orden debe ser el mismo.
La instruccin UPDATE es una orden de SQL que permite modificar las instancias, que
previamente se han introducido mediante INSERT. De esta forma podemos introducir
correctamente los datos que necesiten de varios pasos para ser creados, porque estn
vinculados a las filas de otras tablas que necesitan haber sido introducidas para poder
hacer referencia a las mismas.
Como realizar el Update
La sintaxis de la instruccin UPDATE es la siguiente:
UPDATE nombreDeLaTabla
SET nombreDeLaColumnaModificada1 = valorModificado1,
nombreDeLaColumnaModificada2 = valorModificado2,
...nombreDeLaColumnaModificadaM = valorModificadoN
WHERE nombreDeLaColumnaSeleccion = valorSeleccion;
Lo que hace la orden es dirigirse a una tabla (nombreDeLaTabla), y de esa tabla

selecciona a la instancias que cumplan la condicin de tener un valor concreto
(valorSeleccion) en una columna concreta (nombreDeLaColumnaSeleccion). Acto
seguido, a las instancias seleccionadas les otorga los valores indicados
(valorModificado1, valorModificado2 valorModificadoN) en las columnas indicadas
(nombreDeLaColumnaModificada1, nombreDeLaColumnaModificada2
nombreDeLaColumnaModificadaM).
Para utilizarla, lo que hay que hacer es abrir con un editor de texto el archivo SQL
generado con SQL Developer mediante instrucciones INSERT, para ubicar donde sea
necesario las instrucciones UPDATE.
EJEMPLO
Vamos a ver como se realiza el ejemplo anterior. Si observamos la Imagen 62 la tabla

equipo recoge un campo que es DNI. Este DNI corresponde al que ser el capitn de
nuestro equipo. A la vez la tabla de jugadores recoge un campo que indica de que
equipo es cada jugador.
Imagen 62
Si exportamos los datos el orden lgico sera, dato de los equipos y luego datos de los
jugadores.
El insert del equipo betis sera:
Insertinto PROYECTO.EQUIPO
(IDEQUIPO,NOMBRE,CIUDAD,NUMEROSOCIOS,PRESUPUESTO,DNI,IDESTADIO,IDCIUDADDEP,RI
VALMAXIMO) values ('RBB','Real Betis Balompie','Sevilla','40000',15000000,'10','1',null,null);
El problema al ejecutarse esa instruccin viene en el 10 que hemos remarcado. Ese 10 hace
referencia al dni de un jugador que todava no se ha introducido.
La solucin es dejar ese campo null y posteriormente cuando se haya creado el jugador con
DNI 10 actualizarlo con la instruccin update.
UPDATE "EQUIPO"
set DNI = 10
where IDEQUIPO = 'RBB';
Esto parece solucionar el problema de crear un bucle infinito que hemos comentado varias
veces durante los apuntes. Sin embargo, esta solucin la tiene que hacer el usuario a mano,
por eso el programa nunca va a crearla a priori. La solucin como vemos, es identificar los
campos que van a incumplir una restriccin, borrarlos antes de exportar los datos y
posteriormente aadir al final del DDl una instruccin UPDATE por cada valor borrado.
Usuarios y Conexiones
En una base de datos suele existir un usuario que es el administrador que tiene control
total sobre la base de datos y luego otra serie de usuarios que tendrn unos permisos
restringidos. Oracle tiene un usuario administrador por defecto que se llama SYS. Para
poder trabajar con dicho usuario debemos crear una conexin con el. Veamos como
creamos una conexin.
Vamos a hacer un zoom a la zona 1 de laImagen 7. Podemos ver dicho zoom en

laImagen 63.
Imagen 63
Para crear una conexin pinchamos en la cruz verde o le damos al botn derecho en
connections, new connection y nos sale una ventana que podemos observar en la
Imagen 64
Imagen 64
ConnectionName: El nombre que le queramos poner a la conexin. En este caso le

pondremos Admin para indicar que ser la conexin que usa el administrador.
Username: Es el nombre del usuario que realizar la conexin con la base de datos. En
nuestro caso ser SYS. Veremos que sys puede crear nuevo usuarios para el futuro.
Password: Es la contrasea del usuario. En el caso de SYS, ser la que pusimos al

instalar oracle. En nuestro caso Admin2015. Veremos que al crear un usuario le vamos
a asignar un pasword.
ConnectionType: Lo vamos a dejar en bsico.
Role: Aunque existen varios roles nosotros slo vamos a usar SYSDBA y Default. El
usuario SYS ser SYSDBA y el resto de usuarios que creemos sern Default.
Hostname: Localhost significa que vamos a trabajar en nuestro propia mquina. Si

queremos conectarnos a la base de datos de un compaero o cualquier otra debemos
saber la direccin del Host de destino (en general la ip).
Port: Nos conectamos al puerto 1521 que era el puerto de escucha.
SID: Xe, es la base de datos que trae por defecto oracle.
Save: nos salva la conexin para el futuro.
Clear: Limpia los parmetros que hayamos escrito.
Test: Comprueba que los datos son correctos y la conexin se realizar con xito.
Conect: Realiza la conexin.

Cuando le damos a connect se nos crea la conexin en la zona 1 de laImagen 7. Si la
desplegamos podemos observar la Imagen 65.
Imagen 65
En tables podemos ver el Shema de nuestro usuario. El Shema es el conjunto de de

tablas y datos que forman parte de un usuario.
Si pinchamos en otherusers y le damos al botn derecho podemos crear un nuevo

usuario con la opcin createuser. Vamos a crear un usuario para no usar el usuario
administrador, al darle a create se ha abierto una ventana que podemos observar en
laImagen 66. Esto es siempre aconsejable ya que el usuario SYS tiene todos los
privilegios y podemos cargarnos la base de datos. Si usamos un usuario con privilegios
limitados reduciremos el impacto que puede provocar en nuestra base de datos.
Imagen 66
Username: El nombre que le queramos poner al usuario. USU1
New Password: La contrasea que tendr dicho usuario.
ConfirmPassword: Sirve para confirmar que no nos hemos equivocado al poner nuestra
contrasea.
PasswordExpired (usermustchangenextlogin): Si lo marcamos, el usuario se conectar y

acto seguido le pedir que cambie su contrasea por una que ser definitiva. Esta opcin
es la ms habitual ya que el administrador de la base de datos crear diferentes usuarios
y le dar a cada usuario los datos genricos. El usuario al entrar pondr su propia clave
que a partir de ese momento slo conocer el.
El resto de opciones no las vamos a ver ni a marcar.
Default tablespace: Vamos a darle users. Si vamos a tener un ayudante solemos crear un
usuario con tablespacesystem.
TemporyTablespace: TEMP
Ahora nos vamos a la pestaa granted roles.Imagen 67.

Imagen 67
En nuestro caso slo le vamos a dar el de conect y el de resource. Es decir, el de poder

conectarse y el de poder crear recursos (tablas, datos, etc). Para ello marcamos las tres
columnas de cada uno de los roles.
Por ltimo nos vamos a la pestaa systemprivileges y marcamos unlimitedtablespace.
Le damos a aplicar y ya tenemos creado nuestro usuario.
Si desplegamos otheruser podemos localizar USU1 por si queremos retocar los

privilegios o los roles otorgados.
Una vez creado el usuario es interesante crear una conexin para dicho usuario.
Ya hemos visto el procedimiento, recuerda dejar el campo rol en default.
Es aconsejable desconectarse del usuario SYS.
Por defecto Oracle trae un usuario llamado system cuya contrasea, igual que
para SYS, es la que introdujimos en la instalacin. Si nos conectamos con dicho
usuario podemos cambiar la contrasea de SYS.
Proyecto
Enunciado:
Una academia est interesada en controlar las clases que da, cuantos alumnos asisten,
quien las da. Adems le interesa las comunicacin entre alumnos y profesores por
email. A la hora de fijar los horarios de las clases, debemos tener en cuenta que los
alumnos tienen actividades extraescolares que conviene conocer. Como existen
becarios, interesa saber quien es el responsable de dicho becario. De las clases adems
no interesa saber el turno, el da, donde se dan. Sera interesante introducir datos
generales de las localizaciones por si ms tarde queremos introducir las tutoras que se
suelen hacer en despachos.
Modelo Lgico
Este podra ser el enunciado de un proyecto o de un examen. Lo primero sera

plantearse que entidades debemos tener en cuenta y luego que relaciones existirn entre
ellas. En la Imagen 68 vemos el modelo lgico con sus diferentes relaciones numeradas
vamos a ir indicando que significa cada una.
Relacin 1 y 2:
Ha sido creada a partir de una relacin 1:N entre la entidad Asignatura y Trabajador.
Una asignatura es dada por uno o varios profesores.
Un profesor puede dar una o varias asignaturas.
La relacin 1 y 2 son 1:N Identifying. Esto va a crear parejas de Profesor, Asignatura.
Relacin 3 (Relacin recursiva):
Un trabajador puede ser tutor de uno o varios trabajadores.
Un trabajador puede tener un tutor que le vigile.
Relacin 4 (1:N):
Una clase debe ser de las parejas creadas Profesor Asignatura.
Una Pareja de profesor y Asignatura puede aparecer en una o ms asignaturas.
Relacin 5 (1:N):
Una clase debe darse en un aula.
Un aula puede acoger una o ms clases.
Relacin 6 (1:N):
Una clase debe tener un turno.

En un turno puede tener una o varias clases.
Relacin 7 (N:M):
Un alumno puede ir a una o ms clases.
En una clase hay uno o varios alumnos.
No hemos puedo la relacin que se crea porque no vamos a relacionarla con nadie. Se
ver luego en el modelo relacional.
Relacin 8 y 9 (1:1 y Arco exclusivo)
Un trabajador puede tener un email
Un alumno puede tener un email.
Un email debe ser de un trabajador o de un alumno.
Relacin 11 y 12 (Dos 1:N entre dos entidades):
Un email puede aparecer como origen en uno o varios mensajes.
Un email puede aparecer como destino en uno o varios mensajes.
Un mensaje debe tener un email de destino.
Un mensaje debe tener un email de origen.
La realidad es que un email puede tener uno o varios email de destino. Pero por
simplificar hemos decidido quedarnos con una versin simplificada para poner de
manifiesto la doble relacin 1:N entre dos entidades.
Tambin debemos ser conscientes que un trabajador o un alumno podran tener varias
cuentas pero solo nos vamos a centrar en la que usamos en la academia.
Relacin 13 (1:N Identifying)
Un alumno tiene una o varias actividades extraescolares.
Una actividad extraescolar es realizada por un alumno.

Imagen 68 Modelo Lgico
Modelo relacional
Imagen 69 Modelo Relacional

DDL
-- Generated by Oracle SQL Developer Data Modeler 4.1.1.888
-- at: 2015-11-22 12:44:03 CET
-- site: Oracle Database 11g
-- type: Oracle Database 11g
DROP TABLE ALUMNO CASCADE CONSTRAINTS ;
DROP TABLE ASIGNATURA CASCADE CONSTRAINTS ;
DROP TABLE AlumnoClase CASCADE CONSTRAINTS ;
DROP TABLE CLASE CASCADE CONSTRAINTS ;
DROP TABLE EMAIL CASCADE CONSTRAINTS ;
DROP TABLE EXTRAESCOLAR CASCADE CONSTRAINTS ;
DROP TABLE LOCALIZACION CASCADE CONSTRAINTS ;
DROP TABLE MENSAJE CASCADE CONSTRAINTS ;
DROP TABLE ProfeAsignatura CASCADE CONSTRAINTS ;
DROP TABLE TRABAJADOR CASCADE CONSTRAINTS ;
DROP TABLE TURNO CASCADE CONSTRAINTS ;
CREATE TABLE ALUMNO

(
IdAlu VARCHAR2 (10) NOT NULL ,
Nombre VARCHAR2 (40) NOT NULL ,
FecNacimiento DATE ,
Tutor VARCHAR2 (100) ,
Sexo CHAR (1)
)
LOGGING ;
ALTER TABLE ALUMNO ADD CONSTRAINT ALUMNO_PK PRIMARY KEY ( IdAlu ) ;
CREATE TABLE ASIGNATURA

(
Sigla VARCHAR2 (5) NOT NULL ,
Curso VARCHAR2 (20) NOT NULL ,
Nombre VARCHAR2 (30) NOT NULL
)
LOGGING ;
ALTER TABLE ASIGNATURA ADD CONSTRAINT ASIGNATURA_PK PRIMARY KEY (
Curso, Sigla ) ;
CREATE TABLE AlumnoClase

(
IdClase VARCHAR2 (10) NOT NULL ,
IdAlu VARCHAR2 (10) NOT NULL
)
LOGGING ;
ALTER TABLE AlumnoClase ADD CONSTRAINT Relation_15_PK PRIMARY KEY (
IdClase, IdAlu ) ;
CREATE TABLE CLASE
(
IdClase VARCHAR2 (10) NOT NULL ,
Fecha DATE NOT NULL ,
IdTrabajador VARCHAR2 (9) NOT NULL ,
Sigla VARCHAR2 (5) NOT NULL ,
IdTurno VARCHAR2 (20) NOT NULL ,
IdLocalizacion VARCHAR2 (10) NOT NULL
)
LOGGING ;
ALTER TABLE CLASE ADD CONSTRAINT CLASE_PK PRIMARY KEY ( IdClase ) ;
CREATE TABLE EMAIL

(
IdEmail VARCHAR2 (5) NOT NULL ,
Direccion VARCHAR2 (30) NOT NULL ,
IdTrabajador VARCHAR2 (9) ,
IdAlu VARCHAR2 (10)
)
LOGGING ;
ALTER TABLE EMAIL ADD CONSTRAINT Arc_1 CHECK ( ( (IdAlu IS NOT NULL)
AND (IdTrabajador IS NULL) ) OR ( (IdTrabajador IS NOT NULL) AND
(IdAlu IS NULL) ) OR ( (IdAlu IS NULL) AND (IdTrabajador IS NULL) ) )
;
CREATE UNIQUE INDEX EMAIL__IDX ON EMAIL ( IdAlu ASC ) LOGGING ;
CREATE UNIQUE INDEX EMAIL__IDXv1 ON EMAIL ( IdTrabajador ASC ) LOGGING
;
Esta restriccin oblige que el correo al menos tenga una estructura de
correo.
ALTER TABLE EMAIL ADD CONSTRAINT Direccion CHECK (Direccion LIKE
'%@%') ;
ALTER TABLE EMAIL ADD CONSTRAINT EMAIL_PK PRIMARY KEY ( IdEmail ) ;
CREATE TABLE EXTRAESCOLAR

(
IdAlu VARCHAR2 (10) NOT NULL ,
IdExEs VARCHAR2 (9) NOT NULL ,
HoraInicio VARCHAR2 (5) NOT NULL ,
HoraFin VARCHAR2 (5) NOT NULL ,
Dia VARCHAR2 (15) NOT NULL
)
LOGGING ;
ALTER TABLE EXTRAESCOLAR ADD CONSTRAINT EXTRAESCOLAR_PK PRIMARY KEY (
IdExEs, IdAlu ) ;
CREATE TABLE LOCALIZACION

(
IdLocalizacion VARCHAR2 (10) NOT NULL ,
Metros NUMBER (3) NOT NULL ,
NumEscritorio NUMBER (1) ,
NumCuadros NUMBER (1) ,
NumSobremesa NUMBER (1) ,
Impresora CHAR (1) ,
NumSillas NUMBER (3) ,
NumMesas NUMBER (2) ,
NumOrdenadores NUMBER (2) ,
Pizarra CHAR (1)
)
LOGGING ;
Las siguientes restricciones han sido creadas por mi en la

tabla Localizacin para implementar la herencia.
ALTER TABLE LOCALIZACION ADD CONSTRAINT Comienzo_Idlocalizacion CHECK
( IdLocalizacion LIKE 'A%' OR IdLocalizacion LIKE 'D%') ;
ALTER TABLE LOCALIZACION ADD CONSTRAINT ArcoExclusivo CHECK

((IdLocalizacion LIKE 'A%' AND NumEscritorio IS NULL AND NumCuadros IS
NULL AND NumSobremesa IS NULL AND Impresora IS NULL) OR
(IdLocalizacion LIKE 'D%' AND NumSillas IS NULL AND NumMesas IS NULL
AND Pizarra IS NULL AND NumOrdenadores IS NULL)) ;
ALTER TABLE LOCALIZACION ADD CONSTRAINT ArcoObligatoriedad CHECK

((IdLocalizacion LIKE 'A%' AND NumMesas IS NOT NULL AND NumSillas IS
NOT NULL) OR (IdLocalizacion LIKE 'D%' AND NumEscritorio IS NOT NULL))
;
ALTER TABLE LOCALIZACION ADD CONSTRAINT LOCALIZACION_PK PRIMARY KEY (
IdLocalizacion ) ;
CREATE TABLE MENSAJE

(
IdMensaje VARCHAR2 (7) NOT NULL ,
HoraEnvio VARCHAR2 (10) ,
FecEnvio DATE ,
IdEmailOrigen VARCHAR2 (5) NOT NULL ,
IdEmailDestino VARCHAR2 (5) NOT NULL ,
Contenido VARCHAR2 (400) NOT NULL
)
LOGGING ;
ALTER TABLE MENSAJE ADD CONSTRAINT MENSAJE_PK PRIMARY KEY ( IdMensaje
) ;
CREATE TABLE ProfeAsignatura

(
Sigla VARCHAR2 (5) NOT NULL
)
LOGGING ;
ALTER TABLE ProfeAsignatura ADD CONSTRAINT ProfeAsignatura_PK PRIMARY
KEY ( IdTrabajador, Curso, Sigla ) ;
CREATE TABLE TRABAJADOR

(
Apellido VARCHAR2 (50) NOT NULL ,
NumSegSocial VARCHAR2 (12) ,
Dni VARCHAR2 (9) ,
Salario NUMBER (6,2) ,
FecContratacion DATE ,
IdTutor VARCHAR2 (9)
)
LOGGING ;
ALTER TABLE TRABAJADOR ADD CONSTRAINT TRABAJADOR_PK PRIMARY KEY (
IdTrabajador ) ;
CREATE TABLE TURNO

(
IdTurno VARCHAR2 (20) NOT NULL ,
HoraInicio VARCHAR2 (5) NOT NULL ,
HoraFin VARCHAR2 (5) NOT NULL
)
LOGGING ;
ALTER TABLE TURNO ADD CONSTRAINT TURNO_PK PRIMARY KEY ( IdTurno ) ;
ALTER TABLE CLASE ADD CONSTRAINT CLASE_LOCALIZACION_FK FOREIGN KEY (

IdLocalizacion ) REFERENCES LOCALIZACION ( IdLocalizacion ) NOT
DEFERRABLE ;
ALTER TABLE CLASE ADD CONSTRAINT CLASE_ProfeAsignatura_FK FOREIGN KEY

( IdTrabajador, Curso, Sigla ) REFERENCES ProfeAsignatura (
IdTrabajador, Curso, Sigla ) NOT DEFERRABLE ;
ALTER TABLE CLASE ADD CONSTRAINT CLASE_TURNO_FK FOREIGN KEY ( IdTurno

) REFERENCES TURNO ( IdTurno ) NOT DEFERRABLE ;
ALTER TABLE EMAIL ADD CONSTRAINT EMAIL_ALUMNO_FK FOREIGN KEY ( IdAlu )

REFERENCES ALUMNO ( IdAlu ) NOT DEFERRABLE ;
ALTER TABLE EMAIL ADD CONSTRAINT EMAIL_TRABAJADOR_FK FOREIGN KEY (

IdTrabajador ) REFERENCES TRABAJADOR ( IdTrabajador ) NOT DEFERRABLE ;
ALTER TABLE EXTRAESCOLAR ADD CONSTRAINT EXTRAESCOLAR_ALUMNO_FK FOREIGN

KEY ( IdAlu ) REFERENCES ALUMNO ( IdAlu ) NOT DEFERRABLE ;
ALTER TABLE MENSAJE ADD CONSTRAINT EmailDestino_FK FOREIGN KEY (

IdEmailDestino ) REFERENCES EMAIL ( IdEmail ) NOT DEFERRABLE ;
ALTER TABLE MENSAJE ADD CONSTRAINT EmailOrigen_FK FOREIGN KEY (

IdEmailOrigen ) REFERENCES EMAIL ( IdEmail ) NOT DEFERRABLE ;
ALTER TABLE AlumnoClase ADD CONSTRAINT FK_ASS_41 FOREIGN KEY ( IdClase

) REFERENCES CLASE ( IdClase ) NOT DEFERRABLE ;
ALTER TABLE AlumnoClase ADD CONSTRAINT FK_ASS_42 FOREIGN KEY ( IdAlu )

REFERENCES ALUMNO ( IdAlu ) NOT DEFERRABLE ;
ALTER TABLE ProfeAsignatura ADD CONSTRAINT

ProfeAsignatura_ASIGNATURA_FK FOREIGN KEY ( Curso, Sigla ) REFERENCES
ASIGNATURA ( Curso, Sigla ) NOT DEFERRABLE ;
ALTER TABLE ProfeAsignatura ADD CONSTRAINT

ProfeAsignatura_TRABAJADOR_FK FOREIGN KEY ( IdTrabajador ) REFERENCES
TRABAJADOR ( IdTrabajador ) NOT DEFERRABLE ;
ALTER TABLE TRABAJADOR ADD CONSTRAINT Tutor_FK FOREIGN KEY ( IdTutor )

REFERENCES TRABAJADOR ( IdTrabajador ) NOT DEFERRABLE ;
Export
--------------------------------------------------------
-- File created - Sunday-November-22-2015
--------------------------------------------------------
REM INSERTING into PROYECTO.ALUMNO
SET DEFINE OFF;
Insert into PROYECTO.ALUMNO (IDALU,NOMBRE,FECNACIMIENTO,TUTOR,SEXO)
values ('A01','Mario Carrasco',to_date('05-NOV-97','DD-MON-
RR'),'Javier','M');
values ('A02','Adela Rodrguez',to_date('04-JUL-00','DD-MON-
RR'),'Estefana','F');
values ('A03','Alejandro Hinojosa',null,'Irene','M');
values ('A04','Carmen Garca',null,'Blanca','F');
values ('A05','Judit Romero',to_date('06-MAY-08','DD-MON-
RR'),'Manoli','F');
REM INSERTING into PROYECTO.EXTRAESCOLAR

SET DEFINE OFF;
Insert into PROYECTO.EXTRAESCOLAR
(IDALU,IDEXES,NOMBRE,HORAINICIO,HORAFIN,DIA) values
('A01','E01','Tenis','18:00','19:00','M Y X');
('A01','E02','Piano','18:00','19:00','L y J');
('A02','E01','Fbtol','16:00','18:00','L , X y V');
REM INSERTING into PROYECTO.ASIGNATURA

SET DEFINE OFF;
Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) values
('MAT','3E','Matematica 3 Eso');
('MAT','1B','Matematica 1 Bachillerato');
('SOC','3E','Sociales 3 Eso');
('BIO','1B','Biologa 1 Bachillerato');
('QUI','2B','Qumica 2 bachillerato');
('LEN','5P','Lengua 5 Primaria');
('FIL','2B','Filosofa 2 Bachillerato');
('DIB','1B','Dibujo 1 Bachillerato');
('ING','4E','Ingles 4 Eso');
REM INSERTING into PROYECTO.TRABAJADOR

SET DEFINE OFF;
Insert into PROYECTO.TRABAJADOR
(IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION
,IDTUTOR) values ('T01','Javier','Garca
Gmez','3145782','31727990L',480,to_date('09-JAN-12','DD-MON-
RR'),null);
,IDTUTOR) values ('T02','Estefana','Rodrguez
Salas',null,'74328745L',480,to_date('04-FEB-13','DD-MON-RR'),null);
,IDTUTOR) values ('T03','Irene','Romero
Vargas','3142342','21846237J',500,null,null);
,IDTUTOR) values ('T04','Blanca','Lpez
Sosa',null,'72364934R',450,to_date('18-NOV-15','DD-MON-RR'),'T01');
,IDTUTOR) values ('T05','Manolio','Curado del
Olmo',null,'44261454G',600,to_date('12-NOV-13','DD-MON-RR'),null);
,IDTUTOR) values ('T06','Manuel','Snchez
Ortiz',null,'28562519F',3300,null,'T05');
REM INSERTING into PROYECTO.PROFEASIGNATURA

SET DEFINE OFF;
Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) values
('T01','1B','MAT');
('T01','3E','MAT');
('T02','2B','QUI');
('T03','4E','ING');
('T04','1B','DIB');
REM INSERTING into PROYECTO.EMAIL

SET DEFINE OFF;
Insert into PROYECTO.EMAIL (IDEMAIL,DIRECCION,IDTRABAJADOR,IDALU)
values ('E01','T01@kma.prof.es','T01',null);
values ('E02','T02@kma.prof.es','T02',null);
values ('E03','A03@kma.alum.es',null,'A02');
values ('E04','A03@kma.alum.es',null,'A03');
REM INSERTING into PROYECTO.TURNO

SET DEFINE OFF;
Insert into PROYECTO.TURNO (IDTURNO,NOMBRE,HORAINICIO,HORAFIN) values
('T1','Turno 1','16:00','17:30');
('T2','Turno 2','17:30','19:00');
('T3','Turno 3','19:00','20:30');
REM INSERTING into PROYECTO.LOCALIZACION

SET DEFINE OFF;
Insert into PROYECTO.LOCALIZACION
(IDLOCALIZACION,NOMBRE,METROS,NUMSILLAS,NUMMESAS,NUMORDENADORES,PIZARR
A,NUMESCRITORIO,NUMCUADROS,NUMSOBREMESA,IMPRESORA) values
('A001','Paris',50,30,15,4,'N',null,null,null,null);
('A002','Londres',60,40,20,10,'S',null,null,null,null);
A,NUMESCRITORIO,NUMCUADROS,NUMSOBREMESA,IMPRESORA) values ('A003','New
York',40,20,10,2,'S',null,null,null,null);
('D01','Oficina',30,null,null,null,null,3,4,3,'S');
REM INSERTING into PROYECTO.MENSAJE

SET DEFINE OFF;
Insert into PROYECTO.MENSAJE
(IDMENSAJE,HORAENVIO,FECENVIO,IDEMAILORIGEN,IDEMAILDESTINO,CONTENIDO)
values ('M01','19:03',to_date('16-NOV-15','DD-MON-RR'),'E01','E03','El
martes no puedo ir a clase');
Insert into PROYECTO.MENSAJE
(IDMENSAJE,HORAENVIO,FECENVIO,IDEMAILORIGEN,IDEMAILDESTINO,CONTENIDO)
values ('M02','17:04',to_date('10-NOV-15','DD-MON-
RR'),'E02','E01','Puedes cubrirme la clase de Qumica.');
REM INSERTING into PROYECTO.CLASE

SET DEFINE OFF;
Insert into PROYECTO.CLASE
(IDCLASE,FECHA,IDTRABAJADOR,CURSO,SIGLA,IDTURNO,IDLOCALIZACION) values
('C01','16-NOV-15','T01','3E','MAT','T1','A001');
('C02','16-NOV-15','T02','2B','QUI','T2','A002');
('C03','16-NOV-15','T03','4E','ING','T3','A003');
REM INSERTING into PROYECTO.ALUMNOCLASE

SET DEFINE OFF;
Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) values ('C01','A01');

Apuntes Base de Datos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apuntes Base de Datos

Uploaded by

Copyright:

Available Formats

Diseo de bases de datos relacionales

Javier Garca Gmez

Esta obra est bajo una Licencia CreativeCommons Atribucin

Usted es libre de:

Copiar, distribuir y comunicar pblicamente la obra

Remezclar transformar la obra

Bajo las condiciones siguientes:

Reconocimiento Debe reconocer los crditos de la obra de la manera especificada por el

No comercial No puede utilizar esta obra para fines comerciales.

Los derechos morales del autor;

Modelo Entidad Relacin:

Un modelo es un esquema mental (conceptual) en el que se intenta reproducir las

El Modelo Entidad-Relacin es un modelo que sirve para crear esquemas conceptuales

Si vamos a informatizar una academia. Algunas de las entidades que tiene

Un atributo es una pieza de informacin vinculada a una entidad. Las entidades

1:1 = de uno a uno

Primary Key (sinnimos: clave primaria, UID Primario, PK, P, #)

La Primary Key es un atributo, o grupo de atributos, que identifica de forma nica a

La entidad vuelo y la entidad pasajero tendran este tipo de relacin. Dicha

Un vuelo puede tener uno o varios pasajeros.

Un pasajero debe viajar en un vuelo.

Cuando se establece una relacin 1:N entre la entidad A y la entidad B, la

Varias relaciones 1:N entre dos entidades

Si seguimos pensando en un aeropuerto. La entidad aeropuerto y la entidad

Un vuelo debe tener un aeropuerto de origen.

Un aeropuerto es origen de uno o varios vuelos

Un vuelo debe tener un aeropuerto de destino.

Un aeropuerto es destino de uno o varios vuelos.

CONSEJOS Y BUENAS PRCTICAS

En este caso tenemos dos FK en la entidad vuelo que provienen de la entidad

Un trabajador puede actuar como chofer en uno o varios autobuses.

Alguien podra argumentar que un autobs es conducido en cada instante por un

La forma de enfocar la identificacin de esta nueva entidad depender de nuestra

Imaginemos una flota de autobuses donde queremos recoger las reparaciones.

La nueva entidad que se crea podra llamarse reparacin. Esta no quedara

La obligatoriedad u opcionalidad en el origen tendr consecuencias al hacer nuestro

Si la relacin es obligatoria, al trabajar con los datos y eliminar una instancia de la

Si la relacin es opcional, al intentar eliminar una instancia de la entidad del origen

Si queremos introducir los ordenadores que vende una tienda de informtica.

Si entramos en http://www.oracle.com/es/index.html, nos encontramos con laImagen 1.

Pinchamos en la opcin remarcada en amarillo de la Imagen 1y dentro de ella elegimos

Para descargar el sqldeveloper basta con pinchar en la opcin en rojo de la Imagen 1.

El SQLdeveloper slo necesita ser descomprimido. Para ello es necesario tener un

Importante! Si tenamos un enlace en la barra de tareas tendremos que eliminarlo y

En la Imagen 7podemos ver el SQLdeveloper con la apariencia con la que solemos

Ahora vamos a distinguir entre SQLdeveloper y Datamodeler. Como hemos comentado,

Gracias a esta operacin se nos ha creado la zona 4 que observbamos en laImagen 7.

Se nos abrir la subventana de la Imagen 13.

CONSEJOS Y BUENAS PRCTICAS

Se debe establecer un criterio del uso de maysculas y minsculas, guiones y

A la hora de realizar varias prcticas es interesante aadir un identificador de

Name: indicamos que nombre tendr nuestro atributo.

Mandatory: Si marcamos dicho opcin estamos diciendo que es un campo obligatorio.

Las flechas nos permite reordenar los atributos.

CONSEJOS Y BUENAS PRCTICAS

No se debe tener redundancia de atributos, con varios atributos similares dentro

La PK debe ser siempre el primer atributo de la entidad.

Cuando la PK est formada por ms de un atributo, aparece primero el atributo

La # indica que ese atributo es la primarykey.

El * indica que dicho atributo es obligatorio.

0 Indica que dicho atributo es opcional.

Creacin de la relacin 1:N

Lo primero que hacemos es crear la entidad vuelo y la entidad pasajero.

1. Indica el nombre que tendr la relacin. Al principio solemos dejar el nombre