MANUAL BD Para Alumnos

Oracle de Mxico S.A de C.V. Servicios Educacionales


1

INTRODUCCION


1-2 Introduccin Diseo relacional de Base de Datos

INTRODUCCION A ORACLE


Diseo relacional de Base de Datos Introduccin 1-3



CASE DE ORACLE


Diseo relacional de Base de Datos Introduccin 1-5



2

INTRODUCCION AL

DESARROLLO DE BASE DE DATOS


OBJETIVOS DE LA SECCION


2-2 Introduccin al desarrollo de Base de Datos


Introduccin al desarrollo de Base de Datos 2-3



3 MODELO

DE DATOS CONCEPTUAL BASICO


OBJETIVOS DE LA SECCIN Al final de esta seccin, el alumno ser capaz de:

1. Identificar y modelar entidades 2. Analizar y modelar las relaciones entre las entidades 3. Analizar y modelar atributos 4. Reconocer Identificadores nicos para cada entidad 5. Desarrollar un modelo bsico entidad-relacin a partir de los requerimientos de

informacin y de las entrevistas a usuarios


MODELO CONCEPTUAL DE DATOS

El modelo conceptual de datos es el primer paso del proceso TOP-DOWN para el desarrollo de base de datos, se ejecuta durante las fases de anlisis y estrategia en el Ciclo de Desarrollo de Sistemas.


Diseo Relacional de Base de Datos Modelo de Datos Conceptual Bsico 3-3

El objetivo del Modelo Conceptual de Datos es desarrollar el Modelo Entidad-Relacin que represente los requerimientos de informacin de los negocios.

EJEMPLO:

El siguiente modelo Entidad-Relacin representa los requerimientos de informacin del Departamento de Recursos Humanos

Componentes del Modelo Entidad-Relacin

Entidades Son los aspectos importantes acerca de los cuales se necesita

informacin.

Relaciones Como se relacionan las entidades

Atributos Informacin especfica la cual necesita ser almacenada.


3-4 Modelo de Datos Conceptual Bsico Diseo Relacional de Base de Datos

Un modelo Entidad-Relacin es una forma efectiva para integrar y documentar los requerimientos de informacin de una organizacin.

SINTAXIS

Un modelo E-R documenta los requerimientos de informacin de la organizacin en un formato preciso y claro.

COMUNICACIN DEL USUARIO

Los usuarios pueden entender fcilmente la forma grfica de un modelo E-R.

FACIL DE DESARROLLAR

Un modelo E-R puede ser fcilmente desarrollado y refinado.

DEFINICION DEL ALCANCE

Un modelo E-R provee una clara imagen del alcance de los requerimientos de informacin de las organizaciones

INTEGRACIN DE MULTIPLES APLICACIONES

Un modelo E-R provee una estructura adecuada para la integracin de mltiples aplicaciones, desarrollar proyectos, y/o paquetes de aplicacin adquiridos.

NOTAS

Asegurarse de establecer completamente los requerimientos de la informacin de la organizacin durante la etapa del Modelo Conceptual de Datos. Los cambios de los requerimientos durante las etapas finales en el ciclo de vida de desarrollo pueden ser extremadamente caros.

Usar vistas o subconjuntos de un modelo E-R para facilitar su entendimiento.



El modelo de datos conceptual es independiente del hardware o del software usados para la implementacin. Un modelo E-R puede ser utilizado para una base de datos de red, jerrquica o relacional.



ENTIDADES Una entidad es un aspecto importante acerca del cual se necesita tener o conocer informacin.

OTRAS DEFINICIONES DE ENTIDAD

Un objeto de inters para los negocios.

Una entidad es una clase o categora de cosas.

Una entidad es una cosa con un nombre.

EJEMPLOS Los siguientes pueden ser aspectos importantes acerca de las necesidades de informacin de un negocio:

EMPLEADO

DEPARTAMENTO

PROYECTO

Los atributos describen entidades y son las piezas especficas de informacin las cuales necesitan ser conocidas.

EJEMPLOS Posibles atributos para la entidad EMPLEADO son:

Nmero de clave, nombre, fecha de nacimiento y salario.

Posibles atributos para la entidad DEPARTAMENTON son:

Nombre, nmero y localizacin.

NOTA

Una entidad debe de tener atributos que necesitan ser conocidos desde el punto de vista del negocio, de otra manera no es una entidad que forme parte del alcance de los requerimientos del negocio.



ESTANDARES PARA DIAGRAMACIN DE ENTIDADES

Cajas de cualquier dimensin con las esquinas redondeadas

Un nombre nico para cada entidad

Nombre de la entidad en maysculas y en singular

Nombre de sinnimo, entre parntesis (opcional)

Nombre de los atributos en minsculas.

EJEMPLOS

NOTAS

Un sinnimo es un nombre alternativo para una entidad.

Los sinnimos son tiles cuando dos grupos de usuarios tienen diferentes nombres para el mismo aspecto importante.



Cada instancia debe ser identificada como nica de otras instancias de la misma entidad. Un atributo o conjunto de atributos que identifican de manera nica a una instancia dentro de una entidad son llamados Identificadores nicos (UID).

EJEMPLO

Cada EMPLEADO tiene una clave EMPLEADO nica. El nmero de clave del EMPLEADO es un candidato para ser el UID de la entidad EMPLEADO.

Ver los atributos que identifican de manera nica una instancia dentro de una entidad.

EJEMPLO

Qu atributos se consideran como nicos en las siguientes entidades?



IDENTIFICAR Y MODELAR ENTIDADES

Mediante los siguientes pasos se pueden llegar a identificar y modelar las entidades de un conjunto de notas de entrevistas.

1. Examinar los sustantivos. Son aspectos importantes?

2. Poner un nombre a cada entidad

3. Existe informacin de inters para la compaa acerca de la entidad?

4. Cada instancia de la entidad es identificable de manera nica? Cul o cules

atributos sirven como UID?

5. Escribir la descripcin de la entidad. UN EMPLEADO tiene como significado ser

un EMPLEADO que trabaja para la compaa. Por ejemplo, Juan Gmez y Mara

Herrera son empleados

6. Diagramar cada entidad y sus atributos.

NOTAS

No descalificar tan rpido una entidad candidata ya que posteriormente algunos atributos adicionales para la compaa pueden ser descubiertos.



EJEMPLO

Identificar y modelar las entidades con los siguientes requerimientos de informacin proporcionados por un usuario.

Soy el administrador de una compaa de capacitacin que provee cursos, impartidos por nuestros instructores, sobre tcnicas de administracin. Enseamos muchos cursos, cada uno tiene un cdigo, un nombre y un costo.

Introduccin a UNIX y Programando en C son dos de nuestros cursos ms populares. Los cursos varan en duracin des un da hasta cuatro das. Un instructor puede ensear varios cursos. Pedro Rodrguez y Mara Gonzles son dos de nuestros mejores instructores. Registramos el nombre de cada instructor y su nmero telefnico. Cada curso es enseado por solo un instructor. Se designa el curso y en base a ello asignamos al instructor. Los estudiantes pueden tomar varios cursos a travs del tiempo Javier Daz de AT&T tomo cada curso de los que ofrecemos. Tambin llevamos registro de los nombres de los estudiantes y su nmero telefnico. Varios de nuestros estudiantes e instructores no nos dan su nmero telefnico.



SOLUCIN

Las siguientes entidades son el modelo de los requerimientos de informacin de la compaa de entrenamiento.

DESCRIPCIN DE ENTIDADES

Un CURSO es un evento de entrenamiento ofrecido por la compaa de

entrenamiento.

Por ejemplo, Introduccin a UNIX y Programacin en C.

Un ESTUDIANTE es un participante en uno o varios cursos. Por ejemplo Javier

Daz.

Un INSTRUCTOR es un maestro de uno o varios cursos. Por ejemplo Pedro

Rodrguez y Mara Gonzles.



PRACTICA 3-1

Identificar y modelar entidades

1. Identificar y modelar las entidades con el siguiente conjunto de requerimientos. Escribir una breve descripcin de cada entidad. Mostrar por lo menos dos atributos para cada entidad Soy el propietario de una pequea tienda de pelculas. Tenemos ms de 3000 video cassettes de los que necesitamos llevar registro. Cada uno de nuestro video cassettes tienen un nmero de cinta. Para cada pelcula, necesitamos conocer su ttulo y su categora (ej. Comedia, suspenso, drama, accin, guerra o ciencia ficcin). Tenemos muchas copias de la mayora de nuestras pelculas. Le damos a cada pelcula un identificador especfico, y as podemos saber en que video cassette esta qu pelcula. Un video cassette puede ser tanto de formato Beta como VHS. Siempre tenemos por lo menos un video cassette de cada pelcula que registramos, y cada pelcula es siempre copiada a un video cassette individual y especifica. Nuestros video cassettes son muy largos, as que no tenemos pelculas que requieran de mltiples video cassettes. Frecuentemente nos preguntan por los protagonistas de determinada pelcula. John Wayne y Katherine Hepburn son siempre populares. As, que nos gustara llevar el registro de los actores que aparecen en cada pelcula. No todas nuestras pelculas tienen actores.. A los clientes les gustara conocer el nombre real del actor y su fecha de nacimiento. Nosotros solamente llevamos el registro de actores que aparecen en pelculas de nuestro inventario. Tenemos muchos clientes. Nosotros solamente rentamos videos a la gente que sea socia del video club. Para pertenecer a nuestro club, deben de tener buen crdito. Por cada socio del club, nos gustara registrar su nombre y apellido, su nmero telefnico, y su direccin, y por supuesto, cada miembro del club tiene un nmero de membresa. Necesitamos llevar el registro de que video cassettes ha rentado cada socio en este momento. Un cliente puede alquilar varios video cassettes en un mismo punto del tiempo. Nosotros solamente registramos las rentas actuales. No llevamos rentas histricas.


Primero leer la relacin en una direccin, y despus leer la relacin en la otra direccin.

EJEMPLO:



PRACTICA 3-2

Leer las relaciones.

1. Escribir las oraciones de relaciones para este diagrama E-R.



USAR UNA MATRIZ DE RELACIONES

Se usa una Matriz de Relaciones como una ayuda para la coleccin inicial de informacin sobre las relaciones entre una serie de entidades.



ANALIZAR Y MODELAR RELACIONES

Seguir una serie de 5 pasos para analizar y modelar relaciones.

Pasos

1. Determinar si existe una relacin

2. Nombrar cada direccin de la relacin

3. Determinar la opcionalidad de cada direccin de la relacin.

4. Determinar el grado de cada direccin de la relacin.

5. Leer en voz alta las relaciones para validarlas.



Las siguientes entidades fueron modeladas anteriormente



Estndares de Diagramacin

Los nombres de los atributos estn en singular y se muestran en minsculas Listar los nombres de los atributos en su caja de entidad.

Ejemplo



DIFERENCIAS ENTRE ATRIBUTOS Y ENTIDADES



PRACTICA 3-8

Identificar UIDS.



4 MODELO

DE DATOS CONCEPTUAL AVANZADO


OBJETIVOS DE LA SECCIN

Al finalizar esta seccin, el alumno ser capaz de:

1. Validar que un atributo sea puesto correctamente en base a la dependencia con el UID de la

entidad.

2. Resolver relaciones muchos-a-muchos con entidades interseccin.

3. Identificar y construir un modelo de datos avanzado incluyendo relaciones recursivas,

subtipos y relaciones exclusivas.

4-2 Modelo de Datos Conceptual Avanzado Diseo Relacional de Base de Datos


NORMALIZAR EL MODELO DE DATOS

Normalizar es un concepto de base de datos relacional, pero sus pincipios se aplican al Modelo Conceptual de Datos.

Validar cada atributo usando las reglas de normalizacin.

Regla de Forma Normal Descripcin Primera Forma Normal (1FN) Todos los atributos deben tener un solo valor

para cada instancia

Segunda Forma Normal (2FN) Un atributo debe ser dependiente del identificador nico completo.

Tercera Forma Normal (3FN) Ningn atributo no-UID puede ser dependiente de otro atributo no-UID

Un modelo de datos entidad-relacin normalizado se traslada automticamente dentro de un diseo de base de datos.

NOTAS

La tercera forma normal es un objetivo generalmente aceptado para eliminar

redundancia en un diseo de base de datos.

Formas normales arriba de la tercera forma normal no son comnmente utilizadas.

Diseo Relacional de Base de Datos Modelo de Datos Conceptual Avanzado 4-3


Regla de la Primera Forma Normal

Todos los atributos deben tener un solo valor para cada instancia.

VALIDACIN

Validar que cada atributo tenga un valor nico para cada ocurrencia de la entidad.

Ningn atributo deber tener valores repetidos.

EJEMPLO

La entidad CLIENTE cumple con 1FN? Si no cumple, Cmo se podra convertir a 1FN?

El atributo fecha de contacto tiene mltiples valores, por o tanto la entidad CLIENTE no es considerada como 1FN.

Crear una entidad adicional CONTACTO con una relacin de M:1 hacia CLIENTE.


Si un atributo tiene mltiples valores, se crea una entidad adicional y lo relaciona con la entidad original mediante una relacin M:1


Regla de la Segunda Forma Normal

Un atributo debe ser dependiente del identificador nico completo.

VALIDACIN

Validar que cada atributo dependa completamente del UID. Cada instancia

especfica del UID debe determinar una sola instancia de cada atributo. Validar que un atributo no depende de una sola parte del UID de la entidad.

EJEMPLO

Validar los atributos asignados a la entidad CURSO.

Cada instancia del cdigo de curso determina un valor especfico para el nombre, duracin y cuota. Los atributos estn ubicados correctamente.

EJEMPLO

Validar que los atributos de las entidades de CUENTA y BANCO estn correctamente ubicados.

Cada instancia de un BANCO y nmero de cuenta determinan valores especficos del balance y de la fecha de apertura para cada cuenta. El atributo de localizacin del banco est mal ubicado. Este depende del BANCO, pero no del nmero de cuenta. Este no debera ser un atributo de CUENTA.


Si un atributo no es dependiente del UID completo, est fuera de lugar y deber ser movido.


Regla de la Tercera Forma Normal

Ningn atributo no-UID puede ser dependiente de otro atirubto no-UID.

VALIDACIN

Validar que cada atributo no-UID no dependa de otro atributo no-UID

Mover cualquier atributo no-UID que dependa de otro atributo no-UID.

EJEMPLO

Algn atributo no-UID de esta entidad depende de otro atributo no-UID?

Los atributos nombre del cliente y domicilio dependen de la clave de cliente (Id Cliente).

Crear otra entidad llamada CLIENTE con el campo de Id Cliente como su UID y ubicar los atributos correctamente.

NOTAS

Si un atributo depende de otro atributo no-UID, es necesario mover ambos, el atributo dependiente y el atributo del que depende, a una nueva entidad relacionada con la entidad actual.



PRACTICA 4-1

Normalizar un modelo E-R.

1. Para el siguiente Modelo E-R, evaluar cada entidad contra las reglas de normalizacin, identificar si el atributo est colocado en el lugar correcto; si no lo est, identificar qu regla de normalizacin se est violando.

2. Opcionalmente, redibujar el diagrama E-R en la tercera forma normal.



RESOLUCIN DE RELACIONES M:M

Algunos atributos pueden asociarse con Relaciones M:M.

Resolver relaciones M:M agregando una entidad interseccin con esos atributos.

EJEMPLO

Considerar la relacin M:M entre PRODUCTO y VENDEDOR. Cul es el precio actual de un PRODUCTO especfico para un VENDEDOR especfico?

El precio actual parece ser un atributo de la relacin entre PRODUCTO y VENDEDOR.


Los atributos nicamente describen entidades. Si los atributos describen relaciones, las relaciones debern ser resueltas.


Reemplazar o resolver una Relacin M:M con una entidad Interseccin nueva y con dos relaciones M:1.

EJEMPLO

La relacin M:M entre PRODUCCTO y VENDEDOR puede ser resuelta agregando una entidad interseccin llamada CATALOGO. El precio actual es realmente un atributo de la entidad CATALOGO.

Una vez que est definida la entidad CATALOGO, se analiza la posibilidad de requerimientos para atributos adicionales como: cantidad del paquete y unidad de medida. El UID del CATALOGO es compuesto de estas dos relaciones.

NOTAS

Una entidad Interseccin es frecuentemente identificada por las dos relaciones que le dieron

origen, observar las dos barras UID del ejemplo.

Las relaciones desde una entidad interseccinson siempre obligatorias.

Las entidades interseccin son muy comunes para representar situaciones de negocios en el

mundo real.

Las entidades interseccin normalmente generan requerimietnos para atributos adicionales

como el uso de cantidades y fechas. Estas tienden a ser entidades voltiles y de volmen

alto.



Posicionar las entidades interseccin de tal forma que permitan que Los cuervos siempre vuelen hacie el este o hacia el sur.

Forma de Relacin M:M

Forma correcta de las Entidades Interseccin

NOTAS

Una Entidad de Referencia es una entidad que no ha tenido relaciones obligatorias conectadas a sta.

Cuando las relaciones M:M son resueltas, la forma del diagrama puede ser confusa.



Las relaciones de una entidad interseccin hacia las dos entidades que le dieron origen puede no ser adecuada para definir de forma nica cada ocurrencia de la entidad interseccin.

EJEMPLO

Resolver la siguiente relacin M:M para acomodar estos requerimientos adicionales:

Guardar la fecha en la que cada empleado es asignado a un proyecto, y la duracin de cada asignacin.

Agregar una entidad interseccin llamada TAREA ASIGNADA con los atributos fecha de asignacin y duracin.

TAREA ASIGNADA se identifica parcialmente por las relaciones a EMPLEADO y a PROYECTO, sin embargo, estas dos relaciones no son suficientes para identificar de manera nica a una TAREA ASIGNADA. Un empleado puede tener mltiples asignaciones a proyectos, con diferentes fechas de asignacin. Por lo tanto, el UID de TAREA ASIGNADA deber incluir el EMPLEADO relacionado, el PROYECTO relacionado, y el atributo de FECHA ASIGNADA.



Una vez que se identifica una entidad interseccin, hay que buscar atributos adicionales para describir la entidad interseccin.

EJEMPLO

Qu informacin se necesita conocer sobre la relacin entre PRODUCTO y VENDEDOR?

Nosotros necesitamos guardar el precio actual de un PRODUCTO especfico para un VENDEDOR especfico

Resolver la siguiente relacin M:M para acomodar los requerimientos adicionales

Agregar la entidad interseccin PRODUCTO VENDEDOR con un atributo de precio actual.

Qu otra informacin se necesita conocer sobre el PRODUCTO VENDEDOR?

Nosotros tambin necesitamos conocer la cantidad empacada y la unidad de medida de cada PRODUCTO VENDEDOR



Buscar atributos que identifiquen, o ayuden a identificar una entidad interseccin.

EJEMPLO

Cmo identificar cada PRODUCTO VENDEDOR? Se puede usar la combinacin del cdigo de VENDEDOR y la clave del PRODUCTO?

No, nosotros tenemos un catlogo de todos los PRODUCTOS VENDEDOR, que se pueden adquirir con cada VENDEDOR, y cada uno de ellos tiene un nmero nico en el catlogo.

De acuerdo a las reglas de los negocios, cada PRODUCTO VENDEDOR tiene un nmero nico en el catlogo. Por ello el atributo de NUMERO DE CATALOGO debera ser el UID del PRODUCTO VENDEDOR.



Resolver todas las relaciones M:M al final de la fase de Anlisis. Esta resolucin forzada puede resultar en una Entidad Interseccin sin atributos.

EJEMPLO

En la situacin de la Tienda de Videos, se defini la siguiente relacin M:M.

Al final de la Etapa de Anlisis, el usuario no ha identificado algn atributo asociado con la relacin M:M. Resolver la relacin M:M con una entidad interseccin sin ningn atributo.

NOTAS

Una Entidad interseccin sin atributos es justamente una lista de referencia cruzada en doble sentido entre las ocurrencias de las Entidades.

Una Entidad interseccin sin atributos es la excepcin a la regla de que una entidad debe tener atributos para ser una Entidad.

El UID para una Entidad interseccin vaca, es siempre compuesto de la relacin de las dos entidades que lo originaron.



PRACTICA 4-2

Resolver las relaciones M:M

1. En el modelo E-R de la prctica 3-10 referente al Grupo de Usuarios Oracle, una relacin M:M fue inicialmente modelada entre la entidad MIEMBRO y la entidad AREA DE APLICACIN. Resolver esta relacin M:M basada en el siguiente texto. Requerimientos Adicionales Tambin nos gustara llevar una breve descripcin del inters de cada miembro en cada rea especfica de aplicacin. Por ejemplo, un miembro puede tener un sistema de aplicacin contable muy grande, elaborado por el mismo. Otro miembro puede estar interesado en otra rea de aplicacin sin describir el mismo inters que el miembro anterior.



PRACTICA 4-3

Resolver una relacin M:M.

1. Resolver la siguiente Relacin M:M entre CLIENTE y PRODUCTO. Agregar los atributos fecha de orden, cantidad ordenada y precio.



MODELOJERARQUICO DE DATOS

Representacin jerrquica de datos como un conjunto de relaciones muchos a uno.

EJEMPLO

Modelar la estructura de organizacin jerrquica de una compaa como un conjunto de relaciones M:1

NOTA:

La forma del diagrama E-R de Oracle usando la convencin de Los cuervos siempre vuelan hacia el este o hacia el sur causa que las jerarquas sean dibujadas de abajo hacia arriba.



Los UIDs para un conjunto de entidades jerrquicas pueden ser propagados a travs de relaciones mltiples

EJEMPLO

Cules son los UIDs de las entidades PISO, DEPARTAMENTO y CUARTO?

El UID del CUARTO es la clave de cuarto y est localizado dentro de una DEPARTAMENTO.

El UID de la DEPARTAMENTO es el nmero de habitacin y est localizada en un PISO.

El UID del PISO es el nmero y est contenido dentro del EDIFICIO



Considerar la creacin de atributos artificiales como ayuda para identificar entidades en relaciones jerrquicas

EJEMPLO

Es una estructura tpica de organizacin, Qu puede identificar de manera nica instancias de las entidades DIVISION, DEPARTAMENTO, y EQUIPO?

Cada EQUIPO puede ser identificado basndose en su DEPARTAMENTO, DIVISION y COMPAA. O cada entidad tiene un cdigo artificial de identificacin nico e independiente.

NOTAS

Los cdigos artificiales de identificacin deben ser nicos e independientes. Si las estructuras jerrquicas cambian ocasionalmente, se recomienda usar

identificadores artificiales independientes.



RELACIONES DEL MODELO RECURSIVO

Una relacin recursiva es la relacin entre una entidad con ella misma.

EJEMPLO

Leer la relacin recursiva en el siguiente diagrama E-R.

Cada EMPLEADO puede estar bajo las ordenes de uno y slo un EMPLEADO.

Cada EMPLEADO puede ser gerente de uno o ms EMPLEADOS.

NOTAS

El ciclo puede aparecer en cualquier lado de la caja de entidad pero utilizando la convencin de Los cuervos siempre vuelan hacia el sur o hacia el este. Debemos colocar el ciclo en el ngulo inferior derecho.



Considerar representar una relacin jerrquica como una relacin recursiva.

EJEMPLO

La jerarqua en los negocios se puede dibujar como una relacin recursiva.

NOTAS

Una sola entidad recursiva debe incluir todos los atributos de cada entidad individual. Idealmente, las entidades en cada nivel de la jerarqua deben tener los mismos atributos.

El modelo de organizacin recursiva puede fcilmente manejar la inclusin o eliminacin de capas en la organizacin.

El modelo de organizacin recursiva no puede manejar relaciones obligatorias. Si cada ELEMENTO DE LA ORGANIZACIN debe estar dentro de otro ELEMENTO DE LA ORGANIZACIN, la jerarqua de organizacin debe ser infinita.

La relacin recursiva debe ser opcional en ambas direcciones.



Una lista de materiales puede ser modelada con entidades mltiples para cada categora de una parte y un conjunto de relaciones entre cada una de las entidades.

EJEMPLO

Una organizacin de manufactura de automviles necesita guardar informacin de partes, subensambles, ensambles, y productos. El siguiente diagrama E-R modela estos datos considerando cada una de estas categoras de partes como entidad.



Modelar la lista de materiales como una relacin recursiva de muchos a muchos.

EJEMPLO

Para la organizacin de manufactura de automviles, considerar todas las partes elementales, subensambles, ensamble, y productos como instancias de una entidad llamada COMPONENTE. De esta forma el complejo modelo E-R anterior puede ser remodelado como una simple relacin recursiva.

Cada COMPONENTE puede ser una parte de uno o ms COMPONENTES. Cada COMPONENTE puede estar compuesto de uno o ms COMPONENTES.



Resolucin de la relacin recursiva M:M con una entidad interseccin y dos relaciones M:1 hacia diferentes instancias de la entidad original.

EJEMPLO

Considerar el modelo recursivo de la lista de materiales. Este modelo guarda informacin de cules componentes son partes de un ventilador. Pero si una rondana es parte de una ventilador, Se guardar informacin de cuntas rondanas forman parte de un ventilador?

El atributo cantidad parece estar asociado con la relacin recursiva.

Resolver esta relacin recursiva M:M aadiendo la entidad interseccin REGLAS DE ENSAMBLE y dos relaciones M:1 hacia la entidad COMPONENTE. Las reglas de ENSAMBLE tendrn un atributo de cantidad.

Las dos relaciones M:1 de una instancia de REGLAS DE ENSAMBLE se asociarn con diferentes instancias de la entidad COMPONENTE.

Por ejemplo, la instancia de REGLAS DE ENSAMBLE de rondanas para ventiladores tendr una relacin M:1 hacia la instancia de COMPONENTE para rondanas y una segunda relacin M:1 hacia la instancia de COMPONENTE para un ventilador. La entidad de REGLAS DE ENSAMBLE guardar la cantidad de rondanas que forman parte de un slo ventilador.



RELACIONES QUE MODELAN ROLES

Hay que ser precavidos con las entidades que representan roles.

EJEMPLO

En el modelo Entidad-Relacin para la compaa de entrenamiento, nosotros definimos una entidad INSTRUCTOR y una entidad ESTUDIANTE. Este modelo trabaja bien si un INSTRUCTOR nunca es un ESTUDIANTE, y un ESTUDIANTE nunca es un INSTRUCTOR. Pero Qu pasara si el INSTRUCTOR tambin fuera ESTUDIANTE?

Las entidades que representan roles pueden compartir instancias que se translapan.



Usar relaciones para modelar roles. Las relaciones permiten que una sola instancia de entidad asuma mltiples roles.

EJEMPLO

Para la compaa de entrenamiento, definir una entidad PERSONA que debe tomar los roles de instructor y/o estudiante.



MODELAR SUBTIPOS

Usar subtipos para modelar exclusivamente tipos de entidad que tienen atributos o relaciones comunes.

EJEMPLO

Un negocio tiene definidos dos tipos de empleado: Asalariados y por Honorarios. Para todos los empleados se guarda su nmero, nombre, apellido y departamento asignado. Para los empleados asalariados, guardar su salario. Para los empleados por honorarios, guardar del costo por hora, costo por tiempo extra y sindicato.

Crear un supertipo EMPLEADO con dos subtipos. Cada EMPLEADO puede ser EMPLEADO ASALARIADO o EMPLEADO POR HONORARIOS.

NOTA

Se debe tener cuidado con las instancias que pueden estar en ambos subtipos, la construccin del subtipo-supertipo es incorrecta en esas instancias.



Agregar una nueva entidad para acomodar la relacin que puede variar en el tiempo.

EJEMPLO

El dueo de unos departamentos quiere saber quines son los inquilinos de cada uno de sus departamentos. (Los departamentos slo tienen contratos de renta para una sola persona, no con mltiples personas.) El siguiente modelo E-R slo mantendr al inquilino actual de DEPARTAMENTO.

Agregar la entidad REGISTRO HISTORICO DE RENTA para capturar los valores de las relaciones de renta en el tiempo.



Una entidad interseccin se usa frecuentemente para mantener informacin acerca de las relaciones que cambian con el tiempo.

EJEMPLO

Una sociedad de profesionistas quiere saber, en qu compaas, sus miembros han sido empleados y la finalizacin de cada empleo (por ejemplo de una fecha, a otra fecha). Hay una relacin M:M entre cada socio y cada compaa.

Agregar una entidad interseccin, REGISTRO HISTORICO DEL EMPLEADO, para guardar los empleos que cada empleado ha tenido en el tiempo y las fechas de esos empleos.

Al incluir el atributo de la fecha en el UID del REGISTRO HISTORICO DEL EMPLEADO, este modelo guardar muchas fechas de empleo para una sola compaa y para un solo empleado.



PRACTICA 4-7

Hacer un modelo de relacin compleja.

1. En el MODELO E-R del Grupo de Usuarios de Oracle de la prctica 3-10, una relacin M:M fue inicialmente modelada entre la entidad MIEMBRO y la entidad PLATAFORMA DE COMPUTADORA. Revisar que esa relacin satisfaga los siguientes requerimientos.

Requerimientos

No solo necesitamos conocer que plataforma de computadora utiliza cada usuario. Adems necesitamos conocer que productos de Oracle (RDBMS, Pro*C, SQL *Forms, SQL*TextRetrieval, CASE, Financials, etc) manejada miembro y sobre que plataformas de computadoras corren. No necesitamos conocer la versin especfica de cada producto, slo el nombre general del mismo.



PRACTICA 4-8

PRACTICA OPCIONAL

Desarrollar un modelo E-R complejo.

1. Desarrollar un modelo E-R para el siguiente negocio. Yo soy socio mayoritario en una firma muy grande y diversificada de un bufete jurdico. Mi compaa, Bailey y Asociados, maneja una diversidad de casos incluyendo violaciones de trnsito, peleas domsticas, demandas civiles y casos de homicidio. Tenemos en el bufete a un administrador de base de datos para que organice y registre todo tipo de datos porque la firma ha crecido ms rpido de lo que nos pudimos haber imaginado y actualmente hay casos regados por todo el lugar. Nuestra firma est compuesta de departamentos como litigacin, homicidios, etc y cada caso es asignado a un departamento en particular para fines administrativos. Los abogados tambin son asignados a un departamento en particular, pero esto es slo para fines de nmina y cobranza, ya que un abogado puede trabajar en varios casos de diferentes departamentos. Necesitamos una lista de eventos para un caso dado (esencialmente los antecedentes del caso) que incluyen una bitcora de los eventos y el da en que el evento se volvi efectivo. Los casos pueden ser identificables por un nmero nico que aparece en la lista con cada evento del da y la descripcin del mismo. Los eventos tienen cdigos especiales como A para Abierto, J par Juicio, P para Perdidos, siempre debe de haber un estatus del evento para cada caso. Queremos registrar informacin importante asociada con el caso incluyendo el departamento al que est asignado y una pequea descripcin (tal como Jones vs Jones). Despus de que el caso ha sido cerrado, puede ser reabierto en un da futuro. Le asignamos a estos casos reabiertos un nuevo nmero de caso, pero necesitamos ligar el nuevo nmero de caso con el nmero de caso anterior. Los abogados pueden participar en mltiples casos de la misma manera en que mucha gente puede ser participe de mltiples casos. Por ejemplo, Jones puede ser juez en un caso y testigo en otro. Nosotros solamente estamos interesados en controlar estar partes y los roles en los que juegan en el contexto de un caso particular. Las partes deben de estar identificadas por su nombre y fecha de nacimiento, y de alguna manera por un nmero nico generado por el sistema. Las clases de personas que pueden estar involucradas en casos incluyen jueces (JG), testigos (TT), acusados (AS), y por supuesto los abogados (AG). Por ejemplo, tenemos un caso de asesinato y se trabaja por el acusado. Un abogado es asignado al caso y hay por supuesto, un juez presidiendo al mismo. Hay un testigo. As, que hay cuatro personas. En este contexto, 4-45 Modelo de Datos Conceptual Avanzado Diseo Relacional de Base de Datos


PRACTICA 4-9

Prctica Opcional

Desarrollar un modelo complejo E-R.

1. Desarrollar un modelo E-R para la siguiente situacin. Mi nombre es Phil Sales y trabajo en los Cruceros Shipmore. Hemos decidido que nuestro sistema manual de reservaciones de pasajeros dentro de nuestros barcos no funcionar ms cuando tengamos nuevos barcos. Tendremos dos barcos ms, no botes. Los botes entran dentro de los barcos, y probablemente nos expanderemos a 5 6 para 1995. Cada uno tiene un nombre como Goodsea, Goodwind, y el nuevo es Goodsky, cada uno tiene una capacidad especfica de pasajeros y tiene un registro. El registro es el pas en donde se registr el barco. Necesitamos preocuparnos sobre el tonelaje, o la mecnica, o cualquier otra cosa sobre el barco. Cada ao sacamos un folleto con informacin sobre cada crucero que ofrecemos. Cada crucero tiene un nombre, y una duracin en das. Tenemos cruceros de tres, siete, once y catorce das. Cada crucero tambin tiene un barco asignado especficamente a l, a alguna gente le gusta slo viajar en los barcos ms nuevos. Vamos a necesitar conocer la antigedad de cada barco. Cada crucero se detiene en diferentes puertos. Un crucero de tres das slo tendr una parada, siempre en el segundo da del crucero; un crucero de siete das se detendr en tres puertos; y as sucesivamente. Los puertos van variando dependiendo de donde haya salido el crucero. Los puertos son Los ngeles, Miami y Anchorage, Los cruceros por los ngeles bajan a los puertos de Mxico, como son Cabo San Lucas y Mazatln, los cruceros de Miami van a las Bahamas y las Islas Vrgenes, y el crucero de Anchorage hace paradas a lo largo de todo Alaska. Dependiendo de la duracin de cada crucero, cada barco har llamadas a puertos en das diferentes mientras est afuera. Los pasajeros que viajan con nosotros escogern un crucero determinado, que tendr determinada duracin y un X nmero de puertos, y dependiendo del crucero que elijan nos dir que cabinas estn disponibles. Una vez que hayan escogido una si est disponible, la podemos cotizar. Esto depende del nmero de personas en cada cabina y la clase de la cabina. Siempre que boleteamos una cabina bajo el sistema manual, borramos la cabina del pizarrn de corcho donde llevamos la disponibilidad, a menos de que no est lleno y el pasajero quiera compartirla con alguien ms. Si la cabina tiene capacidad para cuatro personas, y los pasajeros viajan solo, entonces les va a costar ms. Cada pasajero es boleteado, y entonces recibimos su depsito, y despus le pagamos su comisin a la gerencia de viajes que haya hecho la reservacin.



6-4 Diseo Inicial de la Base de Datos Diseo Relacional de Base de Datos


Diseo Relacional de Base de Datos 6-7 Diseo Inicial de la Base de Datos



Nombre de la Tabla: MUNICIPIO


6-40Diseo Inicial de la Base de Datos Diseo Relacional de Base de Datos


7-2 Normalizacin de Tablas Diseo Relacional de Base de Datos


Diseo Relacional de Base de Datos 7-3 Normalizacin de Tablas


8-2 Puntos Adicionales en el Diseo de Base de Datos Diseo Relacional de Base de Datos


Diseo Relacional de Base de Datos 8-3 Puntos Adicionales en el Diseo de Base de Datos


A 2 Servicios y Productos Relacionados Diseo Relacional de Base de Datos


Diseo Relacional de Base de Datos Servicios y Productos Relacionados A 3


A 4 Servicios y Productos Relacionados Diseo Relacional de Base de Datos

MANUAL BD Para Alumnos

Documents

Transcript of MANUAL BD Para Alumnos