INSTITUTO TECNOLGICO SUPERIOR DE JESS CARRANZA

ING. EN SISTEMAS COMPUTACIONALES

DISEO DE BASE DE DATOS ING. RAFAEL AGUILAR SIXTO

JOSUE HEBERTO OCHOA VELASQUEZ

TRABAJO DE INVESTIGACIN
UNIDAD 1 1.3. MODELO DE ENTIDAD RELACION EXTENDIDO 1.4 HERRAMIENTAS CASE Sexto semestre GRUPO: 602A

JESS CARRANZA, VER.

23 NOVIEMBRE DE 2011.

INTRODUCCIN Dentro de lo que es el modelo de relacin tenemos varias cosas que aprender desde los diagramas de flujo hasta las flecas de direccin que es la que nos indican como se realiza el recorrido de dicho diagrama. Dentro de lo que es el modelo entidad relacin extendido veremos como llegar a realizar un modelo que dentro de lo que son sus atributos desarrollar hasta las ultimas caractersticas que posea cada entidad de la clase o del objeto de la que se elabora el diagrama. A continuacin tenemos la descripcin mas detallada paso a paso delo que consta un diagrama entidad relacin extendido.

1.3 MODELO ENTIDAD RELACIN

El modelo Entidad- Relacin, es un modelo de datos semntico. En la primera propuesta del Modelo E/R, Chen (1976), se distinguen en tan solo tres conceptos fundamentales: EntidadRelacin-Atributos. El Modelo Entidad Relacin (ER) permite desarrollar un diseo de base de datos en un esquema de alto nivel conceptual sin considerar los problemas de bajo nivel como la eficiencia, el modelo implcito del administrador de base de datos o las estructuras fsicas de los datos. El Modelo Entidad Relacin se hizo muy popular para el diseo de base de datos y es usado extensivamente. Para aumentar su poder de expresin, muchos investigadores han introducido o propuesto ciertas extensiones a este modelo. Algunas de estas extensiones son importantes, mientras que otras agregan poco poder de expresin, pero proveen caractersticas auxiliares. Puesto que el Modelo Entidad Relacin es ampliamente usado, es importante conocer qu extensiones han sido propuestas para este modelo y qu ofrecen estas extensiones a los usuarios. El objetivo de este artculo es estudiar las extensiones al Modelo Entidad Relacin ms importantes y evaluar sus mritos. Resaltamos que detrs de las diferencias sintcticas de algunas extensiones hay un enriquecimiento de la semntica de las relaciones entre las entidades.

1.3 MODELO ENTIDAD RELACIN EXTENDIDO

Entidad ( entity ) Atributo ( attribute ) Dominio ( values set ) Relacin ( relationship ) SIMBOLOGIA BASICA

El MER es extensamente usado durante el anlisis de requerimientos y para un modelamiento conceptual de la base de datos. Debido a su simplicidad, es ms fcil de entender por individuos no tcnicos. Pruebas en el ambiente de un mundo real han mostrado que es una efectiva herramienta de comunicacin entre diseadores de base de datos y usuarios finales. COMPONENTES DEL MODELO ENTIDAD RELACIN Los componentes principales del MER son los tipos-entidad, tipos-relacin y los atributos. Una entidad es definida como una cosa la cual puede ser identificada como nica. Esta puede ser una persona, un tem, o un concepto sobre el cual una organizacin desea guardar datos. Las entidades que comparten propiedades similares pueden ser clasificadas en tipos-entidad, tales como EMPLEADO y DEPARTAMENTO. Las entidades pueden tener ciertas relaciones unas con otras, estas relaciones pueden ser clasificadas en tipos-relacin. Por ejemplo, ADMINISTRA es un tipo-relacin entre el los tipos-entidad EMPLEADO y DEPARTAMENTO. La relacin puede ser uno-a-uno, como CASADO lo es entre dos entidades PERSONA, uno-amuchos como ENSEA entre PROFESOR y varias entidades CURSO, o muchos-a-muchos como TRABAJA-EN entre muchas entidades EMPLEADO y muchas entidades PROYECTO. En el modelo de Chen, las entidades y relaciones tienen propiedades, llamadas atributos. Por ejemplo, EDAD es un atributo de la entidad EMPLEADO y HORAS-TRABAJADAS es un atributo de la relacin TRABAJA-EN entre EMPLEADO y PROYECTO. Un atributo puede tomar valores de un cierto tipos de datos. Un atributo multivariado puede tener ms de un valor. Por ejemplo, el GRADOACADMICO de una entidad PROFESOR. Cada entidad debe tener un nico identificador que la distinga de las otras entidades del mismo tipo. Este podra ser un atributo ya en uso, como el nombre de empleado, o podra ser un atributo agregado por su unicidad, como el nmero de identificacin nacional del empleado. Chen compara el identificador de la entidad con el concepto de clave primaria en las bases de datos convencionales. Las relaciones son identificadas por el uso de los identificadores de todas las entidades involucradas en la relacin. En el caso de una relacin que involucra entidades del mismo tipo, se deben asignar roles como, por ejemplo, ESPOSO y ESPOSA en la relacin MATRIMONIO. Una entidad puede depender de entidades de otros tipo-entidad para su existencia. En este caso Chen habla de entidad 3dbil.

DIAGRAMAS ENTIDAD RELACIN En el MER original, un tipo-entidad es representado por un rectngulo con el nombre del tipoentidad dentro de l. Un tipo-relacin es representado por un diamante, con el nombre de la relacin dentro. Tipos-entidad relacionados estn conectados al diamante por lneas rectas. Cada lnea es marcada con un 1, N o M para indicar relaciones del tipo 1:1, 1:N o M:N. Un tipo-entidad dbil es encerrado dentro de un rectngulo de doble lnea, se coloca una E en el

diamante del tipo-relacin y una flecha apunta hacia el tipo-entidad dbil. El rectngulo de doble lnea tambin es usado para un tipo-entidad dependiente-ID, con un ID en el diamante del tiporelacin y una flecha hacia la entidad dependiente. Un tipo de dato de un atributo es representado por un crculo con el nombre del tipo de dato adentro, conectado por una flecha a su tipo-entidad. El nombre del atributo se aade a la flecha a menos que el nombre sea el mismo que el nombre del tipo de dato. Un ejemplo de nombres diferentes es un tipo de dato FECHA el cual es usado para el atributo de FECHADENACIMIENTO de una entidad EMPLEADO. Los atributos multivariados son indicados poniendo 1:N cerca de la flecha de conexin. MODELAMIENTO DE DATOS CON NFASIS EN LAS RELACIONES El modelo relacional revolucion el campo al separar la representacin lgica de los datos de la implementacin fsica. Los modelos semnticos fueron introducidos en primer lugar como herramientas para el diseo de esquemas. El nfasis de los modelos semnticos iniciales era modelar cuidadosamente las relaciones que frecuentemente aparecen en las aplicaciones tpicas de bases de datos. Consecuentemente, los modelos semnticos son ms complejos que el modelo relacional y alientan una visin ms navegaciones de las relaciones entre los datos. El MER fue el primer modelo semntico centrado alrededor de las relaciones ms que en los atributos. EL MER ve el mundo como un conjunto de entidades y relaciones entre estas entidades. La filosofa subyacente es que un atributo es slo un simple hecho acerca de una entidad, mientras que una relacin puede modelar la construccin de entidades ms complejas a partir de otras entidades. ORGANIZACIN El poder de modelamiento del MER depende fuertemente de los diagramas entidad relacin. Es por esto que en este artculo nuestra discusin sobre la evolucin del modelamiento ER estar fuertemente centrado en la evolucin de los diagramas ER. No puede lograrse un buen entendimiento de la semntica involucrada en el MER sin un cuidadoso estudio de la representacin sintctica en los diagramas ER. Detrs de un simple cambio sintctico puede haber una importante mejora semntica, un cambio de significado, o algunos otros cambios cruciales en el modelamiento de datos. Un buen ejemplo es el significado de la relacin ternaria. Sintcticamente, una relacin ternaria es muy similar a una relacin binaria; sin embargo, hasta muy recientemente no exista un anlisis detallado de las combinaciones de cordialidades binarias/ternarias. Asumimos que el lector est familiarizado con el concepto de sistemas de base de datos. Tambin es deseable algn conocimiento de conceptos de orientacin a objetos.

EXPANSIONES DEL MODELO ENTIDAD RELACIN ORIGINAL Objetos y clases Un tipo entidad representa una clase de objetos del mundo real as como un tipo-relacin representa un agregado de uno o ms tipos de entidades. Ellos introducen el trmino rings (anillos) para describir una relacin binaria que conecta una entidad consigo misma, la cual es llamada relacin recursiva por otros autores. Se refieren a tres clases de objetos: entidades, atributos y relaciones de Chen. Ellos explican, que las entidades eran los principales objetos acerca de los cuales se recolectaba informacin y usualmente se referan a una persona, lugar, cosa o evento de inters informacional. Los atributos eran usados para detallar las entidades otorgndoles propiedades descriptivas como un nombre, color y peso. Las asociaciones entre entidades son representadas por las relaciones. Y agregan que los objetos son calificados por atributos y son clasificados dentro de grupos de objetos. Esto ayuda a entender el modelo bsico en trminos de objetos y clases ya que esta terminologa ser usada para explicar conceptos avanzados. Las restricciones de las relaciones Los valores de la conexin son o uno o muchos. La cardinalidad como el nmero real asociado con el trmino muchos. Como Chen, ellos usan una notacin 1:1, 1:N, M:N en su modelo. Batini et al.[4] usan una notacin ms especfica que muestra el nmero mnimo de cardinalidad, llamado min-card, y el mximo llamado max-card. Estos son expresados en el diagrama como (min-card, max-card). Por ejemplo, (1, 5) significa que una entidad debe participar en un mnimo de 1 y en un mximo de 5 instancias de la relacin en cualquier momento. El mnimo de 1 tambin implica que la participacin de la entidad en la relacin es obligatoria. MODELOS ENTIDAD RELACIN EXTENDIDOS Diagramas ERE. La figura 1 muestra como se representa la especializacin en un diagrama ERE. Las subclases definidas por una especializacin estn unidas mediante lneas a un circulo, que conecta con la superclase. El smbolo de pertenencia en las lneas entre las subclases y el circulo representan la direccin de la relacin clase/subclase. Los tributos aplicables solamente a cada una de las subclases se unen a estas mediante arcos (por ejemplo, velocidad en la subclase SECRETARIA). Estos atributos se denominan atributos especficos de la subclase. Las subclases tambin pueden tener relaciones especificas con otras entidades (por ejemplo, la relacin PERTENECE entre SUBCONTRATADO y EMPRESA). El smbolo d del crculo se explicar mas adelante.

Utilizacin de subclases en los modelos de datos. Hay dos razones principales para el uso de la relacin clase/subclase en los modelos de datos. La primera es que ciertos atributos no pueden ser aplicados a todas las ocurrencias de entidad correspondiente a la superclase. Una subclase se define para agrupar aquellas ocurrencias de entidad donde el atributo es aplicable. Suele ocurrir que las subclases comparten la mayora de los atributos correspondientes a la supercalse. Por ejemplo, SECRETARIA tiene el atributo de velocidad mientras que INGENIERO tiene tipo, sin embargo ambos comparten los mismos atributos de EMPLEADO.

Figura 1.

La segunda razn para la utilizacin de subclases es que algunas relaciones pueden tener sentido solo para algunas ocurrencias de entidad de la superclase. Por ejemplo, si solo los empleados subcontratados pueden pertenecer a otras empresas, podremos representar este hecho mediante la creacin de la subclase SUBCONTRATADO y relacionarla con la entidad EMPRESA mediante la relacin PERTENECE, como se puede ver en la figura 1. Generalizacin. El proceso de especializacin expuesto en el punto anterior nos permite lo siguiente: Definir un conjunto se subclases a partir de una entidad. Asociar atributos especficos a cada subclase. Establecer relaciones especficas entre cada subclase con otras entidades o subclases.

El Modelo EER de Teorey, Yang y Fry Teorey et al. Dicen que la introduccin de la abstraccin de categoras en el MER resulta en dos tipos adicionales de objetos: jerarquas de subconjuntos y jerarquas de generalizacin. Ellos dicen que las jerarquas de subconjuntos especifican subconjuntos con posibles intersecciones y la jerarquas de generalizacin especifican subconjuntos estrictamente disjuntos. Un tipo-entidad E1 es un subconjunto de otros tipo-entidades E2 si cada ocurrencia de E1 es tambin ocurrencia de E2. En una jerarqua de generalizacin, cuando un tipo-entidad E es una generalizacin de tipos-entidad E1, E2, ..., En, cada ocurrencia del tipo-entidad E tambin es una ocurrencia de uno y slo uno de los tipos entidad E1, E2, ..., En. Por ejemplo, en el diagrama EER de la fig.3., FACULTATIVO y ESTUDIANTE son subconjuntos de PERSONA (asumiendo que una persona puede ser un miembro de la facultad y al mismo tiempo un estudiante), mientras que CURSO es una generalizacin de CURSO-CONCRDITOS y CURSO-SIN-CRDITOS. Una jerarqua de generalizacin es llamada jerarqua es-un exclusiva. Cada tipo-entidad subconjunto es mostrado en el diagrama EER con una flecha gruesa de lnea doble apuntada al tipo-entidad del cual es subconjunto. La jerarqua de generalizacin es mostrada con una flecha gruesa de lnea doble desde cada subconjunto a un hexgono que contiene un nombre que caracteriza a todos los subconjuntos (TIPO-CURSO en el ejemplo anterior), y otra flecha gruesa desde el hexgono al tipo-entidad genrico. En los pasos para usar su modelo, Teorey et al. Instruyen al usuario a poner el identificador y descriptores genricos en el 8 tipo-entidad genrico y poner el identificador y descriptores especficos en los tipos-entidad subconjuntos. As, en nuestro diagrama EER de ejemplo, RUT y NOMBRE son mostrados como atributos de PERSONA mientras que FACULTATIVO y ESTUDIANTE tienen sus propios atributos junto al identificador RUT. 1.4 HERRAMIENTAS CASE

Que es CASE? (Computer Aided Software Engineering)

"CASE es la automatizacin del software" "CASE es una filosofa que se orienta a la mejor comprensin de los modelos de empresa, sus actividades y el desarrollo de los sistemas de informacin. Esta filosofa involucra adems el uso de programas que permiten: Construir los modelos que describen la empresa, Describir el medio en el que se realizan las actividades, Llevar a cabo la planificacin, El desarrollo del Sistema Informtico, desde la planificacin, pasando por el anlisis y diseo de sistemas, hasta la generacin del cdigo de los programas y la documentacin."

"La creacin de software utilizando tcnicas de diseo y metodologas de desarrollo bien definidas, soportadas por herramientas automatizadas operativas en el ordenador".

Objetivos del CASE

1. Aumentar la productividad de las reas de desarrollo y mantenimiento de los Sistemas informticos. 2. Mejorar la calidad del software desarrollado. 3. Reducir tiempos y costes de desarrollo y mantenimiento del software. 4. Mejorar la gestin y dominio sobre el proyecto en cuanto a su planificacin, ejecucin y control. 5. Mejorar el archivo de datos (enciclopedia) de conocimientos (know-how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores.

Automatizar: El desarrollo del software La documentacin La generacin del cdigo

 El chequeo de errores La gestin del proyecto 7. Permitir La reutilizacin (reusabilidad) del software La portabilidad del software La estandarizacin de la documentacin

8. Integrar las fases de desarrollo (ingeniera del software) con las herramientas CASE 9. Facilitar la utilizacin de las distintas metodologas que desarrollan la propia ingeniera del software.

Enciclopedia (Repository)

En el contexto CASE se entiende por enciclopedia a la base de datos que contiene todas las informaciones relacionadas con las especificaciones, anlisis y diseo del software. En esta base de datos se incluyen las informaciones de:

1. DATOS: Elementos atributos (campos), asociaciones (relaciones), entidades (Registros), almacenes de datos, estructuras, etc.

2. PROCESOS: Procesos, Funciones, mdulos, etc.

3. GRAFICOS: DFD (Diagrama de flujo de datos), DER (Diagrama Entidad Relacin) DFD (Diagrama de Descomposicin Funcional), ED (Diagrama de Estructura), Diagrama de Clases, etc.

4. REGLAS: de Gestin, de mtodos, etc.

Clasificacin de las Herramientas CASE

Como ya hemos comentado en los apartados precedentes CASE es una combinacin de herramientas software (aplicaciones) y de metodologas de desarrollo : Las herramientas permiten automatizar el proceso de desarrollo del software. Las metodologas definen los procesos automatizar.

TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informtico: Planificacin estratgica, Anlisis, Diseo, Generacin de programas.

WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la Automatizacin del proceso completo de desarrollo del sistema informtico.

Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en cdigo ejecutable y su documentacin. Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan:

UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de Planes Corporativos. MIDDLE CASE: Anlisis y Diseo. LOWER CASE: Generacin de cdigo, test e implantacin

CONCLUSIN Se le llama si extendido debido a que despus de las ramas principales de la clase se sigue extendiendo de acuerdo a las caractersticas que se pueden tomar como base en una clase es decir en las ramas se seguir anotando lo que seria sus funciones de cada objeto de la relacin y pues se extiende hasta lograr especificar un objetivo en si.

BIBLIOGRAFIA http://www.dcc.uchile.cl/~cgutierr/cursos/BD/extendido.pdf http://www.slideshare.net/guestf131a9/herramientas-case http://ceds.nauta.es/informes/Practicas%20CASE_Ejemplo_Tutorial.pdf