Introducción

Un tema importante para abordar cuando los conceptos de base

de datos para la enseñanza estudiantes es el mapeo de la base
de datos de diseños conceptuales para modelos específicos de
base de datos de aplicación. Por ejemplo, un curso tradicional en
los sistemas de base de datos relacional normalmente cubre la
Entidad-Relación (ER) y cómo utilizar un diseño ER para generar
un esquema de relación con la clave principal y clave externa
restricciones [4]. Con los avances recientes en la tecnología
basada en objetos, Sin embargo, es importante que los
estudiantes a entender a objetos técnicas para el diseño de
modelado conceptual. Como resultado de ello, también es
importante enseñar las técnicas de mapeo a objetos diseños a la
tecnología relacional tradicional, así como orientada a objetos y
sistemas de bases de datos relacionales a objetosUniversidad
Estatal de Arizona, hemos desarrollado un avanzado base de
datos de curso para estudiantes de pregrado (CSE 494,
http://www.eas.asu.edu/ ~ cse494db) que comienza con
la cobertura de los modelos de base de datos orientada a objetos
utilizando el Mejora de relaciones de entidad (EER) del modelo
[4] y unificada la Modeling Language (UML), diagramas de clases
[7]. Suponiendo un Por supuesto requisito previo en los sistemas
de base de datos relacional (http://www.eas.asu.edu/ ~ cse412),
también cubierta de avanzada base de datos de temas
relacionados con los sistemas de base de datos orientada a
objetos [3], objeto-relacional sistemas de base de datos, acceso
a Internet a bases de datos [2], y el profesionalismo y la ética. El
objetivo de este trabajo es en nuestro enfoque al uso de UML
como la base para un enfoque comparativo para la enseñanza de
técnicas de base de datos de cartografía para relacional,
orientado a objetos, y objeto-relacionales diseños de bases de
datos.

Dado que los estudiantes ya tienen una comprensión básica de

la sala de emergencias modelo, el CSE primera introduce el
modelo 494 TCE y sus características para la herencia de
modelado, las limitaciones sobre la herencia, y categorías.
Luego introducimos la notación de modelado equivalente en
UML, así como características adicionales que UML provee
para modelar el comportamiento, la agregación, y clases
abstractas. Debido a estas características adicionales de
modelado en UML que no existen en el Modelo EER, nos
centramos en el uso de UML para una comparativa análisis de
las asignaciones a los modelos de datos diferentes.
Inicialmente, el uso UML para ilustrar las diferentes opciones
de asignación para los diseños relacionales. Como se introduce
la base de datos orientada a objetos y objeto-relacional
tecnología, usar diferentes características de UML en el mismo
ejemplo de la empresa para ilustrar las técnicas de asignación
que se específicos de cada modelo. Este enfoque proporciona
una base para comparación de lo relacional, orientado a
objetos y objeto-relacional tecnologías en términos de
características, cuestiones de diseño, y la restricción
cumplimiento.

En el resto de este artículo, la Sección 2 proporciona una visión

general de la Escuela de bases de datos empresariales que se
utiliza como un ejemplo de funcionamiento para ilustrar las
técnicas de mapeo. En el ejemplo se introduce el uso
el modelo EER. La sección 3 describe el equivalente UML
notación y la forma en que enseñamos cartografía conceptual
para el modelo relacional. Secciones 4 y 5 problemas de
asignación de dirección para el modelo orientado a objetos y el
modelo objeto-relacional, respectivamente. Sección 6 concluye
el documento con un análisis de las ventajas de nuestro
enfoque.

2 La Escuela de Empresas de base de datos

La Figura 1 muestra el diagrama EER de la base de datos de la
Escuela Empresa. En un diagrama EER, rectángulos
representan clases, diamantes denotan las relaciones entre las
clases, y son óvalos atributos, que están unidos por los bordes
de la clase o de la relación que ellos describen. Los bordes se
utilizan también para referirse a la participación de las clases
en una relación. Un doble filo indica que un instancia de la
clase debe participar en esa relación. La número 1, M o N en
los bordes indican la cardinalidad o número de veces que una
instancia de la clase puede participar en la relación. Un círculo
representa una especialización / generalización relación entre
las clases. Un círculo con una anotada 'd' indica una
especialización disjunta - una instancia de la superclase
no puede ser una instancia de más de una de sus subclases.
Una «o» anotación con el círculo de especialización denota un
posible superposición de especialización.
En la Figura 1, las clases de estudiantes y profesores se
generalizan en una clase de persona. La especialización de la
persona en el estudiante y subclases Facultad es discontinuo,
lo que significa que una persona en este
empresa es un estudiante o una facultad, pero no tanto. El
doble borde de la persona a la especialización círculo indica
que cada La persona tiene que participar en la especialización.
Por lo tanto, una Persona en la empresa debe ser un
estudiante o un miembro de la facultad. La clases de los
estudiantes y la Facultad heredar las propiedades de la
persona y tiene atributos adicionales de los suyos.

Un estudiante tiene un atributo de estado, que indica si el

estudiante es un estudiante de primer año, segundo, tercer, o
cuarto año. Un estudiante también participa
en dos relaciones: grandes y clubes. Un estudiante debe tener
exactamente un mayor y un Departamento de muchos
estudiantes que declaran que departamento como una de las
principales. Un estudiante puede ser miembro de varios
Campus de Clubes. Un CampusClub tiene un identificador
único (CID) y se describe por su nombre, ubicación y teléfono.
Un Club Campus tiene a lo sumo un asesor de la Facultad.
La Facultad tiene un atributo de rango y participa en tres
relaciones: informa, worksIn, y una silla. Una Facultad puede
ser el consejero de la facultad de CampusClubs muchos, pero
no puede ser el asesor de cualquier club. La Facultad debe
estar asociado con el Departamento de que la Facultad de
obras. La Facultad está asociado con exactamente un
Departamento y el Departamento tiene una Facultad muchos
que trabajan en ese departamento. El Departamento se
describe simplemente con un código único y el nombre. Hay
más en una silla de un Departamento.

3 La vista relacional
La figura 2 presenta la versión UML de la base de datos de la
Escuela Empresa. En UML, las clases se representan como
rectángulos con un nombre y una lista de atributos. Una clase
puede tener también una lista de operaciones que definen el
comportamiento de la clase. Subclases, como estudiantes y
profesores están conectados por una línea que
apunta a la superclase Persona con una punta de flecha
abierta. limitaciones de Especialización se encierra entre llaves.
En la figura 2, las limitaciones de la especialización de la
persona en sus subclases Estudiantes y Profesores indican
que la especialización es disjunta y obligatoria (es decir, la
participación en las subclases es necesario).
Relaciones en UML, que se conocen como las asociaciones, se
dibujan como líneas entre las clases. Las líneas pueden ser
mejorados con nombres de relación, los nombres de función, y
multiplicidades. En la figura 2, clubes es un nombre de relación,
con la flecha que indica el negro dirección en la que la relación
que se lee. nombres de funciones proporcionan semántica
adicional a la asociación. Por ejemplo, los miembros representa
el papel de los estudiantes cuando se atraviesan los clubes
asociación de CampusClub con el estudiante. Son las
multiplicidades mismo que cardinalidades en el modelo EER.
Un asterisco (*) representa el
lado muchas de 1: N o M: N asociación. El número 1 indica
por un lado, de un total de 1:1 o 1: N asociación. La notación
01 denota parcial la participación en la asociación.
Una asociación en UML puede ser refinado mediante la
colocación de una flecha en un final de una línea de
asociación. El uso de una flecha que se conoce como
navegación y representa una asociación unidireccional, lo que
indica que la asociación sólo puede ser atravesada en la
dirección indicada
por la flecha. De forma predeterminada, una asociación sin una
flecha bidireccional. La figura 2 muestra un diagrama UML que
representa un enfoque para
la aplicación de la Escuela de Empresa en la base de datos
relacional los datos del modelo, donde los rectángulos de
orejas de perro se observa que
un resumen de las técnicas de asignación utilizados para
diseñar el correspondiente esquema relacional se muestra en
la Figura 3. Las relaciones son
creado para las principales clases de la persona, estudiante de
la Facultad, Departamento y CampusClub. La asociación de
clubes de bi-direccional se asigna a la tabla de clubes por
separado, lo que permite al usuario recorrer el asociación en
ambas direcciones a través de consultas en los Clubes
relación.

Las asociaciones restantes (informa, comedor, worksIn,

majorsIn) son unidireccional, lo que ilustra la asignación técnica
de incrustación la clave principal de una relación en la otra
relación de la asociación como una clave externa. Por ejemplo,
la asociación majorsIn se lleva a cabo mediante la
incorporación de la clave principal del Departamento en los
estudiantes como una clave externa (es decir, el atributo
principal). Esta asignación norma hace hincapié en el concepto
de una asignación de uni-direccional, ilustra cómo un usuario
puede navegar directamente a los estudiantes a
Departamento mediante el atributo principal. En la dirección
opuesta a la Departamento con el estudiante, la navegación no
está directamente apoyada y debe ser alcanzado
indirectamente a través de una consulta a través del Estudiante
relación. Como un ejercicio de estudiante, el uso de la
navegación puede ser retirado de la figura 2 para el 1:1 y 1: M,
para que las relaciones los estudiantes pueden experimentar
con diferentes asignaciones relacionales.
Extracción de navegación de majorsIn en la figura 2, por
ejemplo, sería necesario que la asociación se modela como
una separada relación.

Técnicas de mapeo también se ocupan de apoyo a las

jerarquías de clase. El enfoque se muestra en la Figura 3 se
crea una relación separada para cada superclase y subclase,
con las subclases que contienen la clave de la superclase.
Vistas a continuación, se pueden crear para los estudiantes y
Facultad que se unen cada relación con la Persona de acceso
heredados atributos. Otros enfoques incluyen aplanamiento de
la jerarquía en una relación y las relaciones para la creación de
las subclases sólo [4]. Las limitaciones de la jerarquía debe ser
considerado al elegir el la mayoría de la cartografía
correspondiente.

4 La Vista orientada a objetos

La cobertura de bases de datos orientadas a objetos en la
avanzada base de datos de clase de conceptos incluye el
objeto de gestión de datos
Grupo (ODMG) [1] estándar utilizando la definición del objeto
Idioma (EAD) para especificar esquemas orientados a objetos.
Los estudiantes también tienen una práctica en la asignación
de uso de la Objetividad / DB [6]
producto de base de datos orientada a objetos para reforzar el
teórico conceptos. Figura 4 muestra un diagrama UML que
representa un enfoque para la aplicación de la Escuela de
Empresa en una base de datos orientada a objetos
los datos del modelo. En concreto, el diagrama UML ilustra un
implementación de la aplicación de objetividad / DB. Las
opciones de la aplicación de las asociaciones se basan en la
prestación de estudiantes con ilustraciones de las diversas
alternativas que se disponible en la cartografía de un modelo
conceptual para un OODB.

Figura 5 se presenta una especificación abierta ya distancia

para el diagrama UML de
Figura 4. Los clubes y asesora a las asociaciones se modela
como bidireccional relaciones, que son inherentemente
apoyado en un OODB. Por ejemplo, la relación memberOf en
Estudiantes representa la asociación de clubes y es la inversa
de los miembros relación en CampusClub. La relación y su
inversa son explícitamente definidos, y la coherencia de la
instancia de relación se mantiene automáticamente por el
sistema de base de datos. Un modificación a un lado de los
resultados en la relación mantenimiento automático de los
datos en el otro lado de la relación. La asociación silla ilustra
una uni-direccional relación, que se especifica como el atributo
deptChair en Departamento. Hay un método getChairOf ()
asociado a un Miembro de la Facultad para obtener el papel de
la asociación chairof silla. Las asociaciones majorsIn y worksIn
son bi-direccional en el Diagrama UML, pero no se asignan a
las relaciones en el Especificación de educación abierta ya
distancia. En su lugar, estas asociaciones se representan como
los atributos de ambos lados de las asociaciones. Por ejemplo,
la principales de un estudiante se almacena como el principal
atributo cuyo tipo es una única instancia de la clase
Departamento. El atributo de los estudiantes Departamento es
una colección de los estudiantes. Esta alternativa se muestra
.
que el lado muchos de los de 1: N o M: relación de N puede
ser representado de forma explícita en una OODB, que tiene la
capacidad de almacenar colecciones. El uso de dos atributos
para almacenar una asociación también ilustra las ventajas del
mantenimiento automático función de la relación proporcionada
por una OODB. En el ejemplo aplicación facilitará a los
alumnos pone de manifiesto que la programador de
aplicaciones debe mantener la coherencia de un
asociación que no se almacena como una relación binaria
explícito.

5 La Vista Objeto-Relacional
En la sección de objeto-relacional del curso, comenzamos con
cobertura de las extensiones de objetos que se han
incorporado en el estándar SQL99 [5], así como características
avanzadas de SQL99 como disparadores y procedimientos
almacenados. Luego se dedica a un caso estudio de cómo la
Escuela de bases de datos de empresa se pueden asignar a
el modelo objeto-relacional de Oracle 8i. Figura 6 se presenta
la Esquema SQL99, lo que demuestra las características
objeto-relacionales que debe tenerse en cuenta en el proceso
de asignación. El correspondiente
Diagrama UML se muestra en la Figura 7. Las notas en la
figura 7 describir los detalles de implementación que son
específicos de Oracle 8i [8].
Las características objeto-relacionales de SQL99 incluyen el
uso de objetos tablas, referencias entre tablas de objetos para
representar objetos relaciones, y el uso de matrices para
representar varios valores asociaciones. Tablas de objetos se
crean en primer lugar la creación de un objeto tipo, como
person_udt en la Figura 6. Tipos de objetos son definidos por el
usuario tipos que establecen los atributos, relaciones de objeto,
y métodos de una clase. Un tipo como person_udt se utiliza
para crear la tabla persona. Las instancias de la tabla persona
tendrá identificadores de objetos como en el modelo orientado
a objetos. Tipos de objetos pueden formar en las jerarquías
que la herencia de apoyo. En el faculty_udt tipo, la frase "en
person_udt" define faculty_udt ser un subtipo de person_udt.
La facultad que corresponde tabla de objetos será una
subclase de la tabla de objetos persona, heredar los atributos,
relaciones y métodos de una persona.
Las referencias entre objetos se llaman REFERENCIAS en
SQL99. Por ejemplo, la tabla contiene un campusClub REF a
los objetos de tipo faculty_udt para aplicar el asesor de un club.
En el inverso dirección, una serie de REFERENCIAS se utiliza
en faculty_udt para almacenar los clubes que un miembro de la
facultad asesora. Desde las tiendas matriz REFERENCIAS al
club objetos, el método getClubsAdvised se utiliza para
devolver los nombres de
 los objetos del club que se hace referencia en la matriz. El
getClubs método en el student_udt se utiliza para un propósito
similar. Aunque no está demostrado en este trabajo, les
enseñamos el uso de disparadores para mantener inversas en
la tecnología objeto-relacional y comparar este enfoque manual
para mantener inversas a la automática enfoque proporciona
bases de datos orientadas a objetos. Observe también que
en la figura 7, las relaciones majorsIn y worksIn son
unidireccionales. Como resultado, los métodos se agregan a la
department_udt a proporcionan procedimientos almacenados
que utilizan las consultas sobre tablas de objetos a calcular la
inversa de cada relación.
Después de los estudiantes a entender la cartografía con el
objeto-relacional características de SQL99, que luego presentar
un estudio de caso junto con una aplicación de asignación
utilizando Oracle 8i. Oracle 8i no apoyan directamente la
herencia con la virtud de la cláusula que en
SQL99, para que los estudiantes deben aplicar las técnicas que
aprendieron de asignaciones relacionales para simular la
herencia. Oracle 8i también proporciona varrays (es decir,
matrices, de tamaño fijo) y tablas anidadas (es decir,
variable colecciones de tamaño) como alternativas para la
aplicación de matrices de SQL99. Figura 7 puntos de la manera
en que utilizar estas funciones en la Empresa de la Escuela de
bases de datos.

6 Resumen
En este trabajo se ha presentado un enfoque para el uso de
UML como la base para un análisis comparativo de las
asignaciones a relacional, orientado a objetos,
y objeto-relacionales diseños de bases de datos. Hemos
utilizado este método con éxito en tres diferentes ofertas de la
Por supuesto. Los estudiantes aprenden los entresijos de UML
como una modelización alternativa al modelo EER. También
aprenden la navegación función de UML se puede utilizar para
comunicar la aplicación directivas para el proceso de
asignación. Los estudiantes experimentan las ventajas de
mantenimiento automático de las relaciones en una base de
datos orientada a objetos modelo, en comparación con la
aplicación alternativas en los modelos relacionales y objeto-
relacionales que requieren el desarrollo de código para
mantener relaciones inversas.
Los estudiantes también se ocupan de las técnicas de mapeo
desde el punto de
Habida cuenta de las normas de ODMG y SQL99, así como
específicos implementaciones comerciales de cada norma.

Estamos actualizando el estudio de caso objeto-relacional a la

uso de Oracle 9i. También estamos revisando el material para
proporcionar mayor énfasis en el papel que juegan las
restricciones en la asignación y la aplicación de procesos y las
diferencias que existen entre la aplicación de las limitaciones
de cada modelo.