• Categories
• Herencia (Programación orientada a objetos)
• SQL
• Bases de datos
• Teoría de modelos
• Tabla (Base de datos)

Citation preview

Diseño de bases de datos relacionales Modelo Entidad-Relación

Javier García Gómez

LICENCIA Esta obra está bajo una Licencia CreativeCommons Atribución – 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 públicamente la obra Remezclar — transformar la obra Bajo las condiciones siguientes: Reconocimiento — Debe reconocer los créditos 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, sólo puede distribuir la obra generada bajo una licencia idéntica 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 Público — Cuando la obra o alguno de sus elementos se halle en el dominio público según la ley vigente aplicable, esta situación 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 legítimos 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 términos de la licencia de esta obra.

INDICE Introducción: ................................................................................................................................. 5 Modelo Entidad Relación: ............................................................................................................. 5 Conceptos:................................................................................................................................. 5 Conceptos principales: .......................................................................................................... 5 Entidad .............................................................................................................................. 5 Atributo ............................................................................................................................. 6 Relación ............................................................................................................................. 6 Conceptos secundarios: ........................................................................................................ 7 Instancia ............................................................................................................................ 7 Primary Key (sinónimos: clave primaria, UID Primario, PK, P, #) ...................................... 7 Tipo de datos ..................................................................................................................... 7 Estructura de tablas .......................................................................................................... 8 Relaciones ................................................................................................................................. 8 Relación1:N ........................................................................................................................... 8 Varias relaciones 1:N entre dos entidades............................................................................ 9 Relación 1:N Identificación y Entidad débil......................................................................... 10 Relación 1:1 ......................................................................................................................... 10 RelaciónM:N ........................................................................................................................ 11 Relación recursiva ............................................................................................................... 13 Herencia .............................................................................................................................. 13 Arco exclusivo...................................................................................................................... 14 Herramientas: ......................................................................................................................... 15 Modelo lógico.......................................................................................................................... 19 Crear Entidades ................................................................................................................... 20 Creación atributos ............................................................................................................... 22 Creación de modelos ............................................................................................................... 24 Creación de la relación 1:N ................................................................................................. 24 Modelo lógico.................................................................................................................. 24 Modelo Relacional........................................................................................................... 27 Generación del DDL ......................................................................................................... 29 Introducir datos en tablas de SQL Developer ................................................................. 35 Creación de varias relaciones 1:N entre dos entidades ...................................................... 35 Modelo lógico y relacional .............................................................................................. 35

Creación de una relación 1:NIdentifying ............................................................................. 36 Modelo lógico .................................................................................................................. 36 Modelo relacional ........................................................................................................... 37 Creación del DDL ............................................................................................................. 38 Creación de una relación 1:1 ............................................................................................... 39 Modelo lógico .................................................................................................................. 39 Modelo relacional y DDL ................................................................................................. 40 Creación de una relación M:N ............................................................................................. 41 Modelo lógico.................................................................................................................. 41 Modelo relacional ........................................................................................................... 43 Del modelo relacional al modelo lógico .......................................................................... 44 Creación de una relación recursiva ..................................................................................... 44 Modelo lógico .................................................................................................................. 44 El modelo relacional ........................................................................................................ 45 Herencia .............................................................................................................................. 45 Modelo lógico .................................................................................................................. 45 Modelo relacional ........................................................................................................... 46 ¿Cómo hemos creado los diferentes modelos relacionales?.......................................... 47 Restricciones ....................................................................................................................... 50 Restricciones para 1 Tabla:.............................................................................................. 50 Modelo a tres tablas........................................................................................................ 55 Creación 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 Lógico ..................................................................................................................... 68 Modelo relacional ............................................................................................................... 71 DDL ...................................................................................................................................... 72 Export .................................................................................................................................. 76

Introducción: En estos apuntes encontrarás una guía para afrontar el primer parcial de base de datos del módulo de administración de redes. Al final de ella deberás ser capaz de entender el modelo Entidad- Relación. Además aprenderás 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 teórico, luego la instalación del software y por último como hacer cada paso del modelo en el programa. Al final de cada contenido teórico habrá un hipervínculo que nos lleve a como se hará en el programa. Durante el desarrollo del curso ambas cosas se irán alternando pero he creído que es más clarificador tener toda la teoría y luego todo el desarrollo informático. De esa forma creo que es más rápido encontrar el contenido. Por último veremos un proyecto algo más complejo donde trabajaremos con las diferentes relaciones.

Modelo Entidad Relación: Un modelo es un esquema mental (conceptual) en el que se intenta reproducir las características de una realidad específica. Su finalidad es la de simbolizar una parte del mundo real de forma que sea más fácilmente manipulable. El Modelo Entidad-Relación es un modelo que sirve para crear esquemas conceptuales de bases de datos. De hecho es prácticamente un estándar para crear esta tarea. Se le llama modelo E/R e incluso EI (Entidad / Interrelación). Sus siglas más populares son las E/R porque sirven para el inglés y el español. Fue ideado por Peter Chen en los años 1976 y 1977 a través de dos artículos. Inicialmente, en la propuesta de Chen, sólo se incluían los conceptos de entidad, relación y atributos. Después se añadieron otros conceptos (atributos compuestos, generalizaciones...) que forman el llamado modelo entidad relación 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 información más relevante, en función de la temática de la información 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 serán conceptos que dependen del elemento alumno.

1

Extraído del libro Diseño Conceptual de Bases de Datos – guía de aprendizaje. Jorge Sánchez. 2004

Atributo

Un atributo es una pieza de información vinculada a una entidad. Las entidades almacenan la información en los atributos.

EJEMPLO Para la entidad trabajador tiene sentido poner los atributos Nombre, Dni, Sueldo,etc.

Relación

Una relación es un vínculo que establece una asociación 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 serán intuitivas pero otras serán fruto de lo que queremos construir. Debemos ser conscientes que el ordenador sólo va a entender que tipo de relación existe(1:N, M;N, etc) pero no que esta relacionando.

EJEMPLO Vamos a suponer que estamos estudiando una cadena comercial como podría ser Burger King. Es coherente tener una entidad que fuera local donde guardaríamos toda la información correspondiente a nuestros locales (Donde se encuentran, metros cuadrados, horarios de apertura, etc). También parece lógico tener una entidad que fuera empleados. En ella tendríamos 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 también podría 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 sólo ve la relación como algo que restringes los datos que puede recibir una entidad.

Conceptos secundarios: Instancia

Una instancia es una pieza o conjunto de piezas de información concreta, que responden a los atributos de una entidad. Es cada una de las entradas de contenido real de la entidad. En una visualización 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 podría ser: El trabajador Marco Rodríguez, con Dni 31727880L, nacido 20/08/1976 y cuyo sueldo son 700 euros.

Primary Key (sinónimos: 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 combinación 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 librería. La mayoría de las veces tendremos que crearla nosotros. Lo suyo es que sea corta y fácil de usar.

EJEMPLO Para la entidad trabajador, ademas de los atributos nombre, sueldo hay que crear otro que identifique inequívocamente a cada instancia. Éste podría 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 combinación de escalera + planta + puerta sólo habrá una vivienda.

Tipo de datos

Los atributos pueden contener información de muchos tipos. Éstos son algunos de ellos, que pertenecen al conjunto de tipos de datos lógicos: 

Varchar (Varchar2): dato con formato alfanumérico (textos con letras, números, espacios y símbolos) de tamaño variable. Procede del inglés “VARiableCHARacter”.

o





Tamaño: cantidad de caracteres que puede almacenar el campo como máximo. Es obligatorio indicar un valor puesto que si no lo hacemos obtendremos errores.

Number (Numeric): dato con formato de número. Conviene utilizar sólo cuando se van a realizar operaciones matemáticas con dicho número. Por ejemplo, un atributo de salarios o de poblaciones de ciudades debería ser del tipo number, pero para guardar el DNI o números de teléfono podría ser simplemente varchar. o

Precisión: cantidad de dígitos que pueden componer como máximo el número.

o

Escala: cantidad de dígitos, del total de la precisión, que están reservados para los decimales del número.

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 información concreta de cada columna o atributo.

Relaciones Vamos ahora a ver las diferentes relaciones que existen.

Relación1:N Una relación 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 sólo se relaciona con una instancia de A.

EJEMPLO La entidad vuelo y la entidad pasajero tendrían este tipo de relación. Dicha relación podría leerse de la siguiente forma: Un vuelo puede tener uno o varios pasajeros. Un pasajero debe viajar en un vuelo.

CONSEJOS Y BUENAS PRÁCTICAS Cuando se establece una relación 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 través de una relación. 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 relación, pueden crearse más 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 relación. En este caso no podemos dejarle el mismo nombre que la Primary Key de la que viene ya que tendríamos dos atributos con el mismo nombre. En este caso solemos renombrar la FK dándole un nombre que identifique que relación esta cumpliendo.

EJEMPLO Si seguimos pensando en un aeropuerto. La entidad aeropuerto y la entidad vuelo tendrán como mínimo dos relaciones 1:N que se leerían 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.

CONSEJOS Y BUENAS PRÁCTICAS 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 más coherente renombrarla de forma que se entienda que función está cumpliendo. En nuestro ejemplo sería lógico ponerle IdVueloOrigen e IdVueloDestino.

Relación 1:N Identificación y Entidad débil Una entidad débil es una entidad estrechamente relacionada con otra. Por sí misma, la entidad débil no tiene sentido. La Primary Key de una entidad débil 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 débil como Foreign Key y parte de la Primary Key a la vez. Esto se hace mediante la relación “1:N Identificación”. Por tanto una relación 1:N Identificación es como una relación 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 también 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 débil con irrelevante. En una academia puede ser muy importante saber que actividades extraescolares tienen los alumnos. Pero la entidad en si es débil ya que no nos interesa que actividades extraescolares tienen o a que se dedican en ella, nos interesan en relación a nuestros alumnos. Nos interesa saber que un alumno juega al fútbol de 17 a 18 pero que hace dentro de esa actividad nos da igual. En general, esta relación se usa cuando la entidad que creamos se enfoca en función 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 tendría guardado los tipos de accesorios que puedo montar. Pero a su vez tendría sentido tener una entidad que fuera accesorios coche que estuviera relacionada con los coches. De esa forma sabría que accesorios concretos tendría cada coche.

Relación 1:1 Una relación 1:1 es una relación en la que una instancia de una entidad A se relaciona sólo con otra instancia de otra entidad B, y cada instancia de B sólo se relaciona también 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 relación 1:1 la PK de una entidad viaja a la otra como FK en función 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 envíe su PK a la otra como FK. Si ninguna tiene rol dominante, cada una de las dos enviará su PK, de tal modo que también cada una de las dos recibirá como FK la PK de la otra.

RelaciónM:N En una relación 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á también 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 serán vehículos. Una relación M:N sería: Un trabajador puede actuar como chofer en uno o varios autobuses. Un vehículo del tipo autobus puede ser conducido por uno o varios choferes. Alguien podría argumentar que un autobús es conducido en cada instante por un único chofer. Que no son muchos los que lo conducen. Pero debemos pensar que en la entidad autobús guardamos los datos del autobús a lo largo de su vida. En su vida, lo más 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 información de toda la vida que tenga dicho trabajador ergo es lógico pensar que conducirá diferentes autobuses en su vida. Cuando creamos una relación 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 identificación 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 serán además ForeignKey en la nueva entidad, ya que la relación entre cada una de las dos entidades iniciales y la nueva entidad es del tipo 1:N Identificación. Por tanto esta relación M:N equivale a dos relaciones 1:N Identificación con esa nueva entidad. 2 Posibilidad La Primary Key de esta nueva entidad estará formada por las PrimaryKey de las dos entidades iniciales, que serán además ForeignKeys en la nueva entidad, ya que la relación entre cada una de las dos entidades iniciales y la nueva entidad es del tipo 1:N Identificación. Pero añadimos un atributo adicional que también será PrimaryKeys. Por tanto esta relación M:N equivale a dos relaciones 1:N Identificación 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 añadamos y las dos PrimaryKey de las entidades iniciales serán solo Foreign Key en la nueva entidad.

EJEMPLO Imaginemos una flota de autobuses donde queremos recoger las reparaciones. Aunque lo normal sería tener una entidad con todos los trabajadores y otra con los vehículos por simplificar supondremos que tenemos la entidad Mecánico y la entidad Autobús. La relación lógica se leería así: Un mecánico puede estar presente en una o varias reparaciones. Un autobús puede ser reparado por uno o varios mecánicos. La nueva entidad que se crea podría llamarse reparación. Esta no quedaría perfectamente identificada con las dos PK que llegan ya que un mismo autobús puede ser reparado en el tiempo por el mismo mecánico. Para desempatar necesitamos un nuevo campo que haga ayude. Si es mejor quitarle el papel de PK al id del mecánico y al id del autobús y dejar solo un id de reparación o guardar los tres será algo que decidamos según nos comente el cliente. Depende la opción estaríamos 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 relación M:N como dos relaciones 1:N Identificación y una tercera entidad, esas relaciones podrán ser opcionales u obligatorias en el origen, partiendo desde las entidades iniciales. En el destino, es decir en la nueva entidad, serán siempre obligatorias, como todas las relaciones 1:N Identificación. La obligatoriedad u opcionalidad en el origen tendrá consecuencias al hacer nuestro modelo en el ordenador. Las comento brevemente aunque se verá con más detalle en la práctica. Si la relación es obligatoria, al trabajar con los datos y eliminar una instancia de la entidad del origen, también se eliminarán automáticamente 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 relación es opcional, al intentar eliminar una instancia de la entidad del origen veremos que no podemos hacerlo, puesto que dejaríamos a una o más instancias huérfanas 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 relación N:M puede a su vez relacionarse con otras entidades.

Relación recursiva Una relación recursiva es una relación que asocia a una entidad consigo misma, en lugar de con otra entidad distinta. EJEMPLO Un equipo de fútbol puede tener uno o varios rivales máximos. Por ejemplo, el Real Betis es el rival directo del Sevilla FC, o el Real Madrid es el rival directo del Atlético de Madrid y del FC Barcelona. Pero todos son equipos de fútbol, 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 categoría superior, también conocido como supertipo. La herencia no es en si una relación, es más una clasificación. EJEMPLO Si queremos introducir los ordenadores que vende una tienda de informática. Sería interesante conocer el fabricante, el microprocesador, el sistema operativo. Pero que sucede con la batería, este campo no tiene sentido en los sobremesa, al igual que el tipo de torre no tendrá sentido en un portátil. Para resolver este dilema, creamos la entidad Ordenador, la entidad Sobremesa y la entidad Portátil. Estas dos últimas entidades serán “hijos” de la entidad “padre” Ordenador. Así que un portátil tendrá los atributos propios de su entidad más los atributos que hereda de su padre. Estas subclases dentro de una clase mayor es lo que crea el concepto de herencia. En la práctica tendremos una entidad Ordenador con los atributos que comparten todas las subclases. Dicho de forma más técnica: En una herencia, los campos compartidos por todos los subtipos se colocan en el supertipo o entidad padre. De esta forma todos los subtipos heredarán esos atributos, y son los campos concretos de cada subtipo los que se colocarán 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 restricción que afecta a dos o más relaciones que comparten la entidad de destino, de tal forma que en cada instancia de la entidad de destino sólo 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 compañía puede ofrecer al cliente una posibilidad para que además del paquete pueda llegar al punto de salida. Para llegar dicho lugar podrá usar diferentes medios. En nuestro ejemplo, supongamos que puede llegar en avión o en barco. Si la agencia tuviera interés en registrar este dato, tendríamos 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 Avión. Esta elección es lo que conocemos como arco exclusivo. Un arco exclusivo lo que hace en realidad es añadir una instrucción SQL al archivo DDL que contiene la estructura de la base de datos. Dicha instrucción 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 sólo una de las FK puede contener información y las demás deben estar vacías. O estar todas las FK implicadas vacías.

Herramientas: Vamos a trabajar con Sqldeveloper4.1.1 que necesitará Oracle como programa de servicio. En nuestro caso vamos usar la versiónOracle 11g R2 Express Edition. Si entramos en http://www.oracle.com/es/index.html, nos encontramos con laImagen 1.

Imagen 1

Pinchamos en la opción remarcada en amarillo de la Imagen 1y dentro de ella elegimos la opción que nos interese dentro de laImagen 2.

Imagen 2

El único inconveniente es que nos pedirán que nos registremos. Por suerte es gratuito. Para descargar el sqldeveloper basta con pinchar en la opción en rojo de la Imagen 1. Saldrá la Imagen 3donde escogeremos la versión que nos interese.

Imagen 3

Vemos que esta versión trae consigo una máquina virtual java. Existen versiones donde la máquina virtual no viene integrada y es necesario tener una instalada en el ordenador. Además, vamos a ver que esta versión 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 instalación de Oracle no tiene ningún misterio pero debemos recordar que clave le hemos puesto a nuestro administrador ya que la necesitaremos más adelante. La contraseña que le pusimos este año 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 estén 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 sólo necesita ser descomprimido. Para ello es necesario tener un programa capacitado para ello, como podría ser el winrar o el winzip.

Imagen 6

Dentro de la carpeta sólo 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 bilingüe 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 añadirmos al final del documento. AddVMOption -Duser.language=en AddVMOption -Duser.country=US Importante! Si teníamos 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 irán 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 versión de SQLdeveloper. Muchos ordenadores tienen problema con esta versión, una solución es bajarse el datamodeler y el sqldeveloper por separado. Datamodeler va a dedicarse a crear lo que llamaremos el modelo lógico 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 teóricamente. Además, vamos a ver como se implementa la relación en el ordenador y que consecuencias crea. Es interesante ir mirando la teoría a medida que se sigue el ejemplo ya que es vital entender que se esta haciendo.

Modelo lógico Para empezar a crear un módelo lógico lo más intuitivo sería 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 lógico 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 operación se nos ha creado la zona 4 que observábamos en laImagen 7. En la Imagen 9podemos verla más 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 página. Todo estos pasos podemos verlo en laImagen 12.

Imagen 12

Se nos abrirá la subventana de la Imagen 13.

Imagen 13

CONSEJOS Y BUENAS PRÁCTICAS Las entidades se nombran en singular. Los nombres deben ser cortos y claros. No deben contener caracteres extraños o exclusivos del alfabeto español (ñ, tildes...). Se debe establecer un criterio del uso de mayúsculas y minúsculas, guiones y demás 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 minúsculas y si hay más de una palabra, se escriben todas juntas escribiendo la primera letra de las siguientes palabras en mayúsculas. Ejemplo: UnoDosTres, telefonoFijo. A la hora de realizar varias prácticas es interesante añadir un identificador de dicha práctica. Ejmplo: P1_Alumno. Sería la entidad alumno de la práctica 1. Es aconsejable utilizar nombres generales para las entidades, para poder utilizar la misma entidad para el mayor número 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 irán en mayúsculas.

Creación atributos Cada entidad va a tener una serie de atributos. Para crearlos nos vamos a la pestaña 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 más frecuente. Primary UID: Si marcamos esta opción estamos diciendo que dicho atributo será parte de la Primary Key de nuestra identidad. Mandatory: Si marcamos dicho opción 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 opción estamos obligando que al introducir datos dentro de la entidad, todos esos campos no pueden quedarse vacíos. A veces interesa poder dejar parte de la información sin rellanar y posteriormente tener un programita o aplicación que nos diga que algunos campos están vacíos por acelerar el proceso. Las flechas

Imagen 15

nos permite reordenar los atributos.

El atributo de la Imagen 15va a identificar la identidad alumno de nuestro ejercicio. Es un varchar de tamaño 9 (es decir, podrá tener 9 caracteres alfanuméricos). El atributo de la Imagen 16es el número de asignaturas que tiene el alumno. Sería una variable numérica. Donde la precisión indica el número 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 serviría pero 1000,1 no valdría. Ni 10,134.

Imagen 16

CONSEJOS Y BUENAS PRÁCTICAS Los nombres deben ser cortos y claros. No deben contener caracteres extraños o exclusivos del alfabeto español (ñ, tildes...). Todos los atributos de una entidad deben tener una relación 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 deberían estar en otra entidad cliente. El atributo que será o los atributos que serán nuestra PK es interesante que no sean muy genéricos. Si por ejemplo es un código y la entidad es alumno. Sería interesante poner AluCod en vez de código No se debe tener redundancia de atributos, con varios atributos similares dentro de una misma entidad. Cuando sucede, es una señal de que estamos diseñando la base de datos mal. Por ejemplo, no se debe tener en una entidad empleado los atributos cónyuge, hijo1, hijo2, hijo3... En su lugar debería haber otra entidad familiar relacionada con empleado. La PK debe ser siempre el primer atributo de la entidad. Cuando la PK está formada por más de un atributo, aparece primero el atributo más general y luego los más concretos, por orden. Por ejemplo, primero edificio, después 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.

Creación de modelos Vamos a ir viendo ahora como se crea cada una de las relaciones que hemos visto teóricamente. En general crearemos primero un modelo lógico, luego construiremos a partir de este un modelo relacional. Este modelo teórico serán 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 algún otro lugar. Veremos además, que fallos nos indicará el programa en relación con el tipo de relación que estamos trabajando. Para ello, observaremos que relaciones existen, y veremos las restricciones que se crean.

Creación de la relación 1:N Modelo lógico

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

Imagen 18

Imagen 19

Hemos pinchado en el círculo naranja de laImagen 19. Luego pinchamos en una de las entidades y nos movemos hacía la otra. Observamos en la Imagen 19quese crea una línea 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 relación. Al principio solemos dejar el nombre por defecto pero en un proyecto grande, es interesante darle un nombre a cada relación de forma que sepamos cual es su función. 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 símbolo 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 símbolo 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, sería obligatorio. 8. Esta casilla convertiría la relación en una que veremos más adelante. Será la relación 1:N identificadora.

Cuando termines de marcar las opciones que nos interesen le damos a Ok. Al hacerlo se nos crea la relación que podemos observar en la Imagen 21 donde he remarcado los elementos de interés. Si más adelante vemos que la relación es diferente podemos hacer doble click en la relación para cambiarla.

Imagen 21

CONSEJOS Y BUENAS PRÁCTICAS Aunque en la realidad sea lógico 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 añadirá nada si ponemos debe en vez de puede en la entidad 1. Para poder controlar que un vuelo no puede ir vacío. Es decir, que debe tener pasajeros necesitaremos un programa que haga dicha comprobación. El programa no añade nada por un buen motivo. Cuando creemos las tablas y vayamos a meter datos nos encontraríamos en un bucle infinito. Si quiero añadir vuelos necesito tener pasajeros para dicho vuelo así que tendría 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 botón 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 ratón. 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 relación. Dicho atributo lleva una F para indicar que es una Foreignkey. Por tanto, hemos corroborado que cuando creamos una relación 1:N, la PK de 1 viaja a la entidad N. Recuadro gris: indica el nombre de la restricción o constrain que crea una primarykey. Cuando estemos introduciendo datos, si pasamos por alto rellenar el número 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 restricción o constrain que crea la relación 1:N. Que indica que el campo FK es un campo obligatorio (podría no serlo, depende las opciones que hayamos puesto) y que además 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 número 001. Hemos dicho que es interesante que la FK tenga el mismo nombre que la PK, pero hemos visto que al crear la relación, esto no sucede de forma natural. Vamos a ver como podemos cambiar este valor, además 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 más interesante que podemos hacer. General: nos permitiría cambiar el nombre de la entidad. Esta opción no parece muy interesante pero veremos que en la relación 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 restricción 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 restricción de la foreignkey. Es interesante poner un valor que no sea excesivamente grande y que este relacionado con la relación que la ha creado. El límite de caracteres es de 30. A veces, el programa automáticamente la crea con una extensión mayor, así que debemos estar atentos si nos da un error al crearse el DDL, ya que el error podría venir de aquí. El resto de opciones o no tienen interés o se escapan de nuestros dominios para este curso. Generación 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 diseñamos en Data Modeler a nuestra base de datos en SQL Developer utilizaremos los archivos DDL.

Para crearlo pinchamos en el símbolo 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 opción 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 añadimos .sql. Veamos las instrucciones que se han creado para este tipo de relación 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 más difícil 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 más 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. Borraría la tabla pasajero del usuario 1 aunque la estuviera ejecutando el usuario 2. Aunque el usuario 2 tendría 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 añade una constraint (restricción) que indica que DNI es la PK y por tanto no podrá estar vacía. Pasajero_PK será el nombre de referencia cuando se viole dicha restricción. 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 añadido la restricción de cual es su primarykey. ALTERTABLE Pasajero ADDCONSTRAINTPasajero_Vuelo_FKFOREIGNKEY(NUMERO)REFERENCES Vuelo ( NUMERO );

Aquí se añade una nueva restricción. En este caso es añadir que numero es una foreignkey en la tabla pasajero y que esta relacionada con el atributo numero de la tabla vuelo. Las líneas que vienen a continuación podemos eliminarlas ya que no sirven para nada. -----------------------------

Oracle SQL Developer Data Modeler Summary Report: CREATE TABLE CREATE INDEX ALTER TABLE CREATE VIEW ALTER VIEW CREATE PACKAGE CREATE PACKAGE BODY CREATE PROCEDURE CREATE FUNCTION CREATE TRIGGER ALTER TRIGGER CREATE COLLECTION TYPE CREATE STRUCTURED TYPE CREATE STRUCTURED TYPE BODY CREATE CLUSTER CREATE CONTEXT CREATE DATABASE CREATE DIMENSION CREATE DIRECTORY CREATE DISK GROUP CREATE ROLE CREATE ROLLBACK SEGMENT CREATE SEQUENCE CREATE MATERIALIZED VIEW CREATE SYNONYM CREATE TABLESPACE

2 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

--------------

CREATE USER

0

DROP TABLESPACE DROP DATABASE

0 0

REDACTION POLICY

0

ORDS DROP SCHEMA ORDS ENABLE SCHEMA ORDS ENABLE OBJECT

0 0 0

ERRORS WARNINGS

0 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 lógico 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 sólo podemos abrir archivos que tengan extensión dmd, dmdz y xml. Por tanto, no podríamos abrir nuestro *.sql Así que debemos tener cuidado y darle a open estando en start page o en la página 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 botón que comenzará la ejecución de las instrucciones. Cuando pulsemos nos pedirá que digamos con que usuario queremos ejecutar las instrucciones. Una vez elegido, las instrucciones se irán ejecutando. En la zona 3 hay un log donde se pueden ver lo que ha ocurrido. Es interesante por si hay algún fallo. Para ejecutar las instrucciones voy a usar el usuario USU1 que cree en su día. Como se crean usuarios está en otra zona del manual, como vas a necesitar crear uno, pincha aquí si todavía no lo tienes.

Imagen 31

CONSEJOS Y BUENAS PRÁCTICAS 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 conexión esta activa, simplemente se ejecutarán las ordenes. Sin embargo, si la conexión 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 acción Si al crear el DDL marcamos los drop, veremos que al ejecutarse por primera vez darán error ya que no existen las tablas que queremos eliminar.

Introducir datos en tablas de SQL Developer 

Iniciar la conexión correspondiente > Desplegar el elemento “Tablas” > Clic en la tabla deseada > Clic en la pestaña “Datos” > Botón “Insertar Fila” > Introducir los datos de los atributos (columnas) de la instancia (fila) que queramos rellenar > Botón “Confirmar”

Si incumplimos alguna restricción al introducir el dato, por ejemplo porque no hayamos rellenado un atributo obligatorio, porque hayamos puesto letras en un campo numérico, o porque no hayamos puesto un valor válido en una Foreign Key (para que sea válido, el valor debe ser el mismo que el de la Primay Key correspondiente de alguna instancia en la entidad (tabla) origen de la relación que ha generado la Foreing Key), al Confirmar obtendremos un error en el panel de Log que nos indicará la restricción que está siendo violada. Tendremos que corregir la fila para poder confirmarla y que queden almacenados sus datos. El tema de introducción de datos, la exportación de los datos y las ordenes internas las veremos más detalladamente cuando terminemos de ver todas las relaciones ya que funcionan igual para cualquier tipo de relación que hagamos. Incluso, veremos que además de las restricciones que crean las entidades por defecto podremos añadir nuestras propias restricciones.

Creación de varias relaciones 1:N entre dos entidades Modelo lógico y relacional

Los pasos a seguir para crear varias relaciones son los mismos que para crear una sola relación. Ya dijimos que de normal es interesante tener el mismo nombre en la foreignkey la primarykey, esta es la excepción 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 misión que cumple. En las imágenes vamos a ver como queda el modelo lógico y el relacional y como se leerían 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. Además, la clave que marca la violación de dicha relación la hemos renombrado a TCUENTAORI y TCUENTADES para que sea más intuitiva. No vamos a hablar más sobre esta relación porque realmente todo es igual que antes salvo que tenemos dos en vez de una.

Creación de una relación 1:NIdentifying

Modelo lógico

Si observamos laImagen 34. Podemos observar el modelo lógico de una relación 1:NIdentifying. Para crearlo los pasos han sido: 1. Crear las dos entidades. 2. Pinchar en el botón remarcado en negro en la Imagen 34. 3. Pulsa sobre la entidad trabajador. 4. Arrastrar la línea hasta la entidad hijo.

Imagen 34

Si pinchamos sobre la relación vemos la Imagen 35 que es igual a la Imagen 20.

Imagen 35

Como ya comentamos, si marcábamos la casilla 8 de la Imagen 20 obteníamos una relación 1:NIdentifying. Por ese motivo, cuando usamos la opción crear 1:NIdentifying la relación 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 relación 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

CONSEJOS Y BUENAS PRÁCTICAS Ya comentamos que el primer atributo debe ser la primarykey de la entidad. En el caso de una relación 1:NIdentifying ponemos la PF (primarykey, foreignkey) como primer atributo. Para ello pinchamos en la tabla y en colum usamos para desplazarlo arriba.

Creación del DDL

Para crear el DDL seguimos los mismos pasos que para la relación 1:N. Echemos un vistazo al DDL del ejemplo y veamos que la diferencia de una relación 1:N.

DROPTABLE P10_HIJO CASCADECONSTRAINTS; DROPTABLE P10_TRABAJADOR CASCADECONSTRAINTS; CREATETABLE P10_HIJO ( DNI VARCHAR2(9)NOTNULL, IDHIJO VARCHAR2(4)NOTNULL, NOMBRE VARCHAR2(30)NOTNULL, APELLIDO VARCHAR2(50), F_NACIMIENTO DATE ); ALTERTABLE P10_HIJO ADDCONSTRAINT P10_HIJO_PK PRIMARYKEY( IDHIJO, DNI );

Aquí esta la clave. Al añadir la restricción 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 ( DNI VARCHAR2(9)NOTNULL, NOMBRE VARCHAR2(30)NOTNULL, APELLIDO VARCHAR2(50), CARGO VARCHAR2(30), SUELDO NUMBER(6,2)NOTNULL );

ALTERTABLE P10_TRABAJADOR ADDCONSTRAINT P10_TRABAJADOR_PK PRIMARYKEY( DNI);

ALTERTABLE P10_HIJO ADDCONSTRAINT DNI)REFERENCES P10_TRABAJADOR ( DNI );

HIJOTRABAJADOR_FK

FOREIGNKEY(

Una vez creado el DDL.sql, seguiremos los mismos pasos que para la relación 1:N. Como ya dijimos antes, la introducción de datos lo veremos al final de todas las entidades.

Creación de una relación 1:1 Modelo lógico

En la Imagen 37 podemos ver el modelo lógico de una relación 1:1. Para crearlo los pasos han sido: 1. Crear las dos entidades. 2. Pinchar en el botón remarcado en negro en la Imagen 37. 3. Pulsa sobre la entidad Personal. 4. Arrastrar la línea 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 relación. 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 prácticas 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 instrucción cada elemento de una entidad solo podrá estar relacionado con uno de la otra entidad. En nuestro ejemplo, distintas sucursales no podrán tener el mismo IDPER. ; ALTERTABLE SUCURSAL ADDCONSTRAINT SUCURSAL_PK PRIMARYKEY( IDSUC); ALTERTABLE SUCURSAL ADDCONSTRAINT SUCURSAL_PERSONAL_FK FOREIGNKEY( IDPER)REFERENCES PERSONAL ( IDPER )

Creación de una relación M:N Modelo lógico

En la Imagen 41 podemos ver el modelo lógico de una relación N:M. Para crearlo los pasos han sido: 1. Crear las dos entidades. 2. Pinchar en el botón remarcado en negro en la Imagen 41. 3. Pulsa sobre la entidad Autobus. 4. Arrastrar la línea 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 relación puede llevar atributos. Hasta ahora hemos omitido esta opción ya que no tenía mucho sentido. Sin embargo en este tipo de relación puede ser útil. Como ya hemos comentado en la teoría, esta relación crea una nueva relación que podrá contener sus nuevos atributos. Una opción para crear esos atributos es añadirlos a la relación. Luego cuando creemos el modelo relacional veremos que la nueva relación, llevará esos atributos. En nuestro caso, he añadido un atributo que indique la fecha en la que el conductor empezó a usar ese autobús.

Imagen 42

Modelo relacional

Imagen 43

Vemos en la Imagen 43 que como habíamos indicado, el modelo relacional ha creado una nueva relación, donde podemos observar un atributo que habíamos colocado en la relación. Además, por defecto nuestras dos entidades se relacionan con esta entidad con una relación 1:NIdentifying. Si hacemos doble click en la relación nueva y nos vamos a atributo, nos encontramos con la Imagen 44. Aquí podemos tomar varias decisiones. Pero la más importante es cambiar si las dos FK que vienen de nuestras dos entidades son además PK o no lo son. Para ello basta con desmarcar la opción PK. Además, si queremos que alguno de los nuevos atributos sea PK, basta con pinchar en el y marcar la opción PK.

Imagen 44

Del modelo relacional al modelo lógico

Como ya hemos indicado esta nueva relación podemos relacionarla con otras entidades que creemos en el futuro. La pregunta es como podemos hacer esto, si la nueva relación ha aparecido en el modelo relacional. Los pasos a seguir son: 1. Irse al modelo lógico. 2. Darle a control A (seleccionar todo) 3. Darle a suprimir y aceptar. (Elimina el modelo lógico). 4. Irse al modelo relacional. 5. Pulsar 6. Darle a Engineer. Obtenemos la Imagen 45

Imagen 45

Ahora la entidad AutoConductor es una entidad más con la que podemos trabajar. Las PK no se observan en el modelo lógico ya que vienen de la relación 1:NIdentifying que tienen con Autobus y Conductor.

Creación de una relación recursiva Modelo lógico

Para crear el modelo lógico basta con seguir los siguientes pasos: 1. Crear una entidad 2. Pinchar en el botón 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 dándole 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 relación 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 Atlético de Madrid. El Sevilla tiene como rival eterno al Betis. Pero como ya nos ha ocurrido en otras ocasiones. Cuando creo al real Madrid todavía no tengo rivales director que asignarle así que indistintamente la opción que elijamos el DDL no reflejará nada. Tan sólo creará una FK en el campo equipo que será opcional.

Herencia Modelo lógico

En la Imagen 47 podemos observar el modelo lógico 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 lógico las herencias están 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 ingeniería directa, y puede ser de 3 formas: 1. Estrategia de Tabla Única: la entidad padre y las entidades de los subtipos del modelo lógico 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 lógico 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 lógico 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 relación 1:1 Identificación.

Imagen 50

¿Cómo hemos creado los diferentes modelos relacionales?

Tenemos dos formas de hacerlo. Cuando pulsamos nos sale la Imagen 51. En el recuadro marrón podemos ver que la entidad padre está marcada y en el recuadro rojo podemos ver que las dos entidades que heredan del padre también están 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 lógico. Irse a la opción Enginer To y marcar o desmarcar que participe en la realización del modelo relacional. Si la marcamos participa y si lo desmarcamos no participa. Vemos que podríamos incluso desmarcar algún subtipo y marcar otros. Esto crearía 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 sería desmarcar la entidad padre y algunos subtipos. Se crearía una tabla única por cada subtipo no desmarcado que tendría 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 podría implementarse en el DDL. Lo eliminaremos y veremos más adelante como crear restricciones que nos ayuden a evitar estos problemas. Este sería 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

CONSEJOS Y BUENAS PRÁCTICAS Cada estrategia de ingeniería directa de la herencia tiene sus ventajas y sus inconvenientes. La estrategia de tabla única tiene sentido cuando el supertipo contiene la mayoría de los campos, y los atributos concretos de los subtipos van a ser pocos. Esta estrategia permite que existan instancias que no pertenezcan a ningún subtipo, para lo cual basta con dejar vacíos los campos correspondientes a los subtipos. Del mismo modo, una instancia también podría pertenecer a más de un subtipo, rellenando los campos correspondientes. Para evitar esto último, se puede introducir una instrucción SQL en el archivo DDL consistente en una restricción que impida que se rellenen los campos de más de un subtipo (veremos como se hace más 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 número de atributos del supertipo es reducido. Esta estrategia hace imposible la existencia de instancias que no pertenezcan a ningún subtipo, puesto que los datos de una instancia deberán 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 más tablas genera, pero cuando hemos descartado la estrategia de una tabla única, la estrategia de una tabla por entidad es más 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 relación 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 también permite que existan instancias que no pertenezcan a ningún subtipo, cuando sólo se rellenan los campos de la entidad del supertipo, y se dejan vacíos los de los subtipos. Por otra parte, otro condicionante a la hora de elegir la estrategia de ingeniería directa es la obligatoriedad de las relaciones que llegan a los subtipos. Si necesito crear relaciones que tengan como destino algún 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 relación con uno de los subtipos, en realidad se convertiría la relación en obligatoria para todas las instancias de la tabla, de tal manera que todas las instancias pertenecerían al subtipo que tiene la relación 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 través de un ejemplo. En la Imagen 52 vemos un modelo lógico 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. Además, 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á también en el tercero. Lo normal, es crearlo en el modelo relacional que nos permite si queremos no exportarlo al resto de niveles. Creación en el modelo relacional:

Pinchamos sobre la tabla de la Imagen 53. Se nos abrirá la Imagen 54.

Imagen 54

Si pinchamos sobre se añade una restricción en la zona roja. En este caso hemos creado 4. El name es el nombre que va a tener dicha restricción. A la hora de introducir datos, si no cumplen la restricción 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 hubiéramos creado dicha restricción 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 vacíos o que el campo TP debe valer P y en ese caso CS1 y CS2 deben estar vacíos. ¿Podríamos 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 imposibilitaría la introducción de datos en SQL. El motivo es evidente. Cada restricción se chequea por separado. Por tanto, si en el campo TP pusiéramos S, nos diría que estamos incumpliendo la opción P y viceversa. Por eso es importante decir que ocurra una u otra. Esa opción 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. Bastaría con dar una orden de este estilo. Nombre: CampoObligatorio CP1 IS NOT NULL OR CS2 IS NOT NULL

También podríamos escribirla más completa: (TP = 'P' AND CP1 IS NOT NULL) OR (TP = 'S' AND CS2 IS NOT NULL)

Esta restricción nos dice que tenemos dos opciones. O que el atributo CP1 tenga contenido por fuerza o que tenga lo tenga CS2. Podríamos entonces rellenar en un portátil el campo CS2. Si solo existiera esta restricción si, pero al existir también la restricción 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 condición.

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 portátil o a un sobremesa. IO LIKE 'P%' OR IO LIKE 'S%'

O si queremos darle más contundencia: (IO LIKE 'P%' AND TP = 'P') OR (IO LIKE 'S%' AND TP = 'S')

Que además 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 habría problema ya que podríamos haber usado IO LIKE 'P%' OR IO LIKE 'S%'. Pero y si no pudiéramos 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 ilógico 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 quedarían nuestras dos restricciones al quitar el campo TP. Yo podría poner un ordenador 01 (portátil) donde podría rellenar los campos CS1,CS2 solamente. Ya que no incumple Arco y tampoco Campoobligatorio. Es obvio que 01 no debe ser portátil 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, podríamos haber creado una única restricción que incluyera la obligatoriedad de campos y el arco. Esto no es aconsejable ya que si algo falla es más complicado encontrar el error. Aun así, un ejemplo sería: (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)

Además de estas restricciones podríamos crear cualquier otra que se nos ocurra. Que un atributo numérico 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 también es inteligente.

Creación en el DDL

Veamos la estructura que toma una restricción 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 reseñado en Amarillo ya la conocíamos. Indica la tabla sobre la que vamos a introducir la restricción o constraint. La orden en rojo indica el nombre de la constraint o restricción. A la hora de introducir los datos si violamos la condición nos dirá que violet o violamos campoObligatorio. Por último dentro del Check escribimos la condición en lenguaje SQL. Acabando en ;. Sino hubiéramos creado la restricción en el modelo relacional e introdujéramos esta línea en el ddl (obviamente después de la orden que hubiera creado la tabla ordenador). Al ejecutarse el DDL se crearía la restricción. Creación 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 restricción 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 restricción 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 intención 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 condición a la Primary Key de la entidad padre ya que será el único campo presente en las dos entidades hijos.

Creación de arco exclusivo

Lo primero que debemos entender es que un arco exclusivo no es más que una restricción. Por tanto, podríamos crearlo por nosotros mismos. Lo que vamos a ver es que la herramienta en este caso nos permite hacerlo de forma no automática. Pasos a seguir: 1. Creación de las tres entidades (Viaje, Barco, Avión) 2. Creación 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 opción 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 más interesante lo vamos a ver en el DDL.

Imagen 59

Restricción 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 restricción 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 compañía tendría un problema ya que debe tener relleno uno de los dos campos. Lo primero, es que en este caso el modelo lógico estaría mal ya que las relaciones 1:N deberían haber sido opcionales en los dos extremos. Esto habría 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 restricción 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 opción nueva, que es dejar ambos campos a cero.

Instrucciones SQL En el modelo 1:N ya vimos que ordenes ejecuta SQL para crear tablas (créate), para borrarlas (drop) , como alterar el contenido de la tabla (alter), añadir 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 través 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 añadir restricciones a una tabla para que no podamos añadir 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, también surge la necesidad de poder almacenar en un archivo los datos de dichas bases de datos. Para esto sirve la instrucción INSERT, que es una instrucción 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 serán FK en otras tablas) y después se colocarán 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 están 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 opción 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 tendrán permiso para añadir 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, también 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 más 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 fútbol, y que tenemos la entidad JUGADOR con los datos de todos los jugadores. Entre ambas entidades existe una relación 1:N con obligatoriedad en el lado del JUGADOR, de tal forma que un equipo puede tener uno o más jugadores, y un jugador debe pertenecer a un equipo. Si queremos registrar también qué jugador es el capitán de cada equipo, podemos hacerlo estableciendo una nueva relación entre ambas entidades del tipo 1:1 con la opcionalidad activada y como rol dominante el JUGADOR, ya que un equipo puede tener un capitán, y un jugador puede ser capitán de un equipo. Nos encontraríamos 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 podríamos empezar introduciendo jugadores, puesto que necesitan pertenecer a un equipo obligatoriamente, y los equipos todavía no están creados. Si por el contrario introducimos primero los equipos no podríamos establecer el capitán, puesto que todavía 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 instrucción 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 estén 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 instrucción 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 condición 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 capitán 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 lógico sería, dato de los equipos y luego datos de los jugadores. El insert del equipo betis sería: 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 instrucción viene en el ‘10’ que hemos remarcado. Ese 10 hace referencia al dni de un jugador que todavía no se ha introducido. La solución es dejar ese campo null y posteriormente cuando se haya creado el jugador con DNI 10 actualizarlo con la instrucción 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 solución la tiene que hacer el usuario a mano, por eso el programa nunca va a crearla a priori. La solución como vemos, es identificar los campos que van a incumplir una restricción, borrarlos antes de exportar los datos y posteriormente añadir al final del DDl una instrucción 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 tendrán unos permisos restringidos. Oracle tiene un usuario administrador por defecto que se llama SYS. Para poder trabajar con dicho usuario debemos crear una conexión con el. Veamos como creamos una conexión. Vamos a hacer un zoom a la zona 1 de laImagen 7. Podemos ver dicho zoom en laImagen 63.

Imagen 63

Para crear una conexión pinchamos en la cruz verde o le damos al botón 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 conexión. En este caso le pondremos Admin para indicar que será la conexión que usa el administrador. Username: Es el nombre del usuario que realizará la conexión con la base de datos. En nuestro caso será SYS. Veremos que sys puede crear nuevo usuarios para el futuro. Password: Es la contraseña 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 básico. Role: Aunque existen varios roles nosotros sólo vamos a usar SYSDBA y Default. El usuario SYS será SYSDBA y el resto de usuarios que creemos serán Default. Hostname: Localhost significa que vamos a trabajar en nuestro propia máquina. Si queremos conectarnos a la base de datos de un compañero o cualquier otra debemos saber la dirección 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 conexión para el futuro. Clear: Limpia los parámetros que hayamos escrito. Test: Comprueba que los datos son correctos y la conexión se realizará con éxito. Conect: Realiza la conexión.

Cuando le damos a connect se nos crea la conexión 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 botón derecho podemos crear un nuevo usuario con la opción 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 contraseña que tendrá dicho usuario. ConfirmPassword: Sirve para confirmar que no nos hemos equivocado al poner nuestra contraseña. PasswordExpired (usermustchangenextlogin): Si lo marcamos, el usuario se conectará y acto seguido le pedirá que cambie su contraseña por una que será definitiva. Esta opción es la más habitual ya que el administrador de la base de datos creará diferentes usuarios y le dará a cada usuario los datos genéricos. El usuario al entrar pondrá su propia clave que a partir de ese momento sólo 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 pestaña granted roles.Imagen 67.

Imagen 67

En nuestro caso sólo 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 pestaña 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.

CONSEJOS Y BUENAS PRÁCTICAS Una vez creado el usuario es interesante crear una conexión 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 contraseña, igual que para SYS, es la que introdujimos en la instalación. Si nos conectamos con dicho usuario podemos cambiar la contraseña de SYS.

Proyecto Enunciado: Una academia está interesada en controlar las clases que da, cuantos alumnos asisten, quien las da. Además le interesa las comunicación 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 además no interesa saber el turno, el día, donde se dan. Sería interesante introducir datos generales de las localizaciones por si más tarde queremos introducir las tutorías que se suelen hacer en despachos.

Modelo Lógico Este podría ser el enunciado de un proyecto o de un examen. Lo primero sería plantearse que entidades debemos tener en cuenta y luego que relaciones existirán entre ellas. En la Imagen 68 vemos el modelo lógico con sus diferentes relaciones numeradas vamos a ir indicando que significa cada una. Relación 1 y 2: Ha sido creada a partir de una relación 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 relación 1 y 2 son 1:N Identifying. Esto va a crear parejas de Profesor, Asignatura. Relación 3 (Relación recursiva): Un trabajador puede ser tutor de uno o varios trabajadores. Un trabajador puede tener un tutor que le vigile. Relación 4 (1:N): Una clase debe ser de las parejas creadas Profesor Asignatura. Una Pareja de profesor y Asignatura puede aparecer en una o más asignaturas. Relación 5 (1:N): Una clase debe darse en un aula. Un aula puede acoger una o más clases. Relación 6 (1:N): Una clase debe tener un turno.

En un turno puede tener una o varias clases.

Relación 7 (N:M): Un alumno puede ir a una o más clases. En una clase hay uno o varios alumnos. No hemos puedo la relación que se crea porque no vamos a relacionarla con nadie. Se verá luego en el modelo relacional. Relación 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. Relación 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 versión simplificada para poner de manifiesto la doble relación 1:N entre dos entidades. También debemos ser conscientes que un trabajador o un alumno podrían tener varias cuentas pero solo nos vamos a centrar en la que usamos en la academia. Relación 13 (1:N Identifying) Un alumno tiene una o varias actividades extraescolares. Una actividad extraescolar es realizada por un alumno.

Imagen 68 Modelo Lógico

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 , Curso VARCHAR2 (20) 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 restricción 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 , Nombre VARCHAR2 (50) 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 , Nombre VARCHAR2 (30) NOT NULL , Metros NUMBER (3) NOT NULL , NumEscritorio NUMBER (1) , NumCuadros NUMBER (1) , NumSobremesa NUMBER (1) , Impresora CHAR (1) ,

NumSillas NumMesas NumOrdenadores Pizarra

NUMBER (3) , NUMBER (2) , NUMBER (2) , CHAR (1)

) LOGGING ;

Las siguientes restricciones han sido creadas por mi en la tabla Localización 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 ( IdTrabajador VARCHAR2 (9) NOT NULL , Curso VARCHAR2 (20) NOT NULL , Sigla VARCHAR2 (5) NOT NULL ) LOGGING ; ALTER TABLE ProfeAsignatura ADD CONSTRAINT ProfeAsignatura_PK PRIMARY KEY ( IdTrabajador, Curso, Sigla ) ; CREATE TABLE TRABAJADOR ( IdTrabajador VARCHAR2 (9) NOT NULL , Nombre VARCHAR2 (30) NOT NULL , 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 , Nombre 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-MONRR'),'Javier','M'); Insert into PROYECTO.ALUMNO (IDALU,NOMBRE,FECNACIMIENTO,TUTOR,SEXO) values ('A02','Adela Rodríguez',to_date('04-JUL-00','DD-MONRR'),'Estefanía','F'); Insert into PROYECTO.ALUMNO (IDALU,NOMBRE,FECNACIMIENTO,TUTOR,SEXO) values ('A03','Alejandro Hinojosa',null,'Irene','M'); Insert into PROYECTO.ALUMNO (IDALU,NOMBRE,FECNACIMIENTO,TUTOR,SEXO) values ('A04','Carmen García',null,'Blanca','F'); Insert into PROYECTO.ALUMNO (IDALU,NOMBRE,FECNACIMIENTO,TUTOR,SEXO) values ('A05','Judit Romero',to_date('06-MAY-08','DD-MONRR'),'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'); Insert into PROYECTO.EXTRAESCOLAR (IDALU,IDEXES,NOMBRE,HORAINICIO,HORAFIN,DIA) values ('A01','E02','Piano','18:00','19:00','L y J'); Insert into PROYECTO.EXTRAESCOLAR (IDALU,IDEXES,NOMBRE,HORAINICIO,HORAFIN,DIA) values ('A02','E01','Fúbtol','16:00','18:00','L , X y V'); REM INSERTING into PROYECTO.ASIGNATURA SET DEFINE OFF; Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('MAT','3E','Matematica 3 Eso'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('MAT','1B','Matematica 1 Bachillerato'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('SOC','3E','Sociales 3 Eso'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('BIO','1B','Biología 1 Bachillerato'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('QUI','2B','Química 2 bachillerato'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('LEN','5P','Lengua 5 Primaria'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('FIL','2B','Filosofía 2 Bachillerato'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('DIB','1B','Dibujo 1 Bachillerato'); Insert into PROYECTO.ASIGNATURA (SIGLA,CURSO,NOMBRE) ('ING','4E','Ingles 4 Eso');

values values values values values values values values values

REM INSERTING into PROYECTO.TRABAJADOR SET DEFINE OFF; Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T01','Javier','García

Gómez','3145782','31727990L',480,to_date('09-JAN-12','DD-MONRR'),null); Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T02','Estefanía','Rodríguez Salas',null,'74328745L',480,to_date('04-FEB-13','DD-MON-RR'),null); Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T03','Irene','Romero Vargas','3142342','21846237J',500,null,null); Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T04','Blanca','López Sosa',null,'72364934R',450,to_date('18-NOV-15','DD-MON-RR'),'T01'); Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T05','Manolio','Curado del Olmo',null,'44261454G',600,to_date('12-NOV-13','DD-MON-RR'),null); Insert into PROYECTO.TRABAJADOR (IDTRABAJADOR,NOMBRE,APELLIDO,NUMSEGSOCIAL,DNI,SALARIO,FECCONTRATACION ,IDTUTOR) values ('T06','Manuel','Sánchez Ortiz',null,'28562519F',3300,null,'T05'); REM INSERTING into PROYECTO.PROFEASIGNATURA SET DEFINE OFF; Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) ('T01','1B','MAT'); Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) ('T01','3E','MAT'); Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) ('T02','2B','QUI'); Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) ('T03','4E','ING'); Insert into PROYECTO.PROFEASIGNATURA (IDTRABAJADOR,CURSO,SIGLA) ('T04','1B','DIB');

values values values values values

REM INSERTING into PROYECTO.EMAIL SET DEFINE OFF; Insert into PROYECTO.EMAIL (IDEMAIL,DIRECCION,IDTRABAJADOR,IDALU) values ('E01','[email protected]','T01',null); Insert into PROYECTO.EMAIL (IDEMAIL,DIRECCION,IDTRABAJADOR,IDALU) values ('E02','[email protected]','T02',null); Insert into PROYECTO.EMAIL (IDEMAIL,DIRECCION,IDTRABAJADOR,IDALU) values ('E03','[email protected]',null,'A02'); Insert into PROYECTO.EMAIL (IDEMAIL,DIRECCION,IDTRABAJADOR,IDALU) values ('E04','[email protected]',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'); Insert into PROYECTO.TURNO (IDTURNO,NOMBRE,HORAINICIO,HORAFIN) values ('T2','Turno 2','17:30','19:00'); Insert into PROYECTO.TURNO (IDTURNO,NOMBRE,HORAINICIO,HORAFIN) values ('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); Insert into PROYECTO.LOCALIZACION (IDLOCALIZACION,NOMBRE,METROS,NUMSILLAS,NUMMESAS,NUMORDENADORES,PIZARR A,NUMESCRITORIO,NUMCUADROS,NUMSOBREMESA,IMPRESORA) values ('A002','Londres',60,40,20,10,'S',null,null,null,null); Insert into PROYECTO.LOCALIZACION (IDLOCALIZACION,NOMBRE,METROS,NUMSILLAS,NUMMESAS,NUMORDENADORES,PIZARR A,NUMESCRITORIO,NUMCUADROS,NUMSOBREMESA,IMPRESORA) values ('A003','New York',40,20,10,2,'S',null,null,null,null); Insert into PROYECTO.LOCALIZACION (IDLOCALIZACION,NOMBRE,METROS,NUMSILLAS,NUMMESAS,NUMORDENADORES,PIZARR A,NUMESCRITORIO,NUMCUADROS,NUMSOBREMESA,IMPRESORA) values ('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-MONRR'),'E02','E01','Puedes cubrirme la clase de Química.'); 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'); Insert into PROYECTO.CLASE (IDCLASE,FECHA,IDTRABAJADOR,CURSO,SIGLA,IDTURNO,IDLOCALIZACION) values ('C02','16-NOV-15','T02','2B','QUI','T2','A002'); Insert into PROYECTO.CLASE (IDCLASE,FECHA,IDTRABAJADOR,CURSO,SIGLA,IDTURNO,IDLOCALIZACION) values ('C03','16-NOV-15','T03','4E','ING','T3','A003'); REM INSERTING into PROYECTO.ALUMNOCLASE SET DEFINE OFF; Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU) Insert into PROYECTO.ALUMNOCLASE (IDCLASE,IDALU)

values values values values values values values values

('C01','A01'); ('C01','A03'); ('C01','A04'); ('C02','A01'); ('C02','A05'); ('C03','A02'); ('C03','A03'); ('C03','A04');