ejercicio 1- agencia de viajes

Supongamosque se nos ha encargado el desarrollo de una aplicación que se encargue de gestionar la reserva de billetes de avión en una agencia de viajes. Tras analizar el problema con nuestros clientes hemos recopilado la siguiente lista de requisitos:

- La agencia de viajes desea mantener información de contacto relativa a cada cliente que ha utilizado los servicios de reserva de billetes a través de la agencia.
-Cuando un cliente hace una reserva, compra un billete para trasladarse de una ciudad a otra. El billete ha de incluir, aparte del nombre del viajero y las ciudades de origen y destino, su fecha de emisión y su precio total.
-Los billetes pueden ser de distintas categorías (business, turista…).
-Dado que no siempre hay vuelos directos entre dos ciudades, el trayecto realizado por el cliente puede estar formado por distintos tramos. Cada tramo corresponde a un vuelo concreto entre dos aeropuertos y viene definido por el código de vuelo, la fecha y la hora de salida. En algunas ocasiones, la agencia es capaz de reservar un asiento concreto dentro del avión.
-El código de cada vuelo está formado por el código de la compañía aérea y un número. Por ejemplo, el vuelo IB-365 es el vuelo número 365 de la compañía Iberia.
-Cada vuelo oferta un número determinado de plazas para cada categoría y cada categoría tiene asociada una tarifa diferente para un mismo vuelo. -Los aeropuertos vienen identificados unívocamente por un código de tres letras (por ejemplo, GRX corresponde al aeropuerto de Granada).
-En el caso de los billetes de ida y vuelta, lo único que tenemos que hacer es incluir los tramos que sean necesarios para realizar el recorrido completo.

ejercicio 2 -asociacion"amigos de la fiesta"

La asociación "Amigos de la Fiesta" desea recoger en una base de datos toda la información acerca de las corridas de toros que se celebran en España y de todos los datos relacionados con ellas.
Se desea tener información acerca de cada corrida, identificada conjuntamente por un número de orden, la feria en la que se celebra y el año de celebración (por ejemplo: orden = 2, feria = San Isidro, año = 1990); las corridas que no se celebran durante una feria tienen 0 en el campo Feria y se numeran correlativamente dentro de ese año.
En una determinada corrida actúan una serie de toreros (mínimo 1 y máximo 6) de los que se desea guardar su dni, nombre, apodo y fecha en que tomó la alternativa. Además se desea saber quién fue el torero (padrino) que le dio la alternativa en su día (un torero puede dar la alternativa a varios compañeros o a ninguno).
En cada corrida un torero obtiene una serie de premios (número de orejas, de rabos y si salió por la puerta grande) de los que se desea mantener información. Cada torero puede tener un apoderado. A su vez, un apoderado lo puede ser de varios toreros. De él se desea saber su dni, nombre, dirección y teléfono. Una corrida se celebra en una plaza de toros de la que se desea saber su nombre (que se supone único), localidad, dirección y aforo. En una misma plaza se pueden celebrar varias corridas de toros.
Cada toro pertenece a una ganadería determinada. De cada ganadería se quiere conocer su código, nombre, localidad, procedencia y antigüedad (fecha de creación). En cada corrida son estoqueados al menos 6 toros.
Cada toro viene identificado por el código de la ganadería a la que pertenece, el año en que nació y un número de orden. Además se desea mantener información acerca de su nombre y color, así como del orden en que fue toreado.

ejercicio 3 -empresa de formacion x

La empresa de formación X, desea llevar un control informatizado de los cursos que imparte así como de lo profesores que participan en dichos cursos. Para ello, nos han dado las siguientes especificaciones:

Cada curso, del que se desea conocer el título, el número de horas y el tema o los temas que trata, se identifica por un código de cuso. Cada curso puede tener una serie de cursos cuyo realización previa es obligatoria(prerrequisito) o recomendada. Cada curso se puede impartir una o varias veces, en diferentes fechas y en cada edición del mismo pueden participar diferentes empleados.
Los empleados, de los que se desea conocer su código de empleado, nombre, DNI y fecha de antigüedad en la empresa, pueden impartir y recibir cursos pero con la restricción de que en una mismo edición de un curso no pueden participar como profesores y como alumnos.

ejercicio 4- compañia

La base de datos COMPAÑIA se ocupa de los empleado, departamentos y proyectos de una empresa, de acuerdo con los siguientes requisitos:

1. La compañia está organizada en departamentos. Cada departamento tiene un nombre único, un número único y un empleado que la dirige y estamos interesados en guardar la fecha en que dicho empleado comenzó a dirigir el departamento. Un departamento puede estar distribuido en varios lugares.

2. Cada departamento controla un cierto número de proyectos, cada uno de los cuales tiene un nombre y un número únicos, y se realiza en un sólo lugar.

3. Se almacena el nombre, número de la Seguridad Social, dirección, salario, sexo y fecha de nacimiento de cada empleado. Todo empleado está asignado a un departamento, pero puede trabajar en varios proyectos que no tienen porque ser del mismo departamento. Nos interesa saber el número de horas que un empleado trabaja en cada proyecto a los que está asignado.

4. También se quiere guardar la relación de las cargas familiares de cada empleado para administrar el seguro que poseen. Almacenaremos el nombre, sexo y fecha de nacimiento de cada una de las cargas familiares y su parentesco con el empleado.

ejercicio 5- sucursal bancaria

Se desea diseñar una base de datos para una sucursal bancaria que contenga
informacion sobre los clientes, las cuentas, las sucursales y las transacciones
producidas. Construir el modelo E/R teniendo en cuenta las siguientes restricciones:
1. Una transaccion viene determinada por su numero de transaccion, la fecha y la cantidad.
2. Un cliente puede tener muchas cuentes.
3. Una cuenta puede tener muchos clientes.
4. Una cuenta solo puede estar en una sucursal.

Normalizacion

Normalización de bases de datos

Para otros usos de este término, véase Normalización.
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
Cada columna debe tener su nombre único.
No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.

Primera forma normal

La primera forma normal (1NF o forma mínima) es una forma normal usada en normalización de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1NF es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación y está libre de "grupos repetitivos".
Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes teóricos. Como una consecuencia, no hay un acuerdo universal en cuanto a qué características descalificarían a una tabla de estar en 1NF. Muy notablemente, la 1NF, tal y como es definida por algunos autores excluye "atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente establecido por E.F. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe ).

Segunda forma normal

La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2NF definida originalmente por E.F. Codd en 1971. Una tabla que está en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF está en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la clave candidata, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella.
En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto apropiado) de una clave candidata. (Un atributo no-principal de A es uno que no pertenece a ninguna clave candidata).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en más de un atributo), la tabla está automáticamente en 2NF.

Tercera forma normal

La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:
La tabla está en la segunda forma normal (2NF)
Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave candidata
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidato. Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X → Z por virtud de X → Y y Y → Z.
Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo en 1982, es ésta: Una tabla está en 3NF si y solo si, para cada una de sus dependencias funcionales X → A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A, ó
X es una superclave, ó
A es un atributo primario (es decir, A está contenido dentro de una clave candidato)
La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la más rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario").