MANUAL BD para Alumnos

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

1-2 Introduccin
INTRODUCCION A ORACLE
Diseo relacional de Base de Datos

Introduccin 1-3

1-4 Introduccin
CASE DE ORACLE

Introduccin 1-5

1-6 Introduccin
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.
2.
3.
4.
5.
Identificar y modelar entidades

Analizar y modelar las relaciones entre las entidades
Analizar y modelar atributos
Reconocer Identificadores nicos para cada entidad
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
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
socia del video club. Para pertenecer a nuestro club, deben de tener buen
Por cada socio del club, nos gustara registrar su nombre y apellido, su
telefnico, y su direccin, y por supuesto, cada miembro del club tiene un
de membresa.
que sea
crdito.
nmero
nmero
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
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.
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,
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
Nombre de la Tabla: MUNICIPIO
Nombre de la Tabla: MUNICIPIO
6-40Diseo Inicial de la Base de Datos
7-2 Normalizacin de Tablas
8-2 Puntos Adicionales en el Diseo de Base de Datos
A 2 Servicios y Productos Relacionados
Servicios y Productos Relacionados A 3
A 4 Servicios y Productos Relacionados

MANUAL BD para Alumnos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MANUAL BD para Alumnos

Uploaded by

Copyright:

Available Formats

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

2-8 Introduccin al desarrollo de Base de Datos

Oracle de Mxico S.A de C.V.

Identificar y modelar entidades

Oracle de Mxico S.A de C.V.

MODELO CONCEPTUAL DE DATOS

El modelo conceptual de datos es el primer paso del proceso TOP-DOWN para el

Oracle de Mxico S.A de C.V.

El objetivo del Modelo Conceptual de Datos es desarrollar el Modelo Entidad-Relacin que

Componentes del Modelo Entidad-Relacin

Entidades Son los aspectos importantes acerca de los cuales se necesita

Relaciones Como se relacionan las entidades

Atributos Informacin especfica la cual necesita ser almacenada.

Oracle de Mxico S.A de C.V.

Un modelo Entidad-Relacin es una forma efectiva para integrar y documentar los

Un modelo E-R documenta los requerimientos de informacin de la organizacin en

COMUNICACIN DEL USUARIO

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

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

DEFINICION DEL ALCANCE

INTEGRACIN DE MULTIPLES APLICACIONES

Un modelo E-R provee una estructura adecuada para la integracin de mltiples

Asegurarse de establecer completamente los requerimientos de la informacin de la

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

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.

3-6 Modelo de Datos Conceptual Bsico

Diseo Relacional de Base de Datos

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.

Oracle de Mxico S.A de C.V.

Diseo Relacional de Base de Datos

Modelo de Datos Conceptual Bsico 3-7

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.

Oracle de Mxico S.A de C.V.

3-8 Modelo de Datos Conceptual Bsico

Diseo Relacional de Base de Datos

Oracle de Mxico S.A de C.V.

Oracle de Mxico S.A de C.V.