Proyecto de Base de Datos (Parte I)

16

description

Parte I del Proyecto final de Base de Datos realizado para la asignatura de Base de Datos de la Universidad Miguel Hernández de Elche

Transcript of Proyecto de Base de Datos (Parte I)

Page 1: Proyecto de Base de Datos (Parte I)
Page 2: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Í N D I C E

PARTE I

I.I.-Modelo Entidad/Relación......................................................................................................Página 1

Paso1.- Elaboración de la lista de candidatos a Entidades y Relaciones............................Página 1

Paso2.- Construcción de la Matriz de Entidades................................................................Página 2

Paso 3.- Versión preliminar del esquema...........................................................................Página 4

Paso 4.- Cardinalidades máximas y mínimas.....................................................................Página 4

Paso 5.- Comprobación de redundancia y determinación de ciclos posibles.....................Página 6

I.II.-Modelo Relacional................................................................................................................Página 7

I.III.-Creación de la Base de Datos...........................................................................................Página 12

Page 3: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

PROYECTO FINAL DE DISEÑO DE BASE DE DATOS

PARTE I

En esta primera parte del proyecto, realizaremos el diseño de una base de datos respondiendo alas característica del problema que se nos plantea, realizando los esquemas tantoEntidad/Relación (esquema conceptual) como el Relacional (esquema lógico).Una vez hechos estos esquemas, procederemos a la construcción del diseño obtenido,utilizaremos para ello el lenguaje de definición de datos de SQL2 ANSI. Para comprobar que lacreación está bien realizada, utilizaremos Oracle 9i para asegurarnos de ello, pero esto último yapertenece a la Parte II del proyecto, de modo que habrá que esperar un poquito más para poderrealizar las consultas deseadas.

I.I.-Modelo E/R

Empezaremos creando el esquema conceptual, es decir, el modelo entidad/relación, e iremosmostrando en cada paso de este proceso de creación que es lo que hemos supuesto a partir delenunciado y cuales han sido nuestras decisiones de diseño a partir de lo que nos decía este.

Paso1.- Elaboración de la lista de candidatos a Entidades y Relaciones.

Las entidades son los elementos de los que se quiere recoger información, y nos aparecen generalmente,como nombres. Las entidades de nuestro enunciado son:

● Dependencia: Nos dicen que debe tener un nombre, un código, una función, etc., atributos quepertenecerán a dicha entidad.

● Servicio: Identificado por un nombre y una clave, de modo que estos serán los atributos de dichaentidad, y como son identificativos, además, el conjunto de ambas será la clave principal.

● Tripulación: Se quiere llevar al día información de dicha entidad, esta información será: nombre,código, categoría, antigüedad,etc., atributos de dicha entidad.

● Cámara: Aquí tenemos un caso delicado, ya que cámara es una entidad porqué nos dicen que tienelos mismos atributos de una dependencia, por tratarse de una dependencia, pero posee dos atributosmás, que son: capacidad y categoría. Tenemos claro que Cámara es una entidad, el problema senos plantea al reflexionar sobre si se trata de una entidad débil o fuerte.

● Planeta: Se debe tener conocimiento de una serie de características de cada uno de los planetasvisitados: nombre, código, galaxia y coordenadas en las que se encuentra, de modo que estos seránlos atributos de la entidad Planeta.

1

Page 4: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

● Raza: Se almacenará una determinada información sobre una raza en concreto, tales como elnombre, las dimensiones medias, y la población total, es decir, la suma de la cantidad de individuosde esa raza que hay en todos los planetas.

Las relaciones nos indican que tipo de conexión existe entre las distintas entidades, generalmente nosaparecerán en el enunciado en forma de verbo:

● Bajo Control: Cada dependencia debe estar bajo el control de un servicio.

● Estar asignado: Todo servicio ha de estar asignado a una dependencia.

● Trabajar: Cada tripulante estará asignado a una dependencia. Supongo que el estar asignado hacereferencia a que un tripulante realiza sus funciones en una dependencia. Y como esta relación sedenomina igual que la relación anterior, a esta le denominaremos trabajar.

● Aloja: Cada tripulante se aloja en una cámara.

● Es: Una cámara es una dependencia.

● Visitado: Cada tripulante habrá visitado una serie de planetas.

● Estar Poblado: Algunos planetas podrían estar poblados por razas.

ENTIDADES RELACIONES

Dependencia Entre Dependencia y Servicio: BAJO CONTROLServicio Entre Servicio y Dependencia: ESTAR ASIGNADOTripulante Entre Tripulante y Dependencia: TRABAJARCámara Entre Tripulante y Cámara: ALOJA

Entre Cámara y Dependencia: ESPlaneta Entre Planeta y Tripulante: VISITADORaza Entre Planeta y Raza: ESTAR POBLADO

Paso2.- Construcción de la Matriz de Entidades.

– Supuestos del enunciado:

● Cada DEPENDENCIA debe estar BAJO CONTROL de un determinado SERVICIO, esdecir, que cada dependencia tiene un único servicio que lo controla: (?:1). Supongo que nopuede estar bajo el control de diferentes servicios.

● Todo SERVICIO ESTÁ ASIGNADO al menos a una DEPENDENCIA: (?:N), es decir,como mínimo a 1 dependencia, pero puede estar asignado a más de una.

2

Page 5: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

● Cada TRIPULANTE TRABAJARÁ en una DEPENDENCIA: (?:1). Supongo que no puedetrabajar más de una dependencia.

● Cada TRIPULANTE se ALOJA en una CÁMARA: (1:?). Supongo que no puede alojarse endiferentes cámaras, ya que la nave no dispone de tanta capacidad.

● Una CÁMARA ES una DEPENDENCIA: (1:1).● Cada miembro de la TRIPULACIÓN ha visitado PLANETAS: (?:?).● Algunos PLANETAS podrían ESTAR POBLADOS por ciertas RAZAS, es decir, que

pueden o no estar poblados: (?:?).

– Supuestos fuera del enunciado:

● Un SERVICIO puede tener BAJO CONTROL a muchas DEPENDENCIAS: (N:1). Supongoque puede haber un servicio Jefe que puede tener a todas las dependencias bajo su control.

● A una DEPENDENCIA le pueden ESTAR ASIGNADOS muchos SERVICIOS: (M:N). Encaso de existir unos servicios de limpieza y seguridad, estos desarrollarían sus funciones entodas las dependencias, por lo tanto, estos dos servicios estarían asignados a todas lasdependencias.

● En una DEPENDENCIA pueden TRABAJAR muchos TRIPULANTES: (1:N).Puedetratarse de un laboratorio, o del almacén, donde trabajan varios tripulantes.

● Una CÁMARA tiene una determinada capacidad, de modo que asumiremos que una cámarapuede ALOJAR a más de 1 TRIPULANTE, si la capacidad lo permite: (1:N).

● Un PLANETA puede ser VISITADO por más de un TRIPULANTE, y un TRIPULANTEpuede visitar muchos PLANETA: (M:N).

● Sólo nos interesan las razas que habitan en alguno de los planetas visitados, de modo quetoda RAZA POBLARÁ como mínimo en 1 PLANETA (N:?), y un PLANETA puedeESTAR POBLADO por una o muchas razas: (N:M).

En la siguiente tabla podemos ver toda la información de forma resumida:

Dependencia Servicio Tripulante Cámara Planeta Raza

Dependencia Bajo Control(N:1) Alojar(1:N)

ServicioEstar

Asignado(M:N)

Tripulante Trabajar(N:1)

Cámara Es (1:1)

Planeta Visitado(M:N)

EstarPoblado(N:M)

Raza

3

Page 6: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Paso 3.- Versión preliminar del esquema.

Un tripulante puede haber visitado un planeta en más de una ocasión, por ello añadimos a la relaciónvisitado un atributo denominado número de visita.

Población total es un atributo derivado, porqué puede obtenerse a partir del atributo de la relacióncantidad de individuos, puesto que población total es la suma de todos los individuos de esa raza quehay en el universo, bueno, que se conocen que hay, ya que los tripulantes sólo tienen conocimiento deaquellos planetas que han visitado.

Raza no es entidad débil, puesto que de ser así, cada planeta tendría unas determinadas dimensionesmedias de la raza que allí habita, es decir, que una determinada raza no tendría las mismas dimensionesen todos los planetas, y esto no es demasiado lógico.

La única diferencia que existe entre que cámara sea una entidad fuerte y que sea una débil dedependencia, es que en este último caso cámara no tiene clave parcial.Haciendo cámara entidad débil conseguimos un diseño más sencillo, sin menos relaciones, ya quecámara debería tener las mismas relaciones que dependencia con servicio, por ser una dependencia.

Paso 4.- Cardinalidades máximas y mínimas.

Bajo Control:

● Una dependencia tiene que estar BAJO CONTROL al menos de un servicio: SI● Una dependencia puede estar BAJO CONTROL de muchos servicios: NO (1:1)

4

Page 7: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

● Un servicio tiene BAJO CONTROL al menos a una dependencia: NO● Un servicio puede tener BAJO CONTROL a muchas dependencias: SI (0:n)

Estar Asignado:

● A una dependencia pueden ESTAR ASIGNADOS muchos servicios: SI● A una dependencia debe ESTAR ASIGNADO al menos un servicio: NO (0:n), ya que

pueden haber dependencias sin ningún servicio asignado.● Un servicio ESTÁ ASIGNADO al menos a una dependencia: SI● Un servicio puede ESTAR ASIGNADO a muchas dependencias: SI (1:n)

Trabajar:

● En una dependencia TRABAJA al menos 1 tripulante: NO● En una dependencia pueden TRABAJAR muchos tripulantes: SI (0:n), como hemos

comentado anteriormente, una dependencia, puede tratarse de un lugar de trabajo, de modoque es lógico que hayan varios tripulantes trabajando allí.

● Un tripulante TRABAJA al menos en una dependencia: SI● Un tripulante puede TRABAJAR en muchas dependencias: NO (1:1)

Aloja:

● Una dependencia (que es cámara) ALOJA al menos a 1 tripulante: NO● Una dependencia puede ALOJAR a muchos tripulantes: SI (0:n), siempre y cuando la

capacidad de la cámara lo permita.● Un tripulante se ALOJA al menos en una dependencia (que es cámara): SI● Un tripulante se puede ALOJAR en muchas dependencias: NO (1:1), no tiene sentido esto,

suponemos que como la nave tiene unas dimensiones limitadas, no puede haber ningúntripulante que disponga de más de una cámara para alojarse.

Es:

● Una cámara ES una dependencia: SI● Una cámara puede SER muchas dependencias: NO (1:1)● Una dependencia ES siempre una cámara: NO● Una dependencia puede SER varias cámaras: NO (0:1), sólo puede ser como máximo una

cámara, en el caso de que lo sea.

Visitado:

● Un tripulante ha VISITADO al menos un planeta: NO● Un tripulante puede haber VISITADO muchos planetas: SI (0:n)● Un planeta ha sido VISITADO al menos por un tripulante: SI, porqué nos interesan sólo los

planetas que ya han sido visitados por algún miembro de la tripulación, de modo que comomínimo, un visitante.

● Un planeta puede haber sido VISITADO por muchos tripulantes: SI (1:n)

5

Page 8: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Estar Poblado:

● Un planeta ESTÁ POBLADO al menos por una raza: NO● Un planeta puede ESTAR POBLADO por muchas razas: SI (0:n)● Una raza PUEBLA al menos un planeta: SI, puesto que sólo nos interesan las razas que vivan

en algún planeta.● Una raza puede POBLAR en muchos planetas: SI (1:n), por ello tenemos el atributo cantidad

de individuos y población total, el primero es atributo de la relación porque hace referencia ala cantidad de individuos de una raza en un determinado planeta. Mientras que el atributopoblación total hace referencia a la suma de todos los individuos de esa raza que hay portodos los planetas.

Segunda versión preliminar del esquema:

Paso 5.- Comprobación de redundancia y determinación de ciclos posibles.

El atributo de raza, población total, es un atributo derivado, ya que puede obtenerse su valor apartir de la cantidad de individuos de esa raza asociados a cada planeta, de modo que laaparición de este sería redundante, de modo que en la versión definitiva lo eliminamos.

A parte de eso, se puede comprobar en el esquema anterior que no existe redundancia en lainformación y que tampoco existen ciclos, por lo que el esquema que mostramos a continuacióncorresponde con la versión definitiva del esquema conceptual Entidad/Relación.

6

Page 9: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

I.II.-Modelo Relacional

Una vez establecido el esquema Entidad/Relación, llevaríamos a cabo su transformación almodelo relacional.

Los nulos supuestos en el modelo relacional los explicaremos a continuación, tabla por tabla:

Tabla dependencia:

● Código: Al ser la clave primaria, es decir, lo que identifica a dependencia, nunca va a poder ser unnulo.

● Nombre:No podrá ser nulo este campo, ya que los tripulantes se referirán normalmente a unadependencia llamándola por su nombre en lugar de por el código.

● Función:Una dependencia puede no tener una función determinada, o cuando se crea la dependencia,no conocer su uso futuro, por ello este campo puede valer nulo.

● Localización:Va a poder ser nula, ya que la nave tiene una dimensiones bastante limitadas, por ellono es necesario este dato.

● Nombre_servicio y Clave, no se permitirá un valor nulo en este campo porqué una dependenciasiempre tiene que estar bajo el control de un servicio, y si estos campos son nulos no se cumpliría lacondición que exige el enunciado.

7

Page 10: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Tabla Cámara:

● Código: Al ser la clave primaria, es decir, lo que identifica a cámara, nunca va a permitir nulos eneste campo.

● Categoría: No permite valores nulos, porqué cada tripulante, según su categoría estará en una cámarau otra, en función de la categoría que tenga esta.

● Capacidad: No permite valores nulos, ya que para el correcto funcionamiento de la nave, se debecontrolar perfectamente que cámaras están con el aforo completo y cuales no.

Tabla Servicio:

● Nombre y Clave: El conjunto de ambas forman la clave primaria de la tabla servicio, de modo queno pueden valer nulo, ya que es lo que identifica a un servicio.

Tabla Tripulación:

● Código: Al ser la clave primaria, es decir, lo que identifica a un tripulante, nunca va a permitir nulosen este campo.

● Categoría: Para saber en que dependencia, que es cámara, alojamos a un determinado tripulantecomprobaremos su categoría, de modo que este campo no va a permitir nulos.

● Nombre: Este campo no permitirá nulos. El hecho de usar un código para identificar a cadatripulante en lugar de su nombre radica en el hecho de que pueden existir dos o más tripulantes quetengan el mismo nombre, y como lo que identifica a un tripulante debe ser único, se utiliza el códigoen lugar del nombre. Puesto que puede ocurrir que una persona no conozca su código, ya que se tratetal vez de un código generado por la administración. Pero realmente toda la tripulación se llama porsu nombre en lugar de por su código.

● Antigüedad: Este campo no va a permitir nulos, porqué puede ocurrir que según los años que llevetrabajando un tripulante tenga un sueldo u otro, de modo que es necesaria esta información. Estecampo guardará la fecha de inicio en la que un determinado tripulante empezó a trabajar en la nave.Conociendo este campo y la fecha actual podremos obtener el valor de la antigüedad del tripulante.

● Procedencia: Este campo puede permitir nulos, ya que no es demasiado relevante el saber de dondees un tripulante. Sólo nos interesaría esta información para saber, por ejemplo, si algún tripulanteconoce bien un planeta, por si hay que hacer alguna expedición a dicho planeta, pero entonces yaconstará como planeta visitado.

● Situación Administrativa: Este campo no va a permitir nulos, puesto que es necesario conocer si untripulante esta de baja o no para en caso de expedición a algún planeta, saber si se puede contar o nocon él.

● Código_dependencia_trabajar y código_dependencia_alojar: En estos campos no se permitiránnulos, ya que nos dicen en el enunciado que todo tripulante debe trabajar y alojarse en unadependencia.

Tabla Estar Asignados:

● Código_dependencia, Nombre_Servicio y Clave, al ser claves primarias no puede permitirse quesean nulas.

8

Page 11: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Tabla Planeta:

● Código: Al ser la clave primaria, es decir, lo que identifica a planeta, nunca va a permitir nulos eneste campo.

● Nombre,Galaxia y Coordenadas: Cuando un tripulante ha visitado un planeta se supone que hace uninforme sobre dicho planeta, de modo que deberá introducir unos datos mínimos sobre dichoplaneta, luego estos campos no pueden ser nulos.

Tabla Raza:

● Nombre: Al ser la clave primaria, es decir, lo que identifica a una raza, nunca va a permitir nulos eneste campo.

● Peso, Altura y Anchura: Se pueden permitir nulos, puesto que puede ocurrir que el contacto con estaraza no haya sido lo suficientemente representativa como para hacer un balance global del peso, laaltura y la anchura media de esta determinada raza.

Tabla Visitado:

● Código_tripulante, código_planeta, número_de_visita, el conjunto de estos campos conforman laclave primaria de dicha tabla, por ello nunca se va a permitir un nulo en cualquiera de dichoscampos.

● Tiempo de visita: Puede ocurrir que en función del tiempo de una visita, un tripulante sufra unosefectos secundarios u otros, por ello, se les obliga a los tripulantes a indicar el tiempo de su visita, demodo que no permite nulos.

Tabla Estar Poblado:

● Código_planeta, nombre_raza, el conjunto de ambas forman la clave primaria de la tabla, por ellonunca se va a permitir un nulo en cualquiera de ambos campos.

● Cantidad de individuos: No va a permitir nulos este campo, ya que en el caso de querer realizar unainvasión, o un control de natalidad, etc. puede resultar muy útil el conocimiento de este campo.

A continuación, explicaremos las opciones de integridad que hemos especificado en el modelorelacional:

Si borro una dependencia, que es cámara, deberá borrarse también los correspondientes datos de latabla cámara. Si modifico los datos de una dependencia, que es cámara, deberá modificarse el código de cámara, en elcaso de que haya sido el código de dependencia el que se ha modificado.

Si borro una dependencia, que es cámara, los tripulantes que allí se alojaban pasarán por defecto a otradependencia, ya que todo tripulante debe alojarse en una cámara. Si modifico el código de una dependencia, que es cámara, deberá modificarse elcódigo_dependencia_alojar de la tabla de tripulantes.

9

Page 12: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

Si borro una dependencia, los tripulantes que trabajen en ella pasarán por defecto a otra dependencia, yaque según nuestro diseño, todo tripulante debe trabajar en una dependencia. Si modifico el código de una dependencia, se modificará el código_dependencia_trabajar de lostripulantes que trabajen en dicha dependencia.

Cada dependencia debe estar bajo el control de un determinado servicio, de modo que si borro unservicio, todas las dependencias que estén bajo el control de dicho servicio pasarán a estar bajo elcontrol de otro servicio, asignado por defecto.Si modifico el nombre o la clave de un servicio, se deberá modificar el nombre_servicio o la clave,según corresponda, en la dependencia que esté bajo el control de dicho servicio.

Todo servicio ha de estar asignado al menos a una dependencia, de modo que si borro una dependencia,deberán pasar todos los servicios que estaban asignados a esa dependencia, a estar asignados a otradependencia, para evitar que cualquier servicio se quede sin dependencia asignada.En el caso de modificar el código de dependencia, deberá modificarse en cascada todos los códigos dedependencia de la tabla estar asignado.

Al borrar un servicio (su nombre o su clave), deberá borrarse en cascada todos los registros de la tablaestar asignados correspondientes a dicho servicio, no habría ningún problema con dependencia, puestoque una dependencia no está obligada a tener un servicio asignado.Al modificar un servicio (su nombre o su clave), deberá modificarse en cascada todos los registros de latabla estar asignados que tengan a dicho servicio como asignado.

Si borro un tripulante, toda la información de las visitas realizadas por dicho tripulante se borraránporqué ya no me son de utilidad, es decir, en la tabla visitas se borrarían las entradas correspondientes adicho tripulante, sin embargo, el planeta quedaría estando en la base de datos a pesar de que no hubieraningún miembro de la tripulación que lo hubiese visitado. Esto nos permitiría saber que planetas fueronvisitados por miembros de antiguas tripulaciones, y conocer sus características por si se quiere realizaruna expedición.Si modifico el código de un tripulante, se modificará el código_tripulante en la tabla de las visitasrealizadas por dicho tripulante.

Al intentar borrar un planeta, este no podrá ser borrado si hay alguna visita o población que lereferencie. Debería primero borrar todas las razas que allí viviesen, y las visitas realizadas a dichoplaneta, y una vez hecho esto, ya podría eliminar el planeta. Al modificar el código de un planeta, se modificarán todos los códigos_planeta de las visitas y de lasrazas que allí pueblan.

Si borro una raza, se borrará en cascada todos los registros de la tabla estar poblados referentes a dicharaza. En el caso de querer realizar una consulta sobre planetas poblados, en el momento en el que vea lacantidad de planetas que tengo y los que están poblados, sabré cuales no están poblados, ya que noaparecerá ningún registro sobre ellos en la tabla estar poblados.Si modifico el nombre de una raza, se modificarán en cascada todos los registros de la tabla estarpoblados referentes a dicha raza.

10

Page 13: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

A continuación mostramos el modelo relacional realizado mediante la herramienta MicrosoftVisio:

Cada tabla correspondiente a una entidad está del mismo color que tenía la entidad en el modeloentidad/relación que hemos hecho anteriormente.

11

Page 14: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

I.III.-Creación de la Base de Datos

En primer lugar crearemos las tablas con sus diferentes campos, indicando el tipo de dato que sealmacenará en dicho campo, y si no puede ser nulo:

CREATE TABLE DEPENDENCIAS(Codigo_dep NUMBER(4,0) NOT NULL,Nombre_dep VARCHAR(15) NOT NULL,Funcion VARCHAR(15),Localizacion VARCHAR(15),Nombre_servicio VARCHAR(15) NOT NULL DEFAULT Comando_Y_Control,Clave NUMBER(4,0) NOT NULL DEFAULT 0001

);

CREATE TABLE CAMARA(Codigo_cam NUMBER(4,0) NOT NULL,Categoría_cam VARCHAR(15) NOT NULL,Capacidad NUMBER(2,0) NOT NULL

);

CREATE TABLE SERVICIO(Nombre_servicio VARCHAR(15) NOT NULL,Clave NUMBER(4,0) NOT NULL

);

CREATE TABLE TRIPULACION(Codigo_trip VARCHAR(15) NOT NULL,Categoría_trip VARCHAR(15) NOT NULL,Nombre_trip VARCHAR(10) NOT NULL,Antigüedad DATE NOT NULL,Situación_administrativa VARCHAR(15) NOT NULL,Procedencia VARCHAR(15),Codigo_dependencia_trabajar NUMBER(4,0) NOT NULL DEFAULT 0002,Codigo_dependencia_alojar NUMBER(4,0) NOT NULL DEFAULT 0003,

);

CREATE TABLE ESTAR_ASIGNADO(Codigo_dep NUMBER(4,0) NOT NULL DEFAULT 0004,Nombre_servicio VARCHAR(15) NOT NULL,Clave NUMBER(4,0) NOT NULL

);

CREATE TABLE PLANETA(Codigo_planeta NUMBER(4,0) NOT NULL,Nombre_planeta VARCHAR(15) NOT NULL,Galaxia VARCHAR(15) NOT NULL,Coordenadas VARCHAR(15) NOT NULL,

);

CREATE TABLE RAZA(Nombre_raza VARCHAR(15) NOT NULL,Peso NUMBER(3,2),Altura NUMBER(3,2),Anchura NUMBER(3,2),

);

12

Page 15: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

CREATE TABLE VISITADO(Codigo_trip NUMBER(4,0) NOT NULL,Codigo_planeta NUMBER(4,0) NOT NULL,Numero_de_visita NUMBER(2,0) NOT NULL,Tiempo_de_visita NUMBER(3,1) NOT NULL

);

CREATE TABLE ESTAR_POBLADO(Codigo_planeta NUMBER(4,0) NOT NULL,Nombre_raza VARCHAR(15) NOT NULL,Cantidad_de_individuos NUMBER(20,0) NOT NULL

);

A continuación incluiremos el script de restricciones de cada tabla, indicando que campos sonclaves primarias y cuales claves foráneas, además de indicar que debe ocurrir en caso de borradoo modificación:

ALTER TABLE DEPENDENCIASADD CONSTRAINT CLAPPAL_DEPPRIMARY KEY (Codigo_dep);

ALTER TABLE DEPENDENCIASADD CONSTRAINT CLAFOR_DEPNOMSERVICIOFOREIGN KEY (Nombre_servicio) REFERENCES Servicio(Nombre_servicio)ON DELETE SET DEFAULT ON UPDATE CASCADE;

ALTER TABLE DEPENDENCIASADD CONSTRAINT CLAFOR_DEPCLAVEFOREIGN KEY (Clave) REFERENCES Servicio(Clave)ON DELETE SET DEFAULT ON UPDATE CASCADE;

ALTER TABLE CAMARAADD CONSTRAINT CLAPPAL_CAMPRIMARY KEY(Codigo_cam);

ALTER TABLE CAMARAADD CONSTRAINT CLAFOR_CAMFOREIGN KEY(Codigo_cam) REFERENCES Dependencias(Codigo_dep)ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE SERVICIOADD CONSTRAINT CLAPPAL_SERVICIOPRIMARY KEY (Nombre_servicio, Clave);

ALTER TABLE TRIPULACIONADD CONSTRAINT CLAPPAL_TRIPPRIMARY KEY(Codigo_trip);

ALTER TABLE TRIPULACIONADD CONSTRAINT CLAFOR_TRABAJARFOREIGN KEY (Codigo_dependencia_trabajar) REFERENCES Dependencias(Codigo_dep)ON DELETE SET DEFAULT ON UPDATE CASCADE;

ALTER TABLE TRIPULACIONADD CONSTRAINT CLAFOR_ALOJARFOREIGN KEY (Codigo_dependencia_alojar) REFERENCES Dependencias (Codigo_dep)

13

Page 16: Proyecto de Base de Datos (Parte I)

Diseño de Base de Datos Proyecto Final

ON DELETE SET DEFAULT ON UPDATE CASCADE;

ALTER TABLE ESTAR_ASIGNADOADD CONSTRAINT CLAPPAL_ASIGNARPRIMARY KEY (Codigo_dep, Nombre_servicio, Clave);

ALTER TABLE ESTAR_ASIGNADOADD CONSTRAINT CLAFOR_DEPFOREIGN KEY (Codigo_dep) REFERENCES Dependencias(Codigo_dep)ON DELETE SET DEFAULT ON UPDATE CASCADE;

ALTER TABLE ESTAR_ASIGNADOADD CONSTRAINT CLAFOR_NOMSERVICIOFOREIGN KEY (Nombre_servicio) REFERENCES Servicio(Nombre_servicio)ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE ESTAR_ASIGNADOADD CONSTRAINT CLAFOR_CLAVEFOREIGN KEY (Clave) REFERENCES Servicio(Clave)ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE PLANETAADD CONSTRAINT CLAPPAL_PLANETAPRIMARY KEY (Codigo_planeta);

ALTER TABLE RAZAADD CONSTRAINT CLAPPAL_RAZAPRIMARY KEY (Nombre_raza);

ALTER TABLE VISITADOADD CONSTRAINT CLAPPAL_VISITADOPRIMARY KEY(Codigo_trip, Codigo_planeta, Numero_de_visita);

ALTER TABLE VISITADOADD CONSTRAINT CLAFOR_CODTRIPFOREIGN KEY(Codigo_trip) REFERENCES Tripulacion(Codigo_trip)ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE VISITADOADD CONSTRAINT CLAFOR_CODPLANETAFOREIGN KEY(Codigo_planeta) REFERENCES Planeta(Codigo_planeta)ON DELETE RESTRICT ON UPDATE CASCADE;

ALTER TABLE ESTAR_POBLADOADD CONSTRAINT CLAPPAL_POBLADOPRIMARY KEY(Codigo_planeta, Nombre_raza);

ALTER TABLE ESTAR_POBLADOADD CONSTRAINT CLAFOR_POBLADOPLANETAFOREIGN KEY (Codigo_planeta) REFERENCES Planeta(Codigo_planeta)ON DELETE RESTRICT ON UPDATE CASCADE;

ALTER TABLE ESTAR_POBLADOADD CONSTRAINT CLAFOR_POBLADORAZAFOREIGN KEY (Nombre_raza) REFERENCES Raza (Nombre_raza)ON DELETE CASCADE ON UPDATE CASCADE;

14