lunes, 4 de noviembre de 2013

Proyecto Semestral Parte 1

Regla de negocio:

Una Empresa de Radio Taxis “Escorpio” desea que Ud. diseñe una Base de datos que permita manejar la información relacionada con la gestión de su negocio.  La empresa cuenta con una flota de taxis, los cuales son identificados por un patente, marca, modelo, año y si posee su revisión técnica al día o no.
Un chófer conduce un vehículo (Taxi). Los chóferes de la empresa son identificados con un número único y además nos interesa registrar su Rut, Nombre, apellido y edad, esto con el fin de tener la identidad completa del chófer, por otra parte tenemos diferentes clientes que prefieren nuestra empresa, para tomar nuestros servicios necesitamos los siguientes datos de un cliente: nombre, rut, apellido, edad y que tipo de convenio posee con nuestra empresa (ejm: Frecuente, Carrera), y también saber en que fecha requerirán un móvil, el lugar de origen y destino al que se dirigirá


Para mas información Diccionario de Datos mas Scrip
https://www.dropbox.com/sh/sab779qgainwq34/i9kD3-V0k-?n=147404406

Modelo Logico


Modelo Relacional



Reglas de Negocio:


Script DLL:


Script:

-- ELIMINA TABLAS (ESTO ESTA HECHO A MANO)

DROP TABLE Chofer CASCADE CONSTRAINT;
DROP TABLE Cliente CASCADE CONSTRAINT;
DROP TABLE TipoConvenio CASCADE CONSTRAINT;
DROP TABLE SolicituVehiculo CASCADE CONSTRAINT;
DROP TABLE vehiculo CASCADE CONSTRAINT;

--CREA TABLAS

CREATE TABLE Chofer
    (
     IdChofer INTEGER  NOT NULL ,
     Nombre VARCHAR2 (30)  NOT NULL ,
     IdVehiculo INTEGER  NOT NULL ,
     Rut VARCHAR2 (20)  NOT NULL ,
     Apellido VARCHAR2 (20)  NOT NULL ,
     Edad INTEGER
    )
;


CREATE UNIQUE INDEX Chofer__IDX ON Chofer
    (
     IdVehiculo ASC
    )
;

-- Error - Index Chofer__IDXv1 has no columns

ALTER TABLE Chofer
    ADD CONSTRAINT "Chofer PK" PRIMARY KEY ( IdChofer ) ;



CREATE TABLE Cliente
    (
     IdCliente INTEGER  NOT NULL ,
     Rut VARCHAR2 (10)  NOT NULL ,
     Nombre VARCHAR2 (20)  NOT NULL ,
     Apellido VARCHAR2 (20)  NOT NULL ,
     IdTipoConvenio INTEGER ,
     Edad INTEGER
    )
;



-- Error - Index Cliente__IDX has no columns

ALTER TABLE Cliente
    ADD CONSTRAINT "Cliente PK" PRIMARY KEY ( IdCliente ) ;



CREATE TABLE SolicituVehiculo
    (
     IdSolicitud INTEGER  NOT NULL ,
     FechaSolicitud DATE  NOT NULL ,
     Origen VARCHAR2 (30)  NOT NULL ,
     Destino VARCHAR2 (30)  NOT NULL ,
     Precio NUMBER ,
     IdChofer INTEGER  NOT NULL ,
     IdCliente INTEGER  NOT NULL
    )
;



-- Error - Index SolicituVehiculo__IDX has no columns

-- Error - Index SolicituVehiculo__IDXv1 has no columns
CREATE UNIQUE INDEX SolicituVehiculo__IDXv2 ON SolicituVehiculo
    (
     IdChofer ASC
    )
;
CREATE UNIQUE INDEX SolicituVehiculo__IDXv3 ON SolicituVehiculo
    (
     IdCliente ASC
    )
;

ALTER TABLE SolicituVehiculo
    ADD CONSTRAINT "SolicituVehiculo PK" PRIMARY KEY ( IdSolicitud ) ;



CREATE TABLE TipoConvenio
    (
     IdTipoConvenio INTEGER  NOT NULL ,
     NombreConvenio VARCHAR2 (20)  NOT NULL ,
     FechaInicio DATE ,
     FechaFin DATE ,
     PrecioDescuento INTEGER
    )
;



ALTER TABLE TipoConvenio
    ADD CONSTRAINT "TipoConvenio PK" PRIMARY KEY ( IdTipoConvenio ) ;



CREATE TABLE vehiculo
    (
     IdVehiculo INTEGER  NOT NULL ,
     patente VARCHAR2 (20)  NOT NULL ,
     Año INTEGER  NOT NULL ,
     Modelo VARCHAR2 (20) ,
     EstadoRevision CHAR (1)  NOT NULL
    )
;



-- Error - Index vehiculo__IDX has no columns

ALTER TABLE vehiculo
    ADD CONSTRAINT "vehiculo PK" PRIMARY KEY ( IdVehiculo ) ;




ALTER TABLE Chofer
    ADD CONSTRAINT Maneja FOREIGN KEY
    (
     IdVehiculo
    )
    REFERENCES vehiculo
    (
     IdVehiculo
    )
;


ALTER TABLE SolicituVehiculo
    ADD CONSTRAINT Tiene FOREIGN KEY
    (
     IdCliente
    )
    REFERENCES Cliente
    (
     IdCliente
    )
;


ALTER TABLE Cliente
    ADD CONSTRAINT "Tiene convenio" FOREIGN KEY
    (
     IdTipoConvenio
    )
    REFERENCES TipoConvenio
    (
     IdTipoConvenio
    )
;


ALTER TABLE SolicituVehiculo
    ADD CONSTRAINT asiga FOREIGN KEY
    (
     IdChofer
    )
    REFERENCES Chofer
    (
     IdChofer
    )
;


insert into TipoConvenio values (1,'frecuente',to_date('02/04/2013','dd/mm/yyyy'),to_date('02/04/2013','dd/mm/yyyy'),2000);
insert into TipoConvenio values (2,'carrera',to_date('02/04/2013','dd/mm/yyyy'),to_date('02/04/2013','dd/mm/yyyy'),2500);

INSERT INTO vehiculo VALUES(1,'MG-193',2012,'SUSUKI',1);
INSERT INTO vehiculo VALUES(2,'MG-194',2012,'CHEVROLET',1);
INSERT INTO vehiculo VALUES(3,'MG-195',2012,'MERCEDEZ',1);

INSERT INTO chofer VALUES(1,'Mariela',1,'1-9','Fuentealba',24);
INSERT INTO chofer VALUES(2,'Milo',3,'1-k','Oyanedel',24);
INSERT INTO chofer VALUES(3,'Mariela',2,'1-2','Duran',22);

INSERT INTO cliente values(1,'1-2','Juean','Perez',1,26);
INSERT INTO cliente values(2,'1-3','Ana','Reyes',2,44);
INSERT INTO cliente values(3,'1-5','Luis','Muñoz',2,21);
INSERT INTO cliente values(4,'1-8','Pedro','Martinez',1,89);

INSERT INTO solicituvehiculo values(1,to_date('02/04/2013','dd/mm/yyyy'),'Rancagua','Santiago',21000,3,4);
INSERT INTO solicituvehiculo values(2,to_date('22/07/2013','dd/mm/yyyy'),'Santiago','Peñalolen',5000,2,1);
INSERT INTO solicituvehiculo values(3,to_date('12/09/2013','dd/mm/yyyy'),'Valparaiso','Santiago',24000,1,3);

select * from TipoConvenio;
select * from vehiculo;
select * from chofer;
select * from cliente;
select * from solicituvehiculo;

jueves, 10 de octubre de 2013

Taller compañía



-- Generado por Oracle SQL Developer Data Modeler 3.1.4.710
--   en:        2013-10-10 23:14:29 CLT
--   sitio:      Oracle Database 11g
--   tipo:      Oracle Database 11g



CREATE TABLE "Carga Familiares" 
    ( 
     sexo CHAR (1)  NOT NULL , 
     parentescoEmpleado VARCHAR2  NOT NULL , 
     fechaNacimiento INTEGER  NOT NULL , 
     numeroLiquidacion INTEGER  NOT NULL , 
     numeroUnico INTEGER  NOT NULL , 
     numeroUnico1 INTEGER  NOT NULL , 
     numeroLiquidacion1 INTEGER  NOT NULL , 
     numeroUnico2 INTEGER  NOT NULL , 
     numeroLiquidacion2 INTEGER  NOT NULL , 
     id INTEGER  NOT NULL , 
     codigoEmpleado INTEGER  NOT NULL 
    ) 
;


CREATE UNIQUE INDEX "Carga Familiares__IDXv1" ON "Carga Familiares" 
    ( 
     numeroUnico ASC , 
     codigoEmpleado ASC , 
     id ASC 
    ) 
;
CREATE UNIQUE INDEX "Carga Familiares__IDX" ON "Carga Familiares" 
    ( 
     numeroLiquidacion ASC , 
     numeroUnico ASC , 
     numeroUnico1 ASC 
    ) 
;
CREATE UNIQUE INDEX "Carga Familiares__IDXv2" ON "Carga Familiares" 
    ( 
     numeroLiquidacion1 ASC , 
     numeroUnico ASC , 
     numeroUnico2 ASC 
    ) 
;

ALTER TABLE "Carga Familiares" 
    ADD CONSTRAINT "Carga Familiares PK" PRIMARY KEY ( numeroUnico1, numeroUnico, numeroLiquidacion ) ;



CREATE TABLE Departamento 
    ( 
     numeroUnico INTEGER  NOT NULL , 
     nombreEmpleado INTEGER 
    ) 
;



ALTER TABLE Departamento 
    ADD CONSTRAINT "Departamento PK" PRIMARY KEY ( numeroUnico ) ;



CREATE TABLE "Deposito Cuenta C" 
    ( 
     numeroCuenta NUMBER (10,1)  NOT NULL , 
     Monto NUMBER (10,1)  NOT NULL 
    ) 
;



ALTER TABLE "Deposito Cuenta C" 
    ADD CONSTRAINT "Deposito Cuenta C"." PK" PRIMARY KEY ( numeroCuenta ) ;



CREATE TABLE Empleado 
    ( 
     nombre VARCHAR2 (30)  NOT NULL , 
     rut VARCHAR2 (10)  NOT NULL , 
     dirección VARCHAR2  NOT NULL , 
     sueldo NUMBER (10,1)  NOT NULL , 
     sexo CHAR (1)  NOT NULL , 
     fechaNacimiento VARCHAR2  NOT NULL , 
     numeroUnico INTEGER  NOT NULL , 
     numeroLiquidacion INTEGER  NOT NULL , 
     numeroUnico1 INTEGER  NOT NULL , 
     numeroUnico3 INTEGER  NOT NULL , 
     codigoEmpleado INTEGER  NOT NULL , 
     id INTEGER  NOT NULL , 
     numeroUnico2 INTEGER  NOT NULL , 
     numeroLiquidacion1 INTEGER  NOT NULL 
    ) 
;


CREATE UNIQUE INDEX Empleado__IDXv1 ON Empleado 
    ( 
     id ASC , 
     numeroUnico ASC , 
     codigoEmpleado ASC 
    ) 
;
CREATE UNIQUE INDEX Empleado__IDX ON Empleado 
    ( 
     numeroUnico2 ASC 
    ) 
;
CREATE UNIQUE INDEX Empleado__IDXv2 ON Empleado 
    ( 
     numeroUnico ASC , 
     numeroUnico1 ASC , 
     numeroLiquidacion ASC 
    ) 
;
CREATE UNIQUE INDEX Empleado__IDXv3 ON Empleado 
    ( 
     numeroUnico ASC , 
     numeroUnico3 ASC , 
     numeroLiquidacion ASC 
    ) 
;

ALTER TABLE Empleado 
    ADD CONSTRAINT "Empleado PK" PRIMARY KEY ( numeroLiquidacion, numeroUnico1, numeroUnico ) ;



CREATE TABLE "Pago Cheque" 
    ( 
     numeroCheque INTEGER  NOT NULL , 
     Monto NUMBER (10,1)  NOT NULL 
    ) 
;



ALTER TABLE "Pago Cheque" 
    ADD CONSTRAINT "Pago Cheque PK" PRIMARY KEY ( numeroCheque ) ;



CREATE TABLE Proyectos 
    ( 
     numeroUnico_1 INTEGER  NOT NULL , 
     nombre VARCHAR2 (30) , 
     numeroUnico INTEGER , 
     numeroLiquidacion INTEGER  NOT NULL , 
     numeroUnico1 INTEGER  NOT NULL , 
     numeroUnico2 INTEGER  NOT NULL , 
     numeroLiquidacion1 INTEGER  NOT NULL , 
     numeroUnico11 INTEGER  NOT NULL , 
     numeroUnico3 INTEGER  NOT NULL , 
     numeroUnico12 INTEGER  NOT NULL , 
     codigoEmpleado INTEGER  NOT NULL , 
     id INTEGER  NOT NULL , 
     numeroUnico4 INTEGER 
    ) 
;



ALTER TABLE Proyectos 
    ADD CONSTRAINT Key_1 PRIMARY KEY ( numeroUnico11, numeroUnico2, numeroLiquidacion1, numeroUnico_1, numeroUnico1, numeroLiquidacion, numeroUnico3, numeroUnico12 ) ;



CREATE TABLE "Sueldo Empleados" 
    ( 
     numeroLiquidacion INTEGER  NOT NULL , 
     numeroCheque INTEGER , 
     numeroCuenta NUMBER (10,1) , 
     numeroCheque1 INTEGER , 
     numeroCuenta1 NUMBER (10,1) 
    ) 
;



ALTER TABLE "Sueldo Empleados" 
    ADD CONSTRAINT "Sueldo Empleados PK" PRIMARY KEY ( numeroLiquidacion ) ;




ALTER TABLE Empleado 
    ADD CONSTRAINT Asignado FOREIGN KEY 
    ( 
     numeroUnico
    ) 
    REFERENCES Departamento 
    ( 
     numeroUnico
    ) 
;


ALTER TABLE Empleado 
    ADD CONSTRAINT Asignadov1 FOREIGN KEY 
    ( 
     numeroUnico2
    ) 
    REFERENCES Departamento 
    ( 
     numeroUnico
    ) 
;


ALTER TABLE Proyectos 
    ADD CONSTRAINT Controla FOREIGN KEY 
    ( 
     numeroUnico
    ) 
    REFERENCES Departamento 
    ( 
     numeroUnico
    ) 
;


ALTER TABLE Proyectos 
    ADD CONSTRAINT Controlav1 FOREIGN KEY 
    ( 
     numeroUnico4
    ) 
    REFERENCES Departamento 
    ( 
     numeroUnico
    ) 
;


ALTER TABLE Proyectos 
    ADD CONSTRAINT Relation_14 FOREIGN KEY 
    ( 
     numeroLiquidacion,
     numeroUnico12,
     numeroUnico3
    ) 
    REFERENCES Empleado 
    ( 
     numeroLiquidacion,
     numeroUnico1,
     numeroUnico
    ) 
;


ALTER TABLE Proyectos 
    ADD CONSTRAINT Relation_14v1 FOREIGN KEY 
    ( 
     numeroLiquidacion1,
     numeroUnico11,
     numeroUnico2
    ) 
    REFERENCES Empleado 
    ( 
     numeroLiquidacion,
     numeroUnico1,
     numeroUnico
    ) 
;


ALTER TABLE Empleado 
    ADD CONSTRAINT Relation_16 FOREIGN KEY 
    ( 
     numeroLiquidacion
    ) 
    REFERENCES "Sueldo Empleados" 
    ( 
     numeroLiquidacion
    ) 
;


ALTER TABLE Empleado 
    ADD CONSTRAINT Relation_16v1 FOREIGN KEY 
    ( 
     numeroLiquidacion1
    ) 
    REFERENCES "Sueldo Empleados" 
    ( 
     numeroLiquidacion
    ) 
;


ALTER TABLE "Sueldo Empleados" 
    ADD CONSTRAINT Relation_18 FOREIGN KEY 
    ( 
     numeroCheque
    ) 
    REFERENCES "Pago Cheque" 
    ( 
     numeroCheque
    ) 
;


ALTER TABLE "Sueldo Empleados" 
    ADD CONSTRAINT Relation_18v1 FOREIGN KEY 
    ( 
     numeroCheque1
    ) 
    REFERENCES "Pago Cheque" 
    ( 
     numeroCheque
    ) 
;


ALTER TABLE "Sueldo Empleados" 
    ADD CONSTRAINT Relation_20 FOREIGN KEY 
    ( 
     numeroCuenta
    ) 
    REFERENCES "Deposito Cuenta C" 
    ( 
     numeroCuenta
    ) 
;


ALTER TABLE "Sueldo Empleados" 
    ADD CONSTRAINT Relation_20v1 FOREIGN KEY 
    ( 
     numeroCuenta1
    ) 
    REFERENCES "Deposito Cuenta C" 
    ( 
     numeroCuenta
    ) 
;


ALTER TABLE Empleado 
    ADD CONSTRAINT Relation_34 FOREIGN KEY 
    ( 
     numeroUnico,
     numeroUnico3,
     numeroLiquidacion
    ) 
    REFERENCES "Carga Familiares" 
    ( 
     numeroUnico1,
     numeroUnico,
     numeroLiquidacion
    ) 
    ON DELETE CASCADE 
;


ALTER TABLE "Carga Familiares" 
    ADD CONSTRAINT Relation_34 FOREIGN KEY 
    ( 
     numeroLiquidacion1,
     numeroUnico,
     numeroUnico2
    ) 
    REFERENCES Empleado 
    ( 
     numeroLiquidacion,
     numeroUnico1,
     numeroUnico
    ) 
    ON DELETE CASCADE 
;


ALTER TABLE "Carga Familiares" 
    ADD CONSTRAINT Relation_34v1 FOREIGN KEY 
    ( 
     numeroLiquidacion,
     numeroUnico,
     numeroUnico1
    ) 
    REFERENCES Empleado 
    ( 
     numeroLiquidacion,
     numeroUnico1,
     numeroUnico
    ) 
    ON DELETE CASCADE 
;


ALTER TABLE Empleado 
    ADD CONSTRAINT Relation_34v1 FOREIGN KEY 
    ( 
     numeroUnico,
     numeroUnico1,
     numeroLiquidacion
    ) 
    REFERENCES "Carga Familiares" 
    ( 
     numeroUnico1,
     numeroUnico,
     numeroLiquidacion
    ) 
    ON DELETE CASCADE 
;



-- Informe de Resumen de Oracle SQL Developer Data Modeler: 
-- 
-- CREATE TABLE                             7
-- CREATE INDEX                             7
-- ALTER TABLE                             23
-- CREATE VIEW                              0
-- CREATE PACKAGE                           0
-- CREATE PACKAGE BODY                      0
-- CREATE PROCEDURE                         0
-- CREATE FUNCTION                          0
-- CREATE TRIGGER                           0
-- ALTER TRIGGER                            0
-- CREATE STRUCTURED TYPE                   0
-- CREATE COLLECTION TYPE                   0
-- CREATE CLUSTER                           0
-- CREATE CONTEXT                           0
-- CREATE DATABASE                          0
-- CREATE DIMENSION                         0
-- CREATE DIRECTORY                         0
-- CREATE DISK GROUP                        0
-- CREATE ROLE                              0
-- CREATE ROLLBACK SEGMENT                  0
-- CREATE SEQUENCE                          0
-- CREATE MATERIALIZED VIEW                 0
-- CREATE SYNONYM                           0
-- CREATE TABLESPACE                        0
-- CREATE USER                              0
-- 
-- DROP TABLESPACE                          0
-- DROP DATABASE                            0
-- 
-- ERRORS                                   0
-- WARNINGS                                 0

INSERT INTO PAGO
(
  idpago,
  fecha,
  monto,
  descripcion
)
VALUES
(
  1,
  to_date('2013-01-01','yyyy-mm-dd'),
  1000000,
  'MERECE TODO SU SUELDO'
);

INSERT INTO empleado 
(
  IDEMPLEADO,
  NOMBRE,
  APELLIDOPATERNO,
  APELLIDOMATERNO,
  RUT,
  SEXO,
  FECHANACIMIENTO,
  DIRECCIÓN,
  SUELDO,
  HORAPROYECTO,
  FORMAPAGO,
  NOMBREUNICO,
  NOMBREUNICO1,
  IDPAGO

values
(
  '1',
  'mariela',
  'fuentealba',
  'arratia',
  '1-9',
  'femenino',
  to_date('1989-01-01','yyyy-mm-dd'),
  'calle no se, numero 123',
  1000000,
  100,
  'tarjeta',
  'nombreunico',
  'asfasdf',
  1
);


SELECT * FROM empleado

lunes, 7 de octubre de 2013

Práctica SQL DEVELOPER

Objetivo: Práctica SQL DEVELOPER

1.- Crear Modelo E/R (conceptual)
2.- Pasar al modelo relacional
3.- Generar el script (DDL)
4.- Guardar Proyecto
5.- Recuperar Proyecto

Ej: Create table empleado(
idemp integer
nombre varchar2(35)
) ;

Comandos que genera el script
- Create table
- Alter table
- Drop table
- Insert into


lunes, 23 de septiembre de 2013


Ejercicios Hotel

hotel: código, ciudad, país, nombre,teléfono,web
habitación : tipo doble,simple
                       doble 1 matrimonial+1 laza extra
                       simple 1 0 2 camas 1 plaza
cliente:
reserva:
empleados: rut ,nombre, teléfono, cargo, salarioBase ,porcentajeBeneficio

Para crear el modelo 

- se identifican las candidatos entidades
- se crea una matriz de entidades 

sábado, 7 de septiembre de 2013

EJERCICIOS DE ENUNCIADOS DE MODELO ENTIDAD RELACION

EJERCICIOS DE ENUNCIADOS DE MODELO ENTIDAD RELACION

Por Enzo Parra:
EJERCICIO 1.- SERVICIO MILITAR
El Ministerio de Defensa desea diseñar una Base de Datos para llevar un cierto control de los
soldados que realizan el servicio militar. Los datos significativos a tener en cuenta son:
· Un soldado se define por su código de soldado (único), su nombre y apellidos, y su graduación.
· Existen varios cuarteles, cada uno se define por su código de cuartel, nombre y ubicación.
· Hay que tener en cuenta que existen diferentes Cuerpos del Ejército (Infantería, Artillería,
Armada, ....), y cada uno se define por un código de Cuerpo y denominación.
· Los soldados están agrupados en compañías, siendo significativa para cada una de éstas, el
número de compañía y la actividad principal que realiza.
· Se desea controlar los servicios que realizan los soldados (guardias, imaginarias, cuarteleros, ...),
y se definen por el código de servicio y descripción.
Consideraciones de diseño:
· Un soldado pertenece a un único cuerpo y a una única compañía, durante todo el servicio
militar. A una compañía pueden pertenecer soldados de diferentes cuerpos, no habiendo relación
directa entre compañías y cuerpos.
· Los soldados de una misma compañía pueden estar destinados en diferentes cuarteles, es decir,
una compañía puede estar ubicada en varios cuarteles, y en un cuartel puede haber varias
compañías. Eso si, un soldado sólo esta en un cuartel.
· Un soldado realiza varios servicios a lo largo de la mili. Un mismo servicio puede ser realizado
por más de un soldado (con independencia de la compañía), siendo significativa la fecha de
realización.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

EJERCICIO 2.- GESTIÓN DE TRABAJOS DE FIN DE CARRERA.
Una Escuela de Informática quiere generar un sistema para tener controlado en una base de datos
todo lo referente a los Trabajos Fin de Carrera: alumnos que los realizan, profesores que los dirigen, temas
de los que tratan y tribunales que los corrigen. Por tanto, es de interés:
· Que los alumnos se definan por su número de matrícula, DNI y nombre. Un alumno realiza,
evidentemente, sólo un T.F.C.
· Que los T.F.C. se definen por su tema, por un número de orden y por la fecha de comienzo. Un
T.F.C. determinado, no puede ser realizado por varios alumnos.
· Que un profesor se define por su DNI, nombre y domicilio; y puesto que los T.F.C. son del área
en el que trabaja, NO interesa conocer el T.F.C. que dirige sino a qué alumno se lo dirige.
· Que un Tribunal está formado por varios profesores y los profesores pueden formar parte de
varios tribunales. Por otra parte, sí es de interés para el tribunal conocer qué alumno es el que se
presenta, con qué T.F.C. y en qué fecha lo ha defendido. El tribunal se define por un número de
tribunal, lugar de examen y por el número de componentes.
· Al margen de esto, un alumno puede haber pertenecido a algún grupo de investigación del que
haya surgido la idea del T.F.C. Dichos grupos se identifican por un número de grupo, su nombre
y por su número de componentes. Un alumno no puede pertenecer a más de un grupo y no es de
interés saber si el grupo tiene algo que ver o no con el T.F.C. del alumno; sí siendo de interés la
fecha de incorporación a dicho grupo.
· Por otra parte, un profesor, al margen de dirigir el T.F.C. de algunos alumnos, puede haber
colaborado con otros en la realización de dicho T.F.C. pero siendo otro profesor el que lo
dirige. En este caso, sólo es interesante conocer qué profesor ha ayudado a qué alumno (a un
alumno le pueden ayudar varios profesores).Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

EJERCICIO 3.- AGENCIAS DE VIAJES
Una cadena de agencias de viajes desea disponer de una Base de Datos que contemple información
relativa al hospedaje y vuelos de los turistas que la contratan.
Los datos a tener en cuenta son:
· La cadena de agencias está compuesta por un conjunto de sucursales. Cada sucursal viene
definida por el código de sucursal, dirección y teléfono.
· La cadena tiene contratados una serie de hoteles de forma exclusiva. Cada hotel estará definido
por el código de hotel, nombre, dirección, ciudad, teléfono y número de plazas disponibles.
· De igual forma, la cadena tiene contratados una serie de vuelos regulares de forma exclusiva.
Cada vuelo viene definido por el número de vuelo, fecha y hora, origen y destino, plazas totales y
plazas de clase turista de las que dispone.
· La información que se desea almacenar por cada turista es el código de turista, nombre y
apellidos, dirección y teléfono.
Por otra parte, hay que tener en cuenta la siguiente información:
· A la cadena de agencias le interesa conocer que sucursal ha contratado el turista.
· A la hora de viajar el turista puede elegir cualquiera de los vuelos que ofrece la cadena, y en que
clase (turista o primera) desea viajar.
· De igual manera, el turista se puede hospedar en cualquiera de los hoteles que ofrece la cadena,
y elegir el régimen de hospedaje (media pensión o pensión completa). Siendo significativa la
fecha de llegada y de partida.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

Por Mariela Fuentealba:
EJERCICIO 4.- GESTIÓN DE EXÁMENES
Los profesores de la asignatura de Bases de Datos de una Escuela Universitaria deciden crear una
base de datos que contenga la información de los resultados de las pruebas realizadas a los alumnos. Para
realizar el diseño se sabe que:
· Los alumnos están definidos por su n° de matrícula, nombre y el grupo al que asisten a clase.
· Dichos alumnos realizan dos tipos de pruebas a lo largo del curso académico:
1. Exámenes escritos: cada alumno realiza varios a lo largo del curso, y se definen por el n° de
examen, el n° de preguntas de que consta y la fecha de realización (la misma para todos los
alumnos que realizan el mismo examen). Evidentemente, es importante almacenar la nota de
cada alumno por examen.
2. Prácticas: se realiza un n° indeterminado de ellas durante el curso académico, algunas serán en
grupo y otras individuales. Se definen por un código de práctica, título y el grado de
dificultad. En este caso los alumnos pueden examinarse de cualquier práctica cuando lo
deseen, debiéndose almacenar la fecha y nota obtenida.
· En cuanto a los profesores, únicamente interesa conocer (además de sus datos personales: DNI y
nombre), quien es el qué ha diseñado cada práctica, sabiendo que en el diseño de una práctica
puede colaborar más de uno, y que un profesor puede diseñar más de una práctica. Interesa,
además, la fecha en que ha sido diseñada cada práctica por el profesor correspondiente.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

EJERCICIO 5.- CONCESIONARIO DE AUTOMÓVILES
Un concesionario de automóviles desea informatizar su gestión de ventas de vehículos. En particular,
se quiere tener almacenada la información referente a los clientes que compran en el concesionario, los
vehículos vendidos, así como los vendedores que realizan las distintas ventas. Para ello se tendrá en cuenta
que:
· El concesionario dispone de un catálogo de vehículos definidos por su marca, modelo, cilindrada
y precio.
· Cada uno de los modelos dispondrá de unas opciones adicionales (aire acondicionado, pintura
metalizada, etc.). Las opciones vienen definidas por un nombre y una descripción. Hay que tener
en cuenta que una opción puede ser común para varios modelos variando sólo el precio en cada
caso.
· En cuanto a los clientes, la información de interés es el nombre, DNI, dirección y teléfono, lo
mismo que para los vendedores.
· Los clientes pueden ceder su coche usado en el momento de comprar un vehículo nuevo. El
coche usado vendrá definido por su marca, modelo, matrícula y precio de tasación. Es
importante conocer la fecha en la que el cliente realiza esta cesión.
· Se desea saber qué vendedor ha vendido qué modelo a qué cliente. También la fecha de la venta
y la matricula del nuevo vehículo. Es importante así mismo saber las opciones que el cliente ha
elegido para el modelo que compra.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

 EJERCICIO 6.- HOLDING EMPRESARIAL
Un holding de empresas desea tener una base de datos referente a las empresas que posee, sus
vendedores, así como los asesores que trabajan en el holding. La información está organizada de la
siguiente forma:
· Los vendedores se organizan en una jerarquía de pirámide, es decir, cada vendedor puede captar
otros vendedores para el holding, de manera que un vendedor tendrá a su cargo varios
vendedores. Hay que tener en cuenta que un vendedor sólo podrá trabajar en una empresa y sólo
podrá captar vendedores para la empresa en que trabaja; siendo importante almacenar la fecha en
que se realiza la captación. Los datos de interés para los vendedores serán el código de vendedor,
nombre y la dirección.
· Las empresas cubrirán diferentes áreas del mercado y un mismo área puede ser cubierta por varias
empresas. Es interesante conocer el nombre del área y una descripción de ésta. Las empresas
pueden estar actuando en varios países y en un país pueden estar desarrollando actividades varias
empresas. Sin embargo, cada empresa tendrá su sede en un único país, siendo importante la
ciudad donde se localiza la sede. Por cuestiones fiscales, una empresa puede tener su sede en un
país en el que no esté desarrollando actividad alguna. Los datos de interés para las empresas son el
nombre, la fecha de entrada en el holding, la facturación anual y el número de vendedores que
posee.
· Los datos de interés de los países son: el nombre, el PIB, el número de habitantes y la capital.
· Los asesores entran en el holding para dar soporte en cada una de las áreas en las que actúa el
holding. Un asesor puede cubrir varias áreas y un área puede ser cubierta por varios asesores. Un
asesor puede asesorar a varias empresas y una empresa tener varios asesores. Es importante saber
en qué fecha un asesor comienza a trabajar para una empresa en un área determinada. Los datos
de interés de los asesores son el código de asesor, nombre, dirección y la titulación.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

Por Veronica Martinez: 
EJERCICIO 7.- CLUB NÁUTICO
Un club náutico desea tener informatizados los datos correspondientes a sus instalaciones,
empleados, socios y embarcaciones que se encuentran en dicho club. El club esta organizado de la
siguiente forma:
· Los socios pertenecientes al club vienen definidos por su nombre, dirección, DNI, teléfono y
fecha de ingreso en el club.
· Las embarcaciones vienen definidas por: matricula, nombre, tipo y dimensiones.
· Los amarres tienen como datos de interés el número de amarre, la lectura del contador de agua y
luz, y si tienen o no servicios de mantenimiento contratados.
· Por otro lado, hay que tener en cuenta que una embarcación pertenece a un socio aunque un
socio puede tener varias embarcaciones. Una embarcación ocupará un amarre y un amarre está
ocupado por una sola embarcación. Es importante la fecha en la que una embarcación en
asignada a un amarre.
· Los socios pueden ser propietarios de amarres, siendo importante la fecha de compra del
amarre. Hay que tener en cuenta que un amarre pertenece a un solo socio y que NO HAY
ninguna relación directa entre la fecha en la que se compra un amarre y en la que una
embarcación se asigna a un amarre.
· El club náutico está dividido en varias zonas definidas por una letra, el tipo de barcos que tiene,
el numero de barcos que contiene, la profundidad y el ancho de los amarres. Una zona tendrá
varios amarres y un amarre pertenece a una sola zona.
· En cuanto a los empleados, estos vienen definidos por su código, nombre, dirección, teléfono y
especialidad. Un empleado está asignado a varias zonas y en una zona puede haber más de un
empleado, siendo de interés el número de barcos de los que se encarga en cada zona. Hay que
tener en cuenta que un empleado puede no encargarse de todos los barcos de una zona.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

EJERCICIO 8.- COMPAÑÍA DE SEGUROS
Una compañía de seguros desea que se haga un diseño de una base de datos para gestionar toda la
información referente a los seguros que ofrece, los clientes a los que atiende y los agentes de seguros que
trabajan para la compañía. Esta compañía ofrece tres tipos de seguros:
· Seguros de Hogar: los seguros de este tipo ofrecidos por la compañía están ofertados de forma
fija (es decir se han hecho estudios previos), según el valor del continente (la casa), el contenido
(muebles, electrodomésticos, joyas, etc.), riesgos auxiliares (responsabilidad civil, asalto y otros).
Para cada oferta hay una prima asignada.
· Seguros de Vida: de la misma forma que los de hogar, existen varias ofertas fijas según la edad y
profesión del cliente, y la cobertura económica del seguro. De la misma forma que en los seguros
de Hogar, existe un prima fija para cada oferta.
· Seguros de Automóvil: también existen ofertas fijas, según la categoría de coche (utilitario, gama
media, gama alta, gran turismo, lujo, etc.), años del vehículo, edad del conductor y cobertura
(todo riesgo, franquicia, terceros, etc.). A cada una de estas ofertas le corresponde una prima.
Para llevar un control de las comisiones que se llevan los agentes y de sus carteras correspondientes,
la compañía necesita tener almacenados los datos de los agentes, considerándose de interés el nombre,
DNI, dirección y teléfono. Para el pago de comisiones y carteras (se entiende por “cartera” la comisión
anual del agente mientras el seguro este vigente), será necesario saber qué agente ha realizado qué seguro y
en qué fecha.
La compañía considera como datos de interés referentes al cliente (sea cual sea el seguro que
contrate), los siguientes: Nombre, dirección, teléfono y DNI.
Otras consideraciones sobre la contratación de seguros por parte del cliente son:
· Seguros Hogar: fecha del contrato del seguro y dirección del inmueble asegurado.
· Seguros Automóvil: fecha contratación, matrícula del vehículo, recargos y descuentos.
· Otras consideraciones: Un cliente puede contratar más de un seguro de Vida, más de un seguro
de Hogar y más de un seguro de Automóvil. Además estos contratos pueden realizarse a través
de distintos agentes. Los beneficiarios de seguros de vida pueden serlo de varios seguros, e
incluso de varios clientes distintos. Por supuesto un cliente puede nombrar a varios beneficiarios
de un mismo seguro de vida.Diseño de Bases de Datos Relacionales Modelo Entidad/Relación

EJERCICIO 9.- OFICINA DE PATENTES
Una oficina de patentes desea disponer de una Base de Datos que contenga toda la información
relativa a la presentación de patentes, inventores que las presentan y las empresas que desean comprarlas.
Esta información tendrá que estar organizada teniendo en cuenta los siguientes puntos:
· Los datos de interés referentes a cada patente serán el número de patente y el nombre del
invento. La patente sólo puede pertenecer a un único inventor, no pudiendo realizarse varias
patentes referentes al mismo invento.
· Los inventores vendrán definidos por su nombre, D.N.I., dirección y teléfono. Estos inventores
podrán obtener varias patentes, siempre que éstas sean de diferentes inventos. Es importante
saber la fecha en la cual se ha obtenido la patente.
· Hay que tener en cuenta los casos en los que un inventor asesore a otros en el desarrollo de un
invento.
· Cada inventor tendrá uno o varios ayudantes que vendrán definidos por su nombre, dirección,
teléfono y D.N.I.. Además, estos ayudantes sólo podrán serlo de un inventor.
· Cada patente podrá se comprada por una sola empresa y una empresa podrá comprar diferentes
patentes, siendo de interés la fecha de compra de la patente. Las empresas vienen definidas por
un código de empresa, nombre, dirección y sus teléfonos.
· Las empresas, al realizar la compra de una patente, pueden tener interés en contratar a su
inventor. Es importante saber en qué fecha un inventor es contratado por una empresa con una
patente determinada.
· Un ayudante puede ser contratado por una empresa con independencia de que la empresa haya
contratado o no al inventor del que es ayudante, siendo importante conocer la fecha de
contratación.